Re: Data URL Origin (Was: Blob URL Origin)
On Fri, May 30, 2014 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote: Given that workers execute script in a fairly contained way, it might be okay? Worker scripts aren't going to be very contained as we add more APIs to workers. They can already read any data from the server (through XHR) and much local data (through IDB). I'd definitely want them not to inherit the origin, the question is if that's web compatible at this point. Maybe we can allow them to execute but as a sandboxed origin? Good point. We'll have to investigate how much we can do there. I followed up on the WHATWG list with regards to aligning Fetch and HTML with the new policy. I also filed a bug on Gecko. * http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jun/0002.html * https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 -- http://annevankesteren.nl/
Data URL Origin (Was: Blob URL Origin)
On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: How do we deal with data URLs? Obviously you can always get a resource out of them. But when should the response of fetching one be tainted and when should it not be? And there's a somewhat similar question for about URLs. Although only about:blank results in something per the specification at the moment. My proposal is something like this: * Add a new flag to the fetch algorithm allow inheriting origin * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. * I don't know what URL(data).origin should return. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for iframes the flag would only be true if some iframe allowinheritingoriginfordataurlsplease attribute was set. And then it would still only be set for the initial load. If the iframe navigated (through a link or through setting window.location) the flag would be set to falls. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. / Jonas
Re: Data URL Origin (Was: Blob URL Origin)
On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote: My proposal is something like this: Thanks! * Add a new flag to the fetch algorithm allow inheriting origin same-origin data URL flag? Ideally we don't do another data URL mistake. * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. This does not clarify what happens if you end up at a data URL as a result of a redirect. If the redirect is cross-origin you'll end up tainted. If it's CORS you get a network error. But if it's same-origin that's fair game? * I don't know what URL(data).origin should return. Probably just null. I think we should make it about the origin of the request, not the URL. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for XMLHttpRequest? We decided a while back we wanted data URLs to work there. And for iframes the flag would only be true if some iframe allowinheritingoriginfordataurlsplease attribute was set. And then it would still only be set for the initial load. If the iframe navigated (through a link or through setting window.location) the flag would be set to falls. Seems fair. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. Given that workers execute script in a fairly contained way, it might be okay? -- http://annevankesteren.nl/
Re: Data URL Origin (Was: Blob URL Origin)
On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote: * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. This does not clarify what happens if you end up at a data URL as a result of a redirect. If the redirect is cross-origin you'll end up tainted. If it's CORS you get a network error. But if it's same-origin that's fair game? For something like an iframe load I think the safe thing is to always clear the flag when a redirect happens. I.e. if someone does iframe src=http://example.com/a; allowinheritingoriginfordataurlsplease and example.com redirects to a data URL, we would have all sorts of messy questions if we allowed the flag to stay set an the origin to be inherited: * Should it be inherited from the owner of the iframe, who set the allowinheritingoriginfordataurlsplease attribute, or from example.com who is the one that generated the data URL. We don't want example.com to get XSSed either. * What if the owner of the iframe hadn't thought about redirects to data URLs and just checked the src URL for data: and verified that it didn't contain any bad stuff? Redirecting to a data URL feels like a very edge-casy thing. So lets keep it simple and safe rather than worry about cramming more features in. * I don't know what URL(data).origin should return. Probably just null. Given that the effective origin depends on which API you pass the data-url to, I agree that trying to return a real origin here is never going to be sensible. I don't know if returning null is the way to go, or if returning `undefined` is. I guess I don't have a strong opinion. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for XMLHttpRequest? We decided a while back we wanted data URLs to work there. I don't feel strongly. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. Given that workers execute script in a fairly contained way, it might be okay? Worker scripts aren't going to be very contained as we add more APIs to workers. They can already read any data from the server (through XHR) and much local data (through IDB). I'd definitely want them not to inherit the origin, the question is if that's web compatible at this point. Maybe we can allow them to execute but as a sandboxed origin? / Jonas
