Proposal About Private Symbol

[Gary Guo]

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.

```js
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');
        this[Symbol.for('id')]=identifier;
    };
    ret.prototype.set=function(){
        if(this[Symbol.for('id')]!=identifier)throw Error('Invalid This');
        this[sym]=1;
    }
    return ret.bind(undefined);
}();
```
________________________________
> 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. 
>