- From: Drew Wilson <atwilson@google.com>
- Date: Thu, 28 May 2009 09:50:08 -0700
On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking <jonas at sicking.cc> wrote: > On Wed, May 27, 2009 at 6:15 PM, Drew Wilson <atwilson at google.com> wrote: > > Along the same lines, I'm wondering why we require a same-domain check > for > > initial worker URLs, but not for script imported via importScripts(). > > This is because workers run in a security context of the initial > worker URL. So this is the origin that is used for security checks > whenever the worker does something, like load data using > XMLHttpRequest. I'm not quite sure why importScripts() should behave more like a <script> tag than the Worker constructor itself. There's no reason why I shouldn't be able to do Worker("http://foo.com/worker.js") if I can do importScript(" http://foo.com/worker.js"). > > importScripts() however behave more like <script> in that they run the > loaded script in the security context of the worked that loaded them. > > > Seems > > like we ought to have workers inherit the origin of the script context > that > > invoked the Worker constructor, but allow the script URL passed to the > > constructor to point at any domain. > > That would be another solution to this problem, however some people > preferred the solution that is currently in the spec. Can anyone explain the motivation? A search of the archives isn't yielding anything particularly useful - the earliest mention I could find was someone from August of last year saying that essentially the same thing: "some people thought it was not safe" with no details. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090528/65a71e6d/attachment.htm>
Received on Thursday, 28 May 2009 09:50:08 UTC