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

On Tuesday, May 27, 2014, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres <w3c@marcosc.com<javascript:;>>
> 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.


Yes. This was the only intent.


>
> But if we're trying to protect more things, then CORS strikes me as
> the wrong solution. And I do think that we will want to protect
> against other things in the future. In FirefoxOS the "origin" of an
> app is the origin of the app's manifest. This app-origin is then used
> in a bunch of situations.
>
> For example, we allow pages from the app's to store unlimited amount
> of data through various storage APIs (localStorage excluded for
> reasons I won't get into here). So if you hosted the manifest on a
> CDN, then would mean that only pages whose origin is that of the CDN
> would get access to unlimited storage. That is very unlikely what
> developers want.


Agree - the FX OS model is certainly not the intent or how we, the Eds,
envisioned it working. The manifest relates to the explicit  or implicit
"start URL" (and soon the URL scope), but not to the manifest's origin.


>
> In this case hosting the manifest on the CDN would be a footgun, but
> not a security problem.




> I can't off the top of my head think of any actual security problems
> with putting the manifest on a CDN, but I would be surprised if that
> wouldn't happen as we expand the manifest feature set.
>
> And the footgun is bad enough.
>
> So I would recommend sticking with having the manifest be same-origin
> with the HTML page.



 Thanks for the additional data point about how FxOS does things.