Re: IETF privacy policy - update

Andrew Sullivan <ajs@shinkuro.com> Thu, 08 July 2010 15:15 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C43E3A6AE9 for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 08:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.798
X-Spam-Level:
X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=1.801, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHdukJOgZoD4 for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 08:15:36 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1054F3A6AE0 for <ietf@ietf.org>; Thu, 8 Jul 2010 08:15:33 -0700 (PDT)
Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 96CA41ECB408 for <ietf@ietf.org>; Thu, 8 Jul 2010 15:15:36 +0000 (UTC)
Date: Thu, 08 Jul 2010 11:15:35 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: ietf@ietf.org
Subject: Re: IETF privacy policy - update
Message-ID: <20100708151534.GC63066@shinkuro.com>
References: <9C72FA78-C9C2-4719-9BFD-112ABEFA7117@cdt.org> <56522CF0-088B-4027-AF45-A6075A7EA666@muada.com> <51D591B3-1954-47A6-A40A-7DCE6DDD5CF0@cdt.org> <A68985E3-A34B-47AB-A6A2-E6718E505652@muada.com> <B75D4F49-2361-4706-A24A-D5E7026EE58D@cdt.org> <573C3FFA-B8CA-4B71-9128-07863DF1CF2B@muada.com> <tsl630r6pj1.fsf@mit.edu> <Pine.GSO.4.63.1007071250260.20133@pita.cisco.com> <4C34F4BB.4040907@bogus.com> <006FEB08D9C6444AB014105C9AEB133FFE28C51DD8@il-ex01.ad.checkpoint.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FFE28C51DD8@il-ex01.ad.checkpoint.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 08 Jul 2010 15:15:37 -0000

On Thu, Jul 08, 2010 at 11:59:12AM +0300, Yoav Nir wrote:
 
> Without a privacy policy, it's hard to say whether that is
> acceptable or not.

I keep seeing arguments of this sort in the current thread, and it
seems to me to be backwards.  Surely it is not the privacy _policy_
that determines whether something is acceptable.  For instance,
imagine a website privacy policy that says, "We take your personal
information, including your credit card number, expiry date, and CCD
number, and post it on our website."  The existence of that privacy
policy would not make the actions somehow better or defensible: it
would be a bad policy.  I suppose posting somewhere that you're going
to do that would be better than just doing it without any warning, but
the action would be unacceptable regardless.

If the current no-written-policy arrangement is working, it is
presumably because people are making the right choices.  One analysis
of that is that there is an implicit policy, that it is acceptable,
and that the present effort to write down a policy is just a way of
making that implicit policy explicit.  But writing the policy down
does not in itself do anything about whether a given activity with a
given bit of PII is ok.

On the larger topic of whether a privacy policy is actually needed, I
am undecided.  On the one hand, it does seem to me to be a good idea
to have one place where the IETF states what it is going to do with
any PII.  On the other hand, I can easily imagine that such a privacy
policy could end up being used as a mechanism to justify bad ideas in
the event something comes up: it will be more work to change the
policy if it turns out to be inadequate than it will be to accept the
inadequacy.  The present arrangement means that, if a bad idea crops
up, it can be dealt with on its own (de)merits without dragging in a
meta-issue about whether the proposal is consistent with some holy
policy document.  

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.