Hacker News Reader

Comment by shawnz | Hacker News Reader

I was under the impression that the ability to observe all requests was the whole problem that made the webrequest api dangerous. Now they're keeping that but eliminating the blocking features only? What?

View on HN

The stated reason for removing blocking from WebRequest is to improve performance, not privacy. If an extension can block a request, Chrome needs to wait for the extension before performing the request. See the WebRequest section in the design document:

https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

So, why not just not install the extension then? This just seems like taking the user's choice away.

In fairness to Google, it's not absurd in principle. Mozilla has dealt with this problem for years: when an extension slows the browser down, the user is more likely to blame the browser than the extension. But in this specific case of ad-blocking extensions, I have a hard time taking Google's justification seriously. Ad blockers speed up the browsing experience far more than whatever negligible processing time the filter process takes.

That's exactly what it is- taking the choice away from the user. There were other options they could have taken- such as warning a user when installing an extension that uses these APIs, or building out a new asynchronous API (like Firefox did).

Instead they choose to go with the option that screws over users but might make them more money.

Yes. That's what the google employees said, but I recall ghostery or some other group publishing actual numbers showcasing it took microseconds to do the check

This showcased the google employees declaration it was performance to be smoke.

So far as the original message seemed to be saying, it isn't about the uBlock Origins of the world, well behaved, highly performant code. They don't hurt end users. It's the badly written add-ons that they're trying to eliminate.

Given what they're breaking by their chosen mechanism, I would have thought educating end users would be the better approach. The running Chrome instance would be able to tell that an add-on is a large source of blocking, and could easily pop up a warning to indicate such, complete with a one-click option to disable the add-on.

Reply on news.ycombinator.com