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

On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
> 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"

This is a bit of an abuse of CORS. Adding an
"Access-Control-Allow-Origin: *" header currently has the semantic
meaning of "any website can read the contents of this file". I.e. it
only means that the bits in the file are accessible from other
websites.

That means that for a webserver on the public internet it is currently
always safe to add the "Access-Control-Allow-Origin: *" header to any
file since all files can be read anyway by simply using a different
HTTP client than a browser, such as wget.

It does not currently mean, and I don't think it should mean, "I am ok
with acting as a manifest for any website".

I think restricting manifests to same-origin is the way to go. I would
not be surprised if manifests will eventually end up with similar
security properties as hosting HTML files currently does.

/ Jonas

Received on Tuesday, 27 May 2014 18:30:59 UTC