Protect flash video from download/right protect

Question

Is it possible to protect flv files from download? I\'d like to protect my files from download but I don\'t have the money for a streaming server which I think provides some

Answer 1

sites like youtube try to make it difficult to download their videos by obfuscating the flash and also changing the structure every so often. As others have said it is an arms race. Youtube updates their structure and then tools like pytube have to also update.

Answer 2

Have a look to this analysis from Longtail.

It starts with a golden rule:

Anyone who can watch your video can steal your video.

And it ends up with a really nice series of security concerns and prevention techniques.

Answer 3

Make a seperate site for your content. Configure web server app settings for 2nd site ("content server") to intercept requests for any static content (your videos, pictures, whatever) so you can do a check for a permissions cookie for each requested piece of content to check if theyve been validated and granted access to that piece of content or not.

Answer 4

You can't. Any effort or money that you spend chasing DRM will be a waste of resources that you could have put into improving your product. Put your logo and URL into the videos, so that anyone copying them is advertising your site, put a copyright notice into the videos and sue anyone who you catch copying your content illegally, and call it a day.

Answer 5

Have you thought about hosting your video on Amazon S3? you can set urls for your videos to expire so that the link to the video will only be valid for certain period of time. This doesn't prevent anyone from getting the video from their cache once it has downloaded nor does it prevent other ways such as using Orbit downloader, or RealPlayer video downloader but it would prevent hotlinking.

I agree with comments that this is an arms race and a strategy for video delivery that accepts that people do want to download videos to share or copy to other devices etc and tries to live with it will probably be the most successful and pain free. Watermark, embed links to your site, try to capitalise on the increase in the number of eyeballs watching your video as a result of being downloadable.

Answer 6

I fully agree with the DRM consensus of other answers. But would like to add...

There are a couple of obfuscation techniques that may meet you needs. "Good enough", as they say. These aren't full proof mechanisms, but very well may prevent 80%-99% of people trying to copy your FLV streams/files. A dedicated hacker will get to it, but most folks are just script kiddies (or their FireFox plug-in loving cousins.) Plus, some of these techniques are really easy:

• Change/remove the MIME type the server is responding with. Flash players blissfully ignore it anyway. E.g.: image/jpeg
• Change the file extension from .flv to something else, like .jpg. Again, Flash players blissfully ignore it anyway. Additionally, once the file is saved to disk, a non-FLV player will open it (and complain about it being an invalid file format.)
• Set aggressive 'don't cache' headers for all your FLV content. (This, naturally, means more traffic and bandwidth consumed. Maybe this is not an issue for you?)
• Stream over UDP-based protocols (like RTSP). While my read is that UDP protocols are on the way out for large scale streaming of on demand content, it is much more difficult to copy. E.g.: Real Downloader cannot currently pilfer these streams.
• Break up content into two or more pieces of partial content, and play them back to back.
• Hide your FLV content behind a simple, custom one-time authentication mechanism
  • Player requests authorization key for content A
  • Server returns an authorization1 key: SHA1(content key + salt1)
  • Server stores content key, authorization1 key, authorization2 key (which is SHA1(authorization1 + salt2))
    • one time use
    • limited validity (E.g.: 2 seconds)
  • Player creates authorization2
  • Player requests content a with authorization2
  • Server sends ´FLV´ content to client if and only if
    • authorization key matches to content key in server side store
    • authorization key has not expired

I've actually implemented that last idea, the authorization mechanism, myself and can vouch for it's practical effectiveness. No, it is not totally secure. But it is good enough. Not even a power users is capable of beating it.

Defeating it requires

1. reverse engineering the process,
2. decompiling your Flash player,
3. putting it all back together again.

Good enough.

---

It is amazing how many "plz sends me teh codez" emails this post has generated from the "simple, custom one-time authentication mechanism" suggestion. Don't bother, I can't--it was for a proprietary project for my employer, xtendx AG. If interested in purchasing the system, email sales@xtendx.com.