[whatwg] Using Web Workers without external files

Fri Sep 25 06:26:40 PDT 2009

I think that Workers should retain the same-origin policy.  There is no 
reason to use an "ugly hack" to bring in source from another domain, 
there is a really "normal" way to do it given the current spec.

If there exists the need for a worker that runs cross-domain code 
(whether that code is "worker" code or library code or whatever), the 
Worker has access to XmlHttpRequest.  Using XmlHttpRequest rather than 
allowing the Worker to go cross-domain gives the programmer a place to 
(attempt to) check or sandbox the code before the code is executed.

The "externalStub.js" example of an "ugly hack" is just this same style 
with an implied load of the external source via XHR by the script 
executing in the window context.  Rewrite it as:

<script type="text/javascript">
var loaderWorker = new Worker("loader.js");
loaderWorker.post({load: "http://www.foo.com/bar.js", check: "md5", 
hash: "...", sandbox: true});
</script>

Maybe it doesn't look so ugly now?

Even though this seems like a big PITA right now, as we move farther 
along the web-as-application path, the security implications of all this 
distributed code and what to trust and when to trust it are going to 
come back and bite us.  Same origin is really the only mechanism we have 
right now to establish any kind of trust and shouldn't be taken lightly.

Regards,
Jonathan 'J5' Cook

Simon Pieters wrote:
> On Wed, 23 Sep 2009 23:40:41 +0200, Jonas Sicking <jonas at sicking.cc> 
> wrote:
>
>> You can also work around it by doing something like this:
>>
>> test.html:
>> <!DOCTYPE html>
>> <html>
>> <head><title>example</title>
>> <script>
>> str = "<script to evaluate>";
>> w = new Worker("externalStub.js");
>> w.postMessage(str);
>> </script>
>> </html>
>>
>> externalStub.js:
>> onmessage = function(e) { eval(e.data); }
>
> Ah, yep. Still requires an external file, but it could be the same for 
> different uses. Or it could be combined with my hack:
>
>    <!--
>    onmessage = function(e) { eval(e.data); }
>    /*
>    -->
>    <!DOCTYPE html>
>    <script>
>    str = "...script to evaluate...";
>    w = new Worker("");
>    w.postMessage(str);
>    </script>
>    <!--
>    */
>    //-->
>
> or even:
>
>    <!--
>    onmessage = function(e) { eval(e.data); }
>    /*
>    -->
>    <!DOCTYPE html>
>    <script type=text/x-worker id=worker>
>    ...script to evaluate...
>    </script>
>    <script>
>    str = document.getElementById('worker').text;
>    w = new Worker("");
>    w.postMessage(str);
>    </script>
>    <!--
>    */
>    //-->
>
>
>> What's the use case?
>
> As I said:
>
>>> This would allow easier testing, mashups, small standalone apps, and 
>>> so forth.
>
> In particular, though, I suspect that people will work around this 
> limitation by one of the means we've come up with so far, or maybe 
> people with come up with even uglier workarounds. If we remove the 
> limitation, people will have no reason to come up with ugly hacks but 
> instead use the obvious supported way to do it, and it will be easier 
> to debug and follow code.
>
>
>> I think making data: urls is an ok solution,
>> unless the usecases are compelling enough that we think it's something
>> that people will do a lot.
>
> Yeah, I think supporting data: URLs would be good.
>