Re: COVID-19 contacts tracker (Re: a brief pondering)

John Wroclawski <jtw@csail.mit.edu> Wed, 15 April 2020 19:53 UTC

Return-Path: <jtw@csail.mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7837E3A08C9 for <ietf@ietfa.amsl.com>; Wed, 15 Apr 2020 12:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 s0ZcZioFNGRI for <ietf@ietfa.amsl.com>; Wed, 15 Apr 2020 12:53:20 -0700 (PDT)
Received: from ana-server.csail.mit.edu (ana-server.csail.mit.edu [18.26.1.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C733A08C4 for <ietf@ietf.org>; Wed, 15 Apr 2020 12:53:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ana-server.csail.mit.edu (Postfix) with ESMTP id 284C9D384C29; Wed, 15 Apr 2020 15:53:19 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mydomain = ana-server.csail.mit.edu
Received: from ana-server.csail.mit.edu ([127.0.0.1]) by localhost (ana-server.csail.mit.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n3pK6_uVylR9; Wed, 15 Apr 2020 15:48:18 -0400 (EDT)
Received: from callisto-vii.cambridge.schlepp.org (c-66-30-11-134.hsd1.ma.comcast.net [66.30.11.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ana-server.csail.mit.edu (Postfix) with ESMTPSA id 82D60D384A38; Wed, 15 Apr 2020 15:48:18 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Re: COVID-19 contacts tracker (Re: a brief pondering)
From: John Wroclawski <jtw@csail.mit.edu>
In-Reply-To: <4E92D147-3ED1-4109-ACC7-DFA16F1D41C2@gmail.com>
Date: Wed, 15 Apr 2020 15:48:16 -0400
Cc: Carsten Bormann <cabo@tzi.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EEFEEB4-CA51-4FFF-9BAA-857EAEA49FDD@csail.mit.edu>
References: <fd6b7ee2-cdbe-14a1-0087-ce61282b22f6@lear.ch> <29D0DCA7-1D72-428F-A6DD-05511D90C039@cable.comcast.com> <2fa6a8c8-7639-a378-2ff1-3f8697556b66@cisco.com> <24cd67ab-df5a-cc2f-745f-ace19d5325ea@network-heretics.com> <59D332BC-F85E-4744-A3D0-2514551154E8@csail.mit.edu> <4E92D147-3ED1-4109-ACC7-DFA16F1D41C2@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>, ietf@ietf.org, Keith Moore <moore@network-heretics.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M-l6iQP41iM6KENevMJlBUwjoUg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 19:53:22 -0000

Hi Bob,

> On Apr 15, 2020, at 2:30 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
> Yes, but I think it’s a mistake to think that this is a one time thing and that it will be done anytime soon.   We shouldn’t get in the way of what MIT/Google/Apple/etc. are doing in the short term, but I do think there is long term value developing something in the IETF that will prepare for the long term.   That has a reasonable balance between tracking for medical vs. political tracking.
> 
> Until there is a vaccine this will reoccur, and other pandemics will happen.

I think you, Carsten, and I probably all agree at the top level, that the most useful place for the IETF to put energy is in directions that match its timescale, skillset, and culture. 

And I also agree that this is not a one time thing.

But that doesn’t mean that it’s useful for the IETF to put significant energy into this particular space if what ends up coming out of the MIT/Google/Apple/others efforts is a competent, open-standards result that also has the weight of significant deployment behind it. Put another way, your framing suggests that the IETF _could_ somehow do the longer-term version better in some dimension, but in this particular case it’s not obvious that that’s true, either technically or from the code-actually-getting-used point of view. 

In which case, it would seem better to consciously turn our energy to places where there's both need and room, rather than zooming off towards the me-too because it’s the cool topic of the day. I’m not _sure_ that’s how things will turn out in this space, of course, but it does seem (at least to me) very extremely likely.

A side observation addressing the other point in this thread: I have no inside knowledge, but I strongly suspect that one reason both the MIT and (believe it or not) Apple/Google groups are pushing as fast and hard as they are to get something out is to short circuit the people who are pushing equally hard for alternative tools that aren’t remotely privacy preserving or anything else. 

Precisely for the reason you mention (not a one time thing..) _something_ is going to happen in near time, and then will very likely get dug in for the longer haul. Having a reasonably competent, reasonably privacy-preserving protocol/app/whatever _already deployed and running_ is one of the better possible defenses when someone comes along with the idea to create a central-reporting-of-everything app using Covid-19 as an excuse. Which, as you may have noticed, is already starting to happen in a couple of quarters.

cheers, -john