On Thu, Mar 15, 2012 at 5:52 PM, Adrienne Porter Felt <a...@berkeley.edu> wrote: > https://wiki.mozilla.org/Apps/Security#Management_.2F_granting_of_API_permissions_to_WebApps > > Under "Management / granting of API permissions to WebApps", I think two > important points are missing: > > 4. User should be able to audit usage of permissions (this is different from > viewing what permissions an app has, since that does not tell you how or > when it is used) > 5. Apps cannot request permission to do something that is not listed in the > manifest
adrienne, hi, i've added these two excellent points to the wiki page on your behalf. > I'd also like to raise the issue of what happens to permissions when > principals interact. Do webapps have iframes like websites? Can they embed > advertisements? Do the advertisers then get all of the permissions? :) ok, *deep breath*... :) as this is a complex discussion with some 65 messages, i understand it's hard to follow absolutely everything, so i'm happy to repeat things in the context you raise, apologies to everyone else who's seen this before, and to those who are familiar with the B2G architecture gaia apps happen to be implemented as iframes. these are "chrome" iframes (which chris kindly explained: firefox is actually implemented as iframes! all that URL bar etc. is actually in a separate isolated frame which has nothing to do with the main webpage-displaying iframe). the security context of one of these frames is completely separate from a webapp iframe which contains embedded advertisments (standard URL etc.) so it's really rather confusing, as there are separate security contexts and entirely separate concepts for which the *exact* same technology (iframes) is being utilised. if you are familiar with x-windows, you've kinda said "do webapps have windows like websites?", you see what i'm getting at? :) anyway, the point is that there are separate security requirements for: * the root frame (top-level one into which the top gaia HTML is loaded) * individual gaia apps (sub-iframes, one per app) * any gaia app that opens up a public-facing (URL-based) iframe - the browser app is one such * iframes *within* that iframe - as in "iframes that you normally think of iframes being used for". man that's as confusing as hell, but there simply isn't a glossary yet for describing this stuff and giving it some unique unambiguous terminology. anyway: within that context, you can see that the "standard" job to which the "normal" web site security applies (XSS) would do pretty well to deal with "advertisments" etc... *as long as* those pages are completely and totally cut off from the B2G APIs. ah. damn. i've just thought of something. i'll document it separately. it's to do with "eval". > There are two ways iframes/permissions don't mix well: adrienne, would you mind re-phrasing what you've written, in light of the explanation of the *four* different types of iframe, above? i realise this is extra work, but it's too easy to misunderstand. "child frame" could mean any one of 1, 2, or 3 depending on whether you're taking about a parent of type 2, 3 or 4, respectively. the security context boundaries therefore change. in fact, do you even want all "child" frames to even be _aware_ that they even have a "parent"? this is the Cambridge Capabilities Security Model (or, it's a "Capabilities" security model). if you don't want something to be accessed you *don't even make code aware of its existence*! l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
