Privacy concern: Leaking communication / plain text using patterns in packet size, frequency, etc.

[henbos]

Originally from #550 filed by @pes10k:

The stats collected by this API enable two new privacy harms / risks. This spec should enable the main uses of WebRTC, without automatically exposing these additional risks.

Prior work (e.g. http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf) has shown that you can recreate the plain text content of an encrypted, dTLS encoded audio conversation, based on patterns in packet size, frequency, etc. The fine level network information exposed by this API seems to be sufficient to re-carry out this attack. If this is needed for analysis / quality control / etc use, the API should limit it to these special cases (additional permission, for example).

[henbos]

@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 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.

[henbos]

All of that being said though, MediaStreamTrack is already exposed to JS (for both send and receive side) and the JS is talking to other endpoints which could just decode everything anyway so not sure if getStats() would be the prime target (e.g. if you're trying to deduce content from the getStats rather than from the track or the backend, you're doing it the hard way - if not impossible way due limited granularity)

[henbos]

Should this be a https://www.w3.org/TR/webrtc-identity/ issue? For non-isolated streams, permission has already been granted by the user for the app to access the contents

[alvestrand]

Closing this after filing w3c/webrtc-identity#39