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

Re: Data URL Origin (Was: Blob URL Origin)

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 29 May 2014 18:21:39 +0200
Message-ID: <CADnb78jDaH9QqQaQgvCOGpzg0iv4X07c-P71AjbDOM8Ovt5cmA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> My proposal is something like this:

Thanks!


> * Add a new flag to the fetch algorithm "allow inheriting origin"

"same-origin data URL flag"? Ideally we don't do another data URL mistake.


> * 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.

This does not clarify what happens if you end up at a data URL as a
result of a redirect. If the redirect is cross-origin you'll end up
tainted. If it's CORS you get a network error. But if it's same-origin
that's fair game?


> * I don't know what URL(data).origin should return.

Probably just "null". I think we should make it about the origin of
the request, not the URL.


> * 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 XMLHttpRequest? We decided a while back we wanted data URLs to
work there.


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

Seems fair.


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

Given that workers execute script in a fairly contained way, it might be okay?


-- 
http://annevankesteren.nl/
Received on Thursday, 29 May 2014 16:22:06 UTC

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