WEBVTT 00:00.000 --> 00:15.000 Great. Thank you everyone for joining. Welcome to the talk modern network 00:15.000 --> 00:22.000 protocols. Today we're going to discuss what's next for Firefox and a bit of a perspective 00:22.000 --> 00:29.000 obviously from our end on what is next for the web. 00:29.000 --> 00:36.000 I'm Max, I'm a software developer at Mozilla. I work on Firefox's networking stack and 00:36.000 --> 00:43.000 I focus mostly on HP3 and Quick. Both protocols have quite some mention here in this talk 00:43.000 --> 00:49.000 and then on various protocols around it related. You might have seen me here talking about peer 00:49.000 --> 00:54.000 to peer software in the past and I've also been working a bunch on Prometheus and it's integration 00:55.000 --> 01:00.000 If you want to learn more about any of this, there's my home page here, also feel free to reach out. 01:00.000 --> 01:04.000 And with me, I brought my colleague Andrew and Andrew, who are you? 01:04.000 --> 01:08.000 My name is Andrew. I'm the performance engineer on Firefox. 01:08.000 --> 01:13.000 So that means I work to try to make Firefox faster and faster. I'm really interested in field experiments. 01:13.000 --> 01:17.000 So these are like AB studies. I'm very interested in networking performance. 01:17.000 --> 01:22.000 And in particular how the protocols that we're going to talk about today actually behave 01:22.000 --> 01:28.000 in the very complicated Firefox runtime. And then beyond that, I'm actually even more interested in how 01:28.000 --> 01:39.000 they perform for Firefox users at the real world. 01:39.000 --> 01:44.000 Okay. So I have two themes for you today in this talk. 01:45.000 --> 01:51.000 And the major one is HTP S, the thin waist of the internet. 01:51.000 --> 01:55.000 As in the shared protocol of all the applications that we have out there. 01:55.000 --> 01:58.000 And this is very much the case today. 01:58.000 --> 02:04.000 More and more of the internet is moving towards HTTP and a lot of it is already based on it. 02:04.000 --> 02:08.000 And there are of course a million reasons out there. 02:08.000 --> 02:12.000 We very much favor the fact that it's very consistent. 02:12.000 --> 02:17.000 It's extensible as in it's very easy to program against and to extend. 02:17.000 --> 02:22.000 And then more importantly, and that is the second theme of this talk. 02:22.000 --> 02:31.000 It gives us very strong extensible security model around how web applications behave. 02:32.000 --> 02:38.000 And given the fact that HTTP is just above the encryption layer, which will go into a lot, 02:38.000 --> 02:40.000 it's very hard to sensor. 02:40.000 --> 02:45.000 As in if you see on the wire a bunch of HTTP traffic, but you can't look inside. 02:45.000 --> 02:50.000 It's very hard to filter certain things, but not filter others. 02:50.000 --> 02:52.000 So those four things are really important for us. 02:52.000 --> 02:58.000 And that's why we see very much HTTP to continue to be the thin ways of the internet. 02:58.000 --> 03:02.000 And more and more of the internet to depend on HTTP. 03:02.000 --> 03:07.000 And for us to move more and more on top of HTTP. 03:07.000 --> 03:15.000 And we will talk about a lot of protocols that we plan on moving on top of HTTP. 03:15.000 --> 03:21.000 Again, mostly for the security model, as in buying into the entire web security stack. 03:21.000 --> 03:24.000 And then we'll talk about a couple of protocols. 03:24.000 --> 03:30.000 Maybe though, like for example, a quick new development that then enables a lot of these applications on top of that, 03:30.000 --> 03:35.000 to actually run in a performance way. 03:35.000 --> 03:42.000 Okay, so in terms of starting off with HTTP all the things, we'll start with DNS. 03:42.000 --> 03:48.000 So DNS over HTTPS, which we we call though, is pretty much as it sounds, 03:48.000 --> 03:54.000 we make the DNS requests through an encrypted HTTPS connection right to the DNS server. 03:54.000 --> 03:57.000 And you can see the layer diagram here. 03:57.000 --> 04:01.000 So the big benefits for the user, of course, is initially private seed, 04:01.000 --> 04:04.000 because otherwise it's generally sent over to your text. 04:04.000 --> 04:12.000 Integrity comes with this because there's a whole series of DNS spoofing and exploits that are basically completely cut off. 04:12.000 --> 04:17.000 And then the censorship resistant properties of dough are quite strong naturally. 04:17.000 --> 04:21.000 And we actually see that in the field as well. 04:21.000 --> 04:25.000 But so one question looking at the layer diagram here. 04:25.000 --> 04:29.000 It's obviously here, it's implemented over HTTP 1, 2, and 3. 04:29.000 --> 04:33.000 It's obviously more complex than our legacy DNS 53. 04:33.000 --> 04:36.000 So you probably have questions about the performance. 04:36.000 --> 04:39.000 And we'll talk about that a little bit in a moment. 04:39.000 --> 04:45.000 But one thing I want to highlight is that with quick zero RTT is actually identical overhead. 04:45.000 --> 04:55.000 And you're the identical overhead to legacy DNS, and that we're just sending off a datagram with our question to the server. 04:55.000 --> 04:56.000 Okay, don't perform it. 04:56.000 --> 05:01.000 So as you just saw on the stack, it's a lot more complicated than what your OS resolver does, 05:01.000 --> 05:04.000 because it's a lot more work than with all that security and integrity. 05:04.000 --> 05:07.000 So it does take a lot of work to make it as fast. 05:07.000 --> 05:13.000 And I want to highlight some of the work that we've done to achieve parity with traditional DNS. 05:13.000 --> 05:19.000 So here we are looking at dough versus the OS resolver in Canada in the United States. 05:19.000 --> 05:23.000 These are two countries where we're able to do by default. 05:23.000 --> 05:25.000 The red is Canada. 05:25.000 --> 05:30.000 The green is the United States, and the blue is the legacy DNS. 05:30.000 --> 05:34.000 So as you can see, we've been working really hard to make it as fast as possible. 05:34.000 --> 05:36.000 And I just want to highlight two of the improvements. 05:36.000 --> 05:40.000 One area of optimization, then we do this in Firefox, 05:40.000 --> 05:45.000 and also working with the dough server partners, is to make sure that we have a long lived connection. 05:45.000 --> 05:52.000 Because if we have to reestablish the connection, there's a lot of additional work in that obviously introduces latency into the flow. 05:52.000 --> 05:55.000 So that's responsible for a lot of the improvements there. 05:55.000 --> 06:01.000 And one other source of improvements that'll highlight is some of the dough server packages. 06:01.000 --> 06:06.000 Did not have the TCP socket option, TCP, and no delay set. 06:06.000 --> 06:10.000 So in that case, the client would be sitting there very hungry for those bytes in the server, 06:10.000 --> 06:12.000 or would just be sort of waiting at its time. 06:12.000 --> 06:14.000 So with that fixed, we got some really big improvements. 06:14.000 --> 06:17.000 And I'm really happy to say that for these clients, 06:17.000 --> 06:23.000 we are delivering security and SS fast as traditional DNS. 06:23.000 --> 06:25.000 Oh yes, and DNS adoption. 06:25.000 --> 06:27.000 Here we have a little bit of space to grow. 06:27.000 --> 06:31.000 So here we're looking at all DNS resolution through Firefox. 06:31.000 --> 06:35.000 And about dough is responsible for about 12% in the rest, 06:35.000 --> 06:37.000 go through the OS resolver. 06:37.000 --> 06:39.000 So we are working on that. 06:39.000 --> 06:45.000 And the spoiler is that we will be improving this number over time. 06:45.000 --> 06:50.000 So now with DNS established, we have the address to the server. 06:50.000 --> 06:53.000 So it's just up to the matter of connecting. 06:53.000 --> 06:56.000 And it goes to the scheme. 06:56.000 --> 07:00.000 This is quite encouraging, I think, in that actually less than 2%. 07:00.000 --> 07:04.000 A open web traffic through Firefox goes through HTTP. 07:04.000 --> 07:09.000 So unencrypted HTTP is actually mostly just used for local domains, 07:09.000 --> 07:13.000 so corporate networks, web servers, and stuff like that. 07:13.000 --> 07:17.000 So I'm pretty happy about this because it's encouraging. 07:17.000 --> 07:20.000 And other protocols where I hope we can move in this direction. 07:20.000 --> 07:26.000 It's effectively, I think, about complete. 07:27.000 --> 07:31.000 When we have, we do the DNS resolution, right? 07:31.000 --> 07:33.000 We have the IP address as in reset. 07:33.000 --> 07:36.000 We have some way to then connect and connect. 07:36.000 --> 07:38.000 In a particular way, the HTPS. 07:38.000 --> 07:44.000 There is one small caveat to HTPS, in particular to the TLS 1.3 handshake. 07:44.000 --> 07:49.000 Namely, when the client reaches out to the server to establish the connection, 07:49.000 --> 07:51.000 it sends the domain. 07:51.000 --> 07:54.000 So in the example, for example, of Wikipedia.com, 07:54.000 --> 07:58.000 in that client-low, in clear text to the server. 07:58.000 --> 08:00.000 Now, great. 08:00.000 --> 08:04.000 We do the encryption afterwards, but we reveal who word 08:04.000 --> 08:05.000 going to talk to. 08:05.000 --> 08:09.000 And if you put yourself in the shoes of a sensor, 08:09.000 --> 08:14.000 they can very easily look at the first client-low 08:14.000 --> 08:18.000 and then find the S&A as an I at the server name indicator, 08:18.000 --> 08:22.000 in this case, Wikipedia.com, and then sensor based on that, 08:22.000 --> 08:23.000 as in drop of the entire flow. 08:23.000 --> 08:25.000 And that is not great. 08:25.000 --> 08:29.000 And we very much see that being used out there in the wild on Firefox 08:29.000 --> 08:32.000 to sensor Firefox users. 08:32.000 --> 08:34.000 How can we fix this? 08:34.000 --> 08:37.000 There is this extension called encrypted client-low. 08:37.000 --> 08:41.000 The idea is we fetch a public key from DNS as well. 08:41.000 --> 08:46.000 And then we use that public key to encrypt the majority 08:46.000 --> 08:48.000 off the client-low to the server. 08:48.000 --> 08:51.000 And that way, we encrypt the S&A as well, 08:51.000 --> 08:53.000 which is part of the client-low. 08:53.000 --> 08:58.000 And that way, no one on the path can see the S&A itself. 08:58.000 --> 09:01.000 Obviously, they can still see the destination IP address, 09:01.000 --> 09:04.000 so they can make predictions based on that, 09:04.000 --> 09:06.000 but they cannot see the S&A. 09:06.000 --> 09:08.000 And this is especially important for CDNs, 09:08.000 --> 09:10.000 where a lot of CDNs actually operate 09:10.000 --> 09:12.000 behind the single IP address, 09:12.000 --> 09:16.000 and then low balance to their customers, 09:16.000 --> 09:17.000 simply based on the S&A. 09:17.000 --> 09:20.000 So if we get that S&A encrypted, 09:20.000 --> 09:23.000 that gets us the full pipeline off. 09:23.000 --> 09:25.000 I do encrypted DNS. 09:25.000 --> 09:26.000 I get the IP address back. 09:26.000 --> 09:28.000 I do the connection to the IP address. 09:28.000 --> 09:31.000 I encrypt the S&A in my client-low, 09:31.000 --> 09:34.000 and from there on everything on this fully encrypted. 09:34.000 --> 09:36.000 So then we have the full pipeline. 09:36.000 --> 09:39.000 Now, this sounds amazing. 09:39.000 --> 09:43.000 And ideally, I would like the story of we start with HTTP, 09:43.000 --> 09:47.000 and then we start end up with only 2% of the internet being unencrypted. 09:47.000 --> 09:51.000 We are very much at the beginning for ECH. 09:51.000 --> 09:53.000 Adoption is very low. 09:53.000 --> 09:56.000 When Firefox does a TCP connection, 09:56.000 --> 10:00.000 in roughly 0.3% of those TCP connections, 10:00.000 --> 10:01.000 we do ECH. 10:01.000 --> 10:03.000 In all the cases, 10:03.000 --> 10:06.000 we, for example, don't have the public key available 10:06.000 --> 10:08.000 and various other reasons why not. 10:08.000 --> 10:10.000 So adoption is still stalling, 10:10.000 --> 10:14.000 and we want to push a rollout of this a lot more. 10:14.000 --> 10:18.000 Now, the optimistic part, I guess, is whenever we do do it 10:18.000 --> 10:22.000 on those 0.3% we do succeed, which is wonderful. 10:22.000 --> 10:25.000 All right. 10:25.000 --> 10:27.000 So we have the DNS part. 10:27.000 --> 10:30.000 We have the handshake part. 10:30.000 --> 10:33.000 Now, we want to talk about another protocol 10:33.000 --> 10:37.000 that we are very excited about, which is quick NHB3. 10:37.000 --> 10:40.000 You see this here on the very right. 10:40.000 --> 10:44.000 You see basically the architecture of the internet. 10:44.000 --> 10:47.000 You have IP at the bottom, then TCP, 10:47.000 --> 10:49.000 and HTTP1 and HTTP2 on top of that. 10:49.000 --> 10:51.000 That's very much the classic internet. 10:51.000 --> 10:55.000 Then giving you the HTTP semantics on the very top, 10:55.000 --> 10:58.000 so get put post and so on to the application. 10:58.000 --> 11:02.000 And now, in recent years, folks have developed another pillar 11:02.000 --> 11:05.000 on the very right, on top of HTTP stack and quick, 11:05.000 --> 11:08.000 which gives us, for example, reliability guarantees, 11:08.000 --> 11:10.000 and then HTTP3 on top of that. 11:10.000 --> 11:13.000 And then still the same abstraction layer for ever application, 11:13.000 --> 11:16.000 so they can move seamlessly over. 11:16.000 --> 11:20.000 In general, quick tries to be the general purpose transport protocol. 11:20.000 --> 11:23.000 Instead of TCP, it runs on top of HTTP. 11:23.000 --> 11:27.000 We are, again, the theme of this talk. 11:27.000 --> 11:31.000 We're encrypting most of the metadata of quick, for example, 11:31.000 --> 11:33.000 right after the handshake. 11:33.000 --> 11:36.000 Every packet only has two bits that are encrypted. 11:36.000 --> 11:39.000 Everything else is fully encrypted. 11:39.000 --> 11:42.000 We can do various tricks on connection establishment. 11:42.000 --> 11:44.000 We actually have a slide right after that. 11:44.000 --> 11:46.000 We can do both reliable and unreliable delivery, 11:46.000 --> 11:49.000 given that we're on top of HTTP and not TCP, 11:49.000 --> 11:52.000 so we can decide on our reliability guarantees. 11:52.000 --> 11:54.000 Very important for the web. 11:54.000 --> 11:56.000 We have very slow control mechanisms, 11:56.000 --> 11:59.000 and thus are not prone to a headline blocking. 11:59.000 --> 12:01.000 And it's very easy to evolve. 12:01.000 --> 12:04.000 It's very much built to evolve in the future, 12:04.000 --> 12:06.000 and given that it is fully encrypted, 12:06.000 --> 12:08.000 middle boxes cannot metal with it, 12:08.000 --> 12:12.000 and thus there's not going to be a hopefully, 12:12.000 --> 12:14.000 not that much specification like TCP today, 12:14.000 --> 12:18.000 which you basically cannot evolve on the public internet today. 12:18.000 --> 12:21.000 In terms of adoption, 12:21.000 --> 12:25.000 not as good as HGPS way better than the ECH. 12:25.000 --> 12:29.000 We're roughly between 20 and 30% for Firefox today. 12:29.000 --> 12:33.000 Other players on the internet see significantly higher adoption, 12:33.000 --> 12:34.000 so it is possible. 12:34.000 --> 12:36.000 We have various upcoming changes, 12:36.000 --> 12:38.000 which actually done a drive up HTTP3, 12:38.000 --> 12:41.000 and thus quick adoption on the internet. 12:43.000 --> 12:46.000 Yeah, I mentioned the handshakes, 12:46.000 --> 12:48.000 and that is very relevant for web traffic. 12:48.000 --> 12:52.000 On the very left here, you see the classic model of TCPTLS. 12:52.000 --> 12:54.000 You have a TCPZin, TCPAC. 12:54.000 --> 12:57.000 You have the client low, you have the server low, 12:57.000 --> 13:00.000 and then you just send the fin and then the actual data. 13:00.000 --> 13:04.000 You have two full RTTs till you send the request, 13:04.000 --> 13:08.000 and then the request response comes back in the third RTT. 13:08.000 --> 13:11.000 That is very long, especially in the web context, 13:11.000 --> 13:15.000 where users can feel 10 to 100 milliseconds. 13:15.000 --> 13:18.000 On the other hand, quick on the first connection, 13:18.000 --> 13:23.000 it combines the transport part and the TLS part into one round trip, 13:23.000 --> 13:27.000 so you have the quick initials and the client low, 13:27.000 --> 13:30.000 and then the response from the server, 13:30.000 --> 13:32.000 and then on the next one, you already send the request. 13:32.000 --> 13:34.000 So you save one round trip. 13:34.000 --> 13:36.000 That is on the first connection. 13:36.000 --> 13:39.000 On the second connection, you can make use of something called 13:39.000 --> 13:41.000 resumption token, same quick, 13:41.000 --> 13:44.000 where we can make use of previous connection 13:44.000 --> 13:47.000 cryptographic material to then make a connection in zero RTT. 13:47.000 --> 13:49.000 This is the thing, and we mentioned earlier, 13:49.000 --> 13:52.000 which, for example, makes DOH, 13:52.000 --> 13:54.000 viable in terms of performance, 13:54.000 --> 13:57.000 because all of us, and we can compete to vanilla UDP, 13:57.000 --> 13:59.000 which also sends the request right away. 13:59.000 --> 14:02.000 But, by the way, we get encryption for free. 14:02.000 --> 14:06.000 All right. 14:06.000 --> 14:08.000 So that is the theory. 14:08.000 --> 14:12.000 These protocol versions work out in practice. 14:12.000 --> 14:15.000 So here we are looking at time to request start, 14:15.000 --> 14:19.000 looking at Firefox for Android 75th percentile. 14:19.000 --> 14:21.000 So this is how long it takes when Firefox decides 14:21.000 --> 14:24.000 it wants to fetch a resource until the point where it is actually 14:24.000 --> 14:27.000 able to make that request send the get, for instance. 14:27.000 --> 14:31.000 So this includes DNS, which is independent of the protocol version, 14:31.000 --> 14:33.000 and that how long it takes to establish a connection 14:33.000 --> 14:36.000 and do a TLS handshake for all these versions. 14:36.000 --> 14:40.000 And actually, you can see it is actually quite beautiful 14:40.000 --> 14:42.000 in that as the protocol versions increase, 14:42.000 --> 14:45.000 the performance increases drastically. 14:45.000 --> 14:50.000 We are going from about 320 milliseconds for HTTP1 connections. 14:50.000 --> 14:55.000 Down to about 250 milliseconds, actually 260 for HTTP2 14:55.000 --> 15:00.000 and about 130 milliseconds for HTTP3. 15:00.000 --> 15:05.000 So that is actually quite happy about this to see this progression. 15:05.000 --> 15:08.000 And I should note that this is observational data, right? 15:08.000 --> 15:10.000 So there is a lot of factors at play. 15:10.000 --> 15:13.000 For instance, top sites will tend to use HTTP3, 15:13.000 --> 15:19.000 so they are making use of CDN for instance to reduce their latency. 15:19.000 --> 15:22.000 However, in the field, our rather in lab tests, 15:22.000 --> 15:25.000 when we run the same simulation testing, 15:25.000 --> 15:28.000 the same server against through different protocol versions, 15:28.000 --> 15:30.000 we do see a very similar pattern. 15:30.000 --> 15:33.000 So HTTP3 is faster. 15:33.000 --> 15:36.000 And then lastly, if you're curious about the little spikes on there, 15:36.000 --> 15:38.000 those correspond up to weekends. 15:38.000 --> 15:41.000 So the web is actually faster on weekends. 15:41.000 --> 15:44.000 Although probably not this weekend, not here, 15:44.000 --> 15:46.000 but in general. 15:50.000 --> 15:55.000 Okay, so in terms of other protocols, 15:55.000 --> 15:58.000 that we are heavily investing into. 15:58.000 --> 16:00.000 Another one is web transport. 16:00.000 --> 16:04.000 Web transport is the successor to web sockets. 16:04.000 --> 16:06.000 Web sockets for those familiar, 16:06.000 --> 16:09.000 a very directional bite stream, single bite stream, 16:09.000 --> 16:12.000 and web transport lifts all kinds of different properties 16:12.000 --> 16:14.000 that we get from quick. 16:14.000 --> 16:17.000 So for example, unreliable delivery, if we wanted, 16:17.000 --> 16:19.000 on with the level above HTTP, 16:19.000 --> 16:23.000 and thus make those mechanisms available to web applications. 16:23.000 --> 16:25.000 I'm not going to go into much detail here, 16:25.000 --> 16:28.000 because I have a talk right after this in browser different. 16:28.000 --> 16:31.000 If you're interested, moving rooms is very, very difficult, 16:31.000 --> 16:34.000 but you can watch the recording afterwards. 16:36.000 --> 16:38.000 Another protocol here, 16:38.000 --> 16:42.000 and kind of funny with our theme of HTTP being within waste, 16:42.000 --> 16:43.000 is mask. 16:43.000 --> 16:45.000 Mask is a proxy protocol. 16:46.000 --> 16:49.000 We mentioned earlier the introduction of quick and HTTP3 16:49.000 --> 16:53.000 gives all kinds of different new semantics to the web, 16:53.000 --> 16:58.000 and those really make the use case of proxy other protocols 16:58.000 --> 17:02.000 on top of HTTP viable. 17:02.000 --> 17:07.000 For example, leveraging quick unreliable datagrams and things to grab. 17:07.000 --> 17:13.000 Now, we're moving more and more on top of HTTP, 17:13.000 --> 17:16.000 as I said before, one of the reasons, for example, 17:16.000 --> 17:17.000 being censorship resistance. 17:17.000 --> 17:19.000 If everything on the internet looks like HTTP, 17:19.000 --> 17:21.000 and you can't look inside of it, 17:21.000 --> 17:23.000 then it's very hard to censor it. 17:23.000 --> 17:27.000 And so how about we proxy UDP, 17:27.000 --> 17:30.000 TCP, IP, maybe even Ethernet, 17:30.000 --> 17:32.000 on top of HTTP, 17:32.000 --> 17:36.000 and can thus move more and more of the internet in this secure model. 17:36.000 --> 17:39.000 Now, obviously, all of this, the level of tongue and cheek, 17:39.000 --> 17:42.000 is we now moved everything from the bottom, 17:42.000 --> 17:43.000 even on the top. 17:43.000 --> 17:47.000 But it is very much a large effort across various companies 17:47.000 --> 17:50.000 at the ITF, as well, to move proxy, 17:50.000 --> 17:54.000 to secure model in the web context. 17:57.000 --> 17:59.000 Two things I want to mention here, 17:59.000 --> 18:01.000 mask is usually deployed in two different ways. 18:01.000 --> 18:03.000 There's the single-hop model, 18:03.000 --> 18:05.000 so you have a client proxy in destination. 18:05.000 --> 18:07.000 The proxy knows the source in the destination, 18:07.000 --> 18:09.000 but not the actual content. 18:09.000 --> 18:11.000 You establish a connection secure connection over it. 18:11.000 --> 18:14.000 And then you have the two-hop model for those using Apple, 18:14.000 --> 18:16.000 I Cloud Private Relay, 18:16.000 --> 18:17.000 that's the model they are using, 18:17.000 --> 18:19.000 where you have actually two proxies in between, 18:19.000 --> 18:21.000 one only knowing the source, 18:21.000 --> 18:23.000 one only knowing the destination. 18:23.000 --> 18:24.000 If you drive this further, 18:24.000 --> 18:25.000 and add more and more proxies, 18:25.000 --> 18:27.000 you eventually end up at the tour 18:27.000 --> 18:30.000 on your rounding model, right? 18:30.000 --> 18:33.000 Under the assumption that the two proxies don't 18:33.000 --> 18:35.000 collude, or the proxie doesn't collude with a destination, 18:35.000 --> 18:38.000 you then have a significant privacy add. 18:39.000 --> 18:43.000 Another one oblivious HTTP basically mask, 18:43.000 --> 18:47.000 but instead of on the connection level on the request level, 18:47.000 --> 18:51.000 so while on mask you cannot correlate 18:51.000 --> 18:53.000 to connections on oblivious HTTP, 18:53.000 --> 18:56.000 you cannot correlate to request to come from the same client. 18:56.000 --> 18:59.000 We're making use of this for telemetry, 18:59.000 --> 19:03.000 where we really don't want to ever have access to the client. 19:03.000 --> 19:05.000 IP, for example, 19:05.000 --> 19:09.000 or there are various efforts to have the extreme case of DH, 19:09.000 --> 19:11.000 where we put a proxy in front of it, 19:11.000 --> 19:12.000 and then the DNS server 19:12.000 --> 19:15.000 doesn't even know about your source IP address. 19:18.000 --> 19:22.000 Okay, so what do we not see happening in the internet? 19:22.000 --> 19:25.000 So far we only discussed the things that we do see happening 19:25.000 --> 19:27.000 and that we have the invested into. 19:27.000 --> 19:30.000 So we don't see engineering efforts 19:30.000 --> 19:33.000 as in maintaining a browser to become any easier, 19:33.000 --> 19:35.000 and we definitely don't see the various protocols 19:35.000 --> 19:37.000 that we already have to go away. 19:37.000 --> 19:39.000 IP, before it's not going to go away, 19:39.000 --> 19:42.000 DNS over UDP and clear text, 19:42.000 --> 19:44.000 I don't have to hope that's going away. 19:44.000 --> 19:46.000 HTTP is not going away. 19:46.000 --> 19:48.000 And then beyond that, 19:48.000 --> 19:52.000 I reached out to various other musala people during lunch, 19:52.000 --> 19:54.000 and was asking, what do you really see 19:54.000 --> 19:56.000 if you want to see happening in the internet 19:56.000 --> 19:58.000 and one funny colleague just said, 19:58.000 --> 20:00.000 hopefully no HTTP before. 20:04.000 --> 20:07.000 So we talked a lot about what we're going to do, 20:07.000 --> 20:09.000 what we're going to invest into. 20:09.000 --> 20:12.000 Now if you like the mission that we're driving here, 20:12.000 --> 20:15.000 what can you do for a healthy internet? 20:15.000 --> 20:17.000 If you're using a browser, 20:17.000 --> 20:20.000 which I assume everyone here does enable DH, 20:20.000 --> 20:22.000 most browsers support it, 20:22.000 --> 20:24.000 do a quick search on how to do that, 20:24.000 --> 20:27.000 that will significantly up your privacy. 20:27.000 --> 20:30.000 If you're operating DNS infrastructure, 20:30.000 --> 20:33.000 please expose a DNS, 20:33.000 --> 20:35.000 DH endpoint, 20:35.000 --> 20:38.000 so to make it accessible for others to query. 20:38.000 --> 20:42.000 And then if you're operating a website, 20:42.000 --> 20:43.000 serve at BHB3, 20:43.000 --> 20:45.000 and if you want to go extra far, 20:45.000 --> 20:48.000 please support ECH. 20:48.000 --> 20:51.000 I'll skip this. 20:51.000 --> 20:53.000 That's all from our end. 20:53.000 --> 20:55.000 If you have any questions, 20:55.000 --> 20:56.000 talk to us. 20:56.000 --> 20:58.000 I don't think we have talked at the time right after this. 20:58.000 --> 21:00.000 Help us build in healthy internet. 21:00.000 --> 21:02.000 This is not only us doing this, 21:02.000 --> 21:03.000 and we're in this together. 21:03.000 --> 21:04.000 We're here in person. 21:04.000 --> 21:06.000 We're reachable via email. 21:06.000 --> 21:07.000 And if that is a big motivator, 21:07.000 --> 21:09.000 we do have stickers. 21:09.000 --> 21:11.000 Quick stickers and so on. 21:11.000 --> 21:12.000 Come find us. 21:12.000 --> 21:13.000 Thank you. 21:13.000 --> 21:16.000 Thank you.