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

Andreas Rossberg rossberg at
Wed Nov 9 03:46:37 PST 2011

On 9 November 2011 00:16, Mark S. Miller <erights at> wrote:
> On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg <rossberg at>
> wrote:
>> On 8 November 2011 20:46, Mark S. Miller <erights at> 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.
> I think we're agreeing on the operational point -- that much defensive code
> won't bother to freeze such functions. But for clarity, I must correct your
> "no reason". The reason is one of the oldest software engineering best
> practices: Say What You Mean. Perhaps a clearer statement is Mean Only What
> You Say. The "it" in your above sentence presumes a non-local whole program
> analysis which violates this rule, and is in any case inapplicable to
> libraries.
> To keep what the program means in sync with what it seems to mean, we need
> to avoid introducing unexpressed communication channels. Or, put another
> way, unexpressed shared mutable locations. If Alice provides object C to
> both B and D, the only ways in which this should enable further
> communication between B and D (beyond that which they may have already had)
> should be according to the expressed behavior of C. For example, if the
> expressed behavior of C is completely stateless, then the fact that B and D
> both share a reference to C should not enable any additional
> communications/interaction/influence between B and D.
> These constraints are useful for much beyond security. If you wish to
> program in a mostly functional style, you'd like the deviations from
> functional style to only be where you've made a purposeful choice. When
> debugging, you need to figure out: How did the bad symptom happen? If you
> can bound the possible causes, by reasoning in terms of the program's
> intended behavior, your detective work is much easier.

Agreed with everything you say. But I suppose there are two levels of
concern: protecting your own abstractions, and not providing security
loopholes that others can exploit to harm third parties.  Given how
hostile JS is towards encouraging the latter, I would expect that a
significant amount of code exists that only cares about the former,
which I think is a valid concern on its own.


More information about the es-discuss mailing list