On 9 November 2011 00:16, Mark S. Miller <erig...@google.com> wrote: > On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg <rossb...@google.com> > wrote: >> >> On 8 November 2011 20:46, Mark S. Miller <erig...@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. > > 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. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
