On Wed, May 5, 2021 at 11:37 AM Olivier Yiptong via webkit-dev < webkit-dev@lists.webkit.org> wrote:
> > 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. > > Thanks! > > > - Specification Title: Compute Pressure API > - Specification URL: https://oyiptong.github.io/compute-pressure/ > - Explainger: > https://github.com/oyiptong/compute-pressure/blob/main/README.md > - ChromeStatus.com entry: > https://chromestatus.com/features/5597608644968448 > - TAG design review request: > https://github.com/w3ctag/design-reviews/issues/621 > - Mozilla Request for Position: > https://github.com/mozilla/standards-positions/issues/521 > > 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. We've reported an attack of a similar nature in https://bugs.chromium.org/p/chromium/issues/detail?id=1126324. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
