That's a performance comparison against TLS 1.2. It doesn't speak to why they're concerned about authentication+confidentiality+integrity for audio-video streams in the first place.
It's possible to distribute large binary blobs over unencrypted HTTP, and to provide security using hash checks. I believe apt no longer does this due to a flaw in their implementation that would not have been an issue if they'd used HTTPS. I'm unsure if Steam still uses insecure HTTP, but they certainly used to. [0] [1]
I'm all for HTTPS everywhere, but for Netflix and YouTube, that means encrypting exabytes of data. That's going to cost them quite a bit. Seems reasonable to go for more detail than It's good practice in general.
> Are you hinting at something here
No, as I put in my first comment, I think we know the specific reasons (untrustworthy ISPs), it's just interesting they didn't mention them.
Given that hardware encrypting/decrypting is omnipresent, is it really that much more expensive to stream content securely? I'd like to see the numbers, but I just don't think it's actually a meaningful increase in cost. Network traffic itself tends to be the dominating factor in cost, with encryption just upping your electric bill slightly.
It seems like the benefits of transmitting your streaming securely (e.g. defeating interloping ISPs) more than exceed the costs, hence why they're doing it.
It took a significant engineering effort at Netflix.
When people whine about the overheads of HTTPS, they're generally talking nonsense, as the overheads are typically marginal. Video streaming providers are the exception.
Either over HTTPS or by signing the manifest files using a well-known public key, and ensuring that stale manifests are never used (otherwise it's possible for an attacker to cause installation of old, vulnerable software).
apt used to be 100% HTTP based. I believe they've changed course recently though. Unsure about Steam.
Steam were clear that the reason they adopted insecure HTTP (previously they used a proprietary protocol) was to enable web caching, by ISPs and other organisations. I can imagine that being very beneficial at a commercial LAN party, for instance.
Not that I'm agreeing that they don't need HTTP, but they could do a HTTPS connection to fetch the (relatively small) hashes. On the native applications they could bundle their public key and do everything via HTTP, signing the hashes.
