 Hi, everyone. My name is Emily Schechter. I'm a product manager on the Chrome security team. And today, I would like to take you on a myth-busting journey about the protocol we use to send and receive data on the web over a secure connection. And that's HTTPS. And I think this is one of the most important topics for a web developer today. So our story begins on a dark, creepy night in 2010. Imagine that in 2010, you're sitting at your computer. You're surfing the web. You're getting sucked into a YouTube hole. You're watching the Twilight Saga trailer, or maybe that double rainbow video, or one of the other popular YouTube videos in 2010. And you fall into a deep sleep, so deep, that you don't wake up until today, until 2016. And you look around at the web today, and it looks pretty different from the way things were in 2010. Today, we have things like add to home screen, which lets sites behave more like apps. And we have push notifications, which help you keep engaged with your users, keep them coming back. And we have cool new APIs, like device orientation and geolocation. All these cool things around today that let you build progressive web applications, that let sites do all of the cool things today that they really couldn't have done in the past. So these things are very powerful features, but there are also a lot of responsibility, right? Take geolocation as an example. If a site knows where I am, it also knows where I work, where I live, where my friends live, maybe where my children go to school, where my doctor is. That's a lot of stuff for a site to know about me, right? So if you woke up in 2010 to find this very powerful web, you might be surprised to learn that there are still websites out there where you can make a purchase with your credit card or send a private message to a friend or research a sensitive medical condition in such a way that an attacker eavesdropping on the network can see all the data that you're sending back and forth. Or you might be surprised to learn that there are still websites out there that spend tons of money and time and energy crafting the perfect user experience only to deliver that perfect user experience and have some ISP or Wi-Fi provider or some other intermediary to inject really ugly, obnoxious ads like this. And this isn't a hypothetical. We actually see major ISPs doing this ad injection all the time. And if this was your site, you'd probably be pretty upset, right? Because this interferes with that perfect user experience. It might be disrupting your revenue streams by blocking your own nice ads. And worse, it might actually trick your users to downloading and installing malware on their computers. So if you woke up in 2016, you might hope to wake up to a web where data is protected from this kind of snooping and tampering from the very beginning. And that's what we get with HTTPS. That's what this green lock signifies. And in 2016, we're hoping to move towards a web where this green lock is so ubiquitous that we might not even need to show it at all because it's just the bare minimum security that we've come to expect for any site on the web today. So this green lock signifies three main security properties. First, identity. When you type HTTPS Google.com into your browser, your browser receives a cryptographic proof of identity called a certificate from the server. And the browser uses that certificate to prove that it's talking to the real Google.com, not some other fake site who's pretending to be Google.com. So when you type a URL into your address bar, the browser gets a proof that that's the real domain you're talking to. Next, confidentiality. Once your browser knows that you're talking to the real Google.com, both those parties, the browser and the server, have a guarantee that only they can read the data that's being passed between them and not any other friendly person 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 see is what the other party receives. So an intermediary in the network can't modify or tamper with the data that's being sent. Only the browser and the server can. And that's what we get from HTTPS. But you might also have some other associations in your mind with HTTPS. When you see this green lock, you may think that it represents a financial burden or a performance cost or a lot of maintenance, or it's really difficult to set up. And many of these associations actually were true 10 or 15 years ago, but many of them are no longer true today. And that's because people all over the world and all throughout the web ecosystem have been interested in promoting a safe future for the web where HTTPS is everywhere. So in this talk, what I'm going to do is tell you four stories about HTTPS, try to separate fact from fiction, show you what might used to have been true in the past, but is now becoming a bit of an HTTPS myth, and try to convince you that HTTPS is both possible and important for every site on the web today. So my first story is about a web developer named Alice. And Alice runs an online travel guide. You can see it here. It's a very cool, awesome travel guide. But it doesn't have any privacy or security-sensitive content. Like it doesn't have a login page. You can't make any payment transactions. And so Alice doesn't think of her site as something that would require HTTPS. But one day, Alice is talking to her friend. And her friend says that on her computer, Alice's travel guide is really slow and sluggish. And Alice is like, OK, that's weird, because on my computer, it's really fast and snappy, because that's the way I built it to be. So she goes to her friend's house, and she checks out what's going on. And you can probably guess what's happening. She sees a bunch of terrible, slow ads plastered all over her site. So this is ruining the experience that Alice has built. It covers up her own lightweight unobtrusive ads. And Alice's friend trusts Alice's site, so she clicked on these ads. And when she did, she didn't expect to get the malware that she downloaded onto her computer. And this is natural, right? A user who sees terrible ads on a site blames the site for that terrible experience. So Alice is pretty sad about this, as you would be, I'm sure. And to console herself, she starts working on a new feature. And let's say this new feature is using the HTML geolocation API to suggest fun travel stuff to do based on this user's location. But as she goes to implement this feature, she goes to try it out in Chrome, and she sees that it doesn't work. And the reason that it doesn't work, as you can see in this error message in the developer console, is that Chrome and other browsers are starting to remove support for powerful features like geolocation when they can't be safely used over non-secure HTTP. So in order to use the geolocation API, your site needs to use HTTPS. And there's a good reason for this, right? If I'm going to trust Alice's site with my location, I need to know that I'm talking to the real Alice's site, not some other site pretending to be Alice's site. So we need that identity property of HTTPS to be sure that when I grant a site access to my location, I'm actually talking to the site that I trust with my location. So Chrome and other browsers, as I said, are not limiting this to geolocation. There's a list of features that have already been removed when accessed over non-secure HTTP. And there are a few more that are coming down the pipeline. I want to call out AppCache specifically, which is coming up next, and longer-term EME. We actually don't have specific public timelines for these yet, but they are coming up next. And we'll be sure to be responsible when announcing timelines. We'll add a notification in Chrome Dev Console. But if you are relying on AppCache or EME over non-secure HTTP, we encourage you to start thinking about HTTPS now before it becomes an emergency. So what about service workers? Service workers are amazing. As you've been hearing today, my love for them is represented here by these sort of bizarre, blobby, Android, hard eyes emoji. They're the secret superheroes behind progressive web apps that enable performance in the face of sketchy network conditions. Service workers sit between the browser and the network, so they actually manage every request that comes through. And as you can imagine, Alice, as a site owner, needs confidence that she is the one managing those requests. They're not being controlled by some other super-friendly person on the network trying to enhance your browsing experience. And this is why service workers require HTTPS. So Alice realizes, after all that, that in order to build a progressive web app with the features that she wants, and in order to guarantee that the user experience she builds is the one her users receive, she needs to use HTTPS. And this is why we think that it's important for every site on the web today to use HTTPS, even if the site doesn't seem immediately privacy or security-sensitive. So this story is fiction. So our next story is about performance and a data-driven guy named Bob, who's done some careful testing, some AB tests. And he has found that reducing latency, reducing the time it takes for a user to load a site, is crucial for optimizing conversions on his site. So the faster his page loads, the more money he makes. And Bob has heard some not-so-nice things about HTTPS and performance. Yell.com is an online business directory that recently made the switch to HTTPS. And they recently published a blog post describing their move to HTTPS. And what's interesting is that they did experience some negative performance results. And on the other hand, Google moved Gmail to HTTPS way back in 2010 with basically a negligible performance impact. So Bob is wondering what's going on here? What's the discrepancy between these two stories? So let's dig into some of the reasons for this discrepancy and try to figure out how you can move your site to HTTPS without a performance hit. So first, let's look at a simplified view of what it might take to send an HTTPS request. And here I'm highlighting some of the network latency imposed by the extra round trips between the browser and the server created by using HTTPS on your site. So first, there's an HTTPS redirect. If you follow a link to an HTTP page, the server says, actually, that's moved to the HTTPS version. Next, the browser and the server do what's called a TLS handshake, where the server presents that cryptographic proof of identity, which is called a certificate. And that sets up the HTTPS connection. And finally, the HTTP request is made. So it turns out that if you dig into what it takes to communicate over HTTPS, there are some technical optimizations that you can do to reduce latency. So let's step through this again and see what we can do to optimize at each step. So first, there's that initial HTTP redirect to the HTTPS site. Strict transport security, or HSTS, is an HTTP header that helps you avoid redirects from inbound HTTP links to your site by telling the browser, only access my site over HTTPS for some period of time. And you can set this period of time yourself and you're committing to supporting HTTPS for that period of time. And so HSTS helps improve performance by avoiding that redirect round trip. So the next two round trips are used to set up the secure connection over which the browser will send the HTTPS request. And this is known as a TLS handshake. So let me interject here for a moment to tell you that as a product manager and an all-around friendly person, I shake a lot of people's hands. And there are some really terrible handshakes out there. First, there's that bone crusher handshake, which just cuts off all circulation to your fingers. And then there's the sweaty palm, which is just brutal. There's the dead fish, which honestly just makes me depressed. But the worst kind of handshake is the person who grasps your hand and kind of shakes it and then just looks at you and continues shaking and keeps looking at you and keeps shaking and shaking because it's just incredibly awkward and it just takes such a long time. So the moral of this story is you have to make your handshake as short as possible to get onto the really interesting part of the conversation. So normally, the browser and the server are doing one of these long, terrible handshakes. And the browser is waiting for this TLS handshake to be completed before it sends the HTTP request. But this is actually not necessary. You can actually remove handshake latency by sending the HTTP request in the middle of the TLS handshake. So after the certificate is received from the server, but before the TLS handshake is completed. So it will look like this. And this is called TLS false start. And you can turn it on in your server software and it removes a round trip from the handshake latency. And if the browser and the server have spoken TLS before, the browser can remember a session ID. And the next time it goes to make a TLS connection, it sends that session ID, which allows the browser to shave off part of the TLS handshake. And this is called TLS session resumption. And it also allows you to shave off a round trip. And if your server supports it, you should turn it on. So now that we've talked about optimizing that first redirect and optimizing some of the round trips in the handshake, let's talk about sending the actual HTTP request. And this is where things really get cool because this is where HTTPS unlocks some pretty dramatic performance improvements in the form of HTTP2. This is the next version of HTTP, which is now supported in many browsers, including Chrome and Firefox. And using HTTP2, you can do really cool things like multiplexing and server pushing, which majorly optimize performance for HTTP requests. And Serma is actually going to give an awesome talk on HTTP2 that dives into these details right after this talk. So please stick around for it if you're interested in more details. So I mentioned that HTTPS unlocks the mouths of browser performance wins of HTTP2. And what I mean by that is that browsers have said they are only going to support HTTP2 over HTTPS. So if you want to use HTTP2, you have to use HTTPS. There's a practical reason for this, and it's compatibility. So there are some intermediaries, like proxies, that are likely to get confused or, in some cases, actually break things if they see HTTP2 traffic, because it just looks so different from normal HTTP1 traffic. So we need the confidentiality guarantees of HTTPS to be able to support HTTP2 without actually breaking anything. So if we go back to yell.com, that online business directory that Bob read about and was unhappy to see that they had negative performance impacts for moving to HTTPS, it turns out that most of their performance impacts were mostly due to outdated load balancers that they couldn't update at the time and they couldn't actually turn on HTTP2, but they're planning to upgrade to HTTP2 in the future. And we have hope for yell.com because of stories like weather.com, who saw a small performance impact from moving to HTTPS, but it was then majorly blown out of the water by the subsequent performance wins of moving to HTTP2. So in the end, since Bob is in a position where he can update his server software and turn on some of these optimizations, he shouldn't see any performance impact from HTTPS. And if he does, he should be able to far outweigh it by moving to HTTP2. So we have to update the way that we talk about HTTPS and performance. HTTPS is now necessary for achieving the best the web can offer. And HTTP is underperforming. So how many of you work at startups? All right, a few? Awesome. So my next story is about a startup that might be something like yours. So Charlie has an idea. It's about messaging with friends on the web. And she raises a bunch of venture capital funding for it. But these days, Charlie's startup is kind of running out of money. And the VC market has gotten a little bit tighter. So she needs to make sure that every dollar she's spending is going to a good cause. And she's heard that HTTPS costs money, maybe money that she can't afford. Now, money is sort of part of all of these stories in some way or another. I talked about performance, which kind of boils down to money. And next, I'll talk about ad networks, which is about money. But in this story, I'm going to focus on two aspects that Charlie is particularly concerned about. Those are certificates and search ranking. So first, these cryptographic proofs of identity certificates. When you need to get a certificate, traditionally, you buy it from an organization called a certificate authority. You prove your identification to the certificate authority, and it gives you a certificate that you use to prove your identity to browsers. You might wonder how much these certificates cost. Well, it's certainly possible to pay a lot of money for certificates. You certainly don't have to. A project called SSLMate has, for many years now, been offering standard SSL certificates at $16 a pop. And you can also get one of their more advanced options, multi-host SSL, or multiple certificates. And even if you need one of these, they really shouldn't break the bank. And there's a newer project called the Let's Encrypt, which actually offers free certificates. And both of these projects, SSLMate and Let's Encrypt, offer automated command line tools that help you buy and manage your certificates automatically so they don't expire, you can set up configurations, other tasks like that. So certificates are not going to be the reason that Charlie's startup runs out of money. The other thing that Charlie's worried about is search ranking. You can imagine that if you move your site to HTTPS, search engines might get kind of confused. And you might lose search ranking, because kind of a traditional nugget of wisdom is that having two different versions of your site can have a negative impact on search ranking. So Google, in particular, has a few best practices that you should follow when moving your site. And here I'm going to talk about the basics. So the first thing you should do is serve 301 redirects to show search engines that your site is at the HTTPS version. And once the search crawler gets to the HTTPS site, it's important to serve these canonical link elements to reinforce the idea that this is the canonical version of your site. And there are a few other best practices that you should follow. Three up here, and I encourage you to go check out these resources after the talk. So if you do your research and follow these best practices, you can expect a minor fluctuation in search ranking, which happens any time you make large changes to your site. But you'll then recover back to your normal levels that you had before the transition. In fact, Google even does have a search ranking boost for HTTPS sites. So it's actually considered a positive ranking signal. At present, it is pretty small, so you probably won't notice a large boost. But it's possible. We're hoping that might change in the future. And it is a small positive signal now. So in other words, if you follow best practices, take a little time to do research before moving your site over, the financial costs for certificates and search rankings should be negligible. So my final story about HTTPS is the story of Francisco and his adventures with third-party content. I'm sure that many of you have lots of third-party dependencies on your site. So let's say that Francisco runs the website for a major news corporation. And that means he has a large site with a lot of articles, a lot of legacy content, many different types of third-party content to worry about, like old images. And he's heard that if you move to HTTPS, all of your content, including the third-party content, also has to be served over HTTPS. So it's easy to see why this might freak Francisco out a little bit, because it's true that when you move to HTTPS, you're going to also have to start to think about whether all your third-party content is available over HTTPS. First and foremost, Francisco is worried about ads because he runs a publisher site, and ads is how he makes all of his money. So Francisco is wondering whether his ads will be available over HTTPS. Well, something that has changed in the last year or so is that for Google AdSense and AdExchange requests, they're always served over HTTPS for most users. So even before Francisco has served his site over HTTPS, his AdExchange or AdSense ads are already being served over HTTPS for most users. So he shouldn't have to worry about this. And the exception here, why I'm saying most users, is actually only for users located in countries that actually block or degrade HTTPS traffic. And this isn't just a Google thing. It's actually an industry-wide trend. In 2013, the IAB, the Interactive Advertising Bureau, published this blog post saying that nearly 80% of their member advertising systems support HTTPS, and they underscored their commitment to getting all the way there to 100%. So this is one of those things that I talked about, where five or 10 or 15 years ago, pretty much no ads were being served over HTTPS. So this was a major issue. But now the entire industry is changing. And in this day and age, serving ads over HTTPS really shouldn't be a blocker. And if you're using an ad system that doesn't support HTTPS yet, it's probably on the roadmap. And if it isn't, you should ask them why not. And you should tell them I said why not. So the next type of third-party content that Francisco is worried about is the partnerships that he has with other sites that depend on the HTTP refer header. And what this means is that other sites can tell that the traffic came from Francisco's site. In other words, Francisco's site has referred the traffic to those other sites. So Francisco might get some money for this. And the problem here is that if a user follows a link from an HTTPS site to an HTTP partner site, browsers will strip their refer header for privacy reasons. And that makes sense, because if you're doing something sensitive on an HTTPS site, the URL that you're on might be sensitive information. And the browser shouldn't just leak that in plain text over the network to an HTTP site. Fortunately, there's a web platform feature called refer policy that helps with this. And Francisco can set a refer policy to allow his partners to see that traffic is coming from his site, but they won't see the full URL that the user was visiting. So user privacy is still somewhat protected. Finally, Francisco is losing sleep over a kind of general problem called mixed content. And mixed content is the problem of loading non-secure HTTP content on an HTTPS site. And this is important because non-secure sub-resources can actually compromise the security of a secure HTTPS site. So if you try to load insecure scripts or iframes or other active content like that on an HTTPS site, browsers will actually block it, because that content is just too powerful and would completely wipe out all the security of that HTTPS site. So Francisco's site, it's a news publisher, so it has lots of old news articles that link to third-party images that aren't available over HTTPS. And we call these images passive content, and browsers will still allow them to load so the site won't be completely broken, but that green lock does go away. And Francisco's really not happy with this because he wants his green lock that he worked hard for. Fortunately, Francisco can serve what's called a content security policy to receive reports about mixed content. This header is basically a way for Francisco to assert to the browser that all content should be loaded over HTTPS, and he wants to receive reports about any content that isn't. And that allows him to go find and fix mixed content on all of his millions in pages, which means that he doesn't have to rely on users to report broken behavior. He'll be able to find and fix problems as soon as they arise. So in this case, the CSP says all content should be loaded with the HTTPS scheme, but inline and dynamically generated scripts are OK. And send a report to this URL whenever content violates this policy, but don't block content, only report it. And if you don't want to build infrastructure to collect reports yourself, I suggest this awesome service called ReportURI.io, which gives you some cool data visualizations. And for all of these issues, in Chrome, we recently launched the DevTool security panel to make it as easy as possible to find and fix problems with HTTPS configurations, such as these mixed content problems. So Francisco's story is true in that third party providers must support HTTPS in order for you to move your site over. But what's new, what's changed in the past few years, is all of these new tools and support in the ecosystem and in the web platform to help you upgrade your third party content. So when I look back at these four stories about HTTPS that I told you today, I think there's one kind of moral that emerges. And that moral is that five, 10, or 15 years ago, HTTPS used to be kind of slow, kind of expensive, kind of a pain set up. But these days, in 2016, browser vendors, web developers like yourselves, server software developers, security researchers, the whole wild, wild west of the online advertising ecosystem, all of these people have come together to make HTTPS a lot faster and easier and cheaper and all around better than it was in the past. And HTTPS is necessary for unlocking the best the web has to offer in terms of both capabilities and performance. And that's why we think it's both possible and really important for every site on the powerful web today to use HTTPS.