Conversation

so, i'm not 100% convinced that declarativeNetRequest exists specifically to prevent you from blocking Google's ads, but let's say it is. then, observe that 30000 rules is more than enough to block every single Google ad, but maybe not every ad ever twitter.com/valarauca1/sta

This Tweet is unavailable.

Catherine

@whitequark

May 30, 2019

in its current form--if shipped without revision--declarativeNetRequest would be seriously detrimental, but that's most infosec initiatives where the people designing them and the people affected are non-intersecting groups. doesn't have to be ad-related

Quote Tweet

Lord Nightmare

@Lord_Nightmare

May 30, 2019

Replying to @whitequark

The problem is sure it blocks google ads, but it doesn't block google's tracking scripts, nor can it block random javascript from other sites. Its a fail-open blacklist scheme, instead of a fail-closed whitelist scheme like noscript (which requires the old API) allows.

Daniel Micay

@DanielMicay

Replying to

@whitequark

Shipping declarativeNetRequest doesn't imply deprecating blocking via webRequest though. It also appears that it's going to ship long before that happens. A better approach would have been implementing declarativeNetRequest and iterating on it before announcing any deprecation.

11:48 PM · May 30, 2019Twitter Web Client

Replying to

and

I think they should cancel the current webRequest blocking deprecation and rethink it. They also need to be clued into the fact that the benchmark to match for content filtering is not EasyList / Adblock Plus anymore. They succeeded at doing that, but people want uBlock Origin.

Replying to

and

uBlock origin funnily does not block everything either and does not allow all workflows, especially for false positives

Show replies