- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Mar 2022 10:53:15 +0000
- To: public-webrtc-logs@w3.org
> If we were doing rate-limiting, I'd rather do it on the notification end Agreed. A potential counter-point would be that this still allows a capturee to bombard the memory of the capturing application, but: 1. We could allow the UA to put a hard-cap for those truly rare occasions. 2. This is a very unlikely attack, as the capturee would be expending a lot of its own CPU resources in order to attack an would-be capturer - an entity the capturee does not know exists, let alone its identity. So I propose: 1. Adopt your mechanism of allowing the UA to insert a short delay. 2. Allow UA to raise an exception if `setCaptureHandleConfig()` is called exceedingly often, according to the UA's own definition. (But ideally something well over twice-per-second.) -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/11#issuecomment-1062796354 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 March 2022 10:53:17 UTC