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.

5

2

22

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

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.

1

1

14

Replying to

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.

1

3

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.

1

2

10

Replying to

and

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

1

Replying to

and

Sure, all I'm saying is that they chose the wrong benchmark to use for matching the status quo. A blacklist-based approach is fundamentally not going to block all tracking / advertising and doesn't provide fundamental improvements to privacy and security. It's opportunistic.

1

Replying to

and

It provides privacy and security improvements in practice, by opportunistically blocking a lot of stuff, but it's not a workable approach to fundamentally improving that in the browser. It can be bypassed by heavily tying it into actual 1st party content or just lots of changes.

1

Replying to

and

The webRequest API itself was not designed for privacy / security improvements and has the failure mode of allowing requests. If the filtering extension crashes, times out or fails in some other way, the requests go through unfiltered. Making a robust replacement is important.

1

Replying to

and

Lots of people are also harmed by malicious extensions. If you host a site with Content-Security-Policy and report-uri you end up with a huge number of policy violation reports for all kinds of naive and often malicious extensions injecting tracking and advertisements into pages.

12:51 AM · May 31, 2019Twitter Web Client

Replying to

and

The clever ones know how to remove the headers and meta tags for Content-Security-Policy, but many of them don't do that, since decent strict CSP policies are not common. It's a nice view into the world of what browsing is like for regular people. It's a very real issue.

1

Replying to

and

The declarative API doesn't give extensions that power, so that's another advantage. It could still make sense to have a programmatic API for more complex use cases, but it shouldn't be normalized with such widespread use. They probably shouldn't distribute those without review.

1

Show replies