Re: Encapsulation and defaulting to open vs closed (was Re: Shadow DOM Encapsulation)

On Thu, Feb 6, 2014 at 4:36 PM, Sylvain Galineau <galineau@adobe.com> wrote:
> On Feb 6, 2014, at 4:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, Feb 6, 2014 at 3:58 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>>> So I think the debate is not so much whether Type 2 can be added later as much as its being considered a future and therefore ‘nice-to-have’ feature instead of a ‘must-have’ default. Tab suggests you started from the latter point of view before reality pushed you to the former. Looking forward to hearing more on the how and why...
>>
>> Reread the thread at
>> <http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312>
>>
>
> I did. This is good historical context and provides a bit more detail behind the reasoning though it’s still not so clear-cut or obvious to me. (though, as is the case now, it’s clear it’s obvious to you…)
>
> I would note the thread seems to land in the same lack of consensus we have right now e.g.
>
> Maciej http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html
>
>         I still don't entirely buy the use cases for making shadow dom contents public. But I thought the
>         rough consensus in the earlier discussion was to support both modes, not to support public components only.
>
> Earlier, BZ http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html:
>
>         On 11/8/12 9:28 AM, Elliott Sprehn wrote:
>         > If you're worried about malicious attacks on your widget, shadows being
>         > private is not enough. You need a whole new scripting context.
>
>         Er... yes, you do.  Do widgets not get that?  If not, that's pretty
>         broken…

I can't comment as to whether Boris was just confused on that point a
year ago, or what, nor what his thoughts are on it now.  It's
definitely been clear for a long time in Shadow DOM-land that we're
not trying to solve the script-encapsulation problem (aka the "explain
<iframe>s" problem).

> Before that, BZ also http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0330.html:
>
>         On 11/1/12 7:41 AM, Tab Atkins Jr. wrote:
>         > There was no good *reason* to be private by default
>
>         Yes, there was.  It makes it much simpler to author non-buggy
>         components.  Most component authors don't really contemplate how their
>         code will behave if someone violates the invariants they're depending on
>         in their shadow DOMs.  We've run into this again and again with XBL.
>
>         So pretty much any component that has a shadow DOM people can mess with
>         but doesn't explicitly consider that it can happen is likely to be very
>         broken.  Depending on what exactly it does, the brokenness can be more
>         or less benign, ranging from "doesn't render right" to "leaks private
>         user data to the world".
>
>         > As a general rule, we should favor being public over
>         > being private unless there's a good privacy or security reason to be
>         > private.
>
>         As a general rule we should be making it as easy as possible to write
>         non-buggy code, while still allowing flexibility.  In my opinion.
>
>
> It seems little progress has been made to close this gap :/

Same deal here.  Boris makes a good point that we should give thought
to allowing authors to write their code with high-fidelity security
primitives, but nothing we've discussed so far would do that.  Most
certainly, trying to restrict CSS's ability to style into a shadow DOM
won't affect this at all.

However, this entire topic is straying WAY beyond what's appropriate
for this forum.  The CSSWG is *not* the right body to second-guess
decisions made a year ago in WebApps about core Shadow DOM
functionality, and I'm going to stop responding to any attempts to
talk about this stuff in www-style.

For the purpose of the www-style threads, we should take the current
spec as given.  If you disagree, do so in a WebApps thread or bug.

~TJ

Received on Friday, 7 February 2014 01:36:59 UTC