 I hope everyone is feeling really caffeinated and excited to talk about web security this morning. Thanks for coming out so early. My name is Emily Schechter. I'm the product manager for the Chrome security team. And today I'm going to talk about HTTPS. And I'm really excited to talk to you about HTTPS this year because this year we've reached a turning point where we're finally starting to see a whole lot of HTTPS out there on the web. Here's a graph of Chrome page loads over HTTPS for two of our platforms. And you can see that recently things have really taken off. More than three quarters of Chrome page loads on Windows are now HTTPS. And Android is showing a really strong trajectory as well with more than half of page loads over HTTPS. So we're finally in an HTTPS first web. In early 2016, we published an HTTPS transparency report which shows the HTTPS status for the top 100 sites on the web. And we now see 60 of those top 100 sites supporting HTTPS. And of those, 56 are defaulting to HTTPS. And this is so exciting because HTTPS is out there protecting your data. So I'll remind you of how it actually does this. HTTPS actually gives us three security properties. The first is identity. When you type HTTPS Google.com into your browser, your browser receives a certificate that proves the server is the real Google.com, not some other server who's pretending to be Google.com. The second is confidentiality. Once your browser knows that you're talking to the real Google.com with that certificate proof, both the browser and the server have a guarantee that only they can read the data that's being passed between them and not anyone else eavesdropping on the network. And finally, integrity. The browser and the server have a guarantee under HTTPS that when they send data from one to the other, the data they send is what the other party receives. So an intermediary on the network can't modify or tamper with the data that's being sent. So these are the three security properties that we get from HTTPS. And without HTTPS, things start to look pretty scary. Without HTTPS, you have absolutely no idea what site you're actually viewing and talking to. Without HTTPS, you can have absolutely no expectation that the data you're sending, like your password or your credit card, for example, hasn't been eavesdropped on or stolen. And without HTTPS, you can have absolutely no expectation that the site you're viewing hasn't been modified in some way, like maybe ads or malware have been injected by someone on the network. And this is important because the web has always been a pretty powerful place. The content of the sites that we browse through says a lot about our behavior, our identity, and our intentions. And recently, the web has become even more powerful. New APIs allow sites to know more information about us than they ever have before. And the more amazingly awesome and powerful we make the web, the more important it is for us to not give these superpowers to a bad actor. Protecting your site with HTTPS is like locking your front door before you leave the house. It's really just the bare minimum in terms of responsibility for that great power. HTTPS gives us the guarantees we need to trust using the web. And this is why Chrome and the web security community want to move towards a web where HTTPS is everywhere. So HTTPS is important. And what's great is that we're seeing so much momentum as the whole web ecosystem moves toward a place where HTTPS is everywhere. We're seeing sites around the world, across different verticals and industries, migrating to HTTPS. And we're seeing different pieces of the HTTPS ecosystem come together to make it really easy and automated for new sites to be HTTPS by default for free. A vital piece of this HTTPS ecosystem is the certificate authority ecosystem. So certificate authorities give sites the certificates they need to use to make HTTPS connections. Let's Encrypt is one of those certificate authorities. It happens to be a free and automated one. And they've published some really amazing metrics that show how HTTPS is taking off at scale across the web. As of January, Let's Encrypt was supporting more than 20 million active certificates in total. And I just checked yesterday. They tweeted that they just passed 40 million secure websites, which is really pretty amazing. They've even issued more than a million certificates in a single day a few times. So this is amazing progress towards getting the whole web to be HTTPS everywhere. And one of the ways that Let's Encrypt has taken off is by partnering with platform players and website creation tools. So one of these platforms that has enabled massive HTTPS ecosystem change is WordPress.com. For those not familiar with WordPress.com, you can use the platform to create beautiful websites and blogs for free or enhance them with premium services or add WordPress solutions for enterprises. To give you a sense of scale, WordPress.com has to date secured over 1 million unique customer domains. So I talked to WordPress.com to get a sense of their story and how they got there. So in mid-2014, WordPress.com took their first steps as part of an initiative called Reset the Net. And this involved migrating all WordPress.com subdomains to HTTPS. So this is all sites without custom domains, as well as their WordPress.com admin traffic. Then in January 2016, WordPress.com switched their first 100,000 custom domains over to HTTPS only. And they actually did this by working with Let's Encrypt. So Let's Encrypt gave WordPress.com an efficient and automated way to provide certificates for hundreds of thousands of sites at scale. And by April of last year, WordPress.com had moved traffic for all of their customer domains on both WordPress.com and on custom domains to HTTPS. And they make it really easy. It's not opt-in. It's on by default. And it's not a paid premium. It's for free. And there's no configuration or intervention required at all. So scaled support from platforms like this and from all around the web ecosystem has helped us get to this amazing HTTPS first web, where most of the top sites on the web are supporting and defaulting to HTTPS. But we weren't always here. So this is not too long ago, back when we first published this HTTPS transparency report in early 2016. Really not very many of those top 100 sites were supporting HTTPS. And of those, not too many had HTTPS by default. So we didn't really know if HTTPS was going to take off everywhere. And this was because there used to be some pretty significant challenges to migrate to HTTPS. When you used to think about migrating to HTTPS, maybe you used to think that it was going to be expensive, or it was going to hurt the performance of your site, or it was going to be a lot of maintenance. And a lot of these hurdles really have gotten much easier in recent years, because people all over the web's ecosystem have really cared about getting to a future where HTTPS is everywhere. But even with these improvements, HTTPS migrations do take careful planning. They take time, and they take coordination. So for the rest of this talk, we'll go over three case studies from sites who have recently migrated to hear first hand what challenges they did come across and what they learned during their HTTPS journey. And I'll finish by talking about some upcoming changes in Chrome and what these changes might mean for those remaining HTTP sites. So we'll start first with CNET. CNET is a site that publishes tech product reviews, news, videos, and more. So to hear first hand about their HTTPS experience, please welcome the vice president of engineering and technology at CNET, John Sherwood. Thank you, Emily. Hi, everyone. Thanks again for coming out so early on a Friday, especially after the concert last night. I'd always dreamed of performing on stage at the shoreline. I didn't think it would be in a parking lot in a tent, but I'll take it. Just to give you a little context, first of all, CNET is the world's leader in tech media brand with tens of millions of people coming to us every month to consume our tech news, our product reviews, our how-tos, and videos on multiple platforms. We were founded in 1994, which may mean we're older than some of you here. And that also means we have a very long tail of content that we have to deal with. CBS acquired CNET in 2008 to form CBS Interactive. Nearly 300 million people come to our properties every month, which makes us the seventh largest digital media property. And for some context, the top five include Google, Amazon, Facebook, Microsoft, and Yahoo. So we're in pretty good company. Most recently, we just won two Webby awards for Best Consumer Electronics website, as well as a People's Voice Award. And we're very proud of those. So today, I'm going to talk to you about our path to HTTPS. I'll highlight some of the challenges we face and how we resolve them, as well as some key steps we took for our rollout and how we mitigated the risks. And finally, I'll cover some of the results of our transition. I'm going to warn you that this timeline may look rather long. And a couple of things, we did have some of the challenges that Emily mentioned, as well as we took a very conservative approach, because we wanted to protect our business. So for now, we'll start back in Q4 of 2014. So of course, we've been using HTTPS to provide a safe and secure environment for our users when their personal data was involved for things like login and registration. However, we discovered that secure iframes in a non-secure environment were vulnerable to attack. And this meant we had to change some of our user experience. That didn't make our product team very happy. We also had, let's see, and then in late 2014, Google announced that HTTPS would become part of the ranking signal. And as intended, we were incented to take advantage of that. Another driving factor was we wanted to take advantage of the performance improvements that HTTP2 could give us, such as multiplexing or single connection. There were additional capabilities that HTTPS would unlock, such as geolocation. And we also wanted to build a progressive web app. And this would require a lot of service workers to allow for push notifications or offline mode. So we were very excited, and we wanted to start taking a look at how we could move to HTTPS. And unfortunately, we discovered there were some big challenges. So first off, probably the biggest challenge for us was the cost of serving secure content through our CDN. It was going to be extremely expensive. So we were going to have to renegotiate that contract, which we did in late 2015. We would have to work with a lot of our ad clients and providers and third parties to give us safe and secure tags. This required a lot of outreach and education. We actually had to tell some people, no, you can't just put an S at the end. We also had to update our entire video stack. We had the same CDN cost and ad tech issues. But we also had to make some significant changes in our delivery infrastructure. And then, of course, there were the unknowns. We'd heard horror stories of sites that had moved over to HTTPS and had a big bad impact on their SEO performance. We were able to meet with a few of them and talk about best practices, what had gone well, what had gone wrong with their migrations. For example, one of the sites told us that they had turned on their 301 redirects, but they had not unblocked their secure robots file. So search engines were following the redirects and then not able to crawl their secure site. And it took them a few hours to discover that. And Google's also published a lot of best practices, which we followed to a T and helped us a lot. We had also heard ad CPMs were going to be much lower. And unfortunately, this was not really something we could find out from other people. We just heard rumors. So we had to test that one ourselves. And then finally, there's performance. We were concerned of the impact that HTTPS was going to have on every single request. Of course, there are techniques you can use with HTTP2, as Emily mentioned. And in fact, last year at Google I.O., there was an excellent talk called Missbusting HTTPS. And it covers a lot of these. So by Q4 of 2015, we resolved most of these challenges and we were ready to get serious about our migration. So to mitigate the risks, we knew we had to take a phased approach. First off, we formed a small team and it was led by two Rockstar engineers who are here. Tyler Batliner and Jonathan Miller. So you should hit them up afterwards if you want to get the gory details about what actually happened. To kick things off, we moved our static assets and this allowed us to immediately take advantage of HTTP2. We moved our images, our CSS, our JavaScript. We then began the process of moving all the third-party dependencies, so all of the ads, third-party tracking. And we implemented a content security policy. We used a great free tool called report-uri.io and this gave us visibility into all the sub-requests that were being made that were not secure. And then our next phase was an A-B test and this wasn't gonna be available to search engines but this would allow us to expose a segment of our users to a secure site and we could measure our core KPIs as well as the impact on performance. And then by August, we'd finally address all the dependencies and we felt good about the A-B test data and we were ready to move forward with a public launch of our site. We did it in seven phases over the course of about two months which was about once every two weeks and we started with CNET Roadshow which is our site for car owners and enthusiasts. So for each phase, we would start by rewriting all of the links, hrefs, canonicals. We had to make changes in our web apps and in our data. We did this everywhere except for one exception. We ensured we had both site maps for that section for both HTTP and HTTPS and here's whether one exception is our HTTP site map. Included HTTP references that way when we turned on our 301 redirects, the Googlebot could find and follow those links and find our redirects and index us. Then we updated our robots files to include those site maps. One thing to note, our secure robots file had already been crawled and cached by Google so we had to submit it along with our site maps to the Google Search Console to get it to update. And then finally we turned on 301 redirects and we launched and started monitoring all our core KPIs. And so we monitored our site metrics, all of the search engine refers, 301 redirect levels and our ad performance and we were happy to see that we didn't see any negative impact. This here shows Roadshow when we launched in the middle here is August when we launched and as you can see there was no negative impact to our search refers. This is an expanded view across our entire rollout. Once again, there was no negative impact to our search engine refers. And this looks at our ad CPMs. Once again, no negative impact across the entire rollout. And finally, performance. This is our rum data for page load and with HTTP2 we were able to mitigate any impacts there and this was solid. So in late October, just a couple of weeks after we went fully live, we were able to launch our first progressive web app, CNET Tech Today, which is our progressive web app version of our popular iOS app, which gives you the 10 most recent important tech stories of the day. And so once the foundation was laid, all the sites here on the left have now gone to HTTPS and the sites on the right are in progress. So we've seen great results and I would encourage you if you're thinking about moving, now's the time to do it, go ahead. And with that, I'll turn it back over to Emily. Thank you. Thanks so much, John. Those are some really cool graphs to see. So as you just heard from CNET, HTTPS migrations can actually be quite complicated. And this really depends on how complex your site is. HTTPS migrations can require careful planning to make sure that the migration goes smoothly. So I'll use a second case study to highlight how project management and migration planning can help ensure a smooth transition. Rakuten is one of the world's leading internet services companies, offering a wide variety of services for consumers and businesses with a focus on e-commerce, finance, and digital content. Rakuten is headquartered in Tokyo and it operates throughout Asia, Europe, and America. And you may know some of these Rakuten companies. Their e-commerce platform, Rakuten Ichiba, is the largest e-commerce site in Japan. And besides e-commerce, Rakuten services cross many other verticals like payments, banking, insurance, sports, media, and communication across three continents. So you might imagine that moving a huge global ecosystem like Rakuten all over the HTTPS might not be that easy. So Rakuten started looking into their HTTPS migration and they realized that the task was going to be massive and complicated. They realized that they wanted to move over 250 websites and 350 non-website services. And they found that there were over 3,000 interdependencies between these. For example, multiple websites might be relying on the same ad network or API. And because tens of thousands of merchants rely on Rakuten's online marketplace, any HTTPS issue could have damaged the business of these merchants. So a brave group of program managers at Rakuten formed a program approach to steer the migration across the entire Rakuten ecosystem. So Rakuten divided their ecosystem into a number of smaller project teams. And in each group, a lead was assigned to coordinate the HTTPS migration for that group. And then each of these leads reported into the program management office who then reported to a steering committee of Rakuten execs. And this centralized program management office is the key here because they provided a ton of centralized support that provided a bunch of different benefits that allowed Rakuten to smoothly migrate this complex ecosystem over to HTTPS. The centralized program management office dealt with some key migration pieces for the whole company so that technical teams could focus on their own areas of responsibility. Here are some of the pieces that were centralized by the program management office. Information sharing of best practices. The office provided a tool for engineering teams across the globe to ask similar questions and get responses. It provided information sharing workshops and newsletters. There were centralized dashboards so Rakuten had a single source of data and reporting to quickly escalate any real issue within the project teams. And there were centralized risk management. So the program management committee made sure that each of those project teams knew what specifically to look out for and what concern was actually just an HTTPS myth. The program structure specifically helped Rakuten to manage cross-company dependencies. So they mapped out which services had the most dependencies and services that multiple sites relied on became high priority migration targets. This has helped put Rakuten on the path successful HTTPS migration for those 250 websites and more than 350 non-website services. So by March their services were about 80% migrated to HTTPS and they're still on great track to finish their migration by their target date. So Rakuten was able to use effective project management to avoid migration risks for a really complex ecosystem migration. And a quick shout out to Will from Rakuten. He's actually the program manager who led this effort and he's here today and we'll be around after the talk to answer any questions about their migration. So taking a step back from HTTPS, we're all here at Google I.O. It's incredibly early on a Friday morning. You spent the last two days hearing a lot about progressive web apps. And you've been hearing about some amazing capabilities that your site can have with progressive web apps. Some of these capabilities you've probably already learned about from the many talks already in the past few days. Service workers can give your site a huge host of new capabilities like the ability to work offline and huge performance improvements. Add to home screen lets your site feel more like an app with access from your launching screen. Push notifications, keep users coming back and engaged. And some new performance improvements like HTTP2 and Broutly Compression can really improve site performance, especially for those users with poor connection quality. And you may have heard that all of these capabilities actually require HTTPS as a baseline in order for you to unlock them. So the next case study that I'll talk about was motivated to move to HTTPS to create a progressive web app with these new capabilities. And they saw firsthand how HTTPS enabled them to do even more with their site. This site is Trivago. It's a global hotel search platform. Focusing on reshaping the way travelers search for and compare hotels. And as I mentioned, Trivago was specifically motivated to move to HTTPS by the set of capabilities that Chrome and other browsers require HTTPS in order to unlock. And they were able to create a really amazing set of experiences with these capabilities. So here's what some of these capabilities look like for Trivago. With add to home screen, a dialogue allows users to access the app from their home screen. Trivago's new offline awareness helps users even when there's no connection. This is a huge improvement from losing frustrated users who lost their connection while on the site. And they mentioned actually about 2% of their users will lose a connection one time while they're on the site. So instead you can now play this fun maze game. It kind of reminds me of the Chrome offline dino game. And they can also create functionality like helping people to retrieve hotel information when they're offline traveling. And Trivago will also roll out push notifications so that users can be notified when the price for a certain hotel drops significantly. And they also rolled out some amazing performance improvements with service workers and HTTP2. You've probably heard a little bit about service workers already today. HTTP2, if you haven't heard of it, it's the next version of HTTP, which is now supported in many browsers, including Chrome and Firefox. And using HTTP2, you can do things like multiplexing and server pushing, which optimize performance for HTTP requests, especially for your users who have the worst and the slowest connections. So I'll give you a quick PM explain about how cool HTTP2 is. So Chrome usually speaks to web servers using HTTP11. So Chrome will open a communication channel, send a request to the server and wait for a response back. And with HTTP11, it will actually open up to six of these communication channels. So now with H2, there's actually only one communication line using what's called streams to transfer data. So the data will be broken down and sent back in chunks according to the priority of the request. This is called multiplexing. And besides multiplexing, the server will also assume that Chrome will want a few other files like CSS and JavaScript. And this is called server pushing, where they send it automatically. And all of this together makes H2 way more efficient than HTTP11. Remember, this is only available over HTTPS. You might wonder why is this only available over HTTPS? There's actually a really practical reason for this. And that's compatibility. There's some intermediaries and things like proxies that are likely to get kind of confused, or in some cases actually break things when they see HTTP2 traffic, because it looks so different from HTTP1 traffic. So we need the integrity guarantees of HTTPS to be able to support HTTPS without breaking things. So Trivago rolled out HTTPS and H2, and here's what they found. With their HTTPS migration, they saw no major performance effects for their central markets of the UK and Germany. They did see some minor impact on some HTTPS connections, but they were able to win it back and more using available optimizations. At the same time that they migrated to HTTPS, they added some new dedicated HTTPS terminator nodes, and they turned on another performance optimization called Keep Alive. And in their locations that were further geographically and tended to have a little bit more latency, like Australia, for example, they found that Keep Alive improved their site response time by about 800 milliseconds. And then they started sending HTTP2 requests at the beginning of April, just about a month and a half ago, and their data already looks really great. Their average number of connections dropped sharply because of that HTTP2 multiplexing, where multiple assets are sent over the same connection. So here's a graph of the average number of connections to Trivago's CDN, and you can see that on the day they turn on HTTP2, the number of connections is dropping sharply. Trivago also shared that before starting their migration, they were similarly concerned that it might affect their SEO. So they carefully measured their SEO during the migration, and what they actually found was that HTTPS did not negatively impact their organic search impressions and clicks. So here's a nice graph of their search clicks during the migration, and you can see that as the traffic triv... Sorry, it switches over to HTTPS across their platforms. There's even a positive impact on SEO, which they think might be partly due to seasonal effects. So Trivago's HTTPS migration enabled them to create amazing and fast experiences with their web app. So we just talked about three cases from sites who recently migrated to HTTPS, and you've heard about the drivers that cause these sites to want to migrate to HTTPS. So for the past few years, I've talked to a bunch of sites about their HTTPS migrations, and when I asked them about what drives them to migrate to HTTPS, many of them actually mentioned browser UI. So in Chrome, we indicate connection security with an icon in the address bar, and we've actually changed this icon over time to more clearly explain the risks of non-secure HTTP. So this is what our icon for all HTTP sites used to look like, and this was a problem because it did not give users a warning, did not communicate the risks of using non-secure HTTP. We would like to represent non-secure HTTP sites with this scary, dangerous triangle icon, but if we were to introduce this icon right away on all HTTP sites, we think it could actually cause harm. When users see warnings too many times, it's proven that they'll get what's called warning fatigue where they stop paying attention to warnings. So we don't want to introduce warning fatigue, plus we don't want the internet to seem like a scary place. We don't want people to be afraid of using the web or to stop using the web. So we're on a mission to be honest without inducing chaos and panic. So we have a plan to slowly introduce browser UI so that we can balance exposure to the warnings while gradually increasing honesty about HTTP. So in January of this year, we began showing warnings on HTTP pages with password or credit card form fields. And we chose this as a first step because there's limited user exposure to HTTP password and credit card pages, so there's really low risk of warning fatigue. And also because it's conceptually pretty understandable to users that there might be some risks involved with transmitting a password or a credit card online. And we did see great impact from this change. In Chrome Desktop, we actually saw a 23% reduction in the fraction of page navigations that include password or credit card forms over HTTP since we've launched these warnings. So we decided that we're ready to take the next step. So I'm happy to announce that starting in October with Chrome 62, Chrome will show this not secure warning in two additional situations. First is when users enter data on an HTTP page. As shown here, the warning will expand when you type into an HTTP page. In addition, we also think that when you're browsing the web in Chrome's incognito mode, you might want to know when your connection isn't actually private to others on the network. For those that are not familiar with Chrome incognito mode, it's a Chrome privacy feature that opens a new window where Chrome won't save your browsing history, so others who might use your device won't see that activity. But it doesn't change whether your connection to those sites, HTTP or HTTPS, are private to others on the network. So in Chrome 62, it will show the not secure warning on all HTTP pages visited in incognito mode. So we hope that these gradual changes will help users to understand the risks of non-secure HTTP. And we also hope that announcing the change ahead of time gives sites that are still HTTP ample time to migrate before users start seeing the warning. So we've talked through cases from CNET, from Rockerton and from Trivago, who've shown real world examples of smooth HTTPS migrations. They've shown how HTTPS can help unlock amazing capabilities to create awesome features that delight users, that help their business, and that help protect their data. And finally, we've talked through some upcoming changes in Chrome that will help users to understand the true lack of security in HTTP connections, and that hopefully will help bring us even closer to ubiquitous HTTPS. We're in an HTTPS-first world, but we're not all the way there yet. So if any of you work at a company with a website and your site is still HTTP, I encourage you to go out there and start planning what it means for your website to migrate to HTTPS. If we continue working together, we can make the entire web secure by default.