Re: [webrtc-stats] Stats API should require additional permission / user opt-in (#550)

> The fine level network information exposed by this API seems to be sufficient to re-carry out this attack.

I think that is a bit too general. Lets ignore for a bit that [CBR]( is the answer to this. Lets also ignore that you have the audio stream.

The key of fon-iks is this: `The  size  of  the  encryptedpacket therefore reflects properties of the input signal`
getStats provides [packetsSent]( and [bytesSent]( With opus we're talking about a typical frame size of 20ms or 50 packets per second.
To carry ouf foniks you would need to call getStats with a resolution higher than that.

Lets try this actually. Go to [one of the samples]( and paste the following:
const bytes = [];
let iv = setInterval(async () => {
  const sender = pc1.getSenders()[0];
  const stats = await sender.getStats();
  stats.forEach(s => {
    if (s.type === 'outbound-rtp') {
      bytes.push([s.packetsSent, s.bytesSent]);
}, 10);
setTimeout(() => clearInterval(iv), 2000);
If you do a ` => x[0])` you can see that in Chrome there you don't even have enough granularity to capture a single packet. In Firefox you do. @henbos can probably comment on getStats caching in Chrome.

I didn't see any discussion in the foniks paper about the frame size/duration but I assume that recall drops if you increase the frame size. The mitigation here might be to limit the resolution of getStats.

Note that this concern probably also applies to [getSynchronizationSources]( which exposes the RTP timestamp and the audioLevel (typically from the ssrc-audio-level extension) and is explicitly designed for high-frequency polling.

GitHub Notification of comment by fippo
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 19 February 2020 06:08:50 UTC