Re: Blob URL Origin

One thing to note here is that the goal of the design is to have blob:
URLs represent the origin that created the URL. Not the "inherits
origin from who triggered the load" like data:.

A strong reason not to go with the data: design is that data: is still
not implemented consistently across browsers. It's fairly clear that
the current spec for data: isn't going to be implemented as-is (I
think gecko is has the closest implementation, and I'd prefer to
change Gecko to be closer to what other browser do, than the other way
around, see my proposal about explicit opt-in).

So rather than have blob: behave like something that we don't even
know how it should work, lets make blob: instead behave like schemes
where the security model is much more understood and consistently
implemented.

/ Jonas

On Fri, May 9, 2014 at 2:29 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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*
>
>
>
>
>

Received on Friday, 9 May 2014 23:23:30 UTC