Improving Function.prototype.bind

David Bruant bruant.d at gmail.com
Fri Jan 6 08:58:49 PST 2012


Le 06/01/2012 17:43, Mark S. Miller a écrit :
> On Fri, Jan 6, 2012 at 8:31 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 06/01/2012 06:03, Mark S. Miller a écrit :
>
>         Such a built in memoization, whether by boundTo or this
>         enhancement to bind itself, creates a fatal ambient
>         communications channel.
>
>
>            // initSES initialization, freezing all built in
>         primordials other than the true global
>
>            // load Alice as a confined object graph
>
>            // load Bob as a confined object graph. Alice and Bob
>         should not be able to communicate
>            // Covert channels mean we might not be able to prevent
>         them from communicating bits
>            // But we must certainly prevent capability leaks
>
>            Alice says
>
>                Object.boundTo(Object).foo = capabilityBobShouldntGet;
>
>            Bob says
>
>                var HAH = Object.boundTo(Object).foo;
>
>     If Alice and Bob have been loaded as confined object graphs, they
>     could both be exposed different objects for what each refer to as
>     "Object", no?
>
>
> It depends on the intentions of the party that instantiated the 
> confined Alice and Bob -- call her Carol the Confiner, or simply Carol.
>
> If Carol wants to have a rich interaction with Alice and Bob, then she 
> will typically want Alice, Bob, and Carol to all exist within a single 
> SES context (frame) and thereby share the same Object. That way, none 
> of them have to worry about the weird and complex behavior of, for 
> example, instanceof, when computing across multiple frames.
Ok. I forgot that some mecanisms relied on object identity.

> Very concretely, Carol will want to have the same Object as Alice, and 
> to have the same Object as Bob. Therefore, Alice and Bob will have the 
> same Object as each other. Sharing Object and the other accessible 
> built-in primordials (i.e., all the primordials except the global 
> object) is safe in SES because the accessible primordial state 
> contains no communications channels. To a first approximation, it 
> contains no mutable state at all. The only exceptions are Date.now(), 
> Date(), and Math.random(), none of which creates a communications channel.
Indeed. Mutable state does not seem to be the issue by itself. The issue 
would be a mutable state that can be mutated by a script (which isn't 
the case for Date and random)

>
> [...]
>
> > Ps: by the way, what does "HAH" mean?
>
> It is Bob's evil laugh, as Alice and Bob have successfully conspired 
> to leak capabilityBobShouldntGet to Bob.
:-)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120106/e1e264de/attachment.html>


More information about the es-discuss mailing list