This article is more than 1 year old

Ad blockers struggle under Chrome's new rules

As deadline for mandatory code rewrite approaches, Manifest v3 still looks like a step backward

Analysis Next year, Chrome browser extensions – such as ad blockers and other privacy tools – will stop working if they are reliant on an API called Manifest v2 (MV2).

So far, when these extensions are rewritten to work with Chrome's new Manifest v3 (MV3) API, you tend to end up with hobbled software that doesn't work as well.

The cut-off date for MV2 is January 2023 though it can be used to June via an enterprise policy.

Google began working on a revised API, namely MV3, for Chromium browser extensions in 2018 to deal with what it characterized as the security, privacy, and performance consequences of its MV2 extension architecture. In Google's mind, ad blockers and similar extensions, under the MV2 regime, have too much control over and access to the pages you've got open in the browser. If one of these add-ons turns rogue, it can harvest all kinds of sensitive data about you from these pages as you visit them.

Its successor spec, MV3, got rid of powerful but potentially exploitable capabilities, such as the ability to intercept and rewrite requests for pages – a useful weapon for extensions that seek to preserve your privacy and security by blocking requests to undesirable stuff, such as trackers, malware, and ads.

Developers maintaining or creating privacy and content blocking extensions found they would have to rethink how their code might work under the new rules and API, if it would at all. Since MV3 began to take shape – it remains a moving target – privacy-focused developers and advocacy groups have warned that Google's ostensible effort to promote privacy (by limiting data access and enforcing permissions) will end up harming extensions that promote privacy.

Now, two recent experiments by makers of popular content blocking extensions have confirmed that MV3 represents a regression rather than an advance in terms of what browser extensions can do.

Raymond Hill, the creator of uBlock Origin, among the most well-regarded privacy extensions available, on Tuesday published source code for an experimental version that relies on MV3. In what may be taken as a sign of his expectations, he calls the variant "uBO Minus."

Silhouette of someone holding a padlock in front of the Google Chrome logo

Makers of ad blockers and browser privacy extensions fear the end is near

FULL STORY

uBO Minus relies on the declarativeNetRequest API in MV3 to block content. This function replaces the webRequest API from MV2, which allows a JavaScript event handler to modify network requests and has been the primary mechanism for intercepting unwanted network content.

As Hill explains in his commit text, his extension uses declarativeNetRequest to conform with Google's stated goal for MV3 to not require the broad "read/modify data" permission. This approach avoids presenting the extension user with an installation warning that the installed code can "Read and change all your data on all websites" – which may sound scary but is generally what you want when using an add-on that cleans up all the webpages you visit.

But this "permission-less" approach means the extension cannot carry out operations supported by uBlock Origin, such as custom JavaScript injection or filtering of redirects, CSP (content security policy) directives, URL parameters, and cosmetic page elements.

Hill's conclusion is that adhering to the ad giant's vision makes for a subpar content-blocking extension. He wrote, "At this point I consider being permission-less the limiting factor: if broad 'read/modify data' permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad 'read/modify data' permission."

Overprotective parent illustration, a child under glass

Google: We're not killing ad blockers. Translation: We made them too powerful, we'll cram this genie back in its bottle

CONTEXT

That advice won't be viable as of January, when Manifest v2-based extensions will stop working in Chrome. That's likely to be the case for Microsoft Edge, which has endorsed MV3. Apple Safari introduced support for MV3 in version 15.4 and while Apple has not indicated whether it intends to drop support for MV2, it removed the blocking WebRequest API years ago. Outliers like Brave and Mozilla have said they plan to continue support for MV2, though some resources will be required to do so. Brave, for example, will need to launch its own extension store because the Chrome Web Store won't be an option.

Dmitriy Seregin from AdGuard offered a slightly more optimistic take in his description of his firm's effort to create AdGuard AdBlocker MV3 Experimental.

While MV3 forced extension makers to rely on declarative rules (set in advance) rather than dynamic ones (generated on the fly), Seregin nonetheless suggests AdGuard will manage.

"Although the experimental extension is not as effective as its predecessor, most users won't feel the difference," said Seregin in a blog post just over a week ago. "The only thing you might notice is ad flickering due to the lag in the application of cosmetic rules."

The future of content blocking in web browsers looks a lot like the way it was described by Alexei Miagkov and Bennet Cyphers from the EFF last December. They wrote, "Under Manifest V2, extensions are treated like first-class applications with their own persistent execution environment. But under V3, they are treated like accessories, given limited privileges and only allowed to execute reactively." ®

More about

TIP US OFF

Send us news


Other stories you might like