W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 14 Feb 2014 14:02:14 -0800
Cc: Maciej Stachowiak <mjs@apple.com>, Alex Russell <slightlyoff@google.com>, Elliott Sprehn <esprehn@chromium.org>, Dimitri Glazkov <dglazkov@chromium.org>, Arthur Barstow <art.barstow@nokia.com>, "public-webapps@w3.org WG" <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mozilla.com>
Message-id: <14C916C8-D64D-4F7A-A688-E7505F819A94@apple.com>
To: Erik Arvidsson <arv@chromium.org>
On Feb 14, 2014, at 9:00 AM, Erik Arvidsson <arv@chromium.org> wrote:
> 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.

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.

- R. Niwa


Received on Friday, 14 February 2014 22:02:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC