One of the typical reasons for choosing a non-free Online Video Platform (OVP) is the ability to determine who gets access to your valuable content. There are numerous ways of video content protection. Most are dividable into two categories:
This blog post will provide insight into the latter category.
It will give an overview of the layers that we, as Blue Billywig OVP, have put together to form a video content protection solution. Let’s go through some of the implications and find out which set of options works best in each situation.
This is the simplest method of video content protection. It could also be called: “Security by obscurity”. The video player and website prevent the user from viewing the video by hiding links to the video streams or showing a link to a short teaser version instead. To get access to the actual content the user needs to prove he’s entitled to it.
There are various ways to verify the user’s access permissions. One could look at the context the user is viewing the video in - or check the geological location or even specific IP addresses and networks that are whitelisted. All the above mentioned options are available as plugins in the content filter mechanism that the Blue Billywig Online Video Platform provides.
One of the more common ways of providing authentication information is to use a secure token. That token can come in the form of a one time access code - based on a shared secret. The Blue Billywig Online Video Platform supports a basic shared secret based one time password mechanism. It’s based on HOTP (HMAC based One Time Password algorithm): https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm. Another option would be to generate the token on the side of the issuer and let the Online Video Platform backend verify it. The received token can be sent together with specific request info (Content ID, Content category etc.). Which option suits best mostly depends on the level of control you need in granting or withholding access to your content.
For instance: the “shared secret” way of generating and verifying tokens is more suitable for a small set of generic rules and content classes.
Example use case: you have a "Premium section" on your website and want to give "Premium subscribers" access to all videos in that section.
Issuing tokens for specific context sensitive content rules typically require a “callback” approach: gather the token and any relevant information and take that bundle back to the source (decision making platform).
Example use case: You have a "congratulations video" for a specific person or group of people. You want to check the issued token together with some user information to determine whether the video can be shown.
The most important downside of just hiding direct links to your content is that it does not offer any video content protection against “hot linking” : someone using another player and platform can simply link to your stream urls and host - or even monetise - your content. A solution to that problem is protecting the actual stream URLs. The Blue Billywig Online Video Platform extensively uses the Amazon Cloudfront CDN which supports three methods of securing access to video content:
Signed URLs are the only option if fine grained (URL based) access control is required. A typical use case: a user has bought a one time pass to an “exclusive” video clip. The video stream url must be a one-time url. The user should not be allowed to share this URL. A technical downside of this method is that the player or video platform must have a specific per URL signing mechanism. The Blue Billywig Online Video Platform has built-in support for Amazon Cloudfront signed urls using a so-called "Canned Policy". A prefabricated policy statement is reused on each request.
Signed cookies are a viable option when you want the user to get access to a number of video streams - that can be scoped or limited by a certain path reference. For example: A user that has proven to be a “Sports subscriber” gets a cookie that provides access to the entire ‘/sports’ folder on the CDN. This does not provide any fine grained access or time limiting methods per url. An advantage, however, is the fact that the player or platform does not have to have specific authorisation support built in: The authorisation cookie will, once placed on the user’s computer, automatically be sent with each request any application on that computer makes to the CDN.
Geographic content restriction as offered by default in the Amazon Cloudfront proposition can only be enabled for an entire “Web distribution”. This means that all content of a certain Online Video Platform customer or publication will be restricted by the same policy. That restriction renders the feature useless in a lot of situations. Fortunately Amazon Cloudfront can be configured to use an external IP restriction backend, as for example provided by the Blue Billywig Online Video Platform. On each user request the ip address and requested url will be sent to the external (OVP) backend. The Online Video Platform backend will decide whether the user is entitled to view the content. As geographic location is solely determined by comparing the requested ip address with a hosted GEOIP database - accuracy is as good as the hosted GEOIP database offers. The Blue Billywig Online Videon Platform uses a regularly updated GEOIP database that claims an above 70% accuracy on city level.
Content restriction is often considered a “necessary evil”. I hope this blog post gave you some insight in the implications and the solutions the Blue Billywig Online Video Platform has to offer to make your content restriction policy work. Contact us if you need some more advice or want to implement a content restriction policy into your Blue Billywig publication.
Also don't hesitate to contact us if you're thinking about implementing other forms of content protection (for instance a full Digital Rights Mananagment system integration).