Live data from Hacker News

Google backtracks on Chrome modifications that would have crippled ad blockers

zdnet.com

161–169 of 169 posts

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#161
post #156
post #79

Earlier quoted context omitted.

Google isn't removing any ability to observe, log, and forward information about requests, in any way. So the privacy angle is pure bullshit. They are removing, among other things, the ability to dynamically cancel requests, and replacing it with a declarative API. That limits how well an adblocker can function.

When users try to install a Chrome extension, the browser is telling them what permissions it needs, e.g. the capability to read browsing traffic. So you could just decline the installation and install a different ad blocker that works without that permission.

How would such ad blocker work, though?

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#162

Google did NOT backtrack on ANYTHING. From the new thread: > Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still n…

> There is no performance hit from using webRequest like this Citation needed. My personal experiments show that blocking webrequest has more latency than the network connection!

My own personal experiments show that even with huge rule lists, the latency incurred on the connection is barely above the noise and improves loading times on most websites by mulitple magnitudes more than it could increase latency.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#163

Google did NOT backtrack on ANYTHING. From the new thread: > Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still n…

Well quite frankly, I dont care what google does. I am doing if old school since forever, squid proxy doint mitm. And it works for all my OSes from android to linux laptop. It is not as easy to set up as in browser ads blockers, but is completly out of control of browser and ad blockers or OS vendor. Anyway there is firefox too, while for chrome, as everything from google, I can only say - I told you so (10 years bac…

Do you know of a good guide for setting up a squid proxy in this way?

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#164

Google did NOT backtrack on ANYTHING. From the new thread: > Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still n…

> There is no performance hit from using webRequest like this Citation needed. My personal experiments show that blocking webrequest has more latency than the network connection!

Did you read the article? That's what it's about. I'm actually really surprised you posted this, the whole article is about Cliqz doing a performance test and finding that the claims about ad blockers hurting performance were not true.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#165

Earlier quoted context omitted.

> There is no performance hit from using webRequest like this Citation needed. My personal experiments show that blocking webrequest has more latency than the network connection!

Did you read the article? That's what it's about. I'm actually really surprised you posted this, the whole article is about Cliqz doing a performance test and finding that the claims about ad blockers hurting performance were not true.

I think it was sarcasm.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#166

Sounds like Google will still move towards what they were planning but will likely just take a bit more time and more versions to get there (as the outrage subsides). From my perspective, the biggest improvement in their proposal would have been the increased privacy and security users would receive with adblockers that use the proposed scheme. Under the current scheme, any Chrome adblocker can see all of the pages t…

The Safari approach is next to useless, because it can be easily circumvented. That many publishers don't do it, that's only because they don't have the know-how or because they don't want to piss off what's still a minority.

Note that the browser is the "user agent", acting on behalf of the user and extensions are for extending the capabilities of the user agent. The browser should be yours and should do what you tell it to do.

Users only need one or two extensions that they need to trust. Can't you trust uBlock Origin? If no, given its open source nature and the people that work on them, then why can you trust Chrome and Google more?

The privacy angle is a complete red herring.

Yes, Chrome's Store is filled with spyware, but that's Google's fault for having a broken review process. Firefox (addons.mozilla.org) does not have the same problem, in spite of the fact that Firefox lacked permissions until the Quantum release.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#168
post #156
post #79

Earlier quoted context omitted.

Google isn't removing any ability to observe, log, and forward information about requests, in any way. So the privacy angle is pure bullshit. They are removing, among other things, the ability to dynamically cancel requests, and replacing it with a declarative API. That limits how well an adblocker can function.

When users try to install a Chrome extension, the browser is telling them what permissions it needs, e.g. the capability to read browsing traffic. So you could just decline the installation and install a different ad blocker that works without that permission.

An ad blocker that solely uses the declarative API won't be a good one.

The good ones will still want onBeforeRequest() for heuristics and dom access for click-to-block.

The whole privacy excuse from Google is intentional hand waving. Decent ad blockers will still need permissions for scary sounding things.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#169

Earlier quoted context omitted.

Did you read the article? That's what it's about. I'm actually really surprised you posted this, the whole article is about Cliqz doing a performance test and finding that the claims about ad blockers hurting performance were not true.

I think it was sarcasm.

Yeah I'm not good at detecting that, especially not online where people say all sorts of weird things :)
Post reply on HN