Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

Mark S. Miller erights at
Tue Nov 8 10:13:27 PST 2011

On Tue, Nov 8, 2011 at 5:26 AM, Andreas Rossberg <rossberg at>wrote:

> On 3 November 2011 23:55, Mark S. Miller <erights at> wrote:
> >> If I understood Mark correctly, the features needed for SES are
> >> already part of ES.5 and are shipping in browsers
> >>
> >> (and hence don't bear upon future features).  Did I misunderstand?
> >
> > These do bear on future features in three ways:
> >
> > 1) Future features could easily destroy all the security gains that ES5
> > achieved.
> I'm still trying to grasp the implications of the recent direct proxy
> proposal in this respect -- more precisely, its startTrapping
> functionality.
> It seems to me that the ability to attach to a function, in
> particular, invalidates all current security guarantees, since it
> gives a whole new way of completely redefining any random function _in
> place_ by simply turning it into a function proxy. That is, even if
> that function is given by a non-writable binding or property!
> To achieve the effect of today's Object.{seal,freeze}, you hence also
> would have to make _every_ of the object's properties non-attachable.
> That is certainly possible, but seems considerably more fragile. And
> it still breaks the security of pre-existing SES code. IOW, I sense a
> security hazard.

Hi Andreas, thanks for starting a discussion on this. I agree that there is
a huge danger here. There is another approach to so-called data binding
(treat it like an optimization of polling) that cannot cause any loss of
security (if equivalence to polling really is maintained). Altogether, from
a security pov, we'd certainly be better off without Proxy.attach.

The reason Proxy.attach may not be fatal is that it only allows attachment
to extensible objects. Our hypothesis is that any ES5 object that is
interested in defending itself has already made itself non-extensible. This
is why we must key this off of non-extensibility, rather than introducing a
new orthogonal bit -- to avoid breaching the defenses of those ES5 era
objects that tried to defend themselves. ES3 era objects could not defend
themselves, so attaching to them cannot violate any of their valid
assumptions -- to a first approximation, they could not validly assume

> I also wonder about the effect that turning an (ordinary) object into
> a proxy would have on the visibility of private names. If one of the
> original methods accesses a private property on `this', then,
> according to the private names proposal, the handler only gets to see
> the .public property of that name. But can't this still leak
> information? The handler cannot use it to _read_ the existing property
> data, but it will still receive all future _writes_ to it.
> Am I missing something?

Only the defensiveness points above. Regarding data binding, we should also
see if the non-dangerous poll-optimization-equivalence can meet our needs
instead, in which case we probably don't need Proxy.attach.

> /Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list