The article is claiming that lists won't be able to self-update at all. That goes far beyond a ban on remote JS.

> cosmetic filters updates do not require an extension update

Cosmetic meaning what exactly?

> remote JS was never allowed in Mozilla Addons store

I don't see any issues with ublock in firefox, so what's going on there?

> A little bit more research and one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

That sounds like something that can and will randomly stop approving ad blocker updates more than once.

> Cosmetic meaning what exactly?

Filter lists are composed of two types of rules: “cosmetic” and “network”. Network rules define what needs to be done with web requests (block or redirect). In MV3 these rules should now be implemented via new declarative API.

Cosmetic rules is a very wide subset of ad blocking rules that define how a web page needs to be changed. These are implemented the old way.

> I don't see any issues with ublock in firefox, so what's going on there?

uBlock Origin does not use remote JS so yeah, what’s going on with the article is a good question.

The article’s claim is factually incorrect, self-update will also still be possible to implement even without the fast track. It will be more complicated than it is now as we’ll need to do that via differential updates, but nevertheless.

> one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

My understanding is that no-review-fast-track is only for extensions which changes in DNR rulesets are only about block/allow/allowAllRequests rules.

I don't see how comprehensive content blockers can push meaningful updates with only changes to block/allow/allowAllRequests rules and nothing else.

It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. One more approach (a bit “hacky”) is to distribute cosmetic rules inside static rulesets (hide them in a separate “metadata” field).

I personally like the fast track idea as we can use the CWS infra to distribute updates quickly, but this is not the only way.

Differential updates are also possible and if they’re implemented, you can keep a normal release cycle (6 weeks for instance).

> It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”.

It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc.

If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place?

There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API.

This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.

The “safe rules” concept is a little strange indeed, not very consistent.

I actually agree that for an MV3 ad blocker I’d better have a fully declarative default (emphasis on default), but I’d like to provide an option to grant more permissions and allow more rules. I’ll wait until declarative cosmetic rules become a thing before going this way though.

What I don’t like about your way is that it’s very difficult to use the MV3 version for filters development, filter list authors will have to re-build the extension every time they make any change to the underlying filters.

Maybe this is not a big problem though, we’ll only see it when MV3 becomes the only option and there will be more issue reports from its users.

> If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

While they solve similar problems, these are different systems with different constraints.

* In order to allow something through the review process without close examination, you need to be sure it will not compromise end users. The block, allow, and allowAllRequests actions are known to present minimal risk to user's web browsing activities. The same cannot be said for redirecting requests or modifying a request's headers.

* Dynamic rule registration logic can be statically analyzed for risk assessment purposes. For example, say you're looking at two extensions that both have dynamic rules. Extension A only dynamically register block rules based on remote configuration. Extension B has <all_urls> and passed an arbitrary JSON object to the updateDynamicRules call. Personally, I'd be very concerned about what Extension B could do at the developer's behest, whether intentionally or if the dev's servers are compromised. IMO Extension B may even cross the line on what store policy permits.

* Expectations for extension's static content are different from an extension's dynamic operations. If an extension has code that explicitly does something nefarious and that passes review, the review process will be raked over the coals by commentators. If an extension's static contents are benign but a developer makes it do something nefarious at runtime, there is more understanding that this behavior may not have been visible to reviewers during the review process.

I'm sure there are more differences worth mentioning, but I need to run.

As a final parting thought, if safe rules and fast track review were already implemented and dynamic rules were being proposed today, I expect we'd be having conversations about whether or not devs should be able to register unsafe dynamic rules. I think there's a realistic possibility that we wouldn't allow it. Or if we did, that this capability would be gated by a new permission with a warning.

This is the first time I've really looked into Manifest V3, and I'm confused as to how the "no remote JS" restriction is enforced.

What prevents a developer from using non-remote JS (code built into the extension) to tell the current web page to fetch remote JS from a server, and execute that? Obviously, web pages must be able to fetch remote JS, or the whole internet would break.

Google could delist such an extension from the Chrome Web Store. But Chrome (unlike Firefox, grr!) allows extension sideloading, so if I was UBlock Origin I would just say screw the Web Store, download from our website.

And then, once UBlock Origin can inject an unlimited amount of turing-complete Javascript onto the page, the sky is basically the limit... right?

If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla.

Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.

Yes, but Chrome allows users to sideload extensions.

Getting non-technical users used to regularly sideloading extensions sounds like a recipe for disaster in terms of security.

