Blob URL Origin

This email is about the origin of a blob: URL, and corresponds to this specification bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998

1. Syntax on the web, present day.

This is what a blob:URL might look like in Safari:

blob:https://accounts.google.com/e55f2c33-f000-4e88-b89c-874ae09e7f93

Chrome does it like this:

blob:https%3A//accounts.google.com/22f079c8-5dc4-4f1a-bde7-f23ca9a04cbe

Firefox and FxOS, like so:

blob:2e8e7c9e-a5f0-584b-84e6-b5989e226f13

You can see that Safari and Chrome *both* preface the UUID part of the scheme data with a string corresponding to the origin of the URL that coined the blob: URL; they differ on the matter of the ":" (U+003A COLON) character (either using %3A URL encoding or “:” itself).

Only Firefox follows the letter of the present day specification correctly. But, all of these treat the origin of the blob: URL as the origin of the incumbent script settings object of the script which coined the blob: URL. In Firefox, however, you cannot deduce this from the URL alone; it is hidden and part of the context of the URL. 

So this is problematic: we don’t have a common syntax on the web, and even implementations which share code don’t do it exactly the same. Of course, blob: URLs aren’t supposed to be human readable, or really viewed by the developer. But not having a good way to denote origin within the URL that signifies the origin of the incumbent settings object is problematic for Fetch and Parse specifications that need origin information.

I’ll also note that the filesystem URLs, used to access temporary or permanent filesystems on a per domain basis (works only in Chrome for now), look like this:
filesystem:http://example.com/temporary/myfile.png
2. Syntax on the web, future day.
I think we should officialize the Safari version of the blob: URL, and apply some formal strictures around it. For instance, should we allow:
blob:chrome%3A//newtab/702eeefb-d234-4988-a73e-6104f1b615ee
or
blob:file:///foo/UUID
(or other variants of things)? Or leave those undefined?
I think we can safely spec. things for at least the lion’s share of the use cases, but some edge cases will exist.
The origin policy might be that we maintain that the origin is that of the incumbent settings object, and denote this syntactically in the blob: URL, and that the origin of a resource identified by the blob: URL is of that origin, even in cross-origin cases like <img >. This should apply for various proliferating schemes; for instance, filesystem: and mediastream:, which haven’t been formally defined yet.
Feedback / thoughts on this welcome, either on list or in the bug.
— A*