The impact of Google’s new Chrome security policy on WebRTC


UPDATE 9/16/15: After we published this post Google announced that they are pushing back the release date of the HTTPS security change. They’re estimating that it will now be released to production in December 2015. 

Google recently announced a security policy change that will impact future versions of the Chrome browser. Any website which has integrated geolocation technology, screen-sharing, WebRTC and more, will now be required to be served from a secure (HTTPS) site.

We at TokBox are supportive of this update as we believe operating your WebRTC-based applications through HTTPS is a best practice and offers enhanced security. In addition, it has the added bonus of improving your end-user experience by remembering their hardware settings, and even allowing screen-sharing (if you choose to implement it).

Our current estimate is that the security policy change will go into effect for Google Chrome as early as November 2015. The release to production isn’t set in stone, but we’d suggest you make the migration as soon as possible to reduce the chance of disruption to your service.

So what does this mean for your OpenTok-powered application? If you’re running an HTTP site with OpenTok integrated, you need to switch your site to HTTPS. Once this security change is released to Chrome, unsecured (HTTP) sites will no longer be able to implement voice, video, or screen sharing through the OpenTok platform.

Not sure where to start? Here are some technical articles on making the switch to HTTPS:

You will need to obtain a TLS certificate for your website. These are available from a number of certificate authorities. And in mid-September, Let’s Encrypt will start providing free TLS certificates. (Let’s Encrypt was founded by the Internet Security Research Group, with wide industry support.)

Once you have obtained a TLS cert, you will need to configure your web server and your CDN to serve pages over HTTPS. Here is some information:

Note that for local testing, pages served from http://localhost can still access the camera and microphone. Many teams map specific hostnames (, etc) for different purposes in their development workflow. While http://localhost has an exception to allow developers to continue to use getUserMedia() without issue, you may be wondering how to prevent the rest of your servers from breaking with this change. Here are 2 more options:

1) Use a tunnel that supports HTTPS such as or ngrok, which can act as a forward proxy that terminates TLS and forwards traffic to your webserver. For example, using localtunnel, running this command (`lt –port 8000 –subdomain staging-myapp`) will create a public URL ( which will forward traffic to your machine on port 8000.
2) Generate a self-signed certificate (different from your production certificate to limit access to the real private key). Use this for any non production environments (see your webserver software above for setup instructions). Now you can browse to the page and click “Proceed Anyway” in any TLS related warnings. For extra credit, you can avoid those warnings completely on OS X telling it to trust the certificate.

As we get more information around timing of this release, we’ll make sure to keep you updated.