Chrome / Chromium "Manifest V3" and Brave

Feedback Browser Feedback
,
1

Chrome (and hence, Chromium-based browsers … presumably including Brave) will implement “Manifest V3” starting in January 2023. Here are some details from a recent Google blog post.

This isn’t new news. An Electronic Frontier Foundation post from December 2021 doesn’t pull its punches or candy-coat its critical opinion of “Manifest V3”. Here’s another more recent detailed discussion from Ars Technica I’ve read.

I’m unclear how — if at all — “Manifest V3” will affect Brave users. Both the EFF post and the discussion in Ars suggest use of ad-blocking extensions will be impacted, but I’ve read no discussion of whether “Manifest V3” will affect how stuff like Brave’s privacy-protecting “shields” will be affected.

Comments?

2

It does not uses the extension API, it will not be affected.

3 Likes
4

I made a post that brave should make a official blog post on the topic. They have made few tweets on the topic.

Brave shields (adblocking, tracker blocking, anti-fingerprinting) will not be affected by MV3 whatsoever.

Also, google has shifted the timeline from Jan 2023 to Jun 2023 for stable release and till Jan 2024 for enterprise release. Brave will support the enterprise policy meaning MV2 will be available on brave till Jan 2024.

2 Likes
5

Looks like various developers already started updating their browser extension to Manifest V3

6

True, but v3 extenstions are also limited in functionality currently

7

I received a mail yesterday from SIMKL, they had to completely rewrite their Browser Extension to Manifest V3

Here: https://simkl.com/apps/chrome/enhancer/updated/

I think this might, indirectly kill all those outdated apps, which never received any update for ages.

8

Bumping this with a link to a 5 Aug 2024 discussion of Manifest V3.

The Ars article makes no mention of Brave (though some comments do). Some links within the Ars article lead to additional reporting that Brave (and some other Chromium-based browsers) will continue - for now - to support Manifest V2, hence, (one can hope) some extensions not compliant with Manifest V3.

Here’s the link to the Brave Settings page for currently-supported Manifest V2 extensions:

brave://settings/extensions/v2

1 Like
9

Google is removing Manifest v2 (MV2) code from Chromium in June 2025. That means all MV2 extensions will fail thereafter. Users of Chromium variants will have to remove any MV2 extensions, or switch to an equivalent or substitute MV3 version.

Mozilla says they will indefinitely support both MV2 and MV3 in Firefox. Mozilla isn’t a Chromium variant.

The shields integral within Brave are not implemented as an extension, so they not vulnerable to changes in Chromium that Google has made, and any more changes Google makes in the future (to further prevent adblockers from crippling their revenue sources for tracking, logistics, and advertising). However, MV2 extensions in Brave will cease to function once Brave updates to a version of Chromium where Google has removed the MV2 code.

MV2 extensions already installed in Chrome will continue to function – until July 2025 when Google purges MV2 extensions from their store, and also removes MV2 code in a new version of Chromium. When Chromium variants update to that new version of Chromium, they lose MV2 support. Won’t matter if you used policies or workarounds to keep MV2 extensions working, because the MV2 code inside Chromium will be gone.

To keep MV2 extensions working in Brave after Google removes MV2 code in Chromium means Brave would have to try to get the old MV2 code reinserted into Brave, and maintain it. Since MV2 extensions will get purged from the Chrome store, Brave would have to add the MV2 extensions to their own Brave store (not likely they will create one).

For example, for now if already installed you use the full uBlock Origin extension which uses MV2. Some users want to overlap protections from both Brave Shields and uBlock Origin (uBO). Later, when MV2 code is removed from a later version of Chromium, you can no longer can use the full uBO extension despite it is already installed. You will have to switch to the cripplied uBO Lite version (an MV3 extension).

Chrome 139 is the deadline. No more MV2 support after Chrome 138. Chrome 139 expected release date is Mon, Jun 23, 2025. Right now I’m using Brave 1.77.0 with Chrome 135.0.7049.100. No point in bothering with uBO MV2 to use it for only 2 months, or whenever Brave updates to Chrome 139.

10

@VanguardLH as you said all that, you might want to read through https://brave.com/blog/brave-shields-manifest-v3/

1 Like
11

"Will MV2 extensions still work in Brave?
Yes, for now. "

But not after Google removes the MV2 support code in Chromium, and thereafter all Chromium variants can no longer support MV2 extensions.

