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

2013/1/28 Tom Van Cutsem > I just wrote up a strawman on the wiki to summarize the recent debates > about the interaction between proxies and private symbols: > > http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled > > The page actually lists two proposals, out of which I prefe

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

Brandon Benvie wrote: To elaborate, I've realized that my main disagreement with your position (really my care at all with the private discussion) is much better solved by introducing [[CallProperty]]. That is: Proxies currently ... and complicates object model. My main problem with [[CallPro

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

To elaborate, I've realized that my main disagreement with your position (really my care at all with the private discussion) is much better solved by introducing [[CallProperty]]. That is: Proxies currently handle |this| binding of method calls very poorly. I'm all for either removing private or ma

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

Yes, apologies. I meant equivalent in delivering the "final product", or the desired result of the operation as a whole from the the standpoint of the original architect. They are not equivalent on all the other ways discussed at length otherwise. On Tuesday, January 29, 2013, Mark Miller wrote:

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

On Mon, Jan 28, 2013 at 11:27 PM, Brandon Benvie 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 differen

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

I would then suggest, as awb has, the creation of CallProperty (or Invoke) which fixes the problem in most circumstances. With the existence of WeakMaps and private symbols, the dry method/wet this problem is going to be an extremely common one. On Tue, Jan 29, 2013 at 3:19 AM, Tom Van Cutsem wr

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

2013/1/29 Brandon Benvie > 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.

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

2013/1/28 Andreas Rossberg > On 28 January 2013 19:45, Tom Van Cutsem wrote: > > I just wrote up a strawman on the wiki to summarize the recent debates > about > > the interaction between proxies and private symbols: > > > > http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled

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

2013/1/28 Mark S. Miller > Hi Tom, as you and I discussed in chat, "(base case) there are no > built-in private symbols in a standard JS environment (i.e. all the > built-in symbols are unique)" is a bad misunderstanding of the utility of > membranes. Membranes (and membrane-like patterns) are us

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

2013/1/28 David Bruant > I don't understand why problem B isn't solved with the first proposal. > Since the proxy is pierced, access to private symbol'ed properties don't > trap and the proxy can't throw on access (since it's not trapped). > If I'm misunderstanding the proposal, could you show an

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

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. The difference arises when you're

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

On Mon, Jan 28, 2013 at 3:59 PM, Mark Miller wrote: > Tor this[symbol] = value or equivalent on one side of a membrane, followed > by this[symbol] or equivalent on the other side of the membrane, we have > the following eight cases. > That should be "For thing[symbol] = value or equivalent...by

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

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

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

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

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

Tor this[symbol] = value or equivalent on one side of a membrane, followed by this[symbol] or equivalent on the other side of the membrane, we have the following eight cases. For all of these, o1 is the original non-proxy thing associated with the private properties. p1 is the proxy result of pass

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

On Mon, Jan 28, 2013 at 11:52 AM, Andreas Rossberg wrote: > On 28 January 2013 19:45, Tom Van Cutsem wrote: > > I just wrote up a strawman on the wiki to summarize the recent debates > about > > the interaction between proxies and private symbols: > > > > http://wiki.ecmascript.org/doku.php?id=st

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

On 28 January 2013 19:45, Tom Van Cutsem wrote: > I just wrote up a strawman on the wiki to summarize the recent debates about > the interaction between proxies and private symbols: > > http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled > > The page actually lists two proposals

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

On Mon, Jan 28, 2013 at 11:10 AM, David Bruant wrote: > Hi Tom, > > Thanks for this summary. > About the first proposal and getting rid of the whitelist, indeed, the > whitelist was here to tell about known symbols to avoid leakage. If private > symbols pierce proxies, the whitelist has no purpos

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

Hi Tom, as you and I discussed in chat, "(base case) there are no built-in private symbols in a standard JS environment (i.e. all the built-in symbols are unique)" is a bad misunderstanding of the utility of membranes. Membranes (and membrane-like patterns) are useful and needed at many finer-grain

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

Hi Tom, Thanks for this summary. About the first proposal and getting rid of the whitelist, indeed, the whitelist was here to tell about known symbols to avoid leakage. If private symbols pierce proxies, the whitelist has no purpose any longer. I don't understand why problem B isn't solved wi

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

