D
Dennismary Chidiebere
Guest
When people hear "DRM," they picture cryptography: keys, ciphers, the dark art of stopping a video from being copied. That part is real, and on a creator platform that sells video, it is also the easy half. The maths is solved. There are well-understood encryption schemes and well-understood providers to hold the keys. You can buy the hard cryptography.
What you cannot buy is the answer to the only question that actually matters: is this viewer, right now, allowed to watch this video?
That is not a cryptography question. It is a commerce question. And if you build your protection as if it were about ciphers, you will end up with beautifully encrypted content and no coherent way to say who paid for it.
The shape that works is simple to state and easy to get wrong. Encrypt the content once. Decide access per viewer, every single time a player asks to play.
Encrypting once is not a shortcut; it is the point. The encrypted segments are the same bytes for everyone. A subscriber, a non-subscriber, someone who has never logged in- they can all fetch the exact same protected file, because without a key it is noise. There is no "subscriber copy" and "free copy" of the video sitting on disk. There is one copy, encrypted, and it is safe to serve to anyone precisely because serving it decides nothing.
The decision happens later, and elsewhere. When a player wants to actually decrypt and show the frames, it has to ask for a licence. That licence request is the moment of truth, and it is the moment where cryptography hands off to commerce.
Interactive figure: The Cinema Vault. A model of encrypt-once, license-per-viewer: encrypted segments reach every player, and a licence is released only when the rights service says play.
Change the offer and the viewer: the segments always arrive, but only an entitled viewer gets a key.
Run The Cinema Vault on dennismary.com
Here is the move that makes the whole thing coherent. When the player asks the DRM provider for a licence, the provider does not decide on its own. It calls back to the platform and asks: should this person get a key for this content?
That callback is the seam. On the far side of it sits a rights service whose entire job is to answer a commercial question. Does this viewer hold an active subscription? Did they buy this specific video outright? Have they been gifted access, or crossed a gifting threshold? Do they hold a studio that grants them a view? The answer is a boolean, play or do not play, and only "play" releases a key.
Notice what that does. It moves the access rule out of the player, out of the app, out of the client entirely, and into a service the viewer cannot touch. The common alternative is to check entitlement in the app and hide the stream if the check fails. It is cheaper and it is bypassable, because anything the client decides, a determined client can un-decide. We put the decision inside the licence callback instead. The content is the product; the gate protects the product, so the gate lives where the viewer has no vote.
It also means the access rule can be as rich as the business needs without the cryptography knowing or caring. Subscriptions, one-off purchases, gifts, roles, trials, promotions, these are all just inputs to one callback that returns yes or no. The encryption scheme never changes. The packaging never changes. Only the rule the rights service applies changes, and that rule is allowed to be as commercial and as messy as real commerce is.
Where should the entitlement decision live?
An in-app check is cheap and bypassable; baking rules into encryption means re-packaging every time commerce changes. Deciding in the licence callback keeps one encrypted copy and lets the rights service answer a business question the client cannot override.
There is a wrinkle that trips people up, and it belongs to the "encrypt once" idea rather than against it. Different devices speak different streaming and DRM dialects. A browser wants one combination; an Apple device wants another; an Android device wants a third. For a while this looks like it should mean three encrypted copies of every film.
It does not. You encrypt once, with a scheme designed so the same encrypted segments can be described for each family of players. Web, Android and iOS each get a manifest and a DRM system they understand, all pointing at the same protected bytes underneath. Package for each dialect, encrypt only once. The storage stays single, the key management stays single, and every device still gets a stream it can play.
So the flow, end to end, is this. One encryption pass during transcoding. One set of content keys, living with a specialist provider and never on our own systems. Several descriptions of those same segments so every device can ask correctly. And one decision point, the licence callback, where all the commercial logic lives. The cryptography is uniform and boring. The commerce is where all the variation goes.
The payoff of building it this way shows up when you connect payment to playback, which is the whole reason a paid platform exists. A purchase or a subscription is not an entry in a billing table that happens to unlock a screen somewhere. It is an input to the rights service. When someone pays, the rights service learns they are entitled. The next time their player asks for a licence, the callback consults that same rights service, and the key is released. Pay, entitlement, protected playback and the creator's eventual payout become one chain, and the licence callback is the link in the middle that turns money into a decryptable frame.
This is live, carrying paid creator video across web, Android and iOS. And the thing I would tell anyone building it: do not start with the ciphers. Start with the sentence "who is allowed to watch, and why." Write that rule down in plain commercial language first. The encryption is a solved problem you will wire in behind it. The rule is the system. Everything cryptographic is just the mechanism that refuses to release a key until the rule says yes.
Encrypt once, license per viewer, and let the licence ask who paid. The cryptography keeps the honest people honest. The business rule is what you were actually building.
What you cannot buy is the answer to the only question that actually matters: is this viewer, right now, allowed to watch this video?
That is not a cryptography question. It is a commerce question. And if you build your protection as if it were about ciphers, you will end up with beautifully encrypted content and no coherent way to say who paid for it.
Encrypt once, license per viewer
The shape that works is simple to state and easy to get wrong. Encrypt the content once. Decide access per viewer, every single time a player asks to play.
Encrypting once is not a shortcut; it is the point. The encrypted segments are the same bytes for everyone. A subscriber, a non-subscriber, someone who has never logged in- they can all fetch the exact same protected file, because without a key it is noise. There is no "subscriber copy" and "free copy" of the video sitting on disk. There is one copy, encrypted, and it is safe to serve to anyone precisely because serving it decides nothing.
The decision happens later, and elsewhere. When a player wants to actually decrypt and show the frames, it has to ask for a licence. That licence request is the moment of truth, and it is the moment where cryptography hands off to commerce.
Interactive figure: The Cinema Vault. A model of encrypt-once, license-per-viewer: encrypted segments reach every player, and a licence is released only when the rights service says play.
Change the offer and the viewer: the segments always arrive, but only an entitled viewer gets a key.
Run The Cinema Vault on dennismary.com
The licence callback is where the money logic lives
Here is the move that makes the whole thing coherent. When the player asks the DRM provider for a licence, the provider does not decide on its own. It calls back to the platform and asks: should this person get a key for this content?
That callback is the seam. On the far side of it sits a rights service whose entire job is to answer a commercial question. Does this viewer hold an active subscription? Did they buy this specific video outright? Have they been gifted access, or crossed a gifting threshold? Do they hold a studio that grants them a view? The answer is a boolean, play or do not play, and only "play" releases a key.
Notice what that does. It moves the access rule out of the player, out of the app, out of the client entirely, and into a service the viewer cannot touch. The common alternative is to check entitlement in the app and hide the stream if the check fails. It is cheaper and it is bypassable, because anything the client decides, a determined client can un-decide. We put the decision inside the licence callback instead. The content is the product; the gate protects the product, so the gate lives where the viewer has no vote.
It also means the access rule can be as rich as the business needs without the cryptography knowing or caring. Subscriptions, one-off purchases, gifts, roles, trials, promotions, these are all just inputs to one callback that returns yes or no. The encryption scheme never changes. The packaging never changes. Only the rule the rights service applies changes, and that rule is allowed to be as commercial and as messy as real commerce is.
Decision
Where should the entitlement decision live?
- In the app
- In the licence callback (chosen)
- Baked into the encryption
An in-app check is cheap and bypassable; baking rules into encryption means re-packaging every time commerce changes. Deciding in the licence callback keeps one encrypted copy and lets the rights service answer a business question the client cannot override.
Package twice, decide once
There is a wrinkle that trips people up, and it belongs to the "encrypt once" idea rather than against it. Different devices speak different streaming and DRM dialects. A browser wants one combination; an Apple device wants another; an Android device wants a third. For a while this looks like it should mean three encrypted copies of every film.
It does not. You encrypt once, with a scheme designed so the same encrypted segments can be described for each family of players. Web, Android and iOS each get a manifest and a DRM system they understand, all pointing at the same protected bytes underneath. Package for each dialect, encrypt only once. The storage stays single, the key management stays single, and every device still gets a stream it can play.
So the flow, end to end, is this. One encryption pass during transcoding. One set of content keys, living with a specialist provider and never on our own systems. Several descriptions of those same segments so every device can ask correctly. And one decision point, the licence callback, where all the commercial logic lives. The cryptography is uniform and boring. The commerce is where all the variation goes.
Paying becomes watching
The payoff of building it this way shows up when you connect payment to playback, which is the whole reason a paid platform exists. A purchase or a subscription is not an entry in a billing table that happens to unlock a screen somewhere. It is an input to the rights service. When someone pays, the rights service learns they are entitled. The next time their player asks for a licence, the callback consults that same rights service, and the key is released. Pay, entitlement, protected playback and the creator's eventual payout become one chain, and the licence callback is the link in the middle that turns money into a decryptable frame.
This is live, carrying paid creator video across web, Android and iOS. And the thing I would tell anyone building it: do not start with the ciphers. Start with the sentence "who is allowed to watch, and why." Write that rule down in plain commercial language first. The encryption is a solved problem you will wire in behind it. The rule is the system. Everything cryptographic is just the mechanism that refuses to release a key until the rule says yes.
Encrypt once, license per viewer, and let the licence ask who paid. The cryptography keeps the honest people honest. The business rule is what you were actually building.