 Hello, everyone, welcome to Chrome Dev Summit workshop. My name is Eiji, and I'm a developer advocate at Google in charge of front-end security on the web. This workshop is Gain Security and Powerful Features with Cross-Argent Isolation. And Cross-Argent Isolation has a new browser capability that lets you use Shuddery Buffer and Hypercision Timer securely. In this workshop, you're going to learn recap of how web is built, Spectre and its mitigation on browsers, what is Cross-Argent Isolation, how to deploy Cross-Argent Isolation, challenges, and improvements, and summary. I don't know how other people run their workshop in the Chrome Dev Summit, but this workshop is not like a codelab. Instead, this is going to be a presentation-style session, but have a few demos you can play with so that you can learn how things work by actually adding headers to a demo website. You can feel free to ask questions using the chat on the Google Meet. You can find the chat mark at the bottom right corner of your screen. And I will answer them whenever I find it's good time to do so. It's going to take about an hour, and in case some of you will need to leave early, I will start with a spoiler. If you want to use Shuddery Buffer, now you have two options. One, simplify your website and take all the efforts I will explain in this session to enable Cross-Argent Isolation. The second, continue the status quo and keep it available only on Chrome desktop by registering the Precation Trial, at least until Chrome 103. To learn how you will come to this conclusion, please continue with this workshop until the end. Before we actually dive in in order to make this workshop more fun and entertaining, I prepared some quizzes for you. Please go to menti.com and enter the code, or simply scan this QR code with your phone to enter the quiz website. In this session, I'm going to talk about origin relationships, such as same origin, same site, and cross-origin, cross-site interchangeably. And I would like all of you to understand what they are quickly. There are three questions. Each has four options to select from. You have 20 seconds to answer. But the earlier you select the correct answer, you get more points. It's going to be fun. So let me switch to the quiz page here. And let's see how many of you have already joined the quiz. Yeah, please let me go back. This is a QR code and a website URL. I will wait for another few seconds until you join the quiz. Please come in. OK, let me get started with the first quiz. Quiz number one. Choose one that indicates ETLD plus 1. You have four options to select from. Please pick the right answer from there. You have 2, 1, 0 times up. OK, so many of you picked the second one. OK, so the second one is ycg.github.io. It's actually the right answer. Let me explain y, let me see. So ETLD plus 1, what does that mean? So TLD, as many of you may know, means top level domains. So something like if you look at the domain, there are a few entities divided by dot. And the right most side of the entity is the top level domain, so that's TLD. Meanwhile, public suffix is a kind of registered TLD manually registered TLD. For example, like .co.jp or .github.io, which is not automatically detectable so that the list is manually curated and it's a public repository. And it's on browser so that browser can look up on this public suffix list to determine what is TLD for that domain. So ETLD means effective top level domain, meaning TLD plus public suffix. That's what is ETLD. And ETLD plus 1 means the one more entity plus ETLD, which means that, for example, google.com or ycg.github.io. If you look up on the public suffix list, github.io is there, so which means that github.io is considered effective top level domain. So ycg.github.io is the only answer you could pick from the previous quiz. And one optional hint for the next quiz is ETLD plus 1 represents a site. Let's move on to the next quiz. Are you ready? Quiz two, which one is same site to hps www.google.com? There are four options, google.com, gstatic.com, youtube.com, blog.google, which one is the same site to www.google.com? Time's up. The right answer is number one, google.com. Let's see why. The same site means, like I said, site means ETLD plus 1. So that means if you say hps.www.google.com, only the google.com part represents the site. So as long as the site part are identical, you can say that they are the same site. So hps.google.com is the same site to hps.google.com. So the right answer is the first one, hps.google.com. Then let's move on to the next question. Quiz number three, which one is same origin to hps.google.com? Which one is the same origin? google.com, hps.google.com, images.google.com, 443. Time's up. Is it a little too short? Many of you picked the number three. Yes, that is the right answer. So the trick is this, the same origin. If you say same origin, it means that three things, scheme, host name, and port number, all of them matches. All of them are identical to the other domain. Means that they are the same origin. So I said that the original question is hps.www.google.com. And the other candidates has 443 as a port number. Additionally, but if you look at the URL carefully, the scheme is hps, which means that it's using the port default port number 443. So it's implicitly has the port number 443 that they can be considered same origin. So that is the same origin. And we have leaderboard. Oh, Giorgio, congratulations. You got the best point among all. Congratulations. Let me see. Someone has asked the question. Oh, my voice is too low. Sorry, I didn't prepare any prize. Cherish hearing now. I'm using the MacBook Pro microphone now. OK, sorry about that. Let me move on to the next section. All right. So now your brain should be a bit refreshed, hopefully. Let me get started with a story about why. But before explaining why, we need to recap some basics. OK, in a browser, each tab has one URL that's displayed at the top and represents where the document the user is looking at is. This is the first part. In addition to that, it loads many resources such as images, videos, styles, scripts, fonts, and so on, including those that are hosted at different origins, which are soul parties, meaning cross-sourcing. You can load these resources and capabilities onto your website without setting up the hosting server by yourself. Cross-sourcing integration is such a powerful functionality you can bring to your website. For example, you can integrate analytics just by loading a single cross-sourcing script. You can display ads, widgets, personalized videos, and maps using cross-sourcing iframes. You can integrate soul party identity and payment solutions by using cross-sourcing pop-up windows. It shouldn't be an exaggeration to say cross-sourcing integrations is what makes the web today. But why can you say that it's safe to put resources from different origins onto your website? What if a malicious website embeds a personalized widget and steal your cookie? Why can't that happen? Of course, there are many known vulnerabilities and attacks such as cross-site scripting, C-surf, cross-site request for Jolly, click jacking, cross-size leaks, and so on and so on. There are so many vulnerabilities, but as long as you make the website vulnerability-free, the browser keeps your resources safe. That's what we call same origin policy. The browser manages interactions between origins so cross-sourcing scripts can never go beyond the border of origins. For example, you provide a video streaming service. Soul Party websites can embed it and because it's personalized, their customers can watch it there or later on your website by marking it as watch later. This is very typical. The embed is done by using iframe, but a malicious website trying to steal a cookie from your iframe will not succeed because traversing the dump tree across cross-sourcing iframe is restricted by the browser at some point. There's only minimum information available to the parent of the iframe. A similar example applies to pop-up windows. The browser keeps the boundary between cross-sourcing resources firmly. That's what the same origin policy does. However, the discovery of Spectre announced in 2018 changed everything. It's a catastrophic threat to the web that enables a malicious website to even strap cross-sourcing contents by reading their memory despite the same origin policy. Spectre exploits CPU speculative execution and browser's high-precision timer to guess the cross-sourcing contents. Because of the nature of cross-sourcing integration, if a malicious website gets your resources run in the same renderer process and traps your users there, your customers could be a victim. To mitigate the risk that was introduced by Spectre, browser vendors decided to disable some features such as shared or a buffer, and once that relies on high-precision timer to reduce the efficiency of the attack. With that, immediate threat of Spectre was mitigated, but later it's proved that the solution wasn't perfect because it's just a matter of efficiency. A better way of mitigating the risk of Spectre was to isolate the memory space part origin. That's why Chrome decided to introduce a new architecture called Site Isolation. Site Isolation makes the browser processes run part sites as much as possible rather than tabs. Because Spectre's impact is within the same process, this reduces the risk of Spectre-related attacks significantly and could revive the features such as shared or a buffer and high-precision timer that were disabled because of Spectre. Ever since Site Isolation was enabled on Chrome, it has been keeping the web on Chrome desktop secure while enabling the powerful features. As I said, changing the browser architecture is more effective way to protect websites, but the good news is you can keep your website safer by following the standard practices as well, even if you're running a browser that doesn't have Site Isolation architecture. Since this topic is out of scope for today's workshop, I encourage you all to watch the Google IEO video about web security. My colleague Camille and I run this year, but the quick gist is here. The first, control cross-origin embeds of resources with cross-origin resource policy. Second, control cross-origin embeds of iframes with X-Frame options or CSP-Frame ancestors. Number three, control communication between cross-origin windows with cross-origin opener policy. Number four, prevent malicious mime sniffing of resources with X-Content type options, no sniff. So yeah, there's a request. You paste a link there in the chat, but it's a little bit difficult right now for me to do so, but I will, this video will be recorded and will be published so you can re-watch this session, I think. So please try find the video later. Okay, what is cross-origin isolation? So far, I've explained what Spectre is and what was done to mitigate the threat. Site isolation looks like a good protection, but it depends on a specific browser architecture. Though Firefox is also trying to follow the same route, websites shouldn't rely on the browser's architecture. There should be a standardized mechanism to declare that this is an isolated, safe environment. That's where cross-origin isolation comes in. Earlier, I explained that there are HP headers to keep your origin isolated from others. It's considered safe. Then, yeah, thank you. Someone pasted a link in the chat of my YouTube video. By the way, thank you, Giorgio. Sorry, come back to the original topic. Then why not enforcing your website, isolate it from others so that the browser can safely enable powerful features such as shelter or buffer? That's the basic idea of cross-origin isolation. Note that Chrome has already shifted to require cross-origin isolation, even though we have site isolation, in order to use shelter or buffer to align the behavior with other browsers since Chrome 92. That's why we asked everyone to apply for cross-origin isolation. Then, now, here's how to enable cross-origin isolation. Two headers are required. One is co-app, cross-origin embedded policy, require corp, and the other is coop, cross-origin opener policy, same origin. Let me explain further. Cross-origin embedded policy, require corp, instruct the browser to load only the resources that opt in to be loaded with course, cross-origin resource sharing, or corp, cross-origin resource policy. There are so many abbreviations, so please catch up with me, follow me there, that shorthand acronyms. This ensures your website will not put resources loaded cross-origin in danger. Cross-origin opener policy, same origin, instruct the browser to restrict the communication with the window that opened this window or is opened by this window, so mutual communication. This ensures that they will not share its process cross-origin to protect itself from specter-related attacks. By combining coop and co-app, cross-origin opener policy and cross-origin embedded policy headers, you can declare that the webpage is cross-origin isolated and shared array buffer and high precision timers are enabled. And now, it's an exercise time. Let's try how it works using a demo site. Please open force-party-test.glitch.me and try enabling cross-origin embedded policy and cross-origin opener policy to enable cross-origin isolation. Okay, let me try to force-party-test.glitch.me so you can easily open this page. Hopefully, that's hand-pipes your is, your is collect. So if you go to the demo page, you will see something like this. Let me refresh just in case. So what you will see is that at the bottom, you will see that cross-origin isolated is disabled, right? And at the second section, you see that set various headers for the cross-origin image where there's an image circle with a check mark is displayed here. Below that is an iFrame. Within the box is an iFrame rendered from the third-party domain which is sort-party-test.glitch.me. It's obviously sort-party-origin. And finally, there's the section that explains the pop-up window. So by pressing this button, it opens a pop-up window. It's cross-origin. But if you click on this send a post-message button, you can see that the other window shows an alert, which means that the post-message message was delivered to the other window. So you could show the alert, okay? Now, let's go back to the header of this page and find the cross-origin embedder policy line here and change it to require corp. Now, let me open the DevTools first. This is hard to see. Up, enlarge the text and change corp to require corp. And let's see what happens. All right, successfully the page is reloaded. And if you look at the network panel and see the top-level document, you will see the bunch of headers here. And if you see the response header, there's some message, I will get to it later. But response header says that it's sending, sorry, it's sending cross-origin embedder policy header. It's cached, sorry. Here, you can see that there's a cross-origin embedder policy require corp with report, reporting API at the end, but I will get to it later in this session. So this is cross-origin embedder policy header attached to this document. And what has changed? If you look, go down, if you look, go down the same screen, look at that image and iframe. It's blocked, why is that? That is because we enabled cross-origin embedder policy, but we didn't get the sorparity resources opted into cross-origin resource policy. So it's being there being blocked. We will fix that later. Now, let's now change the cross-origin opener policy to same origin. And obviously the background color has now changed. And if you look at the DevTools Network panel, there's also one change that you see that cross-origin opener policy is added to the header. So both corp and corp headers are added to this page. That's why this page turned into cross-origin isolated state. Of course, this background color effect is what I made manually. So that is not happening to your website, of course. And as soon as I added cross-origin opener policy, same origin, that means that the communication between this window and the window open from it or the other window will be blocked. Which means that by opening a pop-up, let's try send a post message. And if you look at the other window, no other is shown, which means that the post message has failed. If you read this text here, it says a window is in a different browsing context, which means that it has separate processes between this window and the other window. That's why we cannot communicate each other. These windows cannot communicate each other. All right, let's go back to the slide and continue the session. Let's move on to the next step. Let's say you want to load cross-origin resources. We've seen that the image and the iframe were blocked. In that case, as I said, you will need to enable cross-origin resource sharing course or cross-origin resource policy to those resources. I'm not going to cover cross-origin resource sharing since it's old enough and we don't have much time today. Meanwhile, what corp cross-origin resource policy does is to instruct the browser to restrict the origin, the resource itself is being loaded too. By sending corp cross-origin, the resource opts in to being loaded from any other origins. For iframes, in addition to corp header, you will need to enable corp cross-origin embedded policy require corp as you did for the parent document. This makes sense because they should all declare the loaded resources are opted in. If it's nested, you will need to apply them recursively. And if you want to enable cross-origin isolation within the iframe, you will need to append allow equals cross-origin isolated attribute as well. And now let's go back to the demo site and try again. So first thing you should do is to look at the image section and let's use cores, let's try cores first. So the upper one, cross-origin resource sharing to anonymous and re-load the image and the image is displayed. Why? Because there are two things happening. One is that if you inspect the image, you can see that image HTML tag has cross-origin equals anonymous, which means that when requesting the image to the server, this request will send as cores cross-origin resource sharing. And if the server accepts the cross-origin sharing request, it will respond. So there are two things needed. So what if I choose use credentials? Anonymous means that the request will be sent without cookies, but use credentials will send a request along with cookie. So that's the difference. Okay, let's put it back and try another one, cross-origin resource policy now. Let's pick cross-origin and re-load. And the image is displayed once again. And if you inspect the image and you will see that cross-origin resource policy is properly sent, responded from the server, right? That's why it is accepted and rather decided to load the image. Note that the header is visible in the DevTools, which means that the resource itself is actually transmitted from server to the browser. It's a browser which decides whether it will be blocked or displayed even though it receives it, right? So the network process decides that, whether it should be blocked or displayed. And only when it's accepted, it is passed to render a process so that browser renders it. Okay, move on to the next section, iframe. For iframe, we will need two things. Yeah, so first thing is to obviously cross-origin resource policy need to be cross-origin, right? And re-load the iframe, still blocks the iframe. What was needed? Cross-origin embedded policy to require a corp. And re-load and boiler. It's displayed now, okay? So iframe requires two things. Cross-origin resource, policy cross-origin and cross-origin embedded policy require corp. And if this iframe document has recursive iframe, it should, the same thing should recursively happen. So they should have corp, cross-origin and require corp. And if you want to make this iframe document to be cross-origin isolated, you will have to append allow cross-origin isolated to enable cross-origin isolation within the iframe. So if you look at the iframe HTML, I have automated it, but by adding allow equal cross-origin isolated, you can enable cross-origin isolation within the iframe. Okay, let's go back to the slide. Now, we learned how things work in theory, but how would we practically enable cross-origin isolation? Before moving forward, I would like to introduce you to the reporting API. The reporting API is a foundational feature of front-end observability, and it's available to corp and corp as well, cross-origin open-up policy and cross-origin embedder policy as well. Usage is quite simple. You define endpoint name and its URL and assign the endpoint to applicable headers. This way, whenever corp or corp encounters a violation, the browser will automatically send reports to the endpoint. Violation as in images or any resources being blocked or the communication is blocked, things like that. We'll be reported. Building your own reporting endpoint is not so easy task to do. There are a few existing solutions, pet solutions such as reporturly.com and urlyports.com. And then there are an open source solution my colleague has built called reporting API for other which can be integrated with open telemetry and open source report collector. So you can connect it with your favorite monitoring tools such as Google Cloud Monitoring or open source monitoring tool called Prometheus and so on. The reporting API is nice, but debugging it is a bit of a pain. We recently added reporting API support to the Chrome DevTools. It might be only canary or dev still. So in case you're now using Chrome stable, you might not be able to try it today, but it's coming there. You can use it by enabling experimental feature in the DevTools configuration. While reporting API is convenient to determine the violations in production environment, Chrome DevTools allow you to debug locally too. Whenever there are issues on your page, the red flag indicates issues. Clicking it opens the issues panel and you can learn more things including how to fix. With that in mind, here's the steps we recommend developers to take. First, define the reporting endpoint by sending reporting and the points header. And next, set coop and quip headers, but with report only mode. Report only mode allows you to receive reports without actually enabling the feature so that you can easily detect where in your website is violating the restrictions. Large website tends to load so many resources that sometimes even the developer don't know what to expect. Run this in production environment gives you a chance to collect a list of resources to fix without actually breaking anything. I think the report only mode is also available on CSP content security policy as well. So some of you might be already familiar with it. Once you have the list apply course or corp, cross-origin resource sharing or cross-origin resource policy, as I said, if there are iframes apply them and quip recursively as well. And whenever you think it's ready, remove the report only mode and finally enable cross-origin isolation. You can check if cross-origin isolation is actually enabled by checking self.cross-origin isolated. It's a simple thing, but you can use it to check whether you can use shared or a buffer or not. I went really quickly on this section, but the same step is described in the URL on the slide. So you can just look back at that page. Okay, now let's try on the demo site and how those things work. Okay, let me reset what we have done first. And the first thing I would like you to do is to click on the link at the top. This will open a reporting end point website, demo website. I have quickly created it. So it will receive whenever there's a violation on the demo site, it will be delivered to this page in real time using WebSocket. So, and it's tied to your session. So you will only see your own violations, okay? And next thing I want you to do is to click on the configuration button. If you're running Chrome, better, I don't know if better can use this yet. If you are using Chrome Dev or Chrome Canary, just in case you don't know Chrome, better Chrome Canary, Chrome Dev are all alternative version of Chrome that are predated. I mean, earlier, more advanced version of Chrome that has the cutting edge features. Okay, Chrome Canary is like updated daily. So every day you get a new Chrome, new version of Chrome and it's yellow. Hope some of you may find it's useful information. So by clicking this toggle, toggle the right word and experiments. And if you go down, you will find a section that says enable reporting API. So check it and reload the DevTools. And now if you go to application panel and go down a little bit, you will see that there's a reporting API section here. Okay, then now please click on report only. So all the headers sent from this page will have report only mode. Let me check with the network panel. If you go to the inspector document, as you can see, the cross-origin embedded policy has report only appended. Also cross-origin open-up policy has report only mode appended. That's why the background color turned to white because it's sending reports, violations, but will not enforce the blocking or communication blocking, right? And the image is successfully displayed here. But this means that there are some issues, obviously. And that's why you see these issues appeared on the reporting end-of-point server. Let's try opening a pop-up and see what happens by looking at this reporting API inspector. Let's see what happens. Open a pop-up. Now you should have seen that there's one more entry added to this reporting API list, report list. And the status has quickly changed to success. But let me try once again. And it starts with queued. And it will be sent in a moment to this other end-of-point server because browser queues any reports and send in batch, kind of bundling different reports and send in a few minutes. So it's batched to send the reporting end-of-point server. Let's see when it will be sent. It's still being queued. It's going to be transmitted in momentarily. Yeah, it's sent and see that it's added at the top, right? So this is what reporting API does. Okay. And also I would like to point out that there are things you can observe without if you are debugging locally without reporting API. Let me remove the report only mode and enable this state. This is the state that you wouldn't expect in the production environment, but you can try it on the locally and see how you can debug this. And if you look at the top of the DevTools, you can see that there's a red flag appearing here. Clicking it will show you that issues that have occurred to this page. And here's cross origin resource policy violation. So despite this page is being blocking the resources with require corp resources without opting using cores or corp will be blocked. And this DevTools issue panel kindly tells you what to do to fix it, right? It's a convenient thing. And also you can find in the network panel, let me reload and if you go to, sorry, not this one. If you go to the blocked entry, you can find here similar guidance how to fix this issue, why this is blocked. You can find the reason why this is blocked. It's kind of, right? So this is how you can debug this cross origin isolation using Chrome and DevTools. Let me go back to the slide and let's continue. All right, so far we've been discussing how to enable cross origin isolation, but they are mostly assuming everything is under your control. From here, let me talk about some common problems and challenges you will likely encounter and discuss what are recommended work allowance. The biggest obvious issue for you is that applying cores or corp on the store party resources isn't that easy. Depending on the website, there are so many resources including ads, widgets, CDNs, and so on to apply the changes, right? Asking all of them to make such changes takes a huge effort and time. In fact, Google ads decided not to adopt corp because even if they do, ads are served from another origin resources, sorry, another cross origin resources, which will not likely easily changeable. The second issue is cross origin opener policy, same origin, which breaks cross origin popup integrations which are typically required by all of or payment integrations. This is a known problem. That environment, both websites cannot call post message and will not function, which is not good. To solve these challenges, we are working on three things. First is corp credential less, credential less mode. The second is anonymous iframe. The third is cross origin opener policy, same origin, allow popups plus quip. Let me explain one by one. For credential less, which that relaxes the restriction from required corp. I said cross origin embedded policy restricts resources to load, restricts resources to load because cross origin isolation puts loaded resources in danger. However, the resources that will be at risk contain sensitive information, sorry, however the resources that will be at risk contain sensitive information and they are not usually public, right? Let me bring it back. You don't want to put resources that have sensitive information to be in danger. Then how about sending requests without credentials such as cookies, then this will only load publicly available resources and we can consider it won't put sensitive information in danger, any sensitive information in danger, right? That is the idea of credential less. So credential less is already available in Chrome 96, which means Chrome 96, if I remember correctly is currently rolling out now, today or tomorrow for you, I guess. So it will be available for you too soon. And the second solution is anonymous iframe. That concept is the same as credential less. It won't send credentials, so it's safe to load. However, the implementation of anonymous iframe is not yet available anywhere even on Chrome yet. We are working on it. And the third solution is about the cross origin window communication. The intention of blocking the communication is to protect the origin from being opened by a malicious website and steal information using Spectre. Then what about allowing communication only when the window is opened by itself, not the other way around? This is why we are working on cross origin opener policy could same origin allow popups, popups plus web. It's a long name. Same origin allow popups plus web. This is a special mode to enable cross origin isolation. Details are still to be determined and not yet available on any browsers yet. But we are actively working on it. So there are the three solutions from standardization perspective. While browser vendors are working on them, many web developers are still struggling to continue using shadowy buffer. We are aware of that. That's why Chrome left an option to continue using shadowy buffer by adopting to deprecation trial. Some of you may have heard a word origin trial. Origin trial is a way to test a new web platform feature before it is shipped by registering your origin. Deprecation trial is similar concept but opposite to it. It's a way to continue using deprecated features after it is disabled by registering your origin. You can register for deprecation trial to continue using shadowy buffer until at least Chrome 103. But unless we have all three new features available on Chrome, we will not terminate the deprecation trial. So you can continue using shadowy buffer without adopting to cross origin isolation. Okay, so that is all I have prepared for this workshop. Thank you all for joining until now. And if you have any questions now is a good time to ask on the chat if you want. Meanwhile, let me summarize what I have talked. Once again, if you want to use shadowy buffer, now you have two options. One is simplify your website and take all the efforts to enable cross origin isolation. So if you have so many resources loaded from different cross origins, it may be hard for you to adopt to cross origin isolation. In that case, you might wanna remove some of them or maybe put in some other pages or so to simplify your website, but you can enable cross origin isolation. The second option is continue the status quo and keep it available only on Chrome desktop by registering deprecation trial until Chrome 103. So my recommendation is just don't bother continue using Chrome desktop if it's okay for you. But if you want to enable cross origin isolation and the use shadowy buffer also on Firefox and soon on Safari, I would definitely recommend you to adopt to cross origin isolation by removing many parts. It may be hard, but that should allow you to make it work across different browsers, okay? All right, let me check what kind of questions you have. Very complex, yes it is. I know I had so many times. So I took a long time to understand all of this. This is one of the most complex topic and we are aiming to make this more simple in the future, but now is a complex transition time. Yeah, learn friendly and easier to remember all these headers. Yes, the presentation. Yes, I think that we are planning to present share the presentation. I will check, yes. Unless you have any other questions, there's the feedback form. Yeah, Rohit added the link to the chat goo.google.cds2121-feedback is a URL for the feedback form. Yes, okay. So thank you for joining me for about one hour. Hope you enjoyed the session.