Le 25/09/2012 07:49, Tom Van Cutsem a écrit : > 2012/9/25 Waldemar Horwat <[email protected] > <mailto:[email protected]>> > > > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
