Re: [w3ctag/design-reviews] Incubation: CPU Performance API (Issue #1198)

marcoscaceres left a comment (w3ctag/design-reviews#1198)

Thanks for sending us this review. After looking at it in a breakout, we have several concerns that we'd like you to address before we set a final position:

First, it's not clear that the [motivating](https://github.com/WICG/cpu-performance/#motivating-use-cases) [use cases](https://wicg.github.io/cpu-performance/#intro) are served by a static measure of CPU performance. We had to guess at how "video conferencing applications" would use this API. For anything related to media decoding and encoding, measurements should reflect the available processing hardware, which often isn't inside the CPU. [`MediaCapabilities`](https://developer.mozilla.org/en-US/docs/Web/API/MediaCapabilities) and possibly the `isConfigSupported()` methods in the WebCodecs API are close, and much better than making assumptions based on the CPU. Similarly, the choice of what neural-network models to use needs to take NPUs and GPUs into account, rather than focusing on the CPU.  If these applications need to get a signal of headroom, consider extending those APIs rather than adding an API that indicates the headroom of the wrong processing unit. Without a clear user-serving use case, we shouldn't add new APIs to the platform. Even with one, please talk to the WGs that focus on those use cases, to see if there's a more-targeted API they can add, which might make a better [low-level vs high-level tradeoff](https://www.w3.org/TR/design-principles/#high-level-low-level).

We see that the [WebKit position](https://github.com/WebKit/standards-positions/issues/622#issuecomment-4232993932) is concerned about the choice of a static vs a dynamic value. For example, a web application may need to re-scale its processor use when it gets hot, when the user sets the device into a low-power mode, or when the user is running other processing-intensive workloads in parallel. We see some indication that the choice of a static measurement is intentional, especially in the statements that this API is meant to complement the Compute Pressure API. However, we don't see an explanation of exactly what you expect applications to do with a static measurement. We guess that it's about downloading code that's flexible enough to cover the range of performance levels that a given machine could expose, but we'd like to see some evidence that this is actually how applications will use the data, and that this up-front downloading is better for users than downloading the right code as conditions change.

We're very concerned about the spec's mention of "Select ads that are better suited for the user device." CPU performance correlates with disposable income, but users can be harmed by exposing that to advertisers. Exposing this may be inescapable (e.g. via benchmarks), but API designers should try to obscure it, not treat it as a feature.

We also want to make sure that the top-level page has control over which iframes can get this information.

We look forward to your responses. Thanks!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1198#issuecomment-4341573837
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1198/4341573837@github.com>