What's Really Going On With Chrome's June Crackdown On Extensions – And Why Your Ad Blocker May Or May Not Work

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

And even then, if those 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 they did previously.

Today those Chrome extensions by and large adhere to an API specification known as Manifest V2: that's what they use to, for example, inspect pages for stuff to filter out. Googlers feel that API puts too much power in the hands of extension developers: someone could make an add-on that offers to do things like block annoying ads on a page, and then later use those powers to steal or manipulate sensitive data on your internet profiles.

The Chocolate Factory's answer to this was to develop Manifest V3, which has been supported by Chrome for a while now: it's an alterative way for extensions to drill into pages and filter out bad content, for instance. Google says V3 is safer - giving users more protection from wayward extensions - but some developers argue the switch from V2 to V3 cripples their extensions and makes them less effective. That would mean less effective ad blocking.

It was clear that at some point Google – which makes billions from web adverts – would end support for Manifest V2 in Chrome and require extensions use V3. Add-ons not compatible with that latest version would thus eventually fail. Google paused this shift from V2 to V3 back in December 2022 because its previous transition timeline proved too ambitious. There were various issues, including a reluctance from developers to hobble their content-blocking extensions by moving to Manifest V3's API.

The ad titan then missed its March 2023 deadline to provide further guidance about the conversion process. Thanks to work on various extension APIs since then, 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) as early as June 2024, in Chrome 127 and later," said David Li, product manager at Google, in a statement on Thursday. "Users impacted by the rollout will see Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store."

That 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 wildly varying degrees. The name refers to the numeric value for the manifest key in the manifest.json file, which is where browser extensions declare their required permissions and capabilities. More broadly, it refers to the set of functional options available to browser extensions.

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

Manifest V3 no longer supports the blocking version of chrome.webRequest, ostensibly as we said above for the sake of performance and security (enterprise and education installations excepted). Instead V3 offers an API called chrome.declarativeNetRequest that performs a similar function but asynchronously (synchronous operations block other tasks until they're done) and by most accounts less effectively.

For developers, the Manifest V3 transition means translating 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 seems, Google's rationale for creating Manifest V3 was sound – Manifest V2 extensions were quite powerful and could be easily abused. But the consequence of the platform rewrite is that certain capabilities will be lost or diminished, notably content blocking. At least one widely used extension, uBlock Origin, is expected not to be ported, though its author has created uBlock Origin Lite, a less capable but nonetheless functional ad blocker for Manifest V3.

Google's Chrome team has insisted it isn't out to kill content-blocking extensions, but its conciliatory messaging has been muddied by YouTube's deployment of scripts to detect ad-filtering extensions and warn people that such tools are against its terms of service. And the mega-corp's financial risk boilerplate makes clear that the ad giant wants investors to know that content blocking poses a revenue threat.

Citing work done on various Manifest V3 capabilities, such as support for Offscreen Documents, better management options for service workers, and a new User Scripts API, Li signaled the adoption and/or acceptance of Manifest V3 has increased significantly.

"Specifically, we are encouraged by our ongoing dialogue with the developers of content blocking extensions, who initially felt Manifest V3 could impact their ability to provide users with the features they’ve come to expect," he said.

Those expectations appear to be lower than Google would have people believe. Li's post cites an endorsement from Andrey Meshkov, CTO of AdGuard, which makes content blocking tools including a browser extension.

The chosen quote goes:

The Register asked Meshkov whether that passage accurately reflects his assessment of Manifest V3, and his answer was more circumspect.

"I guess it's natural that Google chose to use an optimistic quote in their public communication," he told The Register. "What's true about that is that I am indeed much more optimistic about MV3 than I was two years ago. However, there are still shortcomings and limitations."

Meshkov pointed to a piece he wrote on the topic on November 3. He credits Google for actually engaging with the web community through the formation of the W3C WebExtensions Community Group.

'Far from terrible'

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

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

Meshkov also said that certain claims, specifically that custom filters – lists of undesirable domains and servers to block – and on-demand updates to blocklists will not be supported, aren't accurate.

We're confident our ad blocking extension will be almost as good in terms of content blocking

"Regarding custom filters, this is not entirely correct. It will still be possible to add them since the dynamic rules limit was raised six times in the end," he opined.

"But the limit is still rather low compared to the static rules limit. To put it into perspective, you will be able to add a couple of mid-size custom filter lists, but large lists like AdGuard Base filter or EasyList have to be bundled with the extensions."

With regard to on-demand updates, Meshkov said there are two approaches that can be used, the first being differential updates, a Chrome function that allows individual rules in static rulesets to be disabled and makes differential updates possible.

"The second one is not on-demand, but it may be even more interesting to us," he said. "At the latest Ad Filtering Dev Summit, the Chrome team said that they're going to implement 'fast track' automatic reviews for extensions when the only changes are static rulesets (bundled with the extension).

"If it works as expected, you'll be able to push an updated version literally every hour and use Chrome Web Store infrastructure to deliver it, which is an important advantage as serving petabytes of filter lists is rather expensive."

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

Presently, there are still issues

"The requirement to base extensions on service workers adds complexity and headaches to developers, but because of various policy changes and workarounds, is no longer the issue it was two years ago," Miagkov told The Register in an email. "Google put in a lot of effort to make service workers kind of work for extensions. I think the end result is it's now harder to make an extension, but it's no longer a deal breaker.

"However, blocking webRequest is still (mostly, outside of a specific proxy authentication use case) gone and DNR is still not an acceptable replacement. There are still outstanding functionality gaps. 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 a post on Mastodon about MV3's current inability to remove tracking parameters from links.

"Most importantly, declarativeNetRequest is not an adequate replacement for webRequest," he said.

"We now all depend on Google to keep evolving the API to keep up with advertisers and trackers. Google is itself an advertiser," said Miagkov.

"Chrome extensions already had an essentially lost decade, where nothing much happened until the Manifest V3 proposal came to be. It's not a good idea for Google to hold the keys to anti-tracking tech. … Google cannot be trusted to be the gatekeeper." ®