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

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.

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.

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.

/ Jonas

Received on Tuesday, 27 May 2014 23:00:05 UTC