[Shadow]: Add "closed" flag to createShadowRoot (bugzilla: 20144) #100
Comments
|
I guess we don't have to be in a hurry to have a good naming for the API. That shouldn't block browser vendors to start to implement Shadow DOM, right? We can change it later as long as it's not shipped, hopefully. For now, let me summarize the ideas we have seen so far:
Also, AFAIR, I've heard an opinion that we might want to use the new name for the API, which is different name from the current name, (parameterless) createShadowRoot. I guess this matters only for Blink. For me, re-using same name is okay, as of now. |
|
FYI, just in case you you missed it, The API surface to create a closed shadow tree is still in the discussion here. |
|
Is there someone who is still interested in changing parameter for |
|
I think #126 is still in progress for adding a parameter to attachShadow(). |
|
Adding a (optional) member to a dictionary can be done anytime, I think. |
|
agreed. |
|
I still like visible/hidden/isolated because of the way the terms work with light and shadow. I think I would counter @domenic that even though a shadow is visible, that doesn't mean you can easily discern what's inside of it or use the same tools to inspect what's there as you can in the light. I can also live with open/closed/isolated though. |
|
Given I think it's fine to leave |
|
Don't make it impossible for scripts to access nodes in or distributed in a shadow tree. Why? What if we want to have privileged chrome code modify or read content from a page, to alter or enhance a page's behaviour? What if we want to programmatically interact with nodes within a shadow boundary? If scripts have no access to these... this is impossible. It is essentially a form of DRM for any content on the web. The workaround is to recompile Chrome from source and revert changes that introduce these restrictions, in effect forking the browser. |
|
@humanarity if a component want's to be encapsulated, currently, it has only the option of an iframe. This will be a great alternative to the iframe solution and pave the way for some really interesting API-based components. |
|
@tjconcept your reply does not address the issue raised by @humanitary nor has the issue with this feature essentially making audits of pages for concerns such as accessibility been addressed. It is high time that these issues get some serious discussion and consideration by this group |
|
@dylanb how is the closed mode situation different from the iframe approach in terms of access? |
|
The major concern I have with this feature is that there has been no discussion of what goals this feature needs to achieve. Statements about replacing iframes without a clear enumeration of the reasons this is needed, are useless. This feature has no rationale but has some very serious implications and should therefore not exist. Why is this solution worse than iframes from a perspective of auditing?
What mechanism will be available to do this on closed shadow DOMs? |
|
@dylanb I have a bunch of use cases for which iframes are terribly cumbersome due to lack of a formal API and styling issues: ads, single authentication, embedded content (youtube, twitter-streams, Discourse) and payment windows. I don't now the implementation details of this, but what makes you think you won't be able to detect a shadow DOM? I can imagine a simple test would do. |
|
Your aXe project looks cool. How does it handle other-origin iframes at the moment? I imagine the model will be the same with closed shadow DOMs. I also think that "closed" will be the exception and used primarily when a third party would like to extend some functionality to you but maintain security and integrity. |
|
@tjconcept I have personally also been affected by those iframe bugs and issues but I think the right place to fix those is in the HTML spec for iframes. iframes don't always provide this opacity. They only provide it when the document domains for the iframe the the parent are different. When they are the same, the parent document can look inside and modify the content of the iframe. The reason for the opacity has nothing to do with encapsulation and everything to do with security. Specifically, if cross domain iframes allowed access, it could allow a malicious web site to steal users data by pretending to be another site. In order to implement this fully, the canvas element also has to prevent iframes from being painted onto a canvas. If you think about it that way, then using iframes for their encapsulation properties is the same as using same domain iframes, which does not provide the opacity. The open Shadow DOM provides the same encapsulation. It is precisely this analysis which leads me to conclude that the closed Shadow DOM is not satisfying any publicly stated and agreed-upon need. It should therefore immediately be dropped from the spec. On the axe-core implementation, it uses window.postMessage for communication which is not available in the same manner for Shadow DOM. |
|
By "encapsulated" I really meant "secure".
Yes, but Shadow DOM is more powerfull in that the developer can now choose open/closed according to needs (security) and not have to bother with all the issues arising from an iframe.
If the developer chose "closed" mode, then of course you won't be able to inject scripts - and you shouldn't, as that is basically the same as different-origin iframes.
I might be missing something, but how can you conclude that there is no need for closed Shadow DOM, if you recognise these iframe issues yourself? Don't you agree, that closed Shadow DOM would be a great fit for providing the embeddable functionality of the examples I provided? Closed Shadow DOM would finally enable clean API's and over time maybe very granular styling control over embedded content/components (whilst maintaining security). E.g. a YouTube player that has a public interface with events, controls and more without cumbersome bridging due to cross-domain restrictions. |
|
How did you quote my message like that - that is cool! If the intent is to increase security then I would like to see a list of the security requirements that this is supposed to fulfill. For example, https://tools.ietf.org/html/rfc6454 specifies the principles that drive the iframe security model. Is this explicitly a goal of this specification - to provide security that equals that of RFC6454? If it is, then we do not need a closed option at all, the browser can automatically apply the security model. If it is not the aim, then where is the description of the principles and rationale that are driving this requirement? Without an explicit statement on the goals of this supposed security and the needs it is addressing, we cannot evaluate the effectiveness of the spec in meeting these needs and goals. If the intent is security, then why is there no discussion about the impact of this spec on canvas DOM rendering? https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas The rationale for this feature has never been documented and yet the very legitimate concerns related to test automation and auditing that this specification causes have not been addressed. |
I just put
I don't know, but that's definitely the use cases I am interested in. And which I find extremely useful and long overdue. Imagine that the web will have something, that you cannot easily do in native apps, and which should be much more common on the web.
In most cases, I guess, you would not want your components to be closed, even if cross-origin. Explicit is better than implicit.
I would treat it as any other external component. |
|
Thank you for the feedback. Let me share my thoughts:
BTW, we've already decided to add a closed mode. Th remaining task in this issue, #100, is to decide its API. e.g. "visible/hidden" vs "open/closed" You might want to file a new issue so that we can isolates each concern. |
|
@hayatoito I have created a new issue. Can you point me at the rationale for why developers need to create closed shadow dom? For example, why is it necessary for the details and the video objects to be closed? |
|
I think the concern was already addressed in the discussion in another issue. |
|
Just stumbled upon this today, which luckily seems to align perfectly with what I was initially hoping for:
Source: https://webkit.org/blog/4096/introducing-shadow-dom-api/ |
|
@tjconcept note that this is not that. Closed mode is more akin to a closure. If you pollute the global/prototypes, the component will likely be affected. |
|
@annevk I was guessing it would be another flag like "isolated" or similar. |
|
Yeah, nobody has proposed a coherent design for that yet, but it does seem to be something folks want. |
|
Just an FYI: today, someone reported that axe as not working correctly because it was not able to report on accessibility issued inside closed shadow DOM. Well done folks! |
|
@dylanb this issue is 1) about the older Shadow DOM v0 spec that is not implemented in any current browser, 2) closed. Also, was your comment supposed to be productive in some way? |
Title: [Shadow]: Add "closed" flag to createShadowRoot (bugzilla: 20144)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c0
Dimitri Glazkov wrote on 2012-11-28 22:59:01 +0000.
A tree created with this flag set to true will not appear in the shadow DOM traversal API.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c1
Dimitri Glazkov wrote on 2012-11-28 23:01:52 +0000.
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.
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c2
Dominic Cooney wrote on 2013-04-25 04:54:09 +0000.
This public-webapps thread is informative: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0800.html
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c3
Edward O'Connor wrote on 2014-02-07 23:23:01 +0000.
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.)
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c4
Dimitri Glazkov wrote on 2014-02-11 23:28:09 +0000.
(In reply to Edward O'Connor from comment #3)
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/).
comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c5
Maciej Stachowiak wrote on 2014-02-12 01:18:08 +0000.
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.
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c6
Dimitri Glazkov wrote on 2014-02-13 21:47:01 +0000.
This public-webapps thread is informative: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg217
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c7
brian kardell wrote on 2014-02-24 19:56:55 +0000.
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.
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c8
Hayato Ito wrote on 2014-11-19 04:49:40 +0000.
*** Bug 16509 has been marked as a duplicate of this bug. ***
comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c9
Hayato Ito wrote on 2015-02-10 08:44:08 +0000.
Let me change the subject of this bug since I am feeling that we tend to use 'closed' rather than 'private'.
comment: 10
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c10
Hayato Ito wrote on 2015-02-10 08:48:29 +0000.
*** Bug 23134 has been marked as a duplicate of this bug. ***
comment: 11
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c11
Dylan Barrell wrote on 2015-03-10 21:47:48 +0000.
(In reply to Hayato Ito from comment #10)
Please consider my concerns raised in this comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c11
comment: 12
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c12
Maciej Stachowiak wrote on 2015-04-22 01:26:46 +0000.
It looks like 'closed' mode has been added to the spec, but not yet a way to enter it (this bug) or a spec of its behavior (bug 27775).
comment: 13
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c13
Hayato Ito wrote on 2015-04-22 16:54:29 +0000.
The status of the behavior of the closed mode is still WIP. There are still remaining tasks. I have to address how event.path() should work for closed shadow trees further at least.
What's the more important is that we don't have a clear idea how open / closed interact in multiple shadow trees. I'm still investigating.
comment: 14
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c14
Maciej Stachowiak wrote on 2015-04-22 17:00:48 +0000.
Does adding a parameter to createShadowRoot() require solving all those problems first?
comment: 15
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c15
Hayato Ito wrote on 2015-04-22 17:07:36 +0000.
(In reply to Maciej Stachowiak from comment #14)
Good question. No. This bug shouldn't depends on bug 27775 strictly in terms of the spec. We can do in parallel!
Let's move this bug forward.
I think the proposal so far is to make createShadowRoot() can take one optional dictionary, such as:
Is there any other proposal?
comment: 16
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c16
Hayato Ito wrote on 2015-04-22 17:09:55 +0000.
Unless there is any other proposal, let's me spec that tentatively.
comment: 17
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c17
Hayato Ito wrote on 2015-04-22 18:13:40 +0000.
Done tentatively at 7be4645.
I appreciate any feedbacks.
comment: 18
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c18
Maciej Stachowiak wrote on 2015-04-23 21:52:57 +0000.
Looks like a good starting point for the API. Thanks! I think the remaining issues are captured in bug 27775 (to define the behavior) and bug 28445 (to determine the default) so I think it would be reasonable to close this bug now.
comment: 19
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c19
Hayato Ito wrote on 2015-04-27 03:03:50 +0000.
Let me reopen this.
Now ShadowRootInit should be mandatory.
comment: 20
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c20
Domenic Denicola wrote on 2015-04-27 03:50:46 +0000.
There is also the issue of naming. At the F2F many people were saying that "closed" vs. "open" is not a good name for this because the existing mode is fairly closed already.
I offer { censored: true }/{censored: false } since its primary function is to censor shadowRoot, deepPath, and any other future properties.
comment: 21
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c21
Anne wrote on 2015-04-27 08:03:00 +0000.
How about visible/hidden/isolated?
comment: 22
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c22
Olli Pettay wrote on 2015-04-27 17:06:39 +0000.
censored doesn't really say much, IMO.
visible, hidden, isolated - I think I like that.
(better than public/protected/private)
comment: 23
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c23
Domenic Denicola wrote on 2015-04-27 17:09:12 +0000.
"visible" still doesn't seem correct. Unless you are using visible to refer to the light DOM, and hidden is { closed: true }?
comment: 24
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c24
Olli Pettay wrote on 2015-04-27 17:13:42 +0000.
"visible" when passed to createShadowRoot() quite naturally hints that the
created shadow root is visible to the outside users, no?
comment: 25
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c25
Domenic Denicola wrote on 2015-04-27 17:18:12 +0000.
No, to me it hints that the resulting DOM is visible like normal DOM is, not that it's hidden from CSS selectors and from access without the .shadowRoot indirection.
I think if we want a spectrum of terms we need to have it include light DOM at one end. E.g.
comment: 26
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c26
Domenic Denicola wrote on 2015-04-27 17:19:45 +0000.
Sorry, to clarify: I just want some straightforward terminology. We of course wouldn't allow .createShadowRoot({ mode: 'visible' }) in my scheme. I just want to talk about what mode a subtree is in and have a word for what mode it's in when there's no shadowey stuff going on.
The text was updated successfully, but these errors were encountered: