Wide Review for the DOM Review Draft — Published 21 June 2021

[siusin]

This is a review tracker of DOM Review Draft — Published 21 June 2021.

Requested

• A11y
• I18n
• Privacy
• TAG
• Security

Important Changes between Jun 2020 and Jun 2021

Accessibility?

• whatwg/dom@73e7f33
  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

[samuelweiler]

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
whatwg/dom#777

[siusin]

Thanks @samuelweiler. I'll add it to the agenda of our next meeting.

[samuelweiler]

Thanks @samuelweiler. I'll add it to the agenda of our next meeting.

@siusin, any updates here? Has the WG met yet?

@plehegar @LJWatson @hober @sideshowbarker

[plehegar]

TAG has comments at w3ctag/design-reviews#658 (comment)

[sideshowbarker]

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 whatwg/dom#777

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.

[LJWatson]

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?

[samuelweiler]

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.

[LJWatson]

@samuelweiler wrote:

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.

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.

[samuelweiler]

I thought we were asked to help resolve whatwg/dom#776 and whatwg/dom#777, and both were closed with agreement from PING.

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.

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.

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

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.