Special report Seven months from now, assuming all goes as planned, Google Chrome will drop support for its legacy extension platform, known as Manifest v2 (Mv2). This is significant if you use a browser extension to, for instance, filter out certain kinds of content and safeguard your privacy.

Google's Chrome Web Store is supposed to stop accepting Mv2 extension submissions sometime this month. As of January 2023, Chrome will stop running extensions created using Mv2, with limited exceptions for enterprise versions of Chrome operating under corporate policy. And by June 2023, even enterprise versions of Chrome will prevent Mv2 extensions from running.

The anticipated result will be fewer extensions and less innovation, according to several extension developers.

[1]

Browser extensions such as Ghostery Privacy Ad Blocker, uBlock Origin, and Privacy Badger, along with scripting extensions including [2]TamperMonkey , which are each designed to block adverts and other content and/or protect one's privacy online, are expected to function less effectively, if they can even make the transition from Mv2 to the new approach: [3]Manifest v3 .

Manifest v3 caps the certain capabilities of extensions and cuts off innovation potential

"If you asked me if we can have a Manifest v3 version of Privacy Badger, my answer is yes, we can and we will," said Alexei Miagkov, senior staff technologist at the Electronic Frontier Foundation, in a phone interview with The Register . "But the problem is more insidious. It's that Manifest v3 caps the certain capabilities of extensions and cuts off innovation potential."

Google argues otherwise and maintains its platform renovation will meet developers' needs, including those making tools for content blocking and privacy. The internet titan, which declined to comment on the record, maintains that Mv3 aims to improve privacy by limiting extensions' access to sensitive data and that it has been working with extension developers to balance their needs with those of users.

[4]

[5]

Google points to past endorsements, such as [6]remarks provided by Sofia Lindberg, tech lead of ad amelioration biz [7]Eyeo , which makes Adblock Plus. "We've been very pleased with the close collaboration established between Google’s Chrome Extensions Team and our own engineering team to ensure that ad-blocking extensions will still be available after Manifest v3 takes effect."

A numbers game

The estimated number of browser extensions in the Chrome Web Store as of two years ago ranged between about [8]156,000 and [9]190,000 . Today, that figure is said to be [10]almost 114,000 . Comparing these numbers isn't straightforward – Google doesn't publish store data so third parties devise their own counting methods.

[11]About two dozen Chrome extensions have over 10 million users, but most (about 87 per cent) had fewer than 1,000 installs in 2019, according to Extension Monitor, a now-defunct service. Google's disinterest in Chrome Web Store metrics may have something to do with it not being a profit center like Apple's App Store or Google Play – which both Apple and Google celebrate for their revenue generation. When Google discontinued the Chrome Web Store payment API in September 2020, only about nine percent of the extensions were paid or implemented in-app purchasing.

According to [12]Chrome Stats , the most popular Chrome extensions block ads on Google and YouTube, making them something of a revenue sinkhole.

[13]

Google began work on Manifest v3, the successor to Mv2, in late 2018, ostensibly to make extensions more secure, performant, and private. The company's extension platform renovation was necessary – because [14]extension security problems were rampant – and immediately controversial. An ad company making security claims that, coincidentally, hinder user-deployed content and privacy defenses looks like self-interest.

And Mv3 remains the subject of ongoing debate as the extension platform capabilities and APIs continue to be hammered out. But it has been adopted, with some caveats, by other browser makers, including Apple and Mozilla. Makers of Chromium-based browsers inherit Mv3 and Microsoft has already endorsed the new spec.

Others building atop Chromium like Brave, Opera, and Vivaldi have indicated interest in continuing to support Mv2, though it's unclear whether that will be practical beyond June of next year. If Google removes the Mv2 code from Chromium, maintaining the code in a separate Chromium fork may prove to be too much trouble.

[15]

The most widely noted change in Mv3 – and there are many that have significant implications – is the removal of the blocking version of the [16]webRequest API, which is being replaced by an API called [17]declarativeNetRequest .

Google insists the change is not about hindering content blockers.

There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers

"There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers," said Simeon Vincent, Chrome developer advocate, in [18]a 2019 blog post. "This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers."

Requests, and more requests

The blocking version of the webRequest API allows an extension to see all the data in a network request before it gets sent – and possibly block or alter it – and to see all the data in a network response – and possibly block or alter it – before rendering it to a web page.

