Last week held the Kranky Geek mini conference in San Francisco. While Nimble Ape couldn’t be there due to already being in Ireland for Nodeconfeu, we’ve been catching up with the talks which are already on youtube.
Something that wasn’t widely known before last week that was announced during Google’s WebRTC update from Serge Lachapelle and Justin Uberti was the fact that Chrome will no longer support
getUserMedia calls from a site that’s served up over http. The Chrome team are trying to roll this out before the end of 2015 in Chrome 47. That means any of your sites that leverage
getUserMedia will be required to be served up via the https protocol to work across all browsers.
Now, there were outcries on twitter about how developers would be able to develop solutions locally if the API now required https.
Important @googlechrome #webrtc announcement - getUserMedia will not work with HTTP starting in Dec #webrtclive pic.twitter.com/PYJIClHbm4— Chad Hart (@chadwallacehart) September 11, 2015
How are we supposed to test stuff in localhost now? https://t.co/o9RkNimlnh— Saúl Ibarra Corretgé (@saghul) September 11, 2015
There were others I promise…
Well, the answer is; nothing changes! The slide on the presentation should really have said that
getUserMedia will only work with trusted origins, localhost is one of them. This is exactly the same as when you’re developing screen-sharing capabilities with WebRTC. You can see the list of trustworthy origins on the w3 site - Thanks Sam Dutton for clarifying this.
Another thing to note is that self signed certs are not considered trustworthy. So if you want
getUserMedia to work on your site, you’ll need to cough up for a proper TLS certificate and start serving up content with that cert; they’re not expensive nowadays.
You can go and check out whether your site still works as expected by running Chrome Canary
Want to check out the Google WebRTC team’s update? Here it is…