Google says it’s aiming to make the Internet safer with its “HTTPS Everywhere” initiative — encouraging websites to secure their connection to your browser using HTTPS encryption. The company is giving webmasters an incentive to enable SSL encryption by publicly stating that its search algorithms are now using HTTPS encryption as a ranking signal.
But based on GeekWire’s rollout this weekend, it looks like certain parts of the internet aren’t quite ready for an all-SSL world. After briefly enabling HTTPS on the site, we’ve been forced to turn off encryption on our articles.
Search engines are an important source of readership for GeekWire, so we decided to roll out HTTPS to take advantage of the additional security and potential SEO boost, even if that boost was small in the near term. It’s rare that Google gives exact guidance on what is important to their search algorithm, and it is easy to see why the company would place higher trust in sites that go through the time and expense of encrypting their traffic.
Plus, we’ve got at least one reader who is very passionate about this feature.
I think that @geekwire is setting a bad example by not enabling SSL even as it complains about spying. @johnhcook @toddbishop @moniguzman
— Lee Colleton (@sleepylemur) July 26, 2014
We’re listening, sleepylemur!
The process was pretty easy for us. We ended up spending $350 on a wildcard SSL certificate and got that installed on our webservers. We run GeekWire on WordPress, which is filled with lots of absolute URLs, so we had to do a few rewrite rules to change https://www.geekwire.com to https://www.geekwire.com within the content of our pages. Then we redirected all of our pages to serve over HTTPS. We did see a small increase in page response time, from ~25ms to ~90ms, but the pages were still fast enough. This was all pretty straightforward, and our pages were nicely displaying the padlock to show that traffic was being encrypted.
The trouble for us wasn’t our own content. That worked great. Where we ran into problems is with embedded content from other sites, namely video and audio content from major news and media companies. As a news organization, we often use video and audio embeds from around the web to supplement our stories. While YouTube video embeds do support SSL, many of the media players used by websites do not. Web browsers block non-secure content on an HTTPS webpage, so video and audio embeds simply appears as a blank space on an HTTPS page.
While YouTube’s current embed code works regardless of whether traffic is encrypted or not, their older embed code from a couple years back that used Flash was set up to only serve videos over HTTP. It looks like that embed code changed a couple years ago, so we had a bunch of content that wasn’t appearing from 2011-2012. If your site has lots of YouTube videos embedded from a few years back, you’ll have to go and update each video to the new embed code. The side benefit here is that those older video embeds will then also appear on iOS devices which don’t support Flash video content. Tedious, but probably worthwhile.
We went through a number of sites that we sometimes use to embed video and audio content. This is just a sampling, and is by no means exhaustive, but the results are pretty consistent: this sort of embedded content is simply not available over SSL.
- CNN – has its own video embed codes, but server doesn’t respond to HTTPS requests for videos
- NBC News – uses an embedded player from thePlatform that gets blocked for not serving content over SSL
- Bloomberg – has its own video embed codes, but server doesn’t respond to HTTPS requests for videos
- TechCrunch/AOL – has a custom video player for AOL content that doesn’t respond to HTTPS requests
- King 5 – uses embedded Flash player from Brightcove
- KIRO Radio (host of the GeekWire Radio show) – has its own audio embed codes, but server refuses connection over HTTPS.
If your website has tidy content that you directly control, a migration to HTTPS is probably pretty straightforward. However, if you are like us and sometimes use embedded audio and video from other sites, you’re probably out of luck. The content providers simply aren’t supporting SSL in their infrastructure at the moment. Looks like Google will have to push harder on the content delivery websites to enable SSL in the way that YouTube does.
GeekWire will maintain SSL encryption for the administration of our site, and the parts of our site that are e-commerce enabled have always been encrypted through our 3rd party vendors. But for the moment, we’re going to have to hold off on Google’s calls for “HTTPS Everywhere” until content providers support it more broadly.