Given that passwords and account information could be intercepted this way, the webRequest API can be easily abused by bad extensions. According to Vincent, as of January 2018, 42 percent of malicious extensions were exploiting the webRequest API.

The declarativeNetRequest API works differently, applying rules – declared in advance or, in limited numbers, at runtime – that take action when they see a specific network request. The result is extension developers have an API that's less capable but more secure with respect to eavesdropping on network requests.

Asked to cite an Mv3 API that makes ad blocking and privacy extensions more effective, Google pointed to declarativeNetRequest as being more performant and more secure than webRequest .

Mozilla last year said the opposite in [19]a blog post discussing Mv3: "We will support blocking webRequest until there’s a better solution which covers all use cases we consider important, since DNR

declarativeNetRequest

as currently implemented by Chrome does not yet meet the needs of extension developers."

Raymond Hill, the creator of uBlock Origin, last December offered [20]a similarly negative assessment of declarativeNetRequest :

An example that the declarativeNetRequest ("DNR") API is an obstacle to innovation in content blockers.

In discussion with filter list maintainers, last year I implemented a new feature, the ability to use "entity" in domain= option.

[21]1

The DNR API does support domain= option, but it does not support "entity", which is the ability to use a wildcard in place of the effective TLD, to avoid to list all domains belonging to an entity.

[22]2

I can count over 420 filters currently in the default filterset which uses this feature, clearly a benefit to filter list maintainers. These filters would cease to exist in a DNR-based blocker.

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 [to] set back content blockers, but [to] condemn content blockers to stagnate innovation-wise.

Google's approach to performance and security in this context – neutering the webRequest API – isn't the only option. Ill-intentioned developers of native applications, web apps, and software libraries/ [23]SDKs can abuse people's trust equally well without the webRequest API – [24]using JavaScript to grab form data prior to submission, for example.

App security for other platforms generally involves code analysis to see what it does, rather than denying access to APIs. But Google made a decision to restrict APIs rather than strengthen Chrome Web Store code review and enforcement.

Ghost in the machine

In an interview with The Register , Jean-Paul Schmetz, CEO of [25]Ghostery , explained how his company's browser extensions have been using webRequest to disable Facebook tracking.

"When Facebook launched the Like button – it was an image basically of the Facebook logo," said Schmetz. "And part of that [network] request was harmless. It was just a page ID of the page where it was placed. And the other half of the request was a user ID which was absolutely not harmless because it essentially gave Facebook a ping that you were looking at a specific page, which can help them do a bunch of targeting stuff."

"And what we were doing is to keep the harmless part of the request, but remove or modify the harmful part of it," he said. "Which allowed the users to still have the Like button be visible and if you clicked on it, it would work as expected, except that Facebook would not be able to track everything that you read on the web. And that is definitely something that's going to go away with Manifest v3, the ability to modify the request as it leaves the browser."

Schmetz and other extension developers have observed that extensions used to be critical to browser adoption, but have become less important now that Google has what he describes as a monopoly.

One of the consequences of Chromium becoming the monopoly browser, and Firefox going away, is that extensions do not play the role that they used to play

"One of the consequences of Chromium becoming the monopoly browser, and Firefox going away, is that extensions do not play the role that they used to play," said Schmetz. "Before, you know, people would move from Chrome to Firefox if an extension was not available. And that stopped occurring.

"I think that extensions are basically seen by browsers – except bizarrely, for Safari at the moment – as sort of a half-necessary evil. Whereas before they were – I don't know if you remember those days – but basically, Chrome was struggling to implement extensions at one point and knew that if they didn't have extensions, they would never be able to compete against Firefox.

"So it was extensions that were really driving the creativity of the browser ecosystems. And unfortunately, with the monopolization of the browser infrastructure, this is becoming less so. And I think this is a big problem because extending the browser is the only way to make sure that a monopolistic browser is not stopping everything. It's like you can still customize it somehow, right?"

Schmetz said extensions used to be able to fundamentally alter the way browsers worked and now, due to Google's policies, they're only allowed to do one thing.

Wladimir Palant, who developed the Adblock Plus extension that became the basis for Eyeo, the acceptable ad business he co-founded, also cited the way in which extensions have gone from king-makers to supplicants.

"Historically, browser extensions have been a major factor behind Firefox adoption," said Palant. "I’m not saying that people primarily switched to Firefox because of extensions. But its extensibility made Firefox very attractive to power users and early adopters. And these are the people who tend to bring their family and friends along because they are playing IT support for all of them.

