- From: Kenneth Rohde Christiansen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jun 2023 21:18:11 +0000
- To: public-device-apis-log@w3.org
We can do a bit more. Rate obfuscation === One option would be to put a limit on how many change events are acceptable, say per minute, and if that is reached, maybe postpone reporting for say 5-10 seconds. We could detect if abnormal behavior is happening, like say 10 change events spanning across multiple states and then delay reporting by a random value and only report the latest change. Break calibration === Calibration is important to be able to manipulate the CPU into certain states, so slightly changing the buckets that result in the states at runtime would be a mitigation strategy, as well as including other hardware signals, like say temperature as you could expect the temperature to stay consistently high after continuously going into “critical” and “serious” state, without a cooling down period. The broadcaster also cannot recalibrate as that would require using Compute Pressure API, meaning a different origin cannot listen at the same time, and it also needs to be in the foreground. -- GitHub Notification of comment by kenchris Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/197#issuecomment-1577491096 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 June 2023 21:18:12 UTC