 Hi, my name is Camille, and I'm a software engineer on the Chrome Open Web Platform security team. And today, I'm going to walk you through enabling cross-origin-isolated on your website. By enabling cross-origin-isolated on your website, you will gain access to powerful web APIs like Sharder and Buffers on Android or performance.memory. You will also protect your application against cross-origin attacks. So cross-origin-isolated is a new security feature that provides increased isolation from other origins and that is trickter than same-site isolation or the cross-origin policy. Let's get started with what cross-origin-isolated is and how you enable it on a website. So cross-origin-isolated is the result of sending two HTTP headers on your top-level document. These headers are the cross-origin opener policy, co-op, and cross-origin emitter policy, co-op. To enable cross-origin-isolated, you need to send a cross-origin opener policy header with a value of same origin with your top-level document. You also need to send a cross-origin emitter policy header with a value of require cop with each of the frames in your page. So what do those headers do? Co-op isolates your page from other cross-origin pages. So for example, any cross-origin pop-up you open will not be able to directly interact with your document or send it messages. You will see the pop-up window has closed and similarly, the pop-up will see its operator has closed. This protects against data leakage attacks like Spectre because the browser can put your page in a secure environment with only pages that share the same top-level origin. Co-op ensures that every service source you load on your page is same origin with you or it agrees to be loaded same origin. Service sources agree to be loaded same origin by either having a course header or having a corp header with value cross-origin. Without this, the service source will be blocked. So when you set co-op to same origin and co-op to require corp, your page becomes cross-origin isolated. You can current this by checking the result of self.cross-origin isolated. So starting in Chrome 88, this will allow you to use shared web offers on Android as shown in this example. So this is a brief overview of what co-op, co-op and cross-origin isolated do and if you want to know more, you should follow these links on the site. As you have noticed, co-op and co-op impact how a web page works. So if you just set the headers on the page, it's likely that your page will not work as it used to. To help you debug the issues coming from deploying co-op and co-op, we have new DevTools functionalities that are coming in Chrome 88. So let's have a look at those. First, you may want to check the cross-origin isolated status in your off your page. In the application panel of DevTools, you can check the security and isolation status of your top level frame. And there you can see that the page is cross-origin isolated. You can also check the co-op and co-op status of the page. Here, both are enabled. So my page is cross-origin isolated. Not that because I have both, my co-op status is not same origin, but same origin plus co-op. Let's look at co-op support in more details. So first, let me open a cross-origin pop-up. I can see the pop-up I have created in DevTools. And if I click on it, I see that it doesn't have access to its opener. This is because the opener is our main page with co-op and it is cross-origin with the pop-up. So due to co-op, the main page and the pop-up it open don't have access to each other. Okay? So let's try opening the same origin pop-up then. And DevTools is telling me that I still don't have access to it. This is because I haven't set the co-op and co-op headers on the pop-up. So let me do that right now and open a new pop-up with the right headers. And as you can see, this pop-up has access to its opener. And its icon is also different from the other pop-ups that could not access the co-op page. Now, let's look at support for co-op. If I look at the issue tab, I can see that four server-source loads were blocked. As explained in the issue tab, those resources do not have a co-op header so they won't be loaded by a cross-origin co-op page. And I can click on the specific server-sources to get more details about the network load. So beyond support in DevTools, we have also been working at reporting APIs for co-op and co-op. With reporting, you can get production reports on what needs to be changed to support co-op and co-op. If you're familiar with CSP reporting, this should be fairly similar as we are using the same underlying reporting API. To enable reporting, just provide an endpoint in your cross-origin opener policy and cross-origin opener policy reports. This is where the reports will be sent. Note that for co-op, the reporting API is still in an origin trial. So you will need to either subscribe to the origin trial or enable the reporting API through Chrome flags. We also provide a report-only mode for co-op and co-op. So when you enable report-only, the browser won't enforce the policies. Instead, it will send you reports when it detects that something would break if it had enforced the policies you specified. To enable report-only mode for ISR co-op and co-op, you need to use different headers with your documents. So these are the cross-origin opener policy report-only header and cross-origin unbender policy report-only header. In those headers, you will also specify the value of the policy you want reports for and an endpoint to send those reports to. In report-only mode, you also get reporting observer notifications. Okay, so let's have a look at the additional support and dev tools for reporting mode. So here, I have a page with report-only co-op and co-op and it's the same page as the previous demo I have just changed the headers it sends. So on the application tab, I can see report-only values for co-op and co-op and I can also see the associated reporting endpoints. And as you can see, we don't have anything in the issue tab since we're in report-only mode. This means that co-op is not enforced and we don't block the sub-resource loads. Okay, now let me open the cross-origin pop-up. It can still access the page because co-op is not enforced. So overall, what I have shown you is the state of support for co-op and co-op index rules in Chrome 88. We do have more support plan to help you debug co-op and co-op more efficiently and it's gonna show up in later releases. Okay, so let's summarize what you need to do to enable cross-origin isolated on your site. So with cross-origin isolated, you will be able to use powerful APIs like StarDriver for an Android starting in Chrome 88 and your site will also be more secure against ad-x like Spectre that's right to leak your user data. To make your website cross-origin isolated, you need to enable co-op and co-op to help you make the transition. Enable co-op and co-op in report-only mode first. This will give you reports from production that will help you pin down the changes you need to make before deployment. Product with local debugging using DevTool application and issue panel to ensure that your webpage will support co-op and co-op. In terms of actually enabling co-op and co-op, this is all about setting the right headers. First, ensure your cross-origin sub-resources can load with cores or have a corp cross-origin header. This includes your cross-origin timeframes as well. Then, ensure all the documents in your app set to co-op require corp header. So that means top-level documents and child documents including cross-origin iframes. And so finally, you need a co-op same origin header on your top-level documents. And with this, your page should be cross-origin isolated and have access to powerful APIs as well as extra isolation that protects them against cross-origin data leak attacks. So thank you all for watching and see you next time.