Security and Privacy questionnaire responses for the Compute Pressure API
This API exposes a high-level pressure state, consisting of four levels, used to indicate whether the system is under pressure and how serious that pressure is. This allows websites to react to increases in pressure to reduce it before it results in throttling or applications fighting over compute resources. Though generally having a nice smooth system is preferred from a user point of view, such throttling can be detrimental to certain application types such as e-sports, games and video conferencing.
In e-sports and games, throttling can result in input lag making you lose the game, and in video conferencing systems, throttling can result in connection breakage - important words not coming across, or even making it impossible to type up minutes while listening to others talk.
An earlier revision of this feature exposed CPU utilization and frequency (clock ticks) with certain modifications as the values being averaged across cores and normalized to a value between 0 and 1 (ignoring certain kinds of boost modes).
The website could then configure a certain set of thresholds they were interested in, but the amount of thresholds would depend on the user agent. This resulted in lots of uncertainties and issues. Like some early adopters were uncertain why certain thresholds were never crossed due to having created one too many thresholds.
Also, utilization and frequency are not the best metrics available. For instance, thermal conditions can easily affect throttling. Utilization might also be artificially high because certain processes are stalled on I/O.
Additionally, CPU design is becoming heterogeneous with different kind of cores (e.g. performance core vs efficient core). There are even systems today with more than 3 different core types, where all cores are never active at the same time. This makes it very hard to look at aggregates and normalized utilization and frequency and base programming decisions upon that in a way that they make sense across a wide range of current and future devices.
The new design allows the user agent or underlying system to provide much better pressure levels depending on the host system without the user needing to know what system the code is running on.
The API design aggressively limits the amount of information exposed.
The information is exposed as a series of change events, which makes it easy for user agents to rate-limit the amount of information revealed over time. The specification encourages user agents to rate-limit background windows more aggressively than the window the user is interacting with.
The information exposed by this API is not personal information or personally-identifiable information.
The information exposed by this API is not sensitive information.
This API does not introduce any new persistent state. It exposes device data that is likely to change every second.
Aside from the data detailed in question 1, which is data about an instanteneous state of the device, no additional data is exposed.
This specification does not allow direct access to sensors. However, the CPU clock speed may be used to make broad inferences about the device’s temperature.
See answer to question 1.
Some information about CPU utilization can be inferred from the timing of requestAnimationFrame()’s callbacks.
No.
No.
No.
The data obtained in step 1 could pose a cross-origin identification issue, however, we think our mitigations would prevent this risk.
The specified API will be available in third-part contexts via iframe guarded by permission policy and focus requirements.
The API works the same way in Private Browsing / “incognito”. We think that the cross-origin identification mitigations also prevent identification across normal and Private Browsing modes.
Yes.
No.
We think that the questions here accurately capture the API’s security and privacy implications.