Proposal About Private Symbol

Gary Guo nbdd0121 at hotmail.com
Sat Dec 20 22:41:16 PST 2014


Oops, mistakes found. I just ignored the fact that in this particular way the Symbol can be retrieved. It seems impossible to have an idea of private symbol in this way. In the case, I think the language can provide a way to distinguish whether an object is created directly by a class/constructor. It seems that there will be no way to prevent that unless the language ensures this.

For example, Add a well-known Symbol @@constructor, and when constructing an object, make sure any objects have a property @@constructor and has the descriptor {enumerable:false, configurable:false, writable: false, value: *The constructor that actually creates the object*}
```js
var constructor=function(){
    'use strict';
    var sym=Symbol('private', true);
    var ret=function(){
    };
    ret.prototype.set=function(){
        if(this[Symbol.constructor]!=ret)throw Error('Invalid This');
        this[sym]=1;
    }
    return ret.bind(undefined);
}();
```

----------------------------------------
> From: nbdd0121 at hotmail.com
> To: es-discuss at mozilla.org
> Subject: RE: Proposal About Private Symbol
> Date: Sun, 21 Dec 2014 12:08:09 +0800
>
> 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.
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
 		 	   		  


More information about the es-discuss mailing list