Intent to Experiment: Compute Pressure API

[Olivier Yiptong]

Contact emails

oyip...@chromium.org, pwn...@chromium.org

Spec

Spec: https://oyiptong.github.io/compute-pressure/

Explainer: https://github.com/oyiptong/compute-pressure/blob/main/README.md

Summary

We propose a new API that conveys the utilization of CPU resources on the user's device. This API targets applications that can trade off CPU resources for an improved user experience. For example, many applications can render video effects with varying degrees of sophistication. These applications aim to provide the best user experience, while avoiding driving the user's device in a high CPU utilization regime.

High CPU utilization is undesirable because it strongly degrades the user experience. Many smartphones, tablets and laptops become uncomfortably hot to the touch. The fans in laptops and desktops become so loud that they disrupt conversations or the users’ ability to focus. In many cases, a device under high CPU utilization appears to be unresponsive, as the operating system may fail to schedule the threads advancing the task that the user is waiting for.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ

Goals for experimentation

This API provides device-specific information and has been thoughtfully designed to provide useful and actionable metrics while preserving user privacy.

We'd like to experiment on the capabilities offered by the API, to see if the information provided provides the user experience improvement sought after and if the shape matches developer expectations.

We will measure API usage metrics and obtain developer feedback to validate our designs. We'll focus on feedback on UX changes on lower-powered devices specifically.

Experimental timeline

M91-M94

Any risks when the experiment finishes?

Users on low-power devices may have increased computational utilization and therefore a degraded UX.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

The initial implementation will support Linux and Chrome OS. Windows and Mac support will come in the following milestone, i.e. within the OT, aiming for M92.

Link to entry on the feature dashboard

https://chromestatus.com/features/5597608644968448

[Daniel Bratell]

Hi,

I wonder if you have considered the possibility of using this information to intentionally or unintentionally communicate information about what is going on elsewhere on the device or the browser? In the draft specification the security/privacy section is currently empty.

In recent years there have been a series of security attacks that have used the ability to pick up obscure information through a side channel, and this seems to have potential to be such a side channel.

But you have probably thought more about this, so maybe you can add what you think?

(Sorry if this is a duplicate mail, I sent a mail about this a couple of days ago but I cannot find it so I'm sending it again)

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAo21k3W24ktFzaKvdOvTZfKhbN0Y0JqicMOqb%3DOMRvgn6o%2B6A%40mail.gmail.com.

[Olivier Yiptong]

Hi Daniel,

Thanks for your inquiries. Replies inline.

I wonder if you have considered the possibility of using this information to intentionally or unintentionally communicate information about what is going on elsewhere on the device or the browser? In the draft specification the security/privacy section is currently empty.

Do you mean the sharing of CPU information for identification across origins? We have some mitigations that are discussed in the explainer: https://github.com/oyiptong/compute-pressure#minimizing-information-exposure

We'll add those in the spec as well.

In recent years there have been a series of security attacks that have used the ability to pick up obscure information through a side channel, and this seems to have potential to be such a side channel.

But you have probably thought more about this, so maybe you can add what you think?

Yes indeed. We believe that the mitigations explained above, especially the one about rate-limiting (https://github.com/oyiptong/compute-pressure#rate-limiting-change-notifications), in combination with other mitigations, should be sufficient to minimize the risk of timing attacks.

[Daniel Vogelheim]

Hi Olivier & Daniel,

On Thu, May 13, 2021 at 9:51 PM Daniel Bratell <brat...@gmail.com> wrote:

Hi,

I wonder if you have considered the possibility of using this information to intentionally or unintentionally communicate information about what is going on elsewhere on the device or the browser? In the draft specification the security/privacy section is currently empty.

In recent years there have been a series of security attacks that have used the ability to pick up obscure information through a side channel, and this seems to have potential to be such a side channel.

But you have probably thought more about this, so maybe you can add what you think?

Security & Privacy reviewers looked at this, also in light of WebKit stance, here. We believe the concern is technically correct, in that the "compute pressure" API indeed offers access to an abusable, system-wide timing side channel, across different origins or incognito mode. However, the underlying system-wide side channel is not the API, but the shared cpu(s). This side-channel already exists and is already query-able. That is, some proxy of "cpu load" can be determined by timing other APIs or plain code execution. The "compute pressure" API would make the legitimate use cases a little easier while adding little to abuse scenarios. So from our perspective, the proposed API isn't great, but not harmful either.

 

Leaving the privacy section of the spec empty is IMHO a little embarrassing, though. That should be fixed, since there are certainly privacy & security considerations here.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5657bdc4-4377-5cb9-b82f-431ba7c6ac48%40gmail.com.

[Daniel Bratell]

I guess this would be safe enough to experiment with considering that input, but with the information I currently have, I think privacy and security might need further tuning before a shipping decision. Daniel Vogelheim is of course correct in that some of this information can be deduced already with clever coding, but this could, if proper care isn't taken, intentionally leak more information.

/Daniel

[Mike West]

With Daniel (and Daniel)'s feedback in mind, LGTM to experiment through M94.

I look forward to learning more about whether this mechanism solves the problem developers face, as some of the critiques raised about the API's shape seem reasonable (see the webkit-dev thread above, and some of the questions in the TAG's review (https://github.com/w3ctag/design-reviews/issues/621)).

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25339793-ec7a-8fac-2704-98602278b0d5%40gmail.com.