What’s really going on with Chrome’s June crackdown on extensions – and why your ad blocker may or may not be working?

Special report Web ad blockers and other Chrome extensions will stop working by June 2024 unless they have been revamped to keep up with Google’s changes to its ubiquitous browser.

And even then, if these content filtering extensions have been updated to meet Google’s latest specifications and requirements, the add-ons may not work as well or as comprehensively as before.

Today, these Chrome extensions generally adhere to an API specification known as Manifest V2: that’s what they use, for example, to inspect pages for elements to filter. Googlers say the API gives too much power to extension developers: Someone could create an add-on offering to do things like block annoying ads on a page, then later use those powers to steal or manipulate ads. sensitive data on your Internet. profiles.

Chocolate Factory’s response was to develop Manifest V3, which has been supported by Chrome for some time now: it is an alternative way for extensions to crawl pages and filter out bad content, e.g. example. Google says V3 is more secure – giving users better protection against wayward extensions – but some developers say the move from V2 to V3 cripples their extensions and makes them less effective. This would mean less effective ad blocking.

It was clear that at some point, Google – which makes billions from web ads – would end support for Manifest V2 in Chrome and require extensions to use V3. Add-ons not compatible with this latest version would therefore end up failing. Google suspended this transition from V2 to V3 in December 2022, because its previous transition schedule proved too ambitious. There were various issues, including developers’ reluctance to hamper their content blocking extensions by moving to the Manifest V3 API.

The advertising titan then missed its March 2023 deadline to provide additional guidance on the conversion process. Thanks to work since then on various extension APIs, the Manifest V3 transition is once again underway.

“We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary and Beta) starting in June 2024, in Chrome 127 and later,” said David Li, product manager at Google, in a statement Thursday. . “Users affected by the rollout will have Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store.”

This means the end of your Manifest V2 based ad blocker; a Manifest V3 version, if available, will work.

Meet the new boss

Manifest V3 is supported by other browsers – Edge, Firefox and Safari – to widely varying degrees. The name refers to the numeric value of the manifest key in the manifest.json file, where browser extensions declare their required permissions and capabilities. More broadly, it refers to all the functional options available for browser extensions.

For example, the most significant change between Manifest V2 and Manifest V3 is that the old specification supports the blocking version of the chrome.webRequest API. Developers of content blocking extensions could use it to intercept, block or modify data (e.g. advertisements) requested by the browser from websites.

Manifest V3 no longer supports the blocking version of chrome.webRequest, apparently as we said above for the sake of performance and security (except corporate and educational installations). Instead, V3 offers an API called chrome.declarativeNetRequest that performs a similar function but asynchronously (synchronous operations block other tasks until they are completed) and by most accounts less efficient.

For developers, the Manifest V3 transition means translating the extension code into a new grammar that, in some cases, lacks words that mean the same thing or have subtle differences.

As unpopular as it may seem, Google’s reason for creating Manifest V3 was sound: Manifest V2 extensions were quite powerful and could easily be misused. But the consequence of rewriting the platform is that certain capabilities will be lost or reduced, notably content blocking. At least one widely used extension, uBlock Origin, is not expected to be ported, although its author created uBlock Origin Lite, a less capable but still functional ad blocker for Manifest V3.

Google’s Chrome team insisted it wasn’t aiming to remove content-blocking extensions, but its conciliatory message was muddled by YouTube’s deployment of scripts to detect ad-filtering extensions and warn users that such tools violate its terms of service. And the mega-company’s standard financial risk makes it clear that the ad giant wants investors to know that blocking content poses a threat to revenue.

Citing work done on various Manifest V3 features, such as support for off-screen documents, better management options for service technicians, and a new user scripting API, Li reported that adoption and/or acceptance of Manifest V3 had increased significantly.

“In particular, we are encouraged by our continued dialogue with content blocking extension developers, who initially believed that Manifest V3 could impact their ability to provide users with the features they expect,” a- he declared.

These expectations seem lower than Google would have you believe. Li’s post cites the endorsement of Andrey Meshkov, CTO of AdGuard, which makes content blocking tools including a browser extension.

The chosen quote is as follows:

The register Meshkov was asked if this passage accurately reflected his assessment of Manifest V3, and his response was more circumspect.

“I guess it’s natural that Google chose to use an optimistic quote in its public communication,” he said. The register. “What is true is that I am indeed much more optimistic about MV3 than I was two years ago. However, there are still gaps and limitations.”

Meshkov pointed to an article he wrote on the subject on November 3. He thanks Google for truly engaging with the web community through the formation of the W3C WebExtensions community group.

“Far from being terrible”

His overall assessment of Manifest V3 is that “things are far from terrible.”

“Take for example our MV2 ad blocking extension,” he commented. “When it migrates to MV3, we’re confident it will perform almost as well in terms of content blocking. There will be some minor missing parts, but I’m pretty sure most people won’t feel the difference.”

Meshkov also said that some claims, including that custom filters (lists of unwanted domains and servers to block) and on-demand updates to blocklists would not be supported, are not accurate.

We are confident that our ad blocking extension will be almost as good at blocking content.

“Regarding custom filters, this is not entirely correct. It will still be possible to add more since the limit of dynamic rules has finally been increased six times,” he estimated.

“But the limit is still quite low compared to the limit of static rules. To put things in perspective, you will be able to add a few medium-sized custom filter lists, but large lists like AdGuard Base or EasyList filter should be grouped . with extensions.”

When it comes to on-demand updates, Meshkov said there are two approaches that can be used, the first being differential updates, a Chrome feature that allows individual rules to be disabled in static rule sets and makes differential updates possible.

“The second one is not in demand, but it could be even more interesting for us,” he said. “At the last Ad Filtering Dev Summit, the Chrome team announced that they would be implementing “expedited” automatic reviews for extensions when the only changes are static rule sets (bundled with the extension).

“If it works as expected, you’ll be able to release an updated version literally every hour and use the Chrome Web Store infrastructure to deliver it, which is a significant benefit since delivering petabytes of filter lists is rather expensive.”

Alexei Miagkov, senior technologist at the Electronic Frontier Foundation, which manages the advocacy group’s Privacy Badger extension, also gave some credit to Google for fixing bugs, adding missing features, improving the declarativeNetRequest API and relaxing its initially unreasonable lifetime requirements for service workers (which keep processes running in the background for a limited period of time).

Currently there are still problems

“The requirement to base extensions on Service Workers adds complexity and headaches for developers, but due to various policy changes and workarounds, this is no longer the problem it used to be two years,” Miagkov said. The register in an email. “Google has put a lot of effort into getting service workers to work on extensions. I think the end result is that it’s now harder to create an extension, but it’s no longer a deal breaker.

“However, webRequest blocking is still (for the most part, outside of a specific proxy authentication use case) gone and DNR is still not an acceptable replacement. There are still functionality gaps in pending. This particular issue means that MV3 extensions are not able to properly fix redirects at the network layer at this time.”

Miagkov also pointed to an article on Mastodon regarding MV3’s current inability to remove link tracking settings.

“More importantly, declarativeNetRequest is not an adequate replacement for webRequest,” he said.

“We now all depend on Google to continue to evolve the API to keep pace with advertisers and trackers. Google is an advertiser itself,” Miagkov said.

“Chrome extensions have already had an essentially lost decade, where nothing happened until the Manifest V3 proposal. It’s not a good idea for Google to hold the keys to anti-tracking technology. … We can’t trust Google to be the gatekeeper.” ®