Thoughts on the Web Browser Landscape

Arthur Rasmusson | COO, Arc Compute
June 4, 2021
Connect with us
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The Arc Stack

The ultimate software stack for AI and Machine Learning
Reserve GPUs

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.


Looking to learn more about Arc Compute?
Read our latest white papers and case studies.
Arc Compute GPU Cloud Infrastructure

Arc Compute - Company Summary

Arc Compute's customers have one thing in common; they are all large consumers of GPUs who are tired of the current cloud business models and are looking for better, transparent pricing and better performance and security.
Download Now
Arc Compute GPU Cloud Infrastructure

Arc Compute Powers GPU Cloud Offering with Liqid

"Arc Compute, the only cloud service provider to offer Liqid’s revolutionary composable disaggregated infrastructure (CDI) as a service, proposed a GPU cloud option that offered the immersive video company a far more flexible and cost-effective solution".
Download Now
Arc Compute GPU Cloud Infrastructure

Hyperborea - Superior GPU Cloud Performance

As you will see in the following benchmarks, by utilizing Arc’s exclusive software via The Arc Cloud, your workloads can train up to 80% faster. This software is currently used in Arc’s GPU cloud service, with on-premise licensing available soon.
Download Now
Connect with us
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The Arc Stack

The ultimate software stack for AI and Machine Learning
Reserve GPUs

The Arc Blog

Arc Compute: a custom GPU cloud provider
August 23, 2022
Read More
Arc Blog - LibVF.IO: Add GPU Virtual Machine Support

Arc Blog - LibVF.IO: Add GPU Virtual Machine Support

Arthur Rasmusson | COO, Arc Compute
August 24, 2022
LibVF.IO (vGPU & SR-IOV on Consumer GPUs) has added support for GPU Virtual Machine (GVM).
Read More
Arc Blog - Experience Better GPU Performance in the Arc Cloud

Arc Blog - Experience Better GPU Performance in the Arc Cloud

Erik Kimmerer | Sales & Marketing Specialist, Arc Compute
August 23, 2022
Learn how Arc's GPU hypervisor, Hyperborea, increases GPU performance through exclusive configurations made possible thanks to Simultaneous Multi-Virtual GPU
Read More
Arc Blog - The Web Browser Landscape

Arc Blog - The Web Browser Landscape

Arthur Rasmusson | COO, Arc Compute
June 4, 2021
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...
Read More
Arc Blog - Closed Investment Round with OPN & Supporters Fund

Arc Blog - Closed Investment Round with OPN & Supporters Fund

Justin Ritchie | CEO, Arc Compute
June 5, 2021
Typically, when a GPU cloud consumer is utilizing their provider’s GPU compute, the provider must either run single physical devices per user or instead use expensive multi-user sharing...
Read More
Arc Blog - Why Augmented Reality is Not Ready

Arc Blog - Why Augmented Reality is Not Ready

Arthur Rasmusson | COO, Arc Compute
June 24, 2021
What enabled VR to become functionally capable of inducing reliable "presence" (the qualitative threshold for experiences that convince all the cognitive systems that make up your conscious...
Read More
Arc Blog - Learning from OpenBSD to Make Computers Better

Arc Blog - Learning from OpenBSD to Make Computers Better

Arthur Rasmusson & Louis Castricato
December 5, 2019
This is an attempt to consolidate down a number of threads spanning separate discussions from around the 'net I have been having on the subject of operating system development models and...
Read More
Looking to learn more about Arc Compute?
Read our latest white papers and case studies.
Arc Compute GPU Cloud Infrastructure

Arc Compute - Company Summary

Arc Compute's customers have one thing in common; they are all large consumers of GPUs who are tired of the current cloud business models and are looking for better, transparent pricing and better performance and security.
Download Now
Arc Compute GPU Cloud Infrastructure

Arc Compute Powers GPU Cloud Offering with Liqid

"Arc Compute, the only cloud service provider to offer Liqid’s revolutionary composable disaggregated infrastructure (CDI) as a service, proposed a GPU cloud option that offered the immersive video company a far more flexible and cost-effective solution".
Download Now
Arc Compute GPU Cloud Infrastructure

Hyperborea - Superior GPU Cloud Performance

As you will see in the following benchmarks, by utilizing Arc’s exclusive software via The Arc Cloud, your workloads can train up to 80% faster. This software is currently used in Arc’s GPU cloud service, with on-premise licensing available soon.
Download Now