A .js file intended to be used in a worker can check an incoming
message.origin before it calls allowCrossOrigin, but currently (unless
I've missed something) a worker can't discover its own origin [1].
Thus, you can do something like, "I'm hosting my code on example.com,
so my .js file will do an explicit comparison with that hard-coded
string", but not, "here's some generic, cross-origin aware worker
code, feel free to copy to your website".
So, I'm thinking of adding an origin property on the workerpool, so
that you can, in a worker, do things like
google.gears.workerPool.onmessage = function(a, b, msg) {
if (msg.origin != google.gears.workerPool.origin) {
return;
}
google.gears.workerPool.allowCrossOrigin();
// do more stuff
}
This is trivial to implement, since every gears module knows its own
SecurityOrigin (via its ModuleEnvironment).
Any comments? One thing is that, IMHO, an origin is more a property of
the factory than a workerpool (and that allowCrossOrigin should have
been a method on a GearsFactory, not a GearsWorkerPool), but since
allowCrossOrigin is already on a GearsWorkerPool, I thought to keep
the origin property on the same thing.
[1] Well, I suppose it could sendMessage to a range of ints, hope that
one of those outbound messages is delivered to itself, and then check
message.origin of the message it sent to itself, but, yuck.
