Re:Manifest v3 Update
by derefr on Sunday May 30, 2021 @12:36PM
(#27334427)
> Then what's the rationale for Mozilla being extra strict on extensions to Firefox Mobile, which runs in the most sandboxed Firefox platform?
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.
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.