Replying to @⁨timewarp@lemmy.world⁩

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.

Replying to @⁨communist@lemmy.frozeninferno.xyz⁩

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.

Replying to @⁨timewarp@lemmy.world⁩

In practice, I found it breaks sites more, lets some things through, triggers more adblock detectors, and doesn’t work as well with the annoyance list.

It doesn’t work on YouTube. And the maximum number of entries to block is limited.

Its not catastrophic though.

So UBO Lite is not wholly ineffective, no. It works great, mostly. Buts its definitely more of a nuisance to use, which is exactly what Google wants.