If someone can watch your video, they can steal your video. A sufficiently motivated attacker can find a way to steal your videos if they really want to. Like content moderation, it's another arms race where your job is to put up the best defense you can while managing the cost and complexity — making it hard enough for someone to steal your videos that they decide it's not worth their time.
How to steal video content (not a tutorial…)
In order to protect yourself from video thieves, you'll have to first understand how people try to steal video content on the internet. Let's talk about the different attack vectors that you should keep in mind.
Hotlinking/embedding
Someone can grab the URL from the video element that's in your page. This is trivial in a web browser: open the developer tools and you’ll see it all right there, either on the video element itself or with a few clicks in the network tab. We're not talking about grabbing the URL from the URL bar at the top of the browser window. You can protect users from accessing your web application in a number of ways. What we're talking about is someone logging in, loading a web page that has a video player, and then using the developer tools to grab the URL to where the video is hosted. It's slightly more inconvenient on mobile apps, but still fairly easy. All it takes is monitoring the network activity of the app and grabbing the URL. An attacker can take that URL and embed it in their own site. Then promote their site, getting a bunch of traffic to their sketchy landing page papered with ads, they're making ad revenue and you’re footing the video bill. Not great for you.
Downloading
Downloading videos is fairly easy too. Non-adaptive formats like MP4 are the easiest, but even with adaptive formats like HTTP Live Streaming (HLS) it's easy enough to download the video segments and stitch them together to reconstruct the full video. There are even browser extensions and CLI tools that help folks do this.
You might not care about users downloading videos. You might even allow users to download videos, but you'll still want to control that action and make sure only authorized users are downloading.
Screen-recording software
On desktop computers and mobile devices, it takes only a few clicks to record the screen and audio. Later in this post, we'll talk about how you can protect yourself from this.
Physical screen recording
Back in the '90s, people could go to a movie theater with a camcorder and simply record the big screen. Physical screen recording is the modern-day equivalent — only you can't kick them out of the theater, because they're doing it in their own home.
Try as you might, there is no surefire way to stop this attack vector. Someone can play your video and point a separate physical recording device at their screen. They can light the room just right and angle the camera carefully to avoid any reflection from the screen as they record.
What can you do to protect your video content?
There's a whole spectrum of options, starting with no protection at all (which is honestly fine for many use cases) all the way up to very strong protection. Before we get into it, keep in mind that protecting your content is not free. And we don't only mean free in terms of dollars, there are multiple costs to consider:
- Development: Every layer of protection you add will take time to implement.
- Maintenance: More code, more maintenance. Anything you build today will need some level of maintenance. Solutions like Digital Rights Management (DRM), for example, are a constant moving target, requiring continuous code updates to make sure your DRM-protected videos can still be played when new OS versions are released.
- Playback errors: This is often overlooked, but every time you add a layer of security to protect your video from unauthorized viewers, some legitimate users will get an error when they try to watch. This can be minimized with thorough testing, attention to detail, and close monitoring but inevitably, you can expect to see some increase in your playback error percentage
- Dollars: Some tools to lock down your video content cost actual money. Unlike the others, at least this cost is easy to measure!
Before you start slapping DRM on all your videos, consider the cost, the risks, and who you are protecting. Every software project comes down to understanding tradeoffs, risks and benefits, and deciding how to protect your video content is no different.
There's another potential line of defense: even if you can't prevent someone from stealing your video, if you can identify who they are you can mitigate the impact by banning the user from your product or pursuing legal action. If you're dealing with multiple people stealing your video content, this can turn into a time-consuming game of whack-a-mole: banning one user, only for another video thief to pop up.
Let's explore some of the different ways you can protect your video content.
Control access with signed URLs
This is the most basic form of content protection. When a user loads up a video in your application, the video URL contains an individual access token: it can only be accessed under certain constraints. This is most commonly used to add a time-based restriction (roughly the length of the video itself, or a bit longer if you expect users to be scrubbing back and forth). Signed URLs for video work the same way as signed URLs to access a file on Amazon S3 or similar services. After authenticating and authorizing the user, you generate a signed token on your server and pass that token down to the client. That token will expire at some point in the future and when it does, the client will no longer be able to use it. If they want to watch again they have to go back to your server and request a new signed URL.
Signed URLs are fairly straightforward to implement and generating signed tokens on the server side doesn't require any network requests, so your application can generate them quickly and easily without much extra latency to fulfill the user's request.
Remember how we talked about increased playback errors? With signed URLs, you have to think through a few different scenarios to reduce those errors. Let's say someone opens a browser tab, loads your video, starts playing, then pauses to go get lunch … and comes back several hours later and hits the play button again. That URL might have expired so you need to catch that error, get a refreshed URL from your server, and re-load the player (without losing the timestamp of where they were in the video).
Mitigation with signed URLs
A user can still take your signed URL and share it with someone else — and that person can use the exact same URL to watch the video (until the URL expires). But one under-used feature of signing URLs is that you can embed a session ID or a user ID into the token to help you identify the person who leaks a signed URL.
Imagine this scenario:
- You are using signed URLs and your app requires login.
- Users log in, you give them a signed URL, and they can watch a video.
- You notice that your video is being talked about on Reddit or another site where you did not post it.
- As you dig in, you find that someone took your signed URL and shared it publicly, and now a bunch of people are using that URL directly — bypassing your website entirely.
After you find the URL that was shared, you can grab the token from the URL query param, decode it, pull out an identifier like user_id or session_id, and use that to identify the bad actor.
Block viewers outside of your domain with Referrer protection
This applies to playing videos in web browsers (not native applications). When browsers load a video URL, the browser sends a Referer header. One thing you can do on the server side is make sure the Referer header on the request matches the domain of your website. If it doesn't, your server can then reject the request.
This gives you one layer of protection against people grabbing the playback URL and putting it on their own site. It's not a cure-all because referrers can be easily spoofed. Someone who steals your video and wants to make it appear that they are watching from a certain domain can do that fairly easily. Still, it's a handy protective measure against one common attack vector: a nefarious user who steals your video to embed it on their own site (let's call it mybadsite.com). When the rest of the world visits mybadsite.com, their browser will send mybadsite.com as the referrer and you can block those requests server-side.
However, requests from mobile apps do not automatically send referrer headers. If you are playing your videos in a mobile app, you have to allow requests that do not contain referrer headers, so you're out of luck with this approach. Here's another thing to keep in mind: if you want to allow users to AirPlay or Chromecast your videos, then the Referer header is going to be a different value (not the website where they initiated the AirPlay or casting). So make sure you’re allowing domains: mediaservices.cdn-apple.com (for Apple’s AirPlay) and www.gstatic.com (for Chromecast).
One way to do referrer protection is in combination with signed URLs, so you bake in the allowed referrers as part of the claims in the signed token, and verify the referrer server-side.
Eliminate unwanted clients with User-Agent Filtering
Similar to referrer protection, you can disallow requests based on user-agent. You may want to only allow certain clients, like browsers and phones, and disallow user-agents like VLC media player or other unknown agents that might be attempting to play your video from a client that you don't want people using. Similar to the Referer header, the User-Agent header is a self-reported value by the client, so you can't trust its authenticity and it can be easily spoofed.
Similar to referrer protection, this is often paired with signed URLs. In your signed token you can encode the allowed user agents and verify the token and user-agent server-side.
Encrypt with ClearKey and HLSe
OK, let's get into some more advanced options. You might be thinking: can I encrypt the video content so that only my intended clients can decrypt it? Of course you can! But when you encrypt your content, you have to think about how the client receives the keys necessary for decrypting. There is a pattern with ClearKey and HLSe where you encrypt the video content using standard AES-128 encryption, send it over the network, and then the client decrypts it after it's downloaded. To do that, the client needs to get the keys for decrypting — so you send them the keys over the network. It's kind of like putting your valuables into a briefcase, locking the briefcase with a key, and then giving someone the briefcase and the key together. Did you accomplish anything?
Well, kind of. You have encrypted the content "at rest." So if someone gains access to your file system that stores the video segments, they won't be able to decrypt the videos without the keys. This strategy was much more common in the past, when not all devices were able to use HTTPS for both the keys and the chunk segments. Nowadays HTTPS is the default for everything, making this strategy much less practical. This gives you some protection, but not much.
Paint it black with DRM solutions
All the options up until now provide zero protection against software-level screen recording and little protection against downloading. The only way to protect your content from these attack vectors is to use a DRM solution like FairPlay, Widevine, or PlayReady. In broad strokes, here's how DRM works. Your encrypted video content gets downloaded by a client and the client makes extra requests to a licensing server to download the keys. The software on your device receives the keys and decrypts the content in a secure way that is built into the device's operating system — so the decryption keys aren't exposed directly to the client. The decryption can happen at multiple levels below the application: the operating system, the secure memory context in the OS, or the hardware itself. The OS enforces the security around screenshots, screen recording, and downloading. If you're playing a Netflix video on your laptop and try to screen-record it, you'll see black. If you're watching television content on YouTube TV on your phone and attempt a screen recording, then (you've guessed it) you'll see black.
Don't believe me? Try it yourself.
The video content itself is encrypted over the network, and the operating system is taking extra steps to obtain the keys from a licensing server, decrypt the video bitstream, and play it for you.
Trap bad actors with forensic watermarking
Elon Musk famously identified who at Tesla was leaking confidential information to the press. Normally when an email is sent to all employees, they receive the exact same text — but this time everyone got a slightly different email. Between different sentences there was either one or two spaces, creating a unique watermark on every email. When emails were leaked to the press, Tesla could quickly identify who shared them. This follows the same principle as forensic watermarking. Normally when you deliver a video to a large group of people, you send everyone the same video. With a forensic watermarking strategy, you ever-so-slightly alter the video for each individual person — in a way that is invisible or otherwise imperceptible. This doesn't prevent your video from being stolen, but it does allow you to identify who leaked it so you can ban their account or pursue legal action.
The downside of forensic watermarking is that it's much more expensive than other protections. You can't simply encode the video once and send the same video to every viewer. There are different approaches but you will need at least two encodes and logic on the delivery side to create a unique pattern of A- and B-encoded segments for each specific user.
That doesn't mean it's not valuable. For the most sensitive video content, forensic watermarking might be worth it. And as more people do more things with video online, we might see more use cases for forensic watermarking in the future.
Bottom line: How should you protect your video?
There's no catch-all for every use case. The right answer is "it depends." But this post should help you understand the tools that are available and tradeoffs for each approach.
The solutions you choose will depend on the type of content you're streaming and how motivated attackers are to steal it. Ultimately, you need to balance the different tradeoffs that come with adding layers of security. The more security you have, the higher the development and maintenance costs, the more playback errors you will see, and the more it will cost in dollars.
Mux's video security toolkit
The first option is no security, with Public Playback IDs. If you're building a brand new app, or you're just kicking the tires with Mux, start here. No need to add complexity until you know you'll need it.
See Mux's secure video playback guide for more information on the following options:
- Time-based signed URLs. This works the same as signed URLs on Amazon S3. Use a signing token server-side to generate a time-based signature.
- Signed URLs with referrer production. This uses a Playback Restriction with referrer settings.
- Signed URLs with user-agent protection. This uses a Playback Restriction with user_agent settings.
- Signed URLs with custom parameters. This will help you identify the culprit if a signed URL is leaked.
Want to talk to us about DRM? Reach out here about Mux's DRM offering.
