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.
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.