4 ms·

> And there's nothing you can do to plug it through local security, since a virus running with your account's permissions can do all that just as well. As we m

> And there's nothing you can do to plug it through local security, since a virus running with your account's permissions can do all that just as well. 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-dissenter-extension https://reclaimthenet.org/google-chrome-web-store-bans-disse... [2] https://github.com/iamadamdev/bypass-paywalls-chrome https://github.com/iamadamdev/bypass-paywalls-chrome

derefr 5y ago
> Because extension-market web sites censor desired extensions that they think are bad. 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.
- quotemstr 5y ago
  > They can’t spread like public extensions — they have explicitly limited install-count caps — so it doesn’t even matter if they’re malware. 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.
  - derefr 5y ago
    > The fundamental gap here is in people continuing to think that any app can access all of a user's 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?)

derefr 5y ago

> Because extension-market web sites censor desired extensions that they think are bad. 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.

quotemstr 5y ago
> They can’t spread like public extensions — they have explicitly limited install-count caps — so it doesn’t even matter if they’re malware. 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.
- derefr 5y ago
  > The fundamental gap here is in people continuing to think that any app can access all of a user's 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?)