Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

[Vittorio Bertola <[e-mail]>]

>     Il 11/05/2020 21:35 Christian Huitema <[e-mail]> ha scritto:
> 
> 
>     I found the discussion of application embedded resolvers bizarre. It speaks of applications in general, but the way the text is set-up appears to be a specific dig against Mozilla. Look at the text: "popular applications directing DNS traffic by default to specific dominant resolvers". It boils down to accusing some unnamed application of deliberately contributing to centralization. I find that problematic, and also very imprecise. I think this should be rewritten in a much more neutral way.
> 
I think this section has already been rewritten at least half a dozen times, and every time there was a claim that it is not neutral (sometimes even on text that previously seemed to be ok). Every time the authors put the effort to rewrite it once again according to the comment, and every time a new comment comes in saying that this is not enough. I admire their patience.

In any case, I don't know Mozilla's view on whether this is a specific dig against them, but it is meant as a discussion on privacy impacts of a specific deployment model, not of a specific company's policy. These privacy impacts, even if with very variable views, have been the subject of many conferences, articles and talks in the last couple of years - they were not discovered in this document, and it would be weird if they were omitted from a discussion on DNS privacy released in 2020. The fact that Mozilla is at this time the only company adopting that model is just coincidental, apart from perhaps reflecting the fact that others think that that model is not a particularly good idea.


> 
>     In a modern environment, the concept of host is very fuzzy. We get all kinds of special devices. We also get containers or virtual machines running inside hosts. A browser is in practice such a container. There is not a difference of nature between a separate subsystem like a browser environment and a separate device. If a browser embeds its own stub resolver, users can configure the resolver of their choice in much the same way that they can configure the resolver of their choice using a device configuration UI. There are differences in management, but these differences fall largely outside the scope of the DNS privacy draft.
> 
>     In both cases, users are very likely to configure a well-known service. There is not much the difference between setting the device's preferred resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In both cases, the centralization effect results from the popularity of the service, unless you are specifically accusing Mozilla of conspiring to centralize the DNS. And a privacy RFC is not the right place to do that.
> 
You seem to miss the point, which is not about users setting their preferred resolver at the application level, but about applications that by default ignore the resolver settings in the device and pick their own preferred resolver independently from the user.

In a market in which there are few choices, indeed this behaviour promotes centralization: we know that most users do not change the defaults, and if most users of a popular application start using a single resolver in place of a broad set of local resolvers scattered around the Internet, of course the resulting traffic pattern is more centralized.

We also know that centralization of the DNS is potentially a privacy threat, as it makes it easier to track and correlate multiple activities by the same individual. This does not seem contentious - it was actually the first example in last year's IAB "DEDR" workshop charter.

Moreover, this potential downside for privacy can be entirely countered by increased privacy protections offered by the new operator, and this is clearly stated in the final paragraph.

The central paragraphs were initially meant to say that, to preserve the user's privacy, the user should always be given controls to set the resolver. This is in line with the basic principle of most privacy-protecting policy frameworks, i.e. user consent.

However, the current text just says that "if" we wanted to give users the same degree of control they currently have in basically any consumer-oriented operating system, then applications should provide users with controls (any control goes, even if hidden under a 3-click-deep configuration hierarchy, as you have to do today if you really want to reject advertising cookies on the average commercial website). Then, the text adds that if applications don't do it, users might not... be able to control their resolver.

There is not even any more a stance that says that users should be able to choose where their DNS queries go, or that the lack of such choice is in itself a privacy problem. From the perspective of a privacy advocate, this section is now quite watered down.

I am also puzzled by the fact that this draft was actually in last call six months ago, and it only received a single objection just before the deadline, and since then we have entered an endless cycle changing it again and again and again. I did my best to help with compromise text as requested but I do not understand where this process is going.


--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] mailto:[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy