Hacker News Reader

Comment by whstl | Hacker News Reader

From the blog post linked in the article:

> While other browser vendors introduced declarativeNetRequest (DNR) in favor of blocking Web Request in MV3, Firefox MV3 continues to support blocking Web Request and will support a compatible version of DNR in the future. We believe blocking Web Request is more flexible than DNR, thus allowing for more creative use cases in content blockers and other privacy and security extensions. However, DNR also has important performance and compatibility characteristics we want to support.

https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signi...

So, in a nutshell, they won't deprecate an existing working API, like Google did. But they will additionally support the new API.

View on HN

The current API is a security hole.

But that's fine. "It's incumbent on end-users to know what they're installing" is a fine position for Mozilla to take.

I can't tell if you're being sincere or sarcastic. Allowing users to install whatever they want at their own risk is exactly what people complaining about walled gardens not allowing them to do. Attempting to protect people that don't know what they are doing from known security holes is what one of the things walled gardens claim as a feature.

Which direction are taking it?

That’s hardly the only option. Walled guardians that only protect against counterfeits or viruses is a perfectly useful feature even if they allow anyone on the platform.

Except that not being able to block all ads potentially containing viruses makes THAT walled garden unsafe by design.

In what way would the walled garden I described not be able to block adds?

When that walled garden relies on 3rd-party tools and does not give them enough power to do their job well.

You are clearly assuming things that have nothing to do with what I described.

The owner of a walled garden doesn’t need to depend on 3rd parties for anything they can build whatever tools they want in house.

Right, I am talking about Chrome. You seem to be talking about something else.

If you’re going to ignore what people say there’s little point in hitting that reply button.

It's quite clear from the comment that 'shadowgovt supports Mozilla being a non-walled garden, which is the reason Firefox exists. No one needs a Chrome clone.

Being forced to see and potentially click on ads is a security hole. I trust uBlock and gorhill more than I trust Google.

This is what prompted me to start blocking ads many years ago…there’s simply too much malicious advertising out there and the corporations involved have the wrong incentives to deal with it properly.

As long as ad networks allow arbitrary code to run, and content designed to trick users, I prefer to centralize on a single source of potential risk (the extension developer) rather than the moving target of malicious ads from myriad sources.

A recent example readily avoided by not allowing the ad to run in the first place: https://www.securityweek.com/webkit-zero-day-vulnerability-e...

*"uBlock Origin" .

"uBlock" stole the new from gorhill.

All chrome did was prevent extensions from blocking requests. They can still see all requests and do with them what they want, just read-only.

How does that solve the security issue you mentioned?

The security hole is in the guarantees the app store is able to make.

webRequest API, because it runs arbitrary JS, could do anything including something malicious by modifying external JS after the extension was submitted to the store. It's an API that makes it impossible for a store to make security guarantees at all.

This is, unfortunately, the behavior ad blockers rely upon to keep their databases of malicious actors fresh.

That's not really true. Block lists can be updated via the store. The security hole is that the app might maliciously modify the content of the pages you are viewing. It doesn't need to make requests if can tell your page to send your requests to a different server.

The declarative API solves that by not allowing page modification outside of safety boundaries like deleting elements.

Another way to solve it would have been to define a "blocking" webRequestFilter function of the form "Request -> Bool", because ad blockers only care about preventing requests, not actually executing requests or modifying results.

Come again? Here’s an example with declarativeNetRequest that modifies requests:

https://stackoverflow.com/questions/3274144/can-i-modify-out...

Saying that manifest v3 is about security is really not credible. Maybe the changes look like security, but the details are simply not consistent with security being the primary goal.

Am I missing something? It's my understanding that chromium based browsers also allow listening to requests same as before, they merely aren't allowed to block them anymore.

The set of responses to a request is also constrained to a non-Turing-complete declarative language.

Turing-complete and declarative are not the important parts. Ability to read content and perform side effects matter.

That's not in the featured article, so why isn't a more informative article linked instead?

It was a blogpost linked in the article. My wording wasn't correct. I edited it to clarify.

As for your question, that's a legitimate request. Maybe dang can change the link?

We've switched the URL to that post now - more at https://news.ycombinator.com/item?id=34851026. Thanks!

Edit: nope, reverted. See https://news.ycombinator.com/item?id=34851017.

Reply on news.ycombinator.com