Mozilla solves the Manifest V3 puzzle to save ad blockers | Hacker News Reader

Mozilla solves the Manifest V3 puzzle to save ad blockers

adguard.com

343 pointsVinnl134 comments

A bit off topic but, but as a person who develops an extension and browser, another puzzle we need to solve is how to control and transparently log what these extensions are doing with your data.

Cookie, storage, exported DOM reads, fetch requests, etc should all be logged in clear text (maybe even pass handlers that pull reduced data) for the user to audit.

It blows my mind what any developer can do with extension apis. "This site can access data on this site" warning is not enough.

The truth is Manifest V3 is a step in the right direction in that regard. It forces extensions to declare what they want done so the browser can do it directly without exposing user data. This is the right choice for 99% of extensions out there.

It's just that uBlock Origin is so important and trusted that it should be an exception. There should be no limits on uBlock Origin at all. It's so important that it should just be turned into an actual built-in browser feature, and the only reason it isn't is the massive conflicts of interests involved since all major browsers are backed by adtech profits.

Really? Last time I read the spec (which was a while ago), v3 disallowed unrestricted blocking, but it had no corresponding restrictions on sniffing requests and responses and maybe even on modifying requests. So it had no actual security benefit — it just nerfed ad blockers.

The security benefit is preventing unrestricted ability for extensions to modify requests. So much malware is delivered via extension these days, and it's dead simple (and even a relatively common occurence) for a popular extension to get bought by unscrupolous actors that immediately commit changes that would be blocked by v3.

GP said "step in the right direction", as this is indeed just a step and not an entire solution.

If a clever malicious extension can’t inject malware using non-blocking webRequest, I’ll eat my hat. For that matter, injecting malware using declarativeNetRequest doesn’t look particularly hard. I find it very hard to believe that the restriction on, specifically, blocking webRequest is genuinely motivated by security.

If Chrome really wanted a minimal change here to improve security, they might have restricted webRequest to only permit blocking the request but not modifying it.

If you prevent modifying completely, that would break large swatches of all extensions. I would imagine manifest will eventually move there, but moving straight to the end goal would have created a lot more outrage (rightly so).

Again, since you seem to have ignored the main point of GP and my reply, this was the "first step" in the right direction.

> It's just that uBlock Origin is so important and trusted that it should be an exception.

And what about new extensions that are not yet as popular but could reach the same level of importance and trust if it wasn't for restrictions like these making them impossible in the first place.

What about extensions that serve a niche but are nevertheless trusted and important within that niche.

I don't want my browser to dictate what extensions I choose to install can do anymore than I want my OS to dictate what programs I can install.

I'm not even opposed to making a curated experience the default but there MUST be a way to opt out so that technically inclined people can retain their computing freedom.

isn't that basically what brave did?

They are also replacing some with their own ads to promote their tokens iirc. Sounds like a cool concept in theory, but at this point I'm done with internet ads. There will be no third party ads served to me on websites, period. uBlock Origin does this quite well, and having it on Android too is a blessing.

'There will be no third party ads served to me on websites, period.'

Amen to that. I refuse to be sold to in any form possible. Partly the reason I won't switch to IOS. I'm too married to kiwi browser and it's ability to support ublock.

FYI you can use actual uBlock Origin on Android by using Firefox.

I have both Firefox and kiwi running. Ff works most of the time.

Brave blocks ads, then introduces their own... There's a conflict of interest, especially as free services rely on ads to be free.

And then some. Brave is a polarizing project.

I refuse anything or anyone involved with crypto.

That's nice, ignorance is bliss after all.

Do you have the same requirements for normal standalone applications?

Malicious extensions will defeat the logging by injecting scripts into the dom.

The important information referenced in the current article by AdGuard is in this link by Mozilla:

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

Posting it here since there's a lot of questions being asked here in HN that are answered by the post.

Ok, we've switched to that URL from https://adguard.com/en/blog/firefox-manifestv3-chrome-adbloc.... Thanks!

I guess we'll keep that article's title though (in de-baited form) because "Manifest v3 signing available November 21 on Firefox Nightly" would trigger weird responses.

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

AdGuard article contains this :

Acknowledging these apprehensions, Mozilla announced last year that Firefox would continue to support the webRequest API to block entire categories of HTTP requests in its implementation of Manifest V3...

And, per AdGuard, is now shipping that.

So what did Mozilla actually do here? The blog post never gets to the point.

Yeah, I read the post eager to see what AdGuard's thoughts were after building their MV3-based blocker, but the article never actually goes anywhere. It's just repeating Mozilla's stance from at least a year ago.

I tested both AdGuard and uBlock Origin in MV3 for a while, and they seemed fine to me. Adguard's had less friction due to opting sites into cosmetic filtering by default.

We've changed the URL from https://adguard.com/en/blog/firefox-manifestv3-chrome-adbloc... to the older blog post suggested by https://news.ycombinator.com/item?id=34850531 and https://news.ycombinator.com/item?id=34850753.

Does that help?

Edit, ok we'll revert it. Sorry all!

No? The submission was for a blog post from 2 days ago by AdGuard, and now you've made it into a blog post by Mozilla from last year. That's a pretty extreme change. The Mozilla blog post gives some background, so why not just post that link instead of changing the whole submission?

This was a mistake, dang. Not to mention it doesn't have (2022). Which it didn't need, before you changed the link.

The AdGuard blog post has details that the Mozilla post doesn't, such as a specific discussion about ad blocking, as well as recent developments in Chrome's deprecation timeline.

I've seen some pretty weird submission alterations recently, not sure what's purpose of that. I know there's tendency to have information linked to as close to original source as possible but it's just complete miss sometimes

We haven't changed anything about how we edit titles or URLs—all these practices have been stable for many years. So if you've noticed weirder changes lately, it must just be luck of the draw.

