Getting the Green Lock: HTTPS Stories From the Field — Google I/O 2017 Live Blogs

Bright and early on Day 3 of Google I/O 2017 and I find myself in the second row of a session on HTTPS Everywhere. I've blogged about the HTTPS Everywhere initiative a few times before, but I was eager to see how Google thinks the movement to a more secure web is going.

Approximate Read Time: 7 Minutes

Bright and early on  Day 3 of Google I/O 2017 and I find myself in the second row of a session on HTTPS Everywhere.  I’ve blogged about the HTTPS Everywhere initiative a few times before, but I was eager to see how Google thinks the movement to a more secure web is going.

Session Summary

Emily Schechter, a Google Evangelist for HTTPS Everywhere, began her presentation by showing off the progress the HTTPS Everywhere movement has had.  As of this month over 3/4 of pageloads on Chrome for Windows are now HTTPS, and over half of pageloads on Chrome on Android are HTTPS, and the trend is increasing rapidly.  Just over a year ago in January 0f 2016 only 39% of the top 100 websites supported HTTPS, and only 24% default to HTTPS.  Now in May, 2017 60% of the top 100 sites support HTTPS and 56% are HTTPS only.  Lets Encrypt, a certificate authority that allows for automated issuing of free SSL Certificates, has doubled their active SSL Certificates in the last 5 months from 20 million to 40 million active SSL Certificates.

She moved on to explain how WordPress.com has added HTTPS support for both free subdomains and custom customer domains (using LetsEncrypt on the custom domains).

She spent a little time talking about how the old challenges to HTTPS (Cost, Performance and Maintenance) have gotten easier, a topic I blogged about last month.  Afterwords she invited John Sherwood, Vice President of Engineering at CBS Interactive to talk about how c|net migrated to HTTPS.

c|net started discussing migrating to HTTPS in Q4 of 2014 when Google announced that HTTPS was going to be seen as a ranking factor.  By early 2015 they had determined that at the time there were too many challenges, in particular with their providers for CDN, Ads, and Video.  As such the HTTPS migration was put on hold until these challenges could be resolved, which happened in Q4 of 2015.  They started the migration progress in February of 2016 by moving static assets used on various c|net sites to HTTPS.  They finished moving all static assets by March, began A/B Testing of their first HTTPS site in June, 2016 and launched it in August of 2016.

They began a phased rollout process for each site (starting with the c|net Roadshow) starting with Rewriting links, updating sitemaps, updating the robots.txt, and then monitoring as they repeat the process with the next site.  Once the migration process was begun, the process moved quickly.  The Roadshow was launched in August 2016, by September 2016 they had launched 7 sections on HTTPS, and by October they had fully rolled out HTTPS.  They had found that their main concerns with HTTPS (Performance, SEO Impact, and Advertising CPMs) had no negative impact by the migration to HTTPS and in fact they had actually seen increases in all 3 key metrics.

After John Sherwood left the stage, another company, Rakuten came up to discuss the challenges they had with their migration.  Rakuten has a number of completely different web properties, which presented a different set of challenges as the properties were not tightly integrated with each other as c|net’s was.  Rakuten made the decision to begin their rollout by focusing on sites that other sites depended on (for example sites containing shared resources like video and images).  They have migrated 80% of their sites to HTTPS as of April, 2017

When Emily retook the stage, she discussed one of the other reasons to move to HTTPS besides security, Progressive Web Apps.  Many of the key features of Progressive Web Apps (Service Workers, Push Notifications, HTTP/2 and Brotli compression) all require HTTPS in order to function.  She then went over trivago’s recent task of creating a Progressive Web App to help reach markets with less stable internet connections.

Trivago became invested in Progressive Web Apps to help reach these markets, and as a result had to migrate to HTTPS in order to accomplish that task.  Performance was a major concern to them, so they decided to split their userbase and try 3 different options (in addition to the control test of their existing HTTP performance stats).  In the United Kingdom and Germany, they tried simply switching to HTTPS and were pleased to discover that there was no major performance effect either positive or negative.

In Australia they enabled both HTTPS and keep-alive and saw a significant improvement in response time.  Keep-alive is a technique where once the page has loaded, the browser keeps the connection open and reuses the connection for resources on the page.  Later after settling on HTTPS with keep-alive for the main audience they experimented with HTTP/2 and saw the average number of connections to their servers drop significantly while the number of pages loaded actually increased.  This is thanks to the multiplexing capabilities that HTTP/2 offers.

Finally they measured SEO  over time and determined that there was no decrease in search engine originated traffic across mobile, tablets or desktop and in fact all 3 user groups actually showed a slight increase in SEO.

Once she finished talking about Trivago’s HTTPS migration, she ended her talk by talking about the progressive changes in the way Chrome treats non-https pages.  Their goal is to one day show all non-https pages with a frightening looking red “Not Secure” warning message, but they knew that to make a switch so early in the HTTPS Everywhere movement could result in a combination of chaos first and error fatigue later (where people just get used to ignoring the warning resulting in the warning losing all meaning).  As a result they decided to move in a progressive way.

