Hacker News Reader

Comment by tyingq | Hacker News Reader

Right. Advertisers didn't bother with all these tactics because normal chrome users could download a plugin without any major hurdles to thwart it. Why drive people that wouldn't otherwise use an ad blocker to do so?

That's going away now. Now mostly everyone is vulnerable with the only recourse being pretty technical stuff, not just downloading a very popular plugin.

So advertisers will now be free to get more aggressive without much downside.

Edit: I do get that this sounds like conspiracy theory. But it really matches the Google boiling frogs approach. Removing the blocking onBeforeRequest, as one of the very first things in the manifest v3 spec was not a coincidence.

View on HN

Even if Google did want to reduce effectiveness of ad blockers, doing that via removal of blocking webRequest API is a double-edged sword. It may push users to alternate browsers with more effective ad-blocking.

Besides, webRequest implementation in Chromium is a terrible collection of hacks on hacks. It is a good example how not to design or implement API. I will not be surprised if the removal of the API comes from a simple desire to remove that embarrassing code.

onBeforeRequest was removed because it is a massive spyware and malware vector.

> I do get that this sounds like conspiracy theory.

> … was not a coincidence.

Could it be that it was coincidence? Do you have a solution for reducing extension malware without removing onBeforeRequest?

> onBeforeRequest was removed because it is a massive spyware and malware vector.

Yet you can still inject js right into the page. You just can't stop a page that was going to load from loading. They could have taken away the onBeforeRequest redirect capability and left just the onBeforeRequest cancel capability.

Not sure I've heard of any spyware/malware depending on just that cancel capability.

That uses a different manifest permission.

https://developer.chrome.com/blog/crx-scripting-api#breaking...

That's remotely hosted code...also a problem, but you can inject code that's not remotely hosted.

The point is that it’s a different permission.

https://news.ycombinator.com/item?id=41812416

If you are really privacy conscientious, ad blocking extensions should be able to exist without any access to web requests now.

I feel like we're losing the plot here. Removing the cancel capability of onBeforeRequest didn't improve security much. It did, though, hobble ad blockers to just dealing with static lists if they want to prevent an ad from downloading in the first place.

Removing the onBeforeRequest redirect didn't add much security either, since you can just ask for permission B instead of permission A and just inject code. Though, ad blockers don't need that anyway.

It’s insane to think that an extension with the ability to snoop on all your requests is more privacy oriented than one that can’t.

It’s insane to want extensions to snoop on all your requests in an attempt at more privacy.

Well, I would allow it for one specific extension that I feel does more good than harm for the capability. Call me insane.

It only sounds insane because you're saying "want extensions to snoop" to describe "want extensions to run a function call locally".

It is a permission that could be used by a malicious extension to snoop, but that is far from the only use. Wanting the permission != wanting snooping.

I made a plugin for scraping using onBeforeRequest. It's very useful.

Reply on news.ycombinator.com