Re: Blob URL Origin

On Jun 9, 2014, at 3:23 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, May 29, 2014 at 11:42 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> However, I wonder if this at a standards level should come into play
>> in the URL parser. After all that creates a structured clone of the
>> blob in question. The lookup for the blob ID should probably fail at
>> that point meaning it does not really matter when you then try to
>> fetch that URL as it will simply not have an associated blob.
> 
> I filed a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987 for
> this, but it seems worth discussing here.
> 
> A blob URL store is already limited to all the origins that can reach
> each other through document.domain. So cross-origin blob usage was
> already limited per the specification. It seems like what we should do
> is instead make this a same-origin store. And then when URLs are
> parsed you'd only have access to the same-origin (and *not* effective
> origin) blob URL store. In turn that means it does not matter much
> whether you put origins in the blob URLs, but I suppose we cold do it
> for clarity. It would also make new URL(blobURL).origin work.


Right now, the Blob URL Store is defined in terms of units of similar-origin browsing contexts; each unit is required to have a Blob URL Store. As you point out, that allows all origins within document.domain access to a given Blob URL Store.

We could:

1. Require that entries in the Blob URL Store also store origin (namely the effective script origin of the settings object when the URL was created), in addition to identifier and reference to the Blob object. Requests without same origin as that of the entry in the Blob URL store for that identifier must fail. This keeps the Blob URL Store requirement as is, but adds origin as something in the store.

2. Define it strictly as a same-origin store. I’m a bit fuzzy on how exactly to define this; for instance, strictly the origin and not the effective script origin of a Document?

— A*

Received on Monday, 9 June 2014 22:17:23 UTC