I recently bought Amazon Prime and wanted to download a movie.
After downloading a media file it is all black.
It looks like it's encrypted with some key, which the browser has.
My question is: Can i just compile the browser myself
after adding some code to save the video element decrypted buffer to a file?
Most commercial video streaming services will use DRM to protect the content. The DRM systems control the sharing of a license between the server and the client device and player which includes the decryption key and also rules around how it can be used.
To view movies offline the solution will usually use persistent licenses - these have an expiry which is, for example, up to a month and are stored securely by the DRM systems the device to allow them be used offline.
Typically, the video streaming services will only offer a subset of their catalogue for offline viewing - I am guessing that may be the case for the content you want to view.
You can't access the decryption key directly yourself, unless the DRM system is broken.
Related
Apparently I used the totally wrong keywords while googling because Im looking for solutions on how to embed videos in my webpage and still make "impossible" (i.e. make it hard) to download these directly as a mp4 file. I mean there are various players where you'll quite easily find out the original file on the webserver directly within the browser...
And on the opposite there are pages like youtube where you cannot really find out the full file but you'd have to use third party solutions to download the files.
Do you know any libraries / modules which support embedding in such a way like youtube?
Thanks
It really is not that hard to download/capture the file if you are making it available to stream to a device, even for YouTube videos, so you have to consider what your goals are.
Most content protection systems, or Digital Rights Management systems, don't really attempt to stop someone capturing the file. Rather they try to ensure that the captured file is of no use by having it encrypted so it cannot play back.
The tricky part then moves to securely sharing the decryption key with authorised users in a way that neither they nor a third party can view or share the key. This is the essence of nearly all common DRM systems.
If you do want to use DRM but don't want to pay for a full DRM solution then you could use clear key encryption with MPEG-DASH streaming. This essentially transmits the key with the stream so it not very secure, but it may meet your needs. There is some info on using it with a cloud encoding service here:
https://bitmovin.com/tutorials/mpeg-cenc-clearkey-drm-encryption/
I am newbie in using Streaming Server. we are evaluating EvoStream Media Server to stream HLS stream with AES128 encryption.
I have few queries on AES 128. I have search through google but no luck
When doing HLS with VOD(Video on Demand) , Evostream creates chunks of segments along with m3u8 index file that contains all information including key and IV vectors.
#EXT-X-KEY:METHOD=AES-128,URI="2015-06-25T11-20-18.key",IV=0x0360f11b211ef025d7f72c41d58e0a2d
My question if when i play this file in html5 media player and debug it using F12, i can easily get the key and IV used to encrypt the file. Then what is kind of security AES provide if anyone can get those key and IV vector to decrypt the data.
Please any one have some knowledge over it, please share ...
The key seems to be in yet another file:
URI="2015-06-25T11-20-18.key"
2015-06-25T11-20-18.key is only a reference to the key, not the key itself.
So you need to control access to the file and only make it available to persons that are allowed to play the video.
The answer to your question is that HLS with AES-128 provides transport security making it difficult for someone to capture your content in a man-in-the-middle scenario. It doesn't provide DRM.
You are supposed to change the keys every 3-4 hours and the IV every 50 Mb of data and serve the keys over HTTPS and not plain HTTP.
See Serving Key Files Securely Over HTTPS on the Apple Developer site.
The first thing, that you have to keep in mind when dealing with content protection, is the fact that there is no perfect solution. There is no solution to guarantee you that only the audiences that you intended will be able to watch the video. All the protection schemes make it harder for the others to steal it but not impossible. Here are some of your options:
AES-128 encryption - you have to take special care to protect the key. Once the key "leaks" then anyone will be able to decode the video with some effort. The advantage is that's this method is simple and supported by the multitude of players.
SAMPLE-AES encryption - again you have to take care of the key. But even if it "leaks" one would need a specialized software to decode the video as it's not trivial. The disadvantage is that not all players support this method.
use DRM - DRM solutions are very expensive and require effort for integration and specialized players. But they provide the most protection.
There is no silver bullet. It depends on you needs and the level of protection you need. Don't forget that after all even the most advanced encryption scheme is not protected against simple things like screen capturing for example.
In normal case or a general use case
1. You can continue to use AES-128 as the encryption mechanism
2. Use HTTPS to provide the transport security.
3. Use token/cookie to authorize the user
(The cookie/token should be sent to the key server and the key server validates it before delivering the key)
Above 3 steps provide you the content protection, transport protection and to authorize users.
To answer your second question,
Authorized users with right tokens will be able to download the contents and keys to decrypt it. (There are plenty of tools to do it) you need a custom client to avoid that and html5 supported browsers cannot stop that.
I am just researching and playing around with HTML5 FileSystem API. I am downloading a video from the server and saving it to the local sandbox filesystem. Say a user comes to the sites, hits download on the video, it saves to the filesystem, then the user happens to go offline.
My question is, what is the best practice for checking if video is already in the filesystem and loading it from there?
Thanks
You're asking about persistent, client-side storage of video, specifically using the Directories and System API, sometimes called "File System API." I believe this is currently only supported on Chrome 28 and Opera 16 or higher – i.e., slightly less than 1 in 3 web users right now.
Per the API spec, the users will be prompted to allow the quota for the on-client storage allotment because you're requesting persistent, not transient, storage. While the persistent client storage may be handy, it's not entirely transparent to the user.
As for determining if the Chrome or Opera user has the video stored locally, simply calling getFile() file will do it; if the file doesn't exist, it simply throws an error that you can then handle to go ahead and pull down the video. That's the standard / best practice way of determining if a file has been stored locally.
PS: Yes, I see that Blackberry mobile supports the API, too. I just don't know if either of the remaining Blackberry users will have the device storage quota available for video :-)
I know there's a new html5 API called web storage, but it basically allows only up to 5MB of storage per domain, so how services like Deezer do to offer an offline mode ? It means that they have to store the musics on the computer, but it's all in the browser, so how do they do to bypass the 5MB of storage ?
http://www.deezer.com/en/features/everywhere.html
I can't speak for Deezer, but there are several new APIs in development for HTML5 including the FileSystem and FileWriter API.
In use cases it gives examples of large storage requirements the API will be able to fulfil such as storage of large media files and assets.
Offline video viewer
It downloads large files (>1GB) for later viewing.
It needs efficient seek + streaming.
It must be able to hand a URL to the video tag.
It should enable access to partly-downloaded files e.g. to let you watch the first episode of the DVD even if your download didn't complete before you got on the plane.
It should be able to pull a single episode out of the middle of a download and give just that to the video tag.
It's still a working draft and not very widely adopted.
I am building an application that allows authenticated users to use a Web browser to upload MP3 audio files (of speeches) to a server, for distributing the audio on a network. The audio files need to use a specific bit rate (32kbps or less) to ensure efficient use of bandwidth, and an approved sampling rate (22.050 or 44.100) to maximize compatibility. Rather than validate these requirements following the upload using a server-side script, I was hoping to use HTML5 FileReader to determine this information prior to the upload. If the browser detects an invalid bit rate and/or sampling rate, the user can be advised of this, and the upload attempt can be blocked, until necessary revisions are made to the audio file.
Is this possible using HTML5? Please note that the question is regarding HTML5, not about my application's approach. Can HTML5 detect the sampling rate and/or bit rate of an MP3 audio file?
FYI note: I am using an FTP java applet to perform the upload. The applet is set up to automatically forward the user to a URL of my choosing following a successful upload. This puts the heavy lifting on the client, rather than on the server. It's also necessary because the final destination of each uploaded file is different; they can be on different servers and different domains, possibly supporting different scripting languages on the server. Any one server would quickly exceed its storage space otherwise, or if the server-side script did an FTP transfer, the server's performance would quickly degrade as a single point of failure. So for my application, which stores uploaded audio files on multiple servers and multiple domains, validation of the bit rate and sampling rate must take place on the client side.
You can use FileReader API and Javascript built audio codecs to extract this information from the audio files.
One library providing base code for pure JS codecs is Aurora.js - then the actual codec code is built upon it
https://github.com/audiocogs/aurora.js/wiki/Known-Uses
Naturally the browser must support FileReader API.
I didn't understand from your use case why you need Java applet or FTP. HTTP uploads work fine for multiple big files if done properly using async badckend (like Node.js, Python Twisted) and scalable storage (Amazon S3). Similar use case is resizing incoming images which is far more demanding application than extracting audio metadata out from the file. The only benefit on the client side is to reduce the number of unnecessary uploads by not-so-technically-aware users.
Given that any user can change your script/markup to bypass this or even re-purpose it, I wouldn't even consider it.
If someone can change your validation script with a bit of knowledge of HTML/Javascript, don't use HTML/Javascript. It's easier to make sure that it is validated, and validated correctly by validating it on the server.