Re: [Workers] Worker same-origin and usage in JS libraries...

On Tue, 6 Dec 2011, Jonas Sicking wrote:
> On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
> > A new scenario just came to my attention that I thought I might
> > pose to the list. Given the current same-origin restrictions on
> > new Worker(), it is problematic for Worker usage by any JS
> > libraries on a CDN.
> >
> > A site using a CDN simply provides an absolute URL reference to
> > the library, and it is subsequently downloaded and executed in
> > the context of the current page's domain. Relative URLs to a
> > worker script will resolve according to the domain of the hosting
> > page:
> >
> > // http://cdn.net/dowork.js which was included from http://test.com/home.htm
> > var w = new Worker("lib/workers/w1.js");
> > // Tries to open http://test.com/lib/workers/w1.js
> >
> > and absolute URLs will fail due to the cross-origin restrictions
> > on the new Worker constructor:
> >
> > // same setup as before
> > var w = new Worker("http://cdn.net/lib/workers/w1.js");
> > // Cross-origin failure from http://test.com/home.htm
> >
> > I looked back through the list and at the original worker proposals
> > to try and discover why the same-origin restrictions is in place.
> >
> > The root of the issue seems to be the expectation that WorkerGlobalScope
> > runs and executes everything according to its own location.URL.
> > Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
> > previous example, would allow http://test.com/home.htm to potentially
> > modify any data associated with cdn.net's domain (like through
> > Indexed DB, or XHR, etc).
> >
> > One way to allow the CDN scenario to work would be to provide an explicit
> > way to tell a worker to run in the host context, rather than the context
> > that the Worker is loaded from (which is what <script> inclusion and
> > importScripts does today).
> >
> > Since Workers _can't_ be loaded cross-origin [currently], the Workers
> > are already running in the host context by virtue of this limitation.
> > Codifying that a WorkerGlobalScope's execution environment is always
> > that of the document that created it, and then allowing workers to be
> > constructed from any URL would effectively solve the CDN problem IMHO.
> >
> > Later, when/if we open up cross-origin workers, we can provide a special
> > way to instruct the workers to set their execution context to that of the
> > URL they are loaded from.
> >
> > Thoughts from the group?
> 
> It's not an entirely bad idea.
> 
> We've solve the solution in a somewhat less elegant way. Since firefox
> generally considers data:-uris to be same-origin with whatever page
> loaded them, you can create a worker using a data:-uri which then
> importScripts the cross-origin script. (This is relatively newly
> implemented so I forget if it's in released versions of firefox).

I've specced this.


> But I can't really come up with any arguments against your proposal...

My plan is to make it so that cross-origin URLs start cross-origin 
workers. The main unresolved question is how to do this in an opt-in 
manner. The best idea I've come up with so far is having scripts that want 
to opt-in to being run in such a way start with a line line:

   // Cross-Origin Worker for: http://example.net

...or (for multiple domains):

   // Cross-Origin Worker for: http://example.com https://example.org

...or (for any domain):

   // Cross-Origin Worker for all origins

...but that doesn't seem super neat.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 17 July 2012 21:53:36 UTC