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

Claus Reinke claus.reinke at talk21.com
Fri Nov 4 08:14:06 PDT 2011

> In .. an ES5/strict environment in which all primordial built-in objects
> are transitively frozen, ..
>    function makeTable() {
>      var array = [];
>      return Object.freeze({
>        add: function(v) { array.push(v); },
>        store: function(i, v) { array[i] = v; },
>        get: function(i) { return array[i]; }
>      });
>    }
> .. Given just a table instance, can Bob nevertheless obtain direct access
> to the underlying array?

Hm. A favorite pattern that I haven't thought about enough, it seems.
My curiosity did cost me some sleep:-| My favorite work around for
your constraints is this little shim:-)

  // dynamic language
  Object.freeze = function(obj){return obj};

You imply that this is not intended, so I can show it without spoiling
the fun. I was surprised that this works.

The first solution that came to mind ought to be defeated by your
"transitively frozen" constraint, and it is, in current JS implementations,
though not all JS implementations in the wild are there yet - do you
"feature-detect" old engines and issue warnings if they invalidate
your base assumptions?

The second approach took longer to find but relies on non-standard
features (and again, I suspect a bug/interpretation issue).

Both ideas are weak, in that they could be blocked by type checks.

> If you've already seen this puzzle and know the answer, please don't
> post. If no one else has posted the correct answer in 24 hours, I will.

Neither of my approaches seems to be the droid you are looking for,
given your "no realistic fix" remark, so I'm curious what else I've missed.

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

You also rely on you security base framework being the first to run,
and on nobody trying to modify source on load, right?


More information about the es-discuss mailing list