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

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

Sure (Gemini 3)... ran it a few times, gets the same result:

<details>
# CPU Performance API - Critical Review

### Test 1: Use-case coverage by existing APIs

1. **Verdict:** **Fails**
2. **Evidence:**
   *   **Video/media use cases:** The proposal claims a static CPU tier is needed to determine "the resolution and format for images and video" and to "decide if advanced video effects can be rendered." However, the W3C Media Capabilities API already explicitly solves this. Calling `navigator.mediaCapabilities.decodingInfo(configuration)` resolves a promise with a `MediaCapabilitiesDecodingInfo` object containing `supported`, `smooth`, and `powerEfficient` boolean flags. Similarly, WebCodecs provides `VideoDecoder.isConfigSupported(config)` to evaluate specific decoding constraints. Both APIs actively answer whether a device can handle 1080p, 720p, etc., at a given framerate—making a generalized 1-4 CPU tier proxy unnecessary and strictly less accurate.
   *   **ML/AI use cases:** The proposal claims applications need the tier to "decide whether to attempt running AI tasks locally or delegate to the server." The WebNN API directly addresses this by exposing device-specific hardware acceleration. Developers can request specific hardware via `navigator.ml.createContext({ deviceType: 'gpu' | 'npu' | 'cpu' })` and query exact mathematical and tensor limitations via `opSupportLimits()`. WebNN allows applications to probe precise capabilities rather than guessing based on a coarse CPU bucket.
   *   **Other use cases:** The explainer lists "Control non-essential tasks... use or avoid heavy libraries" and "Improve real user monitoring." `navigator.hardwareConcurrency` and `navigator.deviceMemory` already provide static heuristics for device class, while the Long Tasks API and Interaction to Next Paint (INP) provide *actual* measurements of main-thread contention.
3. **What needs to change:** The proposal must articulate distinct use cases that definitively cannot be solved by `MediaCapabilities` for media, `WebNN`/`WebGPU` for compute, or `PerformanceObserver` for monitoring. Currently, it solves no unique problems.

---

### Test 2: The reproducibility claim vs. OS reality

1. **Verdict:** **Fails**
2. **Evidence:** 
   *   **Spec Requirement:** Section "Computing Performance Tier Value" mandates reproducibility: "An implementation should always report the same performance tier for the same user device... The reported performance tier should not depend on the user device's current load or utilization".
   *   **OS/Hardware Reality:** Modern mobile SoCs (Apple A/M-series, Snapdragon, ARM big.LITTLE) aggressively thermally throttle under sustained load. A device capable of "Tier 4" burst performance can drop to "Tier 2" sustained performance within minutes of running a heavy video conferencing app.
   *   Furthermore, OS power profiles (Windows Battery Saver, Android Doze, iOS Low Power Mode) actively cap CPU frequencies and disable high-performance cores to save battery. If an OS caps a "Tier 4" processor to save battery, but `navigator.cpuPerformance` rigidly reports `4`, the web app will blindly schedule heavy background blur and 1080p decoding. This actively undermines the OS's power management, destroys battery life, and causes severe frame drops.
3. **What needs to change:** "Reproducibility independent of current load" is a fundamentally flawed concept for real-time adaptation. To be useful, any performance signal *must* reflect current OS constraints (thermal throttling, low-power modes) rather than nominal, factory-state theoretical maximums.

---

### Test 3: Privacy and fingerprinting surface

1. **Verdict:** **Fails**
2. **Evidence:**
   *   **Information gain:** The explainer asserts the API mitigates privacy risks by mapping devices to a small number of tiers. However, when combined with `navigator.hardwareConcurrency` (core count) and `navigator.deviceMemory` (RAM), a 4-tier CPU bucket provides a highly specific cross-section that *increases* fingerprint entropy. A device with 4 cores and 8GB RAM could be isolated into distinct SoC families just by adding the `cpuPerformance` tier.
   *   **Permissions Policy & 3rd Parties:** Section 14 of the security questionnaire states: "The API behaves identically in first-party and third-party contexts... allowing third-party content (such as embedded video players) to adapt." Because the spec defines no Permissions Policy feature, tracking pixels and cross-origin iframes get passive access to a stable device hardware fingerprint.
   *   **Cross-session stability:** The spec explicitly requires tiers to be stable and immutable over years ("implementations should not redefine tiers"). A permanent, unchangeable device attribute is the exact definition of a high-value fingerprinting vector.
   *   **Ad Targeting:** The proposal explicitly lists "Select ads that are better suited for the user device" as a usecase. Exposing hardware class for ad targeting correlates heavily with socioeconomic status (flagship phone vs. budget device) without any user consent mechanism.
3. **What needs to change:** The API must be gated behind a Permissions Policy (disallowed in cross-origin iframes by default). The ad-targeting usecase should be removed, as the web platform should not provide socioeconomic proxies for ad networks without explicit consent.

---

### Test 4: Abstraction level

1. **Verdict:** **Fails**
2. **Evidence:**
   *   The proposal exposes a static JavaScript property `navigator.cpuPerformance` that returns an integer. This forces developers to write rigid, imperative heuristics (as seen in the explainer's `switch (navigator.cpuPerformance)` example).
   *   This compares poorly to OS-mediated signals like `prefers-reduced-motion` or `prefers-color-scheme`, which are exposed as CSS Media Queries and can change dynamically based on OS state.
   *   If the goal is to disable heavy effects or animations on low-end devices, a dynamic media query (e.g., `@media (prefers-reduced-performance)` or `@media (performance-tier: low)`) would be vastly superior. It would automatically adapt to OS Battery Saver modes, allow declarative CSS degradation without requiring JavaScript, and avoid exposing a static hardware identifier to tracking scripts.
3. **What needs to change:** Shift the abstraction from a static, imperative JS hardware classification to a dynamic, OS-mediated state signal (like a media query) that respects current system conditions and user preferences.

---

### Overall Assessment

**The proposal does not justify shipping as specified and requires a complete conceptual rework.** 

By attempting to provide a static, load-independent hardware taxonomy, the API paradoxically becomes useless for its own stated use cases (adapting to device capabilities), which are already better served by `MediaCapabilities` and `WebNN`. Furthermore, its insistence on immutable tiers creates a permanent fingerprinting vector that can be exploited by third-party frames for profiling and ad-targeting. 

**Minimum viable change set for rework:**
1. Abandon the static, load-independent `navigator.cpuPerformance` property.
2. Pivot to a dynamic, OS-backed signal (e.g., a `prefers-reduced-performance` media query) that reflects the device's *current* operational reality (accounting for low power modes, user preferences, and thermal throttling).
3. Ensure this signal is designed strictly for adaptive degradation, stripping out the static taxonomy that enables cross-session fingerprinting and ad targeting.
</details>

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

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