Hacker News Reader

Comment by TrianguloY | Hacker News Reader

And how did Firefox solved it? I only found it mentioning that Firefox will continue to support V2, but that's not a solution.

View on HN

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.

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?

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.

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.

It's explained here

https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...

And here

https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...

Firefox kept support for Event Pages which get direct access to DOM and WebAPIs in the background as well as Web Requests, both of which are not available via Chrome's use of service workers/restricted request API

> “One of the most controversial changes of Chrome’s MV3 approach is the removal of blocking WebRequest, which provides a level of power and flexibility that is critical to enabling advanced privacy and content blocking features. Unfortunately, that power has also been used to harm users in a variety of ways Chrome’s solution in MV3 was to define a more narrowly scoped API (declarativeNetRequest) as a replacement. However, this will limit the capabilities of certain types of privacy extensions without adequate replacement.

> Mozilla will maintain support for blocking WebRequest in MV3. To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest. We will continue to work with content blockers and other key consumers of this API to identify current and future alternatives where appropriate. Content blocking is one of the most important use cases for extensions, and we are committed to ensuring that Firefox users have access to the best privacy tools available.”

I hope FF gets service workers going soon, I haven't followed development closely so I'm not sure what's holding them back besides not wanting to replace Event Pages entirely with it [1]. I tried to build a (non-complicated) extension recently and the service worker API seemed cleaner and modern.

1 https://github.com/w3c/webextensions/issues/72

> I hope FF gets service workers going soon

As of October 2022, that’s “not planned”:

https://github.com/mozilla/web-ext/issues/2532

Yeah seems like they want to stick with one approach rather than supporting both EventPages and service workers at once.

> Firefox will continue to support V2, but that's not a solution

That is the solution, it's just not the solution we're allowed to have.

they're supporting manifest v3 fully, but not removing the thing that breaks the better content filtering.

Reply on news.ycombinator.com