Ultimately someone could use a screen capture program or even a video camera pointed at your monitor if you wanted the video bad enough...No matter what level of encryption and authentication. All about making it as irritating as possible without causing end-users grief. IMO, they shouldn't even know it is protected unless they try to get at it.

Which is why the DRM stuff in iTunes and the like is irritating. If I buy a song on one machine, I should be able to take that song to any machine I want without being bugged. I mean, if I have a cd, I can take the media with me to unlimited machines, so long as it can't be played two places at once simultaneously.

Hmm, that has got me thinking....

What if proprietary video files had to be played in a proprietary player with some sort of header that says you need to get authentication from a web server before they could be played. Each file is given a unique id when it was "birthed". The web-side could communicate over an encrypted channel figuring out whether or not the video was currently playing somewhere else with the same id. Like a check-in/check-out for media assets. If this id isn't 'checked-out' somewhere else, then you can play it. If you have shared this copy with your friends, and they have checked it out, well, then you may not be able to play it when you want to. Perhaps you get a prompt - hey someone is already viewing this file, if you want it for yourself, go here.... Hmmm, the check-in/out process may be tricky too. How do you allow someone to check out a file? Can't use username/password (too easy to pass around), can't use machine info (too easy to break if someone changes their machine), if you check out by request alone, then you can make sure a whole bunch of instances of a file aren't being played at once, but that may not be an issue with most projects.

One weakness is that any time any sort of authentication is included in the file, it can be cracked. BUT if you have a server on the other end validating these codes, it makes the process a lot harder. Other weakness would be that whatever is playing these files would need to handshake with the server over an encrypted channel so it would be harder to spoof. The handshake would have to somehow vary so that you couldn't find patterns in the encrypted data and try to decypher it. 128-bit encryption over ssl can be slow, and has legality issues with it when going overseas I believe...

Anyway just a brainstorm... a lot of work though :0) Depending on the distribution, your servers could get hammered with requests as well...You'd better REALLY want to protect those movies to do something that in depth... Ultimate result is that there is no one method that works for everything. It depends on your end-users and how much flexibility they are willing to give up for security.

~Mathew


Colin Holgate wrote:
Also, I know there have been threads about this, but the conclusion is that
there really is no way of protecting video files (MPEG-1) from being
accessed outside of the protected program. Correct?


You can probably do some things to stop a novice from easily getting at the file (even a simple rename might do), but no protection on earth will stop me from easily getting a copy of video or audio if I want it.


[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]

Reply via email to