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 <[email protected]>
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.
