On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres <w...@marcosc.com> wrote: > > > On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@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
