- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Jun 2023 12:13:56 +0000
- To: public-device-apis-log@w3.org
@kenchris (about 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. The 5-10 seconds delay seems too large and may render the API useless for its purpose (tracking pressure and notify apps when they still can make relevant changes to react voluntarily). We can introduce some random variations, but in all APIs that have such real time bounds (to maintain usefulness), it's very hard to mitigate these kind of attacks, since the attacker's rate of communication could be just slowed down until the point to circumvent the mitigations. That actually is some kind of mitigation already, but I assume we want to do more. We should also think what else makes the side channel / steganography more difficult, i.e. the conditions less regular or relevant - for instance, making it less likely to be able to trigger the API impl raise a notification by manipulating other parts of the system. That depends on that system, and most of those mitigations belong to the underlying platform, rather than the API implementations. Of course the spec should pass down the requirements, preferably without strong suggestions, then the implementations might use platform/HW specific mechanisms to mitigate. But then it's hard to guarantee the outcome. The question is what to do when those mitigations are not available. Should the API impl switch to a safe but limited mode (to be defined), or switched off altogether (signaling a generic rather than specific error). -- GitHub Notification of comment by zolkis Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/197#issuecomment-1582475657 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 June 2023 12:13:58 UTC