On Wed, Jun 6, 2012 at 9:23 AM, Paul Theriault <[email protected]>wrote:
> It is expected that all Gaia apps will fall into the certified category Really?! If all Gaia apps are considered to require enough privileges to need the "certified" level, given that "3rd party certified apps" are "out of scope for 1.0" ( https://wiki.mozilla.org/Apps/Security#Out_of_scope_for_1.0), does that mean that third party developers won't be able to write apps which are able to compete with any of the Gaia apps and users will be stuck with the ones that ship with the device? > , and as such I wanted to raise this requirement for discussion, as there > are significant implications which have not really been explored as yet. > > Proposal > ========================= > The proposed requirement is that all certified apps have a strict CSP > (default-src 'self') which allows loading of resources from same-origin > only. I had a skim over the Gaia apps and the key impacts I see are: > > * For <script> tags, this means that all script must be contained in files > loaded from the same origin. This is generally already the case for most > Gaia apps, but there are a few inline script tags in some apps (e.g. > https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/index.html#L8- > though this looks like a fix until the webapi.js is in the browser > itself?) > Applying same-origin to JavaScript, CSS and appcache will mean that no assets (JavaScript libraries, CSS files or even icons) can be shared between Gaia apps. It will be more difficult to maintain duplicate code but we can probably live with this if necessary. Appcache actually already has a same-origin policy when assets are loaded over HTTPS, at least that's what the spec says even if browsers don't always implement it that way... "Whitelisting a specific domain for gaia apps" as suggested below is another thing that we can do for gaia apps but third party developers can't do for their apps. Doesn't sound like a very level playing field. > * data URIs are blocked. Again these arent really used much but there are > a few examples (e.g. https://github.com/mozilla-** > b2g/gaia/blob/master/apps/**system/js/windows/window_**manager.js#L380<https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/windows/window_manager.js#L380> > ) > This could break stuff. For example, in the browser app favicons can actually be data URIs. Having said that, storing favicons in the browser app won't work at all if the same-origin policy applies to XHR. This seems to be the complete opposite direction to https://bugzilla.mozilla.org/show_bug.cgi?id=692677 which looks to relax the same-origin restriction for XHR for privileged apps to allow not only little things like favicons in browsers, but also entire apps like client-side news readers, podcast clients and calendar apps. If lots of apps will be forced to be certified (which I hope they won't), they are very likely to need a way to request exceptions to these restrictions. Ben -- Ben Francis http://tola.me.uk _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
