Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres w...@marcosc.com wrote:
The only way one could do what you describe would be for my own app
store to host its own manifests. So:
http://myownappstore.com/gmail/index.html
Would contain:
link rel=manifest
href=http://myownappstore.com/gmail/manifest.json;
Which would have:
{
name: Gmail
start_url: http://gmail.com;
}
This would allow custom stores that provide tailored app experiences for
sites that lack manifests.
Where this could become a problem in the future is if manifests start
granting elevated privileges (e.g., access to specific APIs or unlimited
storage). However, the security model could then be refined so that, for
instance, only same origin manifests that are served over HTTPS get special
powers. In such a case, non-same-origin manifests could be tainted and
only the basic metadata from the manifest would be used by the user agent.
To be clear, this is the case I was talking about. The benefit is that it
makes it much easier to build a large app store of tailored app
experiences for sites that lack manifests without the involvement of app
authors themselves. For example, everything.me may have a larger catalogue
of web apps than the Firefox Marketplace because the latter requires
same-origin manifests and for app authors to submit their own apps, whereas
the former doesn't require any involvement from app authors themselves.
One risk of allowing cross-origin manifests might be that these tailored
app experiences are perceived by the actual app author and/or end users as
a fake app masquerading as the real thing. In the longer term when
additional features are added to the manifest there could be additional
risks.
That is why I'm interested in feedback on whether this is a desirable
feature or not.
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tue, May 27, 2014 at 9:53 PM, Marcos Caceres w...@marcosc.com wrote: On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote: One risk of allowing cross-origin manifests might be that these tailored app experiences are perceived by the actual app author and/or end users as a fake app masquerading as the real thing. In the longer term when additional features are added to the manifest there could be additional risks. That is why I'm interested in feedback on whether this is a desirable feature or not. That's a very good summary of both the use case and the problems. I'm also interested in hearing feedback. As Ben makes clear, same-origin basically kills installations from custom stores. Wait what? Man-in-the-middling someone's content is not a use case. -- http://annevankesteren.nl/
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 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. 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
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri mou...@lamouri.fr wrote: 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 ;) I think we have a winner. -- http://annevankesteren.nl/
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Wednesday, May 28, 2014, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri mou...@lamouri.frjavascript:; wrote: 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 ;) I think we have a winner. Yep! Will update the spec. Thanks for all the good input. -- http://annevankesteren.nl/
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tue, May 27, 2014 at 6:11 PM, Marcos Caceres w...@marcosc.com wrote: Where this could become a problem in the future is if manifests start granting elevated privileges (e.g., access to specific APIs or unlimited storage). However, the security model could then be refined so that, for instance, only same origin manifests that are served over HTTPS get special powers. In such a case, non-same-origin manifests could be tainted and only the basic metadata from the manifest would be used by the user agent. So long term are we expecting deployment on CDNs on sites that do not want these features too? Sticking to same-origin seems simpler. -- http://annevankesteren.nl/
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres w...@marcosc.com wrote: On May 27, 2014 at 9:25:26 AM, Ben Francis (bfran...@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: titlefakegmail.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
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
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. It does not currently mean, and I don't think it should mean, I am ok with acting as a manifest for any website. This is a different interpretation of the semantics of sharing a manifest - and certainly not the primary use case (though http://generic-manifest.com/manifest.json; could be useful for testing and other interesting things). The idea was to say which stores can create a product page with the manifest. 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. Given the current stuff the manifest defines, I don't have a strong opinion - but it certainly does seem like a few less potential headaches down the line. I'm happy to make this change and restrict to same origin.
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote: To be clear, this is the case I was talking about. The benefit is that it makes it much easier to build a large app store of tailored app experiences for sites that lack manifests without the involvement of app authors themselves. For example,everything.me(http://everything.me) may have a larger catalogue of web apps than the Firefox Marketplace because the latter requires same-origin manifests and for app authors to submit their own apps, whereas the former doesn't require any involvement from app authors themselves. One risk of allowing cross-origin manifests might be that these tailored app experiences are perceived by the actual app author and/or end users as a fake app masquerading as the real thing. In the longer term when additional features are added to the manifest there could be additional risks. That is why I'm interested in feedback on whether this is a desirable feature or not. That's a very good summary of both the use case and the problems. I'm also interested in hearing feedback. As Ben makes clear, same-origin basically kills installations from custom stores. It means one or two additional clicks for users to install an app - but we assure that apps are always being installed from the source. -- Marcos Caceres
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tuesday, May 27, 2014, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres w...@marcosc.comjavascript:; 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. 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.
