Chrome 151 Kills Manifest V2 — uBlock Origin Is Done

Google started closing this door in January 2022, when the Chrome Web Store stopped accepting new Manifest V2 submissions. Today it finished. Chrome 151 carries a Chromium change that deletes the AllowLegacyMV2Extensions code path, the developer mode switch a stubborn minority had been riding since Chrome 138 disabled Manifest V2 for everyone else. No flag is left to flip. If you want an anti tracking extension in Chrome, you are choosing from what Manifest V3 permits.

Four years and eight months from first restriction to final removal. The slowness is why most people did not notice until their blocker went gray.

Key Takeaways

• Chrome 151 reached stable on July 28, 2026 and removed the last Manifest V2 code paths from Chromium, including the AllowLegacyMV2Extensions developer mode override.
• Chrome 150, released June 30, 2026, had already dropped the kExtensionManifestV2Disabled flag that let users restore Manifest V2 installs from the Chrome Web Store.
• Google's published timeline sets August 31, 2026 as the date every remaining Manifest V2 extension leaves the Chrome Web Store, freezing installed copies with no further updates.
• The uBlock Origin Lite FAQ blames the missing features on declarativeNetRequest's inability to enforce rules according to the top context — the URL in the address bar — not on rule caps alone.
• Extensions that rewrite page content through content scripts, including Gmail pixel blockers, never used the blocking webRequest API that Manifest V3 removed.

What Exactly Did Chrome 151 Remove?

Three legacy flags and the code behind them: ExtensionManifestV2Unsupported, ExtensionManifestV2Availability, and AllowLegacyMV2Extensions, the last of which let a developer load an unpacked Manifest V2 extension in developer mode. As heise online reported when the change landed upstream, Chromium deleted the implementing code rather than disabling the switch. A toggle can be restored downstream with one line; a deleted branch cannot.

The sequence, from Google's own Manifest V2 deprecation timeline:

• July 24, 2025 (Chrome 138). After a rollout starting October 2024, the re enable option disappears; the ExtensionManifestV2Availability enterprise policy goes with Chrome 139.
• June 30, 2026 (Chrome 150). The kExtensionManifestV2Disabled feature flag is removed, closing the last route to installing Manifest V2 from the store.
• July 28, 2026 (Chrome 151). The remaining flags and AllowLegacyMV2Extensions go with it.

One date is still ahead: August 31, 2026, when all remaining Manifest V2 extensions leave the Chrome Web Store. Google's wording on what happens to your copy: they "will remain installed, but will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome."

Why Can't uBlock Origin Just Be Ported to Manifest V3?

Because blocking webRequest let uBlock Origin judge each request individually, as it happened, knowing which page had asked for it, and declarativeNetRequest hands none of that back. Raymond Hill's position has not moved in seven years: the project points Chrome users at Firefox or at uBlock Origin Lite, and the uBlock Origin repository says outright that uBO works best on Firefox.

Here is the part most coverage gets slightly wrong. The story is usually told as a rule count problem: Google capped how many filter rules an extension may carry, and uBO's lists were too big. The project's own explanation is different and more damning. From the uBlock Origin Lite FAQ: "Because the declarativeNetRequest API does not support the ability to enforce rules according to the top context, i.e. the URL in the address bar, the following capabilities can't be supported."

Fourteen casualties follow, among them dynamic filtering, the per site no scripting switch, strict1p and strict3p, redirect rules, click to load for embedded content, regex filters generally, and CNAME uncloaking. Those are not features you fit under a cap. They need to know which site you are on, and the API refuses to say.

The caps are real too, just secondary. Chrome's declarativeNetRequest documentation guarantees 30,000 static rules across at most 50 enabled rulesets, allows 30,000 dynamic rules, and permits only 1,000 regular expression rules of each type. That regex ceiling is the tell: tracking infrastructure rotates hostnames constantly, and a regex is how a list keeps pace between updates instead of shipping a rule per variant.

What Does uBlock Origin Lite Actually Give Up?

Dynamic filtering entirely, generic cosmetic filtering at the default setting, and user supplied filter lists as a concept. uBOL is a good MV3 blocker that is deliberately less capable than the original, and the project says so itself.

• Cosmetic filtering is off by default. The FAQ states that "by default there is no generic cosmetic filtering in uBOL while this occurs by default in uBO," and that you "will have to raise the blocking mode to Complete" to get it. Complete mode is the one asking for broader site permissions.
• There are no filter lists in the usual sense. Again from the FAQ: "There are no filter lists proper in uBOL. There are declarative rulesets and scripts which are the results of compiling filter lists when the extension package is generated." Adding your own is not a setting you overlooked, and because rulesets compile into the package, new rules reach you through a Web Store update rather than a background refresh.
• The upside is real. uBOL needs no broad read and modify permissions by default and runs with no permanent background process, so it costs almost nothing in memory or CPU.

Install it if you are on Chrome. Just know what you traded. The Electronic Frontier Foundation warned in December 2021 that a declarative API would leave developers dependent on Google engineers shipping new rule primitives. Five years later, that is the arrangement.

Which Privacy Extensions Survived, and Which Are Hobbled?

The dividing line is not extension quality. It is whether the tool needed to inspect and cancel network requests at runtime, knowing which page made them. We covered the mechanics when this migration was still theoretical, in why Manifest V3 makes privacy extensions weaker. Now it is settled.

Hobbled: full featured content blockers, whose value came from per request decisions and large regex driven lists. Every blocker on Chrome now works inside the same declarativeNetRequest envelope, AdGuard included; fitting more rules under the cap is engineering skill, but it gives nobody back top context awareness. Anti CNAME cloaking is the sharpest loss, since trackers disguised as first party subdomains cannot be uncloaked declaratively.

Largely intact: content scripts, cookie managers, password managers and form tools, none of which used blocking webRequest. Browser level blocking also survives, because Brave Shields runs inside the browser rather than as an extension, and Firefox kept blocking webRequest.

Why Did Email Tracking Blockers Survive the Cut?

Because a Gmail tracking blocker is a content script, not a network filter. It runs inside the mail.google.com page, walks the message DOM after Gmail renders it, and rewrites the attributes that would make your browser fetch a remote resource. A 1x1 tracking pixel is an img tag pointing at a sender's server; neutralize the src before the fetch fires and no request happens. A tracking link is an href pointing at a redirector; rewrite it to the real destination and the redirector is skipped. Nothing gets intercepted, because no request is ever made.

Blocking webRequest going away does not touch that, and the same holds for the other Gmail tracker blockers built this way. It is not a loophole. This class of tool was solving a page problem rather than a network problem all along.

Three honest caveats. Manifest V3 bans remotely hosted executable code, so a blocklist that updates itself must arrive as data the extension interprets, not code it runs. A content script needs host permission for its site, which is a real thing to grant and you should read it. And it only covers webmail you have a script for — open the same message in a desktop client and you are back to that client's image settings.

What This Means for Your Inbox

Most people ran one general purpose blocker and assumed it covered everything. It never covered the inbox well. Marketing platforms serve pixels from the same domains that serve legitimate images, and Gmail proxies remote images through Google's own servers, flattening the sender's hostname out of the request entirely. That is why blocking email tracking in Gmail has always needed a tool that reads the message rather than one that watches the network.

So Chrome 151 changes less about your email privacy than the headline suggests, and more about your browsing. Your ad blocker got worse this month. Your email tracker blocker did not, because there was never a good way to build one except as a content script.

Watch the second order effect. As general purpose blockers lose their sharpest tools, analytics vendors gain room in the channels those blockers used to police. Email was always the softest: no ad blocker sits between a sender and your read receipt, and open rate telemetry is a feature marketing platforms sell, not a bug they hide.

Which Anti Tracking Extension Should You Actually Install?

It depends which problem you have, and after Chrome 151 no single Chrome extension covers all of them. The fuller rundown is in the best anti tracking browser extensions for 2026. Compressed, with each tool's real trade off:

• uBlock Origin Lite — the closest drop in replacement, free and light. Trade off: no dynamic filtering, no custom lists, cosmetic filtering only in Complete mode.
• AdGuard — a mature MV3 extension with real investment in fitting coverage under the caps. Trade off: the same declarativeNetRequest ceiling as everyone else.
• Ghostery — tracker focused, with clear reporting on who watches a page. Trade off: its value is as much visibility as blocking.
• Privacy Badger — the EFF's extension learns tracker behavior instead of consulting a list. Trade off: it needs time to learn, and complements a list blocker rather than replacing one.
• Brave Shields — blocking at the browser layer, immune to extension API politics. Trade off: you change browsers.
• Firefox with the original uBlock Origin — still the maximum capability option. Trade off: leaving Chrome.

For the email tracking niche, four names come up and they do different jobs:

• Ugly Email — marks tracked messages with an eye icon before you open anything. Trade off: its core strength is detection.
• PixelBlock — blocks pixels locally, shows a red eye when it stops one. Trade off: pixel focused, and the classic build was Manifest V2, so confirm your listing is the current MV3 one.
• Trocker — pixels and link trackers across Gmail, Outlook.com and Yahoo. Trade off: broad surface, small project.
• Gblock — Gmail focused, with a blocklist that updates itself and tracking link stripping alongside pixel blocking. Trade off: one mail client, and it is paid.

What to Do This Week

Five things, in order. The first has a deadline of August 31.

• Audit chrome://extensions today. Note what you still want, because after August 31, 2026 a Manifest V2 extension you uninstall cannot be reinstalled.
• Install a replacement blocker rather than going without. A constrained blocker beats nothing by a wide margin.
• Add a behavior based layer. Pairing a list based blocker with Privacy Badger catches trackers no list has catalogued, and the two do not conflict.
• Handle email separately. Turn off automatic image loading in Gmail settings as a free baseline, then decide whether you want something that also strips tracking links, which image blocking does nothing about.
• Consider Firefox for one profile. Keeping it with the full uBlock Origin for anything ad heavy is a cheap hedge.

One last thing: Microsoft Edge and Opera are Chromium downstream and both have signalled they will follow. Treat any Manifest V2 extension still running there as borrowed time.

Manifest V2 is not the only deadline reshaping the store this summer. A second set of rules landed on August 1, 2026, restricting what any extension may collect at all — see what Chrome's August 1 data rules mean for email tracker extensions.

Sources: Google, Manifest V2 deprecation timeline, Chrome for Developers, chrome.declarativeNetRequest API reference, uBlock Origin Lite, Frequently Asked Questions, gorhill/uBlock repository, 9to5Google, "Google Chrome will remove older Manifest V2 extensions in August" (July 8, 2026), heise online, "uBlock Origin: The last Chrome workarounds are falling", and Electronic Frontier Foundation, "Google's Manifest V3 Still Hurts Privacy, Security, and Innovation".