Hacker News Reader

Comment by dragonwriter | Hacker News Reader

The design doc — the part quoted in the note linked here even — explicitly notes that it will probably be required to retain some degree of the existing functionality slated for eventually removal until the new API and other replacements cover all use cases; the response linked here appears to (not improperly, in the context of making a case for why much of the functionality is needed) ignoring that and treating the planned intent as removing all of the existing WebRequest API functionality that is not observational for a hard cutover to the new API which does not immediately supports large swath of currently used functionality.

I think the response is appropriate, energetic advocacy, but the HN headline is hyperbolic.

View on HN

The uBlock maintainer specifically says that uBlock Origin and uMatrix use a different matching algorithm than the declarativeNetRequest.

The title isn't at all hyperbolic. You don't deprecate such important functionality without laying out a full plan for replacement.

Unless there is no such plan and in reality you want to screw uBlock Origin, which I might say is the most aggressive ad blocker available, and isn't owned by a company in bed with the ads industry, like AdBlock Plus.

Oh, the Google fanboys. “Didn’t you read the article? This is purely for privacy reasons.” Nevermind that this makes it harder to actually keep your privacy. Nevermind that this is exactly what people warned would happen in a browser monoculture controlled by an ad company. That’s just a coincidence. It must be, because Google are the good guys, am I right?

Supporting privacy would allow browsers to block requests, full stop. There's no way to spin this specific action as pro-privacy.

The design as presented isn't for addressing privacy concerns.

It still allows extensions to get a list of URL's accessed

firefox isn't that good with privacy either

https://www.zdnet.com/article/firefox-tests-cliqz-engine-whi...

This was a terrible mistake by Mozilla, but a test pilot for a limited number of users doesn't seem permanently worse than what Google does in regards to privacy.

Moreover, this presumably didn't affect users who installed via a package manager, while with Chrome the installation method doesn't matter.

However I wish Mozilla was publicly funded, so that they don't have to constantly search for alternative revenue sources.

Irrelevant whataboutism. It doesn’t matter what Firefox does, the article is about Google Chrome/Chromium.

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...

> 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.

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...

> 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.

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)

But the design document only mentions retaining the old API for features that aren't possible with the new API, such as onAuthRequired. So it would still cripple uBlock

What if someone would create a pull request to implement unlock origin natively inside chromium, instead of an extension. If such a PR met all technical criteria, would Chromium project accept it?

No. Google would not include, as a built-in part of Chromium that is installed by default, a feature to lower their ad revenue.

Doesn't Chromium already lower their revenue from other lacks of integration that are included in Chrome?

Next to no one uses Chromium. The integrations usually start in Chrome, leaving Chromium pure, allowing Opera etc to forge their own path. This is a disturbing trend to change the course of the project, likely due to Edge being based on Chromium.

I bet a decent chunk of the MS engineers lobbied to adopt Gecko instead of Chromium when they decided to move away from EdgeHtml. I wonder what the reasoning was for not going that route, it seems like a huge miss and a total acceptance of a browser monoculture.

Gecko is deep in to a transitional phase. Once it comes out the other end it may be simple to embed but it's currently far too early for that.

On the other hand Chromium is relatively simple to adapt with many real world examples to learn from.

(Personally I think they should stick with EdgeHtml but it seems that ship has sailed).

I wish they would have thrown in with the Servo project, but Chromium is ready now and Servo isn't, so I'm sure that factored in.

I wonder how quickly servo could become feature if a major player decided to adopt it.

nodeJS uses Chromium and not Gecko. I suspect MS’s requirements basically necessitated the use of Chromium.

However, this does provide an opening for MS edge, if MS forks Chromium for Edge and excludes user hostile “features” such as this.

Sadly the only use of Chromium among regular non-tech people is in spyware/malware installations.

There is a quite a bit of adware which uses unsigned Chromium to push their wares.

That is the malware installs a modified Chromium with all the "extras".

So anecdotally, when I see Chromium on a users computer I assume the worst (that I have a cleanup task ahead).

Of course not.

Brave browser may be what you are looking for.

Isn't it also based on Chromium?

Sure, but this change might cause a hard fork. VC investment in browsers has been a long time coming.

If you want something like that, get Brave. It's Chromium-based that has privacy and ad-blocking built-in.

Is there a chance that Google's changes here might disrupt Brave's integration into Chromium? I mean, they might be using this WebRequest API to do their built-in blocking.

I'd love Chromium feature that uses system password manager (macOS / iCloud).

On the flip side Chrome's profiles are nice and I wish macOS supported more of it.

I really like the point the uBlock maintainer's make:

"Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

I'm just waiting for the time until websites won't load at all unless you have hardware DRM turned on that will take all of your control away.

>Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium

This is off-topic, but I felt the same way about most data privacy problems. It was my own browser that was giving out the information and I would still like to see better control over it by default. Data privacy laws are simply a bandaid that don't help at all against malicious actors.

> I'm just waiting for the time until websites won't load at all unless you have hardware DRM turned on that will take all of your control away.

I already leave websites that become unusable with adblock on, or without it on. It will just trim down on the amount of sites I go on.

Same here.

If it's something I'm particularly interested in, I look for a cache, snapshot or whatever.

Edit: Or just read HN comments.

Ah yes, I used Firefox' reader mode, but some news sites now don't even properly support that. I may have to remind myself not to go on those sites anymore as well.

