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

Re: Component Model is not an Isolation Model

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 10 Mar 2011 17:07:24 -0500
Message-ID: <4D794B9C.1040501@mit.edu>
To: Dimitri Glazkov <dglazkov@chromium.org>
CC: public-webapps <public-webapps@w3.org>, MarkM Miller <erights@google.com>
On 3/10/11 4:58 PM, Dimitri Glazkov wrote:
 > We want to be useful and not in the way for this use case.

Agreed-ish.

> For the cases where isolation is necessary, be that mashups or
> browser's implementation of HTML elements
> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements),
> we should provide the capability.

Yes.

I think we agree that isolation should be optional.

I'm not sure I agree that we need a broad far-reaching general isolation 
model before we can provide isolation for the special case of 
widgets/components (just like we already provide isolation for frames).

> This, in essence, is what triggered realization that components and
> isolation are complementary, but different things.

I agree, but I think that "isolation for components" is a much more 
tractable specification and interoperable implementation problem than 
isolation in general.  Now clearly each UA already has some sort of 
isolation infrastructure that it would use to implement this, but I see 
no reason to expect that these will match in all particulars for other 
use cases.

>> 1)  Cross-site components are safe to use.
>> 2)  You can't screw up and depend on implementation details of a
>>     component, because if you're calling something the component
>>     provides then you're using APIs the component explicitly exposed.
>>
>> Is there something I'm missing?
>>
>> Or are those things that fall under "modularity" or "encapsulation" in your
>> message?  If so, what are you thinking of in terms of "isolation"?
...
> Isolation is an abstraction that provides a boundary (a membrane from
> the Caja world http://en.wikipedia.org/wiki/Object-capability_model)

OK, so this is the part that makes #1 above OK-ish (in the sense of not 
allowing the component to run code as you immediately).

Is #2 above what you put under "encapsulation" then?

> The Isolation model (whatever it turns out to be), should provide
> ability to create this boundary at will, not tied to a component spec
> in itself.

It's not clear that we need to solve this problem in generality to 
create something usable for components.

Past that, I have no problem with separate specs here, as long as we 
don't end up with the the overreach problem and end up with no isolation 
for components because we couldn't agree on how all the rest of the 
isolation model should work.

-Boris
Received on Thursday, 10 March 2011 22:08:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT