Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google backtracks on Chrome modifications that would have crippled ad blockers

zdnet.com

Post reply on HN
Print view View original

81–90 of 169 posts

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

#81

Post by tyingq »

Tsubasachan wrote: post #42
rajeshmr wrote: post #33

I never understand the intent behind introducing this move - is it greed for more ad money through lockdown ? The company is literally a monopoly and still it wants more. This seems like the company is bowing down for shareholder supremacy.

In my opinion its not really a conspiracy. People at Google are so far up their own ass that they don't understand the importance of content blockers. Personally I just can't deal with websites without ublock modifying them.

The initial proposal was for a static list of blocked uris, and no api to add an item to the list.

That really speaks to a conspiracy to me. What plausible reason would there be for that? You would have had to push a new version of an extension to change the list. There's no way that omission was an "oopsie".

They did back off on that.

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

#82

Post by magicalhippo »

rajeshmr wrote: post #33

I never understand the intent behind introducing this move - is it greed for more ad money through lockdown ? The company is literally a monopoly and still it wants more. This seems like the company is bowing down for shareholder supremacy.

The only argument that made sense to me was the one that the current APIs makes it quite difficult to reason about what the extension actually does once installed and running.

By dynamically installing rules downloaded from the web a nefarious ad blocker could, for example, not just block ads but also hide certain political content from search results.

By requiring the list of rules to be hard-coded in the extension, it's easier to see what exactly the extension will do once installed.

For me though, this benefit does not outweigh the cost.

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

#83

Post by tyingq »

happybuy wrote: post #32

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…

"At least with the proposed scheme, adblocker extensions wouldn't have had access to a user's browsing history."

No, that's not true. They aren't removing onBeforeRequest() and friends. They are only removing the "cancel" function in it.

Extensions can still log and forward every request.

The only tiny kernel of truth here is that an extension that only asks for the declarative API permissions couldn't do that.

I doubt there will be any popular blocker that only asks for that declarative API. They still need access to onBeforeRequest() for any sort of heuristics to allow the user to add/change rules based on page behavior.

Also, separately, extensions can inject JS into the DOM. So they can do anything that Google Analytics can do anyway. Like track visited pages.

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

#84

Post by zuzun »

saagarjha wrote: post #63
zuzun wrote: post #56

Earlier quoted context omitted.

JavaScript code will take a millisecond to decide whether to block a request or not and some hard-coded browser function will do it slightly faster, but not by much, because most of the work will be done by the same regular expression, so we are talking about fractions of a millisecond here and you claim to notice that?

Safari pre-compiles the blocking list into some internal representation that is faster than a raw regular expression, and the matching operation is performed many times per page. So I do think it's possible to notice a small performance benefit?

To filter URLs, you have to parse them, check if the domain is blocked using a hash table and then search for thousands of substrings in the path and query parts of the URL. If you use a regex for that, most of the filtering will already run in native code. I guarantee you that this gives you a tough to beat baseline with almost no room for improvements.

Looking at the WebKit implementation, the authors are shipping their own regex engine for whatever reason. I doubt that it beats the battle-tested re2 engine by large margins, if at all.

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

#85

Post by feanaro »

saagarjha wrote: post #64
feanaro wrote: post #53

Earlier quoted context omitted.

The question still remains: what are they optimizing for if we already have sub-millisecond response times? The only evidence you offer is anecdotal. I'm having a hard time imagining perceptible differences in sub-millisecond response times so either you or the study are in error. And just to reiterate other comments: yes, Safari is probably able to block ads just fine now , because they modeled the engine according…

To be honest, I'm much more in favor of this API because of its privacy features than performance. I think it's a little bit faster, but it has a much bigger benefit on the trust side because extensions no longer run arbitrary JavaScript in every page I visit.

It's very improbable the few popular ad blocking extensions could slide in something sinister and avoid public scrutiny for a long time. You have much more reason to be worried about your privacy from Chrome than from uBlock Origin, since Chrome and Google provably violate it.

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

#86

Post by ubercow13 »

saagarjha wrote: post #64
feanaro wrote: post #53

Earlier quoted context omitted.

The question still remains: what are they optimizing for if we already have sub-millisecond response times? The only evidence you offer is anecdotal. I'm having a hard time imagining perceptible differences in sub-millisecond response times so either you or the study are in error. And just to reiterate other comments: yes, Safari is probably able to block ads just fine now , because they modeled the engine according…

To be honest, I'm much more in favor of this API because of its privacy features than performance. I think it's a little bit faster, but it has a much bigger benefit on the trust side because extensions no longer run arbitrary JavaScript in every page I visit.

It does not have any privacy benefit. Extensions can still do that

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

#87

Post by AsyncAwait »

Vogtinator wrote: post #59
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

> With Mozilla's Rust adoption, Firefox got fast. Those are unrelated.

Well, it got faster because of Servo, which is written in Rust, so not completely unrelated, but yes, it did not get fast because of Rust the language.

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

#88

Post by amluto »

happybuy wrote: post #32

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…

A better example of how this could be done is iOS keyboards. They’re run in a sandbox (by default), and they have no internet access. An ad blocker could be sandboxed like this. Sure, such a sandbox can be bypassed by intentionally leaking bits through keyboard input or, in the case of an ad blocker, exactly which requests are blocked, but that would be very obvious nefarious behavior.

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

#90

Post by jfk13 »

XorNot wrote: post #71

Someone pointed out that every Chrome user got that way because a techie got them off Internet Explorer... and those same people can just as easily get them onto Firefox.

Some of them may also have got that way because of the billions Google spent advertising Chrome. I doubt Mozilla could afford to put Firefox ads all over the web to anything like the same extent.
Post reply on HN