W3C home > Mailing lists > Public > public-web-security@w3.org > March 2011

Interaction with Workers (was Re: setTimeout error handling)

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 28 Mar 2011 17:05:45 -0700
Message-ID: <AANLkTikYJBkGz1W6KsAQtdNYVGQ9gei98c5we=Uz0xzi@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: public-web-security@w3.org
How do these requirements interact with workers?  For example, workers
have setTimeout and setInterval as well.  Also, there's an
importScripts API in WorkerContext.  Should that be restricted by
script-src?

Adam


On Mon, Mar 28, 2011 at 4:55 PM, sird@rckc.at <sird@rckc.at> wrote:
> If this is supposed to take IE quirks into consideration, then
> execScript should be added to that list of forbidden functions.
>
> -- Eduardo
>
>
>
>
> On Mon, Mar 28, 2011 at 3:06 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Sorry for spamming the list with lots of questions.  I'm just emailing
>> questions as they come up in the implementation.
>>
>> [[
>> User-agents must prevent strings from being converted to ECMAScript
>> code, including calls to:
>>
>> eval()
>> new Function() constructor
>> setTimeout() called with a String argument
>> setInterval() called with a String argument
>> ]]
>>
>> Suppose the page does call setTimeout with a string.  How should the
>> user agent handle the error?
>>
>> For example, in Step 6 of
>> http://www.whatwg.org/specs/web-apps/current-work/#dom-windowtimers-settimeout,
>> the user agent is instructed to "Return handle".  Should that step
>> occur or should we return a null handle?  Should setTimeout throw an
>> exception?
>>
>> There are similar questions for the other functions that convert
>> strings to code.
>>
>> Also, what about non-ECMAScript code?  For example, if the user agent
>> supported VBScript as a scripting language (e.g., Internet Explorer),
>> should the user agent prevent strings from being turned into that sort
>> of code?
>>
>> Proposal: We should return a null handle from setTimeout and
>> setInterval.  That lets the page detect the error would being so
>> drastic as to throw an exception.  We could also log to the error
>> console (and of course report via the reporting-uri) to make the error
>> more visible to developers.
>>
>> Adam
>>
>>
>
Received on Tuesday, 29 March 2011 00:07:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 March 2011 00:07:13 GMT