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

Reply via email to