This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says: > This scheme should have an origin policy and a lifetime stipulation, to allow > safe access to binary data from web applications. ...but where is this actually defined?
Some have argued (Cc annevk)
(In reply to Arun from comment #1) > Some have argued (Cc annevk) (I'm sorry, I inadvertently submitted too soon). Some have argued (Cc annevk) that blob: URLs shouldn't have origin strictures, and be like data: URLs. The spec originally specified Blob URLs to be origin-restricted to having the same origin as the script that invoked URL.createObjectURL. Jonas points out that data: URLs are a poor role model, since they are inconsistently implemented across UAs. On balance, I think I should add the same origin restriction as we originally had, namely origin-restriction to the origin of the script which calls URL.create*.
data: URLs have a defined origin: http://tools.ietf.org/html/rfc6454#section-4 I don't really mind what the origin of blob: URLs is, but if it's not the usual origin, we should define it. Right now the spec says it should have a special origin, but doesn't say what it is. Note that I'm not talking about the origin of resources generated from blob: URLs, I'm talking about the origin of the blob: URLs themselves. (If we define blob: URLs as having the same origin as their resource, though, it would make certain things work really well. For example, it would mean workers automatically supported blob: URLs.)
How's http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL ? Reopen this bug if necessary. Note that the Blob URL Store is maintained by units of similar origin browsing contexts; revoking a Blob URL across windows within an origin works, so some part of the functionality of Blob URLs is restricted to same-origin Blob URL Stores.
Right, I mean blob URLs should have a unique identifier as origin so we don't mix strings with origin data. The way blob URLs should work is that they don't return a tainted response when fetched and therefore workers should automatically work.
(In reply to Anne from comment #5) > Right, I mean blob URLs should have a unique identifier as origin so we > don't mix strings with origin data. The way blob URLs should work is that > they don't return a tainted response when fetched and therefore workers > should automatically work. Well, I think the formulation based on script also ensures that workers automatically work. What's *wrong* with the script-based origin?
You cannot use the blob URL on a different origin. Also, does the specification define how you extract the origin out of a blob URL, or is the encoding left to the implementation?
(In reply to Anne from comment #7) > You cannot use the blob URL on a different origin. Also, does the > specification define how you extract the origin out of a blob URL, or is the > encoding left to the implementation? But I think not using the blob URL on a different origin is ok? You can always postMessage the actual Blob, and then mint a Blob URL for use with *that* origin, though. Also, as it currently stands, the specification does nothing more significant than equating the origin of the Blob URL with that specified by the incumbent settings object for the script at the time the create* method was called. IMHO that makes it pretty clear how to extract the origin, no?
It seems annoying that if you have an API that takes a URL you need to ask the person providing that API to also support Blob objects... I don't see how that makes it clear. You have a blob URL, which is a string, how do you get the origin out of it?
(In reply to Anne from comment #9) > It seems annoying that if you have an API that takes a URL you need to ask > the person providing that API to also support Blob objects... Well, it's true that they are currently coupled; that is, the API that minted the Blob URL has to know about the Blob, and that's the origin of the Blob URL also, since the incumbent settings object provides the global out of which the create* is called. This seems safe and conservative for file resources. > > I don't see how that makes it clear. You have a blob URL, which is a string, > how do you get the origin out of it? You cannot. As specified, the scheme data is only a resource identifier, not an origin identifier, and you can't look at the string that is the Blob URL and conclude anything about origin. I don't imagine anyone is really going to be looking at the string that is the Blob URL. Your proposal is to simply do exactly what we do for data URLs, right?
The implementation is going to look at that string and wanting to know the origin of it... How else is it going to do origin-comparison? Yes, my proposal is to do like data URLs, but that does mean blob URLs work across origins (which I think might be desirable, but others might disagree).
(In reply to Anne from comment #11) > The implementation is going to look at that string and wanting to know the > origin of it... How else is it going to do origin-comparison? The same way it does origin comparisons based on the incumbent settings object? That is, the same way scripts are origin-restricted. > > > Yes, my proposal is to do like data URLs, but that does mean blob URLs work > across origins (which I think might be desirable, but others might disagree). This thread isn't resolved properly, and I can't change the origin policy till that happens: Start here: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0442.html Specifically, I want to understand: "This is because we have been bit several times by having code from security context A (in our case code from chrome://) receive a URL from code from security context B. A would then load that URL. This way B can trick A into creating content that B controls, but that runs with As privileges. I'd love it if the web also had such an opt-in flag, but I don't know how possible that is to create." Which is found: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html A conservative way to thwart this is to make the URL from B not loadable in A. This isn't about the guessability of the URL either.
Before we do origin handling for anything like we do origin handling "like data URLs" we should actually make sure that the origin handling of data URLs is something that browsers agree on. Right now the origin handling for data URLs differ between browsers. And the way that we handle them in Gecko has caused security issues in our chrome. I would expect websites to be hitting those same issues. http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html
Marking this fixed based on listserv discussions and recent specification update: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL