Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Mark Miller erights at
Tue Jan 29 07:24:09 PST 2013

On Mon, Jan 28, 2013 at 11:27 PM, Brandon Benvie
<brandon at>wrote:

> I realized the discrepancy between my thinking and what you said. In the
> case of a membrane, you are correct. A membrane will always unwrap
> everything, so you will only ever end up with dry method/dry this. That
> makes all the different forms of private equivalent.

Hi Brandon, just to be clear, so this statement of "equivalence" is not
misunderstood later: They are "equivalent" only in the limited scenario you
outline, where the private-symbol/weakmap does not cross the membrane
boundary. When it does, for all eight cases that arise, the weakmap
maintains transparency. The private-symbol does not.

> The difference arises when you're not dealing with a membrane, rather just
> a one shot proxy. In this case, you often do end up with (to borrow
> membrane the membrane terminology) dry method/wet this. this is the
> specific circumstance (and I believe the likely most commonly encountered
> one) in which auto-unwrapped private symbols do the right thing when the
> other private forms fail to work correctly.
> On Monday, January 28, 2013, Mark S. Miller wrote:
>> So the corresponding WeakMap situation would be one where the WeakMap o2
>> is never passed through the membrane, so there is no p2 on the other side
>> of the membrane. In that scenario, AFAICT PrivateSymbol proposal #1, #2,
>> and WeakMaps are all equivalent. Not so?
>> On Mon, Jan 28, 2013 at 4:19 PM, Brandon Benvie <
>> brandon at> wrote:
>>> The assumption that my conclusion on auto-unwrapping rests on is that
>>> the situation shouldn't arise where a wet value is set as a dry object's
>>> private property. The reasoning is that the private key is presumed to be
>>> something closely guarded and that won't be shared in such a way that this
>>> happens. This assumption is the underpinning of the whole thing, so it's
>>> the real point of contention.
>> --
>>     Cheers,
>>     --MarkM

Text by me above is hereby placed in the public domain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list