EME encodes the video content. i.e. without eme you can basically extract the video via tcpdump, with eme you can't since everything, even metadata is encrypted.
the attack inside the pdf does basically mention the old technology which netflix used and not dash+eme inside video element (MPEG-CENC). i.e. widevine
which is kinda funny because the browser drm is highly controversial, but in this case serves as additional privacy since video metadata and content get's encrypted, no matter which transport layer is used.
EME encrypts the video content, yes, but I don't see that this changes things. Netflix uses HTTPS (TLS) encryption over the top of the EME encryption, as this thread's title states.
> even metadata is encrypted.
I don't believe so. If you're delivering EME-encrypted blobs over insecure HTTP, an ISP will be able to see which blobs you are requesting, simply by their URL.
Aside: I recall reading that Netflix's CDN servers ('OCAs') store EME-encrypted blobs, so only the HTTPS encryption burdens the delivery server's CPU. Unsurprising, of course.
> without eme you can basically extract the video via tcpdump
Six years ago, sure. Today, no, as the stream is sent over HTTPS.
> in this case serves as additional privacy since video metadata and content get's encrypted, no matter which transport layer is used.
Perhaps unencrypted streams are still used to support legacy devices, but Netflix are committed to maximal use of HTTPS.
I don't see how EME's additional layer of encryption changes anything as far as privacy and unscrupulous ISPs are concerned.
the attack inside the pdf does basically mention the old technology which netflix used and not dash+eme inside video element (MPEG-CENC). i.e. widevine which is kinda funny because the browser drm is highly controversial, but in this case serves as additional privacy since video metadata and content get's encrypted, no matter which transport layer is used.