I'm also not sure if sideloaded extensions can receive automatic updates, but the much bigger problem is getting people used to sideloading unsigned extensions with full web site access: Tech support scammers will have a field day with that.

It wouldn't be good for security. But I fundamentally believe that user freedom—the ability to do what big tech would rather they did not, such as adblocking—fundamentally depends on sideloading. You simply can't have one without the other. You're trusting the vendor to decide which software is safe, but that vendor will inevitably also consider which software makes them money.

On platforms where sideloading is either impossible (iOS) or usual (Android), adblockers are completely inaffective. The gatekeepers simply don't allow them to exist. This is true even though the maker of iOS ostensibly (!) isn't ad supported.

> I'm also not sure if sideloaded extensions can receive automatic updates

They can't (at least without some external software), which is why the ability to load remote Javascript would be important. For less frequent updates, they could prompt the user.

There’s a legal avenue for this kind of thing too: pass laws that enforce clear and transparent rules around what the gatekeeper can do and give legal recourse to participants to hold said gatekeeper accountable if they break them.

But it's still like putting the coal companies in charge of the EPA. You can add laws and mandates to try to tie their hands, but they're going to push the boundaries as much as they possibly can.

You could have app approvals go through some truly public, government-run agency... except frankly I'd object to that too on free-speech grounds.

As a developer not only can I be trusted to not install extensions from unknown sources, but there’s a much easier vector via NPM :)

I'm not a developer, but I trust the author of ublock Origin a lot more than I trust Mozilla.

Mozilla routinely fails its users and spends a lot of money on downright bad ideas. They are a pinnacle of intransparency and most of their press releases are written in Newspeak, far worse than Google, ironically.

In this very thread we have a discussion about Mozilla putting the boot on its formerly open extension ecosystem.

So it is an odd idea that the manufacturer of the browser (Google, Apple, Microsoft, or Mozilla) should have a say in how much I can trust my content blocker.

The last group of stakeholders I would want involved in decisions about my content blocker is the ad-funded tech industry.

Ad blockers work fine on iOS. Yes, compared to ublock some things get through but not many. I have had good success with 1Blocker and AdGuard. Apple has allowed those apps for years.

I have 1Blocker and I find it does very little.

> I'm also not sure if sideloaded extensions can receive automatic updates

They can't update the entire extension automatically, but should be able to get updated blocklists no problem.

Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.

Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions.

I have used both browsers, and I find sideloading in Chrome to be completely painless. I use many sideloaded extensions in Chrome (mostly because I wanted to make small edits to existing extensions).

I guess I'm trying to figure out whether all this fuss is really a limitation of Manifest v3, or merely Chrome Web Store policy. If the latter, I don't see a problem as long as sideloading is possible, and I really hope UBlock Origin will just go that route.

Sideloading is the real freedom which everyone should rally around and protect. (I am extremely unhappy with Mozilla's approach to this, if you can't tell.)

The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform.

This remote JS stuff is a CWS policy.

So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction.

(I appreciate you answering my questions!)

JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.

Javascript is very powerful, but simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) that have already happened. An injected script is not guaranteed to run before the site's own scripts, I believe.

Other than that, you can probably really do everything you could do with the webRequest API, but the complexity of doing it essentially reduces to the halting problem: You'd have to statically analyze all Javascript loaded by the page and figure out if it's going to do any requests you don't want to happen and then rewrite these parts. Maybe there's clever things you could do by shimming all web APIs that can issue HTTP or other requests, but that also doesn't sound fun.

On the other hand, with an API that just gets to veto every outgoing request, you can trivially achieve the same goal.

Another area where in-page Javascript is limited compared to an extension is the same origin policy. A very fancy ad-blocking extension could e.g. run an image classification AI on third-party image resources and hide the ones that look like visually distracting, flashing etc. ads by default – in-page Javascript can't.

Thank you! I guess the main problem is figuring out which elements are ads. Blocking certain requests is a handy way to do that, at least for as long as external ad servers are the norm.

> Simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images)

But could you detect the request, see what element it loaded in, and then hide that element? Or is that much more complicated than I'm imagining?

If you only care about visual annoyances I believe that should generally be possible (although I also don't know the details!), but many people also use content filters to stop third-party tracking.

> Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions.

There is. But you must be running firefox on Linux, on specific distribution (i.e. Debian or Fedora), built by that distribution and the extension has to be installed system-wide by root. Then the signature won't be enforced.

So in a sense you're not running Firefox anymore, you're running a derivative from your distro which modified the source code. (I do appreciate that they do this, however.)

On Firefox for Android all extensions must be present in the AMO store at the time of installation, no sideloading - even of signed addons.

Mozilla banned non-store extensions in their last Firefox for Android overhaul a few years ago and afaik does not plan to allow them again.

This is the reason why the anti-paywall extensions are all gone/DMCAed.

It's a massive power shift away from the user. No idea why Mozilla did that.

How do you develop extensions then? Surely it must be possible somehow.

Not impossible, at all.

The answer is Firefox Nightly or Firefox Developer, you're freely to install unsigned addons in these editions.

> Not impossible, at all. The answer is Firefox Nightly or Firefox Developer, you're freely to install unsigned addons in these editions.

I do use Firefox for Android Nightly. How would I install an unsigned addon there?

I don't think it's possible. ... but if it were, this would be very useful to get the Anti-Paywall addons back.

It's called Sideload XPI, iirc Firefox Nightly allows you to sideload XPI if you enable Experimental by tapping Firefox logo in About 7 times.

But it's easier with Ice Raven or Smart Cookie Web Preview:

- https://old.reddit.com/r/browsers/comments/18ezd3g/iceraven_...

- https://github.com/CookieJarApps/SmartCookieWeb-Preview/rele...

Opera and MS Edge for Android don't support extensions as well. So my guess is, the Playstore rules won't allow it.

> Unsigned extensions can be installed in the Developer Edition, Nightly, and ESR versions of Firefox, after toggling the xpinstall. signatures. required preference in about:config

So I guess not in regular?

Exactly, not in regular, in those builds the xpinstall flag is ignored.

A lot of people recommend switching to Developer Edition to use unsigned extensions, but that's aligned to the Beta update channel. There's no way to get stable releases + unsigned extensions.

Whatever the security argument, I find this completely antithetical to user freedom, especially given that it's allowed in Chrome! I just can't believe that Mozilla is the one restricting their own users.

(It's also news to me that unsigned extensions can be enabled in ESR, I thought it was just Nightly and Developer. That's nice I guess.)

Agreed, it’s definitely not in line with their stated philosophy. Sadly, Mozilla has been drifting away from it more and more lately.

I used to run a homebrew'd extension to change my new tab page. Chrome makes it so annoying to use a sideloaded extension. Every time you start the browser, and every couple of hours when you open a new tab it will have a big popup warning you that an unsigned extension is running, and give you a big button to remove the extension that fires when you hit space or enter, and a tiny little subtext button to continue using the extension. After the 3rd time accidentally uninstalling the extension because I was typing in a search too quickly and not paying attention, I gave up on using it.

You must be able to turn this off, because I've been running many homebrewed extensions for years and never encountered these popups.

Huh, I've never seen this. Are you loading extensions via "load unpacked" (which is what I use) or some other method I'm unaware of?

Why are people so eager to look away from the clear agenda that's playing out?

It's not the time to be sticking one's head in the sand. Google is dead to me once they push Manifest v3.

My point is that reporting must be accurate and factually correct.

Google's showing their hand. You're here nitpicking. If something CAN be done, it usually WILL be done, especially if the actor is a business and the reward is power, influence, or profit.

Will you be one of the ones 'giving Google a chance' once they play their hand next year?

Because that agenda is hypothesis based on outsiders' observation of what Google is doing. It needs to be based on facts. Without facts, such an "agenda" is really just speculation and fear-mongering, not much better than the likes of Breitbart News.

Speculation like this is easy. I can also just speculate that the Ars has an agenda to slander Google. Expand that to a couple hundred words and you have an article. Now get people to read it and become angry. That's basically the sorry state of online journalism.

I have unsubscribed from Ars.

Can you name a single thing Google's done that's earned them trust?

I'm more of a technologist than a product guy so I care more about the technologies coming out of Google. When I see major open source efforts like tensorflow or k8s I see goodwill and trust. Outside the realm of software, when I see principles or ideas or algorithms like CoDel, BBR congestion control, and SPDY (later becoming HTTP/2) and even later QUIC, MASQUE, I see the same (please excuse me for listing networking technologies because that's where my recent interests are). Here's a very simple thought experiment: if all the above technologies came from a different company say Cloudflare would you consider these earning them trust? The answer is an unequivocal yes.

The only reason why you might be unable to name a single thing Google did to earn them trust is perhaps because of rampant brainwashing by the anti-Google rhetoric.