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.
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.
There’s also pretty restrictive length limits on filter lists iirc, so ubo lite would have to select top filters at some point. This getting worse as websites add more ads or obfuscate more requiring more rules.
Some of those limitations were never supported in Chrome to begin with. MV3 still supports webRequestBlocking at the engine level but it is gated behind enterprise policy (ExtensionInstallForcelist in the Windows Registry, macOS MDM, or Linux managed policy JSON). If an extension with webRequestBlocking is installed via policy, it restores programmatic interception.
Not all users are able to do that, as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.
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.
There’s also pretty restrictive length limits on filter lists iirc, so ubo lite would have to select top filters at some point. This getting worse as websites add more ads or obfuscate more requiring more rules.
Like FB putting every character in every [w][o][r][d] on the site into a unique code block
Some of those limitations were never supported in Chrome to begin with. MV3 still supports webRequestBlocking at the engine level but it is gated behind enterprise policy (ExtensionInstallForcelist in the Windows Registry, macOS MDM, or Linux managed policy JSON). If an extension with webRequestBlocking is installed via policy, it restores programmatic interception.
Not all users are able to do that, as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.