Bugzilla – Bug 20144
[Shadow]: Add "closed" flag to createShadowRoot
Last modified: 2015-03-10 21:47:48 UTC
A tree created with this flag set to true will not appear in the shadow DOM traversal API.
It seems that having a distinction of a "private" shadow tree is a misnomer, possibly giving the author a false hope that their shadow tree is somehow protected from a motivated owner of the document. Unfortunately, that's not the case -- the document can easily override and capture all shadow trees created, thus killing the shadow author's illusion of privacy.
This public-webapps thread is informative: <http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0800.html>
So, any progress on this?
(I'm not sure if you are using Bugzilla's Importance field; if so, I bumped this up to P1 given recent discussions.)
(In reply to Edward O'Connor from comment #3)
> So, any progress on this?
Not yet. But it's still on the radar.
BTW, this should also disable access via relevant CSS selectors (http://dev.w3.org/csswg/shadow-styling/).
Suggestion: how about instead of private vs public, the flag is "open" vs "closed"? That won't unduly promise security isolation. Then a hypothetical third truly secure mode could be called "secure" or "sandboxed" and it would be consistent.
This public-webapps thread is informative: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg217
It seems to me that there are different concerns you might talk about, not entirely unlike sandboxed iframes. Shadow DOM (as currently) provides a nice simple membrane to keep lots of accidental things from going wrong, but can be easily traversed into/pierced and doesn't get a separate execution context or anything special. If we had a ::parts concept it would be useful to explain what that means in terms of CSS and DOM boundaries, etc.
Is it possible to consider, instead of a flag, that a shadow root has a set of properties (which I hope default to what they currently are in canary, personally). This would probably help explain things in the platform even if we never entirely enable them in author space, if you see what I am saying.
*** Bug 16509 has been marked as a duplicate of this bug. ***
Let me change the subject of this bug since I am feeling that we tend to use 'closed' rather than 'private'.
*** Bug 23134 has been marked as a duplicate of this bug. ***
(In reply to Hayato Ito from comment #10)
> *** Bug 23134 has been marked as a duplicate of this bug. ***
Please consider my concerns raised in this comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c11