Compute Pressure API

[rniwa]

WebKittens

@achristensen07 @youennf @rniwa

Title of the spec

Compute Pressure Level 1

URL to the spec

https://w3c.github.io/compute-pressure/

URL to the spec's repository

https://github.com/w3c/compute-pressure/

Issue Tracker URL

https://github.com/w3c/compute-pressure/issues

Explainer URL

https://github.com/w3c/compute-pressure

TAG Design Review URL

No response

Mozilla standards-positions issue URL

No response

WebKit Bugzilla URL

No response

Radar URL

No response

Description

[Proposal for] a new API that conveys the utilization of system resources, initially focusing on CPU resources (v1) with the plan to add other resources such as GPU resources in the future (post v1).

[rniwa]

From https://lists.webkit.org/pipermail/webkit-dev/2021-May/031848.html, we do not support this proposal for the reasons including but not limited
to:

1. CPU utilization isn't something which can be easily computed or reasoned on asymmetric multi-core CPUs, not to mention the dynamic adjustment of CPU frequency further complicates the matter.
2. Whether the system itself is under a heavy CPU load or not should not have any bearing on how much CPU time a website is entitled to use because the background CPU utilization may spontaneously change, and the reason of a high or a low CPU utilization may depend on what the website is doing; e.g. a daemon which wakes up in a response to a network request or some file access.
3. The proposal as it currently stands seems to allow a side channel communication between different top-level origins (i.e. bypasses storage partitioning). A possible attack may involve busy looping or doing some heavy computation in one origin and then observing that CPU utilization goes up in another.

[rniwa]

I suggest we add the label position: oppose 7 days from now for the reasons stated above.

[jyasskin]

When possible, it'd be good for standards-positions requests to cc the feature's proponents so they can address any possible factual mistakes. In this case, I believe that's at least @kenchris and @arskama.

On (3), the proponents presented some mitigations to the PING at TPAC, which @pes10k reviewed at w3c/compute-pressure#197 (comment).