@mux/ai

Have you ever been

on Netflix and

seen a scene that

you want to share

with friends or

family and so you

take a screenshot

or record your

screen, all for it

just to turn black?

Well that's

DRM in action.

DRM stands for

digital rights

management and is a

generic tool that's

used across digital

media to control

access to content.

Who can see or

view or share any

protected content.

DRM works really

well for companies

who are live

streaming sports

and want to prevent

valid customers from

sharing the stream

out with a lot of

other customers

who aren't paying.

It's especially

useful for companies

who are sharing

static stream URLs

and want to prevent

you from walking

away with your

favorite movie.

It can also be

used in some cases

where there's user

generated content

that's typically

behind a paywall,

maybe extended cuts

or extra features.

Part of the

intrinsic security

model with DRM is

that a lot of this

authentication is

actually delegated

across many

different actors.

So there's the

DRM provider on

one hand, which

does the actual

authentication

to allow your

computer or your

device to play

back the content.

The players check

the manifest for

keys and access the

license request.

The content

decryption module

takes the response

from the license and

actually decrypts

the content.

So take it from

me, there's a

number of different

steps in this

whole DRM process

and implementing

any one of them

is difficult.

But implementing

all of them by

yourself is next

to impossible.

So let's say

you want to

watch Dune this

weekend on Macs.

The first thing

you do is log in,

find your movie,

and click play.

This determines

if you as the user

are allowed to

view the content

in the first place,

but Now we have to

determine if the

device is allowed

to play it back.

The first thing the

player will do when

it recognizes that

it needs to make a

license request is

ask the CDM to look

at the host machine

and determine a

couple of factors,

like is it the right

operating system?

Do you have any

monitors plugged in?

And if those

monitors are

plugged in, are

they the right

HDMI, HDCP version?

If all those things

check out, it

creates an opaque

blob that the client

can then send to

the DRM provider.

The provider will

do that comparison

and see is this end

device allowed to

play this content.

It's an important

distinction to make

here that it doesn't

actually do the

user authentication.

That's still your

responsibility as

the platform owner.

But if that device

is allowed to play

back that content,

it will return

the decryption

key with a few

other features.

The CDN can then

take that response,

that license, apply

it to the encrypted

content, and return

to the client, uh,

decrypted and ready

to play video.

And that all happens

faster than you can

say Lisa Nalgaib.

So we've

talked about the CDM

and what information

it might put into

the license request.

It's important

to note that the

more strict you

make these license

requirements, the

more compatibility

issues you might

run into on lower

powered devices,

legacy devices, etc.

That might be

perfectly acceptable

for your use case.

You can think of

DRM as a constant

dialogue between you

and your end users.

There are a lot of

mitigating factors

you can use to

secure your top end

content, while still

being permissive

for some of your mid

range resolutions.

A very common

practice is to make

your 4K and UHD

content strictly

policed, whereas

your HD has some

middling security,

and then your SD

content is a little

bit more accessible.

Obviously we've

barely scratched

the surface for DRM.

There's an enormous

list of concerns

ranging from

cryptography to

video packaging,

but I'll save

you those details

in this video.