JAKE ARCHIBALD: Yeah,
and I've got me notes. SURMA: Got me notes. JAKE ARCHIBALD: Got me notes,
so I don't get it wrong, although hopefully,
I won't need them. SURMA: That's a
lot of notes, mate. JAKE ARCHIBALD: I know. This might be a
really long episode. Oh, dear. Shall we just-- SURMA: Where did
this voice come from? JAKE ARCHIBALD: I don't know. If the episode's really
long, just play it faster. [HIGH SPEED SPEECH] [MUSIC PLAYING] JAKE ARCHIBALD: OK. I want to talk about
cross-origin fetches. SURMA: Oh, god,
I'm bored already. JAKE ARCHIBALD: I know. I know. I deleted a lot of these
slides because they were really boring. So hoping what's left is not. But these are things
we're going to look at. SURMA: Cookies, CERF,
CORS, CORB, CORP, COEP. JAKE ARCHIBALD: Yep,
well done, actually. If you're playing
this in fast motion, you'll miss that all right, so. SURMA: Do they do
this on purpose? JAKE ARCHIBALD: What, how
they like used four-letter C words for the worst things? Yes. I think that probably
is intentional. SURMA: So CORS is
a four-letter word. JAKE ARCHIBALD: Yes, it is. These are all C bombs. Cookies isn't. SURMA: But why is this not-- why is this one-- never mind. JAKE ARCHIBALD: Never mind. That's what I say. We're going to go back in time. This is 1993. This happened. SURMA: Oh, this was a new thing. JAKE ARCHIBALD: This
was a new thing. SURMA: This wasn't on the
blog at that point in time. JAKE ARCHIBALD: Yes. This is in Mosaic. The image tag arrives. And I think-- SURMA: I hadn't touched
a computer at this point. JAKE ARCHIBALD:
Well, I was nine, so I had, but not
on the internet. I wasn't allowed on the
internet at that point. Also, no one in
Carlo where I grew up knew what the internet was. This was a community
that found tin foil to be too technologically advanced. [LAUGHTER] Anyway image tag
arrives in Mosaic, and I think I've done so
much research into this, and I'm still not confident. But I'm going to say anyway. I'm just going to
go full confidence. This was the first
sub-resource the web ever had. SURMA: Like if the
camera would correct it. Like, Jake. JAKE ARCHIBALD: I was waiting
for someone to crawl out of the camera and go-- SURMA: Well, actually. JAKE ARCHIBALD: Actually,
that was just weird SGML. SURMA: OK. That probably was. JAKE ARCHIBALD: Yes,
first sub-resource. That landed, and also
interestingly, oh, look at that. It can be cross origin. SURMA: Was the concept of
an origin even established? JAKE ARCHIBALD: Nope. But at the time, they would
have said, different domain, I guess. SURMA: So if Facebook existed,
that would be leaking. JAKE ARCHIBALD: Yeah. Well, we'll get onto that. We will get onto that
because they weren't leaking a lot of the time because
cookies hadn't been invented yet because they came along
in 1994 as Netscape 0.9 beta. That arrived. SURMA: Look at that
research number. JAKE ARCHIBALD: I know. I didn't even look at
the notes for that. SURMA: What? Do you know what
motivated cookies? JAKE ARCHIBALD: State. State and HTTP. So things like login because
it was entirely stateless before that, but they
wanted some way-- SURMA: But it's still stateless. JAKE ARCHIBALD: --to
know [INAUDIBLE] user. Except cookies are
sent every time. That's stateless. SURMA: Still stateless. JAKE ARCHIBALD:
Is that not state? SURMA: The protocol
is stateless. You send state with
the stateless protocol so that the protocol
doesn't have to hold it. JAKE ARCHIBALD: Fine. Fine. OK. I would count that as state. Shut up. Right, next year, 1995. Look what lands. SURMA: Look at all
these sub-resources. JAKE ARCHIBALD: All these
sub-resources, but importantly, script. So this is Netscape Navigator 2. SURMA: How many people know
that this frame and not iframe? JAKE ARCHIBALD: Yeah,
that's a frame, not iframe. I've not used a
frame for so long. SURMA: That was the only
thing I ever used when I was a kid playing with HTML. Love it. Always had the sidebar,
the site nav in a frame because you could drag it. Great. JAKE ARCHIBALD: And
would stay there. SURMA: Yeah. JAKE ARCHIBALD: It was perfect. And then your URL at
the top never changed, which was useless. But never mind. Something bad had
happened at this point. One of probably-- SURMA: You started saying, "Yo"? JAKE ARCHIBALD: [LAUGHS] It
was actually because if I had-- so you're going to see some
more code coming down here, and so I needed something
short to put in there. And that's why that is. But the web made a
huge mistake here, probably one of the
biggest mistakes in the design of the web we
ever made, and it's right here. And it's that-- no matter
what site is containing these, the cookies for example.com will
be sent with these requests. SURMA: Right. JAKE ARCHIBALD: And
that was a big problem. And it was a problem
that we continue to make [INAUDIBLE]
of elements as well. SURMA: I see here. [INAUDIBLE] JAKE ARCHIBALD:
Yeah, there you go. One more letter
and that overflows. SURMA: Why was it
a mistake, Jake? JAKE ARCHIBALD:
We'll get onto that. SURMA: Oh, OK. JAKE ARCHIBALD:
But it wasn't just a mistake for
sub-resources, it was also for some kinds of
navigation as well. Because this would be sent
with the cookies as well. SURMA: Now that I
can see as a mistake because I can send
someone to a random form and suddenly delete their
bank account or some crap. That doesn't seem good. JAKE ARCHIBALD: That
seems bad, doesn't it? SURMA: It does seem bad. JAKE ARCHIBALD: But this is how
all of this stuff was built. SURMA: Right. JAKE ARCHIBALD: Big mistake. And I'll go through some
examples of the horrible things that can happen. SURMA: Great. JAKE ARCHIBALD: But I
do want to acknowledge that things were starting to
go right at this point as well. So we had these frame
objects, and these frames will tell you things
about the images on the page, the forms on the
page, the links on the page-- so the basic JavaScript
we had back in 1995. But they decided
that you would only be able to access
those properties if you were on the same-- SURMA: Origin. JAKE ARCHIBALD: Origin! SURMA: Bam! JAKE ARCHIBALD: As the
parent site or whatever. And the origin was decided to
be scheme, host, port number. And there we go. So things were starting
to become good. They were thinking
of the objections that they should have
thought of back at the start. Look at this! SURMA: I have never written
these lines, but I-- JAKE ARCHIBALD: I have! SURMA: ActiveX, I remember as
being the source of many evils. JAKE ARCHIBALD: This
is XMLHttp request. This is the first version of it. This is what it looked like. SURMA: It started as
an ActiveX object. JAKE ARCHIBALD: Oh, yes! Yeah, it used to have this
horrible tri-cache thing just to find the correct string
of that that you needed. Because there were
multiple versions of this. Anyway, whatever. It was horrible. But yeah, we did eventually
get standardized. And it took a long time. SURMA: Nine years! JAKE ARCHIBALD:
Another nine years before we started to get
cross-origin of these. So this was the change. We had XHR in other
browsers long before that, but this was the
cross-origin one. SURMA: With cookies? Without cookies? JAKE ARCHIBALD: Well. SURMA: Well. JAKE ARCHIBALD: So I'm going
fast-forward to modern code because it's all
worked the same. SURMA: Look at it. This nice. That's nice! JAKE ARCHIBALD: And they
decided that, for this to work, it would have to be
an opt-in system. They don't want you
to just be able to-- SURMA: Opt-in by the site
providing the data, not me, the person who writes the code. JAKE ARCHIBALD:
Yes, because they didn't want you to just be able
to go and grab someone's emails or whatever. SURMA: Yeah. JAKE ARCHIBALD: The same
problem with the frame stuff, so you needed this to
be an opt-in system, and that opt-in became CORS. And what it involved
is the other side sending this back, that header. And there you go. You can now access the data. SURMA: So basically, everyone is
allowed to read this resource. JAKE ARCHIBALD: Yes, exactly. But, like you
picked up on before, the request would be
sent without credentials. We call it-- which is cookies,
cookies and some client cert. SURMA: Can the site to opt-in
to allow with credentials? JAKE ARCHIBALD: Yes, it can. So you would do
something like this. The same existed on XHR. But you would need this access
control credentials true and your access
control allow origin. You couldn't use star. Can't use star for this. It has to be the origin. SURMA: But sometimes--
so this is obviously headers in the response. JAKE ARCHIBALD: Yes. SURMA: Which means the
request has already been sent, processed, and a response has
been sent, which could already have done damage. JAKE ARCHIBALD: So
these are the slides-- you're now talking about the
slides I deleted from this because I thought
they were boring. No, but you're right. So the way it was decided
when this was an invented, it is like we don't need
to worry about the request if it's already
a kind of request that the browser
can already send. SURMA: Right JAKE ARCHIBALD: So
this, a request to there with credentials,
it's an image tag. You can already do it. SURMA: That's true. JAKE ARCHIBALD: A post request,
you can do that with a form. And there's also
rules around the kinds of headers you can use. Like for a content type,
the content type can be-- for the body of the post, it
can be URL-encoded, the x URL-- I can't remember it
off the top of my head. SURMA: Yeah, thing--
the long thing. JAKE ARCHIBALD: Because
you can do that with forms. Form multipart. SURMA: Oh, I just remembered. JAKE ARCHIBALD: Because
you can do that with forms. SURMA: If you want
to deviate, you go into the whole
preflight request thing. We're not going to talk
about, I'm guessing. JAKE ARCHIBALD: Content-- no. So if you deviate,
it does a preflight where it has to
go and ask first, "Can I make this request?" Absolutely. Interestingly, you
can do a POST request with the content
type text plain. And that's fine
because you can already do that with the form element. SURMA: Oh, they can? JAKE ARCHIBALD: Yes. SURMA: I did not know. JAKE ARCHIBALD:
Yes, this is like-- I always forget about this. The encoding for form
data text plain is-- SURMA: That's how I used
to send emails to myself! It's just like value equals-- or key equals-- JAKE ARCHIBALD: Which is
almost entirely useless because if you have-- because the line break
separated, but your form values can have line breaks. So it's impossible to parse. SURMA: True. JAKE ARCHIBALD: But it exists. SURMA: I made pages
back in the day, I would have a contact me form,
where you send emails to me, and I would use that. JAKE ARCHIBALD: Yeah,
then CGI script to do it. Yes, absolutely. But the point I want
to make about this is-- yeah, you have to-- SURMA: CGI script mail, too. JAKE ARCHIBALD:
Oh, with the body. Yes, fine. You have to send
the origin back. SURMA: The exact
origin, not star. JAKE ARCHIBALD:
You can't do star if you're doing credentials. SURMA: Interesting. JAKE ARCHIBALD: So how
would you get this? Because how do you get-- SURMA: From the request, right? JAKE ARCHIBALD:
From the request. Now, at the time we had
the referrer header. SURMA: The infamously
misspelled referrer header. JAKE ARCHIBALD: The
misspelled referrer header. But also, the often
absent referrer header. SURMA: True. JAKE ARCHIBALD: Because
internet safety software-- actually, I'm not
even going to do that, because this is actually
a good piece of safety. Leaking the path of where
you were on the previous site is actually quite
privacy invasive. SURMA: Or could-- yeah. JAKE ARCHIBALD: Because it could
have your user names, account, user numbers, all of
that sort of stuff. SURMA: True. JAKE ARCHIBALD: So a
lot of this software would just remove the referrer. SURMA: Yeah. JAKE ARCHIBALD: But then that
means it's useless for this. SURMA: True. JAKE ARCHIBALD: So we invented
a new header, origin, and that's sent with the request. So it doesn't have all of the
path data that would be leaky, it just says the
origin it came from. SURMA: Was this header invented
as a response to this problem? JAKE ARCHIBALD: Yes. SURMA: That's interesting. JAKE ARCHIBALD: Yeah,
it is exactly that. So that exists on CORS requests,
and that's how that works. SURMA: I think it comes
pretty much any request now. JAKE ARCHIBALD:
We'll get on to that. So, the point I want
to make about this, and I wanted to get here a
lot quicker than we have, but here we are. Is that adding this is almost
always safe, almost always. SURMA: And yet,
almost nobody does it. JAKE ARCHIBALD:
Yes, more the pity. So when these requests are
sent without cookies and stuff, the question we
get a lot is, why do we need an opt in if
it's sent without cookies? SURMA: Yeah. JAKE ARCHIBALD: And the
problem is intranets, because they're not
protected with cookies. SURMA: True. JAKE ARCHIBALD: IoT devices
all around your house. A lot people will run dev
servers that have seat-- SURMA: Yeah. JAKE ARCHIBALD: Right. And so, you don't want--
if you're visiting a site, for me to just be able
to go to 1270011-- SURMA: Yeah, go to my router
web interface and do shenanigans with it. JAKE ARCHIBALD: Exactly, yeah. SURMA: Yeah. JAKE ARCHIBALD: So this
is almost always safe. SURMA: Except when it isn't. JAKE ARCHIBALD: So the rule is-- I would say the rule is, go
to the URL in a incognito tab so there's no cookies
there and look at it. And if you are happy with
the world seeing that-- SURMA: From your phone,
on mobile internet. JAKE ARCHIBALD: Well, no,
from whatever connection that you can access it from. So if you access your
router and it says your name on it in an incognito
tab, then you're like, I'm unhappy with that, so it
shouldn't have this header. But if you're happy with
the content and the source, you can put that header on it. That is the vast majority
of stuff on the web. SURMA: But nobody's following
that guidance, Jake. Because we've tried-- JAKE ARCHIBALD: That's why
I'm saying it right now. I'm hoping that
everyone's going to go, oh, I'll go and add
it to all my stuff. You know? SURMA: Nobody is, let's be real. JAKE ARCHIBALD: Right. Let's get back to these. So I was saying that this is
a huge mistake for the web. SURMA: Yo. JAKE ARCHIBALD: Yo. Yo, what up? This up. [LAUGHTER] Am I cool? Am I cool now? SURMA: If you weren't
already white, you would be so much
whiter right now. JAKE ARCHIBALD: Impossible. I feel like I'm going
red, I'm embarrassed. Right. So we got this problem
here that, you know, you've got a URL that gets
the current user's avatar. Now, I can do a load event
to tell if this loads. And by that, I can determine
you are locked into example.com. Bad. SURMA: Oh, yeah. OK. JAKE ARCHIBALD: Right? SURMA: I see where you're going. JAKE ARCHIBALD: So this -0,
this is a sort of convention. - SPEAKER 2: Dash-0. JAKE ARCHIBALD: Dash-0, hello. Dash-0, that's my rap name. SURMA: [LAUGHS] JAKE ARCHIBALD: So, yeah. We've got that -0, it's
the original avatar the user uploaded. But then from that, I can
get the width and height, and now that's user
identifiable data. SURMA: Potentially. JAKE ARCHIBALD:
Because that's more likely to be unique
than that other stuff if it's the original
version they uploaded. This is all leaking of data
that shouldn't really happen. It does, thanks to these
bad mistakes that were made. And we're only recently
started to fix some of these. SURMA: I mean,
it's a hard problem because backwards
compatibility is one of the uppermost
goals on the web. JAKE ARCHIBALD: Absolutely. SURMA: Just breaking that
will probably break-- or changing that will break a
good amount of existing sites. JAKE ARCHIBALD: Or will it? Or will it? So this is one of the fixes,
you put in your cookie. So this is how the site would
deal your log in cookies, you've got your
session ID or whatever. But look at this. SURMA: Lax. JAKE ARCHIBALD: Same site lax. And what this means is,
only send this cookie if the request
came from my site. SURMA: OK. JAKE ARCHIBALD: So that means
it would not be sent with this. If this is on
evil.com, or whatever, the session cookie would
not go along with this, so that this would
always fail to load. Or then you would get-- SURMA: Right. But now that site has
been broken, which-- JAKE ARCHIBALD:
Well, not really. Well, only if it expected
to be able to display avatars on oversight. SURMA: Which was reasonable
to expect, right? JAKE ARCHIBALD: Some-- maybe. But then, well-- if you-- I would say not, right? You don't want a single
URL to deal out your avatar because you're logged in. SURMA: Probably. I mean-- JAKE ARCHIBALD: Because
it's an information leak. There are cases where you
want that, in which case you need to do something else. And you probably need to
change your code right now, because Chrome 80 made a change. SURMA: Oh, yeah. JAKE ARCHIBALD: We've decided
that if this says nothing about same site cookies, we are
going to assume same site lax. SURMA: Yeah. JAKE ARCHIBALD: Actually, no. We filmed this
episode a month ago, and a lot has changed
in the world since then. This cookie change that
we're talking about actually broke a
few important sites like government sites
and shopping sites, and we felt like now especially
is a bad time to be doing that. So we've actually
rolled the change back. We're still going to
be doing it eventually, but we've rolled
it back for now. Check out the link
in the description for more details on that. And in the meantime,
back to the episode. So that means, yeah, if you
have one of those services where you want people to
be able to log-- it's not going to work unless
you go in and say, same site. SURMA: Doesn't lax
stand for relaxed? Like the-- JAKE ARCHIBALD: Yes, it does. SURMA: So there is also
an even stricter version. JAKE ARCHIBALD: There
is a stricter version. SURMA: Oh, wow. JAKE ARCHIBALD: The
stricter version works for navigations as well. So even if you navigate
from site A to site B, it will not send
site these cookies. SURMA: Interesting. JAKE ARCHIBALD: That is strict. Which is really-- SURMA: So if have a
link, here, go to GitHub and you press the link-- JAKE ARCHIBALD: You
would be logged out if they used same site strict. SURMA: Interesting. JAKE ARCHIBALD: Which is why
lax is really the simplest one to use, unless
you want to go above and beyond for some
certain bits and pieces. So yeah, Chrome 80
made this change. Firefox is going to as well. But same site cookies
in general, well supported across
all of the browsers. SURMA: Yup. JAKE ARCHIBALD: And it also
solves this problem, which you mentioned earlier on as well. SURMA: Yeah. JAKE ARCHIBALD: Where I can
have a form and I can submit it, but even though this
is a full navigation, it won't send those cookies
even if there's lax. Right? SURMA: Yeah. JAKE ARCHIBALD: It's fine. But what if you can't
do that for some reason? What if you can't change
your cookies or whatever, how can you protect
yourself from this? This is SRF, this is, yeah. SURMA: Yes, with CSRF,
tokens and stuff. JAKE ARCHIBALD: You can use
the tokens, they're a horror. SURMA: It's hard. It's annoying. JAKE ARCHIBALD: There is
a way you can do it in-- I wouldn't say modern browsers. I mean, for quite a while
now, there's much easier ways. Another thing you sort of
alluded to, this header. This header was originally
designed for CORS but we've started
adding it-- well, we've since added it to
lots of other requests. SURMA: Yeah. I don't think I've ever seen
one without it, to be honest. JAKE ARCHIBALD: A GET request. SURMA: The first
navigation, yeah. Because-- JAKE ARCHIBALD: And
all GET requests. A CORS GET request will have it,
all other GET requests won't. SURMA: Interesting. JAKE ARCHIBALD: The reason
is backwards compatibility. There was enough
servers out there that were using the
presence of this to decide it was a CORS request. SURMA: Of course they did. OK, sure. JAKE ARCHIBALD: Yeah. SURMA: Sure. JAKE ARCHIBALD: Exactly. So it's added to post
requests and all of that. It's just non CORS GET requests
don't have this header. SURMA: Right. JAKE ARCHIBALD: But it doesn't
matter, because it was a post, so you're fine. So you can just check
to see that this is the origin you're expecting. SURMA: On the code
for your post handler, you say, must have the
origin header, and if so, not doing it. JAKE ARCHIBALD: Exactly. SURMA: Yeah, makes sense. JAKE ARCHIBALD: Yeah. And that's a nice
easy way, you don't need all of the the SRF
tokens and all that kind of stuff, nice easy way. Another example. So again, I can
use the load event to know that you
work at example.com. Or you are in a position
where you have access to their intranet, because
the logo loaded, didn't it? SURMA: It did. JAKE ARCHIBALD: And this is
not something that is typically solved with cookies. A lot of intranets
assume they're safe just because they're
on an internal network. They're not, but they do. Right? SURMA: Yeah. JAKE ARCHIBALD: So here I'm
detecting quite a lot about you as a user. How do we solve this? This is CORP. So this
is a header that you add onto the image
thing that says, this can only be
embedded same-site. SURMA: Ah. OK, so if you use this resource
on anything but the same site, it will just-- JAKE ARCHIBALD: Fail to load. SURMA: OK. JAKE ARCHIBALD: Yeah. So you would look
like you were not within the CORP,
the example.com. It would just look like you
didn't have access to that. SURMA: That makes sense. JAKE ARCHIBALD: So there you go. Next problem. Now, this is a case where-- this wouldn't be solved
by same-site cookies. SURMA: Because you would
never put a resource policy header on an HTML file? JAKE ARCHIBALD: Well, so you
could, but you might not, or you might have
forgotten or something. A lot of servers-- I mean, many servers out
there have not done this. SURMA: Yeah. JAKE ARCHIBALD: Obviously
this is not going to load. SURMA: No. JAKE ARCHIBALD: But it is
going to bring this HTML file into the process. SURMA: Ah, and then we're-- JAKE ARCHIBALD: It means the
coding is done in process. SURMA: Yeah. And then we're back
in Spectre land. JAKE ARCHIBALD:
Spectre, Meltdown, those CPU bugs that will let you
hammer away at certain things and start maybe trying
to read some of the data. So this is a problem,
that is fixed by CORB. There it is, look at it. It's beautiful. This is Cross Origin
Read Blocking. I had to memorize
that, because I knew I was going to get that wrong. SURMA: So it's not resource
blocking, no, no, it's read blocking. JAKE ARCHIBALD: Read blocking,
definitely read blocking. And how this works
is, as part of fetch, before things entered
the process, what it does is it looks at
particular mine types, it looks to see if it has
the no-sniff header on, and it can get
straight to it then. But Chrome will also do things
like, if this looks like HTML and it's not a CORS request,
not letting it through. SURMA: Oh, so it
prevents it from ever getting to the process. JAKE ARCHIBALD: Yeah. SURMA: But it has to be
a header on the response? JAKE ARCHIBALD: No, so-- SURMA: Oh, so CORB
is just a technology. JAKE ARCHIBALD: CORB. SURMA: CORB. JAKE ARCHIBALD: Oh, I
feel like I'm going mad. CORB is just like a-- SURMA: A feature in Chrome. JAKE ARCHIBALD: Yes. Well, yeah. SURMA: It's not like CORB
is in the header, or-- JAKE ARCHIBALD: No,
it's not a header. It's in the fetch spec. And in the fetch spec
version, you have to do some-- you have to have no-sniff
on the response to say, don't look at this to see
if it's an image or not. But you see, when it's
got no-sniff and-- SURMA: So it knows
if you're saying, I guarantee that I set
the correct mine type on the content type header. JAKE ARCHIBALD: Yes, exactly. And then it just goes, HTML
cannot be a sub resource. Gone. SURMA: Gotcha. JAKE ARCHIBALD: I mean, if
it's a CORS request, it can. But you know, this code
isn't run for CORS requests. SURMA: OK. JAKE ARCHIBALD: So, yeah. What will happen is it
will look at and go, this-- and Chrome will do extra
sort of sniffing around it as well, and go, oh, this
looks a bit like HTML. I'm just not going
to let this through. It does the same with JSON,
does the same with XML. SURMA: I wouldn't
let JSON through. JAKE ARCHIBALD: Yeah, exactly. There you go. Final one, here you go. SURMA: COEP. JAKE ARCHIBALD: This is COEP. CO-EP, I've heard it pronounced. Yeah. And so this is
something that you would use on your HTML page. SURMA: And COEP requires CORB. JAKE ARCHIBALD: Yes, it does. Are you following along? There's going to be
a test after this. Hope you're concentrating. And what you're saying here,
is you're making a declaration that everything on
your page is either going to be CORS or authorized
by some other means. That site is going to
opt into including it, and the opt in would
be using the CORP, but a specific
opt-in to saying this can be embedded cross-origin. SURMA: OK. So this would-- then if-- wait, but hold on. Images still work if they had
no-sniff and the correct mine type. JAKE ARCHIBALD: Yes,
but now if you've got this header on your page,
they will start failing. SURMA: Oh, accept-- JAKE ARCHIBALD:
Because you're saying, I am saying I am opting
into this stricter model. SURMA: On a per
sub resource basis. JAKE ARCHIBALD: On a
per sub resource basis. And the reason for that is
to opt into more powerful features, because we now know-- SURMA: Right. JAKE ARCHIBALD: Once
you've done this, you're in a position where
you don't really have anything to Spectre Meltdown. SURMA: Yeah. JAKE ARCHIBALD: Right? So that's the point
where we can go, oh, we can give you
high resolution timers. Oh, we can give you-- SURMA: But only if-- JAKE ARCHIBALD: --a shared array
buffer, that sort of stuff. SURMA: If we can
guarantee that there's no sensitive data
in your process. JAKE ARCHIBALD: And this
enforces that guarantee. SURMA: So if I
remember correctly-- and I'm excited about
this not because it's so easy to understand,
but because I think this is the headers that
would allow us to bring shared array buffers back. JAKE ARCHIBALD: That is it. SURMA: For everyone. JAKE ARCHIBALD: It
is exactly that. SURMA: Yes. JAKE ARCHIBALD: Yes. Because that high resolution
time, it's all of that stuff that we've had to take out
because of Meltdown, Spectre, it can come back. SURMA: Because if
and when we get this, we'll also get threats for
wireless and all this stuff on mobile, on the
other browsers. JAKE ARCHIBALD: Yep. SURMA: So in that sense, yay. JAKE ARCHIBALD: Yay, excellent. SURMA: In terms of
understanding it, whew. JAKE ARCHIBALD: And that
is pretty much everything I wanted to talk about. Because we can't--
we've got quite a lot. But I want to
acknowledge that there's a-- we looked at a certain
class of problems here. And this is where one
site is stealing stuff from another site, or
making the other site do things it didn't want to do. And that makes the user
sad, because they lose data, or they have their
privacy invaded. There is a whole other
class of problems where site A and site B,
totally fine with sharing data, but the user is sad about it. SURMA: Oh, that's
the tracking problem. JAKE ARCHIBALD: This is
cross-site tracking, and-- SURMA: This is not that,
that is a separate problem. JAKE ARCHIBALD: And I want to
spend a whole episode on that at some point, because there's
a lot of interesting things happening in that space. So that's a shout forward
to another episode some other time. SURMA: Oh, stay
tuned on that one. JAKE ARCHIBALD: But
that's enough for now. SURMA: OK, bye. JAKE ARCHIBALD: We've had
a guest in the studio. He's about to he's about
to arrive, here he comes. He's very-- just
to let you know, someone is very carefully
dodging cameras and lighting equipment in order to do this. But look, this is the
official show dog. Look, look, this is Watson. And Watson is going to
be very sad if you don't click Subscribe right now. Aren't you, Watson? SURMA: And click the bell. JAKE ARCHIBALD:
Aren't you, Watson? SURMA: I would love it if
he just barked at your face right now. He's like, [BLEEP] off. JAKE ARCHIBALD: Even
the dog's yawning now. The dog's bored. SURMA: He's very excited. JAKE ARCHIBALD: I'm bored. Aw, good boy.
