Proposal About Private Symbol

Gary Guo nbdd0121 at
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 constructor=function(){
    'use strict';
    var sym=Symbol('private', true);
    var identifier=Symbol(undefined, true);
    var ret=function(){
        if(this===undefined)throw Error('Cannot be called as function');
        if(this[Symbol.for('id')]!=identifier)throw Error('Invalid This');
    return ret.bind(undefined);
> Date: Sat, 20 Dec 2014 22:48:37 -0500 
> Subject: Re: Proposal About Private Symbol 
> From: zenparsing at 
> To: nbdd0121 at 
> CC: es-discuss at 
>>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 mailing list