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

On Mon, Mar 17, 2014 at 6:19 PM, Jonas Sicking <> wrote:
> On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <> 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.


Received on Wednesday, 19 March 2014 15:06:24 UTC