Google today reached the final milestone in a browser-extension transition that has been years in the making, all remaining Manifest V2 extensions were removed from the Chrome Web Store.
Not really. UBlock Origin Lite works really well. They even added content scripts recently. From a technical perspective MV3 offers more security by default.
The following filter options can’t be translated into DNR rules:
strict1p, strict3p: whether a network request is same-origin as its initiator
Entity-based values for domain= filter option (webextensions #394)
redirect-rule=: the DNR API does not support redirect-if-blocked concept (webextensions #493)
Click-to-load embedded contexts through redirect=click2load.html filter option
Regex-based removeparam= modifier filter options
Exceptions for all modifier filter options are not possible
Workarounds exist for removeparam= and csp= by carefully tuning the priority property.
Many very useful regex-based filters used in uBO are not allowed, or are rejected by the DNR API (webextensions #344)
replace=, can't modify the response body (full support is only possible with Firefox MV2)
ipaddress=, can't use IP address as a condition to block/unblock (full support is only possible with Firefox MV2)
urlskip=, this requires programmatic steps to extract a URL from another URL (partial support, for strict-blocked pages only)
aside from that it is somewhat better than default ublock but that’s a pretty big list of issues.
They generate memory issues (use-after-free, dangling pointers, double free(), zombie processes, uncomplete teardown, GC failures or abrupt stops, race conditions, etc.) because of their shitty isolation, and their poor service-workers and IPC architecture.
What’s worse, they greatly limit the network APIs needed to active defense (DNR instead of webRequest).
I agree however that Chromium has some issues still. I have personally managed to crash my browser when calling the Mojo APIs via JavaScript. However, it wasn’t related to security. As GrapheneOS notes, no other browser engine provides the same levels of sandboxing. Recognizing the effectiveness of Chrome’s sandbox, Microsoft began evolving Windows kernel access control to formalize and harden these techniques at the OS level. The upcoming Windows Updates implements this in its new ProcessContainer support.
Blaming process isolation and IPC for memory bugs like Use-After-Free and dangling pointers fundamentally confuses language-level C++ problems with OS containment architecture. Memory corruption exists across all C++ engines (Gecko, WebKit, Blink); isolation is what prevents those bugs from compromising the host OS.
Handing third-party extensions blanket permissions to inspect and modify live plaintext traffic across all tabs creates a massive MITM exfiltration surface. Moving rule matching to declarativeNetRequest enforces least privilege by executing filters in the native engine without exposing sensitive network payloads to extension code.
webRequestBlocking is not deleted in MV3. The synchronous blocking engine still exists in Chromium. If an extension is installed via local policy or the Windows Registry (ExtensionInstallForcelist), full programmatic webRequestBlocking executes in Manifest V3 just as it did in MV2.
Big win for Firefox.
Not really. UBlock Origin Lite works really well. They even added content scripts recently. From a technical perspective MV3 offers more security by default.
The following filter options can’t be translated into DNR rules:
aside from that it is somewhat better than default ublock but that’s a pretty big list of issues.
No, they’re intrinsically less secure.
They generate memory issues (
use-after-free, dangling pointers,double free(), zombie processes, uncomplete teardown, GC failures or abrupt stops, race conditions, etc.) because of their shitty isolation, and their poor service-workers and IPC architecture.What’s worse, they greatly limit the network APIs needed to active defense (DNR instead of
webRequest).GrapheneOS disagrees with you:
https://grapheneos.org/usage#web-browsing
I agree however that Chromium has some issues still. I have personally managed to crash my browser when calling the Mojo APIs via JavaScript. However, it wasn’t related to security. As GrapheneOS notes, no other browser engine provides the same levels of sandboxing. Recognizing the effectiveness of Chrome’s sandbox, Microsoft began evolving Windows kernel access control to formalize and harden these techniques at the OS level. The upcoming Windows Updates implements this in its new ProcessContainer support.
Blaming process isolation and IPC for memory bugs like Use-After-Free and dangling pointers fundamentally confuses language-level C++ problems with OS containment architecture. Memory corruption exists across all C++ engines (Gecko, WebKit, Blink); isolation is what prevents those bugs from compromising the host OS.
Handing third-party extensions blanket permissions to inspect and modify live plaintext traffic across all tabs creates a massive MITM exfiltration surface. Moving rule matching to declarativeNetRequest enforces least privilege by executing filters in the native engine without exposing sensitive network payloads to extension code.
webRequestBlocking is not deleted in MV3. The synchronous blocking engine still exists in Chromium. If an extension is installed via local policy or the Windows Registry (ExtensionInstallForcelist), full programmatic webRequestBlocking executes in Manifest V3 just as it did in MV2.