[Bug 25914] No definition of parsing blob's scheme data

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

--- Comment #18 from Glenn Maynard <glenn@zewt.org> ---
To recap something from IRC: a problem with the idea of embedding the origin
inside the blob: URL and then extracting it later is that it won't work with
anything that has a unique origin, which includes sandboxed iframes and data:. 
This already works today:

http://zewt.org/~glenn/blob-inside-sandbox.html

We might not care about file:, but we should care about data: and we definitely
care about sandboxed iframes.

Unique origins serialize to "null".  I think there's no way for us to embed the
origin inside the blob URL and then pull it out later--we need the real origin
to do origin checks, not "null" (and not the effective script origin, which is
what sandboxed iframes see in document.location.origin).

This seems to point towards Firefox's "implicit origin" approach: don't put the
origin in the URL at all, so the blob URL is simply "blob:uuid", and store the
origin in the blob URL store.

It seems like we shouldn't expose the origin from URL.origin at all if we do
this.  Otherwise, the result of new URL(blobUrl).origin will be different
before and after blobUrl is revoked, which is unfortunate.  It would also mean
synchronously looking up the URL in the blob URL store to get its origin, which
might be IPC.  I don't know if that's critical, but as far as I know blob URLs
are completely async entities today, which seems like a good thing.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 9 June 2014 14:08:51 UTC