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

91–100 of 169 posts

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

#91

Post by justanother- »

xkapastel wrote: post #78

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

Btw, it is quite interesting, that over all those "we were right" years, people are still trying to confort themself about how great their favorite brand is, we have a saying that even donkey walks on ice only once.

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

#92

Post by tyingq »

magicalhippo wrote: post #82
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,…

That's an interesting thought, but extensions can still hide, inject, or replace content. They just can't avoid downloading the original by any criteria other than uri patterns.

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

#93

Post by esistgut »

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…

I did the switch to Firefox too but can't help notice during frontend (Angular and React) development that Chrome reload my apps significantly faster.

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

#94

Post by steveklabnik »

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.

Stylo was attempted in C++ twice. Both times it was too buggy and had to be thrown out.

The third time, they used Rust. And it worked.

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

#95

Post by tyingq »

amluto wrote: post #88
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.

I like that idea, but it would be hard to pull off. The extension API, for example, allows for messaging between background scripts and content scripts. So you could make a proxy of sorts. And messaging is not the only hole you can poke. They would essentially have to redesign the whole extension API. To the point where no interesting extensions would be possible.

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

#96

Post by tyingq »

rajeshmr wrote: post #45
the8472 wrote: post #40

Earlier quoted context omitted.

That justifies adding the new API, it does not explain removing the old capabilities. They could nudge extension developers to try the new API by adding some "extension X may slow down page loads" warnings somewhere if they don't use it.

> It does not explain removing the old capabilities Very true! Especially if the network impact is of the order of sub-milliseconds.

It's also likely that the net gain in performance by blocking resources with heuristics (that wouldn't be blocked by a simple pattern) outweighs any loss. At least for many websites.

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

#97

Post by magicalhippo »

tyingq wrote: post #92
magicalhippo wrote: post #82

Earlier quoted context omitted.

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,…

That's an interesting thought, but extensions can still hide, inject, or replace content. They just can't avoid downloading the original by any criteria other than uri patterns.

Sure, but the idea, as I understood it, was that by locking down the APIs such that they can't change behavior post-install, any such patters would be visible on inspection.

For example, extensions are already rejected if they contain minified scripts as that also obfuscates what happens. This could be seen as going one step further.

Again, not endorsing this move.

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

#98

Post by kgwxd »

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…

At this point in time, there's hundres of real world exmples of every single "crazy" warning given by Stallman.

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

#99

Post by tyingq »

magicalhippo wrote: post #97
tyingq wrote: post #92

Earlier quoted context omitted.

That's an interesting thought, but extensions can still hide, inject, or replace content. They just can't avoid downloading the original by any criteria other than uri patterns.

Sure, but the idea, as I understood it, was that by locking down the APIs such that they can't change behavior post-install, any such patters would be visible on inspection. For example, extensions are already rejected if they contain minified scripts as that also obfuscates what happens. This could be seen as going one step further. Again, not endorsing this move.

Ah, yes. The separate set of manifest v3 proposals that disallow external and/or obfuscated code. Probably a good idea at a high level, but it does break good stuff like TamperMonkey (10 million users...ouch).

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

#100

Post by kgwxd »

esistgut wrote: post #93
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…

I did the switch to Firefox too but can't help notice during frontend (Angular and React) development that Chrome reload my apps significantly faster.

Cache disabled when dev tools open in FF but not Chrome?
Post reply on HN