"Extensions come at a cost however. They threaten security and stability of a browser, and they are a huge maintenance burden. So we’ve seen Chrome become successful with an entirely different compromise: their idea of extensions was far less than Mozilla’s, with the extensions being very limited in what they could do. But it allowed them to ship a more stable product and innovate faster, eventually leading to Firefox adopting the same extension model."

Palant said now that extensibility is no longer the defining factor in browser adoption, Chrome is able to make changes with less risk of losing users.

" webRequest is an obvious choice to cut, it being a feature implemented fairly late because Chrome users kept demanding capable ad blockers," he said. "I doubt Chrome developers were ever happy with it, it being a notorious performance hog."

Palant said Mv3 entails a wide range of changes intended to improve security and fix bad decisions made during the early stages of Chrome development.

"The main issue here is breaking backwards compatibility abruptly," he said. "Many extensions won’t make the jump. But losing even half of their extensions is something Google can afford now. Users will no longer switch browsers because of extensions."

The EFF's Miagkov sees Google's prioritization of online advertising as the source of Chrome's problems.

Everything that happens in Chrome is at the very least colored by their advertising-driven priorities

"Chrome, the browser, belongs to an advertising company," he said. "And I think this is a major issue. Everything that happens in Chrome is at the very least colored by their advertising-driven priorities."

And it's not just Manifest v3 but also the various Privacy Sandbox initiatives and adjacent web specs that reflect this agenda. For example, Google has proposed a web standard called [26]WebBundles that rivals like Brave argue would help websites [27]avoid content blocking. The technology has been [28]debated for several years but the privacy concerns raised remain unanswered.

"Google does not want to imagine a different web," said Miagkov. "Google does not want to imagine a web where nonconsensual personalized tracking is forbidden, period, like you just can't do it. When you look at Manifest v3, in the context of everything else that's happening, then it becomes much more clear that it's not at all driven by what's important to extension developers and consequently, extension users. It's driven by corporate Google priorities."

That would be fine if Chrome were one option among many, said Miagkov, but Chrome has a monopoly on the desktop where extensions are most relevant. According to the US Justice Department's [29]2020 antitrust lawsuit [PDF] against Google, "In the United States, Google Chrome is the leading computer browser, with almost 60 percent market share," and "over 85 percent of all browser usage in the United States occurs on Google’s own Chrome browser or [another browser that has a revenue sharing agreement with Google]."

Acts and consequences

One consequence of that dominance is that if Chrome fails to fix a known avenue of privacy abuse, then a large number of users go unprotected. That's been the case with [30]CNAME cloaking , a way publishers can delegate control of a subdomain to a third-party firm to enable web visitor tracking. While other browsers like Brave, Firefox, and [31]Safari have implemented defenses, Chrome has [32]left the issue unaddressed for the past two years.

There was hope last June that the formation of a W3C WebExtensions Community Group (WECG), in which browser makers and other interested parties could discuss the future of extensions might change the dynamic of Google declaring technical changes prior to community engagement. But according to Miagkov, that hasn't happened.

"I think the W3C group holds great potential," he said. "It's already helping extension developers get heard a little bit, because there is a biweekly meeting where anybody can come and talk about what concerns they have.

"What I've seen, however – and I've attended every meeting for the last many months – I have not seen a single sign that Google changed anything, including its approach to input – from the group or from anybody else."

Google insists it has incorporated changes into Chrome as a result of developer feedback from the WECG and said WECG discussions have influenced the design of Chrome's Offscreen Documents proposals and have aided cross-vendor discussions of browser extensions. According to Google, this chatter has covered topics including allowing extensions to:

Declare [33]optional host permissions with the optional_host_permissions field in manifest.json

Declare a custom content security policy that allows the extension to use WebAssembly

Specify whether content scripts should run in the extension's isolated world or in the page's world

Open their own popups using action.openPopup() (currently in development)

Google has also made other changes in response to developer feedback, such as raising the number of static rules that can be applied using declarativeNetRequest to a minimum of 30,000, the introduction of session rules, and regex rules, among others. Additionally, Googlers have made changes to other APIs, such as scripting.executeScript , and introduced storage.session for service workers. And The Register understands Google engineers intended to continue doing so.

Schmetz argues that Google's extension platform changes make browsers more a channel for publishers than a tool that serves internet users.

