Proposal About Private Symbol

Kevin Smith zenparsing at
Sat Dec 20 19:41:40 PST 2014

> Under careful use of the symbols, and without Object.getOwnPropertySymbols
> leaking every symbol, we can use symbols as private field.

There are other ways that symbols can leak besides
`getOwnPropertySymbols`.  Take a look at proxies, which allow you to
intercept [[Get]] and [[Set]].

In fact, in my opinion [[Get]] and [[Set]] in the current MOP are
antithetical to privacy by definition, since the property key must be
transmitted to arbitrary exotic objects.

Anyway, in order to make symbols work for privacy, you would need to make
sure that:

- They are not exposed via getOwnPropertySymbols
- They are not exposed to proxies
- They are not exposed to arbitrary exotic objects

You would also have to accept the fact that private symbols would simply
not function across membranes.  That would be sad.

Furthermore, private symbols will tend to create a vector for confused
deputy-style attacks, since it is very easy to accidentally use [[Set]] to
create a private symbol on a "foreign" object, thereby accidentally
branding an object from an unknown source.

    const _p = Symbol("", true); // <= private, presumably
    class Oops {
        constructor() {
            this[_p] = 0;
        mutateMe() {
            this[_p] = 1; // Easy bug
    var x = {};;
    // x now has _p, but wasn't constructed by Oops

V8 already has implemented private Symbol (just one more boolean field when
> defining the struct symbol) though it is not exposed to Script-side.

It's true that V8 has implemented something, although the extent to which
that something is private is unknown to me since there's no spec and I
haven't read the code.  From looking at V8's promise implementation,
though, it seems that ensuring correctness of private symbol usage is
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list