This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0683.html we might need to revisit our strategy. It seems we've already given the URL parser access to the global environment so it can reach the blob URL store. However, the scope of the blob URL store also encompasses global environments that can be reached solely through document.domain and so not all of them are same-origin. So I guess in addition a same-origin check is in order. I guess we should do the same-origin check in the URL parser so it's deterministic. And then fetching a URL which has an associated object will just never fail. Does that make sense?
(In reply to Anne from comment #0) > Given > http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0683.html we > might need to revisit our strategy. > > It seems we've already given the URL parser access to the global environment > so it can reach the blob URL store. > > However, the scope of the blob URL store also encompasses global > environments that can be reached solely through document.domain and so not > all of them are same-origin. So I guess in addition a same-origin check is > in order. I guess we should do the same-origin check in the URL parser so > it's deterministic. > > And then fetching a URL which has an associated object will just never fail. > > Does that make sense? It makes sense, but I'm not clear what pieces of the origin check occur in the URL Parser vs. what occur in File API. Units of same origin browsing contexts maintain a Blob URL Store. Where should the origin check happen?
Is it actually harmful if foo.bar.com and bar.com can reach each other's blob URLs? Note that browsers do allow this today: https://services.zewt.org/test-blob-url-origin-after-change.html prints "test" in both Chrome and FF.
Glenn, that is not testing this scenario. You need to actually use an <iframe> on zewt.org that also sets document.domain and then I guess try to create a Blob in one window and use it in the other. Just setting document.domain does not really change the origin. It just changes what origins can be reached because the effective script origin changes.
(In reply to Anne from comment #3) > Glenn, that is not testing this scenario. You need to actually use an > <iframe> on zewt.org that also sets document.domain and then I guess try to > create a Blob in one window and use it in the other. Just setting > document.domain does not really change the origin. It just changes what > origins can be reached because the effective script origin changes. Well, here's a test such as the one described: http://foo.aruner.net/resources/BlobURL/blobURLTestContainer.html If you comment out the 'document.domain = "aruner.net";' part, the iframe accesses the parent.url variable (which is a Blob URL) and prints "test" to the console. If you don't comment it out, it raises a security exception in Chrome and Fx resembling: "Uncaught SecurityError: Blocked a frame with origin "http://foo.aruner.net" from accessing a frame with origin "http://foo.aruner.net". The frame requesting access set "document.domain" to "aruner.net", but the frame being accessed did not. Both must set "document.domain" to the same value to allow access." Of course, if you also put a "document.domain="aruner.net";' in the page containing the iframe (the "parent"), then it prints "test" (but they are effectively same origin anyway, irrespective of document.domain). http://aruner.net/resources/BlobURL/blobURLTestContainer.html fails to print "test", even if both frames set document.domain to equal values. User agents are more conservative than the spec., which has a consistency bug: cross-origin requests are not allowed *strictly* but we make it seem that document.domain usage *is* allowed in the way we've defined the Blob URL Store. So, I think the right thing is to make it a same origin Blob URL Store along the lines of the correspondence, in which one of the suggestion is to bind the Blob URL Store to a global object. Blob URLs' origin is the origin of the settings object of the global object.
This is fixed per discussions on the listserv. 1. The Blob URL Store is no longer between "units of similar origin browsing contexts" but on the global object that supports URL.createFor or URL.createObjectURL. http://dev.w3.org/2006/webapi/FileAPI/#lifeTime http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL 2. Origin extraction is through recursive invocation of basic URL parsing, which parses identifiers (scheme data components of Blob URLs) into scheme, host, port; we return a tuple of these. http://dev.w3.org/2006/webapi/FileAPI/#extractionOfOriginFromIdentifier If further spec problems/bugs exist, I'd prefer *specific* bugs rather than re-opening this.