Thoughts on the Web Browser Landscape

‍

As I’m sure many people have heard over the course of the last few days Chrome’s developers have chosen to change the way Chrome’s advertising, JavaScript, XHR connection, CSS, and iframe blocking functionality works by deprecating the blocking capabilities of the webRequest API in Chrome’s Web Extension Manifest V3.

Now that the dust has settled somewhat in part 1 of this article I’d like to offer my thoughts on Manifest V3 and attempt to give some possible clarification to misunderstandings around this hot button issue. In part 2 of this article I'd like to offer a number of possible future paths to dealing with the impending change.

On performance gains made by setting webRequestAPI to ‘observe only’ and replacing this functionality with the new declarativeNetRequest API:

In the original Google Groups thread some developers using the webRequest API conducted their own performance analysis of the existing API’s blocking methods compared to the proposed changes and they concluded that the difference in speed seen when comparing the new declarativeNetRequest API to the webRequest API was overshadowed by the speed increases that come from the more powerful blocking functionality offered by the webRequest API's ability to block tracking scripts, and loading of advertisements as compared to the more limited functionality offered by the declarativeNetRequest API which is limited to a static filter list of 30 thousand entries and a dynamic filter list of 5000 entries essentially crippling the extension's ability to reliably whitelist scripts or provide a verbose list of tracking scripts that span most websites (compare the limitations to Ublock's "EasyList" for example). In these performance tests the webRequest blocking method itself accounted for 1 millisecond which one would imagine would not be enough of a difference to justify such a significant change in the API's functionality on it's own. The methodology may have been incomplete given the tests were run using components of Chrome rather than the entire Chrome stack, however we cannot be certain of the thought process change (if any at all) that may have gone on inside the Chrome team as a result of these performance tests done by the extension developer community as they have not yet responded to any of the comments in the thread which have attempted to deconstruct their stated reasoning for the change.

For those that have not read the original extensions Google Groups thread it can be found here.

On “Enterprise Deployment” exemptions.

From the Chrome Team’s statement the extensions Google Groups thread:

>"Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments)."

Many journalists have speculated that this means paying Chrome customers. I am not entirely certain about this however based on my reading of Hacker News it does appear that this enterprise mode can be enabled using Windows Group Policy and it is not limited to users who purchase a license for a premium deployment of Chrome.

Some closing anecdotal thoughts on “boiling out the power users":

Chrome's changes remind me of Microsoft's transition to Windows as a service which came along with the addition of much more telemetry (key logging, advertising identifier strings, collection of browsing history) than was seen in prior versions of Windows as well as other features which were highly unpopular with the userbase such as Microsoft Store, Microsoft Account, Cortana, and integrated advertising functionality. Microsoft's new stated goal is to become a services business rather than a business that sells enterprise software and copies of Windows. With that change came the addition of a number of user-hostile changes that many of the so called "Windows Power Users" who had been on the platform for years despised. Microsoft however made some smart decisions about how to go about implementing these new features. In this section I'll draw some comparisons between Microsoft's decisions with Windows 10 and Google's decisions with Chrome's Manifest V3.

I have been watching the Chromium Google Group and I noted that what appears to be taking place is Chrome’s developers are using the same tactics that were used to split the power user group from the target majority in terms of their behaviour. Based on my recollection of forum posts I read at the time this was called “boiling the power users out” or something similar. From what I can remember this tactic involves implementing harmful features in such a way that the very loud “power user” minority would be able to nullify changes that are otherwise just out of reach for the average user.

The main advantage of this approach is that the core technical users might have held some sway over the system’s technical progression over time which acted as a sort of shield for regular users who would otherwise just go along with whatever software changes were imposed on them. When the “power users” would complain and eventually the company would revert their changes the ones who were upset really did not comprise the bulk of the target population to begin with.

Enter the “boiling” strategy. By “boiling” the loud minority out of the mix with slightly difficult configuration tweaks they were able to for the most part still impose their desired harmful anti-feature additions (perhaps spyware/adware/ect..) on the primary population of users without being forced to revert their changes as a consequence of collective action by the loud “power user” minority.

Chrome’s Extension Manifest V3 appears to be doing the same thing. Supposedly the limits imposed by the new declarativeNetRequest API will be possible to nullify with Windows Group Policy as well as presumably minor adjustments to the Chromium's source code and recompilation for MacOS and Linux users which places the skill barrier for nullifying these harmful changes at precisely the level that would be possible for the loud minority of core technical users to accomplish while also preventing the core audience of Chrome users from escaping these new harmful features. By doing this the informed core technical audience would simply fix the problems for their own machines and go on about their business rather than making a lot of noise and boycotting the product.

‍