[manifest] Fetching restriction, Re: [manifest] Update and call for review

On May 27, 2014 at 9:25:26 AM, Ben Francis (bfrancis@mozilla.com) wrote:
> > As per our conversation in IRC, something else I'd like to highlight  
> is the fact that in the current version of the spec any web site  
> can host an app manifest for any web app.

I'm really sorry, seems I wasn't very coherent on IRC - it's not possible for site A to use site B's manifest unless site B explicitly shares it (using CORS). 

Unlike with stylesheets or other <link>'ed resources, the fetch mode for manifests is always "CORS" - meaning that the following would not work:

<title>fakegmail.com</title>
<link rel="manifest" href="http://mail.google.com/manifest.json">

Even if the above "manifest.json" existed, the above would result in a network error when the user agent tries to fetch "manifest.json" from google.com. The error is because the request is not same origin, and because google doesn't include the CORS header allowing the cross-origin request. 

The only way that gmail would allow "my own app store" to use its manifest would be for Google to include the HTTP header:

Access-Control-Allow-Origin: "http://myownappstore.com"

Or from "*". 

You can see this in the spec in the "obtaining a manifest" algorithm [1].

Sorry again about the confusion. Hope that is more clear now!

> That means for example  
> that I could create my own app store for web apps and provide a listing  
> for a GMail app which users can add to their homescreen, without  
> any involvement from Google.

The only way one could do what you describe would be for "my own app store" to host its own manifests. So:
http://myownappstore.com/gmail/index.html

Would contain: 
<link rel="manifest"
href="http://myownappstore.com/gmail/manifest.json">

Which would have:

{
   "name": "Gmail"
   "start_url": "http://gmail.com"
}

This would allow custom stores that provide tailored "app experiences" for sites that lack manifests. 

Where this could become a problem in the future is if manifests start granting elevated privileges (e.g., access to specific APIs or unlimited storage). However, the security model could then be refined so that, for instance, only same origin manifests that are served over HTTPS get special powers. In such a case, non-same-origin manifests could be "tainted" and only the basic metadata from the manifest would be used by the user agent.  

> It would be good to hear some opinions on whether it is a good thing  
> or a bad thing that manifests don't have to be served from the same  
> origin as the web app itself.

It would indeed be great to get some more opinions about this. 

[1] http://w3c.github.io/manifest/#obtaining-a-manifest

-- 
Marcos Caceres

Received on Tuesday, 27 May 2014 16:12:09 UTC