Wide review tracker

[anssiko]

About

This is a meta issue to track wide review for the Compute Pressure API.

An important part of wide review is horizontal review from W3C's key horizontal groups listed below in horizontal groups section. Also feedback from other stakeholders is equally important. Additional pointers are welcome via comments.

The list is based on the How to do wide review page guidance.

Legend:
🔴 Review request not submitted
🟡 Review request submitted
🔵 Review feedback received
🟢 Review closed as completed

Horizontal groups

🟢 ♿ Accessibility

• Work through this questionnaire
  • Accessibility Checklist #183
• request a review via GitHub from APA
  • Compute Pressure API 2023-02-07 a11y-request#53
    • Review closed as completed with substantive contributions Add Accessibility considerations #247

🟢 📐 Architecture

• Ask the TAG for review; see how to work with the TAG

  • Compute Pressure Specification Review w3ctag/design-reviews#795
  • Positive feedback received on data minimization approach: Compute Pressure Specification Review w3ctag/design-reviews#795 (comment)

• If you are developing javascript APIs you may also want to ask [email protected], a technical discussion list shared by W3C and ECMA's TC 39

  • No issues related to JS language features that should be brought to TC 39 for consideration.

🟢 🌍 Internationalisation

• Read the Request a review page
• work through the Short Checklist
  • Internationalization Checklist  #184
• request a review via GitHub
  • Compute Pressure API 2023-02-07 > 2023-03-31 i18n-request#204
    • Review closed as completed Compute Pressure API 2023-02-07 > 2023-03-31 i18n-request#204 (comment)

🟢 🔍 Privacy

• Write a "Privacy Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, Mitigating Browser Fingerprinting in Web Specifications, and RFC6973
  • Completed Self-Review Questionnaire: Security and Privacy
  • Authored Spec: Privacy Considerations
  • Chrome Security and Privacy team feedback Security and privacy review tracker #79
• request a review via GitHub from the Privacy Interest Group
  • Compute Pressure API 2023-02-07 w3cping/privacy-request#113
    • Review closed as completed with substantive contributions Compute Pressure API 2023-02-07 w3cping/privacy-request#113 (comment)

🟢 🔒 Security

• Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy
  • Authored Spec: Security Considerations
  • Chrome Security and Privacy team feedback Security and privacy review tracker #79
• request a review via GitHub
  • Compute Pressure API 2023-02-07 security-request#50
    • Review closed as completed: Compute Pressure API 2023-02-07 security-request#50 (comment)

Other stakeholders

From who to ask for review:

Horizontal reviews [...] are only a subset of a full wide review, which must also include other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and standards organizations working on related areas, etc.

🟢 Zoom - positive signals and support #14

[anssiko]

I have now initiated the Privacy and Security reviews with the respective horizontal groups.

In addition, I have staged both the Accessibility and Internationalisation reviews for submission, pending editors' review of the checklist materials to be provided as references in these requests.

Lastly, we had submitted the Architecture (aka TAG) review request earlier.

The status of our overall wide review progress is being tracked in this issue with links to the relevant material and feedback. Our goals is to turn all 🔴 into 🟡 during Q1, and push to 🟢 during Q2.

Your diligent efforts ensure that the entire set of stakeholders of the web community, including the general public, have had adequate notice of the progress of the Working Group and are able to actually perform reviews of and provide comments on the specification.

Our second objective is to make sure we request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review.

Thank you for your contributions.

[anssiko]

Current status:

• All wide review requests have been submitted.

• Internationalisation review has been completed.

• Privacy review feedback has been received and is being addressed.

Please refer to the tracker in the first comment for pointers.

[anssiko]

Current status:

• Accessibility review request queued for processing.

• Architecture review received. Positive feedback with a request to share developer feedback when available. Confirming if further feedback is expected.

• Privacy review feedback broken into privacy-needs-resolution issues welcomes contributions.

• Security review closed as completed.

[anssiko]

Current status:

• Accessibility reviewers volunteered to contribute an Accessibility considerations section to the spec in Compute Pressure API 2023-02-07 a11y-request#53 (comment) (thanks @matatk et al.!), the WG expect this contribution by the end of this month.

• Architecture review received. Positive feedback with a request to share developer feedback when available. No new information since the Apr 24 status update.

• Privacy review feedback improved the Security and Privacy considerations substantively (thanks @pes10k!) in Reorganize Security and privacy considerations #216, remaining improvements under review in Improve User notifications section #218 and Add proposed Cross-site covert channel attack description #219

• Security review closed as completed.

[anssiko]

I'm thrilled to announce wide review for the Compute Pressure API has been completed. 🥳

The Devices and Sensors Working Group would like to thank numerous contributors across Accessibility, Architecture, Internationalization, Privacy and Security horizontals for their deligent review and contributions.

[himorin]

@anssiko Next step toward CR after HR, would be settling down all spec issues (or marking related part as at-risk?), and call for consensus to publish as CR within the group, I believe.
It seems there is only small number of registered issues (except for V2 or enhancement), we may go further shortly. How do you think? (of course, all works might start after new year.)

[anssiko]

@himorin, thanks for reminding us of the next Rec Track transition ahead of us.

