The file is already encrypted for DRM purposes... if thry want to go beyond that, how about a system where each edge server gets a differently encoded file from the master?
(though... I was just thinking about this, and due to the use of variable-bitrate encoding, the varied rate of data transmission over time (even though encrypted) would give each video a fingerprint that an observer could use to determine whatever it is that you're watching, anyway, albeit with greater effort that simply inspecting the unencrypted stream)
As I recall, monitoring total home power consumption could also identify what you're watching on TV. That was on the old CRT sets, not sure about now.
Gotta love side channel attacks.
I'll give you the rewind scenario, but play/pause events are going to be equally obvious in HTTPS. Besides, what exactly does the attacker learn? That you were watching Netflix during that time? The HTTPS traffic to Netflix will be an equally good indicator of that.
One possibly relevant factor is that shared encryption keys make it harder to authenticate the data: you can't rely on an HMAC, and RSA verifying every frame would be too slow. You can still do it efficiently with a hash tree, but I bet Netflix currently isn't, and TLS allows browsers to enforce verification on behalf of the user. Without verification, you could potentially exploit the browser with malformed audio or video data, or freak the user out by injecting some other video...
You want to have the app on https for several reason, starting with the security of session cookies, but in the case of DRM, there's a reason for browsers to seek to limit the EME API (the JS API for communicating with the DRM component) to https (though AFAIK no browser does so at the moment):
DRM schemes usually implement node locking, i.e. anti-cloneability of the DRM state from one device to another. The obvious way to do this involves keys that no other device has. If information about the possession of a persistent key that no other device has is exposed to a network eavesdropper (e.g. by presenting, in the clear, a certificate for a unique key), the eavesdropper can use that piece of information to track devices and, therefore, users.
While this problem could be mitigated in the design of the DRM protocol, to move addressing the problem out of what the DRM component controls to what the browser controls, limiting EME to https is the most straight-forward solution that can be implemented on the browser level. And as noted above, this has the side effect of limiting the MSE-feeding XHR to https, which means the media data needs to be served over https.
https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl...
* Not leaking any tracking or user-identifiable information. EME DRM plug-ins track users, but browsers don't have control over this (and I guess it may even be illegal to audit EME DRM security due to DMCA), so it's best to have it on HTTPS just in case.
* All new browser features require HTTPS (and EME DRM plug-ins are new-ish), because browser vendors want to deprecate HTTP, and don't want headache of mixed content or HTTPS alternatives built on DRM.