The following are the outputs of the captioning taken during an IGF virtual intervention. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid, but should not be treated as an authoritative record.
***
>> PAUL HOFFMAN: Good morning. Good afternoon, good evening. I'm Paul Hoffman. I'm going to be the online moderator for this session. Welcome to everyone here. This is a 90‑minute session and the way that we will be organizing is we have three expert speakers each of who has, um, positions that they will lead first and then we will be having an open discussion certainly among the speakers, but also hopefully with questions from the audience for those of you on Zoom. You can use the raising hand feature. David Huberman from ICANN will be sort of watching the Zoom and such like that. But the idea today is that we will be presenting information about DNS privacy especially how it is happening these days. We will have a bit of discussion, but really our purpose here is to have the community understand better what are the aspects of DNS privacy that are going to ‑‑ that are currently affecting policy and governance, but certainly will be affecting policy and governance in the near future.
So, I am not going to introduce the individual speakers. I'll let them do it, but I will give their names. First is Andrew Campling. Next will be Carlos Martinez and Roxana Radu. Everyone can introduce themselves and talk about their background and also where they're coming from on this topic. So with that, why don't we start. Andrew, why don't you take it away.
>> ANDREW CAMPLING: Right. Thanks, Paul and welcome, everyone. As Paul said, my name is Andrew Campling. My background is tech and occasionally, I dip into the IGF and other tech as well as also more on the public policy, public affairs side.
So let me just share my screen, if I can. I hope this will work well. So I trust that you can all see that.
>> PAUL HOFFMAN: Yes, we can.
>> ANDREW CAMPLING: Fantastic. I would be stuck otherwise. Okay. So as Paul said, we talk about The State of DNS Privacy Technologies. I'm going to start with a focus that more with client and protocol end and then we'll also move outwards from there. Firstly, a reminder DNS is the ‑‑ is the directory when you type in the URL or your client software. It puts in the URL. So DNS provides the content this you're actually seeking. I will talk a little bit about how the elements, recently developments are being encrypted, look at other things coming up in the future as well as just pose a couple questions around technology and whether it gives the necessary privacy and considering a few other aspects. I will focus a little bit on the tech aspects, but I will try and keep it also to tease out some of the policy implications of that. And I will put some links in the slides if we're sharing the slides afterwards, you are welcome to use those if they're useful.
Firstly very briefly, just a reminder that standard DNS, if you look at the top left picture on the slide, you send a request from a device that goes to a resolver with which converts a URL into the IP address and sends it back again to your device. And when DNS was invented, all those decades ago it wasn't a crime. It was sending clear text because that wasn't really an issue at the time. And it's worth noting that because it is in clear text that a third party could if neigh have the necessary competence could either at least passively monitor and learn by that passive monitoring what data you are accessing or equally they could intercept and maybe change the results of your DNS queries and perhaps blocking sensitive material, if it is a state factor or something else. Perhaps they were a malicious (?) that is getting you to update their malware. So with that in mind, a number of different protocols have been developed that can encrypt the DNS signal. One of the more receipt of those and it's had a relatively large amount of interest from the community is something called d NS over HTTPS. Usually (?) though. If you look at the bottom right picture, you will see that in this example, there are very simplistically a query goes from your device to a server and back again. But the main difference is that it's not sending clear text. It's encrypted and sent within the rest of your HTTPS traffic. And then decrypted the far end by the resolver before the result is sent back again encrypted. So an observer therefore would find it quite challenging, if not impossible to monitor pass or actively ‑‑ or actively what you are doing through that route. It is worth bearing in mind, of course, it throws out a couple considerations from a policy point of view that any client software that can directly access the DNS this way and that means they can potentially bypass any settings that either the user or the operating system has set any preferences. So it may be going to resolve and maybe the user would prefer not to be using. It is also worth that the signal was encrypted, the resolver at the far end is decrypting it. So they still see details of everything that you're accessing. Sorry. By no means full proof. It just removes the risk of a so‑called man in the middle of the attack, intercepting and neither talking or disrupting your DNS activity.
Now, in order for you to upgrade from standard classic DNS to incremented DNS, that means that either the user or the client software has to change the resolver. I'm just going to briefly touch on a couple of three different approaches to that. Firstly, Mozilla corporation was one of the earnest adopters of a standard went five folks resolver. And it uses an approach where certainly in the U.S., it will prompt the user to upgrade. It doesn't do it without their confirmation by pressing if you're looking at the screen the attractive looking okay got it button to move from their existing resolver to an encrypted resolver. But it is clearly encouraging the user to make that choice. Just throw out a number of issues. As you see, the dialogue suggests that will be more secure and improve the users privacy. It doesn't consider whether the user may already be using an encrypted resolver. Nor does it take into account whether that resolver does things like malware filtering because some of the default resolving options that Mozilla offers do not offer any form of protection in that sense. So it's possible by clicking that attractive blue button, the user might be less secure and have less privacy than maybe they did before because they might be more open to malware attacks. It does throw out some interesting policy challenges that way by maybe overriding some of those local choices. Currently Chrome and Windows 10 are using a so‑called same provider auto upgrade approach where they examine the preferred resolver that a user or system has and then check whether that same resolver operator provides encrypted option. If so, they will seamlessly in the background upgrade to the encrypted option. The thinking being that it's the same operator and they should carry forward the same policies in terms of things like what do they offer filtering, et cetera, et cetera. Same privacy. So choices and so on. So maybe overcome some of the issues with the Mozilla approach. But it does require the client software to maintain a manually curated list of resolvers so within the software. It is not automatic how it does. And as a technical point interested in that aspect, the resolvers have to be operating from public IP addresses, which means that a lot of resolvers operated by SPs particularly those certainly in Europe, and I think parts in Asia and less in the U.S., they don't operate on a public IP address. So therefore, they can't use this route to seamlessly provide in background. And that's why as I move down the slide, this current activity in the standards ITF within the ADD working group to look at a standards based approach to finding what resolvers are available the offer to different forms of encryption so that client software can use a standards‑based approach to finding that resolvers on then automatically or through some sort of user dialogue enabling an upgrade and potentially a choice of upgrades that way. There's a bunch of different approaches currently in development not particularly meaningful names. DDR or DNR. Two of those and also less more developed, but current activity to try and support a so‑called (?) DNS which solves problems and are pertinent in the enterprise space whereas the first two may be more relevant in the consumer space. There's already some early deployment using DDR Sisco, Microsoft and quad 9 have currently got prototypes deployment using the DDR protocol. DNR is potentially much more suited in the long‑term to ‑‑ for the needs of ISPs because it works with DS forwarders and private IP addresses. So it's far better suited to the environment that's typical in many markets around the world, but may require the CP to be upgraded. So the adoption cycle will potentially be a lot longer because of that. Arguably, that's really the best long‑term answer and I think data we had from Google suggests about 85% of queries that Google sees originate from a private IP address. So we really need this DNR solution for the vast majority of current resolver traffic.
There are some other developments which I will not dwell on in terms of other encrypted DNS choices. So DNS over quick is currently being standardized. It is not quite a standard, but it is getting very close to that. It is already being deployed pretty standard at guard claim the first deployment of both client software and the resolver. And from their testing, it appears to offer 30 something performance benefits relative to DOH. But as with DH, the operator still has four double of queries from a user. So you still need to invest trust in the resolver operator. To overcome that particular problem, oblivious has been developed through a more complex route that's able to hide the IP address of a user from a resolver operator, but it is by no means full proof. You have to trust the deployment which is goes through a series of two proxies. They report concluding with each other because if you are, you don't gain any benefit and you do take a performance hit. So that's also in development. It is a full standard and been marked as experimental by the ITF. There is greater development. There's a broader protocol that covers more HTTP traffic than just DNS.
And then finally, there's a DoH using the Tor network, it is a lot slower. So you take a performance hit. But you do need to be careful how you invent it because you might get the performance hit, but still be prone to digital finger printing. So you may not get the full privacy benefits that you expect even if you use Tor for your DNS queries.
And then just briefly covering a couple of other aspects. You may have come across private relay, Apple's new relay which was announced middle of this year. It went live a couple of months ago with the latest updates to the IOS, iPad OS, and Mac OS and systems. That encrypts DNS and indeed, other traffic using the oblivious mechanisms and Apple implementation of that. I'm not going to dwell on that. There's a diagram on the screen that shows you two different proxies that it routes traffic to. First of which is operated by Apple, second of which by one of its partners so that the IP address that hits a resolver and indeed, that hits the website they visit is ‑‑ is a temporary address and not the actual end users address. So it disguises the origin of queries. So you get privacy benefits that way. It still suffers from the weakness of oblivious that you have to trust. There's no collusion between the proxies because if there is, you don't get any privacy gain. They can still observe you if they do not collude and also throws up some issues because of the way it is implemented. Apple is controlling the routing and a lot of Internet traffic globally through private relay. So I know a number of providers are concerned about the quality of service and resilience and cost impacts that it has as well as local policy impacts that private relay has. It also from a policy perspective does raise compliance and anti‑trust issues which are worthy of consideration if time permits.
And then also on the horizon, there are other technical developments. So the encryption of DNS, so removes that from plain text. There's some other data, server indicator which is also in plain text currently, but there are standards underwork to hide that as well. I think from a policy point of view, the issues that raises potentially bypasses a lot of cone tent filtering software. So removes protections without warning from end users. I know that's a concern in some parts and the way that if you want to reinsert those protections with content filtering, then you have to put far more intrusive software on client devices than you would currently need to do content filtering. So perversely, this privacy development may result in far more intrusion into data than is currently necessary to provide protections. And then briefly, the other interesting development. I know there's concerns about increased centralization about Internet infrastructure and the negative effects it has in terms of behaviors and loss of resilience. The European Commission is looking at a number of initiatives because of that. It certainly concerned about loss of resilience within the DNS space and is therefore proposing to introducing DNS4 EU, which will provide an open resolver that the European Commission will part fund the deployment costs for. That's a message you might see the very first deployment so towards the end of next calendar year. So maybe by IGF2022. It might be some signs of the first deployment. It might provide an EU base because many are operated by U.S. corporations.
Now, as a very brief run through technology developments, and I've highlighted maybe some of the issues that they bring. It's worth noting that in most cases, the policy implication of some of the new technology developments are often ignored when the technology is being developed. And arguably, a lot of those developments are brought forward very much with a U.S. market perspective and it's apparent that there are quite significant differences between markets. For example, you don't have so great a prevalence of forwarding from IP addresses from the U.S., which is a very common place in Europe and parts of Africa and parts of Asia at least. And the voice of the end user is not really heard when a lot of these protocols are being developed. As I mention the already, do raise centralize and anti‑trust concerns in different ways. It is also worth bearing in mind they are also the new developments can be and often are helpful to malware developers. So one of the earlier adopters of DoH was malware, but it is helpful to malware to make it much harder to detect on client systems. So with that in mind, in my view, I think more needs to be done to make sure that regulation and legislation keeps pace with technology developments and also in addition to looking to technologies solved privacy problems, I strongly recommend the people look to the privacy and transparency policies of ‑‑ of the software that they use that the company is behind that. Again, a lot of those are often with a U.S. perspective and actually the word missing on my side I realize there isn't a U.S. wide GDPR equivalent, for example. So that makes a difference too. A lot of the software privacy and transparency policies are drafted and a lot of policies don't even tell you explicitly what legislation, what regulations are applicable. They don't necessarily in some cases by deliberately don't state what jurisdiction they're operating under, which I think is deeply problematic. If they're by U.S. based companies, many resolvers even if they do have privacy policies, it is worth noting the clown acts apply to all U.S. companies which basically means if you're not a U.S. citizen, any U.S. law enforcement agency has worked as access to your private data, which is why I would never use a U.S.‑based open resolver. Basically in my opinion, it completely overrides any protections from GDPR. And often, the process is fragmented and quite complex and difficult to understand for a typical end user. So just wanted to perhaps finish up by highlighting one of the things we have done is developed European result of policy as an alternative to those, for example, offered by the likes of Mozilla and others. It is explicitly written GDPR on compliant that says that you cannot monetize personal data either the resolver operator or any third party. And it states what jurisdiction the service is being operated under as well as many other aspects. I would commend people to look at that and use resolvers that are compliant with the Europe line policy or adopt at least the concepts that did it because it is developed openly, freely available. So at least take on board the approach within it.
I'll finish there. If anyone wants access to the slights, there are various sources of information of where to put links and so on which may be of interest if people should want to get in touch. I will stop and see if there are any questions. Thanks.
>> PAUL HOFFMAN: Thank you, Andrew. Before we go to questions to you, I think it would be good have both Carlos and Roxana give their perspectives just because we do actually have three different perspectives. This is not going to be all technical and direct policy things like what Andrew just gave. So Carlos, please introduce yourself and tell us why ‑‑ give us an introduction to an operators perspective, if you would.
>> CARLOS MARTINEZ CAGNAZZO: Thanks, Andrew, for the technical introduction. I'm going to take it from there. I will repeat some of the ‑‑ from a much higher level, some of the technical descriptions that Andrew made and I'm going to address the what I consider to be the operators perspective.
One thing that Andrew mentioned one of the slides I think is really relevant that many things have been created with the U.S. sensory perspective. I meant to tell you a little bit about me. I work for LACNIC. It is the Latin America and Caribbean registry. Before that, I used to work for ISP. The largest in the country, smaller or medium, but our country standards about we had like 1 million customers, something like that. So the issues and the problems that the operators face are very near to me. Let me tell you a little bit about south American in terms of how privacy in general is perceived here is definitely not on the (?) of almost any end user. Choose this to be more secure. Everybody is going to pick on it because it's nice. It sounds warm your heart, something like that.
[Laughter]
But I question how many of those users in our region actually understand what they are choosing to be part of. And there is something that sometimes is ignored on this very large country perspectives tend to ignore is that operators in countries like say Brazil or Argentina, while they're huge operators there, for example in Brazil, you have 8,000 small pieces cut into specific communities, Amazon communities. Many of those using technologies like wireless networking and for those communities, the operator is sometimes their only contact with the way their Internet or sometimes even with technology itself. So they depend on them for many things. They trouble shoot their connections. They one can say they set up a social (?) in that sense. So one of the things that worries me is while I think encrypting is something that we should tackle, it may introduce problems for this particular cases which I see would be very unfortunate. So, um, a little bit more about me.
I've been working with a network in the region for a while. I was part of the (?) and I am still doing the route keys, the DNS route keys ceremonies which I hope can take place in person next year again.
So I'm not going over the details of the DNS technology, but the three most relevant that everybody needs to have in mind is DOD and DNS are quick. There are new players sent to describe. I have my personal favorite which is DOD. It's a proper protocol in terms of architecture because in some part, it doesn't invent the new transport. We solve the problem. We know how to solve using traditional technologies. We ‑‑ we have become very good at applying security to other protocols and we have been doing this in a very successful way like DLS101 and 102. We have those two and we haven't been using them. So what exactly and Andrew mentioned this, what exactly protected the strong? It protects us from passive monitoring underwire or active monitoring in some cases by lawful or unlawful actors. But this refers only to traffic on the wire. In the end, at some point, (?) will be in clear text because service will need to process them. So this means that there are multiple other points where traffic can be analyzed. It is not in our universal solution to the privacy problems in DNS. So just as one example that I don't remember if Andrew mentioned, I think he didn't, but it is an interesting take on how information from DNS can leak onwards is that usually when you do the recursion, you leak a lot of information. If you are running recursion from recuring server towards server that are not sunning the DNS, you end up potentially leaking more information like basically asking every server on the Internet things you want to know. This can be minimized. There is a technical (?) that encourage everyone to deploy. It has its own issues, but I think it is also ‑‑ it is just an example of, you know, encrypting DNS is important and it is not the only thing that operators did too.
The other issue that operators find that can in a particular use cases that I described where there are situations and the operator is important or has an important work within the community is what I call a shift in trust. We have been doing this for a while. Die this myself using a server and things like that and they're very valid situations where that is a good idea. Curiously enough, many of these small spaces, data decided to stop running sent over the HCP to customers, which introduces a set of considerations into, you know, liability, jurisdiction and things like that. Opens a whole window of policies and situations for this, regulator for these operators. So this has been going on for a while. Operators I think they know many of their users do this and they are prepared to deal with. When I mentioned deal with it, I think what I am referring to is what happens when the user calls their support line. Basically they're saying my Internet doesn't work or even worse things like Facebook is down and then the internet must be down. So they are prepared to ask the proper question to the users to try to identify whether this different DNS resort they may be using; however, when you encrypt this traffic, it becomes much harder to do the same thing because particularly if you use DOH when ‑‑ where most of the DNS traffic will be picked with normal web traffic, it can become very difficult for operators to trouble shoot potential issues. And there are other things that also can suffer. One of the things that is more veered is the video service as they provide. Because if users start going and start fetching video content from transit links, their costs basically sky rocket. And the quality of service provided definitely suffers. Why does this happen? Because many of these encrypted particularly these public resolvers will not provide something called the client ID, which is used for a local (?). Basically preventing local caching from properly assigning a local cache user meaning your Netflix will suffer or YouTube will suffer and you end up with lower quality video which translates again into more support calls. So one of the things that horrified me when Mozilla brought up the first iteration of particular RR, which is basically doing it without telling anyone enabling things like default is that this will quickly become a nightmare for operators. We even organized a panel in one of the last in‑person learning events. Basically trying to raise awareness within the operator community. This may happen. You need to be prepared for this. We tried to reach out to Mozilla, but they declined to participate. It was a bit unfortunate. I am very, very glad to hear that in some way, they roll back by default policy they have. Microsoft have much friendly approaches to enabling encrypted DNS. For example, something that I'm going to mention ‑‑ my last slide they will try to use a local encrypted DNS provider. If the operator provides that, they will prefer that.
For the use of community, I agree that the user community sold am listen to these matters and this is not a very technical audience. We need to be very clear on the message. One of the things that I I'm comfortable with is when we tried to sell solutions that apparently solve everything. You will encrypt the organize and your privacy will be saved forever. They come from multiple fronts and as Andrew described. In some cases, encrypted DNS can take you to a worse position that you were in before. There is one initial thing that I think I'm going to be very clear. I think it's a terrible idea which is moving the DNS to the application space. There is a trend of software developers and application providers particularly from the larger ones, of course. They think they can do DNS better than the operating systems. So they decide to rebuild within their application and you end up with let's say five or ten applications on your phone trying their own d NS request. Perhaps sending their incremented queries to different (?) ending up in situations where every not only every server, but every application on a single device will have a different view of the Internet leading to very, very uncomfortable, you know, split internet questioning and bringing the whole centralization. I would say (?) to focus. I see this is probably one of the most worrying trends. This is not specific to encrypted DNS and this has been going on for a while. I think it would be important to raise this topic I would say up more often.
So what is the ideal for me if I were to go back to working as a network operator? Enable DOT and I believe users should always have the possibility to use an upside resolver if they so choose to. Why? Because situations like the one on the lower picture happened all the time. It won't continue to happen and I think it's a powerful thing leaders can have tools offsite servers if they need and they can provide service. And I think I have a few conclusions here. I think again I hope I wasn't too strong on my opinions of the (?). I think encrypted DNS is important and it's one element on the privacy fight. Again, moving to boundaries without user acknowledgment was an idea and it is no longer the case. And I definitely encourage operators to deploy and encrypt DNS on their other servers. And again, thank you.
>> PAUL: Thank you, Carlos. So it wasn't until about 2/3rds of the way from your talk that you were going to slides that you weren't presenting to us. That was a terrible mistake.
>> That's okay. That's okay. Try to make those. There we go.
>> CARLOS MARTINEZ CAGNAZZO: That was terrible. Sorry about that.
>> PAUL: Not a problem. We will make the slides available later and we'll make sure there are URRs available and such. Thank you. I mean, network operators are obviously very core to all of this. So having ‑‑ especially having the view point of an operator who is not one of the giant ones who can do anything, um, very, very valuable. So our last speaker for this session and before we go to general discussion is Roxana Radu. I have no idea if I pronounced your last name correctly, but very good who will talk a little bit about one of the topics that both Andrew and Carlos have touched on, but is very central to a lot of policymakers questions, which are open resolvers and how that affects policy and such. Roxana, please take it away.
>> ROXANA RADU: Thank you very much, Paul and also Carlos and Andrew because they made my job easier because they have explained in detail all the changes we're seeing in this market. So I would like to focus a little bit on the business model and how that might play out in this discussion. Let me start with a quick introduction about myself. I am a receipt associate of the graduate institute in Geneva and I am a co‑author in the D, in S solution mart together with my colleague. We conducted this research last year and it was published in the journal of cyber policy. I wanted to touch upon some of the empirical findings from the data that we gathered and also some general trends that we think affect the policy discussions. I do believe the IGF is the right place to have this conversation because it is part of this larger debate as to whether we can have security and privacy at the same time for a really long time. We have been talking any the trade off, more security for less privacy or the other way around. This is one of the areas where we could achieve both where we wouldn't need to give up on anything. It is a great example of how our thinking has been evolved and we're now in a position to have a mature conversation where again, the aspiration would be that we don't have to sacrifice anything. We can achieve both security and privacy and more equitable market, if possible. So we know that the DNS solution is a critical service. It is also sensitive. It reveals data about websites that we visit and it is integrated in absolutely everything we do online. Therefore, it is not having the security built in from the beginning obviously poses a number of problems, but I think it's always good to not have privacy as an afterthought, not having coming at the end and potentially privacy as well, but really redesign some of the protocols that we have with that in mind. And it's fair to say that the DNS market has been highly decentralized in the beginning each Internet service provider would operate this service for their local users. But we have seen an increased concentration of the power of certain companies in this space because they have offered competitive services that was to a large extent provided more security but also come with some challenges. We can also talk about this dynamics in the market like leaving some operators completely ‑‑ let's say yeah. We could separate this into two and we can say there's a large incentive to invest in this and make it a lot better and then there's also that part of the market that simply thinks okay. We can outsource the service. It is going to be better handled by other people or we simply have no incentive. This is not a user requirement. There is very little awareness of what happens. We don't necessarily need to do more. We can just go ahead with business as usual. And that has also meant the security protocols that Andrew talked about in the beginning tend to be mostly implemented by the large open resolver rather than the small ISP providers and, you know, remote neighborhoods around the world. So that's where the business model comes in as well. This consolidation of a two‑sided market, there is an aspect that is completely financial (?) as well. You pay for your provider and we all have monthly bills to pay for the Internet we're getting at home or at work. But then if you are using an open resolver, you're not necessarily paying anybody directly. That becomes very interesting because, of course, nothing runs for free, right, on the Internet. And here we have noted there is this two sided market. So the public DNS resolution is offered for free, but there is monetization coming out of monitoring traffic and overall Internet health data that can then be sold to cybersecurity companies and a package that is offered for a cost. And with this, I think we are now in a good position to understand that having market considerations as part of the discussion is quite important in order to understand what the regulatory gaps are and for best policy. But also understand what the consequences might be down the line in the evolution of the Internet.
So in our data, we could see that for mobile platforms, more than 50% of all queries were handled by alternative DNS services. That was data for 2019. So Google and Cloud Flared together and answered 49.7% all DNS queries on our measurement which was only data. The open observatory for network interference. We also noted that compared to 2016 where we had less providers in the market, just longevity did not make a big difference. This is highly dynamic and Cloud Flare and Cloud 9 only with a few years of experience in this market. So it is quite interesting to see that when we talk any consolidation, we will have actually very different implications there and it might be a market that changes much faster than we envisioned. What we have is a top open DNS providers operate mostly from the U.S. with the exception of Cloud 9 that moved to Switzerland recently. But in general, we have not really heard a lot in terms of how they are processing data and what that means for the end users in the policies that we were reading from these providers. So it goes back to the point made by both Carlos and Andrew about user awareness number 1 and second privacy protections that might be offered regionally or that might be including some of the policies which would not be applicable for other jurisdictions. But overall, we noted that there was very limited research in this space and very close monitoring of market trends. So that puts already policymakers at a disadvantage because very few of these providers shared any data on it and there is let's say convoluted methodology around how we might monitor the market trends. So my colleagues already spoke extensively about the security protocols. I will not go deeper into that part, but I think we can ask the question of who gets to configure the resolver service and we have a few options here. Is it users? It's very rarely so. Users still need to be relatively tech savvy to be able to do this especially if we consider that most d NS requests come from mobile devices and it is not as easy to configure in a mobile device, but more generally so, they have incentive to look at this invisible part of how to use their devices. It can happen if there is an outage, but other than that, it's quite limited. They need to be quite advanced users to go there. Second should be configured by applications. Carlos gave a wonderful overview of some of the challenges there and some of the concerns that will lead to (?) and question of operators configuring and here what we note is we have different restrictions and obligations in place than we would have with browsers and applications and then we would have with localized IPs versus local operators. Again, security versus privacy in terms of security, we have a number of obligations on operators themselves and under the EU and IS directive are seeing that. There is a requirement for national authorities to supervise the security of operators of social services. But obviously if DNS services are provided by Telecom, we might have ‑‑ Telecom providers and we might have them covered by national Telecom legislation. In some cases, they might be covered by both. None of these obligations would apply to ‑‑ to applications. So that creates already another gap in the regulatory space we are talking about. So when we go to just privacy consideration, I think there are three main points we can consider. One is the question of jurisdiction. Again, we don't necessarily know what happens to the personal data collected when that happens outside of the EU where we have a strong regulatory framework around it, but also many other countries around the wonder are still grappling with developing their personal data protection legislation. So in most places around the world, this would definitely be under explored by regulators. And when we go to the question of how this personal data might be used, this is point number 2 is a question of reusing personal data. Again, we have very little information as to whether this is integrated into other services that open resolvers offerings or even local ISPs. In some countries, this limbs to personal data which again includes domain names and websites visited and much can be inferred from knowing this about the person. So it can be highly sensitive data. But again, we don't know whether there are restrictions in place as to how this might be used from our study, we looked at the Google policy because they were the dominant player in market. And there we saw there was nothing in the policies to restrict integration across their own services. So they might not be doing anything with the personal data as such that would necessarily infringe on privacy, but integrating that into other services they're offering would consolidate the positioning in the market making them impossible to compete with down the line.
And the third is quite important is the question of content filtering and potentially national blocking. Obviously national regulators can mandate counted blocking and the jurisdiction and localized piece would be forced to comply with such policies. Again, this could be for better purposes or for worse. That's a separate discussion we can have that was in order to restrict political positions or to make sure that certain activities are simply banned under national legislation could be gambling, could be any decision on the national level with blocking and that would mandate ISB, to comply with these requirements. But what we're seeing is that the open resolvers are not bound by the same regulations. And that can have an effect on privacy down the line. So I think it's important to consider all of this and also keep in mind the business model and whether we can achieve again privacy security and equitable mart with an open competition in this space. Thank you. I will stop here for the time being. Thank you very much.
>> PAUL: Thank you, Roxana. So we've had three different perspectives not just three different opinions on the same topic, but different perspectives on where people are coming from and such. For those of you who are not following the chat on Zoom, there is a fairly active discussion with some different perspectives going on. I think at this point, it would be good if folks wanted to in Zoom wanted to raise their hand, bring some of the discussion that's been happening over in the chat out so that our speakers and so others in the virtual room are looking over at the upper left corner of my screen at the actual room which seems to be nearly empty. You can tell none ever the speakers are in the (?). If folks would like to bring some of the perspectives that they've been stating over in the chat out to the room, our speakers can speak to them even if folks in the discussion are not. I can see that some of our speakers have been following the chat as well. But any time you talk about the balance of privacy especially by encryption and policy, it brings out some strong opinions, which is just fine. As folks know that my background is actually on the technical side, but as a strong advocate of the technology that we've been talking about, at least from the technical implementation which is why I help to develop them in the standards body, but really this kind of discussion should be among people who are both implementing the technologies and distributing technologies as well as the ones who are governing them. I encourage folks to raise their hand. I will call on you and I'm not even sure how to unmute. Maybe David Huberman will help me on this if folks want to speak. If not, I would encourage panelist to speak to each other about what they are seeing and conversation can continue. We still have half an hour. I think there's plenty of time for us to hear a lot here. I'm not seeing any hands raised in the official Zoom, but I think I saw ‑‑ Andrew, did you put your hand up?
>> ANDREW CAMPLING: I was going to ask how anyone in the room can engage? I presume there's a micro folk in the room and it looks like there's a lady walking to it.
>> PAUL HOFFMAN: Thank you very much.
>> Mallory here.
>> PAUL HOFFMAN: Thank you for holding the space for us there.
>> I'm not going to moderate. I have a comment. Maybe others can feel encouraged to come up to the mic. I also like Paul agreed working on the technical side means we do need to have these conversations that brings in the policy. I think what I'm hearing just also from the last from Roxana's presentation is it might make sense to bring some real policy recommendations around us whereas we can meet in the miss on the other side of things. I worked with Shevaughn Call. We worked on a policy paper ‑‑ it is a technical paper that brings in public interest on DNS privacy. So that paper is trying to resolve what from a user perspective is the right technical choice crossed various tensions. So it disrupts measurement. It disrupts accessibility features. It can disrupt a variety of things and some of those have been mention here today. We're trying to approach it from what's the best in the public interest so we don't have big Telecom operators speaking on the public interest because that seems to be an incongruous chip. Meet us in the middle with real concrete changes to policies that would encourage the right user centric approach because it is an ecosystem question. We're not necessarily going to be able to control how implementers do this. We can only suggest what's best when folks are really trying to do the right thing for privacy, how they can do that to get the best tradeoffs and what users want given that it is a rather difficult thing to know how to configure and to know how to threat model. So that would just be my encouragement and maybe, Roxana, you and I can talk later. It's not final because there are so many other considerations that telephone to come up that we want to keep feeding into it. So ‑‑
>> ROXANA RADU: Absolutely. I would be very curious as to what would be best in the public interest.
>> It's very complicated. I think somebody mentioned that we can't have silver bullet solutions. Being able to trouble the questions from a environment of different angles is what's important and to also evaluate the difference between DOH, DOT, all those different things have different outcomes depending on what problem you're trying to solve. It is more a very complicated guidance for implementors which is the best I can do.
>> ROXANA RADU: Thank you. Sure. I would love to follow up.
>> PAUL HOFFMAN: I am not seeing any hands on Zoom. I will ‑‑ I want to surface one of the things that was said a few minutes ago in the chat which was that the feeling that or the question of should we not have deploy the will technical solutions before the policy discussion had happened? So basically do you have a policy discussion on privacy in the absence of knowing how the technology will work or do you deploy the technology as a way of getting the policy folks to understand what will happen under certain circumstances and stuff like that. I think that's a fairly relevant point and clearly I'm of the opinion that the privacy should be ‑‑ the privacy technology should be deployed early and often as a way. In areas other than d NS over the last 25 years, we have seen policy follow deployment by 5 or 10 years and those are ‑‑ those are ‑‑ my feeling is that in those 5 or 10 years, we wouldn't have seen any policy discussion unless it was forced. So, um, it's not that I believe that we need to force policy discussions all the time, but in these cases, I think history shows that we did need to in fact deploy first. I see somebody else in the room and even though the vast majority of us are offline, I like face to face. So whoever is at the mic, please speak first and then we have some other folks with hands up.
>> Thanks. I am joining from the communication speculator in the UK. One of the things we're really proud about in the UK regulatory space is the development of new umbrella organization called the digital regulators cooperation forum, which brings together Ovcom and the competition and markets authority to try to set common agendas around the evolving regulatory space for digital platforms and services. So I wondered I know that Andrew had mentioned in passing competition that angle of things. I wondered if the different panelists will be able to comment more about that intersection and just to respond to your point about the kind of policy and technical questions, I think it's really important to treat those hand in glove and, you know, as regulators in the UK, at least, there's been a concerted effort to bring more technologist on board and try to beef out internal capacity. But there's a real need for ongoing multi‑stakeholder and relationship building between different actors to insure policy making isn't happening in a vacuum. Thanks.
>> PAUL HOFFMAN: Thank you. Andrew, you have your hand up and also since you were just name called here, why don't you respond to that.
>> ANDREW CAMPLING: So I will do this in order. The reason I raised my hand was to the earlier point about leading towards the policy discussion as well as the tech development. In my view, I think one of the current problems that we have is the standards bodies are operating in a vacuum not deliberately in fairness, but there's a way to engage in standards development. Even though the development of those standards are often brings with it enormous policy and other impacts. And as I said earlier, in my view, the voice of the end user is really quiet in the standards. I think mass deeply problematic. So there are few exceptions, but I would really love to see more regulators, more government agencies, more industry bodies with a present in the standards development. And frankly, I think current stance within the ITF that only focus on the technical aspects and don't look at the policy implications at developments is an issue that needs to be fixed. So that ‑‑ we need to have proper engagement in the standards community. This stuff is far too important to leave it just to the technologists because dare I say it. The tech sectors have done some bad things over the last decade or so. No one in their right mind would let it carry on by itself without paying careful attention to what it is doing because otherwise, it will make bad choices in my view. And I've completely forgotten. Colin made a good point. Would you mind prompting me? I can get back on track and address Colin's point.
>> PAUL HOFFMAN: She was speaking about the competitive aspect ‑‑
>> ANDREW CAMPLING: Yes. Sorry.
>> PAUL HOFFMAN: Operators or folks receiving the traffic or blocking others from seeing the traffic as such.
>> ANDREW CAMPLING: I think that's really valid and that's one of the motivations behind the European Commission bringing forward DNS for you project because there are anti‑trust concerns. Currently, for example, if I look to the excellent data that comes from with Jeff Hustin and team, from their data, the combined share of traffic that Google can resolve that, if you look at both the data goes directly to it including the data rooted from ISPs and also the data that it gets if there's a serve foul from a first choice resolver potentially can save up to a third of DNS traffic in some conditions. I think in other conditions, I would say 15% of global traffic. They're just one (?) traffic, but the entire globes DNS traffic. Given the dominant mart condition, if I was an anti‑trust regulator, I would be paying close attention to that equally. From that view, consider the business models to some of the other open resolvers, not all of them. (?) 9 is an exception because it is not for profit. Some of the others are monetizing, but they are monetizing operation to improve the core business and potentially to exclude orders. So yeah. Again, anti‑trust ‑‑ if somebody is doing something for free, but it has a cost, surely and regulators should be considering how they're recovering that cost because potentially, they're disrupting a market for a commercial motivation. And time doesn't allow here, but certainly again I got some links in my slides. E‑mail me for them and report out for them in private relay where there is clear anti‑trust considerations with again if I was a regulator, I would be having a close look at. (?) dwell on that just now. Stop there. I see Carlos wants to say something.
>> PAUL: Thank you, Andrew. Carlos?
>> CARLOS MARTINEZ CAGNAZZO: Thank you. This is a very, very interesting discussion. I would like to start by referring to something that I think her name is Colleen. She mentioned something about the initiative bringing together operators in order to collaborate and I think that's a brilliant idea. I have tried to raise this same idea with a regulator. So I would love to get in touch with you, Colleen, to see whether you can help me with some ideas to actually convince the regulator here to make something like that happen in my country. I think one of the key things that I believe was lost in the whole debate whether DOH was with it or not was no technology happens in a sustainable way without industry collaboration. And this opened a few things like I don't know how involved the developers of DNS, open source DNS software solutions like unplanned and things like that because in my opinion, those are key players in this. Having good open source implementation and encrypted DNS resolvers is one of the most powerful tools we can use to get encrypted DNS deployed widely. I know that ‑‑ I don't know if all of them, but most of them have implementations at least of the DOD and not sure about DOH, but that took a while. For the long time the only way of using DOH was using something on the Internet. I don't want to pick on anyone, but particularly Cloud has been very open in our region. They have discussions that participate in the (?) and talk about these issues and I have a very good relationship with them. Talking about industry collaboration and reinforcing something that Andrew said that I think is very, very concerning is that operators participation, for example, they're at the record low. Next to no engagement yeah, sure. You may find, you know, some e‑mails from ‑‑ (?) or AT&T or something like that in the participant list, but there is no meaningful interaction with the (?) and suddenly, I get the impression. It is very unfortunate. It happens inure region, for example, in the network operators group. They're called network operators group, but participants either from smaller networks or, ah, universities which is great, but we are ‑‑ there is a disconnect there and it is probably a thing that is manifestations that I think we should address. Thank you.
>> PAUL HOFFMAN: Thank you, Carlos. Roxana, just before you jumped in, I would like to respond to the feeling that not enough either operators or regulators and such are active in the IATF. That has always been true. It has been more or less true as Carlos mentions. Voluntary organizations especially voluntary organizations that spend a lot of time on developing new ideas is very hard to get people's day job is to look at current developments. To be involved. If we can get more folks who will be affected by our protocol changes involved early, that's great. So Carlos, you are asking, for example, you know, how many developers were involved in DOT and DOH. There was a good matter, but even they were looking at it what do I have to do once this protocol is finished and are they doing anything in the protocol that would make my development difficult? Similarly when we do get folks from the governance community in the IATF, they are often only watching and would only speak when a development is obviously going to hurt them in the short run. I don't ‑‑ I'm not suggesting a way to get them more involved. I'm certainly active in trying to get newcomers there over a long period of time. Sometime its is successful and sometimes it's not. But all organizations that are voluntary generally have a hard time at getting participants to be active early in the process in the IATF having been around for over 30 years has seen this over and over again not just in the DNS and not even in encryption. There is other things that we do. Let's stay on the DNS topic without diverting into routing. Roxana?
>> ROXANA RADU: Yeah. Thank you. Just two brief comments. One is that we definitely need to look at the ecosystem and we can't regulate in silos. That is simply not going to work. We have seen this happening for more than a decade now and I think that has to change. So I commend the initiative from the u K for trying to bring everybody in the same room and understanding this collectively. I think that e U is moving in the same direction. We have been part of consultations on the resilience of DNS. So I think that's getting quite a bit of attention recently. And that's a good shift from a policy perspective. We need to make this invisible part of how our networks operate more visible also to the end user because at the end of the day, we are never getting informed if our ISP providers are switching over. We get no net fixation as part of the contract. To be able to challenge this even at the level of consumer protection, it's a completely different discussion. But it has to be the ecosystem approach that we're taking rather than just talking to the open resolvers or talking to ISPs and we need to talk to the consumer respective. Rather than just protecting what you consume, but whatever goes in that direction is still welcomed. And second, I would like to also touch upon the dynamics in the standards community. I'm not as experienced as Andrew, but some of the proposals that we are seeing now getting implemented on a large scale are sponsored by the open resolvers. So it is Google putting forward some of these proposals and, of course, that doesn't ever challenge the business model. So these are small adjustments that never goes to complete overhaul of what we currently have that would actually make them get access to less data. So by not having those other voices in the community, we are ending up with the voice of the loudest, the ones that are always present and that is again not going to mean a fundamental change for public interest.
Second with what voluntary standards obviously, there is a question of implementation and adopting a standard and if we are having operators with so much power in the Mark, they can always design their own standards. Right? So the fact that we have global discussions about certain standards that could improve everybody's wellbeing doesn't mean everybody is going to adhere to that. We are seeing that with the power of just switching to another alternative because we just have that option out there. So consider a market of this type in 5-years time where there's more consolidation. I think that brings us to rethink some of these connections between what these actors do with market power they have and how that place out also in the standards making (?). Thank you.
>> PAUL: Thank you, Roxana. Just to acknowledge what you just said about the powerful players already who are using their ‑‑ who can set their own internal standards. The DOH standard was something that going already had implemented internally and, um, when the IT S said we would like this as a public standard and that was mostly even though I was co‑author, that was mostly driven by fox folks at Firefox. Google was okay with that. One of the nice things about open standard bodies is if there is a first mover, sometimes they are doing first moves just to get things going particularly on the privacy side and are willing to then also take in the input from other folks. In this case, in the DOH case. They have done that pretty much fairly heavily. So I think what we are seeing in open standards as well as open governance such as meetings like this is that somebody needs to get the discussions started and maybe that's not just with records, but with inactivity as long as they're willing to then say okay. Now the discussion started. What do we need to do? I think it's something that we at least see and I would love to see it fall on the governance side. I see someone on the mic ‑‑
>> Users understand would it and there would be operators that would want to provide it. And so the details of how it was done I also don't think would upon well influenced by governments or regulators that had an agenda coming to the standards bodies. How it was implemented with DOH, with DOT, with all the other options out there is just the best way to do it from an engineering perspective and I don't think those changes ‑‑ you couldn't make changes to the pink is protocols in standard setting that would make a government body happy or an ISP happy because really what we're saying is we're going to disrupt the 80 to look at this data and let users decide which intermediaries they trust. So that is going to have an impact on ISPs who like to filter content by domain. It's going to have an effect on any kind of censorship that uses the D, in S. So yeah. There is going to be those outcomes. I just want to clarify that I don't think, um, that this is necessarily about who made the standards has been pointed out. We keep falling back on this thing that big tech is a euphemism for the purview of GDPR and others. That's a policy question. Go ‑‑ let's make some recommendations for how to do that better and the other side of it on the technical level how you resolve that, for example, well, resolve is an intentional pun, but, you know, one of the things with regards to ISPs for many years had, um, the corner of the market on d NS data and have abused it. If you read the report that just came out in the U.S. about still the persistent abuses of user data by ISPs, which is incredibly staggering, that's been the status quo. This changes that and I will note to get ISPs back into the game of DNS data, they have to resolve using DOH or DOT. We're pulling ISPs kicking and screaming into a space where they're respecting user privacy. I think that's a good thing even though there is resistance to it. But I am happy to know there are folks working on getting more ISPs to do that and I am glad to hear there are lots of people that think about it as the right thing to do because it is.
>> PAUL HOFFMANl: Thank you. I am not seeing other hands. Andrew?
>> ANDREW CAMPLING: That segways fantastically well. Thank you for that. Looking specifically to go first and then make a more general observation. I think you have to consider what motivations were in the design of those specifically. And I note that one of the raising brows is because it is better browser performance. The fact it may also have some privacy benefits interesting, but I think entirely coincident an. It is about getting a snappier user experience with a browser.
One of the reasons I am concerned about though is that the design allows for the use of cookies which if you were genuinely concerned with privacy, you would not do that. You're now into the HTTPS realm. So which is partly why with a European result policy, clearly it should not support cookies. And also again from a privacy point of view, again a technical point, some of the resolve operators and cloud operators again for performance reasons have sessions as long as 7 days which is fantastic for a digital finger printing and conversely really bad for privacy. So the reason I'm making this point is simply encrypting DNS is not magical. It does not by itself infer privacy. It simply means that no other party can easily get hold of your data other than the resolver operator. They may have bad intentions, which is why as I said earlier, you must consider basics like what's their privacy transparency policy and et cetera. Don't just go I was using that. Therefore, my privacy is protected. The reverse may well be true. And also ‑‑
>> PAUL HOFFMAN: I say, sitting here in California, I don't think of these things, but there is a physical room that will have to be cleared soon. Thank you and Carlos do you want to have the last word?
>> CARLOS MARTINEZ CAGNAZZO: Thank you very much, Paul. I just wanted to highlight something that Mallory said. I think anything that breaks status quos and brings them to light is (?). It needs to be better than the last. Just shifting. The priority that it uses something on a different part and it abuses it is not necessarily improvement. But I definitely agree that bringing things to light creates a space for improving things and that's a good thing. And my final reflection is that I definitely think that we need to do traffic. I think we need to frame it in the proper way. Not assign it rules or powers that it doesn't have and have it in perspective of having why wide industry collaboration. Thank you very much. This was a very lively session, very enjoyable.
>> PAUL HOFFMAN: Especially thank you to all three of the speakers. Thank you for the active discussion over in the chat. I guess this is what we get when we're not in the room and all standing at the mic and thank you for the folks in the room standing at the mic line. I do like to be reminded that physical people and when they stand in the mic line, you don't see the back of their office and such. Enjoy the rest of the week in Poland. Hope to see you all in the various discussions about DNS privacy that are coming soon. Thanks.