- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Sep 2022 14:06:28 +0000
- To: public-webrtc-logs@w3.org
@pes10k Does the paper say what kind of granularity the packet information is needed in order to exploit this? getStats() does not have per-packet information only total counters, so I would assume you would have to call getStats() at a pretty high calling frequency in order to deduce anything about per-packet metrics. The spec does contain [guidelines for stats caching](https://w3c.github.io/webrtc-stats/#guidelines-for-getstats-results-caching-throttling) and while nothing is mandated at the moment, Chromium implements a 50 ms caching interval today, i.e. if you call getStats() more often than this you would end up getting cached results and you would only be able to tell average rates over the 50 ms interval. (50 ms was chosen arbitrarily, we may be able to increase the cache time further.) A proposed way to mitigate this privacy concern would be to say that implementations MUST cache results for at least X ms, where X is chosen such that it would be infeasible to deduce plain text from the information provided. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/699#issuecomment-1259562367 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 September 2022 14:06:30 UTC