As already noted, Brave Shields is not an extension, so it unaffected by Google’s changes to manifests and what is supported. Yes, Brave Shields is unaffected by loss of MV2. But many users still add extensions to web browsers. And MV2 extensions that were already installed continue to work – until Chromium no longer has the code to support MV2 extensions.

I noted the removal of MV2 code to note that even Brave will lose support for MV2 extensions. The guillotine is coming down on MV2 in a couple months (June 2025).

I applaud Brave for developing integral code for Shields to avoid Google’s scheme to salvage their tracking, analytics, and ad revenues. Users still like extensions, and in June they’ll be forced to the much crippled MV3 versions.

Didn’t Brave Shields come from Raymond Hill for his uBlock Origin extension?

12

While Brave has no extension store, we have a robust process for customizing (or “patching”) atop the open-source Chromium engine. This will allow us to offer limited MV2 support even after it’s fully removed from the upstream Chromium codebase.

As of now, the MV2 extensions we plan to explicitly support are AdGuard AdBlocker, NoScript, uBlock Origin, and uMatrix. This feature will be best-effort: we might have to modify support based on either Google’s plans or what extension authors ultimately decide to do. If extensions become stale or obsolete, we may remove support for them rather than offer our users an out-of-date (potentially even unsafe) experience.

The point:

You’re sitting here saying it’s impossible and it’s going away in June. But Brave hasn’t said that yet. You’re just saying what Chrome/Chromium is planning. Brave is going to work with extension developers like uBlock Origin to make it work for as long as possible.

But you saying Brave is going to automatically lose support is incorrect. That’s where I was telling you to read and was kind of correcting what you shared.

13

It will indeed be interesting to see how well MV2 is supported in Brave going forward from when Google removes it in Chrome. Between Firefox and Brave decided Google’s decision was not in the best interest of the user, and if MV2 survives far past Google’s cutoff, perhaps Google may reconsider.

Plus after a recent court judgment against Google whereafter Google mentioned they may decouple from Chrome then whomever takes over Chrome may not be so predicated against ad blockers. Chromium started and still is a Google project, and Google is Chrome’s major developer, but if the decoupling happens then things could really shake up with Chrome, like reverting to MV2, or even supporting both MV2 and MV3.

Although Brave Shields are very good, I feel uBlock Origin (MV2 version) still has a lot to add. I use uBO in Firefox. I’m stuck with uBO Lite in Edge which is a Chromium variant.

While Brave hasn’t yet made clear what it will do after the June 2025 cutoff of MV2, many users would like to know their game plan before then, so they can plan on which web browser to use.

14

@VanguardLH in a November 2023 blog post Google said they had increased the number of dynamic rules 6-fold after discussions with ad-blocker developers.
https://developer.chrome.com/blog/improvements-to-content-filtering-in-manifest-v3

If they wanted to stop people blocking adverts they would either ban ad blockers from the store, like they did with youtube video downloaders, or not implement any content-filtering APIs. The MV3 change is not designed to ban ad blockers, it implements a model whereby content-filtering extensions do not need broad access to your data. This makes them safer and more efficient.

15

The blog from Google is their defensive posture defending their choice, not comparing their choice to how ad/content blockers work and how effective and speedy are MV2 extensions.

All of Google’s claims have been debunked. They claimed MV3 would be faster. Wrong in the benchmarks. They claimed MV3 would have a smaller footprint. Ad/content blockers have long had efficient and compact storage in memory. Rather than implement a permissions scheme to allow users to decide to what resources an extension is granted access by the user, instead Google decides to make blanket decisions in their interest, not the user’s.

I have used both uBlock Origin (uBO) and uBO Lite (uBOL), and found uBOL is a very crippled version of uBO hence uBOL is not as effective as uBO. Raymond Hill, author of uBO explained that he did not use any workarounds for loss of MV2, especially since MV2 code is getting chopped out of Chrome, but made his Lite version wholly MV3 compliant. The result is Brave Shields (which are not an extension but integral to Brave, so are not subject to Google’s MV3 limitations) is closer in effectiveness to uBO under MV2. uBO Lite is not as effective as uBO, especially with the loss of Expert Mode to see just what got blocked by domain, and letting the user override the blocks on a per-domain basis if they want to allow some untoward content to make a web page usable.

