News for hackers. Stuff that matters.

A comment on Google proposes changes to Chromium which would disable uBlock Origin. Parent comment

Re:Google proposes changes to Chromium which would disable u... by tyingq on Wednesday January 23, 2019 @08:02AM (#18977760)
It also spells out that the new API can consist solely of static, known ahead-of-time rules[1]. The rules are json, so that kills any logic beyond pattern matching. We already know that approach severely limits the effectiveness and usability of an ad blocker. It's pretty much the same as ad blocking with a hosts file, other than being able to also statically provide path info. Imagine a list of "bad sites" and/or "bad uris". Limited to 30k entries to cover the entire internet.

The fact that the plan ends with extensions still able to see all web requests, record all web requests, forward a log of all web requests to any arbitrary endpoint, etc...means the "privacy" angle is pure bullshit. I suppose the "performance" angle is somewhat true, but the net performance gain of NOT downloading all the ads makes up for any performance loss of processing/filtering requests. Sites with ads are faster when you load an adblocker.

The only thing being taken away is the ability to dynamically observe a web request and cancel it. Who uses that functionality outside of ad-blockers? Not many. There's no hyperbole in the headline.

[1] https://developers.chrome.com/extensions/declarativeNetReque...

[ Parent | on HN ]
Re:Google proposes changes to Chromium which would disable u... by magicalist on Wednesday January 23, 2019 @09:09AM (#18978196)
> It also spells out that the new API can consist solely of static, known ahead-of-time rules

If it ends up as effective as Safari/iOS's content blocking, I don't see the problem.

> The fact that the plan ends with extensions still able to see all web requests, record all web requests, forward a log of all web requests to any arbitrary endpoint, etc...means the "privacy" angle is pure bullshit.

Yes, if you grant permission to access everything, it has permission to access everything. The benefit of the rule based approach is that the extension doesn't have to have access to everything.

The privacy angle is being able to move most extensions away from accessing all data in all tabs.

[ Parent | on HN ]
Re:Google proposes changes to Chromium which would disable u... by tyingq on Wednesday January 23, 2019 @09:16AM (#18978250)
Safari/iOS's content blocking has a 50k limit, not a 30k limit. I don't own anything that can run Safari. Is there a credible comparison of how well it works versus Ublock Origin on Chrome? I'm skeptical that a static list would match up to the ability to dynamically make decisions. If I were in the ad business, I'd immediately make use of ads from the same root domain as the content, or subdomains mixed in with lots of random/changing subdomains for content like images, etc. Voila, static ad blockers thwarted.

Edit: I assume "right click -> hide and don't ever load again" becomes "right click -> load but hide" ? Also, related: https://apple.stackexchange.com/questions/337094/safari-12-c...

[ Parent | on HN ]
Re:Google proposes changes to Chromium which would disable u... by AsyncAwait on Wednesday January 23, 2019 @11:18AM (#18979532)
> how well it works versus Ublock Origin on Chrome? I'm skeptical that a static list would match up to the ability to dynamically make decisions.

The Safari content blocker is better than nothing, but it's extremely simplistic compared to uBlock Origin. It can't even block YouTube ads properly.

[ Parent | on HN ]
Re:Google proposes changes to Chromium which would disable u... by csharp on Thursday January 24, 2019 @09:57AM (#18989178)
Apples rules are a huge pain. Exception handling gets extremely complex (block all urls matching regex R, on domain B and C but not on subdomain D.B). I have not seen anyone yet able to handle the full breathe of the EasyList format.

To get around the 50k limit added by Apple, you must use multiple lists, however domain exceptions must be included in the same subset as the parent rules, since rules do not combine once compiled.

Also, dynamically whitelisting a domain is annoying since you must remove all of the lists form the webview before loading the page. HTTPS-Everywhere is even worse to get operational using Apple's content blocking lists.

(edited grammar mistakes)

[ Parent | on HN ]