I, for one, learned quite a few things too out of your presentation, which is here: https://2019.eurobsdcon.org/slides/NUMA%20Optimizations%20in...
And we have John Baldwin to thank for upstreaming the Netflix kTLS.
It seems like encrypting the video stream traffic at this kind of scale requires a substantial engineering effort and special hardware.
Encryption also means that shared downstream caches at ISPs can't do anything to reduce their bandwidth consumption. The only option is to contact Netflix and physically install one of their edge caching boxes.
Content tampering protection could be obtained by simply computing content hashes offline once, which the clients could verify.
Such as an end user device asking for 4k, but a middlebox somewhere between the customer and Netflix inspecting the http content and blocking it (or modifying the client request in flight), because "only 480p allowed here" or something like that.
TLS fixes a whole lot more than just privacy, it's also authenticating the remote end. Are we really suggesting dumping something that is trivially accelerated in hardware to do some homebrew crypto crap just for the sake of a forum thread?
Netflix solution is fine, and the concentration of interest in TLS means it only gets cheaper over time to build Netflix-like configurations, which is especially great since we've spent the past decade or more trying to convince the entire industry this configuration is also best practice
But yeah, you’re right. You could glean a lot of information from nothing but a collection of movies’ exact runtimes, as visible from the network stream. Although that wouldn’t tell you much about a single movie, given enough viewings you could make pretty good guesses about which movies someone is watching.
Like let's say you're a network admin of a college with conservative religious views, and you want to see if anyone in the dorms is watching "immoral" content. You probably can just intercept an entire unencrypted session and replay it on your machine and see what it was. But you don't really have the funding or access to expertise to develop a side channel attack yourself, and there are no off-the-shelf devices that will do this for you, are there?
Encryption is likely the difference between your management saying "Show me what the kids are watching" and "This isn't worth assigning our network admin to spend half a year on effectively a cryptography research problem."
(Incidentally, encryption may also be what allows a sympathetic network admin to refuse an order from their management, which is also worth considering in your threat model.)
I think it's true that if you had either the resources of one of the richest handful of countries in the world or access to some talented grad students etc., you could do it. But if you're even a non-rich country (like one of the many small countries with moralistic governments that censor the internet) it seems harder, and if the goal is spying on what people watch, it's unlikely that people talented enough to do it will find this a problem they're happy to volunteer their time to solve.
(This is a genuine question - the attack might be much easier than I think!)
https://www.xda-developers.com/android-permissions-bypass-pl...
https://www.trustedreviews.com/news/facebook-scraping-call-m...
They are completely terrible on privacy, lol, the answer here is "if you care about privacy don't use a samsung". Or more generally "don't use android".
If you care about privacy, you don't buy Samsung phones (or other products like TVs). They are the tip of the spear on data collection.
Also while HN likes to raise the spectre of TVs connecting to open wifi/shipping with 5G radios, at the moment there is no evidence for either so users could always use a trusted device to play back Netflix rather than the TV app and leave the TV without internet
But, beyond that, the battle to use http when it makes sense has been lost. Modern platforms strongly encourage https and discourage http.
True there's no out-and-out porn, but there is content that's close to the line, and beyond that there are themes that could be indicators that a viewer is gay, or in some other demographic that he might want to keep private.
Target can tell if you're pregnant based on your shopping; certainly there's a lot that can be inferred from the movies you watch.
I am very skeptical about that story, it sounds too good/scary to be true, and there is only 1 reported incident, without proper sources. Sounds made up to me.
https://medium.com/@colin.fraser/target-didnt-figure-out-a-t...
I'm genuinely curious: why did you implement it in FreeBSD rather than Linux? Isn't that kind of offload something that already exists in Linux? Or does something in the way Linux is implemented/designed that makes it impractical / impossible to implement as efficiently? Or is somehow Linux not secure enough for your use case? Or not something else enough?
I'm asking because I'm always interested to know what are the practical limitations of Linux and also because, while I think it's nice that Linux had some serious competitors, I cannot help being a bit sad that contribution like this will only benefit the few people that use FreeBSD (even if to be fair, it seems that it will benefit all netflix customers at least, which is quite a few people ;) )
Same could be said the other way around, the thing is Linux can implement it and even take the code, the other way is rather difficult....so much for freedom.
And not sure what you mean with "few" people, the few Playstation 3/4/5 users? Juniper? OpnSense/Pfsense installations? Or the few Truenas/Freenas users?
>Or not something else enough?
The point of the licence is a good point. Is the kind of code drewg123 is referring to regularly copied from BSD to Linux? (i understand it should be possible in this direction?).
Thanks for the video, looks like exactly what I was looking for, I will watch it later.
However, publicizing the ideas and the results is valuable to other operating systems even without the code. If you're building something on Linux (or Windows? or ?) that could benefit from kTLS (including NIC accelerated kTLS), knowing it can work and having a roadmap is great. You would still need to do the plumbing, but you could skip a lot of the design. Being able to look at the code is nice too.
And, if you're willing to try FreeBSD + nginx, you could jump directly to that. If you're deploying something with similar performance characteristics to a CDN box, it's probably a very narrow application, and doesn't need to run on the same stack as the rest of your fleet.
Not to mention all the Minix and NucleusRTOS Users ;)