W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 7 Dec 2011 01:05:24 +0000
To: public-webapps <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>
Message-ID: <9768D477C67135458BF978A45BCF9B38381C3D09@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
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?

-Travis
Received on Wednesday, 7 December 2011 01:06:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT