Re: [Doh] GDPR and DoH

Brian Dickson <> Sat, 06 April 2019 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB8E8120075 for <>; Sat, 6 Apr 2019 15:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ywQjIxR1SUZV for <>; Sat, 6 Apr 2019 15:08:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCCC9120003 for <>; Sat, 6 Apr 2019 15:08:33 -0700 (PDT)
Received: by with SMTP id b3so5310546pfd.1 for <>; Sat, 06 Apr 2019 15:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VW7XKXyWvyzfFSp+Uc2tYcoJGd1wxsFoUMujYIVFIWY=; b=G4Rfs95R+pQcHwDud8GNi7+1Mi64dRMdgmpXn5dsakooSJ4C4Yt5HMkdPPLaFMr9pi kNiDR2mRMmN6NMP+NiBEQJM0yA+XUGwCfL+eXmuv8WwDXQ26SkgQzYP7zoNPflp7NHqs Hq9SUgggJXOONIauIgPfidEgOiRbjk5vzgmAAo1yLPCC55TovOax2eKTN/s/OeDnVtwi mt6kQjr9mXpLpeYmZn03VtuAQPiuS0Sg4qGiQ89jiJoqjlIV5ebldGc3trxcKD3vemwc E8fRnHHSgzvjmUZKy9Oa40TWSh5860Gp8NCBAr2AXhhShJeN3X0tXqMyy8L67fuNgIjE XPJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VW7XKXyWvyzfFSp+Uc2tYcoJGd1wxsFoUMujYIVFIWY=; b=nqtQ85fEr/TYYR1u2vBu0ARzU0S9cZw6Yv3pEWh4scYQhfxR4yU3jnsQjjvn+WVvoU 1kP2T+S134mIjEvHZCM+/WWJQHg91zLYgta9hAZN4RMbQ887jRmoAbO48/uigP5N0/JO xf5cVSup0KU0/PFUY8/Yul/LBeENRfuHVaL4lh6I74MoYnV2CS/w10ZU3V8HMjvVArDK cMluV3PZ4X16JPJvVYvbPXRzoq9lpWb8zbJJzFiUthM4gJUeVFeb85WW2q1gIsOHOBX4 e/EP7fkbABYqC0H4zTXo5ptwqQVdFSvuQZJLREco9eCx7XTCKm3PZ9LO1/4ogZBY7cSQ lXtw==
X-Gm-Message-State: APjAAAWTeEJwd/51BokZ/63+rC4sMrgtZLhJcQl71VtBGOP/iXAjPgC4 bkZcZ8uwdMqeyfIhIeya9u1VuV2n
X-Google-Smtp-Source: APXvYqwjkshBB5oneJSf7+mjlIflO1nekx6rZFiMjfzRUJWQpjqNzbjOKIWCQq7o7MSRnXoBFRBC5A==
X-Received: by 2002:a63:4f52:: with SMTP id p18mr19662090pgl.333.1554588513318; Sat, 06 Apr 2019 15:08:33 -0700 (PDT)
Received: from ?IPv6:2601:646:8881:1fb4:a805:6ffd:bde7:a00b? ([2601:646:8881:1fb4:a805:6ffd:bde7:a00b]) by with ESMTPSA id v20sm38458076pfn.116.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 15:08:32 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Brian Dickson <>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <>
Date: Sat, 6 Apr 2019 15:08:31 -0700
Cc: DoH WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Stephen Farrell <>
Archived-At: <>
Subject: Re: [Doh] GDPR and DoH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Apr 2019 22:08:36 -0000

Sent from my iPhone

> On Apr 6, 2019, at 2:23 PM, Stephen Farrell <> wrote:
>> On 06/04/2019 21:13, Brian Dickson wrote:
>> The ISP issue isn’t relevant. Two wrongs don’t make a right, and
>> bringing ISP DNS choice into this is deliberately conflating the
>> issue, IMNSHO.
> Ok, that's where we disagree then. I think both ISP or
> browser choices of DNS recursive are the same in terms
> of (lack of) real consent. That doesn't mean either or
> both are "wrong" but I think it does mean that there's
> no really new consent issue here.

The distinction is similar vs new. They may be similar or even identical, but the browser one is very literally new.

Regardless of how the system choice of resolver/stub is done, it preexists as a/the mechanism for DNS resolution. Making changes to that choice (regardless of whether the previous choice was informed or explicit) IMHO requires additional consent, and that is what is new.

Lack of consent on the ISP does not justify, excuse, or convey implicit permission for an app to bypass the consent issue. 

Again, the above is MHO, but also, this consent problems is an issue that crosses over the line where leaving it unsettled by stating it is an issue we don’t agree to, does a disservice to the community of users of DNS.

> (And btw, it's not great that you accuse me of "deliberately
> conflating" - to do so would mean discussing this dishonestly,
> and I am not doing that - it might be stylish of you to
> retract that accusation.)

It is possible to conflate things honestly, and 
I apologize if you or anyone else may inferred otherwise. I withdraw the “deliberately” from my previous statement, with apologies.