Skip to content
Check other posts

Chrome Manifest v3 musings

Published: at 10:22 PM

mlembug:

tevruden:

You Have until June To Dump Chrome

Google has announced that starting in June 2024, ad blockers such as uBlock Origin will be disabled in Chrome 127 and later with the rollout of Manifest V3 (#Mv3).

Resuming the transition to Manifest V3 - Chrome for Developers

Firefox is RIGHT there

The original post does not explain it well enough, so I will do it instead:

Google intends to make a change to Chromium that has been announced a while ago, and the deadline has been moved a few times, that among other things, affects how extensions can act upon what happens when a browser downloads a webpage, which will affect ad blocking.

The new approach is fundamentally different to what extensions could do before, and ad blockers for Chromium-based browsers will need to adapt to new approach in order to keep working after this change gets introduced.

The link above leads to the Google’s announcement, where in one of the linked pages, they provide an explanation for why they do this

Blocking or modifying network requests in Manifest V2 could significantly degrade performance and require excessive access to sensitive user data. The Declarative Net Request API allows extensions to block or modify web content with fewer permissions and without hindering performance.

The link below leads to a discussion on what it will specifically affect, and in particular it has gorhill (the original author of uBlock Origin, and also the current maintainer), mentioning an attempt at making a version of uBlock Origin that works under the new approach, and a technical overview of the differences.

Chrome extension manifest v3 proposal · Issue #338 · uBlockOrigin/uBlock-issues

The summary of what is no longer working in uBlock Origin Lite in comparison to regular uBlock Origin is as follows:

which leads to the conclusion that the ad blockers will be more restricted and less effective.

Several further observations are worth including:

On recent YouTube fight against adblockers

Updating filter lists under the new approach requires extension update. This, combined with how recently YouTube (owned by Google) started doing frequent updates to the site and uBlock Origin’s filter lists are frequently updated in turn… combined with how extension updates need time for an approval… by Google… before they are published in the extension store… leads to an obvious conclusion.

On the differences between old and new approach

With the old approach (the “imperative” approach), when a browser makes a request, it asks the extension what to do with it, at which point the extension can 1.) examine the request 2.) tell the browser what to do with it. With the new approach (the “declarative” approach), the extension never gets a request to examine. Instead, the extension, during installation time, tells the browser of all the addresses and rules to match these addresses to block, and the responsibility to check if an address matches these rules falls to the browser.

This is what Google is attempting to convey in the quote with “could significantly degrade performance and require excessive access to sensitive user data”. Given the fact that extension can examine a request before it can make a decision whether to block it or let it happen, could in theory slow things down if an extension takes a long time to make a decision. Also the fact that it can examine the request means the extension knows what addresses user goes to.

On why Google’s explanation is an obvious excuse

  1. This processing time in well designed extensions takes almost no time at all in comparison all the time spent downloading, processing, and displaying ads.
  2. The imperative approach is still available to extensions. The only thing that changes, is that extensions using the imperative approach can no longer tell Chrome to block a request, and therefore can still see what you are sending. It is possible that even further in the future the imperative approach will no longer be a thing at all, but this is not yet the time.
  3. The way Firefox does the imperative approach is actually designed better.

On worrying implications of the declarative blocking approach

This is what is worrying me the most about the new approach, in the words of the author of uBlock Origin:

The core issue is the lid on innovation, which is key for content blocker to stay reliable. If the DNR API had been designed in 2014 according to the requirements of the time, content blockers would be awfully equipped to deal properly with the current landscape. The DNR API as designed now not only set back content blockers, but condemn content blockers to stagnate innovation-wise.

This means that the ads will only evolve while adblocking extensions will no longer will be able to keep up.

On Chrome-like browsers

(in case you aren’t sure: if your browser is not Safari nor Firefox, it is most likely a Chrome reskin)

The change applies to Chromium (will reject installing such extensions) and Chrome extension store (will no longer provide such extensions). Microsoft Edge already announced that it will keep a similar timeline.

One silver lining is that the official Chrome timeline says that corporations have one more year to adapt to the change. This leads to the conclusion that there’s a possibility that Chrome reskins could potentially prolong the support for one more year by modifying the check and pretend that the individual users are also corporations. This possibility is mentioned, for example, on Vivaldi’s blog, although no promises are made.

Removing a feature from software is usually preceded with announcement of intent of removal, which is exactly what is happening here. Chrome reskins could potentially bring the feature back, but this introduces divergence from the official Chromium repository and therefore requires constant effort to maintain. We can therefore likely assume that Chrome reskins will eventually lose the blocking capability too.

On Firefox

For compatibility with other browsers, Firefox also supports Manifest V3, except the capability to block will keep being supported under the imperative approach. Which leads me to the obvious recommendation to switch to Firefox.

To address one of the replies

google already has firefox on its payroll, how do we know they won’t add a few hundred million to block adblock there too?

Google specifically pays Firefox for making sure Google happens to be the default search engine, nothing more. How do we know nothing more will happen? History of the project, combined with the fact Mozilla is a non-profit foundation, combined with the savvy userbase, leads this to be an extremely unlikely possibility.

I can’t switch, site X doesn’t work under Firefox!

We already experienced this before in the 00s when Internet Explorer had 95% of usage and sites never bothered to check that the site works in any other browser, or even took active effort to make a site not work in other browsers (in particular, Microsoft did this all the time to Opera, back when Opera was not a Chrome reskin).

It was terrible. Internet Explorer was stuck on version 6 for 5 years. It didn’t have tabs. It was slow. It was buggy. It had tons of security holes, to the point people kept joking that Internet Explorer lets other people explore your computer.

How did we break through? By making more people use Firefox to the point web developers actually had to check their site works there.

Also: browsers send a piece of info each time they access a website which identifies the browser. This info is spoofable with an extension. This in particular thwarts the most obvious attempts at blocking non-Chrome browsers.

Bottom line

Google is an advertisement company. If you do not like ads, avoiding products made by an advertisement company is a good idea.