 I hope you're enjoying the first day of Chrome Dev Summit. I'm an engineer on the Chrome security team. And my colleagues and I on the security team are on a mission to be honest with the people using our software about their connection security. And we need the help of you all, the developers, in this room to do that. The first way that I'm going to ask you to help us out is to do a little thought exercise where you put yourself in the shoes of an average web user. So probably not a developer. Maybe someone who is even new to computers or new to the web. And if you were this average web user looking at this omnibox, which is what Chrome shows when you visit an insecure, plain HTTP site in Chrome today. If you were this average web user, what might this omnibox say to you? You can see it kind of has the host name of the site. And it has this sort of neutral informational icon. So if you were seeing this, what would this mean about the site that you're visiting? As an average web user, you probably wouldn't realize that an attacker sitting between the web browser, between your computer and the web server can read any data that's passing back and forth between the two of you. So that could be sensitive data like passwords, credit cards, health content, all of the stuff you probably don't want an attacker sitting between your computer and the web server to read. Or as an average web user looking at this omnibox, you probably wouldn't realize that even though the omnibox says example.com, that's not necessarily who you're actually talking to. Over insecure HTTP, you don't actually have that guarantee at all. You could be talking to any attacker who's impersonating example.com. And that's probably pretty unintuitive to the average web user who looks at the omnibox and sees example.com. Really, this average web user probably wouldn't realize that any attacker sitting between your computer and the web server can modify or tamper with content that's going back and forth between them. That tampering could be to inject ads, perhaps overwriting your legitimate ads. It could be to insert some fake or malicious content. It could even be to tricks a user into downloading or installing malware. So if this was your site, with this attacker modifying or tampering with your content, this is obviously very bad for your users. They're probably getting a poor user experience. They might even be being tricked into downloading malware. And it's bad for your site. It's bad for your brand. It's bad for your revenue. You're not delivering the legitimate good user experience that you want to deliver. And these risks are real. They happen every single day in coffee shop, Wi-Fi, internet service providers injecting ads, software like FireSheep that makes it really, really easy to passively sniff on unencrypted session cookies. These things happen. They're real. They're probably affecting your users. And the way to protect your users from that is to use HTTPS. These risks are why we on the Chrome security team are on this mission to fix this UI, which we don't think is being particularly honest or forthcoming about what it means to use insecure HTTP. What we plan to do in the future is not this sort of neutral presentation, but a presentation that actually delivers a warning to the user, the risks that they're taking by using insecure HTTP. So in this talk, I'm going to tell you about our mission to use this to get to a place where we can use this warning UI to be honest with our users about their connection security and how and why you as developers should help us with that. I'm going to be telling you about some newly released metrics about the honest state of HTTPS usage in the world today. And those metrics will hopefully help motivate why and how you as developers should help us move the web to a place where it's HTTPS by default, because it's good for you and your users. It's good for your site. And it's also good for the web as a whole. And finally, I'll be previewing some upcoming Chrome UI changes that illustrate our strategy, which is to gently prod developers like you into adopting HTTPS, while simultaneously kind of using our users into the idea that HTTP is probably not what they want to be using. In the spirit of honesty, I'm going to start by telling you about a section that we added last week to the Google Transparency Report. The Google Transparency Report, if you haven't seen it before, is a collection of all sorts of interesting and useful data about Google and about the internet as a whole. And for most of this year, we've had a section on this transparency report that's devoted to HTTPS. Very interesting data, but up until now it's mostly focused on HTTPS usage at Google, so on Google services, Google traffic, and also on some of the top sites. Acting this data has been pretty encouraging. Since we launched the HTTPS section of the Transparency Report in February, we've seen 12 more of the top sites adopt modern HTTPS. But this is not necessarily the full picture, because what are the top sites? What does that actually mean for people who are using Chrome every day? That's why last week we released a new section in the Transparency Report that releases data about HTTPS usage as Chrome users see it. One of the milestones that we passed recently, as you can see here, is that on desktop platforms, Chrome users now load over 50% of their pages over HTTPS. This is a big milestone, and overall we're pretty happy about the trend here, which is that HTTPS usage, when we look at that as percent of pages that Chrome users load, slowly but steadily increasing. That's what we want to see. I mean, obviously we want to see faster increase, but slow but steady, we'll take it. Another way to look at it is not the percent of pages that are loaded over HTTPS, but the percentage of time spent. And as you can see from this graph, this is an even more optimistic way to look at it, because Chrome users spend on desktop platforms about 75% or more of their time on HTTPS. We don't necessarily know why this is for sure, but one way you can think of it is that users probably spend more time on sites like Gmail or Facebook, or you're super engaging for rest of web apps than they do when they're just googling around for some information, clicking a link, navigating away. So we think that users spend most of their browsing time on sort of heavy duty apps that, for the most part, are top sites using HTTPS. I also want to make a quick note about Android usage, which you might have noticed in both of these graphs is this green line. It's kind of an outlier down at the bottom. Again, we don't know why this is for sure, but one hypothesis we have is that on Android, this sort of serious web browsing on Gmail, Facebook, things like that, that stuff that Android users are doing in apps. So from Chrome's perspective, they see more of the non-HTPS traffic, and less of the traffic that tends to be HTTPS that Android users tend to do in apps. So again, that's just a hypothesis, but we think it kind of makes sense, and it means that as the mobile web becomes more and more engaging, as you all build and gain traction on your progressive web apps, we would hope to see this line kind of continuing to go up and hopefully catch up with desktop. So this is great news. Developers like you are adopting HTTPS. You might be wondering why. What is driving this slow but steady increase in HTTPS usage? And we can't tell you for sure, but I want to pull out a few things that we hear over and over again, anecdotally, from developers who are transitioning their sites to HTTPS. First, modern browsers like Chrome and Firefox and others are restricting usage of powerful features over insecure HTTP. Some features have already been deprecated and are already not available over insecure HTTP, and some will be restricted in the near future. So these are things like geolocation, service workers, push notifications, the payments and credential management APIs, all sorts of things that you've heard about today that you need to build a progressive web app are increasingly only available over HTTPS. So we're not doing this to be mean. We think it makes sense and that is the best thing to give our users more control over their privacy and devices and data. And I think this is easiest understood with an example like geolocation. Because if a website wants access to my location and if I grant them access to my location, then I'm giving them information about potentially where I live, where I work, where I shop, where I go to the doctor, what I do on my weekends, all sorts of things that is pretty privacy-sensitive information for a website to have. And that may be fine. I may be perfectly happy sharing my location with some website, but I can't really make that a meaningful decision unless I know which website I'm talking to. And that's exactly the guarantee that HTTPS gives you, which is why we are increasingly restricting access to these privacy-sensitive, powerful features unless the user actually knows which site they're talking to. As I said, Chrome is not the only browser doing this and just one other example is Firefox. In this blog post, they actually announced that they're eventually planning to require HTTPS for all new features. So this is something that browsers are pretty much united around the hope that it makes sense that if you're going to grant access to privacy-sensitive information or a powerful feature, the user should know which website they're granting that access to. I think this is one of the drivers behind HTTPS adoption because we hear it from developers. One example of this is the BBC, which cited these restrictions on powerful features as one of the reasons that they decided to move BBC.co.uk to HTTPS earlier this year. Another consideration that we think is behind the slow but steady increase in HTTPS usage is that HTTPS performance is getting better and better every day and it's no longer kind of the bottleneck that it maybe once was 10 or 15 years ago. What you're seeing here is a website built by one of my colleagues, Ilya Grigorek. It's called isTLSfastyet.com. TLS being the protocol underlying HTTPS. So the answer is yes, but that's not just what this website tells you. It tells you about all of the performance improvements and enhancements that are coming out every day with HTTPS and it tells you how to configure your server with them and which servers support them. So it's a great source of information about HTTPS performance. I want to draw particular attention to HTTP2, which is the next version of HTTP and offers a whole suite of web performance improvements, but it is critical in this talk because HTTP2 is only available if you're also using HTTPS. So what we hear from developers is that in the case that they do encounter some performance hit when they move to HTTPS, it can often be offset, more than offset, by the performance advantages that they unlock using things that are only available over HTTPS, like HTTP2. These are some of the things, these restrictions on powerful features, the improvements in HTTPS performance, these are some of the examples of what we think is driving this slow but steady increase in HTTPS adoption. But while things are moving in the right direction, we still have a gap to close and we need your help doing that. We need your help by adopting HTTPS on your site so that we can get as close as possible to HTTPS everywhere. And we need that. We need to be as close as possible to HTTPS everywhere. If we're going to get to the place we want to be where we're honest with our users about connection security. My point here is that if we were to tomorrow turn on this warning state that we want to have where we do this kind of scary red dangerous warning indicator on insecure HTTP, if we were to just turn that on tomorrow, it would probably be a little bit counterproductive. Users would see it everywhere, they'd see it all the time, they'd learn to ignore it, they'd have to ignore it to kind of use the web, and they'd kind of get trained to basically just not see it. So that's not what we want. We want it to be the case that insecure HTTP is a pretty rare occurrence. So rare that when the user encounters it, we can show them this warning and they will pay attention, they won't be scared or confused or habituated, they will see it, they'll pay attention and they'll understand the risks of the situation that they're in, where they don't have any guarantees against attackers reading their content or injecting malicious content or any of those risks that I talked about at the beginning of the talk. So that's what we're asking of you, we're asking you to adopt HTTPS on your site, it helps you and your users in your site and it also helps us in our mission to make the whole web more secure, to make users more educated and to make their activity on the web less of a risk for them. But we know this is not always easy for developers, it can be overwhelming and that's why we at Chrome and at Google and then other organizations are mobilizing a lot of support and investment around helping you transition your site to HTTPS. One of the organizations that is becoming critical in this movement is called Let's Encrypt. Let's Encrypt is a certificate authority, a certificate being a cryptographic proof of identity that you need in order to use HTTPS. It's the thing, the cryptographic proof that proves that your site is who you say it is. If you say yourexample.com, you get a certificate proving that you'reexample.com and that's what gives your users the guarantee that their browsers are actually talking to therealexample.com. Historically, getting certificates has not always been easy and it's not always been free. But thanks to the work of organizations like Let's Encrypt, it's now possible for you to get a certificate very quickly with no money and they also provide easy command line tools for automating the management and renewal of your certificates. So we think this is a critical part of internet infrastructure going forwards. Chrome has made a large donation to Let's Encrypt and users are funding it as well because it's becoming such a core reliable, core part of the process of running a web application that they've come to depend on. And in case you don't believe me that Let's Encrypt is here to stay, I think you can see it just in the numbers. This is a critical part of internet infrastructure that is really going to change the way that people do HTTPS, it already has. Looking internally a little bit more at Chrome and at Google, one of the ways that HTTPS sometimes worries developers is ad revenue. And if you haven't heard about this concern before, it might seem a little bit random. What do ads have to do with HTTPS? The connection is that when you move your site to HTTPS, you have to move all of your content, all of your third party resources, including ads in order for your site to work properly. So developers are often worried about having to move their site to HTTPS, needing to move all their ads to HTTPS and therefore losing ad revenue from ads that are only available over HTTPS. To help alleviate this concern, all Google-sourced ads are already served over HTTPS. So when you move your site to HTTPS, you will not have a revenue hit from Google-sourced ads because they are already available over HTTPS. And this is backed up by developers in the wild, the Washington Post moved to HTTPS recently and saw no hidden revenue from their Google-sourced ads. Another Google service that people sometimes worry about when moving to HTTPS is losing search ranking. Because anytime you make a large change to your site like this, you should make sure you follow the proper steps to make sure you don't, you minimize the disruption to your organic search traffic. These are some of the questions that people have. How to move their site? Do they do it all at once? Do they do a little bit at a time? What kind of fluctuation should they expect? And more technical aspects of the move, like what do they do with robots.txt and their site maps and how do they tell Google that they're moving to HTTPS and all those sorts of things. What we're doing in this space is expanding and improving upon documentation. And we really like to hear from developers about what their questions are so that we can answer them publicly. These two FAQs I recommend to people all the time. There are just lists of questions that people have with very straightforward practical advice answering some of the questions I had on the previous slides. And we also have a web fundamentals guide that walks you through the process of setting up and configuring HTTPS performance tuning, things like that, and also has a section on how to handle your transition from the perspective of Google search ranking. CNET was able to move to HTTPS with, as you can see, minimal disruption to their search ranking. So we are hopeful that we've improved the documentation to such an extent that if you just do a little bit of research and follow the steps and the documentation that we provide, this isn't a traumatic thing for your search ranking. It really shouldn't be nearest and dearest to my heart. And I could spend a whole talking about web platform and browser tools that we're building and sometimes standardizing and evangelizing and other browsers to help developers like you move to HTTPS. These are things that I work on pretty much every day and I just want to give one example, which is the DevTools security panel. So if you move your site to HTTPS and you open it up in DevTools and you go to the security panel here, you'll see that it's designed to basically help you figure out if you've done it right, if you have any problems, if you've made any mistakes in your transition to HTTPS, it'll help you try to figure out what they are and tell you how to fix them. These tools are ways that we at Chrome and at Google want to guide developers into using HTTPS on their sites. But simultaneously, we're planning to start easing users into the idea that HTTP is bad because we want to get to eventually a place where enough developers are using HTTPS that we can really warn users when they have a lack of connection security on insecure HTTP. And we don't want to just jolt them into that world right away. We want to kind of ease them into this association between HTTP and bad. This is the new UI treatment that we'll be using for some insecure HTTP sites in Chrome 56, which goes to stable in January. So you can see we're still doing kind of the neutral informational icon, but we're adding the not secure text to start to educate users about what it means to be using insecure HTTP. And we'll be specifically launching this for HTTP pages that have passwords or credit card inputs on them. So our goal here is to use passwords and credit cards as a signal that the user might be in a particularly sensitive situation in which they want to be particularly careful with their data and in which it's especially important to warn them about the risks of insecure HTTP. So this feature is still in development, so I want to stress that it's subject to change, but you can go try it out in Chrome Canary today. And we would love for you to do that, both to report bugs, to see what it's like browsing the web with this feature on. I find it really interesting to see what it's like a glimpse of browsing the web in the future. And also to try it out on your site and see if your site will have this UI applied to it if you're not using HTTPS yet. So to do this, you just go download and install Chrome Canary if you haven't already. Go to chrome colon slash slash flags and find this mark and on secure as flag and flip it to the option that says something about passwords and credit cards on an HTTP page. So if you do this and then you go browse around the web or browse around your site, you may see that we're doing, as I said, we're detecting when a password or a credit card field appears on the page and using that to trigger this not secure warning in the omnibox. So we really encourage you to try this out. Try out your own site if you're not using HTTPS. And if you find that your users will see this not secure warning come January, maybe you want to start using HTTPS by then. Our hope is that this does help incentivize developers like you to move to HTTPS and also starts to sort of build the association in users' minds between entering sensitive data and the lack of security of HTTP. So fortunately it's not just about negative indicators. We have sticks and we also have carrots. If you download Chrome 55 beta, we're already using this secure chip for sites that are using HTTPS. So it's not just that you'll get a not secure warning if you have a password or credit card on HTTP. If you adopt HTTPS, you get this shiny green badge next to your site telling users that, hey, you are using a secure connection. So we hope this provides some incentive to adopt HTTPS in addition to all the other benefits that you get like the privacy and security benefits for your users and the ability to use powerful features like geolocation and service workers that you get with HTTPS. So that's the glimpse of the very near future. These secure warnings for secure sites and starting to show not secure warnings which is closer to the honest truth about HTTP for some sites in Chrome 56. But this is where we're going. We hope to get here as soon as possible to a place where the web is as close as possible to HTTPS everywhere so that we can be fully honest and truthful with our users about what insecure HTTP means. One of the things that we're considering doing in the future is sort of gradually picking more and more signals. So in Chrome 56, it'll be passwords and credit card fields. Maybe in the future it might be something like when the user is in incognito mode or when the user is downloading a file over HTTP. Things like that, more and more signals to kind of gradually make an assumption that the user is in a potentially sensitive situation and warn them more and more aggressively about the insecurity of HTTP until we get to the world that we wanna be in. The theme of my talk today has been honesty. The new transparency report metrics show an honest picture of the world when it comes to HTTPS usage. It shows that we're moving in the right direction. We have a slow but steady increase, but we need your help closing the gap by adopting HTTPS on your site, which we think is good for you, for your revenue, your brand, your user experience. It's good for your user's privacy and security and it's also good for the web as a whole, the whole ecosystem, by helping us get to a point where we can be fully honest and truthful with the people using Chrome about their connection security. Thank you and enjoy the rest of the summit.