W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Blob URL Origin

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 10 Jun 2014 08:57:57 +0200
Message-ID: <CADnb78iAK9q3Or6z4WDNgfV-25y54qFJ0zrXVwi7W1EK8Ouo-Q@mail.gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Jun 10, 2014 at 12:16 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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.

Yeah, so unlike what the discussion claimed thus far, we did not in
fact allow that much cross-origin blob URL usage. Only origins within
the document.domain reach.


> 1. Require that entries in the Blob URL Store also store origin

I thought this was the idea. The "identifier" would be
"http://someorigin:70/uuid".


> 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?

We could say that the store is bound to a global object. And then both
URL.createObjectURL() and places that parse URLs hook into the entry
setting object's global object's blob URL store.

At that point the only benefit of putting the origin into the URL is
so that new URL(blob).origin works.


Something that is still unclear to me is what happens when you
navigate to a blob URL. I guess that still technically works as the
URL parsing would happen within the correct global.


-- 
http://annevankesteren.nl/
Received on Tuesday, 10 June 2014 06:58:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC