Lecture series on SES and capability-based security by Mark Miller

[Douglas Crockford]

On 11:59 AM, Mark S. Miller wrote:
> Note that I don't see any realistic way to fix problem #3 in the 
> ES.next language. My point is only that defensive programming is 
> tricky even after you've gotten all the formal properties you need. As 
> ES.next introduces various new abstraction mechanisms, whether 
> classes, enhanced object literals, proxies, modules, or private names, 
> the design of these can either help or hurt those attempting to write 
> defensive abstractions. Any class abstraction that is only useful for 
> making indefensible instances is worse than useless -- it is actively 
> harmful, both to security and to serious software engineering.
>
I share your concern about the unintended consequences of new features. 
The dangers are very real, and the patterns can be extremely subtle.

But while #3 is not fixable, there are features of ES5 that make it 
easier to live with. For example, if you had built makeTable with

     var array = Object.create(null),
         length = 0;

and adapted the methods accordingly, then in this example, the leakage 
could have been avoided without excessive trickiness. I think this level 
of practice is teachable.