[dns-operations] Bad ISPs, DoH and user choice (was Re: Can Root DNS server modify the response?)

Mon Apr 1 10:14:30 UTC 2019

Vittorio

You cannot speak for all Europeans. Please stop making broad sweeping statements that conflate personal opinion or experiencewith facts.

Your statement about the legalities might be based on *some* European laws, but they are most definitely not true in all European countries.

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845

From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Vittorio Bertola <vittorio.bertola at open-xchange.com>
Date: Monday 1 April 2019 at 10:05
To: David Conrad <drc at virtualized.org>
Cc: "dns-operations at lists.dns-oarc.net" <dns-operations at lists.dns-oarc.net>
Subject: Re: [dns-operations] Bad ISPs, DoH and user choice (was Re: Can Root DNS server modify the response?)

Il 30 marzo 2019 alle 18.12 David Conrad <drc at virtualized.org> ha scritto:

Vittorio,

In general, I try to avoid the DoH “discussions" as to date, they have tended to be full of hyperbole and rhetoric with relatively few facts, building strawmen and then arguing how those strawmen will do bad things. For example: (...)
What Mozilla has publicly stated they are doing (see https://mailarchive.ietf.org/arch/browse/doh/?gbt=1&index=HPTOUtziIYe_PFuawExeetkSjVg):

    [...]

    2. The user will be informed that we have enabled use of a TRR and

    have the opportunity to turn it off at that time, but will not be

    required to opt-in to get DoH with a TRR.

    3. Any given client will automatically select a resolver out of that

    set and use that for all resolutions [with the two exceptions noted

    below.]

    4. At any time, the user will have the option to select a

    different resolver out of the list, specify their own resolver, or

    disable DoH entirely.

    [...]
This does not appear to me to be “the opposite” of putting the users in charge as you accuse.
But to me it does, so you should not discount my viewpoint as "building strawmen and then arguing how those strawmen will do bad things". And let me explain better:

- at least in Europe, where I live, opt-out is not accepted as a valid form of user choice, and has not been (even legally) for over 20 years; only opt-in, and in many cases (e.g. newsletters) double opt-in, is considered acceptable;

- also, many users will have consciously selected their resolver in the operating system, so disregarding the OS configuration is disregarding their choice, and unnecessarily requiring them to do it again if they want to keep it;

- moreover, and this is a problem with the whole protocol as it has been conceived, moving resolver configuration from the system into each application requires users to configure their intended resolver once per application rather than once per device, i.e. 5-10-30 times rather than one. This is a significant UX design flaw in my opinion, and it does disempower users a lot, so it is the opposite of putting users in charge.

I do not think that these are strawman arguments, or that they are artificial, or even that they are "personal" against Mozilla. I have nothing against Mozilla except taking issue with what they are doing on this matter.
. Of course, it is entirely possible that Mozilla are lying. I guess we’ll see.
I never said they are lying, I just said I disagree with the assessment on what they plan to do.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola at open-xchange.com<mailto:vittorio.bertola at open-xchange.com>
Office @ Via Treviso 12, 10144 Torino, Italy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190401/8fa91802/attachment.html>