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


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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC