Re: [Add] meeting hum: should the IETF take up this work?

Paul Ebersman <list-add@dragon.net> Tue, 30 July 2019 22:11 UTC

Return-Path: <list-add@dragon.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8771B1200C5 for <add@ietfa.amsl.com>; Tue, 30 Jul 2019 15:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrKSumiear78 for <add@ietfa.amsl.com>; Tue, 30 Jul 2019 15:11:02 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005FE120045 for <add@ietf.org>; Tue, 30 Jul 2019 15:11:01 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 0885D37401E4; Tue, 30 Jul 2019 15:11:00 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id C71B315E88D1; Tue, 30 Jul 2019 16:11:00 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id C2C8F15E88D0; Tue, 30 Jul 2019 16:11:00 -0600 (MDT)
From: Paul Ebersman <list-add@dragon.net>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
cc: add@ietf.org
In-reply-to: <488E2CE0-73D5-4B9E-A5AD-28FDCB95ED2A@cable.comcast.com>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <AAEA003A-58DB-4FEE-81B2-BBFE9BBB2A37@rfc1035.com> <CAChr6SwA+HM4u5-xpUxQXPH8G8k7sfm6AETJJ019HE=bsq+OXA@mail.gmail.com> <8F094057-DFBC-4732-9DA4-BE46E7914C8A@rfc1035.com> <20190724165951.GB29051@laperouse.bortzmeyer.org> <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com> <d653d422-4a71-9fab-fd2e-b8ddaa476f91@nostrum.com> <488E2CE0-73D5-4B9E-A5AD-28FDCB95ED2A@cable.comcast.com>
Comments: In-reply-to "Livingood, Jason" <Jason_Livingood@comcast.com> message dated "Tue, 30 Jul 2019 21:49:21 -0000."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <65250.1564524660.1@fafnir.local>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jul 2019 16:11:00 -0600
Message-Id: <20190730221100.C71B315E88D1@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/1mvkPu5kZFnEup_aD20yBFZymIQ>
Subject: Re: [Add] meeting hum: should the IETF take up this work?
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 22:11:03 -0000

aroach> policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ 
 
JLivingood> This speaks to the DNS query/response. But with DoH, this is
JLivingood> contained inside of an HTTP envelope, so to speak, which has
JLivingood> much more rich tracking - noted at
JLivingood> https://www.cloudflare.com/privacypolicy/ under website
JLivingood> visitors (which I presume applies to all HTTP
JLivingood> transactions). So the confluence of DNS and HTTP here seems
JLivingood> interesting to better understand and document as TRR-style
JLivingood> policies evolve. Since there is an HTTP server involved in
JLivingood> DoH, presumably all the normal HTTP log items are seen &
JLivingood> processed and can be logged, like user agent, cookies, and
JLivingood> so on.

Indeed. While things like java going away and more users trying to use
privacy badger and other things to make browser fingerprinting less
accurate, it's still scarily accurate. Being able to tie DNS queries and
individual browsers is yet another step down that slippery slope to
privacy loss.

  <https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how-it-changes-game-sneakiest-web-trackers>