Securing Your Content
Since the Napster trials in late 1999, content producers have become increasingly aware of intellectual property issues. Even then, the Recording Industry Association of America (RIAA) tried to send the message that the Internet had made widespread piracy possible, and that it was leading to enormous losses in revenue for the music labels and artists.
In addition to direct losses from piracy, content producers today face an even greater challenge when it comes to controlling how their work is distributed. It's quite common for anyone who admires your video to simply repost it on their site. Generally, this isn't a big deal - it's flattering and it provides a mechanism for increasing the visibility of your work. Unfortunately, this redistribution can also lead to a poor perception of your work and it can also dramatically increase your web-hosting costs.
With that in mind, I'd like to introduce "The Golden Rule":
Anyone who can watch your video can steal your video.
It is very easy to become paranoid about protecting your content. We'll try to offer a few simple steps that you can take to defend against most unauthorized uses, however you will need to take into account the technology you have available, the time amount of time you can invest in setting everything up, and the amount of money you're willing to spend.
Security for Individuals
The most basic form of protection is obfuscation, which can be accomplished on the web with JavaScript. In order to watch your video, a viewer's computer must first know its location. As a result, the location is generally printed right in the source code of the page with the video. Using JavaScript, it's possible to do some complicated text replacements so that the actual address isn't immediately visible. As easy and useful as this seems, most web browsers offer an interface for inspecting web traffic, which will always display the non-obfuscated address, thus rendering this solution ineffective.
This is a prime example of client-side security, which means that the actual security measure is written into the software running on the user's computer. However, given the limitations of this type of security, most content protection relies on a completely different type of security: server-side security. Server-side security is much more reliable as regulates access at the source and only relies on hardware you control.
The most widely used form of server-side security is web authentication. If your web browser has ever popped up a dialog box and asked you for a username and password, then you've used web authentication. The best part is that most web common servers have this functionality built in, which makes it incredibly cheap and easy to implement. In fact, configuring web authentication can be as simple as creating a text file. But be careful - it's very easy to give users access to content they shouldn't be able to see and it can become time consuming to manage. In fact, web authentication is relatively insecure in practice as individuals often share their usernames and passwords. For this reason, it's not recommended in an organizational setting, but it's perfectly appropriate for sharing between a few trusted individuals.
Security for Small and Medium Sized Organizations
Just like web authentication is the de-facto security mechanism for individuals running their own web servers, temporary URLs are the de-facto security mechanism for organizations using a content delivery network (CDN). Sites using temporary URLs generate a new link to a video file every time a user loads the page. This link is only valid for a short period of time or a limited number of accesses. Once it has expired, individuals who want to view the content will have to request a new link. This makes it incredibly effective at protecting against leechers (people who copy-and-paste your embed code into their site), since the link that's copied will eventually expire. In fact, many video hosting services, such as Bits on the Run and Amazon Web Services' CloudFront readily promote this.
Temporary URLs become even more effective when uses in combination with encrypted streams. This prevents malicious individuals from intercepting web traffic on your network in order to reconstruct the video, since only the viewer at the end will have the credentials to decrypt the video. The most commonly used implementation is Adobe's Flash Media Server (FMS) with encrypted RTMP. While individuals have created software that allows viewers to extract the video from these streams, they are not widely used, in large part due to legal action by Adobe. Both Bits on the Run and Cloudfront offer encrypted RTMP streaming via FMS, and it works in combination with their temporary URL mechanisms.
Security for Large Organizations and Institutions
No discussion of content security would be complete without mentioning digital rights management, or DRM. While DRM is the most secure form of content protection, it's really only suitable for large organizations, owing to its cost and complexity. DRM solutions use special cryptographic algorithms when encoding to ensure that only individuals with the proper credentials are able to decrypt and view the content, and often only after being authenticated by a DRM server or for a specified period of time. Not surprisingly, vendors charge a pretty penny for the software ($40,000+ in licensing fees are not uncommon), and this says nothing about the cost of maintaining and running the necessary server hardware.
Additionally, DRM blocks many legitimate users, especially those using mobile devices. For example, Apple's DRM solution for audio, video, and eBooks, FairPlay, only works on Apple devices or computers running QuickTime. Microsoft's PlayReady DRM has been supported by their cross-platform Silverlight player since version 2, but only after they abandoned their PlaysForSure DRM solution, stranding many users with unplayable content. Finally, Adobe's Flash Access DRM has only recently become available to clients with the release of Flash 10.1, so it's ability to deliver secure content to clients is still limited.
Conclusion
Hopefully you are now aware of the need to protect your content, and feel equipped to make a decision about what type of protection best suits your needs. Clearly, the challenges associated with securing original content online have continued to increase as people have sought out ways to circumvent protective measures. And so while technical solutions to protect intellectual property continue to grow more complex, you should always remember one thing: that your videos are your property and you have a right to protect them.
Comments
How Longtail supposed to provide security for the content ? Longtail player shows the file's path in the source code in flashvars of JW player like file='filepath' anyone can use that then how can we as a longtail player can avoid this ?
Thanks
Submitted by Vivek Narula on Wed, 2010-08-18 05:23.
it would be good to see some implementation of at least xml/js obscure techniques like a3amazon uses somehow implemented in future builds of jwplayer. yes it's true that dedicated folks can rip content no matter what you do (w/screencapture software or looking inside xml files), but it would help a bit to have some way to obscure the flv location w/js/xml redirect code... what do you think, devs?
ken c
Submitted by ken c on Wed, 2010-08-18 07:54.
how do we overcome the process of simply taking a screencapture of your video using an app like Camtasia?
Submitted by eric on Wed, 2010-08-18 12:11.
We take a bunch of steps:
We don't hard code the path to the RTMP stream. We hard code a path to the XML playlist file on the server. That playlist file is generated dynamically, and looks at things like whether the user is logged in and has access to the film.
All of our URLs are RTMPE.
We use temporary URLs that are cryptographically signed. We had our own scheme originally, but most CDNs have their own scheme.
We use SWF verification where possible. With Wowza, we use secure token (although I think SWF verification is better).
We don't validate the domain that the HTML page is on since that was not relevant for our business. We encourage people to embed our player because we determine access restrictions when they try to fetch the playlist.
Submitted by Shannon -jj Behrens on Wed, 2010-08-18 16:47.
It would be nice for someone to tell us how to stop realplayer from downloading clips played on JW player.
I cant figure it out.
Submitted by Eddie on Wed, 2010-08-18 20:07.
@Ken C, Devs. will not reply same as their support and forums...., so have to find our own ways.
Submitted by vivek on Thu, 2010-08-19 02:45.
@Eddie
Blocking realplayer is easy with Apache:
SetEnvIfNoCase User-Agent "^RealPlayer" bad_client
<Directory "/your/streaming/files/*">
Order allow,deny
Allow from All
Deny from env=bad_client
</Directory>
An other solution is to set a cookie and check the request for it. JW Player send the cookie as long as you do not use JavaScript to draw the box. RealPlayer does not support it.
However this is only a sulution to block the RealPlayer. There are many other tools that can download the files!
Submitted by RITZE on Thu, 2010-08-19 05:05.
@RITZE
Any words on stopping anyone to use our video directly. Kind of hotlinking ?
Submitted by Vivek Narula on Thu, 2010-08-19 08:19.
@ Ken C, Vivek:
If you want to minimally hide the location of a video, you could simply point your player at a playlist (as Shannon suggested). This amounts to setting the playlistfile flashvar equal to the location of a valid playlist. For more information on creating and using playlists in the player, see our tutorial on creating playlists.
If you're looking to prevent leaching (aka hotlinking), we recommend using temporary URLs. If you use a service like Bits on the Run, this is handled completely transparently to you as a publisher. If you're tech-savvy, or have access to a developer, you should take a look at Amazon S3's authentication, which allows you to generate URLs that will expire after a specified period of time.
Submitted by Zach on Fri, 2010-08-20 15:40.
Hi
How to set temporary Urls of my video??
I cant see any tutorials here..
Submitted by Animalaya on Sat, 2011-03-05 06:09.
<p>We don't have a demo running live, but if you download <a href="http://developer.longtailvideo.com/trac/export/1643/testing/files/s3-generator.php">s3-generator.php</a> and upload it to your own server, it will generate signed urls for you.</p>
Submitted by Zach on Mon, 2011-03-14 07:35.
Hi,
I'm using Cloudfront and licensed JWplayer to stream videos. I'm able to create signed and dynamic links that expire after some time. In your post you mention that "This link is only valid for a short period of time or a limited number of accesses". Now I'm thinking about "expiring" the link after first access. Is it possible with Cloudfront.
Thanks.
Ankit
Submitted by Ankit on Thu, 2011-10-13 08:35.
I agree. Good explanation on the article. But lack of resource / articles or direction for developers who are using JWPlayer. A nice tutorial would have been appreciated!
Submitted by Jones on Fri, 2011-10-14 09:19.
3dBuzz.com has a player that overlays user information over the video, so whoever watches the video has their own information overlayed. This way if they choose to use Camtasia to record your videos, they will also have to blur our the area of the screen that has their information on it.
They only have this information for their commercial products, so to see it in action you would need an account.
It is a very good way to protect content however, because in the related industry, their content is the least pirated.
Submitted by Martin Krol on Tue, 2011-11-29 13:07.
With our player, you can overlay your own logo / watermark, which is similar to what you are talking about.
Submitted by Ethan LongTail on Tue, 2011-11-29 17:00.
Its very different, because nothing will stop someone from using camtasia to record what they see on their screen if the company logo is on it.
However, if someone uses camtasia to record their screen, and shares that video online, and their own user information is on there... ( like Name, email, and or even address ).they wont be as willing to share the material to others through pirate channels. Their only option would be to blur that area of the content.
Granted, this would have to be a feature that would have to link into Content management systems for it to work, because it would have to extract the user info first.
Again, having a company logo on the video does nothing. people will pirate anyway, because it doesnt affect them.
The point of doing things like masking URLs, expiring links, etc is to make it a bigger pain in the butt for the user to pirate content. in the end there will always be a way for users to pirate, but by making it inconvenient for the pirates, they might not want to go through the effort. And that is the point. :)
Submitted by Martin Krol on Tue, 2011-11-29 18:37.
Yeah, it is hard to stop Camtasia users. One idea would be to encode your own logo onto all of your videos, so if someone tries to download your video, the logo remains. Bits on the Run has this feature (in addition to security with rtmpE).
Submitted by Ethan LongTail on Tue, 2011-11-29 18:58.
The problem isnt about people stealing your videos and passing it off as their own. The problem is people stealing the videos in the first place, and putting it up for other users on bit torrent sites, or rapidshare, etc. Those users don't care about any kind of logo on the video, and the guys that stole it dont care about it either.
however if we could put the users info on the watermark, then those people would think twice about posting the content, because the content creators would know who stole it to begin with. That way the account who stole it could be terminated right away, and legal action could be taken.
the only other option that user has is to blur their own information out of the screen, but they run into the issue of blurring actual content on the video. If this is a learning video, people want to see the full interface and not a blurred result.
Submitted by martin krol on Wed, 2011-12-28 20:04.
Yeah.
Submitted by Ethan LongTail on Thu, 2011-12-29 14:50.
I cnt access red5 using rtmp ...i dnt know what is the problem
i have given like
'streamer': 'rtmp://192.168.0.6/oflaDemo'
I am using jwplayer for streaming
but its not working
Thanks in Advance
Submitted by Anju on Tue, 2012-03-06 03:21.
can you please give me ur email id..Mr Ethan
Submitted by Anju on Tue, 2012-03-06 03:23.
http://www.longtailvideo.com/support/contact-us
Submitted by Ethan LongTail on Tue, 2012-03-06 13:51.
Post new comment