W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2011

Re: [RequestAnimationFrame] Integer identifiers: let's not make the same mistake again.

From: James Robinson <jamesr@google.com>
Date: Tue, 28 Jun 2011 16:33:57 -0700
Message-ID: <CAD73md+K5e4oTNycfUyPXccfT91rGo=d8GD6dN+3qxD-dBhaAA@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: David Bruant <david.bruant@labri.fr>, public-web-perf@w3.org, Google Caja Discuss <google-caja-discuss@googlegroups.com>
On Tue, Jun 28, 2011 at 4:29 PM, Mark S. Miller <erights@google.com> wrote:

> On Tue, Jun 28, 2011 at 3:37 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>> James Robinson:
>> > I'm not sure I understand exactly what you mean here - script can only
>> > cancel timers that it set.  Could you expand a bit on what you mean by
>> > "granted the right to do so"?
>> And if script you don’t control is running on your page, it being able
>> to cancel your requestAnimationFrame calls is probably the least of your
>> worries.
> Not any more:
> http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/
> Original announcement at
> https://mail.mozilla.org/pipermail/es-discuss/2010-August/011684.html
> Presentation http://www.infoq.com/presentations/From-E-to-EcmaScript
> Interview
> http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security
> With the improvements made by EcmaScript 5 and initSES.js, enabling Secure
> EcmaScript (SES), in most ways we now have better protection from untrusted
> code within a web page than we do between pages at different origins. SES
> strives to be a compatible subset of ES5, and its DOM taming, Domado,
> strives to be a compatible subset/virtualization of the browser DOM API.
> We achieve this goal almost perfectly. One place we had to violate the
> subset rule is setTimeout/setInterval. In Caja and SES, these return opaque
> objects, not integers, precisely for the reasons given at the start of this
> thread. So far, we have encountered no legacy code broken by this change. If
> the w3c does make this mistake again, Caja and SES will violate the standard
> again in precisely the same way and for the same reason. I suspect the
> effect of this violation to be as painless on actual code. Still, it would
> be better for w3c/whatwg to avoid this mistake, as proposed in this thread.

I'm aware of caja but do not see how that is relevant to this discussion.
 Caja wraps native APIs like setTimeout/clearTimeout, right?  It should be
possible to implement any sort of guards around the values allowed at this
level without changing the type of the identifier.  For example, you could
remap the values returned by the user agent to another integer range or
check that a clearTimeout() from a given script is ignored if it does not
correspond to an earlier setTimeout() associated with the same value.  I'm
not sure why you chose to have caja return opaque identifiers (as that seems
unnecessary) but you could do that as well, I suppose.

- James

>> > The reason for using integer identifiers is to remain close to
>> > setTimeout/setInteval, but I think an opaque identifier would work
>> equally
>> > well.  I'm not sure what benefit it would give, however.
>> I agree, I don’t see it providing enough benefits to warrant changing.
>> --
>> Cameron McCormack ≝ http://mcc.id.au/
> --
>     Cheers,
>     --MarkM
Received on Tuesday, 28 June 2011 23:34:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC