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

On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote:
> On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> >
> >
> > On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jonas@sicking.cc) wrote:
> >> On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
> >> > 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.
> >
> > hmmm... I thought this was *exactly* the point of having the "*-Allow-Origin" header (restrict sharing to the domains the server chooses in browsers).
> >
> >> 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.
> >
> > Yep. The point was that combined with the `start_url` member, you can make "install pages" away from the origin where the application resides.
> >
> >> 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.
> >
> > Sure. But that's not the point here. The use of CORS here is to control who can do what within the context of the browser (as the policy enforcement point). Of course, anyone can just go and download  anything with wget or whatever - but that's not going to give that person a web app with the manifest applied.
> 
> So let's start by asking this: What are you trying to protect against
> by using CORS at all? Rather than using the policy that <img> uses.
> 
> If the *only* thing you are trying to protect is the actual bytes in
> the manifest itself, then CORS is indeed the right solution.

This is exactly what I was going to ask: I'm not sure what is the
benefit of CORS restricted manifest fetching if we allow the manifest
start_url to point to a cross origin URL. As is, the manifest doesn't
contain sensitive data. It is only metadata that aren't user-specific
and should be fairly public (at least as public as the website is). In
that regards, the only benefit from enforcing CORS restrictions on the
manifest fetching I think is to be safe and future-proof (if the
manifest ends up having sensitive stuff in it, we don't need to break
all the things).

This said, I think that start_url should be same origin as the manifest.
It sounds very odd to navigator to foo.com, fetch foo.com/manifest.json
and then ends up going to bar.com when I try to navigate again to the
foo.com page via my bookmark. It might not make much sense for the user
and the confusion could lead to attach scenarios. I would be more
comfortable to have everything in the manifest being same origin as the
manifest itself.

Then, it might make sense to have the manifest same origin as the web
page because obviously making start_url same origin as the manifest
would be moot if the manifest doesn't have to be same origin with the
web page ;)

-- Mounir

Received on Wednesday, 28 May 2014 10:20:51 UTC