On Wed, Jun 18, 2014 at 7:28 PM, Jonas Sicking <[email protected]> wrote:
> The W3C TAG is currently > working on creating a standardized packaging format for the web. > I believe this is http://w3ctag.github.io/packaging-on-the-web/ > 1. Create a new package format. The format should support streaming > and support adding metadata, like headers, to individual resources. It > likely also needs to support metadata for the package itself. > This seems to be addressed by http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format > 2. Add CSP syntax similar to "self" but which means "in the same > package" rather than "from the same origin". > No mention of this yet in the Editor's Draft. > 3. Add a new URL syntax for referring to resources within a package. > One candidate is > http://server.com/url/to/myapp.webpackage!//images/pic.jpg. I.e. the > "!//" signals boundary between the URL sent to the server to fetch the > package, and the path within the package to get a resource. But we > need to check that this is web compatible. > As you know, this is currently explicitly listed as a "rejected approach" here https://github.com/w3ctag/packaging-on-the-web#specialising-urls > 4. Define metadata which can be added to the package for "this is a > privileged app" and/or "this package is signed" > Not surprisingly, no mention of this yet. In the W3C proposal a package link relation (e.g. <link rel="package" href="/app.package" scope="/">) points to a file which is just a packaged version of a collection of resources which would otherwise be individually requested from their respective URLs. As I understand it the idea is that a user agent which supports packages can notice when it comes across a reference to a file which falls under the scope of a package, and wait to download and process the resources contained in the package before attempting to individually download that resource, thereby cutting down the number of HTTP requests. It could then use the contents of the package to populate a local cache so that resources can be fetched from the cache rather than individually requested over the network. A user agent which does not support packages would ignore the package link relation and just go ahead and download the individual resources from their respective URLs. The package is just a progressive enhancement to help the user agent get resources more quickly. For backwards compatibility all of the resources would still have to be individually retrievable from the server at their own URLs. One of the examples given ( http://w3ctag.github.io/packaging-on-the-web/#example-scenario) allows for an individual resource whose cached copy has expired to be updated independently of the rest of the resources in the package. Unfortunately this approach wouldn't allow for a security model based on the signing of packages or a separate origin for files retrieved from inside a package, because the package is just used to populate a cache of resources. The user agent is free to either load the resources from a cache or to load them from the server at any time, they will always be considered as having come from the same origin. It seems that the W3C proposal is incompatible with arguably the main use case of packaged apps in Firefox OS, which is the cryptographic signing of source code by a trusted party. My question is should we again raise this contentious issue with those responsible for the W3C proposal and risk derailing the standardisation effort of packages on the basis that they don't meet this basic use case, when standardised packages may have some value in their own right?
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
