 With progressive web apps, we can create user experiences that are fast, reliable, and engaging. They can be added to the home screen, send push notifications, and implement sophisticated casting strategies. These capabilities give us a lot of power. You can do things we were not able to do before, but it also means that if they're used improperly, bad things can happen to both the site owners and the site users. Because of that, these technologies can be used only on top of communication platform that offers some fundamental security guarantees for both our sites and our users. Essential component of the secure underlying platform is the HTTPS protocol, which allow us to send and receive data in a secure way. Let's take a look at what it really means and some of the factors to consider when implementing it yourself. Hypertext Transfer Protocol, or HTTP, is a protocol used to exchange between the browser and the website you connect to. HTTPS is a secure version of that protocol, where the S at the end stands for secure. It indicates that all communications between your browser and the given web server are encrypted using cryptographic protocol called Transport Layer Security, or TLS. By showing this green lock and the word secure in the URL bar, the browser indicates to the user that the connection between the site and the user is using TLS and therefore it's safe. Having a secure connection really means three things. Identity. When you type HTTPS colon slash slash Google.com into your browser, your browser receives a cryptographic proof of identity from the server called Certificate. The browser used that certificate to prove that it's talking to the real Google.com, not some other server that's pretending to be Google.com. So when you type a URL into your address bar, the browser gets proof that it's the real domain that you are talking to. Confidentiality. Once the browser knows that you are 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 processed between them, not any attacker spying 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 modify or tamper with the data that's being sent. Only the browser and the server can. But you might also have some other association in your mind with HTTPS. When you see this green lock, you might think that it represents a performance cost or financial burden or maintenance problem. Many of these associations were true 5 or 10 years ago, but many of them are no longer true today. And that's because people all over the world have been interested in promoting a safe feature for the web where HTTPS is everywhere. My website doesn't ask the user for any personal information, so you might think I don't really need HTTPS. But by having our site delivered over HTTPS, we get protections against things like a man in the middle attack. A man in the middle attack is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. These attacks can have a very negative impact on our apps because it can be attacks on the revenue and the reputation of your site. And the worst part of it is that we may not even realize that attacks are taking place. On insecure connections, an attacker could essentially take over the control of the communications between your site and your users. Users would think they are communicating with your site, but they are not. Also, an attacker could infect your user's computer with malware, and malware is really dangerous for users and can cause immediate reputation damage to your brand. On insecure connections, we are vulnerable to third parties looking at the data being exchanged. An attacker could glove cookies with that user's credential or see other data that's crossing the network. And there's one more very important reason we must consider. Chrome and other browsers are starting to limit access to important APIs when they are not served from secure source. This is a list of features that have already been removed when accessed over non-secure HTTP. And a few more of that are coming down the pipeline. AppCache specifically is coming up next. And longer term, encrypted media extensions. We'll be sure to be responsible with announcing Timeline and adding a notification in Chrome Dev Console. But if you are relying on AppCache or EME, we encourage you to start thinking about HTTPS now. If you want to use the video or audio capabilities of your devices, your site needs to be served over HTTPS. Most importantly, service workers are amazing as you've already heard. They are the secret superheroes behind PWAs 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 you can imagine it's critically important that the site owners own their service workers. This is why service workers require HTTPS. The bottom line is that HTTPS is a critical part of delivering a good user experience everywhere. So how about the performance issue? Will all the encryption and negotiation of secure connections slow down my site? This is a valid concern, but with modern hardware and a few simple optimizations, we can eliminate the performance issues. To understand what's going on and how we can ensure fast experience, let's take a look at how an HTTPS request is made. When the user requests a page, unless they specifically want the secure version, the browser will request the page over HTTP. If your site is only provided over secure connection, which it should be, it responds with a redirect, telling the browser to request a secure page. Next comes the TLS handshake, which takes two more long trips to establish the connection and exchange keys. Finally, the browser is able to securely request a page. There are two places that can slow down the user's experience. First, there is a computational cost of generating the cryptographic keys and encrypting data. Thankfully, modern hardware has made great improvements to help minimize these costs, and what once may have required additional hardware can now be done well by the CPU. The second issue is that additional long trips require for the initial redirect and the TLS handshake. We can easily get rid of that first redirect using web security feature called HTTP strict transport security. HSTS lets a website tell browsers that it wants to communicate only using HTTPS and therefore avoids the redirect. If a browser and a server have spoken TLS before, the browser can remember a session ID. And the next time it goes to make TLS connection, it's in the session ID, which allows the browser to shave off part of the TLS handshake. This is called TLS session resumption, and it also allows you to shave off a long trip. TLS full start is an optional protocol extension that allows the client to send application data when the handshake is only partially complete. During the TLS handshake, as soon as the client received the first response from the server, it has all the information it needs to start encrypting and sending data. Combining this optimization with TLS session resumption, we can cut one long trip from the TLS handshake for both first-time visitors and returning visitors. This will also reduce the overhead of public key cryptography for returning users. Finally, HTTP2. The next version of HTTP, which is supported in many browsers, including Chrome, Firefox, Edge and more. HTTP2 unlocks some pretty dramatic performance improvements for HTTPS. Using HTTP2, you can do things like multiplexing and solver pushing, which majorly optimize the performance of HTTP requests. While it is true that HTTPS is now free by applying optimization like the ones I've shown, your site can actually get performance boost from switching to HTTP2. For example, whether.com saw a small performance impact from moving to HTTPS. When they moved to HTTP2, they saw a significant performance increase with an overall drop of 250 milliseconds per page view. With the proper planning and optimization, it is possible to have high-performance HTTPS implementations. To obtain a certificate, you needed to prove your identity to certificate authority who then provides you with the certificate. In the past, buying that certificate could be expensive, especially if you needed to handle multiple domains or wanted to get an enhanced certificate. But this is not the case anymore. So what's the cost? A project called SSL-MADE has for many years been offering certificate for $16. So even if you need multiple certificates or one of the fancier options, it shouldn't break the bank. A newer project called Let's Enclipped offers free certificates. Both SSL-MADE and Let's Enclipped also offers command line tool that help you buy and manage your certificate so that you can renew or set up configurations automatically. So certificates should not be the reason not to employ HTTPS. Some of you are worried about search linking. You can imagine that if you move your site to HTTPS, search engine might get confused and you might lose search linking because traditional nugget of wisdom is that having two different versions of your site can have negative impact on search linking. Google in particular have a few best practices that you should follow when moving your site to HTTPS. The first thing you want to do is serve 301 redirects to show search engines that the site is at the HTTPS version and once the search crawler gets to the HTTPS site it's important to serve canonical link elements reinforcing the idea that this HTTPS version is the canonical version of your site. There are several other best practices that you should follow to keep your site in good shape but we're not going to get into that. There are plenty of resources available to you. The final thing I want to look at is the third-party dependencies. I'm sure many of you have lots of third-party dependencies on your site. As you move to HTTPS all your content including third-party content also has to be served over HTTPS. When you move to HTTPS you also have to think about whether all your third-party content is available over HTTPS. Serving ads over HTTPS should not be a blocker nowadays. For example, Google's AdSense and AdExchange requests are always served over HTTPS. And this isn't just a Google thing. This is an industry-wide trend. In 2013, IAB published a blog post in which they indicated that 80% of their member ad systems are supporting HTTPS and they underscored their commitment to getting all the way to 100%. If you depend on the deferred header to get paid for traffic referrals the browser will strip that header when the user follows the link from your secure site to their non-secure site. Fortunately, there is a web platform feature called Referral Policy which can be used to set Referral Policy HTTP header to allow our partners learning an insecure HTTP to know that our site is sending traffic to them without showing the full URL that the user was visiting. So user privacy is still somewhat protected. For understanding the details of security the Clom DevTool security panel can help you. In conclusion, HTTPS will protect your users is required to use some APIs but moving to HTTPS needs some planning in order to make the move smooth. If you want to know more we have lots of resources to help you on the way. Thank you for watching.