Because it's private. Because I don't want to register and maintain a Mozilla account. Because I can't trust my current network environment. Because I just don't want to deal with that code-signing shit[1]. Why should I even need an internet connection in order to run my own scripts in my browser.

Assuming private means malware or illegality isn't very creative.

[1]: I specifically listed the Windows version of Firefox because generally I have no problem with that procedure at all. But on Windows they even removed the about:config-flag to disable it. That's very rude.

Snark: because browser extensions only run on HTTP(S)-schema URLs, so you’ll at least need an active (maybe virtual) NIC with a loopback interface and a webserver listening on it, in order to see your extension running.

Reality: you don’t. You can still tell Firefox (or Chrome!) to trust a local extension in Group Policy, and it will. But only if your PC is actually bound to an AD domain, such that that GPO policy came from the AD controller rather than being something your computer created locally for itself. Because a virus can (get elevation and then) create a GPO policy to allow itself.

(You don’t technically need an Internet connection for setting up AD binding, because your AD controller can actually live on a VM that runs on the computer it’s managing. Crazy, but it works. People who pirate Windows may be familiar with a tool I won’t name here, that’s essentially a tiny wire-protocol-mimic of a VM running Windows running an AD controller running a Key Management Server.)

> But on Windows they even removed the about:config-flag to disable it. That's very rude.

It’s because Windows is where all the viruses that install malware extensions are. MacOS/Linux could run the malware extensions just as well — the extensions are just trying to [hijack your browser to] show ads/mine bitcoin/add Amazon affiliate IDs to things, and all that can be done in pure JS — but they can’t run the viruses that install them (and they’re uncommon-enough on networks to have low per-neighbour R0 even for viruses written specifically for them), so they’re somewhat protected.

It is frankly shocking to see such a hardcore authoritarian viewpoint here.

Things that steal your password, track your information, and show you ads. Y’know, BonziBuddy-esque things. Things that have a registered signature in an antivirus database, with nobody complaining about that.

Let me rephrase my initial statement to make it more clear: 99+% of the usage of the private extension install API — whether you choose to measure by volume of installations, or by variety of software installed — is by malware. Just like usage of the modern POTS phone system is 50+% by scam callers. Both because of the sheer quantity and variety of bad actors, and how automated and wide-reaching their attacks are; but also because of the dwindling valid use-cases, as most users’ needs have since been met by other technologies that meet those needs better.

In the POTS phone case, most people have switched to using email/texting/collab software/IP video-calling, which is why it feels like every ordinary phone call you receive is a spam/scam call. In the browser extension case, most people with more complex needs — e.g. the people who thought Chrome Apps were a good idea, the people who needed their extensions to have a native-library component, etc. — have switched to building standalone apps that have a browser embedded in them, where their “extension” can run un-sandboxed on your OS, not sandboxed within the browser. Y’know, Electron and the like.

(And moving your extension to Electron actually solves a great amount of the problem, because now your functionality itself is considered a base part of an “app” that can be independently quarantined by the OS, installation-constrained by MDM/GPO, sandboxed with a capabilities manifest to just what its use-case needs rather than what an entire browser needs, etc. IT admins love the shift from extensions to purpose-built Electron apps.)

> hardcore authoritarian

I have nothing against having control over your own system. For modern security, though, you truly have to have control over your own system — i.e. not let it control itself, but rather have two systems, where one follows the other’s whims via MDM.

The only truly-secure systems are ones where their choices are out of their own hands, and rather in some other system’s hands. Either interactively, via MDM; or non-interactively, via limited-capability ephemeral immutable-image infrastructure. Such systems have no entrypoint for a rootkit: in the immutable-image case, because the OS itself doesn’t have the physical capability to modify the boot volume (because it’s an NFS/iSCSI mount from a server that’s sharing it read-only; or because the OS kernel is a simplified unikernel that just doesn’t have “write to disk” as an implemented code path; or because it’s running as an instanced VM that disappears if it reboots.) And, in the MDM case, because there’s a chain of trust (signed BIOS → signed bootloader), where the bootloader will only boot a boot volume if that boot volume has been signed by the MDM controller; and where the keys for doing that aren’t on the device.

(If you like, instead of an additional MDM system, you could in theory have your boot-volume signing key held offline in a smart card/hardware wallet. No OS currently has the capability to use that offline signing key during the OS update flow, but it’d sure be neat if they started doing that.)

Is that authoritarian? In the same way as someone on a space station telling you not to open the airlock, perhaps.

As we move to a desktop world with strongly sandboxed processes (e.g. snap and flatpak), this argument will become less relevant, since it'll no longer be the case that dancingbunny.exe will run with the same credentials as the user himself and be able to plop an extension in a browser extension directory.

In a sandboxed-app world, local extensions will be much more likely to reflect the real intent of the user. I don't think we'll see a loosening of browser permissions though: basically every web browser maker feels that it ought to keep bad and desired extensions out of the hands of users.

> Besides — if your private extension isn't malware, why not just upload it to Mozilla's servers, but never set it to public, instead just personally being its only user?

Because extension-market web sites censor desired extensions that they think are bad. One example is Dissenter [1]. Another example is "bypass paywalls" [2]. Browser makers have blacklisted both extensions despite their not being malware and despite real human users actually wanting to use these extensions. Why? Because the people at major browser vendors just don't like these extensions. Browser makers should not have the power to censor other people's programs. Fundamentally, it's the user's computer, not Mozilla's or Google's.

[1] https://reclaimthenet.org/google-chrome-web-store-bans-disse...

[2] https://github.com/iamadamdev/bypass-paywalls-chrome

Have you ever uploaded an extension yourself? There’s more to these extension hosting portals than a public-facing website. There’s also an authenticated area for you to manage your own uploaded extensions, where extensions go through a set of states similar to a CMS: from “draft” to “private/unpublished”, to “private beta”, to “in review”, to “public.”

I’ll say that again: in even the Chrome Web Store, “private beta” comes before platform review. You can publish an extension for just yourself + a limited set of friends, give them the URL, and they can install it — without the platform owner ever even taking a glance at it. And they won’t in the future, either, because the behaviour of private-beta extensions just don’t matter to them. They can’t spread like public extensions — they have explicitly limited install-count caps — so it doesn’t even matter if they’re malware.

But, just like with emulators on iOS, anyone who wants one can just take the source code, change the identifier on it, and deploy a copy of it to their own device for their own use, as a “test.” And unlike with iOS TestFlight, these private-beta browser-extension deployments don’t expire after a week.

Yes, that’s still a big hurdle to expect non-technical people to jump, compared to just allowing these extensions to get published. Yes, that puts Mozilla/Google/etc. in positions of censorship, where they may make arbitrary decisions.

But don’t just say “don’t do that then.” Carefully envision an alternative. What do you want the browser to do: let you add alternative extension trust-roots, like adding repos to apt? Then a virus could go in and add its trust-roots. (This would, again, be fine if it was only something the browser trusted if set in an MDM profile / GPO policy, signed with some remote key a virus couldn’t grab from the local OS; but it’s fundamentally not something the browser can trust if it’s just data sitting in the user’s personal preferences directory, or even the OS’s preferences.)

I’d be happy to see any solution to this problem that lets the locus of control remain within the local computer, while preventing viruses from tampering with it. Capability-based OSes were there decades ago, and some sandboxing approaches are kinda-sorta getting there. But nothing that consumers use is in any way there yet.

Why should browser makers get to decide which extensions are allowed to spread?

> let you add alternative extension trust-roots, like adding repos to apt? Then a virus could go in...

In an OS with app sandboxing, no a virus can't just "go in" and add extensions. The way to stop malware from compromising the user's data is to stop malware from compromising user data! It's not imposing central control over third-party software development.

The fundamental gap here is in people continuing to think that any app can access all of a user's preferences directory. That's an obsolete and reckless model. In the modern world, every app runs in a sandbox and can affect only its own preferences directory.

Yes, but I'm talking about how the world works today — and today, viruses still find ways to run on OSes where they aren't forced into any kind of sandboxing.

Usually because they get spread in the form of some kind of system-automation script (which inherently run with the kind of non-sandboxing that "gluing disparate apps together" requires) where "run embedded script with elevation" is an API call, so all they need to do is to convince the user to accept the elevation prompt.

Today, in the here and now, we shouldn't be playing with knives. But maybe we can play with knives again when we learn to wear gloves.

---

I feel like I should say: Mozilla aren't an OS manufacturer. They can't fix the OS security model of all OSes, everywhere. They can only modify the thing they have control over (the browser) to be secure in the face of generally-broken OS security models.

But that's not even really the point, because this is as much about Evil Maid attacks as it is about viruses. Sandboxing doesn't prevent someone impersonating the user, with the user's full authority from installing extensions on the system. They might have the right keys to authenticate as an admin, but as long as they can authenticate as the user, they can act as the user to do the same things the user themselves would do, to install user-specific malware browser extensions.

