Origin of blob: documents doesn't match implementations

[bzbarsky]

What is the origin of a document loaded from a blob: URL without sandboxing?

Stepping through the "For Document objects" list at https://html.spec.whatwg.org/multipage/origin.html#origin (sadly no direct way to link it):

1. No sandboxing, does not apply.
2. URL is not data:, does not apply.
3. Scheme is not a network scheme, does not apply.
4. Not about:blank, does not apply.
5. Not about:blank, does not apply.
6. Not javascript:, does not apply.
7. Not srcdoc, does not apply.
8. Fall through to DOM behavior, give it a unique origin.

Needless to say, this is not how blob: actually works in browsers, nor how anyone expects it to work. @mikewest @annevk @domenic

What Gecko does in practice is that when you create a Blob URL the association from url to Blob includes an association to the origin of the thing that created the blob, I believe. The load from the blob: URL gets that origin. In particular, if you load a subframe from a blob: URL and then set document.domain (or do it in the opposite order, either way) you are still "same origin-domain" with the blob: thing you loaded. Note that this is not the same thing as javascript: and about:blank origin inheritance, but similar.

[domenic]

This seems to fit into a general known issue, although I'm not sure people have specifically understood the sandboxing case before:

• "origin of a blob URL" is redundant/confusing w3c/FileAPI#63
• Origin of blob URLs doesn't match what implementations do url#127

@mkruisselbrink

It really would be good to get this fixed.

[bzbarsky]

Oh, sandboxing was explicitly brought up in those issues. I wish we had an actual searchable issue database; right now just finding which repo issues are reported against is a total guess. :(

[domenic]

I mean, this is somewhat of a special case as the definition of origin of URL is spread across two specs right now. Over time we should be able to consolidate that into one.

Not sure about how or whether we can deal with the definition of "origin" in general being spread out across HTML/URL/DOM though. I guess I have some ideas but I'll move them to another thread...

[bzbarsky]

Also, it sort of fits into that issue, but note that the basic problem here is that we never even reach the "origin of the URL" bit at all here.

A second problem is that even if we did that might not match UAs in terms of document.domain handling. It looks like I have a testcase written for it already, so maybe I even filed it before... http://web.mit.edu/bzbarsky/www/testcases/security/blob-iframe-document-domain.html shows that Firefox treats the blob: as same origin-domain but Chrome does not. So I'm really not sure what Chrome implements exactly, and in particular how it manages to have nonce origins match but apparently without it being the same origin in general (because the document.domain bits don't match)?

[mikewest]

Hrm. It looks like Chrome is doing the wrong thing here; I agree with @bzbarsky that we ought to be following Firefox's behavior here; I haven't looked at the code, but I assume we're just creating a new origin object rather than aliasing the existing origin, so the domain check fails. Filed https://bugs.chromium.org/p/chromium/issues/detail?id=733351 to track.