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

Sam Tobin-Hochstadt samth at
Wed Nov 9 06:35:13 PST 2011

On Tue, Nov 8, 2011 at 4:58 PM, Tom Van Cutsem < at> wrote:
>> > Perhaps we should
>> > be more conservative here, without necessarily backing away from the
>> > whole
>> > Proxy.attach idea?
>> Disallowing attaching to functions with your own call/construct traps
>> would be the minimal restriction, I think. But maybe there is
>> something cleaner.
> I wonder if chaperones, as implemented in Racket, would be of help here. To
> my understanding, a chaperone is a proxy that is very restricted in its
> actions, specifically: when intercepting a function call, a chaperone is
> only allowed to throw an exception, return the original value, or a
> chaperone for the original value (racketeers on this list should correct me
> where needed).
> Chaperones would still be powerful enough to express data binding: firing an
> update event as a side-effect does not require changing the arguments or
> return values of wrapped functions.
> However, at this point I'm not yet sufficiently familiar with chaperones to
> see how they can be adapted into our Proxy framework.

That's a very accurate summary.  I agree with Andreas that this is a
significant risk for Proxy.attach.  ES in the wild has few enough
invariants that we should be very wary of breaking the ones we've got.

However, the direct proxy proposal is already enforcing some
invariants -- the proxy must produce === values to the underlying
object for frozen properties.  Could we just reuse this mechanism for
the [[Call]] and [[Construct]] behavior of functions in the cases
Andreas brings up for Proxy.attach (if we decide that we want it)?

The idea of chaperones would be then relaxing this invariant slightly,
to allow frozen properties to produce proxies for the underlying
property value, instead of just something === to it.  This makes
proxies more expressive in some cases, without reducing the invariants
we can rely on.
sam th
samth at

More information about the es-discuss mailing list