🔒 Improving Privacy with DNS over HTTPS

Hello and welcome to Cloudflare TV. I'm Alissa Starzak. I'm Head of Public Policy at Cloudflare and I'm here today with Marshall Erwin, who is the Chief Security Officer at Mozilla, formerly Head of Trust. And we're here to talk about DNS over HTTPS. But before we even get there, Marshall, I want to ask, as someone who is formerly Head of Trust, currently Chief Security Officer, what does that mean? What do you do? Yeah, you know, it's interesting you say that, because I tend to think of trust as kind of a bad word in our industry. Typically, when you see someone who's Head of Trust like that, it's actually a signal that they're responsible for collecting everyone's data and pretending you don't need to worry about that fact. And I think, oh, I hope not. I hope my job is very different than that, meaning that, you know, what we try to do, and I think we can sort of talk through it in the context of the work on HTTPS is think about all of the things that we need to do to make sure that like, we are really protecting our users from the basic data that we're collecting to the partners that we work with, like Cloudflare to the policies that we need to have in place and making sure that we have all of that in place ahead of time, so that we don't run into a problem and all of a sudden find that we didn't think about the right mechanisms we needed to protect our users. Well, that's actually a great segue, because what I'm curious about is how you first got interested in DNS or HTTPS at all. And so how do you identify those things? And how did you identify it specifically for DOH, as we can call it? Yeah, so we, you know, I think employees from Mozilla and Cloudflare had been working on DNS or HTTPS first in standards bodies like the IETF, going back for some time. Originally, I was brought in by Eric Rescorla, the Firefox CTO, at the point when the technology was close to being standardized. And we were now thinking about doing some initial experiments within the browser with Cloudflare. And I remember very clearly that meeting, when Eric explained to me that your DNS traffic is essentially all in the clear, which I just found remarkable at the time, because we as an industry have made so much progress at encrypting, just generally your web browsing. And the fact that we hadn't, that this was still transmitted in the clear was just remarkable to me and something I maybe should have known, but did not know. And I still think you're alone, actually, I think I think that's a yeah, yeah, I've been sort of struck by the same thing. So at the time, so we, we started to think about some initial experiments where we would essentially provide a default DOH browser in, sorry, a DOH provider in the browser. And initially, it was, like I said, just an interesting experiment that we were considering doing in partnership with Cloudflare. But it was very clear, even at that time, before we thought like what the path was going to be over the next two years, that there were some really important, challenging policy issues associated with providing a default DNS provider in the browser, and ensuring that when a user's data is then going to be provided to a new third party, it was critical to know exactly what what was going to happen with that data, what protections were going to be in place. And so we quickly started this discussion about like, okay, if we're going to do this, what policies do we need to have? And by that policies, I mean, what does the contract with Cloudflare for some of these initial experiments look like? And it, that was a really good conversation that we had that I think we all recognize the policy challenges associated with what we're doing, and built those into the contract from the outset, which was a really good in retrospect, because it meant that when we ran into some challenges with DOH, and particularly the pushback that we had gotten, we had really laid the groundwork from to think about this from the outset about what strong policies we had, we needed to have, that we could just represent those policies publicly. And it really works stood up really well. Because of that, because some of those early conversations with Cloudflare went so well. So so we're gonna get into all that, because that's, that's, to me, that's the fun stuff. I'm the policy person, right? So of course, but I, you know, I think that there are people, I mean, going back to your first point, I think there are people who don't really understand what DNS in the clear means. Can you just give a little bit of background, sort of the, you know, try to explain it to my mother, who is not, who's not, who's not security savvy, or savvy, or Internet savvy at all. Yeah. So there are really, what I think of as kind of two problems with the the current DNS system that we have. One is that your DNS queries are sent in the clear, which is what the DOH protocol attempts to address. And that means that when you type in a URL, the sort of Internet phone book, the DNS, sort of you send your query to another party, and anyone sitting between you and the DNS provider, when your query is sent in the clear, they can look at it and see essentially what you're going to browse to. So that's what it means when your your DNS query is sent in the clear. The other problem, though, and one which we feel like is as important to address, is the fact that you are sending that DNS query to a party, your DNS provider, and you typically have no idea who that party is, exactly what they're going to do with your data. Which again, is so out of step with what the privacy and security properties of the web should be. Like when you disclose your data to a party, you should know who that party is, and what they're going to do with that, that data. And that's not actually the state of play with the DNS today, where you are disclosing your DNS queries to a party that you have no idea who it is, it's going to change depending on whether you're at your home or work or your local Starbucks. And the different DNS providers are going to have a very different set of properties and might be doing something with your data that you're not happy with. So those are kind of the two core challenges that we've always wanted to address. One, the fact that the query itself is in clear text, and therefore available to anyone who's kind of sitting in the middle between you and your DNS provider. And the second problem being that your provider might not be able to up to something that's good, and you might not really want to trust them either. So that gets into the policy pieces. So let's talk through some of them, because they are really interesting questions. So how did you think about what requirements should be in place on that second piece? So how do you decide what is appropriate sets of practices for DNS data, for example? Yeah, so I think the first policy piece that we focused on was the core privacy questions of, okay, your DNS queries are going to be disclosed to a provider, in this case, Cloudflare. And the questions then become, okay, how long is that data going to be retained? And what can the data be used for? So the first question, we take a pretty simple approach, which is like, the data should be retained for as long as is really needed to actually operate the service, right? And then you have a just open conversation with relevant stakeholders who know what they're talking about, about what's really operationally needed to run a DNS service. And while for a lot of DNS services, you won't be able to find how long they retain their data, the fact of the matter is, it isn't retained very long. And so in those early discussions we had, we identified kind of a 24-hour retention period, but that's actually longer than is typically needed by most of these services where the data is often retained at a very ephemeral state for a very short period of time before it's aggregated and the raw data is deleted. And then the second important privacy protection is just that the data should only be used for the purpose of the service rather than being sold or passed on to other third parties, which is pretty, should be pretty sensible policy. But again, surprising that that's not necessarily a standard practice or a standard policy at this point across the industry. I think it's in part because going back to the first part of the conversation, people don't always think of the fact that these are out there or how the information is being used. That's not necessarily something that always comes up. Although we have seen some regulatory pieces in the U.S. over time that have gone back and forth a little bit on that issue, but it's definitely not sort of consistent practice. So what about other policy things? We obviously talked a lot about policy challenges at the time, other things that could come up. So how DNS is used around the world, what the impact might be. Can you talk a little bit about those? Yeah. So there's kind of two other important pieces of the policy. The first one are the transparency requirements and the transparency requirements in our policy are one, there has to be a public privacy notice. Again, that doesn't sound too radical, but the fact is most DNS providers today, you're not going to be able to find a privacy notice that actually attests to the privacy properties of the DNS service. And then the second one, transparency requirement is that there should be a transparency report that documents what law enforcement requests might've been provided to the DNS, sent to the DNS provider. The idea there being this is disclosing something since your browsing data is being disclosed to this party. It's important to know if law enforcement is using that as a mechanism to get data that it needs for its investigations. Now we can't as Mozilla say, like you can't respond to law enforcement requests, but we can say within the bounds of the law, you need to have a transparency report that at least attests publicly to the fact that your resolver might have been subject to some of those requests. So that's the second sort of core policy areas are these transparency requirements. And then the third area, which has proven to be the trickiest, but is really a kind of secondary consideration, at least at first has been blocking provisions. Because again, the value proposition that we thought we were offering with those, it's a core, it's a privacy issue and a security issue about, your data should be encrypted so that it's not in clear text as it's sent, and then it shouldn't be abused. And so we were always focused on solving those problems. But the fact is the DNS is used in many ways to block traffic or prevent people from accessing traffic. And so if we as Mozilla are going to ship a DNS provider in our browser, we want to know that there's not some abusive blocking happening that is going to prevent our users from accessing legitimate sites. And so the third core policy area, the policy criteria that we have are essentially about blocking and stipulate that we want to work with DNS providers that have minimal blocking that is only strictly required by law, rather than a bunch of expansive discretionary blocking that we feel could have free expression implications. So I actually want to go back for a second on something because I realized there's one technical piece that you didn't explain that I don't think I fully understood when I first started in this world, but it's the role of the browser actually. And then why the browser in particular can play an important role, why it's something that is an important piece of DOH, why it's not just a provider like us in the DOH chain. So can you talk a little bit about that from a technical standpoint, then we're going to go back to TRR. Yeah, it's a really important point, which is that what the browser can do, it's a question of what we decided to do, is we can select a DNS provider by default, so that our users, as soon as they download Firefox, they are using that DNS provider that we have configured in the browser, rather than the DNS provider that they would otherwise get by default, which will typically be their ISP, but again, will change depending on whether they're at Starbucks, or work, or the house. And that means that we are very deliberately saying, like, this is the DNS provider that we think you should use, because it has a good set of privacy properties, rather than whatever default that we're going to have. Now, we could have taken a different approach and said, like, okay, here's something in our settings, if you're a very privacy conscious person, you can go into the settings, turn this on, and easily use Cloudflare's DOE provider, rather than establishing it as the default within the browser. So, we decided to go the other route. We decided we thought it was important to offer this protection to as many of our users as possible by default, at the point at which they start using the browser. That reflects a general shift that we have made over the last few years, to turn on more of our privacy protections by default. The other core example of this shift is our anti-tracking work, where we block tracking and third party cookies by default in the browser. Now, whereas previously, five years ago, you could go into what we call private browsing mode, and see the benefit of some of those protections, but the default state, when you start to use the browser, would be less protective. And overall, we felt like that left, that approach left too, essentially allowed for too permissive of an environment, and abusive activity with respect to our users' data, and a data economy that isn't healthy. We feel that today, the more appropriate approach is for the browser to be opinionated about these things, and to say, no, we actually want default protections for our users that prevent this abusive activity. Do you feel like it shifts the conversation? I mean, so, to what extent do you feel like it's been successful from that standpoint? So, you know, now, defaults are an incredibly important thing, in part because they just can shift mindsets, where people get used to a certain reality, which in this case is more privacy protective, right? So, what has been your experience with defaults to date? How has it worked? Have there been challenges? Yeah, I can actually answer that second question for you. Yes, there have been challenges. It's been really important. One thing it doesn't, because these privacy issues are so invisible, it doesn't really change user behavior one way or the other, which is somewhat of a challenge, because it means there isn't as much demand as we would want for real privacy features like this. It just happens, we provide the protection in the background, often users don't know it's happening. What it does do, though, is it still provides the meaningful protection for our users, and it also has proven helpful in driving a real conversation. I think both in the context of what we're talking about today, about like overall the security of the DNS, but also in the context of tracking, where we rolled out some of our anti-tracking technology, Apple rolled out a very similar, has a very similar approach. And the combination of those two, while we've only addressed a subset of the market, it has really forced ad tech to think about what it's doing and to respond to our approach in a way that the non-default protections that we had in place years ago would not have driven that change in that conversation. And I think, again, that's the same type of thing that we've seen in the context of Doe, where we've rolled out this protection for our users, we think it's important, but it has also driven a challenging, but I think ultimately healthy conversation about what the state of the DNS should be. So let's talk about that challenging conversation. So in my experience, and I think in yours too, we've seen somewhat different conversations in the U.S. and in Europe. So let's start with U.S. and then we'll go on to Europe, because they're both interesting. So on the U.S. side, what did you experience? What were people's reactions to it? How would you describe it? Yeah, so I think I will say from the outset, I try to remind our team what we are trying to do with a lot of our approach to some of these privacy protections is be disruptive of an ecosystem that we think isn't entirely healthy. And so that disruption is going to generate some pushback. And I take that pushback as largely a positive signal. That doesn't mean there aren't things or critiques that we should really internalize and think about. But actually, I tend to think the most important things I've done in my career have always made people angry. So in the U.S., we made people angry. I think we generated a pretty aggressive and actually more aggressive than even I expected campaign from the ISP community to try to force us to walk back our work on DOE and particularly change our deployment model. I think we were well aware that this wasn't something that the ISPs were going to love. We heard a lot of criticism as the protocol was being developed. But probably mid-2019 is when there suddenly appeared a massive campaign from the U.S. ISP community that involved public engagement, engagement through media, engagement through Congress, the executive branch, almost like everybody that the ISP community could talk to about what we were doing and why it was a bad idea they talked to. It was really an impressive lobbying campaign. That at first was intimidating in its scale because we don't have those resources. But again, when we stepped back, we thought what we do have is we're doing the right thing for the right reasons. That's an argument that's going to hold up when we make it. I think when we saw that massive lobbying campaign, it just made a real effort to tell our story more effectively. That story went out because we knew why we were doing it. We knew why it was the right approach. I'd be curious if you thought the lobbying campaign was counterproductive in the sense that it all of a sudden drove awareness that some of these practices were happening. Just in the sense that, again, going back to the first point, that people don't understand that this information is in the clear, that it can actually be accessed and there are no restrictions on how it's used. Yeah, I think that's right. Ultimately, what it did is it prompted more people to just actually turn on Doe before we even deployed it. I'll say we could talk more in detail about what the actual critique is, but the fact is in the US, the argument didn't have very much merit. It was a fairly deceptive argument that was being made. As a result, I think it did what you're suggesting, which is it gave the issue more profile, frankly, which was helpful for us. It helped us crystallize exactly what our argument was for why this was the right approach. I think, like I said, ultimately, that argument won out pretty easily despite our being fairly outmatched in terms of the size of our lobbying capacity. Yes. Let's shift over to Europe because you've obviously taken... We talked about defaults, but you've taken a different approach in Europe. You don't have things on by default in Europe, at least not right now. I'd be very interested to know how did it come about? Where do you stand? What was the pressure in Europe? Yes. The concern in Europe is very different. I think we disagree with some of the points that are made in Europe, but the argument is much more substantive. There's two core issues that we ran into. The first, which is more easily addressed, is that there was concern that we would be turning on a default DNS provider that would be a US company. That is Cloudflare. Now, that was never actually our intent. We never said that that was our intent, but we were not as clear as we could have been about exactly what our plan was for Europe. That's partly because we weren't focused on Europe at the time. Now, I have also said I would encourage all of our users to use Cloudflare Resolver. Like I've said many times, it has the best-in-class privacy protections that we stand by, not because we feel like we need to come to Cloudflare's defense, but rather just because I think it's a good protection that we offer our users. That said, the fact is that there are concerns generally across Europe about providing data to US companies. Those are concerns that we have to be cognizant of when we think about deploying a technology like this to our European users. On that point, I think one of things we're cognizant of it as well. I think that we share the values I think that Europe is actually pushing for. I think it's been an interesting conversation for us because so much of it has been ignoring the fact that the underlying thing that we talked about before, which is that this is actually privacy protective in the long run. It's a way more conversation. Right now, we do not have go on by default. We are interested in finding providers that can either be selected by users or that could be a default in Europe. That has been a slow process in part because of the second challenge that we've run into, which is really the crux of it, which is that unlike the US where we see really a lack of a strong privacy regime, which is a problem, but also you don't really see mandatory data retention. You don't really see mandatory blocking in the US. Parts of Europe do have various retention regimes or mandatory blocking regimes, or at least there is a desire within the policy space within Europe to consider especially the DNS as a tool to facilitate content blocking. Now, we think that's a very bad idea for a number of reasons, partly because it's bad on principle. It will result in risk to free expression, but also because it's not a very effective way to address a lot of these serious content problems on the web today. That's the argument that I tend to make. We are actively thinking about the right set of solutions for malicious content on the web, but blocking at this level of the stack through the DNS system is just a bad idea. It's not going to work and it will have serious free expression challenges. But nonetheless, our DNS policy for potential default providers says we do not want to see expansive blocking happening through the default providers that we would ship in Firefox. That is misaligned with at least some desire within parts of Europe to use the DNS as a mechanism to block and moderate content. That has largely been the source of a lot of the pushback we've seen in parts of Europe. One of the interesting pieces about the DNS, your point about it not being the right source for blocking, we often talk about the fact that in some ways it's been used for blocking because it is in the clear. One thing actually causes another. It's not that it's the best mechanism or the most appropriate mechanism. It was just the available mechanism. I'd be curious, actually, on your thoughts on one of the criticisms I think that we've heard is that if you block off this channel for blocking, for example, if they make it impossible to block through this mechanism, are you going to see more aggressive blocking efforts? Are you going to see DPI, DPAC inspection, or other types of things? I'd be curious if you have thoughts on that. Yeah. I don't understand this as well as I would like to or as I should, but actually, the sense I've gotten when I've talked to people across Europe about this is actually most of the blocking is already happening through DPI and is not DNS-based. This is somewhat of an artificial argument. I think, like I said, there's a desire to have the DNS available as a mechanism to block content, but I don't think it's widespread right now. I think most of the blocking is not through your DNS provider. It is sometimes through your DNS provider. I'm not too concerned that it would drive people towards other blocking mechanisms because I think that's actually already happened to some extent. The majority of the blocking, my impression is it hasn't largely been DNS-based. Mm-hmm. I think one of the interesting things to me about the debate is, again, it's become more public because of some of these pieces. Again, going back to Mozilla's default piece, you've raised a bunch of arguments that I think most people weren't thinking about way up. They've bubbled up much higher, I think, than they would have otherwise. Yeah. I'm curious. Now, thinking about where you are now, so you're in a consultation period. You have this trusted resolver. You have your TRR program for recursive resolvers. You're doing consultation on what the standard should be. Describe that a little bit. What are you looking for out of it? What are you hoping for? Where do you want to be? Yeah. Almost a year ago, when we started to hear some of these concerns in Europe, at which point we clarified what our plans were, we also made a commitment at that time to launch a public consultation period about our TRR policies. Again, I stand by those policies. I think they're really strong, but it is true that they are largely built with a US regulatory framework in mind. Just to give one example, the transparency report requirement, it's a useful tool that I think we often use in the US to provide transparency into law enforcement requests. Actually, it doesn't translate well into other jurisdictions that don't have the same First Amendment law that says exactly what you can put on your transparency report. That's just one example where it's not necessarily a useful policy in other contexts. What I'm hoping we can do with the consultation period, which we said we committed to doing that a year ago and just actually launched the public consultation period about a month or a month and a half ago. The policies right now are strong. I think we will get input essentially suggesting we should weaken those policies, which is not what we want to do, but we do want to find ways to make them more flexible and apply them to other jurisdictions. For example, another requirement in our TRR policies regarding blocking is that any blocking that does occur in accordance with legal requirements, the block list should be public. We've heard a lot of feedback to the effect that, look, a lot of times we can't make these block lists public for a host of reasons. That seems like a legitimate concern to me that I expect we will get feedback. The reason we think it's important that those block lists be public is because it provides accountability. If something is on those block lists that shouldn't be, people will be able to easily identify that. If we change that provision, which is possible we would, the input that we would want is to say, okay, what should the accountability mechanism be? If these block lists can't be public, there has to be something else that can provide oversight. Getting input on that, for example, thinking about what the right oversight structure should be for any blocking that does occur is important. That's just one example of the type of thing where I'm hoping we can get input to make these policies more applicable in some of these other jurisdictions. I'm just going to warn you, we have a little under two minutes now. On that point, it does raise a whole bunch of challenges. This is the global component of defaults. How much those transparency requirements that you just mentioned, the fact that they're based on a US framework, if you're thinking about it from Mozilla's standpoint and what you get from defaults, are they things that you want to push in other places? We have been sort of struck in Europe that that is not necessarily always where things go. People don't talk about cases, they don't have open filings the same way that they do in the US. What is your sense of, is there room to push there? Is that a good thing? Or is it sort of pushing against something that's just a different framework and doesn't make sense? The default, well, I'll say I think we want to get to a point where we have a default provider or set of providers in Europe. Then also a set of options like Cloudflare that users can select that might not necessarily be the default option. We don't have a path forward for that yet. I think we need to first run this consultation period, make some changes to the policy. One worry that I have is that we will not get to that point where we can have the default. The fact of the matter is that is a real problem because that means that our European users will have less privacy protections than our users in other parts of the world. That's not an outcome that any of us should want. That Europe should want, right? That's a bad outcome. I don't necessarily know what the path is yet to avoid that outcome. We want to avoid it. The public consultation period is the next step we have. Marshall, thank you so much for doing this. It was great. It was great.