- From: pes10k via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jun 2023 21:13:44 +0000
- To: public-device-apis-log@w3.org
@anssiko i think this is a good change, but i think something further is needed in terms of in-spec mitigation. Some questions: 1. can i circumvent the rate limiting by activating and deactivating the listener, since i get the first message immediately on attaching / activating the listener? 2. i didn't see any change to address the concern that one-bit-a-second isn't sufficiently slow to prevent the attack (since a/the primary use cases for this feature is long lived sites like video conferencing). I suggest one of the following approach (in order of preference) a. limit the number of times the signal can flip. A listener can find out that the pressure moved to a new status a maximum of (say) 5 times, and then the listener no longer receives messages. I think this would achieve the main goal of the spec (allowing a processing-intense app to cool off if the system is being pegged) while restricting the amount of information that could be sent through the channel b. have some exponential decay in the update rate. So, the longer you're listening on the channel, the less frequent the updates are -- GitHub Notification of comment by pes10k Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/197#issuecomment-1577484720 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:13:45 UTC