Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 13, 2014, at 4:01 PM, Alex Russell <slightlyoff@google.com> wrote:

> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Feb 12, 2014, at 4:04 PM, Alex Russell <slightlyoff@google.com> 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