"The browser is technically called the user agent," Schmetz said. "And by [making extensions less capable], I think you make it less the user agent and you make it more like a page agent or publisher agent. Or browser manufacturer agent."

Schmetz sees Google's security claims as a cover for what they're doing.

"It's clear that a powerful platform like extensions has created some bad actors who have used extensions to do bad things. So Google can always say, 'Well, we're making our user safer.' But, you know, behind all that, it also means that the browser is not a user agent anymore."

[34]Windows malware uses PowerShell to inject malicious Chrome extension

[35]The Return of Gopher: Pre-web hypertext service is still around

[36]Safari is crippling the mobile market, and we never even noticed

[37]Mozilla opens testing for Manifest v3 extensions in Firefox

[38]Microsoft backtracks on lack of easy Windows browser choice

[39]Firefox introduces cookie clearing, clutter-free printing, Microsoft single sign-on... so where are all the users?

Schmetz expects Ghostery will manage to adapt its extensions but worries about what comes next.

"I think the only thing that we are not able to do in the future is this modification of requests," he said. "I think making the tracking visible is going to continue to be possible. Again, we don't know exactly what form Manifest v3 will have in the end, but it looks okay at this point for us. But we are worried about Manifest v4."

Ghostery has hedged its bets by having its own browser, based on Firefox, where it can continue to offer its privacy tools if they become untenable within Chrome. But judging by [40]recent browser trends , Chrome continues to maintain its market dominance.

Schmetz believes it's really important that people continue to have access to effective anti-tracking tools, particularly for blocking fingerprinting scripts.

"We definitely see a lot of fingerprinting going on," he said, noting that the ad industry has already moved beyond cookie-based tracking.

"Basically that these scripts are trying to create numbers that are unique to you and are being transferred in the requests. They are not being stored on your machine but are being predictably generated every time you visit a website. … It's very important to have tools that can block that because if you don't, you will be tracked right. There's no way to avoid it." ®

Get our [41]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YqBzQyhn5T3m254-dxiBBgAAAAc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://github.com/Tampermonkey/tampermonkey/issues/644#issuecomment-742680842

[3] https://developer.chrome.com/docs/extensions/mv3/intro/

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YqBzQyhn5T3m254-dxiBBgAAAAc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YqBzQyhn5T3m254-dxiBBgAAAAc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[6] https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html

[7] https://eyeo.com/

[8] https://techacake.com/chrome-extensions-statistics

[9] https://www.theregister.com/2020/09/23/google_sunsets_chrome_web_store/

[10] https://chrome-stats.com/authors

[11] https://chrome-stats.com/authors/user-counts/user-10000000

[12] https://chrome-stats.com/top

[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YqBzQyhn5T3m254-dxiBBgAAAAc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[14] https://www.theregister.com/2020/06/18/chrome_browser_extensions_new_rootkit/

[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YqBzQyhn5T3m254-dxiBBgAAAAc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[16] https://developer.chrome.com/docs/extensions/reference/webRequest/

[17] https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/

[18] https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html

[19] https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/

[20] https://github.com/uBlockOrigin/uBlock-issues/issues/338

[21] https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#domain

[22] https://github.com/uBlockOrigin/uBlock-issues/issues/1008#issuecomment-624194528

[23] https://www.theregister.com/2021/02/03/location_tracking_report_xmode_sdk/

[24] https://www.theregister.com/2022/05/16/ad_companies_data/

[25] https://www.ghostery.com/

[26] https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html

[27] https://brave.com/web-standards-at-brave/3-web-bundles/

[28] https://github.com/WICG/webpackage/issues/551

[29] https://www.justice.gov/opa/press-release/file/1328941/download

[30] https://www.theregister.com/2021/02/24/dns_cname_tracking/

[31] https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/

[32] https://bugs.chromium.org/p/chromium/issues/detail?id=1063095

[33] https://bugs.chromium.org/p/chromium/issues/detail?id=1265064

[34] https://www.theregister.com/2022/05/27/chromeloader-malware-powershell/

[35] https://www.theregister.com/2022/05/23/the_return_of_the_gopher/

[36] https://www.theregister.com/2022/05/23/opinion_column/

[37] https://www.theregister.com/2022/05/20/mozilla_opens_testing_for_manifest/

[38] https://www.theregister.com/2022/03/29/microsoft_browser_choice/

[39] https://www.theregister.com/2021/08/11/firefox_91/

[40] https://gs.statcounter.com/

[41] https://whitepapers.theregister.com/