CDN DRM

Live and on-demand video is easy to steal once it's decrypted in the browser. Standard DRM systems like Widevine or FairPlay solve this at the OS/hardware level, but they're heavyweight, platform-restricted, and often overkill for a use case that doesn't need studio-grade protection, just enough friction to stop casual restreaming, direct URL reuse, and unmodified bots from lifting a stream wholesale.

The harder problem isn't encrypting the video once. It's doing it in a way that still lets a CDN cache the content normally, since caching is what makes video delivery affordable at scale in the first place. Encrypt naively and every viewer needs a unique file, which defeats caching entirely. Encrypt predictably and the CDN can do its job, but only if you're careful about what "predictable" means from an attacker's perspective.

Content is encrypted between origin and the CDN using a custom stream cipher implemented in Rust, compiled to WebAssembly so the same encryption logic runs identically on the server and inside the browser. Keys are derived per segment from the content path itself, so the same segment always encrypts to the same output. That means the CDN can cache encrypted objects exactly like it would cache plaintext ones, it just can't read them.

On the browser side, a custom fork of the video player intercepts encrypted responses before they ever reach the normal playback pipeline. Those responses get decrypted by the WASM module in memory and handed off to the player as if they were clear HLS all along, so nothing about the actual playback logic changes.

Access to the decryption key isn't handed to the page freely. Before playback starts, the client goes through a short handshake with a key server, proving it's running the real player on an approved origin rather than a script replaying URLs. That handshake includes a proof-of-work step and a set of behavioral checks meant to distinguish a real browser from an automated one. Only after that handshake succeeds does the client get a session-specific key it can use to decrypt the stream it's about to play.

This is also where the fingerprinting piece lives. The same handshake that gates key access doubles as a detection point, flagging clients that look automated, that are replaying a stream from an unapproved origin, or that show the fingerprint of a restreaming setup rather than a normal viewer.

This system is designed to stop the common cases: someone grabbing an HLS URL and rebroadcasting it, a bot scraping the stream directly, a naive script pretending to be a browser. It is not equivalent to hardware-backed DRM, and it's not meant to be. A sufficiently motivated attacker running the actual player on an approved origin could still extract what they need, the same way any software-only protection eventually can be worked around given enough effort. The goal was raising the cost of casual and semi-automated theft, not building something unbreakable.

DRM is usually treated as a binary: either you have real hardware-backed protection, or you have nothing worth calling protection at all. This project sits in the middle deliberately. It doesn't try to be Widevine, it tries to make the easy attacks not easy anymore, while staying compatible with normal CDN caching instead of fighting against it. Most content doesn't need studio-grade security, it needs enough friction that casual theft stops being casual. That's the problem this was actually built to solve.