 I was in the meeting yesterday, Paul Lewis was there. He did an amazing mixed metaphor. Something like, you know, we don't want to rock the boat till it's in the bag. And it's like, don't put boats in bags like I got. So the topic I'm putting on the conveyor belt is corp, corp, corp. This is Swedish chef, corp, corp, corp. This is cross origin read blocking. And I said pause like, so I always want to say resource, but it's read. Did it used to be a resource blocking and a rename to read blocking? I don't know. Oh, no, is it corp? Corse is cross origin resource sharing. What is the S in chorus? Let's say sharing. Security. No, it's not security. It's sharing. Let's say sharing. It's sharing. Now, this is a new behavior in the fetch spec that was sort of added by some Chrome folks. And it's all to do, it's kind of to do with Meltdown Spectre. Oh, is that where we had the cool headline that because of Meltdown Spectre Chrome uses more RAM now? Oh, yeah. Well, that's not to do with this exactly. But yes, that has been a cool. So the more memory thing is that's more down to site isolation. Oh, I thought it was part of site isolation. Interesting. See, I learned something. It's sort of to do with it. So in case the user don't know, I wrote an article on site isolation. I will link to it in the description. Oh, did you? I think so. I might have just been thinking. I think I had three weeks of security reviews on it because it was. Oh, that's right. Yes, back in the. Yes, of course it is. Back in the day when it was announced. Back when it was right. Yes, so we'll add then. Yes, the site isolation is like Chrome has been putting tabs in different processes since version one. We were the first to do that, I think. But we didn't do it with iFrames. And we didn't do it. In some cases, we didn't do it with new windows. Like if you had, sometimes if you were clicking, if it was window.open, I don't think we put that in a, well, that has the opener thing. So yeah, there were some cases where we weren't putting these things in other processes. Meltdown, Spectre came along and went, we've got this problem. This is an entry point for us. Yes, where memory that's in the same process can. Freefall, you can just read it if you do it right. Yes, for a lot of trickery and a lot of that. I should probably be more careful about what I say about Matter Inspector, right? Oh yeah, yeah, we need to get this review. Spreading more fear and uncertainty in doubt about this is probably not the best idea. It's a very tricky hack, but it's something that we need to be careful of. So we thought, well, oh, this thing where we are putting things in different tabs, different processes, really good idea, but we just need to finish that work. And so we did that and that was like upiffs, which was out of process iFrames. Oh, the upiffs. Upiffs. So that was all part of site isolation. Same with Windows. And we've done that work and we've shipped it. More processes means more memory, but it means more security and that's more important. So that solves the problem of another origin's iFrame sharing a process with you and being able to get that, potentially maybe getting out of that data through Meltdown Spectre. But we have a lot of APIs on the web that let you read data from another origin with the other origin's cookies. And they have it do things on your page. Script tag includes. Script tag. Images. Images. Video audio. Style sheets. Style sheets. Correct. Yeah, lots of stuff. Those are the main ones. And this is bypassing course, right? This is just like, do a request, put in you can't read it in terms of like JavaScript, read it by byte, but it's just going to get incorporated into the page one way or the other. Exactly, exactly. And so the danger is, if you have this image tag, we'll say, pointing at facebook.com, it's going to load that data in and it's going to have an image decode error. But that data does go into the process. It's in the memory. It's in the memory. Because it had to be there to get the value and then the browser can determine. This is actually an image made. Yes. And it's the same for, I mean, the Fetch API lets you do no cause fetches. That's another one. And then same with script tags and everything. Even if it fails to load because it's the wrong type, it has still gone into that process. So that is what Corp is all about. The way it works is, if it's a no cause fetch to another origin, the data comes back. What it does is it tries to determine ahead of time before it sends the data back to the API, like the image tag or whatever. It tries to determine, it's like, hang on a minute. Does this seem like something that you're not going to be able to use anyway? Does it seem like something that could potentially hold private data? OK. And those are, it looks at MIME types right now, for things like. MIME types deducted from the file extension or? Determined from the content type header. Oh, so basically it sends out the fetch and gets the response out of process, does analysis, and then decides whether the data goes into the tab process or not. And if it's text HTML, or if it is JSON, or if it is XML, except for SVG, that's when it kind of goes, this looks dangerous. It's ecstodgy. I'm just going to fail. And that takes me back into the process. Right now, we're relying. Even when I want to include an HTML file or something? You can't include an HTML file as an image. You can't include it as scripts. These are all formats that are definitely going to fail. True. OK. Go with you. Right now, you need the header for strict MIME type checking to do it. But we're going a step further, and we're experimenting with actually, rather than relying on MIME types, to sniff the data. So even if it's served as script, but it's quite clearly HTML, or quite clearly, it's not an image. It's something else. We can look at it and go, when we get a judgment call, we don't actually want this data to end up in the process. We're pretty confident this API is not going to be able to do anything with it anyway. And that's how it works. There's some weird edge cases. Textplane is another one of the formats that we think, well, that could have user data in. Less likely, but possible. But lots of script tags load their scripts with Textplane. Not anymore, they don't. Because we're blocking that. No, it turns out that's not happening a lot for cross-origin. OK, sure. But yeah, it's not a cross-origin anyway. But one API that does receive a lot of Textplane, can you guess which one receives a lot of Textplane? The style sheet? It is video. Yeah, there is a load of video data out there that is served as Textplane for no good reason. That is very confusing. So there's had to be an exception for that. Like, if the response is a range response, two or six, then if it's Textplane, fine, whatever. Oh, look, it's cross-origin video. That sounds familiar. Right, yes, you've talked about that before as well. So yeah, that's called. People shouldn't see any difference in data. It's basically a know-up for most people, unless you want to opt in with the mind type checking. Yes. To make it better? Yes, and that would protect your data more against. Or your user's data. Absolutely, your user's data. And you might see failures in cases where you maybe are relying on this Textplane thing to be done. I mean, in the end, you want to make sure your content type hairs are correct anyway. Yes, and we've made a judgment call that it's so few sites. Percentage of breakage is low enough for us to take that damage. And the benefit of a security upgrade from Meltdown Spectre is worth it. So that's called. Brilliant. Cut my podcast into pieces. Cut my life into pizzas. This is my second course. Right.