W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: On starting WebWorkers with blob: URLs...

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 19 Mar 2014 15:05:57 +0000
Message-ID: <CADnb78hbtrBKoYEfZQjDHvhms6nymd2+X3HYMqD=U353tCGWLg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, Travis Leithead <travis.leithead@microsoft.com>, public-webapps <public-webapps@w3.org>
On Mon, Mar 17, 2014 at 6:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> I don't think this is the way we should go about this. I don't
>> understand why a blob URL would have an origin.
>
> Because URLs with origins are much simpler than what we do for data:.
> The main indicator of that is that we still haven't managed to get
> implementations to agree on how to do security boundaries for data:,
> whereas we're quite well aligned on security boundaries for http:.

I guess it depends on what you want the scope for a blob URL to be. I
don't really see any problem with sharing it with an <iframe> for
instance through postMessage() (the API on the other side only deals
with URLs, not URLs or something else).


> Inheriting origins the way data: does it is actually quite tricky from
> an security point of view. Internally in gecko we're moving towards
> adding a flag whenever we're doing a resource load that indiciates
> "Allow this load to inherit origin if it wants to". The default for
> that flag would be *false*.

That makes sense.


> This is because we have been bit several times by having code from
> security context A (in our case code from chrome://) receive a URL
> from code from security context B. A would then load that URL. This
> way B can trick A into creating content that B controls, but that runs
> with As privileges.
>
> I'd love it if the web also had such an opt-in flag, but I don't know
> how possible that is to create.

We could have an attribute on the various loading contexts, no?


>> Trying to couple origins with strings seems like a bad idea.
>
> Isn't that what http does?
>
> I'd actually love it if data: encoded an origin too in a way that
> prevented the above attack. But that doesn't seem possible.

It seems this would prevent certain scenarios too. Also, I think
coupling tainting with the response makes more sense given service
workers. You could fetch http://crossorigin.example/ and the response
could be generated by a service worker and be untainted. As I
understand the latest discussions, we want that to work. Blob URLs
would not be much different, they would always return untainted
responses, unless a redirect was involved.


-- 
http://annevankesteren.nl/
Received on Wednesday, 19 March 2014 15:06:24 UTC

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