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

Tom Van Cutsem tomvc.be at gmail.com
Tue Nov 8 13:58:35 PST 2011


2011/11/8 Andreas Rossberg <rossberg at google.com>

> On 8 November 2011 20:46, Mark S. Miller <erights at google.com> wrote:
>  > Nevertheless, I see your point. Many defensive ES5 abstractions will be
> less
> > defensive than this. If I understand you correctly, your point is
> > specifically about the [[Call]] and [[Construct]] traps.
>
> Yes. Existing code has no reason to bother making functions
> non-extensible if all it does is calling them. Proxy.attach
> fundamentally breaks that (so far correct, AFAICT) assumption.
>

Indeed.


> > 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.

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


More information about the es-discuss mailing list