Its been a very productive discussion, though I do think we have perhaps focused too much on the question of "installed vs not" and thereby created a bit of a false dilemma. For example, if we agree that random HTTP web content should be permitted to request access to a certain set of webAPIs, whether that content is "installed" via a manifest or not does not significantly change the risk inherent in granting it that set of privileges. This permits the use case of just turning a normal website into an app, without having to go through significant packaging. This is ok because that app can have no more privilege than a regular web page can request.
Now if there is a set of APIs that an app might have implicit access to, or APIs that present too much risk to have completely random web content request access to, then we need to have a category of application that the user can make a trust decision regarding (the app or publisher) before granting such privileges. This ensures that when the user decides to trust code from X, that can be a meaningful decision. I'd like to propose a different way of framing these categories as: a) unauthenticated content (typical web content): contains privileges that any content can request. Risk is generally limited to privacy, i.e. to what the user chooses to share via that API at that point in time. Safe enough for any content to request at any time. (risk: low severity) b) authenticated content (trusted content): privileges that require the user to make some explicit trust decision based upon the identity of the requesting party BEFORE these privileges can be explicitly prompted for or implicitly granted. This requires code integrity as well as authenticity. These are privileges that we would not want random pages prompting for without the user first accepting the identity of the requesting party, and if abused the risk is limited to disclosure of confidential information / privacy / persistent annoyance / phishing, but not persistent system compromise (risk: moderate to high severity) c) certified content (trusted content vouched for by 3rd party): privileges that the user has to make an explicit trust decision about based upon strong authentication AND vouched for by a trusted 3rd party. One use case for example are B2G APIs for implicit access to dialer and SMS. For an app to have direct access to them, it would need to be certified by the carrier or manufacturer in question. These are APIs that the average user cannot realistically make a risk judgement about and/or the misuse of which can result in local system compromise or direct financial impact (risk: critical severity). Anticipated objections: 1) Your proposal means code signing: no it doesn't, we haven't decided what authentication means. So I suggest that we table the discussion of what specific mechanisms we use to authenticate the code (SSL, SSL + HSTS + CA pinning + CSP, code signing, widgets-digsig, etc.) until we have a better understanding of the risks inherent in each category of app. Threats before mitigations. :) 2) Your proposal requires installer packages: it doesn't, code authentication is orthogonal to packaging; packaging is just a delivery mechanism 3) Your proposal means all privilege are granted up front at app install: Nope, we should not confuse authentication with authorization. For authenticated apps the initial trust decision just grants the app the right to request those sensitive privileges. They could still be opt-in, opt-out or any combination thereof. This is TBD. 4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks. Next steps: rather than debating packaging and signing, we should do the difficult work of talking through each API and determining the risk level (and proposed mitigations) for each of the categories above. This discussion will driven by identified use cases for each API, which ensure we can make the right experience/mitigation decisions. I will start sending those out shortly as our PM's prioritize them based upon use cases and schedule. I suspect some of these will be very quick, while others may become quite involved. Once we've gone through a representative set of these APIs, we will then look at the installation experience, at which point we can have a far more informed discussion of the risks and merits of the various proposed approaches. I am trying to keep this discussion focused on the dev-webapps mailing list, so if you could please send your responses there that would be ideal. Failing that I'll take a response on any other list over silence. :) Thanks! Lucas. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
