Has anyone demonstrated that this attack is actually practical? It's super interesting.

One way to defeat it, that is already happening to some extent (though not for this reason), is buffering. Maintain a large enough local buffer, and fill it at a constant bitrate, rather than runrate, and you lose this attack vector, no?

The attack is known from VoIP systems: https://www.researchgate.net/publication/321888273_Classific...

Adapting the research to other non-CBR streams doesn't sound far-fetched.

VoIP is a completely different use case though because it needs to be real-time. A latency of even 100ms is noticeable. By contrast, Netflix is streaming pre-recorded content, so any latency is not perceived at all so long as it is smaller than the buffer size. E.g. I could have a 5 minute buffer and suffer a 4 minute Internet outage and never so much as notice, whereas that would obliterate any VoIP use case.

I agree it's not exactly the same. I would also love to inhabit the parallel universe where Netflix hands out a 4-minute buffer, because in this one 20 seconds seems to be on the high end.

However, I strongly suspect that Netflix's video and audio are sent in different streams. Occasionally video for some titles is missing but audio gets through, confusing our daughter to no end. So while you can't infer individual syllables from the audio stream (as you would from VoIP), the audio streams should have varying enough size and chunking characteristics that allow to identify them.

> I would also love to inhabit the parallel universe where Netflix hands out a 4-minute buffer, because in this one 20 seconds seems to be on the high end.

Presumably it depends on the device, but I vaguely recall testing this out on a Chromecast, and I found Netflix to buffer up for several minutes. Some other streaming providers, such as Rakuten, only buffered around 15 seconds.

> I strongly suspect that Netflix's video and audio are sent in different streams

I think this might be right. They presumably want to support lots of different combinations of audio codecs and video codecs, so keeping them separate would make sense. Pure guesswork on my part though.

This is why someone needs to do the research on it. Even a 20 second buffer, filled at a constant bitrate, may suffice to deter the vast majority of potential bitrate signatures that could be used to identify the stream. The status quo may already be sufficient defense.

Interesting data point on the separate AV streams. I can't say I've noticed that myself.