Compute Pressure Specification Review

[arskama]

Wotcher TAG!

We are requesting a TAG review of the Compute Pressure API. The Compute Pressure API provides a way for websites to react to high-level changes in the CPU pressure, in a privacy preserving manner, such that websites can trade off resources for an improved user experience.

• Explainer: explainer
• Specification URL: specification
• Tests: wpt
• User research:
• Security and Privacy self-review: specification
• GitHub repo: repo
• Primary contacts:
  • Kenneth Rohde Christiansen (kenchris), Intel
  • Arnaud Mandy (arskama), Intel
• Organization(s)/project(s) driving the specification: Intel, Google. Web Capabilities (Project Fugu, Chromium)
• Key pieces of existing multi-stakeholder review or discussion of this specification: reviews
• External status/issue trackers for this specification: issues

Further details:

• [X] We have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: No specific deadline, but interest in shipping when possible
• The group where the work on this specification is currently being done: WICG incubation
• The group where standardization of this work is intended to be done: Devices and Sensors WG
• Major unresolved issues with or opposition to this specification: Security and privacy issue tracker

As a result of earlier feedback received from among other WebKit, we have updated the spec to introduce the high level states concept

You should also know that... We'd prefer the TAG provide feedback as:

Leave review feedback as a comment in this issue and @-notify @kenchris

[cynthia]

Positive feedback on data minimization approach detailed in the privacy & security considerations seciton - see data minimization for our emerging work in this area. Also the user needs are well defined in the explainer.

We'd like to hear what the developers think about how useful this is especially in multi-core (especially heterogenous) setups, once it moves on to trial.

We noticed that WebKit position is WIP, could you poke that thread and see what they think?

[kenchris]

Thanks @cynthia !

We are working our way through the PING feedback and will poke WebKit after that

[hober]

WebKit's position on this from May 2021

[hober]

Mozilla's standards-positions issue on this

[anssiko]

@cynthia thanks for your feedback! Speaking as the co-chair of the WG responsible for this API, I'm hearing the TAG is not suggesting any concrete changes to the API at this time but is interested in feedback from early-adopter developers. The WG will provide the TAG this information when it becomes available.

Informed by both WebKit and Mozilla folks' feedback provided in May 2021 the WG has improved the API substantively from its earlier version using in particular data minimization principle as a guide. The WG believes it has addressed this feedback from May 2021 with its redesigned API.

[torgo]

Hi @anssiko - thanks for the opportunity to review this spec. We're generally happy with the design and the articulated user needs. We remain concerned about multi-stakeholder support. We note that this API is going to experimental implementation. We'd be interested to review the results of that experiment. Thanks! ✨

[anssiko]

@torgo, Zoom, Whereby and Slack have shared with the WG they're experimenting with this API. Also other players are trialing but haven't publicly shared this information.

When we receive the final feedback from the first wave of early adopters we'll share a summary as applicable. Thank you for your review and suggestions.

[kenchris]

Though we cannot share the exact feedback from the origin trial due to confidentiality, the feedback was quite positive with all respondents extremely likely to continue using the API. None of the respondents found the API hard to use, but we received some minor feedback on the API shape and feature requests that we have adopted or at least filed issues for.

Please see below for aggregated and manually vetted OT feedback that was shared as per Google's policy:

• 100% of the respondents are extremely likely to continue using the API.

• 43% of the respondents found the API 'Extremely easy'

• 43% found it 'Neither easy nor difficult'

• 14% found it 'Moderately easy' to use.

• 7% of the respondents mentioned that they would prefer to give the callback frequency in time units (secs, milliseconds), similar to other APIs such as setInterval in place of Hz as currently designed. A number scale along with labels would be more useful e.g. { pressure: 2, label: 'nominal' }.

• 2% of the respondents suggested adjusting thresholds or combining states to reduce "flapping" between fair and nominal