This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A page inside an <iframe sandbox="allow-same-origin"> should not be allowed to use filesystem: URLs. Allowing reading from filesystem: would effectively allow the page to probe for data in the origin's filesystem storage and then send that information back to the server. For example there have been CSS proposals for things like: background: image(url("..."), url("...")); If you point the first URL to a filesystem URL and the second url back to the home server, that would effectively let the home server know if a particular file exists in the user's filesystem API. This will apply to any other data schemes that we create for loading local data, such as if we ever introduce a indexeddb:// url scheme. So basically, from a sandboxing perspective, we should treat "load from local-data-url-schemes" as "run scripts".
Sounded like Adam Barth was ok with this suggestion, though I'll let him speak for himself.
Anne, this is mostly going to be for you. Do you want me to provide a sandbox flag for this that you can hook into?
At what point does this sandboxing apply? Would these URLs just fail to parse or should fetching fail?
I think fetching. Failing to parse would be very odd... I mean, it would make the utility of the parsing API dependent on sandboxing, which is weird.
Is sandboxing part of CSP yet? Because then it could become part of the CSP check Fetch does.
Sandboxing and CSP interact cloely, but they're not part of each other per se.
K, assuming they are distinct, how should this work? http://fetch.spec.whatwg.org/#concept-fetch has a hook for HSTS and soon for CSP (open issue still). Should I add another hook for HTML sandboxing? What do you need passed?
You would just add this to the algorithm: "...if the Document's active sandboxing flag set does not have the sandboxed something-or-other flag set, then..." Then tell me what "something-or-other" should be, and I'll add an appropriate flag. For example, "sandboxed origin-privileged schemes flag" or whatever. See pointer lock for an example of a spec integrating with this.
Fetch currently only has a handle back to a global (request's client). But I guess I can get to a Document from there. "sandboxed local-data scheme flag"?
data: is "local data" too. As is cached HTTP.
Actually, isn't this similar to "sandboxed automatic features browsing context flag" or "sandboxed scripts browsing context flag" combined with an origin check? Is there a reason to have a distinct flag for those two? "sandboxed storage area URLs flag"
"sandboxed storage area URLs flag" works for me. Having more flags is essentially free from the spec point of view and gives us more flexibility later. I expect implementations to actually just have one bit for all the flags that can't be individually controlled.
Okay, sounds good. I'll add placeholder sections to Fetch for these new schemes and implement the desired sandboxing. Where are these new schemes being defined by the way? I've the feeling I might want to give some input to make sure they work nicely with the revamped URL parser.
Checked in as WHATWG revision r8706. Check-in comment: Add a sandboxing flag for use by fetch http://html5.org/tools/web-apps-tracker?from=8705&to=8706
https://github.com/whatwg/fetch/commit/e6fa8899423652413287c0cf22cd074ffed12905