Building a live video streaming website – Part 3 – DRM
benwilber.github.io
benwilber.github.io
> WARNING: This method of DRM will keep honest people honest. But determined people will figure out how to break it. This is the case with any kind of DRM.
It seems to me that this is more about essentially preventing the link being shared.
Having not played around with HLS I don't see why this couldn't be done by simply doing an authentication check and refusing to serve content if the auth check fails.
Preventing decryption of the video is obviously impossible as it's being decrypted on the box itself.
The key rotation seems odd to me.
If you're worried about users sharing their session key or something then that can be dealt with on the back end (it surprises me that, for example, YT seemingly don't care about the same IP downloading a ton of videos in parallel with ytdl, say; I suppose NAT makes it slightly more difficult to detect, but not much more so...).
Once someone has the decryption key they have the plaintext. It's the same plaintext for everyone so what does it matter if it's the same key for everyone? Once they have the plaintext they don't have to give some other users your encrypted stream + key, they can just give the other users the plaintext.
1. Don't use DRM.
2. Feel ashamed for considering using DRM.
3. Repeat.
Buyer beware. Seriously, don't do this to yourself. I read this because streaming is an enigma to me, but this post is suicide.
If you want something this fragile for yourself, just pay this guy to do it for you.
From a cursory look, it looks like he is using nginx-RTMP - one of the most widely used streaming solutions out there: https://github.com/arut/nginx-rtmp-module + ffmpeg
If you know Linux - shouldn't take more than 5-10 minutes to set it up.
After reading, I was excited to read the previous two. The links at the bottom of the page are broken, as they appear to include the wrong date (off by 1).