Whitelist WeakSet

[David Bruant]

Le 25/09/2012 07:49, Tom Van Cutsem a écrit :
> 2012/9/25 Waldemar Horwat <waldemar at google.com
> <mailto:waldemar at google.com>>
>
>
>     Yes.  This was bothering me during the meeting and (as far as I
>     know) didn't get resolved.  What if someone passes in a proxy to a
>     WeakSet instead of an actual WeakSet?
>
>     A.  Allowed.  Then the security protocol is utterly broken.
>
>     B.  Disallowed.  Now we have a class that can't be proxied.
>
>     Neither sounds good.  What am I missing?
>
>
> I intended option B. The whitelist can't be proxied.
>
> It's not that WeakSets can't be proxied in general (they can), but for
> the specific use of a WeakSet as a whitelist, the proxy needs a
> genuine WeakSet. This isn't all that different from DOM methods
> requiring genuine DOM elements, etc.
>
> I also don't see how membranes would require proxied whitelists: it
> would be weird to construct a Proxy whose whitelist must be a
> membraned object. I think of a newborn Proxy and its whitelist as
> being part of the same abstraction. It makes little sense to separate
> them by a membrane.
I'm thinking of an example like what can be seen in some of Mark's
presentation with one actor creating 2 subgraphs of objects Alice and
Bob. Thanks to some language property, Alice and Bob are only connected
through their creator and any communication is mediated by this creator.
Both subgraphs can be membraned so that their creator can stop any
communication between both anytime.
Now, let's say Alice wants to share knowledge of some private names with
Bob. She can send a WeakSet. But as she does that, the mediation
membrane wraps the WeakSet and Bob only ever gets the wrapped version.
This wrapped version is unusable for Bob to create proxies (assuming the
handler and Proxy constructor are provided by Bob).

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