(And, maybe of more concern to home users, there are plenty of ways for a virus to impersonate the user, e.g. through accessibility APIs. Unlike superuser elevation prompts (which run on a different Desktop / as high-integrity / etc., and thus ignore other programs sending input-events to them), there's no elevation prompt for one program goes to interact with another program's files (ala macOS's recent Gatekeeper changes), that accessibility APIs can't be made to interact with. Imagine how a user operating the OS with switch-control would react to not being able to use switch-control to accept an inter-app-elevation-prompt. Untenable, right?)

As for evil maid attacks: that's just paternalism. It's the user's responsibility not to grant unauthorized humans access to his user account. Trying to protect against the scenario in which a user willingly grants account access to somebody he shouldn't trust through artificial feature limitations is an unacceptable infringement on user autonomy.

See my reply to a sibling comment: it's because extensions in Firefox Mobile aren't really "extensions" (modules external to the download package) per se, but rather are built into the package pushed to the App Store / Google Play Store. This is forced by the platform owners, who want to vet all [non-sandboxed] code that ever runs in relation to a given app — which means all that code has to be in the app, amenable to static analysis / fuzz testing / malware signature scanning / human spot checks / whatever else the platform-owner wants to put the app-bundle through as part of vetting it for release.

The alternative model Firefox Mobile could do, is to build an extension model where the extensions are each their own app-like things that get submitted to the App Store + Play Store. (Think iOS Safari's "iMessage Sticker Pack" app-bundles.)

This, though, has three problems: first, it takes the extension trust model out of Mozilla's hands (so, depending on the API, Mozilla potentially wouldn't be able to block what they consider to be malware extensions, without disabling all extensions.) Second, it forces extension authors to go through the platform owners to publish, which removes the "write once, publish once" flow that WebExtensions currently have.

But the third and most important problem, is that it requires these platforms to add one-off support for the new "type" of purchasable item within their stores — which they might not necessarily be willing to do.

Maybe Mozilla has already tried and failed to get the platforms to do so already. Or maybe — I'd guess this is more likely — they're still working on it, and the current situation is a stop-gap until then.

> It's the user's responsibility not to grant unauthorized humans access to his user account.

If you're the CIO of a corporation; and it's the frequency at which your company's employees fall victim to social-engineering attacks is a literal KPI that your job-security is determined by; and you can't drive that by just saying "don't hire people who aren't paranoid about OPSEC" because there aren't enough paranoid-mindset people in the world to actually fill all available positions in your company; then what are you going to do?

There's an analogous situation you're in when you're an able-bodied adult, advising an elderly person or a child or a very new computer-user of what software to install.

Yes, that's literal paternalism. Some people need someone else to be their IT admin. I really wish it was easier to set up home-OS computers during initial setup so that they were one-off MDM managed by some other person somewhere, without that person needing to run an MDM server.

But as that isn't easy — you need to actually have an MDM server set up, and bind them to it, and everything gets screwed up if their computer can't reach the domain for a month — then the closest thing you can do, is to just tell them to install software that enacts the same sort of MDM-restrictions you'd enact, for you.

The trend in the industry has been to ignore the existence of the individual home-user "power user" — i.e. the person who wants to be the sysadmin of their own computer. In the modern security model most OSes and apps subscribe to, there are three groups / user-stories:

1. home users who aren't (and don't want to be) sysadmins, but who don't have anyone else to be their sysadmin

2. corporate employees who have a real sysadmin managing their computer

3. the corporate sysadmins themselves

The modern setup is to give group 3 complete control over group 2, and to restrict the actions of group 1 about the same way as if the software ISV itself was the user's sysadmin (but to take these de-facto restrictions away for group 2, instead trusting group 3 to make the right decisions concerning them.)

This works well-enough to prevent the things the ISVs want to prevent — the spread of viruses/malware, etc. And it works well-enough for most users as well.

For the users that want to be their own sysadmin, their situation is annoying, but not impossible: they have to opt out of being a member of group 1, and instead join both groups 2 and 3: make their computer think it's managed by some corporate sysadmin, and then also be that corporate sysadmin.

We could make this much easier for these people... but honestly, there aren't that many of them. It's a good-enough solution, especially since most of these "power users" are exactly the kind of people who can follow extended lists of arcane instructions to put their systems into this externally-self-managed state.