Back to blog homepage

Will Google’s Push to HTTPS Disrupt Your Video Delivery?

The web is moving from HTTP to HTTPS on it’s journey to a more secure internet. This will create a lot of potential problems for video providers, and the best defense is to be pro-active.

Google is known to favor HTTPS on the web, even to the point of ranking HTTPS sites better than HTTP. For some time, Google’s Chrome browser has been notifying people that some JavaScript APIs will stop being available on non-secure sites (i.e. on sites not using SSL encryption). The list will likely grow but for now, some of the notable inclusions are as follows:

  • Geolocation
  • device motion / orientation
  • Encrypted Media Extension (EME)
  • getUserMedia
  • AppCache and Notifications

Google didn’t announce any specific dates about when these features will become HTTPS only. For some time it seemed like an empty threat, until Google removed the Geolocation API in Chrome 50. Now, we are starting to see more changes in the pipeline, some more subtle, and some which could have a major impact on your business!
The recent Chrome version 56 now marks sites with passwords or credit card information, that are not using an encrypted connection. The next step in the interest of user awareness is likely to be a fundamental switch in communicating a website’s HTTP/HTTPS status. Instead of highlighting a website with HTTPS as secure, we will start to see warnings marking HTTP websites as non-secure, regardless of the information on the site. The potential loss in traffic for sites that are marked as insecure is likely to be significant.
Support for Encrypted Media Extension (EME) will also stop for non-secure sites. EME is required for playback of DRM (Digital Rights Management) protected content and is used on websites such as Netflix or Amazon Prime, but is also a necessity for many smaller content providers. Content providers using DRM, who are too slow to upgrade to HTTPS, will simply be unable to stream their videos.

The challenges in securing a website

Securing a website is easier than ever, thanks to initiatives like Let’s encrypt. where you can get a SSL certificate for free, but there are a few challenges to overcome before we achieve a completely secure web.
The first roadblock is awareness. Many website owners are simply not up to date with these developments, and so can’t react to them. The second, and much more important, as it has further implications, is that a website running on HTTPS should only load other resources from HTTPS origins, otherwise you end up with mixed content. Browsers may tolerate loading so called passive content over a non-secure connection, but this still opens the thread of a man-in-the-middle attack. Non-secure resources that a browser qualifies as active content will be blocked by almost all modern browsers. Active content are resources which can interact with the rest of the website. This includes for example JavaScript, CSS, flash objects and iframes. Passive content on the other hand are resources which are not interactive in this respect, such as images, video or audio.

About now you are probably thinking, “Wait, so my videos are not affected, right?”

How will this affect your video platform?

If you are using a plain video element and feeding it a direct source, such as a simple progressive mp4 file, then you are probably OK. However, if you are using adaptive streaming and DRM, things are a bit different. The content as well as for the DRM license request both happen via JavaScript’s XMLHttpRequests (XHR). As they are initiated by JavaScript one might already guess that this falls under the restrictions of active content and hence will be blocked by modern browsers.
Will your videos play with the HTTPS video changes?
The solution for this problem seems to be easy: Simply provide an HTTPS-enabled DRM license server URL and serve all content via a secure connection. While getting a secure connection to the license server is usually not a big issue, serving the content can be tricky. Usually, the content is served via Content Delivery Networks (CDNs), such as Akamai, CloudFront or Fastly. Most of them already support serving content over HTTPS, but unfortunately not in every available region.
If that happens to be the case for you, what can you do about it? As it seems, currently the only option is to look for a better CDN provider. Hopefully, all CDN providers will support secure connections in all regions soon. Until then, this criteria should be a major point when choosing your CDN provider.

One last thing

Google Chrome 58 promises to deliver one last subtle change to the way EME and DRM will need to be configured. Until now, it was sufficient to initialize the EME with a simple configuration object specifying that the content to be decrypted is common encryption (MPEG-CENC) compliant. Starting with the Chrome version about to be released in April, more details, like the exact video and audio codes are required. If that’s not the case, it will simply not work anymore. Starting in the current Chrome version 56 you will notice a warning mentioning this behavior.
If you’re using the Bitmovin HTML5 Player there’s no need to worry about this. The team is working on the required changes and we will provide an update to v5, v6 and v7 players within the next weeks. Update: The required changes are available in the player versions v5, v6 and v7. Please make sure to use at least v5.2.20, v6.1.14, v7.0.12 or v7.1.0.
If you are using your self-brewed player it is time to start working on the changes. Currently, your working code might look like this:

var widevineOptions = [
 { initDataTypes: [ 'cenc' ] }
 'com.widevine.alpha', widevineOptions)
 .then(function(keySystemAccess) { … } );

It just requests access to the DRM system via the EME by specifying the type “cenc”. At the current Chrome versions this works perfectly fine. However to get it to work in v58 and above, you will need to add the specific codecs to the capabilities:

var widevineOptions = [
 initDataTypes: [ 'cenc' ],
 audioCapabilities: [ {
 ​contentType: 'audio/mp4;codecs="mp4a.40.2"'
 } ],
 videoCapabilities: [ {
 ​contentType: 'video/mp4;codecs="avc1.4d401e"'
 } ]
 'com.widevine.alpha', widevineOptions)
 .then(function(keySystemAccess) { … } );

Please note that the code with the specific audio and video capabilities is also already supported in current Chrome versions, so it can already be safely used. The main reason for this change by Google might be to make it possible to check exactly which codec is supported by the EME and which is not, as the EME implementations tend to have their own decoding and rendering units, as well to ensure a trusted chain is available.


By forcing websites with premium video content to HTTPS Google takes another big step towards a more secure web. Unfortunately, this might come at with a price for some online content providers. As we have seen above, solutions to some of the upcoming challenges are not always straightforward. Not only for website providers and browser vendors, but also for CDNs who need to update or upgrade to survive in a more more secure online environement. Hopefully, all major CDNs will support secure connections in all regions over the world due to the lead that Google is taking. Until then, customers need to choose carefully, based on the location of their users.
Bitmovin is very active in identifying these challenges early and creating solutions for our customers. We are taking care of changes for you as much as we can so you don’t have to worry about. If you haven’t already tried our player, sign up for a fully featured HTML5 Player here.

Spread the word!


Daniel Weinberger is a Principal Solutions Architect at Bitmovin. After years of developing the Bitmovin Player and leading the player engineering department, he's now enabling customers to integrate and optimize the Bitmovin Player and Analytics into their applications.

Ready for the future of video streaming?

Contact us to see how we can optimize efficiency, decreasing time-to-market for your video needs