As readers of this blog will know, this process started in January with a grey “Not Secure” warning showing up any time someone visits a non-https page that has a form asking for either a password or a credit card number.  This coming October, the same grey Not Secure warning will show up on any page that has a form once the user has entered any content in the form.  Also in October, the Not Secure warning will show up on any non-https page loaded in an incognito window.

She didn’t have any timeline to share beyond that, but I would expect the messages to become more prolific on non-https pages as time moves on until eventually the red “Not Secure” warning shows up on all non-https pages.

After the talk, I took a little time to talk with Emily Schechter about the concerns people have been having recently with the false sense of security that https pages can give, especially when you hear about the 14,000 domains containing “paypal.com” as part of the domain that LetsEncrypt has issued SSL Certificates for.  While she agrees that this is a problem, she feels that phishing domains with ssl certificates are a problem for things such as Google’s Safe Browsing List to solve, rather than Certificate Authorities such as LetsEncrypt, and that the benefits that come from a more secure web overall far outweigh the problems of SSL Certificates being issued to fraudulent domain names.

The bottom line of all this is that, as we said last month, HTTPS is vital for your site’s ongoing success on the web, so make sure that your website is secured with HTTPS as soon as possible, but make sure you pay attention to the pitfalls that could cause your HTTPS site to cause more harm than good.

Session Video

Live Blog Transcript

• 08:35: Over 3/4 of chrome loads on windows and over 50% of chrome loads on android are now HTTPS
• 08:35: Primary reasons for HTTPS: Identity, Confidentiality and Integrity
• 08:36: A Vital piece of HTTPS is the certificate authority ecosystem
  • LetsEncrypt, a free certificate authority, in January reported they had 20 million active certificates, in May they have doubled that by passing 40 million.
• 08:37: Another piece of the ecosystem is platforms.  Wordpress.com has secured over 1 million unique customer domains
• 08:38: WordPress.com migration progress
  • June 2014: Reset the net, all wordpress.com subdomains https
  • Jan 2016: First 100k custom domains (Using LetsEncrypt)
  • April 2016: HTTPS Everywhere (all customer domains on wordpress.com and custom domains)
• 08:39: HTTPS support on Top 100 sites
  • January 2016: 39% support HTTPS, only 24% default to HTTPS
  • May 2017: 60% support HTTPS, 56% default to HTTPS
• 08:39: Old Challenges to HTTPS
  • $$$?
  • Performance?
  • Maintenance?
• 08:40: c|net, John Sherwood, VP of Engineering takes the stage
• 08:43: c|net was using HTTPS for secure stuff before, but after google made it a ranking factor they were motivated to go fully HTTPS
• 08:44: Why HTTPS?
  • HTTP/2
  • Geolocation
• 08:44: Challenges
  • CDN Cost
  • Ads
  • Video
• 08:45: Unknowns?
  • SEO?
  • Ad CPMs?
  • Performance?
• 08:46: By Q4 2015 they had resolved the challenges, so they started moving forward
• 08:46: In March, 2016 they moved their static assets first
• 08:47: June 2016 they did an A/B test
• 08:47: August 2016 they launched the first section on HTTPS (c|net Roadshow)
• 08:48: Phased Rollout
  • Rewrite links
  • Available sitemaps
  • Robots.txt updated
  • Monitor & Repeat
• 08:50: c|net’s first Progressive Web App (which requires HTTPS) in October, 2016
• 08:50: Now that c|net is HTTPS, parent Company CBS Interactive is starting to roll out HTTPS to their sites
• 08:53: @emschec is back on stage now to talk about Project Management during a HTTPS Rollout
• 08:55: rakuten focused on migrating sites that other sites depend on first
• 08:56: Progressive Web Apps
  • Service Workers: performance improvements and lets your site work offline
  • Add to home screen
  • Push notifications: keep people coming back
  • HTTP/2
  • Brotli Compression
  • All of these capabilities for Progressive Web Apps require HTTPS
• 08:57: trivago was motivated to move to HTTPS because they wanted to make a Progressive Web App
• 08:58: Performance Wins: Service Workers and HTTP/2 made a huge imact to trivago
• 09:00: HTTP 1.1 v HTTP/2
  • HTTP 1.1 makes separate connections for each file to load a page
  • HTTP/2 multiplexes using a single connection
• 09:00: HTTP/2 Server Push lets you send requirements (css, javascript, images) along with the initial request
• 09:01: trivago HTTPS (UK/DE): no major performance effect
  • HTTPS + keep-alive (AUS): Response time improved 800ms
  • HTTP/2 (in april), Average # of connections dropped considerably)
• 09:05: Browser Changes
  • Chrome has started a goal to move to having non HTTPS pages marked as insecure, but if they went straight to the scary red warning, it can cause more harm than good
• 09:06: Jan, 2017: http pages with passwords or credit cards got a slightly less scary warning (grey “not secure” message)
• 09:06: October 2017: Warning will show up on any page that has a form (once a user has entered any data) and on all incognito window tabs
• 09:07: Spread the word: migrate to HTTPS