-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wide Review for the DOM Review Draft — Published 21 June 2021 #19
Comments
Asking for the authors to include their own analyses of security issues, as is the typical prerequisite for reviews. Similar request re: privacy analysis. whatwg/dom#1013 |
Thanks @samuelweiler. I'll add it to the agenda of our next meeting. |
@siusin, any updates here? Has the WG met yet? |
TAG has comments at w3ctag/design-reviews#658 (comment) |
The response on this from the HTML editor side is at whatwg/dom#1013 (comment). This gist of that is, the HTML editors don’t plan to add any specific Security and Privacy Concerns section to the spec. And thus far, nobody from the W3C HTML WG side has stepped forward to commit to writing an such section to accompany the spec. |
Perhaps someone from PING could help with the privacy review? Similarly, @samuelweiler could you think of anyone who ight be able to help with the ssecurity bit? |
PING has completed its privacy review and we have an issue filed re: the lack of a separate in-line privacy considerations section. I thought PING had asked for the HTML WG's help, both in this issue and perhaps elsewhere, to resolve the misaligned expectations between PING (as a W3C horizontal review group) and the WHATWG. See, for instance: whatwg/dom#1013 (comment) Similarly, we have (overlapping) issue(s) filed re: an in-line security considerations section. I do not plan to ask a security reviewer to step in until that is resolved - as in https://www.w3.org/TR/security-privacy-questionnaire/#reviews, writing those sections is a prerequisite for review. |
@samuelweiler wrote:
I thought we were asked to help resolve whatwg/dom#776 and whatwg/dom#777, and both were closed with agreement from PING. Reading through the issues again it seems that the suggestion made in whatwg/dom#1013 (comment) met with cautious support in whatwg/dom#1013 (comment) and an effective invitation to contribute in whatwg/dom#1013 (comment). Horizontal review is part of the W3C Process, not the WHATWG's, so my take is that this is where we can contribute something that will make the DOM Standard more informative about privacy and security. So unless I'm missing something, I suggest the next step is to open a PR to add a privacy/security section (or sections) to the DOM Standard, based on the guidance given in w3cping/privacy-request#49 (comment). Given familiarity with the subject matter and the guidance for writing such sections, it seems logical that someone from PING and/or @samuelweiler would be best placed to do this. If the PR isn't accepted then we'll need to reconsider, but for now I think it's on us to make the next move. |
776 and 777 were the security and privacy section requests, respectively, from 2019. Indeed, Pete consented to closing both in 2019, though 776 (security considerations) is not technically not in scope for PING. Both topics were raised again as part of the 2021 reviews and filed as the combined issue 1013. I also reopened 776 re: the missing security section (which it now seems I should not have done?), and the WHATWG folks preferred to reclose it in favor of the new combined issue 1013. The substance is not resolved - it's just been transferred to the new issue 1013.
Writing these sections is not a service PING nor our security reviewers normally provide. I generally think document authors, as the people most familiar with the spec, are best situated to write them. In this case, PING might have people who want to contribute to such a section - indeed, the PING chairs are talking a bit about that now. Ultimately, though, the duty for writing them falls to the document authors.
If by "us" you mean the W3C HTML WG, sure. If by "us" you mean the W3C horizontal review groups, then I disagree, as above. |
@samuelweiler to be sure I understand correctly... the ask is that a privacy/security section be added to the DOM Standard, documenting that no known privacy or security considerations are known at this time, yes? |
There's some unfortunate muddling of security and privacy here, and whatwg/dom#1013 definitely contributes to the muddling. In 1013, sysrqb suggests a "no security concerns" text, but his review was on behalf of PING, re: privacy issues, not (primarily) a security review. My own take: For privacy, yes, that is the ask. For security, I don't think we've had a review that concurs that "no issues" would be appropriate, and my intuition is that "no issues" would not be appropriate. So the ask would be for a security analysis (normally from the document authors, though that seems to be the sticking point), documented as described in https://www.w3.org/TR/security-privacy-questionnaire/#considerations. |
This is a review tracker of DOM Review Draft — Published 21 June 2021.
Requested
Important Changes between Jun 2020 and Jun 2021
Accessibility?
Correct boundary point comparison in set the start or end
I18N?
Please review the full list to see if anything is relavant.
Security & Privacy?
whatwg/dom@83037a1
Add signal support to addEventListener()
whatwg/dom@aa384af
Add AbortSignal.abort() static method
Architecture?
whatwg/dom@12beda2
DOM Events introduction: clarify how listeners are invoked
whatwg/dom@f837ce1
Add "precustomized" custom element state
whatwg/dom@8c0049e
Add "is available to element internals"
whatwg/dom@52f7a52
Need to catch exceptions to report them
whatwg/dom@83037a1
Add signal support to addEventListener()
whatwg/dom@aa384af
Add AbortSignal.abort() static method
whatwg/dom@c80cbf5
Use a single exception for name validation (follow-up)
whatwg/dom@acfe96b
Add imperative slot assignment API
whatwg/dom@d2c84ec
Add the IDL of XSLTProcessor
whatwg/dom@f346858
Add ShadowRoot.prototype.delegatesFocus attribute
The text was updated successfully, but these errors were encountered: