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

On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 13, 2014, at 4:01 PM, Alex Russell <slightlyoff@google.com> wrote:
>
> 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); }
>   }
> };
>
> Leakage via other methods can be locked down by the first code to run in
> an environment (caja does this, and nothing prevents it from doing this for
> SD as it can pre-process/filter scripts that might try to access internals).
>
>
> Caja is effective for protecting a page from code it embeds, since the
> page can have a guarantee that its code is the first to run. But it cannot
> be used to protect embedded code from a page, so for example a JS library
> cannot guarantee that objects it holds only in closure variables will not
> leak to the surrounding page...
>

That is incorrect. It is definitely possible to write code that does not
leak to the environment. It is painful to do because like Ryosuke wrote you
cannot use any of the built in functions or objects. You can only use
primitives and literals. But with a compile to JS language this can be made
less painful and in the days of LLVM to JS compilers this seems like a
trivial problem.

-- 
erik