On Feb 13, 2014, at 4:01 PM, Alex Russell <[email protected]> wrote:
> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak <[email protected]> wrote: > On Feb 12, 2014, at 4:04 PM, Alex Russell <[email protected]> wrote: > It is meant to be an encapsulation mechanism. Let me give a comparison. Many > JavaScript programmers choose to use closures as a way to store private data > for objects. That is an encapsulation mechanism. It is not, in itself, a hard > security mechanism. If the caller can hook your global environment, and for > example modify commonly used Object methods, then they may force a leak of > your data. > > A closure is an iron-clad isolation mechanism for object ownership with > regards to the closing-over function object. There's absolutely no iteration > of the closed-over state of a function object; any such enumeration would be > a security hole (as with the old Mozilla object-as-param-to-eval bug). You > can't get the value of "foo" in this example except with the consent of the > returned function: > > var maybeVendFoo = function() { > var foo = 1; > return function(willMaybeCall) { > if (/* some test */) { willMaybeCall(foo); } > } > }; But what if maybeVendFoo called some builtin functions like Math.abs on foo? e.g. var maybeVendFoo = function () { var foo = 1; var bar = Math.abs(foo); … return function (willMaybeCall) { if (/* some test */) {willMaybeCall(foo); } } The caller of maybeVendFoo could easily override Math.abs and observe the value of foo: var foo; var realAbs = Math.abs; Math.abs = function (val) { foo = val; return realAbs(val); } maybeVendFoo(); Math.abs = realAbs; This is exactly the kind of leakage we would have in Type 2 encapsulation Maciej has been talking about. - R. Niwa
