Proposal About Private Symbol
nbdd0121 at hotmail.com
Sat Dec 20 20:08:09 PST 2014
Technically speaking there is no way to prevent such a attack, since in the debugger everything can be exposed to external environment. Careful check is still needed with private symbols according to my proposal.
var sym=Symbol('private', true);
var identifier=Symbol(undefined, true);
if(this===undefined)throw Error('Cannot be called as function');
if(this[Symbol.for('id')]!=identifier)throw Error('Invalid This');
> Date: Sat, 20 Dec 2014 22:48:37 -0500
> Subject: Re: Proposal About Private Symbol
> From: zenparsing at gmail.com
> To: nbdd0121 at hotmail.com
> CC: es-discuss at mozilla.org
>>2. They would not invoke any traps on proxies.
>>3. They would not tunnel through proxies to proxy targets.
>>4. Getting a private-symbol-keyed property would not traverse the
> prototype chain of the object (perhaps arguable).
> Unnecessary, as long as symbol doesn't leak to external environment, I
> don't think we need to impose these constraints. Without these
> constraints I did not see any problems there.
> You simply cannot allow 2 and 3 and still call them private symbols.
> If you allow 2, then an attacker can discover private symbols by
> creating a proxy for an object which uses them in one of its methods.
> If you allow 3, then private symbols are an unmediated communication
> channel across membranes.
More information about the es-discuss