Call it an educational series section if you want but this is my take on how to prevent piracy and is a little bit technical.
It stems from the base that the vast majority of people being pirated from offer their product in digital format *only* and so the easiest way to prevent your product from spreading as pirated is to prevent your product from getting on the hard drives of the future pirate/seeder.
Technology in this matter has moved enormously in the last few years and I'd say everyone offers streaming as an option in their members area.
If you offer downloads of your movies and don't want to enter into DRMing them, then you will not prevent piracy.
The best solution is to offer your movies *only* as protected streams. I'll get to other problems associated with only offering your movies as streams (ie members want access to the movie always even after membership expiry) at the end.
If you take the stance that your members are signing up to see what they want to see and not to seed it to the masses then this solution will work for you.
If you don't care that your content is pirated and only wish to see a new revenue stream open up by "fighting" the pirates, I don't see why you're in this thread anyway, so stop reading now.
1. Turn off mpg/avi/wmv whatever downloading
Why do you even offer this? It makes storing your content much more costly, your bandwidth increases, and is the sure fire way to get your content pirated.
if you must give downloads, inject the user details into the mpg file - see
http://gfy.com/showpost.php?p=17565717&postcount=76
2. Only stream your content
All your content needs only to be flv or (better) mp4 (h.264 format) - cut your storage needs by > 50% in one fail swoop
3. Protect your streams
This is the technical stuff - stream rippers are two a penny these days, but follow this sequence of events and your streams are 100% secure. The only way to "rip" your stream is to have a screen capture program record full playback of your move. Impossible to prevent that!
a) Stream - don't use progressive downloading
Progressive downloading is where you put a flash player wrapper around your content - the user can only view the content currently downloaded. That means the entire movie can only be viewed once the entire movie has been downloaded. Thus, the movie downloads into the browser cache and can then be transcoded by the end user to any other format and pirated.
You also consume a lot more bandwidth
Stream your content with a streaming application such as the flavours that Adobe and Wowza offer up - this way, if a user watches only 30 seconds of a movie, you pay only for 30 seconds of bandwidth, not what the users internet connection allowed him to download in 30 seconds (which could be the entire movie!). It also allows for scrubbing by clicking ahead/behind in the movies current position.
b) Stream your movies with RTMPE
Adobe launched the encrypted RTMP (RTMPE) streaming protocol a few years back and by using it, you block 90% of stream rippers. Only three that I know of can still rip RTMPE streams, and Adobe is actively pursuing trying to shut down those apps (no chance!).
In any case, at a 1.5% overhead on the server per stream, RTMPE is worth it to kill the majority of stream rippers
c) Protect your streams with a Secure Token
OK, you have a secure stream. This means streams in process by one app cannot be ripped by another. This however leaves a hole in the handshake between client and server - if the client is an app that can convince the server to engage in an encrypted stream, the server will diss it out.
A Secure Token is one only known to your app (eg your flash player) and your streaming server. On request for a stream, the client (your player) will send a SSL-protected Secure Token in the header of the request. If this matches the token stored on your streaming server, the server will release the stream. Only this token is known to your flash player (that is compiled into the player) and your streaming server (in the server config). Impossible for a rogue client (like a stream ripper) to know this.
However, one ripper app can listen to what is being sent during a request and circumvent this (see later)
Secure Token is supported by Adobe and Wowza and most players (JW PLayer included) support secure token.
d) Protect your "Secure Tokenised" flash player
A person can download your flash player which contains your secure token inside the compiled app and either
i) use the player to request streams on their own behalf, fooling your streaming server
ii) reverse engineer the app to find the secure token
A simple way to do this (which is not foolproof, but since it's transparent to the end user it's a good security) is to mod_rewrite all requests for your player that do not have a trusted http_referer set (direct requests do not have http_referer set)
the [L] is quite important since the redirect will be transparent - it will look like they are getting the same player as is shown in the HTML, but it will be untokenised and always fail on any request to serve up a movie
f) Protect your streaming server from unauthorised requests
For the only available stream ripper (which requires a LOT of knowledge of the command line to operate by the way, so eliminates a lot of pirates), that can see your encrypted secure token in the stream request header and use it to make unauthorised requests for streams, make sure your streaming server *ONLY* listens for requests coming from a valid host - a valid referrer. There is *NO* stream ripper available that can trap the secure token and spoof referrer for the moment.
Adobe and Wowza offer this as a plugin (free for wowza, paid for adobe)
g) Add encrypted user login vars to your stream
This is paranoid, but some circumstances like VoD where the username is important to the streamer, it is important. Don't give out unsecured user vars - encrypt them with a method encryption compatible with your web server (encryption) and streaming server (decryption). I won't go into the details on how to implement this, as it can be avoided if your member area is well protected from intrusive entries. I've done it though for unprotected areas where a logged in member is sent one content and a none-logged in member is sent another... the options are there in any case
This requires a custom compiled streaming server plugin.
Following all the points above in Point 3 will protect your streams in today's market to the hilt.
4. How to deal with members that want the content all the time
OK, in point 1 you shut off all movie downloading, in 2 only offered movies in streaming format, and in 3 you prevented your streams being ripped
For the majority of members, albeit taken from stream/download stats over a 2 month period with 2 clients, streams are what people want - content is fresh, no download wait time to get cock in hand etc I suppose, but the movie requests were mainly for streams.
However, there are a still a lot of members that like to have the movie on their HD so they can watch it forever, even if they cancel membership.
One client didn't want to offer only streams for this reason. The members of this client that were logged as downloading movies were polled via survey monkey to ask them
a - if we didn't offer movie downloads would you consider cancelling your membership (95% said they would consider cancelling)
b - if we didn't permit downloads, but made sure the movies you like were always available, in full, for 1 year even after you cancelled your membership at some point in the future, would you consider cancelling your membership (15% said they would consider cancelling)
That was enough of an answer for the client since within those 15% were the pirates. Maybe all of them were pirates, maybe only 1% but a good enough chance to take the risk.
I implemented a method where, during the lifetime of a member, any movies added to their favourites or watched in their entirety were logged. If the member cancelled, their login would still be valid for 1 year whereupon relogin they would have full streaming access to those movies. Any new movies or old ones they never watched would be removed from full access rights and clicks on them would be used for upsells to get them back.
By implementing this, they lost 3% of their recurring (downloading) member base (remember only those ones that were downloading the movies - not the entire member base), but over the next 6 months got a ~70% upsell success rate turning that expired member back into a full member.
In all, the implementation of all the above means that all your movies are free from pirating and by-and-large your members won't care that there are no downloads since they still have access to the content they liked. Better still, it gives a chance for active upsells to win back lost members.
It stems from the base that the vast majority of people being pirated from offer their product in digital format *only* and so the easiest way to prevent your product from spreading as pirated is to prevent your product from getting on the hard drives of the future pirate/seeder.
Technology in this matter has moved enormously in the last few years and I'd say everyone offers streaming as an option in their members area.
If you offer downloads of your movies and don't want to enter into DRMing them, then you will not prevent piracy.
The best solution is to offer your movies *only* as protected streams. I'll get to other problems associated with only offering your movies as streams (ie members want access to the movie always even after membership expiry) at the end.
If you take the stance that your members are signing up to see what they want to see and not to seed it to the masses then this solution will work for you.
If you don't care that your content is pirated and only wish to see a new revenue stream open up by "fighting" the pirates, I don't see why you're in this thread anyway, so stop reading now.
1. Turn off mpg/avi/wmv whatever downloading
Why do you even offer this? It makes storing your content much more costly, your bandwidth increases, and is the sure fire way to get your content pirated.
if you must give downloads, inject the user details into the mpg file - see
http://gfy.com/showpost.php?p=17565717&postcount=76
2. Only stream your content
All your content needs only to be flv or (better) mp4 (h.264 format) - cut your storage needs by > 50% in one fail swoop
3. Protect your streams
This is the technical stuff - stream rippers are two a penny these days, but follow this sequence of events and your streams are 100% secure. The only way to "rip" your stream is to have a screen capture program record full playback of your move. Impossible to prevent that!
a) Stream - don't use progressive downloading
Progressive downloading is where you put a flash player wrapper around your content - the user can only view the content currently downloaded. That means the entire movie can only be viewed once the entire movie has been downloaded. Thus, the movie downloads into the browser cache and can then be transcoded by the end user to any other format and pirated.
You also consume a lot more bandwidth
Stream your content with a streaming application such as the flavours that Adobe and Wowza offer up - this way, if a user watches only 30 seconds of a movie, you pay only for 30 seconds of bandwidth, not what the users internet connection allowed him to download in 30 seconds (which could be the entire movie!). It also allows for scrubbing by clicking ahead/behind in the movies current position.
b) Stream your movies with RTMPE
Adobe launched the encrypted RTMP (RTMPE) streaming protocol a few years back and by using it, you block 90% of stream rippers. Only three that I know of can still rip RTMPE streams, and Adobe is actively pursuing trying to shut down those apps (no chance!).
In any case, at a 1.5% overhead on the server per stream, RTMPE is worth it to kill the majority of stream rippers
c) Protect your streams with a Secure Token
OK, you have a secure stream. This means streams in process by one app cannot be ripped by another. This however leaves a hole in the handshake between client and server - if the client is an app that can convince the server to engage in an encrypted stream, the server will diss it out.
A Secure Token is one only known to your app (eg your flash player) and your streaming server. On request for a stream, the client (your player) will send a SSL-protected Secure Token in the header of the request. If this matches the token stored on your streaming server, the server will release the stream. Only this token is known to your flash player (that is compiled into the player) and your streaming server (in the server config). Impossible for a rogue client (like a stream ripper) to know this.
However, one ripper app can listen to what is being sent during a request and circumvent this (see later)
Secure Token is supported by Adobe and Wowza and most players (JW PLayer included) support secure token.
d) Protect your "Secure Tokenised" flash player
A person can download your flash player which contains your secure token inside the compiled app and either
i) use the player to request streams on their own behalf, fooling your streaming server
ii) reverse engineer the app to find the secure token
A simple way to do this (which is not foolproof, but since it's transparent to the end user it's a good security) is to mod_rewrite all requests for your player that do not have a trusted http_referer set (direct requests do not have http_referer set)
Code:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_REFERER} !^http://members\.domain1\.com/ [NC] #main webserver
RewriteCond %{HTTP_REFERER} !^http://members\.domain2\.com/ [NC] #some other trusted server
#we are trying to download the SecureToken player...
##send them a custom player that doesn't provide the SecureToken!
RewriteRule ^FlashPlayer\.swf$ /media/players/FlashPlayer.swf [L]
f) Protect your streaming server from unauthorised requests
For the only available stream ripper (which requires a LOT of knowledge of the command line to operate by the way, so eliminates a lot of pirates), that can see your encrypted secure token in the stream request header and use it to make unauthorised requests for streams, make sure your streaming server *ONLY* listens for requests coming from a valid host - a valid referrer. There is *NO* stream ripper available that can trap the secure token and spoof referrer for the moment.
Adobe and Wowza offer this as a plugin (free for wowza, paid for adobe)
g) Add encrypted user login vars to your stream
This is paranoid, but some circumstances like VoD where the username is important to the streamer, it is important. Don't give out unsecured user vars - encrypt them with a method encryption compatible with your web server (encryption) and streaming server (decryption). I won't go into the details on how to implement this, as it can be avoided if your member area is well protected from intrusive entries. I've done it though for unprotected areas where a logged in member is sent one content and a none-logged in member is sent another... the options are there in any case
This requires a custom compiled streaming server plugin.
Following all the points above in Point 3 will protect your streams in today's market to the hilt.
4. How to deal with members that want the content all the time
OK, in point 1 you shut off all movie downloading, in 2 only offered movies in streaming format, and in 3 you prevented your streams being ripped
For the majority of members, albeit taken from stream/download stats over a 2 month period with 2 clients, streams are what people want - content is fresh, no download wait time to get cock in hand etc I suppose, but the movie requests were mainly for streams.
However, there are a still a lot of members that like to have the movie on their HD so they can watch it forever, even if they cancel membership.
One client didn't want to offer only streams for this reason. The members of this client that were logged as downloading movies were polled via survey monkey to ask them
a - if we didn't offer movie downloads would you consider cancelling your membership (95% said they would consider cancelling)
b - if we didn't permit downloads, but made sure the movies you like were always available, in full, for 1 year even after you cancelled your membership at some point in the future, would you consider cancelling your membership (15% said they would consider cancelling)
That was enough of an answer for the client since within those 15% were the pirates. Maybe all of them were pirates, maybe only 1% but a good enough chance to take the risk.
I implemented a method where, during the lifetime of a member, any movies added to their favourites or watched in their entirety were logged. If the member cancelled, their login would still be valid for 1 year whereupon relogin they would have full streaming access to those movies. Any new movies or old ones they never watched would be removed from full access rights and clicks on them would be used for upsells to get them back.
By implementing this, they lost 3% of their recurring (downloading) member base (remember only those ones that were downloading the movies - not the entire member base), but over the next 6 months got a ~70% upsell success rate turning that expired member back into a full member.
In all, the implementation of all the above means that all your movies are free from pirating and by-and-large your members won't care that there are no downloads since they still have access to the content they liked. Better still, it gives a chance for active upsells to win back lost members.
Comment