Sorry if the question is confused, as I'm confused myself. I'm working around these requirements:
I'm building a public website where I need to display video.
I need to control what the player looks like
I'm the sole publisher of the video, meaning it can't be on YouTube for example
I need as much protection as possible in terms of protecting the content from being downloaded
So, I've read around StackOverflow and the web, and found lots of suggestions, like numerous flash players, Streaming servers, DRM protocols, services like Panda etc etc.
The problem is I don't understand how everything fits together.
For example, what makes my video content secure?
Is it the player on the client? is it the server that hosts the content? is it the streaming process? who hosts the streaming servers and what difference does this make?
Bearing in mind this is otherwise a very simple site, and is not a business venture.
if you were working around my requirements, what would you do? Could you explain step by step at a high level?
EDIT:
Just based on a couple of answers, I'm not saying no one can ever download my content. And I realize this kind of thing is expensive.
I'm just asking, if you had my requirements, what would you do? And could you explain it to me so i understand?
thanks again
Edit:
Thanks again for all the feedback, I can't vote anyone up as I'm a new user, but your answers have been very helpful.
The one thing I will say, is that my only request was to attempt security, that is 'make it difficult' for most users...that is common in software security.
Some of the suggestions have been just to not even try.
My question was really based around the fact that I know nothing about video deployment on the web, apart form the basic embedded swf flv combo.
Anyway, your info has been very useful though. I'll try a simple "real" streaming service (as opposed to HTTP streaming).
Any other recommendations would be awesome
cheers
"For example, what makes my video content secure? " Nothing.
"Is it the player on the client?" Neither. Anyone can write a client and retain the video content. Remember this. Anyone can write a client. This client can absorb and save your video. Nothing can stop this. Nothing.
"is it the server that hosts the content?" No. Server is only one piece of security. You have to secure the protocol. And the client. And anyone can write a client and retain the video content.
"is it the streaming process?" No. Protocol is only one piece of security. You have to secure the server, the protocol and the client. And anyone can write a client and retain the video content.
"who hosts the streaming servers and what difference does this make?" You host the streaming video servers. Otherwise, you might as well use YouTube.
Edit
"The problem is I don't understand how everything fits together."
"For example, what makes my video content secure?"
These are unrelated. You keep mentioning security, AND not knowing how "everything" fits together.
Here's a suggestion: stop mentioning security -- edit your question to eliminate all references to security and see if you get more useful answers.
Many companies sell streaming media servers. You put HTML in your page that references the streaming media site.
Example. Apple sells Quicktime media server. Read http://developer.apple.com/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML_Document/chapter_1000_section_1.html for lots of information on how to present video from quicktime.
Before you go too far worrying about setting up these secure streaming protocol client server whatevers, make sure you weigh up the cost of your time getting this going, versus the cost of someone downloading your video.
Just to be clear: if your server is sending to a client, then they can copy (download) it. There's no way around it.
Response to your comment:
What I'd probably try doing if you wanted to try to avoid users downloading the files is this (I'll assume you're using FLV files, since they're the de facto standard on the web these days):
Put the FLV files in a non web-accessible directory.
Have a player.swf file request the file via a script on your site, eg: video.php?file=myVideo.flv
The video.php can then perform whatever security checks you'd like: for example, require logins, check the referrer, etc.
If the security checks are ok, then pass through the appropriate video file. If not, then perhaps have a short back-up video which is an ad for your site or something, saying "to watch this video, please come to mysite.com!"
Mostly video streaming sites like Hulu achieve a kind of poor-man's security by using RTMP to transfer the video data. You would need special server software to serve video via RTMP, for example Adobe Flash Media Server or WebORB.
RTMP is a proprietary protocol, so this is a case of security through obscurity; it's non-trivial to download a copy of the video (you can't just grab the file from a URL), but there are programs out there that are capable intercepting the stream and keeping a copy.
2.I need to control what the player looks like
Download and customise a free player like OSFLV.
4.I need as much protection as possible in terms of protecting the content from being downloaded
Forget it.
DRM for FLV exists, but you'll have to pay Adobe a load of money for Flash Media Server and Flash Media Rights Management Server, you'll lose client compatibility and ease of deployment, and in the end it's still breakable. Big old waste of time.
Accept that some people will download your videos, and put a big watermark on them so at least when they do you're getting free advertising.
Related
DISCLAIMER :) :)
Some of them may think it's not relevant for discussion as it does not
fit here. Why not? As I think in StackOverflow we find smartest people
around the globe. Even if I try to create in other StackOverflow
domains it won't be that visible.
NOTE: So if your the kind of guy who is trying to pull this down. Please
have some pity on me as I won't get good answers in other Q&A sites
like Quora
I would like to understand how companies like UDEMY protects the videos that are not allowed to download. I know they cant just fully protect but can harden it via various methods. Some of them what I found is as follows:
In Udemy I saw with point 3. Sounds interesting.
Starting from basic one
1. Disable right-click to download (Can be hacked by disabling the browser js).
2. You can use custom video libraries or no download options but god knows how fairly it plays. As I was able to download that kind of video.
3. Using BLOB URL for the video, this downloads the video in bytes. (Kind of secure using but can use HLS video downloader)
4. Can use On-demand live HTTP video streaming from Amazon or Vimeo but over time they may cost much price.
5. Then I read about large giants like Netflix, Amazon Prime uses multiple streaming files which will be stored in different chucks. Which makes it harder to download.
Any other ways you guys might have found an interesting way to harden it would love to hear.
AT THE END OF THE DAY USER CAN STILL SCREEN RECORD YOUR VIDEOS DAMMMMMM IT!
Streaming IS downloading. If you want someone to be able to watch a video, you MUST let them download it.
The way large sites protect the content is not through downloading, but by encrypting the files BEFORE they are downloaded. Then the player knows how it request the decryption key from a DRM server.
For more information, read about DRM and EME on Wikipedia.
I have some audio and video files which will be served from server to browser on request. Now I need a way by which "Users can watch or listen to media but shouldn't be able to download in anyway (even with developer tools or download manager plugins)". Kindly share your ideas if you have had experience on this.
If you are streaming it to them you can't stop them downloading it as, in extreme cases, they can simply capture the network traffic.
It sounds like you may want to encrypt the content using one of the commonly used encryption techniques and then find a secure way to share the encryption key with your users and their devices/players. This way any captured or downloaded content will not be of use to anyone without the right key.
This is essentially what DRM technologies do so it would probably be worth you investigating them - you can integrate the functionality to your own sever or simply host your videos with a provider who provides the functionality and embed their video player on your site.
what is the best way to make podcasts available on a website, in a more interactive way possible.
I have to use Wowza? how does it work? how to create a stream to the user's liking of several hundred files already recorded, these podcasts are episodes of a radio show ...
is there a way to 'tag' and listen to the audio at will?
I can not be more specific in my question, sorry.
Wowza allows on-demand streaming and live streaming.
+ you can use server-side playlists, i mean you can create live feed from already recorded files, so that will behave like TV.
IMO Wowza should be ok for your project, however some consultant/developer will be needed.
Wowza should work well for what you are trying to do. I would contact their team to have them help tell you specifically what you will need.
I'm trying to play an FLV file located on a remote server ('crossdomain.xml' does not exists in the process) in 3 ways:
From a browser using an SWF player located on some server
From VLC, pointing to the remote file.
Downloading the remote file and swf player - playing it locally
Guess what?
Didn't play the flv
Played like a charm
Played like a charm
Conclusion: Flash's Cross Domain security is useless.
Please tell me where I'm wrong or perhaps I'm just helping someone understand that this security is useless.
I wasn't going to write my own answer, because I felt like #jpea had already written the most important things. But it seems like the idea and use of the crossdomain.xml files is still unclear. So here it is:
Cross-site scripting does not refer to accessing media content from other servers, but to an attack method used for roughly 80% of all internet security violations. It can happen in many different ways, but always involves injecting foreign code into a web page (or plug-in content) to make the client behave in a way that was not intended. It might result in an attack on the server later, but the initial problem is always related to vulnerabilities on the client side.
Crossdomain-policy files are the Flash implementation of the so-called "same-origin-policy", an important part in preventing cross-site scripting. Essentially, it is meant to ensure that any content loaded by an SWF must be within the same domain (as opposed to "on the same server") as the original content.
What does this mean, in practice? It means, for example, that an attacker is not allowed to load your original SWF into an (invisible) enclosing SWF hosted on a different server, and monitor all incoming and outgoing traffic, or capture keyboard events, to steal passwords and such: Violating the crossdomain-policy will cause a security error that stops execution of all ActionScript.
It does not, however prevent FLV files from being played in some other way - and that is absolutely not what it is intended to do.
Admittedly, there are (more or less easy) ways to get around crossdomain-policy files, for example by using a proxy to channel the SWFs URL requests, so using them will not result in "real" security. But as part of a multi-level security strategy, they do help to raise the bar for attackers.
crossdomain.xml is meant as a security measure for the Flash player plugin. An FLV alone isn't the security risk, the player is. In instance #2, you didn't use the Flash player. Instance #3, it's uses the same security that Flash uses in it's IDE (to allow debugging). Instance #1 worked exactly as intended.
crossdomain.xml isn't meant as a DRM sort of security, or to not allow downloading of files. It's meant to disallow unintended domains from using your FLV/F4V from another server (better known as cross site scripting).
I want to view dynamic contents (flash games, online transaction...etc) offline.
For example, I finish level 1 of this cool flash RPG game.
I go offline and play the level again.
Or, I make a purchase.
And make the purchase again offline.
Of course this won't do anything. It will be strictly for demonstration purpose.
Or, I watch a video online. Go offline and watch it again.
Is this feasible? Whatever I do through browser, it has to download things.
When it downloads, it stores on disk. Then, when it is in offline mode, it routes all traffic out to local disk.
Sounds simple, but is this really possible?
Or am I missing something?
Let's say someone patched a browser to make offline mode much more powerful.
As a web developer, how can I secure my application from this
patched browser?
Let's say I charging my contents (video, game...etc)
per view/use. With this patched browser, people can pay once
and view/use it over and over again.
They might even make a tarball out of their browser cache
and share with other people online.
So, my questions are:
is this patched browser possible?
if it is possible, how can I defend my content against it?
I'm trying to find the original author of the quote: "Trying to make digital content not copyable is like trying to make water not wet."
In your question you describe several different scenarios as if they were similar. They are not. If you have a specific question, then please ask it so that people can focus on addressing the specific case that concerns you.
Let's talk about video (and audio). Essentially, without controlling the client, you can NOT stop the downloaded video from being cached and re-watched. "Patched" browsers exist. In fact, they're not patched. They don't even need to be. FireFox has any number of plug-ins such as "DownloadHelper" which make all of this possible. YouTube goes to some effort to change their system regularly to break DownloadHelper. But they know they can only slow things down.
The only way to control a video download being re-watched is insist on the user using your completely custom plugin or application. The problem is that (a) that costs you much more money, (b) it's more painful for the user.
The other cases you mention - RPG and online transaction... these are different. Often with an RPG or other game, the client portion includes only a part of the code. Some of the code resides on your server. Without a connection to the server, the game cannot be played. You don't have to write it that way, you could make it 100% client... in which case (e.g. for Flash) the SWF file can be downloaded and played again and again, without your control.
But usually those online flash games are part-server in order to do what you say, and make them playable only online and only via the game-writers site.
An online transaction ALWAYS involves a server component, usually encrypted and non-repeatable. They can be secured.