[whatwg] Workers and URL origin check

[Jonas Sicking]

On Thu, May 28, 2009 at 9:50 AM, Drew Wilson <atwilson at google.com> wrote:
>
>
> 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() have to behave like <script> since both import script
into an existing security context.

So the question is if the Worker construct should create a new
security context or not.

>> 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.

Personally I don't have a strong opinion either way for dedicated workers.

But I do note that shared workers more or less have to create a new
security context since they can be used by several different windows
and thus it wouldn't make sense for them to use the same security
context as any one of those windows.

/ Jonas