I obviously got this change wrong since people hated it so much - but no one much liked the original URL either (e.g. https://news.ycombinator.com/item?id=34850937). If there's a better article, we can change it again.

> If there's a better article, we can change it again.

There's not a better article. I think people are mainly confused by the title of the article.

There are 2 different links to mozilla.org with background info in the first 3 sentences of the article, so it seems like people just aren't clicking those links.

To me, it's clear that the intention of the article is primarily to criticize Google and Chrome, with a contrast to the behavior of Mozilla and Firefox. Which is why the title can be a bit confusing, and people are expecting a long explanation of what Firefox did, when the point is really that Google could and ought to do better.

Much worse dang. The original article wasn't bad; it just glossed over the details. But has a lot on the background and the migration to V3, so another vote to revert to the original submission.

Reverted now. Sorry!

Having read both -- no, it did not help.

Read Moz first - very confusing how signing saved ad blocking.

Sorry! I switched it back.

There are not many places on the internet where you can read the mods apologizing and backtracking on their decisions. Thanks!

It's worse

No, I was very confused why the link was going to an old blog post by mozilla until I read the comments.

This is a terrible change.

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

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.

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.

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.

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.

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.

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.

Also why on Firefox Mobile, do you still have to enable developer mode AND create add-on collections to be able to install the add-ons you need? It's just a pain to have to do that every time you install Firefox. It's been possible for maybe 2 years on Nightly.

How often do you install Firefox?

I don't care. I'm not going to create an account on some website just to install addons on my OWN browser. Period.

Firefox will continue to bleed users like me who don't know how to dance this stupid dance or refuse to do so until it completely collapses. I wonder why mozilla chose this hill in particular to die on.

Not very often but it's an annoyance and I always forget how to do it when the time comes, so I have to web search it.

FYI Android Firefox, since version 68, only allows installation of addons that are on a certain whitelist. For custom extensions, they require you to register on addons.mozilla.org, even if you just want to install an extension you wrote yourself.

Yes? Nothing to do with manifest v3?

Also, better than any other browser on Android.

Chrome allows no addons.

Samsung internet and Edge only has Adblock Plus.

Brave, Opera and Vivaldi has its own built-in adblockers.

There is Kiwi browser and Bromite but those where way behind on Chromium versions last I checked.

On android and IOS I would use Brave and/or Firefox.

saying Firefox is "better than any other browser on Android" might be true, but it still doesn't make a forced whitelist acceptable. Users should be able to accept the risk and install untrusted addons with a warning. Again, if its an addon that I wrote myself, I should not need Mozilla's approval to install that on my own device.

It would be even better if they wouldn't force unnecessary and unremovable "Extensions" button on toolbar.

uBlock Origin Lite has been a good solution this far. It might not be as robust as uBlock Origin, but I fear less for the future that it’s here.

If you don't mind the drastically reduced feature set[1].

It works if you were using nothing but default settings but if you want custom filters or anything else that's not included in the bundled filter list then you are SOL.

[1] https://www.reddit.com/r/uBlockOrigin/comments/1067als/eli5_...

How does Manifest v3 compare to Safari content blocker API in terms of ad blocking capability? Currently AdGuard for Safari (from Mac App Store, the one that uses native content blocking API) has 7 content blockers categories you have to enable, and each of them allow 150k rules, amounting to over a million rules total although you can’t count it like that really. V3’s 30k per extension and 330k total sounds like a lot less.

Is there something more to it than just the amount of rules, is v3 still better than Safari?

Just bring back XUL based extensions. I miss how customizable firefox was during those days.

I don’t disagree that XUL was great for it’s time, but this offers some interesting perspective on the reasons for its demise: https://news.ycombinator.com/item?id=24231017

There are many forks for that, not a problem.

> Unfortunately, Google has made many decisions about the design of its new platform without taking into account the wishes and concerns of extension developers and, in the end, their own users. As a result, ad blocking extensions will lose some of their functionality.

Basically the same thing that happened to Firefox extensions when they abandoned the entire old ecosystem and switched to Chrome's webextension. And now that they're stuck with that choice they're happy about mitigating even more damage to add-ons caused by it. This is not so much a win as a holding action after a bad choice.

The idea of a well-defined extensions interface is not a bad idea. In fact, it's a very good idea. For as much power the old, everything-goes extensions model gave you, it also meaningfully prevented Firefox from evolving for years. Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Yeah, and it was that way because Mozilla couldn't change a damn thing without half of the entire extensions ecosystem imploding with every release. You need a well-defined API if you want to have any hope of improving the browser without breaking the whole world every week. Chrome had such an API, and it was popular, so Firefox lifted it. That's not nefarious, that's just smart. I'm happy that they managed to pull it off, and I'm happy that alternative browsers continue to exist in order to resist Google's death grip on the web.

> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"?

Except it wasn't. I used Firefox a lot on Windows and Linux and didn't have the slightest problems.

The only reason I see why Chrome took over was a rather insane push, about the same level of intensity as IE6, from Google, using everything:

- artificially reducing performance of Firefox on key Google properties (Google Calendar, YouTube)

- bundling Chrome with Adobe

- ad campaigns on the front of Google where no one else has been allowed to serve ads (this alone must have been worth billions)

- lies ("switch to a better browser" they wrote even when I was using Firefox)

Google needs to be punished - big time - for this abuse.

Firefox was slower than other browsers at the time. A lot slower, and buggier. There are plenty of benchmarks. I’m a Firefox user now, but before Quantum I didn’t touch it because it really was terribly dated.

We might have different usage patterns.

I regularly ran it with multiple extensions and 400 - 600 open tabs and didn't feel Chrome was better.

And I'm the kind of person who can start a 2 hour troubleshooting session over a few tens of milliseconds unexpected lag.

Edit: maybe Chrome was hopeless with multiple tabs or maybe one of the older memory saver extensions was so much better it made up for it, or maybe it just matched my hardware/SW at the time extremely well (high end HP laptops with Windows or Linux), or maybe it was just a feeling, I don't know. But I know I spent a significant part of my work day in the browsers and Firefox felt significantly better even when I wanted to try the then new and cool Chrome.

Edit 2, since I see this thread still has activity:

I should point out that by "better" I don't mean that Firefox was necessarily faster but

- it was equally fast (for my usage),

- handled 400-600 tabs effortlessly even back then

- had a number of great extensions and themes that significantly improved ones life (subscribe to pages that didn't offer any feeds? I had an extension that polled pages at configurable intervals and ran a smart diff checker on it that gave me a notice if some change had crossed a configurable threshold. Need access to docs while offline or just tired of spending your data quota or waiting for the train ro exit the tunnel? There was an extension that let me download pages recursively, configurable with domain, path and how many steps. It would deduplicate the downloaded pages and rewrite all links from absolute to relative and it "just worked" for everything I needed it for.)

By comparison, extensions in old Firefox was Hitachi or Milwaukee and new extensions are somewhere between Fisher Price and Black and Decker. Yes, you could absolutely hurt yourself on the old ones, they were tools, not toys.)

> plenty of benchmarks

What kind of benchmarks? Microbenchmarks that test specific JIT capabilities or something that better represents the average user experience.

I've been a consistent Firefox user since the days of 3.5, and only Firefox at that. Before Quantum it was noticeably slower than the competition; even Internet Explorer, let alone the people I saw using Chrome on comparable hardware.

I am a Firefox user NOW, but before Quantum it WAS dog slow compared to Chrome.

They keep doing it: https://twitter.com/dmitriid/status/1625756307297914883

>Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"?

The only part I remember where Firefox was notably slower was videos when Google led Firefox for a ring around the rosie when they singlehandedly decided to use a proprietary codec for their youtube videoplayer after first making everyone believe they were working on using a different one which FF started working on supporting. I can't count the amount of complaints i heard of firefox being slow there.

Is this when you had to make sure you were brute forcing the HTML5-based playback?

> The idea of a well-defined extensions interface is not a bad idea.

when I am forced to register on addons.mozilla.org, just to install an extension that I wrote, yes, that is a bad idea.

Give users the option to say "yes, I understand that this is not an 'approved' addon. install it anyway"

> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Yeah, and it was that way because Mozilla couldn't change a damn thing without half of the entire extensions ecosystem imploding with every release.

This is misleading. Like wildly so. The imprimatur that the Firefox team was working under meant that they absolutely could, and very often did, break things from release-to-release.

The long, slow decline related to slowness at the core of Firefox had very little to do with extensions (the unwillingness to break them, that is). The real reason is that the work needed for what was eventually delivered in the overhaul that made XUL obsolete was work of the sort that takes a long time to complete. If anyone had stumbled upon working patchsets for those goals stuff through divine revelation and had the ability to say so, then they would have broken things sooner.

If anything, keeping XUL extensions around while all this work was being done helped prop up Firefox's user numbers for a while longer. (Compare to if XUL, while still technically viable, had been killed 10 years ago with a feature flag by fiat and then multiprocess, parallel rendering, and other deliverables related to Gecko Rustification were still as many years away as they actually were.)

If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of addons in FF didn't feel too aggressive, but then again I'm not in the clique with dozens of open windows. There were times of fast/slowness in FF. It was never bad enough to chase me off the platform, but to say the slow ess was simply saddled on addons is probably disingenuous.

It's not that the add-ons were slow, it's that the architecture built to support those add-ons made the browser as a whole inherently slow. Everything was quite siloed, and required a series of dynamic dispatches to accomplish anything. This allowed extensions to easily change lots of core functionality, but also meant that the entire Firefox codebase had become a public API, and practically any change made would break something.

The slowness wasn't caused (just) by slow addons. As I remember it, Firefox was unable to move to a multi-process architecture as long as old extensions were supported.

My recollection was that they had some multi-process things, though the problem was that they had to keep breaking extensions as they added more and more. I believe multi-process NPAPI plugins was somewhere around 3.6 or 4? (Of course, 4 took forever to ship too… that was great for extensions though, because it meant no API breakage during that time.)

It's not that the addons were slow. It's that the architecture in Firefox that was needed to support the addons was slow - even if there were no addons in use.

> This is not so much a win as a holding action after a bad choice.

That choice was made over 7 years ago. It may or may not have been a bad choice, but at this point Firefox is well beyond the "mitigation" phase of its previous add-on API migration.

As an extension developer myself, I was happy that Chrome, Firefox, and Safari all had similar implementations with Manifest V2. Now it's in a very awkward phase again.

> Now it's in a very awkward phase again.

Only because we allowed a single browser engine to become a quasi-monopoly again. Google doesn't need to adhere to addon standards, Google sets them.

> It may or may not have been a bad choice

It was a necessary choice, the previous framework for extensions was not multiprocess-compatible.

you can not have both competition in the browser market, and every browser being the exact same all the time...

I prefer less monopoly and more competition

> you can not have both competition in the browser market, and every browser being the exact same all the time...

Are you claiming that there can't be such a thing as web standards? HTML?

Why would an extension standard be any different from an HTML standard?

Web standards should specify the semantics of HTML, CSS, etc, not dictate how exactly the browser operates. Limiting extensibility of all browsers just because there is some webextensions standard is ridiculous. Similarly, browsers should be able to ignore user-hostile parts of specs like the HSTS spec trying to dictate that users cannot override the certificate validitation.

In fact, even how websites are rendered should ultimately be up to how the user has configured his browser even if some spec says otherwise. This includes being able to install effective ad blockers that remove elements and deny requests that should be there according to the standard.

Think of web standards more as the definition of a common language between websites and browsers and not as a rulebook for either.

Manifest v3 didn't kill ah blockers. It just got rid of the webRequestBlocking API and replaced it with declarativeNetRequest. This mean you don't have to give ad blockers permission to see all of the requests you are making. Ad blockers can still dynamically create rules for what requests they want to block.

I want to give my ad blocker permission to see my requests. I trust gorhill implicitly, moreover the code to ubo open source.

Ad blocking is a cat and mouse game. Google, a mouse, is trying to cripple the cat enough that they can squeak all of their ads through.

It is a fucked up situation when the attacker, i.e. Google, who does record everybody's history, is trying to convince us that our security will be enhanced if they stop allowing us to run our security software on our own devices. And that the open source security software is actually the attacker, with no evidence of that assertion whatsoever! The word "gaslighting" is thrown around frequently but what Google is doing here comes close to that.

Google knows that crippling ad blockers will result in more privacy violation, but they keep pushing this lie that ublock is dangerous and anti-privacy because they want to line their pockets.

>I trust gorhill implicitly

Your comment made me take a closer look at what Raymond does and his twitter wasn't a positive surprise, it's full of political propaganda a lot of it anti-US and pro Putin/CCP. For example he shares Caitlin Johnstone tweets, which is a pro China account that might be known to people who follow what goes on in the sinosphere. Doesn't say anything about his code of course, but it's also not a sign to me this person should be trusted unconditionally. In general, there should be as little trust as possible. I expect my browser to ideally restrict extensions maximally and only give the permissions I explicitely agree to. The goes for open source code as well, there can always be a bug or exploit that hasn't been found yet.

https://nitter.namazso.eu/gorhill

Being anti-US (government) is a pretty reasonable stance considering known past transgressions. Since when is questioning the popular (western) narrative automatically propaganda? I can't really be bothered to look trough all the tweets to guess what you consider to be pro Putin/CCP but distrusting someone for sharing specific tweets from someone associated with Putin/CCP is too close to guilt by association territory for me.

In the end, almost everyone has opionions on politics. I'd wager that many more peole have opinions that you consider problematic than you realize - most just keep them to themselves. I don't think mistrusting those who are open about their views more than those that hidem them is a good policy.

In the end, gorhill is not trusted because of things he has said but because of his actions including retaking ownership of uBlock (now origin) after the new maintainers went against his ideals even thoug he originally did not want that burden. Do you have any actual reason to question gorhill's integrity or are you just spreading literal FUD?

Now as for Mozilla (and even moreso Google), they have shown their willingness to go against user wishes with telemetry, in-browser ads and experiments. Why would you trust them implicitly but find the idea of giving select extensions that same trust unthinkable? See, the problem here is not that browsers allow you to restrict what extensions can do but that browsers enforce certain restrictions and don't allow users to override them.

I do think it would be good if extensions were more commonly distributed (and hopefully checked) by (e.g. Linux distro) package maintainers rather than FF having its own developer-controlled update mechanism. But ultimately you do have to trust someone and the guy who has been dedicated to making the web usable without selling out so far is not a bad candidate.

They did just kill bypass-paywalls-clean though. On desktop you can sideload it but on mobile you can't. They're not in my good books for a while.

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

The add-on got DMCA claimed. Until the creator counter claims, they have to take it down.

As horrible as the DMCA is, it does not mean that Mozilla or any other hoster has to honor any claim anyone thinks up. If they are confident that a claim is frivolous they can just tell the submitter to fuck off. It does mean that they take on some liability of the claim turns out to be valid but again, they can determine that themselves and there isn't any abosolute safety from having to defend yourself against invalid legal claims in either case. Mozilla trying to benefit from extension creators (which provide immense value to the browser) while trying to offload all legal risk to the little guy is not exactly making me more confident that they are all that interested in protecting the open internet.

Now I haven't seen this claim specifically (has Mozilla posted it publicly?) but I doub the extension is actually infringing anyones copyright and this is instead about providing a way to circumvent coyright protections. AFAIK DMCA circumvention is not grounds for a DMCA complaint, which are for direct infringement of the claimants "IP" only.

What's even the point of disabling Manifest v2 in Firefox? Is there something wrong with it or that significantly different that Firefox can't support aspects of both v2 and v3? Having just made a Manifest v3 extension for Chrome, I don't really see how it's so wildly different that Firefox would have to do that much to support it. What am I missing?

The world of software sure is good at "fixing" things that aren't broke.

Also, this article doesn't seem to make it clear what Firefox is doing to "save" ad blockers other than continue to support Manifest v2. If they're making ad blocking possible with v3, there doesn't seem to be a lot of detail around it. Yes, I can go research it, but the point of articles like these should be to aggregate that information so people don't have to do all the work for themselves.

The problem is that Google removed a very important API that is crucial for ad blockers. They did that change along with the update to Manifest V3. Mozilla is trying to do the right thing by implementing Manifest V3 without the problem introduced by Google. It will "save" ad-blockers by not removing a specific API that is important for them.

Firefox will keep supporting both V2 and V3. They want to implement V3 in order to avoid forcing most developers to have different manifests for different browsers. This is a good thing in general.

If you want details on what Mozilla is doing, here's a snippet from the linked blog post:

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

Your answer is hiding in your comment. You wrote a Manifest v3 extension instead of a v2. If Firefox, an underdog, wants to maintain compatibility, they're going to have to adopt v3. However, they don't want to adopt v3 with the blocking choices Google has made. So they had to do this, unless they wanted Firefox to fade into further irrelevance through extension developers refusing to support it.

Also, technically, Firefox is supporting both 2 and 3, their solution here isn't magical wizardry. It's just maintaining those specific features (blocking Web Requests) on top of adopting 3.

Chrome has a hard wall around some features like chrome.scripting and promised APIs (MV3-only) but Firefox doesn’t.

It seems that Firefox is keeping around the same MV2 APIs so Firefox extensions will eventually be able to update the MV number with no effort.

> Also, this article doesn't seem to make it clear what Firefox is doing to "save" ad blockers other than continue to support Manifest v2.

Yeah, that's a misleading title; the authors explain why extension-writers are going to switch to the "common platform", which will be V3, whatever Mozilla (or AdGuard) do.

I was looking for an account of some cool Judo move that Mozilla had pulled off, to draw the teeth of V3. That's not what it's about.

Basically they had to rewrite everything just to get the same functionality? What a giant waste of everyone’s time… which is probably one of bigCo goals: keep churning, so that people with less bandwidth are forced to deal with churn instead of improving their product.

That wasn’t the intention obviously. You may call it shortsighted, but they certainly wanted to kill the old platform and start fresh. Only now we know that wasn’t as easy.

In reality we should be thankful that it hasn’t happened (yet) rather than bashing the choice to keep MV2 around longer. They could very easily pull the trigger, I don’t think many will actually switch to Firefox just for that. Most won’t even know.

As a product manager, I don’t know what they’re waiting for exactly.

I mean... Valid criticism in many ways. But also not something that is unique to the big companies. Or computers, for that matter.

And there is a chance we can take learnings from the last attempt and improve in them.

Reply on news.ycombinator.com