zwetan wrote:
> On 12/13/06, Alex Thurlow <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure if this is the right place to ask, but I thought some
>> people here might have some knowledge on the subject and could at least
>> tell me if it was possible.
>>
>>
> ...
>
>> Basically, the idea I had was to use some sort of stream cipher on
>> the video. I could pre-encode them, and then serve them to the player.
>> Would it be possible, in flash, to have the player run that cipher back
>> over the video before playing? That way, without a lot of work, the
>> videos wouldn't play outside my player. It wouldn't necessarily need to
>> be real encryption either. If some sort of bit-shift or bit-mask would
>> be possible, that would work too.
>>
>> I know it's sort of a dumb problem, but with the legal landscape the way
>> it is these days, I need to try to solve this.
>>
>>
>
>
> real video stream can not be saved on the user side
>
> flv as progressive download can
>
> using FMS or equivalent to serve real streamed flash video
> will not allow your user to download it per se
>
> after, someone can record the feed as any other streaming technology
>
> anyway, just don't confound progressive download and streaming
> not the same thing at all
>
> cf this
> "Delivering Flash Video: Understanding the Difference Between
> Progressive Download and Streaming Video"
> http://www.adobe.com/devnet/flash/articles/flv_download.html
>
> cheers,
> zwetan
>
I thought I'd update everyone who may be in this same situation on what
I've come up with based on my options. I figure someone else out there
is having the same debate. My conclusion, and basically a given of the
situation, is that if you're delivering data to someone, they can save
it. With programs like WMRecorder (http://wmrecorder.com/), nothing is
safe, all you can do is make it inconvenient. Here's what I came up
with for progressive http download:
1. My flash player makes a hash with the playlist requested and a secret
key contained in the swf. This hash is also generated by the code that
delivers the playlist, and it makes sure they match.
2. The playlist contains one-time urls for all of the content.
3. The webserver delivers "no-cache, no-store" headers when serving the
file.
With all of this, the user still has a few options for getting the file.
1. Use a browser that ignores the no-store header.
2. Capture the playlist and download the file before the player grabs it.
3. Decompile the flash player and pull the secret key and hashing
function to then pull a new playlist.
I believe this discourages people from saving the videos almost as well
as a streaming server does. The main advantage to this system, is that
it prevents people deep-linking our videos. Every once in a while, one
of the many video-code sites decides to give people our windows media
streams. There is absolutely nothing in windows media server to prevent
this, besides us switching the mount points now and then. As far as I
can tell, FMS wouldn't stop this either. That's a much bigger problem
to us than content download.
In the end, when red5 is ready, I think we'll make that do what we need
it to do, but until then, $18,000 on FMS is not a purchase in my future.
-Alex
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
