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

Re: Component Model is not an Isolation Model

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Thu, 10 Mar 2011 14:19:41 -0800
Message-ID: <AANLkTimqmP+10Yv=OBG=-=FSWNrujHTUiYef_xM3+ny5@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps <public-webapps@w3.org>, MarkM Miller <erights@google.com>
On Thu, Mar 10, 2011 at 2:07 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

Yes.

>
>> 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.

That is certainly a concern. Perhaps the right approach is to
recognize the need to address the isolation before we consider
component model spec done ("done" TBD).

Also, maybe Caja folks could lend their skillful hand in crafting a
simple DOM-centric isolation spec?

>
> -Boris
>
Received on Thursday, 10 March 2011 22:20:11 GMT

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