Data URL Origin (Was: Blob URL Origin)

On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> How do we deal with data URLs? Obviously you can always get a resource
> out of them. But when should the response of fetching one be tainted
> and when should it not be? And there's a somewhat similar question for
> about URLs. Although only about:blank results in something per the
> specification at the moment.

My proposal is something like this:

* Add a new flag to the fetch algorithm "allow inheriting origin"
* The default for this new flag is "false"
* If the flag is set to false, the origin of the URL is a unique identifier.
* When the origin is a unique identifier, it would not match any other
origin and so responses would always be tainted.
* If the flag is true, then the origin of the URL is equal to that of
the page that initiated the load.
* When the origin of the URL is inherited, it would always match the
origin of the caller, and so responses would never be tainted.
* I don't know what URL(data).origin should return.
* Make APIs explicitly opt in to setting the "allow inheriting origin"
flag to true based on whatever policies that we decide.

So for example we could make <img> always set the "allow inheriting
origin" flag to true.

And for <iframe>s the flag would only be true if some <iframe
allowinheritingoriginfordataurlsplease> attribute was set. And then it
would still only be set for the initial load. If the iframe navigated
(through a link or through setting window.location) the flag would be
set to falls.

For `new Worker(...)` I'm not sure what would be web compatible. I'd
prefer if the flag was set to false by default, but that the page
could use some explicit syntax (similar to the <iframe>) to opt in to
allowing inheriting.

/ Jonas

Received on Thursday, 29 May 2014 07:07:57 UTC