MV3 limits how many rules an extension can load into tables in memory. That limits how many rules are available for filtering untoward content. 30,000 static rules per extension, 330,000 aggregate rule count across all extensions.

Google Chrome’s uBlock Origin phaseout has begun
“uBlock Origin Lite has more limited filtering capabilities than uBlock Origin, as the Manifest V3 spec puts restrictions on the Declarative Net Request API used by ad-blocking extensions.”
You WILL be forced to uBOL when MV2 support disappears, and are forced to MV3.

At first, Raymond Hill gave up on MV3 saying he would not produce an MV3 version of uBO. Happily he relented, and did produce an MV3 “Lite” version. Better than nothing under MV3. Not all ad/content blocker authors have been so proactive.

Browser Guard reached rule limitations (MalwareBytes)

Since the total rule-count limit in MV3 is per-extension based, I recall reading how some adblockers would slice into multiple extensions trying to separate their service workers to get around the MV3 limitation, but are still limited to the 330,000 aggregate rule count across all extensions. The ad/content blockers still have a ceiling to stay under. Remember that these tables are in memory (which are compacted), so there is no performance loss to having more rules. There are more rules to look through, but database lookups are binary, not linear.

In uBO in Firefox, and subscribed to all supplied blocklists (and not added more than supplied at install-time), I have:

340,000 network filters + 247,358 cosmetic filters

Obviously that far exceeds the MV3 rule limit per extension. In uBOL which I must use in Edge which is a Chromium variant, I have:

20,554 rules CONVERTED from 356,355 network filters

The static-to-DNR rule conversion is needed to stay under the 30K static rules per-extension limit of MV3. Many static rules cannot be converted to DNR (declarative network request) rules, so those get discarded. See chrome.declarativeNetRequest documentation.

Notice there are NO cosmetic filters in uBOL. MV3 doesn’t allow them, because MV3 extensions are not allow to interrogate and modify web doc content before rendered. So, you cannot define a cosmetic filter to, say, get rid of those “Best viewed with Chrome” popup ads by Google when using a non-Chrome web browser at Google sites trying to nuisance users into switching to Chrome. There is a web site that I visit that started adding Wikipedia inserts as a top banner on their web pages, as though I’m too stupid to understand some terminology or technology, so I defined a cosmetic filter in uBO to eliminate that garbage content at that web site. Can’t do that in uBOL, or any other MV3 compliant ad/content blocker.

Another limitation of MV3: Ad/content blockers cannot update their blocklists. That means you don’t get the latest version of blocklists, and that is important to remove filters for sites that are no longer presenting untoward content, but also to add more filters for newly found sites with untoward content.

AdGuard Browser Extension for Chrome MV3
“No auto and manual filter updates. The options Auto-update filters and Check filters update are no longer available in the Filters tab. Since some of the rules are now applied in DNR form, we can’t update filters on request, only through the full process of updating the extension along with the review in the stores.”

You don’t get updated blocklists until the extension gets updated. To keep up-to-date on the latest versions of blocklists the MV3 extensions have to get updated as often, and many blocklists are updated every 1 to 6 days.

Every MV2 ad/content blocker has more than just subscribing to blocklists. They also have their own feature set in addition to rules, like:

  • Disabling CSP (Content Security Policy) reporting, a means to track your visits via fingerprinting. See Content-Security-Policy-Report-Only.
  • Disable pre-fetching of hyperlinked content. See Disable pre-fetching. However, while effective in Firefox, disabling pre-fetch in Chromium is flaky or impossible – because “Chromium allows web pages to override that user setting”.
  • Uncloak canonical names. Another Firefox-only feature since Chromium doesn’t support it. A Chromium issue, not an MV3 issue. Brave’s integral Shields do have CNAME exposure; see Fighting CNAME trickery.
  • Disable hyperlink auditing
  • Cloud storage support. Sync extension settings across multiple instances of extension in different web browser or across OS platforms. This enhances the Sync function in the web browser, not add yet another cloud service.
  • Cosmetic filters. Gone in MV3.
  • And other additional features available in MV2 versions of other ad/content blockers that are not doable under MV3.

Forcing MV3 ad/content blocker extensions to use service workers means Google can undo the blocks within Chrome. If Google should decide, they can undo any blocks on their ad tags service, analytics service, and any other Google services they want to protect for their revenue streams. The web browser gets control over content, and can override extensions and their service workers.

16

They were not being defensive, they were being open, taking advice form ad block extension developers. Their MV3 implementation has always allowed content filtering, and anyone making a limited-functionality ad blocker extension would surely use their limited options to block the most ads, which would mean blocking Google as a priority. Google has not done anything in MV3 to force people to view their adverts.

Filters do not translate 1-to-1 to rules
“Additionally, each rule must be less than 2KB once compiled.”
https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest#dynamic-rules

17

I did not say MV3 eliminates content filters. Network rules will still block content resourced from untoward sources. I said MV3 eliminates cosmetic filters.

As I recall, Google originally allowed only 3000 static rules per Manifest 3 (MV3). That’s from recollection, and to be accurate means I would have to track through articles at www.archive.org to find the firstmost articles reporting on the limitations of MV3. After the backlash from users and extension authors (not all of which are ad/content blocker authors), Google upped the static rules count to 30,000 as a per-extension limit, and 330,000 aggregate rules across all extensions. So, yes, Google put off their scheduled moves to MV3 for a year while reevaluating their decisions, and getting feedback, they upped the static rule limit, but there is still a limit, and it isn’t that high. I already showed an example between uBO under MV2 and uBOL under MV3 as to the drastic reduction in rules. Some static rules got converted to DNR rules, but many got discarded since they could not be converted to DNR rules.

Content filtering and cosmetic filtering are not the same. Network rules do content filtering. That’s how ad content gets filtered out. 3rd-party comes from another source than the web document you retrieve. 1st-party ad content often comes from a different path or using URL arguments which can be filtered by network rules. Some adblockers (e.g., Raymond Hill for uBlock Origin) prefer to call their extension a content blocker instead of an adblocker, because they can filter out more than just ad content, and why I often say “ad/content blocker” to encompass both viewpoints. MV3 does not eliminate content filtering. It does eliminate declarative cosmetic filtering. Regular cosmetic filters are declarative, and use CSS selectors handled by web browsers through the ‘style’ tag element. Procedural cosmetic filters use Javascript to find DOM elements to hide.

What’s the issue with Manifest V3?
“MV3 imposes new limitations, such as a cap on blocking rules, the removal of background scripts, and changes around cosmetic filtering.”

Migrate to Manifest V3
“Migrate to a service worker … This change also requires moving DOM, window, and certain extension API calls into offscreen documents.”

[Blog post] Mozilla’s Manifest v3 FAQ
Move DOM and window calls to an offscreen document

Removing DOM access breaks many extensions, not just for adblockers. There is a less-than-ideal workaround, but it does not alter the DOM for the current web doc’s elements. Service workers have no access to document functions. Service workers can’t access the DOM or the window interface. Manifest 3 sucks.

When did you last use an MV2 extension that was untoward to the handling of your data accessible within the scope of the web browser? Do you install extensions from elsewhere than the Chrome store? Or from unknown and never-reviewed extension authors? That untoward behavior is possible does not mandate it does happen.

I also did not say “Google is using MV3 to unblock their adverts” (or their ad tags, or analytics, or other Google services") to undo ad/content blockers. I am saying it is a possibility under MV3 where the browser has control to override any blocks by MV3 extensions. Remember that Google is the one that chose to change from MV2 to MV3. That does not preclude them in changing code in the browser to override/ignore the service workers in changing content in the web doc when rendered.

You think Google did not invent MV3 to protect its revenue streams. I believe Google’s motivations were profit-driven, so we differ on Google’s motivation to leave MV2 to move to MV3. Google’s is not driven by altruism. Alphabet is a $192B business intent to stay in business, and proactive to grow their business.

Google has hinted they may decouple from Chrome. They started the Chromium project, and are its major developer. If that happens, who knows what will happen with Manifest 3. Could be, as with Firefox and Brave, MV2 support will return to Chrome, MV3 will continue forward, so Chrome, like other web browsers, will both versions. There will be no return of MV2 if Google choose not to decouple from Chrome.

18

Brave team member @fanboynz:

“Brave uses the same lists” (as uBlock Origin).

In addition, I occasionally write custom filters; and I created a Manifest V3 extension for Brave Browser.

I do not expect “ease of use” to improve. I anticipate “let Microsoft do ‘this’ and ‘that’ for you.” ← That I keep trying to disable.

My interest in Brave Browser is Privacy and Security, as long as Brave has the browser that has the lead.