In reality, you can't. But you can make it harder to download.

---

Browsers make grabbing too easy

Because that's what browsers were designed to do: Serve content - which means give the content to the user. To show you how easy it is, here's how I usually grab videos on virtually any video streaming site:

Prepare the network tab of your preferred browser debugger and let the video load. Then look for it in the loaded resources. Videos are usually streamed in .flv or .mp4, and audio in .mp3. When you spot the url, open a new tab/window and open the link there. The browser will then download the file.

---

Making it harder

Here are methods on making a grabber's life harder. Like I said earlier, these are not fool-proof methods, but can at least ward off skiddies.

Video to Canvas technique

Recently I came across this article from HTML5Doctor while researching motion detection in JS. This involves streaming your video via a <video>, then with some JS, literally copy the video to a <canvas>. Here's an example where the video is up front, while the canvas at the back get's fed with data from that same video.

Essentially, what you do is:

• Predefine on the HTML or dynamically insert a <canvas> to the DOM. This is the "player" that the user sees.
• Dynamically create a video tag via JS, append it to the DOM hidden and give it a url to stream. This will be the video source for the canvas.
• Then with JS, you periodically grab data from the <video> you just created and draw it to the <canvas>. With this step, the video gets fed to the canvas.

That's the very basic of the entire routine. Since your player is now the canvas and the true video hidden, you can try right-clicking all you want and save. Since the canvas acts like an image on the page, you can only save a shot of a frame that was displayed on the canvas. As for controls, JS has an API for controlling <video> so you can create custom buttons and sliders.

However, if they know you are doing this, they will find your hidden video element, and you are screwed. This leads us to the next method that complements this front-end only technique, with aid from the server side.

Temporary resource urls

One thing you can do to prevent this method is to prevent the link from being reusable. Make the link disposable, temporary, one-time use only. Once the player loads using the disposable url, dispose of it. Make it unusable.

Similar to CSRF prevention, when a browser requests a page with your video, have it generate a random token and store it in some storage on the server side for later reference. At the same time, append it to the url of your video, something like this:

//we load some video with id 1234324 from your site using this url
//and the token generated on page load is appended as sid

http://yoursite.com/media.php?video_id=1234324&sid=a0s9d8a98a0d98asd09809wq0e9

Now when your player loads the video, it will use this url that carries the token. Have the server validate the token.

If it's good, stream the video and destroy the token from the server to avoid reuse. This essentially makes the url "one time use only". If an invalid token is used, return the appropriate headers as the response, like a 403 perhaps.

To add a bit more security, impose an expiry of the url by storing it's timestamp along with the token. Then compare the request timestamp with the stored timestamp if it's still within the "use window". Make this "use window" short enough to be used by the player on the page, but not long enough for a skiddie to grab that url and paste it into another tab/window/downloader.