Hacker News Reader

Comment by tyingq | Hacker News Reader

Static list of uris versus live heuristics. So "much of a difference" depends a lot on what you browse. If your browsing is covered by the static list, yes...there's little difference.

Also, keep in mind advertisers are not unaware of all this movement. You don't think they'll try new tactics once they know everyone using chrome is now hobbled to solely static lists? That cloaking (or other approaches) won't then become really popular?

View on HN

A lot of other ad blockers use static lists for years. The fact that they work tells that ad industry does not see the blockers as a problem that needs to be dealt with. It can also be that so far the increased cost of development of ads that are immune to simple static lists is not worth it.

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.

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.

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.

I’ve noticed a huge number of websites have interstitials pop up asking you to remove your ad blocker. While some let you bypass it anyway some don’t. Clearly the websites themselves seem to care.

Reply on news.ycombinator.com