> Firefox' reader mode, but some news sites now don't even properly support that

All sites which are on Google Amp. Google, whenever it can, "helpfully" gives me the amp site and then I have to find and click the link to the actual site to get to the "readable" version.

Excuse me, but I believe using a google website to get to content negates the whole discussion over how to prevent webscale surveillance by advertising companies.

In other words, if your "solution" to the problem as outlined in the OP involves google, you already lost.

I'm just waiting for the time until websites won't load at all unless you have hardware DRM turned on that will take all of your control away.

My money is on news sites and other paywall sites doing that first. How long before they stop letting us "open in new private window"? Washington Post doesn't even allow that anymore -- a shame too, since I haven't read a single one of their articles since then.

I think this is the core difference motivating this change: do extensions necessarily act on behalf of users? If that were true, there'd be no such thing as extension malware.

Google's business model is exactly the same.

Extensions should act on behalf of users but, like websites, some don't. A questionable or poorly-maintained extension can do more damage than any single website, and browsers can support user agency by replacing APIs with better ones: an effective declarative API for content blocking would majorly speed up extensions like uBlock Origin and make it harder for other extensions to follow users around the web.

That said, we should all fight for changes that let extensions like uBlock maintain feature parity.

Disclaimer: I'm both a Chromium developer and a uBlock Origin user and speak only for myself.

If you create a superior api (esp w/regards to speed) people will naturally move to extensions which use that api. Then once usage of the old api has dropped significantly, you can deprecate the old api.

It has been proven time and time again, that that's at best only partially true. There are two factors:

If they have something working with one API, they have to have a good reason to re-implement it with a new API. It may be 'fast enough' and reliable, so why go through all that pain?

Or, it's just the long tail of API consumers (e.g. site on the web). Some things aren't maintained and updated, but they don't go away.

I would gladly live in the universe which is a smoking bomb crater of questionable and poorly-maintained browser extensions, than be a wealthy rock star in any universe of amazingly performant extensions, but which are using a browser API which has denied my right to self-determination on my own computer, effectively taking away my ability to say "no" to actions which are then forced upon me. This is like a kind of information rape. And here the suggested "alternative" of static, declarative, JSON-only filters means no programmatic ability to veto requests before they happen. It is effectively forcing users to leap before they look. And this completely arbitrary limit on the number of filters -- and it is completely arbitrary -- is the same kind of neutering mechanism, forcing me to "prioritize" a small number of request vetoes. In other words, it's forcing me choose the manner in which the rape happens.

Is it perhaps time to return to using external tools such as Privoxy, Pi-Hole and the like? Privoxy appears to still be around, and (I think) was originally at the forefront of user-managed web controls.

Once the browser reaches its natural Borg-self, transparent user-level tools will be all that provide a semblance of control. Well that, and Firefox.

If a website shows a popover ad, it might be a first-party script putting up a modal, then a third-party iframe with the ad inside that modal.

Blocking at the network layer will leave the iframe blank, but the modal will still be present. It's not such a good user experience, especially for less savvy users who might be confused by a mysterious blank modal.

AFAIK Privoxy isn't actively maintained.

I think you are correct, and that may be an opportunity.

Tools such as Pi-Hole cannot block YouTube ads effectively.

That's what the DNS-over-HTTPS is about - so your local DNS won't be consulted, instead it will be drowned in the HTTPS traffic. Remember, SNI is going to be encrypted too, so your router cannot distinguish DNS and regular traffic.

There are four listeners with blocking ability on the webRequest API.

The design document says "potentially removing blocking options from most events". There is one mention that the blocking ability of webRequest.onAuthRequired may still be required.

From this I deduce that the plan is to remove the blocking ability of the three remaining listeners with blocking ability

uBlock Origin uses two of these remaining blocking listeners, uMatrix uses three of them.

To interject with a potentially inconvenient fact, I think the premise that ad blocking (request blocking) is now obstructed, is incorrect. Therefore this response seems exaggerated to me.

This is because Chrome extensions can use the 'debugger' API to send remote debugging protocol commands to a page, to intercept and filter / block all requests.

There is no need to use the provided Chrome extension APIs for blocking. Google can remove all of them, I think, without effect.

This is because there are multiple ways to do the same thing. Authors/engineers complaining that now they are impeded, are in fact mistaken.

Disclosure: I know this because I have actually re-implemented the blocking from AdBlock Fast using CRDP Network domain.

I'm interested in this. What's the CRDB equivalent of onBeforeRequest()?

I don't know, you should have a look yourself. I know that you can intercept requests, and block, provide other payloads etc.

I'm interested in that even tho this is factually correct, it's ignored / downvoted because it goes against the prevailing narrative. Discourse here can be pretty 1 dimensional, it's more like a confirmation bias machine / echo chamber, than a discussion. Just like the rest of the net, no matter how 'smart' the people here are. The same behavior pattern occurs here as everywhere else.

It would be interesting if this can be solved in discussion forums of the future.

An alternative explanation is just that people assume if ad blockers move there, Google will deprecate that API for the same stated reasons.

I did find it, it's called setRequestInterception(). It's marked as experimental, and has a note that it disables caching, but there's some debate as to whether it actually does.

I think most of the meaning here isn't found in a design document

Reply on news.ycombinator.com