I'd like to share with the WG that a number of high-profile customers want to continue experiment with the API. To that end, we announced an intent to extend the Chrome Origin Trial from 120 to 123 inclusive, running until early April '24. The goal of this extension is to gather feedback to further increase the WG's confidence we are addressing real user needs across a variety of use cases.

I believe the WG wants to integrate the feedback from these early adopters before advancing to a CR, so I'd suggest we check back when we have completed the Origin Trial extension. It is definitely great to see the wide review (one of the important requirements for advancing to a CR) completed with major contributions to the specification.

[anssiko]

Feedback from early adopters of the Compute Pressure API is now available: w3ctag/design-reviews#795 (comment)

This feedback suggests the current version of the API is addressing real customer needs. The feedback also motivates possible future work.

@kenchris @arskama please ensure that we have recorded the relevant feedback for possible future work as GH issues in this repo, labeled as V2

[anssiko]

The Compute Pressure API shipped in Chrome 125 Stable release yesterday. Congratulations everyone who made this happen!

This important implementation milestone was reached after an extensive trial period with real-world customers between July 2023 and March 2024. Feedback received during this trial period demonstrated the API addresses important end user needs and motivated the shipping decision.

Considering this significant advancement on the implementation front, I recommend the WG to start advancing this specification toward the Candidate Recommendation stage in the near future. This transition is to formally signal the specification is welcoming further implementation experience.

We will assess the CR transition readiness in the coming months with assistance from @himorin and will follow up with more information and concrete next steps. Meanwhile, I encourage the editors @kenchris @arskama to triage the remaining open issues and label any issues considered out of scope for the expected CR, including any new features, as V2 This is to help delineate what should be addressed by CR from what comes after.

[pes10k]

Thats wonderful @anssiko . I'm repeating myself I know, but i just wanted to appreciate your group for working so hard and collaboratively to address the privacy risks that PING identified, and integrating mitigations into the default behavior in the spec so that Web users and sites can benefit from this new, exciting functionality without putting users at risk. Congratulations to you all again

[anssiko]

Working on this specification together with you @pes10k and the PING participants has been a rewarding experience for the entire group. Your major contributions shaped what became an extensive security and privacy considerations section documenting both identified threats and innovative mitigation strategies, also incorporated into normative definitions.

Our group is guided by our mission statement ("create secure and privacy-preserving client-side APIs") so your kind words mean a lot to us. Your feedback tells us we're doing the right things and doing them right.

I'm proud to see this API ship with the strong privacy protections we co-designed. Thank you for co-traveling with us on this journey.

[anssiko]

@kenchris @arskama in preparation for our TPAC discussion w3c/devicesensors-wg#69, can you please triage the remaining open issues and:

• label any open issues considered out of scope for the expected CR, including any new features, as V2
• and then, identify issues out of the remaining issues that are not V2 that are substantive bug fixes to be addressed prior CR, and label them as bug Something is wrong or under specified

You can also use other labels as appropriate, but check the assignment for those two (V2, bug) are up to date.

This will help the group make an informed decision on the publication readiness. Thank you!

[arskama]

V2 labels:

1. v2 labels under investigation, higher prirority, or requires discussions:
• Use-case: Current process contribution #8 : Working on a solution, requires some discussion with isv's and chromium team.
• Use-case: Analytics / RUM #233: Buffering of CP statuses before requesting: Subject to discussion
2. v2 labels out of current scope:
• Use-case: GPU pressure #9 Specification wise easy, but implentation is complex. no OS APIs or paltform API available.
• Use-case: optimize for long battery life #119: No investigation on metrics and algorithm.
• Use-case: Memory stalls #120: Requires discussion on possible usage, metrics and memory types, platform and OS API available. wide area of research.
• Does compute pressure reflect OS-level speed limit changes due to throttling? #228: Catch-All pressure: Not feasible at the moment, very complex to define.
• Exposing low-level metrics via permissions #246: Not investigated.
• Energy measurement: Track energy consumption for a tab #249: Not invetigated.
• automation: Consider adding WebDriver BiDi actions in addition to the WebDriver Classic endpoints #288: Not investigated.

bug Something is wrong or under specified labels:

1. Permission policy needs to be checked when owner set changes #243: No easy fix before CR.
2. "Current pressure state" definition and cardinality are confusing #281: Could be fixed before CR.
3. "Rate-limiting change notifications" section is confusing #291: Could be fixed before CR.

[anssiko]

Thanks @arskama. If there are bugs that you think should be out of scope for CR, you could use a combination of bug Something is wrong or under specified + V2 for those.

[himorin]

also I believe 'no', but is there any (additional) at-risk feature we should mark?

[anssiko]

@himorin I believe thermals pressure source could be marked as at risk.

[anssiko]

Current status:

• The only at risk feature identified has been removed in Move at-risk to experimental #300
• The only remaining bug Something is wrong or under specified Permission policy needs to be checked when owner set changes #243 has a PR Turn issue into note, as workers have their own policy container #303 in review.
• The rest of the open issues are either deferrer to V2 or considered non-blocking for CR based on our TPAC discussion.

@himorin I plan to initiate a CfC to publish the CR when PR #303 has landed. Please let us know if you identify any further areas that require attention prior to the expected publication.

[anssiko]

CfC to publish Compute Pressure API Candidate Recommendation Snapshot - review by 29 Nov 2024