TCP/IP headers leak info about what you're watching on Netflix | Hacker News Reader

TCP/IP headers leak info about what you're watching on Netflix

theregister.co.uk

16 pointspera7 comments

The GitHub repo[0] says that the server takes about 20 minutes to load the data and requires about 30 GB of memory to run. It would be interesting to play around with this, but I don't think a lot of people have a spare 30 GB of RAM in their box. Would it be feasible to modify the program so that it just reads from the filesystem instead? Or would that slow it down to the point of the server being unusable?

0. https://github.com/andrewreed/codaspy2017

I tried spinning up a VM on google gcp this weekend since my laptop was low on memory, and easily scaled it to 24gb with a literal click of a button. At a few bucks per hour, it doesn't really seem that far out of reach for most people these days?

Hm, I actually hadn't considered that. I suppose that is a good solution, if you don't mind paying a few bucks to spin up a VPS.

Summary: VBR encodes videos with a variable bit-rate throughout the video. By fingerprinting many videos, recording the bitrate at different parts of the video, they can make a guess at what you are watching by looking at the size of the stream being downloaded while watching the video, even with HTTPS, likely even over a VPN.

Very rough analogy: Whoever delivers your parcels can tell if you ordered parts to assemble a jumbo jet or a lawn mower just by looking at the quantity, size and sequence of parcels. Since it is known what kind of blueprints you have (the netflix library), it's not too hard to match the parcel sequence (or a part of it) to the order list of a known blueprint.

What do TCP/IP headers (SEQ/ACK/RecvWindow/src port/dst port/packet length/checksum/morefrags flag etc.) have to do with HTTP headers??????

Nothing. HTTP headers aren't used in this. Just sequences of APU sizes which are guessed from TCP headers.

Reply on news.ycombinator.com