On Mon, Apr 2, 2012 at 10:58 AM, Lucas Adamski <ladam...@mozilla.com> wrote: > 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).
I had a discussion with Lucas about these groups and we came to the conclusion that it might be good to split up the a) group into two groups: a1) 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) a2) "installed" unauthenticated content: Same as a1, but some privileges are automatically granted. No privileges that expose the user to additional privacy or security risk are granted automatically. However privileges which use device resources (harddrive space, network bandwidth, CPU power) and privileges which could annoy the user (replace context menus, set screen orientation). So there are clearly APIs which have different UX between a1 and a2, so it makes sense to split it into two separate groups. Also considering that most applications will hopefully fall into either of these categories, it makes sense to be more detailed in how we treat them. / Jonas _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