I just wrote up a strawman on the wiki to summarize the recent debates about the interaction between proxies and private symbols: http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled The page actually lists two proposals, out of which I prefer the second one. If I forgot some b

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

Just to clarify, the example I gave of WeakMap usage breaking with proxies was just to illustrate how a type of private data currently in use alongside proxies can break the target object purely by accident. While I do think [[CallMethod]] would go a long way to ameliorating the problem, I still be

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

Le 24/01/2013 09:52, Tom Van Cutsem a écrit : 2013/1/23 David Bruant mailto:bruan...@gmail.com>> Le 23/01/2013 09:38, Tom Van Cutsem a écrit : 3) because of JS's "invoke = get + apply" semantics, by default a proxy always leaves the |this| value pointing at the proxy

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

2013/1/23 David Bruant > Le 23/01/2013 09:38, Tom Van Cutsem a écrit : > >> 3) because of JS's "invoke = get + apply" semantics, by default a proxy >> always leaves the |this| value pointing at the proxy. >> >> Looking only at 3), sometimes this is what you want, and sometimes it >> isn't. >> > I

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

Le 23/01/2013 09:38, Tom Van Cutsem a écrit : 3) because of JS's "invoke = get + apply" semantics, by default a proxy always leaves the |this| value pointing at the proxy. Looking only at 3), sometimes this is what you want, and sometimes it isn't. In which case would it be what you want? The

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

Tom Van Cutsem wrote: 2013/1/23 Brendan Eich mailto:bren...@mozilla.com>> Brandon Benvie wrote: It is my opinion that the primary use case for private symbols is for properties that proxies expressly shouldn't be given a chance, in any manner, to corrupt or modify. T

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

2013/1/23 Tom Van Cutsem > Looking back at the code for an identity-preserving membrane < > http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_identity-preserving_membrane> > I think this membrane actually properly unwraps the |this| value before > forwarding. > The relevant line of code

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

2013/1/23 Brendan Eich > Brandon Benvie wrote: > >> It is my opinion that the primary use case for private symbols is for >> properties that proxies expressly shouldn't be given a chance, in any >> manner, to corrupt or modify. They are likely used for sensitive internal >> state that will only b

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

Brandon Benvie wrote: It is my opinion that the primary use case for private symbols is for properties that proxies expressly shouldn't be given a chance, in any manner, to corrupt or modify. They are likely used for sensitive internal state that will only be accessed by methods or friend class

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

Le 22/01/2013 20:05, Tom Van Cutsem a écrit : 2013/1/22 David Bruant mailto:bruan...@gmail.com>> Just realizing now, but how does the membrane do the symbol unwrapping if private symbols pierces it? 2 contexts A and B share a symbol, the symbol initially has to go through a publi

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

2013/1/22 David Bruant > Just realizing now, but how does the membrane do the symbol unwrapping > if private symbols pierces it? > 2 contexts A and B share a symbol, the symbol initially has to go through > a public channel (get trap with a string name for instance) and if A > created a symbol a

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

Le 22/01/2013 16:13, Tom Van Cutsem a écrit : 2013/1/22 Allen Wirfs-Brock > We can probably fix the built-ins with some ad hoc language about them automatically resolving proxies to the target as the this value. Or perhaps we could expand the internal MO

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

On Jan 22, 2013, at 9:06 AM, Brandon Benvie wrote: > Kevin Smith pointed out something I hadn't though about before but is obvious > in retrospect. The hazard that proxies bring to the language in general: > proxies make it possible to break the target object by inconsistently > handling forwa

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

Kevin Smith pointed out something I hadn't though about before but is obvious in retrospect. The hazard that proxies bring to the language in general: proxies make it possible to break the target object by inconsistently handling forwarding during the operation of methods. class Counter {

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

2013/1/22 Allen Wirfs-Brock > We can probably fix the built-ins with some ad hoc language about them > automatically resolving proxies to the target as the this value. Or perhaps > we could expand the internal MOP api to include a resolve proxy to target > operation. > > Using private symbols fo