Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

Tom Van Cutsem tomvc.be at gmail.com
Mon Jan 28 23:52:21 PST 2013


2013/1/28 Andreas Rossberg <rossberg at google.com>

> On 28 January 2013 19:45, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> > I just wrote up a strawman on the wiki to summarize the recent debates
> about
> > the interaction between proxies and private symbols:
> >
> > http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled
> >
> > The page actually lists two proposals, out of which I prefer the second
> one.
> >
> > If I forgot some benefits/drawbacks of either approach, please speak up.
>
> Under the second approach, how can you transparently proxy an object
> with private properties _at all_? It seems like you can't, even when
> you have access to its private names. In other words, what do you mean
> by "inherit the private state of the target", when the target is still
> aliased and accessed?
>

What I had in mind was something along the lines of:

// wrap target in a proxy, "inheriting" the private state identified by
privateSymbols
function wrap(target, handler, privateSymbols) {
  var p = Proxy(target, handler);
  privateSymbols.forEach( symbol => {
    Object.defineProperty(p, symbol, {
      get: function() { return target[symbol]; },
      set: function(val) { target[symbol] = val; }
    });
  });
  return p;
}

Having written this out, I realize I further assumed that
Object.defineProperty would work for private symbols, and would similarly
not trap on a proxy. I think these assumptions are valid.

I further realize that under the above approach, we lose the ability for
the proxy to virtualize the *attributes* of properties keyed by private
symbols (i.e. target[symbol] may be a data property, while proxy[symbol]
will be an accessor). My assumption is that this is not that big a deal,
but we should be wary of this limitation.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130129/afd30f05/attachment.html>


More information about the es-discuss mailing list