 Hi everyone, I'm Eji. In this session, Camille and I are going to recap the basics of semi-origin policy and the challenges and mitigations to that, then talk about the new defaults we are bringing to the browser in the future. Let's dive in. One of the powerful aspects of the web as a platform is the ability to bring functional components from different services and embed them as part of your website. Just like puzzles. Using components you can embed to your website like YouTube videos, Google Maps, images, styles, scripts, fonts, and so on. You can load these resources and capabilities onto your website without setting up the hosting server by yourself. Cross-origin integration is such a powerful functionality you can bring to your website. However, at the same time, the nature of cross-origin integrations opens your site up to some threats. For example, cross-site scripting, XSS, is a vulnerability where an attacker can inject arbitrary code in order to steal user data. Clickjacking is a technique where an attacker embeds your website within an iframe and tricks a user to take an unintended action by concealing buttons behind a disguise. As you can see, the boundaries between sites and origins are key to keeping your website secure from attackers. That's why browsers have a mechanism called the same-origin policy. The same-origin policy keeps an origin independent from others while allowing a certain extent of interactions. For example, a document on host.example can load an image from cdn.example and it's visible to the user. However, a script on host.example cannot read the binary of the loaded image from cdn.example because it's loaded cross-origin. The same applies to iframes and pop-up windows. The host document can't read contents from cross-origin resources. This behavior is called an opaque response. And the browser is designed to prevent cross-origin access to such information as part of the same-origin policy. If cdn.example wants to explicitly allow host.example to access the binary of the served resource, they can use cross-origin resource sharing, CORS, to obtain. CORS is a mechanism to instruct the browser to control access to cross-origin resources. However, the discovery of Spectre announced in 2018 was a catastrophic threat to the web that enables a malicious website to even stop cross-origin contents by reading their memory despite being protected behind the same origin policy. We published a proof of concept in March that demonstrates how Spectre.js can even stop a cross-origin resource. If you look at the demo, you can see that it's not just in theory, but it's for real. You can try it yourself at leaky.page. Because the vulnerability is caused by the hardware CPU and it's unrealistic to expect them to be completely eliminated from the market in the foreseeable future, this unfortunately is an irreversible change. Luckily, there are some effective mitigations you can apply to your site to protect against Spectre. Let me walk you through some of them. Protecting against Spectre attack is about isolation. You need to ensure your site's sensitive data is never handled in the same context as an attacker's site. For example, don't let the sensitive resource such as an access-restricted image on a social network be loaded by cross-origin documents unless you intend to do so. To prevent your resources from being loaded by cross-origin documents, you can instruct the browser not to load it by using cores or by sending a cross-origin resource policy, corp header. The corp header can pass same origin, same site or cross-origin to indicate in which relationship with the document the resource can be loaded. If they don't match, the browser will block loading the resource even after they receive the response. A document opened by a cross-origin window with window.open is a chance for an attacker to exploit Spectre too. You can't prevent your document from being opened by a cross-origin document, but you can isolate it to mitigate the risk. Cross-origin opener policy, corp, is a header to instruct the browser to control the isolation of the document when opened as a pop-up. The value of same-origin isolates the document from any cross-origin documents. Note that as a side effect, when the document is opened isolated, they have no handle mutually so they can't send a pass message to each other, for example. Same-origin allow pop-ups is the same, except it allows sharing the context with that window opened by itself unless the opening is opted out. UnsafeNum is a current default and allows any cross-origin documents to share the context. Iframes are in a similar position. Blocking your documents from cross-origin loading has been mainly to protect them from click-jacking, but Spectre is now another reason. In the web today, websites can embed any cross-origin documents by default. This means a malicious website can embed yours and steal the personal information of the browsing user. You can prevent your documents from being embedded with X-Frame Options header and Content Security Policy, CSP's Frame Ancestors directive. With X-Frame Options, you can prevent embeds altogether. With CSP Frame Ancestors, you have more granular control allowing embeds per origin. Content Sniffing XSS is an attack that exploits the browser's mind-sniffing ability. For example, an attacker website can try loading a victim's website as another type, for example, a script, so that Spectre allows the attacker to read the victim's website content. To prevent it, set X-Content Type Options No Sniff to all resources along with the correct content type header. This header instructs the browser not to apply mind-sniffing. Now I have talked about opt-in-based security, but ideally, security should be nibbled by default. Let me hand it over to Camille to talk about upcoming new security defaults in the platform. The recommendations AEG just described mitigate site-channel attacks like Spectre. However, they require all developers to do some work to be protected. Ideally, we'd reverse this. Applications should be self-contained and safe by default. Those developers whose applications require more prosthetic interaction can opt out of protections. This would ensure that costs accrues only to those developers with extraordinary needs. It would also ensure that those developers are encouraged to sync through the mitigations they remove. Then, hopefully, they can put their own application-specific defenses in place. Let's have a look at three problematic behaviors. The first one is document.domain. Document.domain allows a page to relax the same origin policy, and it's easy for developers to accidentally hurt themselves by relaxing the same origin policy using document.domain. Say that you changed document.domain from your specific subdomain origin to the generic top-level site because you want access to another cross-origin document in the same site. Then, any unprotected property in the same site can also become same origin with you, which means that this property has now direct read access to all of your resources. And if that property is poorly protected, it could be exploited by an attacker that leverages the fact that now both different properties are same origin. On top of this, document.domain prevents browsers from deploying mitigations against Spectre by isolating websites based on their origins. Documents in the same site could eventually become same origin because of document.domain, so we cannot isolate them from one another. Concretely, the spend secure page is only as secure as the least secure page in its site. With this in mind, we aim to deprecate document.domain. We recommend that developers shift away from its use as soon as possible. Consider using window.pass message to communicate between cross-origin documents without relaxing the same origin policy. Following the deprecation, just using document.domain will not change your document's origin. This way, websites will avoid accidentally modifying their origin to something potentially dangerous. Given its usage, we're not going to be able to remove it immediately. To get there, we plan to have an escape hatch for legacy content. Pages that need to use document.domain will need to opt into doing so via document policy. If you enable the document policy document.domain, your site will still be able to modify its origin when we transition to the escape hatch model. Otherwise, using document.domain will be a no-op. The second problematic behavior is cross-origin document embedding. By default, all documents are embeddable cross-origin, which means that by default, an attacker can embed any document it wants. The attacker could try to perform a click-chatking attack on an embedded frame. The attacker has access to a window handle for an iframe it embeds. With this window handle, it can post message to the frame. Or maybe it can count the number of child frames its iframe has. This could allow the attacker page to distinguish between a logged-in version of a site and the not logged-in version and reveal information about the person browsing the page. And in some browsers, the attacker can even perform a specter attack on the embedded iframe. Many documents have no reason to be embedded cross-origin. So instead of every document having to secure themselves, we'd like to require documents to opt into cross-origin. With this change, documents will be saved from an attack from a cross-origin embedder without their developers having to do any work. In the new model, developers will have to opt out of security protections when they want their documents to be embedded cross-origin. To opt out, developers should send either an iframe options header or a CSP Frame Ancestor directive that allows embedding. So if you have documents that you want to be embedded cross-origin, please send an iframe option header or a CSP Frame Ancestor directive in your headers. Beyond iframes, we also have an issue with pages opening another page as a pop-up. When a page opens a cross-origin pop-up, by default the opener page obtains a handle on the pop-up unless the pop-up is using co-op. This allows an opener page to abuse window APIs like frame count to learn information about the cross-origin pop-up they just opened. In some browsers, the handle also allows the opener to mount a spectre attack against the pop-up it opened. In many cases, pop-ups have no use for communication with a cross-origin opener. We think that the web would be safer if pages did not have that communication with their opener by default. Concretely, this means that we would treat pages as having co-ops same origin-allow pop-ups by default. And in this world of co-ops same origin-allow pop-ups by default pages are protected against attacks from their openers by default as well. To be clear, there are legitimate reasons to want to have communication between a pop-up and its cross-origin opener. For example, a no-host flow, which is why in our world of co-ops same origin-allow pop-ups by default a page can specify a co-op of unsafe none and retain communication with its opener. Again, you opt out of security protections to have communication with the opener. So if you have a page that needs to interact with its cross-origin opener, for example you are maintaining an authentication or payment flow that requires pop-ups, we would like you to send co-op and safe none headers with it. This broadcasts that you want this page to communicate with a cross-origin opener. This way, when we switch to a world of co-ops same origin-allow pop-ups by default, your page will still be accessible from a cross-origin opener and it will have access to its opener as well. To summarize, there are security APIs that help protect your pages against a variety of attacks but it requires work to enable them. We want to make some of those protections default. This way, web pages will enjoy more protection even without deploying some of the security headers that AEG presented. To do this, we must change some of the permissive behaviors of the web to be opt-in rather than opt-out. If you are a developer, you can help us move to the safer new world by doing a few things. First, don't use document.domain or prepare to enable the document.domain document policy once we release it. Second, send an XFO header or CSP frame ancestors directive with all of your documents that need to be embedded cross-origin. Finally, send a co-op and saved on header with all of your pages that need to be accessed by a cross-origin opener. Those changes are going to be coming at some point in the future so you know it's your chance to be ahead of them. So if you want to learn more about what we presented today, we have included a few links to interesting resources on this site and thank you all for watching.