 I'm Carlos. I work in Security UX in Chrome, and today I'll give the Security 101 or Intro to Security class session. First of all, I want to say I adopted these slides from some made by Chris Palmer and Emily Stark. So thanks, Emily and Chris, for giving me the starter slides to begin with. With that being said, today I'm going to tell you a bit about the security architecture and the guiding principles for Chrome. And then I'll give you a quick overview of what it's like to work with the security team. And what are the cases where you will likely work with the security team. And then we'll have some time for questions at the end. There should be plenty of time, but if anything goes unanswered, I'll get to the questions in the Dory or someone else in the security team will get to the questions in the Dory before. With that being said, that's the link to the Dory if anyone has any questions or ones that you want to add in the meantime. OK, so first I'll talk a bit of a general security principles, and then we'll talk about how they apply to Chrome. So in order to understand what a security mechanism is, we have to understand what trust is. And the main thing here is that when you trust an entity, it can break your expectations. So if you don't trust an entity, there's nothing to break. But once you start trusting it, it can break that trust that you're giving it. And then a security mechanism has to do at least one of those three things that you see here on the slide. And ideally, a good security mechanism should not regress any of the other ones. Unfortunately, not everything that's sold as a security mechanism is a net positive. That is, some will do one of these things, but then regress that to a point where you're worse off than where you started. Much of this slide deck will discuss how we try to do these things in Chrome. So let's start with the definition of security. It's the system behaves correctly the way that stakeholders expect, even when it's being sabotaged. That is, even when someone's trying to make it not behave correctly. This is hard, because correctness to begin with is hard, and security is just another layer of more hardness on top. So the work that we do is a bit fun. So I'll talk a bit now about how this applies to Chrome. So let's go back to the definition. So in the case of Chrome, we have multiple stakeholders. We have us implementing Chrome. We have the users, and we have websites, and we have other stakeholders. So how do we decide who we focus on? Well, we go by the HTML design principles of the W3C, which is users over outers, over implementers, over specifiers, over purity. If you take one thing from this slide, it's just that we try to focus on keeping the user safe over everything else. And then we follow this order, if need be. Our goal as a security team is to establish Chrome as the most trustworthy implementation of the open web platform. That is to comply with all the OWP security mechanisms to implement them correctly, and to try to be the least buggy, or the least likely to let attackers harm you. So now that I mentioned the open web platform security mechanisms, I'm going to talk a bit more about those and define the web security model. The web security model is actually kind of crazy. The web security model aims to enable you to visit any website and allow the website to run code on your computer JavaScript code to be specific. And even if the site is under control of an evil attacker, or if it's either because it's just owned by an attacker, or because it's compromised right now, we aim to let you navigate away or close a tab and escape completely unharmed. This is what makes web applications very powerful, and also makes them potentially very scary. So each website should then be able to influence anything beyond its own control, and any resources that you explicitly give it. Downloads will be an exception to this, because downloads do persist in your computer and can cause lasting harm. In the case of downloads, Chrome tries to protect users by giving you enough information to decide whether or not you should download from that particular site, as I'll talk in a bit of the later slides. So this is something that makes the web as on as a platform, but it's also something that makes working on browser and web security important and very challenging. So how does Chrome manage this feed? Well, the fact that the code is managed is a big part of it. In this case, managed means that the code is memory safe, the JavaScript is memory safe. In theory, at least, as you can see, if you attend security 201, there are bugs sometimes that make this not to be the case. The code is garbage collected, and the code is not arbitrary machine code running your computer. That is, it's not native code running your computer. It's running towards Chrome, and Chrome can decide what runs and what shouldn't. Besides being keeping the code safe, there's also a thing that's called the same origin policy. What is this? Well, it's a form of isolation between websites. If you go to some website.com, which might be evil, it can read or manipulate data or state from any other website, like, say, Google.com, nor use permission-gated APIs that you run it to Google.com. In this case, the browser is responsible for enforcing this isolation. The spec defines the isolation, but each browser is responsible on implementing it correctly. Since I mentioned origins, I'll take a bit here to explain what an origin is. An origin is just a combination of the URL scheme, that is, HTTP or HTTPS, the host, and the port that it's running on. And unless all of these are equal, we consider two URLs to be different origins. So in the slide, you can see a few origins that look similar. Well, for the first three, they look similar, but are actually treated as completely different origins for security purposes. So one of those will then be able to access resources from the other. OK, so all this isolation is great. Oh, excuse me. All this isolation is great. But we also, so even if this is implemented correctly, we also have to assume that there are attackers in the network. And in the presence of network attackers, we have at least two problems. For one, we can have passive attackers that can read anything you send to the server, anything that sends back to you. The server sends back to you. So that is, they can eavesdrop on all communications. And we also have active network attackers, which we usually call person in the middle, that can alter anything you send to the server or anything the server sends back to you. That is, they can impersonate other servers. They can impersonate data that you're sending to the server and the like. And on the internet, we have to assume that these network attackers are always present. And realistically, they likely are. In particular, you can get from these that active attackers, that is, those that are acting as a person in the middle, can sever the same origin policy. They can also do whatever they want with the resources from just one origin, because they can pretend to be that origin as we'll talk about in a minute, which has very deep implications for user permissions for anything the user grants to sites. We'll talk a bit more about how it affects that later. So what do we do to protect ourselves against these network attackers? Well, some URL schemes like HTTPS for websites and WSS for web sockets use transport layer security, which we'll describe, to provide three benefits. Those are server authentication, data integrity, and data confidentiality. The TLDR is server authentication is proving that the server you're talking to is the server that you think you're talking to. Data confidentiality is preventing any eavesdropper or any passive attacker to see the data. Again, data integrity is preventing any active attacker from actually manipulating the data and changing what you get from the server or what you send to it. How does this work? Well, with cryptography, TLS will only expose ciphertext to the network attacker. That is, they can still see what you send to the server, but they just can't understand it or read it. In a similar vein, an active attacker, they can still alter the contents that are coming from the server or that you're sending to the server, but we will detect that the contents have been modified and just drop the connection. So we can prevent those two things, but we can just make them completely pointless. And I'll go a bit more into how the server authentication works in the following slides. So how do they work? To get some clues, let's look at the security panel in depth tools, which is what you can see in this slide. If you click that button that says, does that work? Yeah, be a certificate there. It takes you to these. I wasn't able to resize that, so it looks a bit small, but focus on the part on top where it says certificate hierarchy. That's the certificate chain. And a certificate chain is just a string of certificates which is signed and vouched for the next one. So a certificate contains a public key, metadata, but how the key is to be used, and a signature proving that someone else, in this case, the previous certificate, believes that the metadata that someone else believes that this data is true. So in the case here that I'm showing, the one up top is GeoTrust Global CA. That one comes with the operating system, in this case. That one trusts Google Internet Authority, and Google Internet Authority trusts any site that Google.com. So the shame of trust is, you trust your operating system certificate store because you have to because that's where the trust starts. Your operating system vendor trusts the operators of GeoTrust to issue certificates for any site on the internet. That's where they include it. The operators of GeoTrust themselves trust the operators of Google Internet Authority to issue certificates for any site on the internet. And finally, the operators of Google Internet Authority trust the operators of anything.google.com. In practice, Google Internet Authority will not, and as far as I know, has never issued certificates for any site on the internet, just for Google properties. But the operators of GeoTrust have to trust Google Internet Authority to sign certificates for any site, because there's no technical enforcement that Google Internet Authority will never issue certificates for any other site. So your operating system trusts many trust anchors or root CAs that come included with the operating system. But there is a problem. Like I mentioned, any of them can sign certificates for literally any website, even if the website does not want their certificates issued by that certificate authority. And as you can imagine from what I'm showing here, this has happened. Sometimes it's a legitimate CA that is compromised. Sometimes they just make a mistake. And other times the platform vendor proves untrustworthy and includes some issues trust anchor in the platform. So what can we do about this? Well, one approach to the problem that was actually invented here at Google, excuse me, is to have the browsers require that any issuance of certificates occur in the public view and leaves an audit trail. That way, any attacker that wants to use mis-issuance, they just create a trail. And the mis-issuance is likely to be more caught fast in the certificate revoked. We call this certificate transparency. The goal is to have any issuance occurring at least one public log and then have browsers check for proof that certificates are in at least one public log before accepting a certificate and just rejecting the certificate and dropping the connection otherwise. The logs are cryptographically verified, and they are append-only, so there can be no tampering that is a certificate going to be included and then removed from the log without breaking the integrity from the log. The example here is what certificate transparency logs know about PayPal.com certificates. So you can see all certificates that have been issued for PayPal.com. OK, so back when I started talking about why this is important, I mentioned user permissions. So let's go back to that and as to why HTTPS is important and transport security is important in general. So you can see here the certificates that you grant any site. Here are a few of them in the page info panel. Most of them are actually not meaningful unless you're granting them to a secure origin. If you're granting them to a non-secure origin, you're pretty much granting it to any origin. That is, if you grant something like, say, use of your location to http.httpexample.com, any site could abuse the fact that you trust this site. Well, any attacker can abuse the site that you trust this site, many in the middle of it, and then just use the fact that you trust it to gain access to whatever you trusted it with. That's why we say they're meaningless. So for this reason, Chrome is heavily invested in the adoption of HTTPS across the web and has been pushing more sites to move to HTTPS. Improving HTTPS adoption is an ecosystem-wide project. It's not something that Chrome can do by itself. For our part, we built developer tools, browser UI, and analysis tools to tackle this problem, to convince sites to move to HTTPS. Fortunately, HTTPS usage is slowly but steadily rising. And you can see in the right on the graph that it's now hovering around 70% across all platforms, which is a fairly large increase from 2015. So what does this mean that we're pushing for HTTPS usage for you as a Chrome engineer? Well, if you're building a new web platform feature, consider how an attacker might abuse it, and consider making it only available to HTTPS sites. In fact, this is an actual policy, as you can see in the screenshot, that features that we classify as powerful have to be limited to secure sites only to protect the users. If you remember, when there's an active network attacker, any non-secure origin is essentially one big non-secure origin, because any attacker can just change the data to be whatever they want. So this means that if a user trusts HTTPExample.com, as I mentioned, with your location, the attacker can just get it. Moreover, an attacker can combine all the permission-gated APIs that you've rented to different HTTP sites and just abuse all of those to get literally all the permissions that you've rented to any of them. Sorry. Yeah, so in order to prevent that, we try to limit powerful features to HTTPS only, and this will come up when your feature is going for a secure review, as I'll talk a bit more about that later. OK, so let's go back to Chrome and talk about how these mechanisms are implemented in Chrome. So enforcing an ambitious security model, like the one that I talked about, requires defense in depth, because Chrome is millions and millions of lines of C++ code, and we have to assume that there are bugs in the code. And in fact, there are bugs in the code. And some of those bugs will be in the way that the browser parses, runs, and renders sites. That is, parses the HTML or runs the JavaScript. For example, the JavaScript engine might have a bug where it allows a window from one side to control contents in the window from another side, which is clearly not allowed by the same review policy that I talked about earlier, even though that shouldn't be allowed. Or the HTML parser might have a typical memory corruption vulnerability, like a buffer overflow. So a malicious site can serve HTML that allows them to run native code in your computer. If you want to see an example of this, you can go to the Security 201 presentation that Adrian will give today in the afternoon, where he will go deeper into how this is possible. So one of the ways that we try to limit the impact of any of such bugs is through process isolation and sandboxing. What are those? So Chrome is actually made of many operating system level processes. Sorry, my screen is weird. Chrome is made of different operating system level processes, and the content like HTML and JavaScript runs in what we call renderer processes, which are sandboxed. That is, their privilege level is limited. So if an attacker gains control of renderer processes, the effect that they can take in your computer is much more limited. They are limited in things like installing software or doing arbitrary network requests. As opposed to that, anything that runs in the browser process is highly privileged and can do those things. So that is what process isolation means. That is what sandboxing means in this case. For this reason, we prefer that all code that's powerful and likely to contain vulnerabilities remains or anything that deals with untrustworthy inputs remains in the renderer process as opposed to the browser process. One thing here is that browser processes and renderer processes can communicate through IPC or inter-process communication. We have to be very careful when designing these messages, because if we allow the browser process to act on the renderer on behalf of the renderer process and the renderer process is compromised, this will cause the browser process to pretty much run any code in the compromised process once it's run, therefore causing, like, losing the effectivity of sandboxing. Another way that we deal with the inability of boxing software, specifically in C++, is to proactively try to find them and fix them. One way we do that is by rewarding external reports. Another way that we do that is to what we call C++. Subteam of Chrome security works in this system, which automatically finds and reproduces bugs with fusing. Fusing is running different pieces of code with random inputs, trying to find memory corruption and other type of crashes that can lead to security issues. C++ constantly runs on thousands of cores, throwing all sorts of test cases to Chrome and looking for those crashes that I mentioned. Those test cases can be generated randomly or they can also be evolved from a set of C++ cases, therefore evolving the coverage and increasing the coverage over time. ClusterFuzz has already found thousands upon thousands of security bugs in Chrome, which is pretty cool. So in the course of working in Chrome, you might notice that ClusterFuzz finds a bug in code that you wrote and either a security team member triages it and decides that it's slightly related to your code and assigns it to you or if ClusterFuzz can confirm that it was caused by a seal that you landed, ClusterFuzz will automatically assign it to you. Excuse me. If this happens, we really appreciate your help in finding a fix in the bug as soon as possible. One of the core principles in Chrome is that security is the responsibility of the whole team, not just those of us working in the security team. So if you get a ClusterFuzz bug, you'll get something that looks like this report. The main thing to focus here will be the link on top where it says detail report. If you click that one, it will send you to detail report and here we can focus on the triggering circle parts here. So you can see the minimize test case one at the top. If you click that one, it will show you the HTML files that ClusterFuzz was running when it triggered the crash. So this is what you can use to reproduce the crash in your own code and try to figure out what's going on. You also see the revision range where these regress. In this case, that is the range of CLs that landed in the period where the bug regress. This is where if there's only a single CL, ClusterFuzz will automatically assign the bug to the owner of that CL. And at the bottom, you can see the crash factories. In that case, it's the series of functions calls that led to the crash. So this is also useful when debugging, especially if you happen to not be able to reproduce locally. In any case, if this is not sufficient or if you don't know how to deal with a bug that ClusterFuzz assigned to you, feel free to contact the security team and we can help you figure out what's going on. So with that being said, I wanna talk a bit about what's the difference between handling security bugs as opposed to other non-security related bugs. So if a non-security bug is a non-regression and it has already been unstable for a while, there's a valid argument that we've lived with this for a bit, maybe we're gonna live with it for a bit more and we down prioritize it and work on higher priority stuff. With security bugs, this shouldn't be the case because even if the bug has been unstable for a while, the longer it's unstable, it's the longer that our users are exposed to it and the more likely an attacker is to find it. So we have to address those as soon as possible even if we can see that it's not a recent regression. For a similar reason, with crash bugs, when crash bugs are not a security issue, if you look at the crash metrics and the crash bug is not happening very often in the wild, it's fine to say, well, this doesn't happen very often. We can work on higher priority stuff or on crashes that happen more often. With security bugs, that's not the case because even if a crash is not being hit in the wild often, an attacker can craft this HTML or JavaScript that causes it to happen and then exploits that. So we also want to address those as soon as possible even if they're not being hit much. When you get a bug that's a security bug that's reported by an external reporter, it's perfectly fine to pick on them for more data, like more better reproduction steps, your opinion on the fix, anything that you need from them because we pay those users through the vulnerability rewards program and we pay higher amounts for better reports. So it's both in yours and the external reporter's best interest to get a higher quality report in the bug. And finally, we should prioritize merging security bug fixes as soon as possible. So as soon as the fix lands, we want to start the merge process and get it merged into stable as soon as possible because the bug pre-merge becomes public the minute that you land a fix. An attacker can just see the seals that landed and try to determine if they're related to a security bug and if you have a test case that's actually a pretty much a reproduction case. So we want to merge those as soon as possible. Well, so let's assume now that we had perfect code and that everything we fix all our bugs really quickly our code never fails. We even force everything perfectly. Well, even if we had everything perfect and that was all working, the side reality is that it's still fairly easy for users to get tricked on the web and all the work that I described so far and all our due diligence and fixing bugs will not protect users if they get tricked into giving up their sensitive data including credentials, data, privileges or credit card numbers, et cetera. This example here is your typical phishing email in which a user clicks a link and then they enter their Google account password in their legitimate list changing their password when in reality they're giving the password to an attacker which we'll be able to log in as them. So what do we do to prevent those? Well, one way that we try to protect users is with safe routing interstitials like this which we show when we believe a site is a phishing site or when it's distributing malware or it's being compromised in some other way. So this one also shows a bit of what we have as our security UI design principles. You can see that we give a simple explanation to the user where they can understand, well, pretty much we believe the site is trying to trick you as opposed to something highly technical. We use what we call opinionated UI that is the safe choice in this case back to safety which just takes you back to the previous site is the most immediate and more obvious thing to click. You have to actually click advance details to get even the override available but we do have that override available because we respect users who want the override and decide that they know what they're doing in this case. I wanna highlight that we do extensive research when implementing any new security UI or when we're changing existing UI that's security sensitive to make sure that we're providing the right information to users and in the case where we're using opinionated UI we also do research to make sure that this is having the effect that we expect supposed to do the opposite effect or no effect at all. With that being said, now that we covered a bit of the guiding principles, I'm gonna talk a bit about interacting with the security team that is with us and how we can make this easier. The security team is a loose group of people that are working on many different areas of security. These are some of the security teams here on this slide. I talked about some of these teams and what they do today, but unfortunately I didn't have time to cover all the areas that everyone is working on. And as you work on Chrome, you'll have many opportunities to work with the security team and learn more about how we try to keep our users safe. And we're actually quite friendly and we don't want you to be blocked on us. So I'll try to talk a bit about how to not get blocked on us when you're working with us. So if we go back to the first section, I talked about inter-process communication and why this is important and why this has to be reviewed. So whenever you change an inter-process communication that is a Mojo message or an IPC message, you'll have to get a security reviewer's owner's approval. The main tips for this is if you get nothing else, just get the first one. Free them as any other owner for code review. Don't expect a rubber stamp once you've gotten everything else. Expect a tariff review. Definitely don't TBR them. It's not okay to send the review to like to get other approvals and then just TBR it for the security owner's approval. And yeah, this can all be summed up into treat them as any other code reviewer. Include them promptly and expect that tariff review. Another way that you'll interact with us is through security reviews. These are a part of the launch process when you're launching a new feature. And the main tip here is you want to reach out to Chrome Security early to get any design advice or any big security questions out of the way. And this is particularly important for larger features or anything that spans multiple quarters because we don't want you to work on something, finish the design and then realize that this design is not safe and will have to change or much worse spend time implementing it before realizing that it is not safe. And I wanna stress, even if you think that you're working on something that's inherently dangerous and that there's no completely safe way to implement this feature, I will still encourage you to talk to us. We might be able to find a way that's either some form of compromise or even just a different way to implement this and turn it safe. So more so if you think that your feature is inherently dangerous, talk to us early. So what are we looking for when we do those security reviews? Pretty much everything that I mentioned before on this presentation. For one, we're looking for any UX visuals and any flows and make sure that users have the informations they need for anything that's security sensitive. We're looking for any new risks that might be introduced by this feature and whether the benefits outweigh the risks and how the risks are being mitigated. So your transport just means we're looking for usage of HTTPS for anything that we deem a powerful feature. We're looking for good testing. This includes like the regular unit and browser tests and this also includes fuzzing that is adding test cases for clusterfuzz which is particularly important if you're running on a parser or anything similar to that. And we're looking for what we call the rule of two. So what's the rule of two? So we have three things and trustworthy inputs and unsafe implementation language and high privilege. You get to do two of those three, not all three. The one easy solution is to, if possible, is to get your code to run in a sandbox code that is in renderer processes as opposed to the browser process that will get the high privilege part out of the way and you'll be complying with the rule of two. A different one is to try to make your inputs trustworthy that is filter them or validate them before running them. This can be tricky depending on what inputs are because inherently anything that you're getting from the open web will be untrustworthy. So talk with the security team if you're not sure if you're validating away all the dangerous cases. The other one of those three things is unsafe implementation language. Unfortunately C++ will be an unsafe implementation language so there's no way to get rid of that part while working in Chrome with the exception of some Android only features where the code can run just in Java code in which case we could work without the unsafe implementation language but this is the minority of coding Chrome. So how to get approved quickly when you're working on a secure review. For one, we need the design doc and if you're changing any UI, we need Mox. So we appreciate if you point us to those when you're running through the review process. If you're working on a new open web platform API then we also need a link to the spec proposal or the spec change and both your design doc and the spec change if applicable should have a security considerations process section that is try to document any risks that you already know are part of your feature and any mitigations that you've already taken for those. In general, documenting the risks, finding the risks is Joe of the security team when doing the review but if you help us by providing us a pointer to those and telling us what you've already considered then we can make this smoother for everyone. And finally, show what you use for security for existing security mechanisms. One of those is having a fuzzer if you're writing a new parser making sure again that you have all tests for anything that you're running that will catch any bugs early and just in general show good use of all the recommendations that I talked about here.