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

On Fri, Feb 14, 2014 at 2:02 PM, Ryosuke Niwa <> wrote:
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson <> wrote:
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak <> wrote:
>> On Feb 13, 2014, at 4:01 PM, Alex Russell <> 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.
> While it's technically the case that one could write a Turing-complete
> closure that doesn't leak any information, I think we all agree it's so
> painful that nobody can do this successfully by hand without relying on
> heavily-weight tools such as Caja or a LLVM-to-JS compiler.
> Instead of accepting this is as a status quo, we should strive to improve
> the Web platform to provide better encapsulation.

Also, I think that the Type 2 encapsulation has the same
characteristics. If the component author does things perfectly and
doesn't depend on any outside code, a Type 2 encapsulation might very
well be equivalent to Type 4.

In practice, I'm not sure that this is an interesting debate though.
In practice everyone does depend on outside code. Even people using
closures. Trying to use closures to enforce security is too brittle.

/ Jonas

Received on Friday, 14 February 2014 22:32:52 UTC