streaming - 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 sort of protection. The files are streamed via PHP and are located in an upload folder on my server.

I've used PHP to ensure that only subscribers can view the video but I basically want to go a step further and prevent subscribers from, upon login, downloading my videos with downloaders such as Sothink Flv Downloader for Firefox.

Answer 1

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.