I have some comments on Jonas' proposed new security model for B2G. Apologies to Jonas if this is a work in progress and not ready for discussion, but it's been on the wiki for a few days now and I think Tim linked to it in his blog post so I figured it was fair game ;)
https://wiki.mozilla.org/FirefoxOS/New_security_model *URLs* The proposal says that "The format used for the packaging will be the one defined in the W3C packaging spec draft". In addition to a packaging format that spec [1] proposes a different URL format than the !// system which is discussed here. In the W3C proposal the package is specified in a <link rel="package" href="..." scope="..."> link relation and is an alternative way to fetch a packaged version of a bunch of URLs within a defined URL scope in a single HTTP request. Before trying to separately GET any resources which fall within that scope, the user agent should first check inside the package to see if the resource is included. In the W3C draft the example URL you give of: https://website.com/RSSReader2000/package.pak!//index.html would simply be: https://website.com/RSSReader2000/index.html But could also be referenced directly inside the package if needed with: https://website.com/RSSReader2000.pak#url=index.html Each part of the package has a Content-Location header to refer to the non-packaged resource's canonical URL. What I like about this proposal is that it's more backwards compatible and easier to retro-fit to existing content, and doesn't require a special URL format. What's the reason for needing the new !// separator? is there a risk that this could create parts of the web which will only work in Mozilla products? Would the server be able to distinguish between user agents which support the packaging format and those that don't, in order to return an unsigned individual resource instead of the package for a given URL? It would be nice to degrade gracefully even when the privileged permissions aren't supported. For CSP purposes, could the URL of the package the resource came from (or the manifest URL inside that signed package) be stored alongside the resource in the browser cache when marking it as a "signed resource", rather than using a !// URL to determine whether it's part of the same package? *Signing* The Streamable Package Format is designed to be consistent with multipart media types. Should we therefore consider using the multipart/signed format from RFC 1847 [2] (e.g. [3]) rather than include separate signature files? Note that this would allow the HTTP headers of the resources to part of the signed resource. Are you expecting individual parts (files) in the package to be signed (each part could be a multipart/signed), or for the package to be signed as a whole (the package would be a multipart/signed)? If it's the whole package, would that effect its streamability? Does the whole package have to be verified before any of the resources can be used? Note: It might make sense for the app manifest to be the first resource in the package if that's used to enumerate permissions and specify a start_url/launch_path. I hope that developers can host their signed packages themselves on their own servers, and eventually sign their own packages as well. I think as long as these are "Firefox Apps" proprietary to Firefox products (essentially a Firefox OS addon) it's fine for them to have to be signed by Mozilla, but if we ever wanted to standardise this signing mechanism to make them "web apps" we certainly need a more distributed trust system. Perhaps like the code signing system for XPIs we are currently moving away from with Addons (!) with multiple certificate authorities https://developer.mozilla.org/en/docs/Signing_a_XPI *Scope* You point out that a signed app should run in its own process and its iframe should only be allowed to navigate to URLs which return signed resources. This sounds tricky, but it also sounds potentially related to the "navigation scope" we have discussed around web apps. Note that it might not be as simple as only allowing the browsing context to navigate to URLs of resources which came from the package. We may want to create Gaia apps which have dynamic URLs like http://contacts.firefox.com/contacts/123 which the Service Worker intercepts and generates a page for, but which were not one of the static resources included in the package. My proposal for navigation scope was for a webview to specify a manifest attribute pointing to a web app manifest which specifies the navigation scope of the app in a scope property. Any navigations outside that scope would open outside the application context (the webview with the manifest attribute). <webview manifest="/manifest.json"> That was mainly intended for a web app launched from the launcher of an installed app, to create an application context for app with the manifest applied. I'm not sure how this could be applied to apps which aren't installed. I don't really have an answer here, I just wanted to highlight some potential requirements. Should package scope, Service Worker scope and navigation scope all be the same thing, or are they all orthogonal? *Permissions* If we want to grant permissions to apps which are not installed, I think we need to at least re-visit all the permissions which have the default granted permission as "Allow" [4]. Currently our permissions system assumes an implicit level of trust from the user from the act of installing an app. Allowing a permission to be used simply by navigating a web page removes this implicit opt-in from the user and puts a lot more responsibility on code reviewers at Mozilla. *Updates* If the cache header of a particular resource has expired, could Gecko be smart enough to just download that one resource from the package (streaming the package until it comes across the resource it's looking for) rather than having to download the whole package or use some complex incremental diffing system? This would require that individual parts of the package were signed though, rather than the whole package. I'm not sure whether the server would be able to respond with a 304 Not Modified response for a resource in the package if it doesn't need updating... *Origin* Are signed resources from the package always considered cross-origin with other resources on the same server? Could a static signed JavaScript file at http://contacts.firefox.com/js/script.js do an XHR to a dynamic REST API URL at http://contacts.firefox.com/contacts/123? *Manifest* Could these new Firefox Apps maybe use the W3C web app manifest format as a base, and use vendor prefixed proprietary properties where necessary? (e.g. moz_permissions). Seems like an opportunity for a fresh start. Thanks Ben 1. http://w3ctag.github.io/packaging-on-the-web/ 2. https://tools.ietf.org/html/rfc1847 3. http://www.in2eps.com/fo-cms/tk-fo-cms-ex14.html 4. https://developer.mozilla.org/en-US/Apps/Build/App_permissions
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
