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

[+google-caja-discuss] which was actually added but not annotated in my last
message.


On Tue, Jun 28, 2011 at 5:33 PM, James Robinson <jamesr@google.com> wrote:

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

Caja and SES are designed to support two modes: Coarse-grain confinement
(sandbox mode), which addresses only the offensive code problem, and fine
grained object-capability security (ocap mode), which also addresses the
defensive code problem. (SES currently only supports ocap mode, but sandbox
mode support is coming.) In the ocap mode, individual objects can defend
their own integrity, and the programmer can treat arbitrary subgraphs, down
to individual objects if desired, as separate protection domains. In ocap
mode, mutually suspicious subgraphs of objects share the same JavaScript
context. It would cause terribly awkward patterns to have to create separate
virtualizations of setTimeout/setInterval whenever crossing a trust
boundary. And the need to spawn this multiplicity of setTimeout/setInterval
identities would cause a greater deviation from existing stds than simply
making the returned result opaque.

By allowing all ocap code granted access to setTimeout/setInterval in the
same JavaScript context to share the same setTimeout/setInterval constructs,
the normal patterns of use become generally compatible with fine grained
security -- but only if the returned object represent the unforgeable right
to cancel a scheduled event.



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


-- 
    Cheers,
    --MarkM