Re: Comments on <draft-cooper-privacy-policy-01.txt>

Alissa Cooper <acooper@cdt.org> Thu, 15 July 2010 15:37 UTC

Return-Path: <acooper@cdt.org>
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 320033A6AA2 for <ietf@core3.amsl.com>; Thu, 15 Jul 2010 08:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.243
X-Spam-Level:
X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_40=-0.185, GB_I_INVITATION=-2, GB_I_LETTER=-2]
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 TOKlQglrOeAf for <ietf@core3.amsl.com>; Thu, 15 Jul 2010 08:37:28 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 3239C3A6B33 for <ietf@ietf.org>; Thu, 15 Jul 2010 08:37:28 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 15 Jul 2010 11:37:33 -0400
Message-Id: <9D90BC0A-188F-4E6E-8AA7-CA0088DF6CEF@cdt.org>
From: Alissa Cooper <acooper@cdt.org>
To: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <47076F01-CC4C-45E6-803E-8E2516BE15AC@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Comments on <draft-cooper-privacy-policy-01.txt>
Date: Thu, 15 Jul 2010 16:37:27 +0100
References: <7022DEA1-7FC0-4D77-88CE-FA3788720B43@cdt.org> <47076F01-CC4C-45E6-803E-8E2516BE15AC@gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: IETF-Discussion list <ietf@ietf.org>
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, 15 Jul 2010 15:37:30 -0000

Hi Bob,

Thanks for your comments. Responses inline.

On Jul 8, 2010, at 11:05 PM, Bob Hinden wrote:

> Alissa,
>
> No hats on, these are my personal views.
>
> I have now read the draft.  My overall comment is that I am not  
> convinced if this is needed and am sympathetic to the views  
> expressed on the mailing list that this is solving a problem the  
> IETF doesn't have.
>
> Comments below.
>
> Bob
>
>
> General comments:
>
> If the IETF is to have a privacy policy, I would prefer it to be  
> much simpler and of the form where it first starts with a general  
> statement that the IETF does it's work in public and almost all  
> information information supplied to the IETF is made public and will  
> be available on the IETF (and other related) web sites.

A simpler intro with a focus on the public-ness of the IETF is  
definitely doable.

> I would then list the exceptions.  For example, credit card  
> information for meeting registration and social tickets, and  
> information for "letters of invitation".   Note: As I read the  
> draft, there is very little that actually falls into the private  
> category.  This leads to to wonder about the scope of the problem  
> this draft is solving.

I tend to think that privacy risk isn't so much about the percentage  
of sensitive data collected as about the sensitivity of any data  
collected. The IETF interacts with credit card numbers, passport  
numbers, authentication credentials, and other kinds of data that are  
widely perceived to be sensitive. I think those deserve documentation  
(as do less sensitive data elements like web logs, but I can  
understand why others may disagree on that point).

>
> The IETF goes to great length to tell people about how we do our  
> work and what is considered a public contribution, via the Note  
> Well.  I would be surprised if anyone thought otherwise.  Doing our  
> work in public is essential to how the IETF works.
>
> Detailed Comments:
>
> I have issues with the Introduction.  The first sentence says:
>
>   In keeping with the goals and objectives of this standards body, the
>   IETF is committed to the highest degree of respect for the privacy  
> of
>   IETF participants and site visitors.
>
> This makes it sound like the highest priority of the IETF is  
> Privacy.  I don't think this is true as I described above.  The vast  
> majority of what the IETF does in Public.  There is very little that  
> is Private.  The IETF is careful about what needs to be kept private  
> and does not disclose it.

That sentence was cribbed straight from ISOC's policy and could easily  
be removed.

>
> The Introduction says:
>
>   This policy explains how the IETF applies the Fair
>   Information Practices -- a widely accepted set of privacy principles
>   [1] -- to the data we obtain.
>
> I don't know if it is appropriate that the IETF apply these  
> practices.  Or if there are other practices that would be more  
> appropriate.

I know that the IETF is different from many other organizations, but  
the Fair Information Practices form the basis of more or less every  
information privacy law, regime, policy, best practices, self- 
regulatory framework, and guidance document around the world. The IETF  
doesn't have to reference them, but I think the reference makes the  
document better rather than worse -- at least we're basing it on some  
well-accepted framework.

> The IETF is different from other organizations in that much of our  
> data is public and not private.

It might make sense to remove the parts of the document that discuss  
public data so that it only focuses on private data.

>
> The rest of the Introduction appears to be a summary of the first  
> reference:

One suggestion I got on the -00 was to summarize the Fair Information  
Practices up front since they may not be familiar to many people. So  
the summary was by design.

>
>   [1]  Organization for Economic Cooperation and Development, "OECD
>        Guidelines on the Protection of Privacy and Transborder Flows  
> of
>        Personal Data",  http://www.oecd.org/document/18/
>        0,3343,en_2649_34255_1815186_1_1_1_1,00.html, 1980.
>
> I don't know anything about this web page, who produced it, how  
> stable it is, etc, etc.

On who produced it, I think it's fairly obviously produced by the OECD.

> It is fairly long, around 21 pages.  I don't know if this is  
> appropriate for the IETF.  I think it would better to not include  
> this information as it is hard to judge how appropriate it is.   
> Also, some of the practices seem to be at odds with normal IETF  
> practices.  For example, it implies that individuals have complete  
> control of the data the IETF makes public.  This isn't true in most  
> cases.

Removing the public data parts of the policy might help here.

>
> Section 2 and 3
>
> A lot these section is a summary of what is defined in other places  
> (References 2, 3, 4, 5, 7, 8).  Other parts of the text are fairly  
> generic, such as the information that a web server can learn about a  
> web client.  Not thing very IETF specific here.  I don't see very  
> much value repeating this.

One benefit would be having all of it in one place, especially if this  
turns into a layered policy that is referenced from a central location  
(like www.ietf.org).

>
> Section 4
>
> The first paragraph:
>
>   The IETF does not sell, rent, or exchange any information that we
>   collect about our participants or site visitors.  However, we will
>   disclose information under the following circumstances:
>
> The first two "sell & rent" is true, but the "exchange" is not true  
> as you state later in the section.  Much of the data we collect is  
> exchanged.
>

Correct. This was more language pulled from ISOC's policy that I can  
fix.

> Section 5
>
> I am not really qualified to comment on the specifics here, such as  
> how long credit card or letter of invitation information needs to be  
> retained.  I would have thought that all financial data needs to be  
> kept for some number of years.
>
> This describes our current operational practices regarding log  
> files.  Including specific times for retention will make it hard to  
> change this in the future.

If the written policy is not too difficult to change, the actual  
policy shouldn't be hard to change either.

> Also, if log files are going to be covered, what happens to the  
> backups?  Are we required to scrub the backups?  This would be  
> difficult and expensive.  What about backups of credit card  
> information?

I need to find out the back-up policies, but the idea right now is  
just to document the current policy, not change it.

>
>
> Section 10
>
> In the acknowledgment section you cite the IAOC.  The IAOC has not  
> done any formal review of this draft.  It is better if you cite the  
> people in the IAOC you have discussed this with you and not list the  
> IAOC.
>
> Now that I have written this, you can cite me if you choose :-)

Got it.

>
>
> Section 11
>
> I think most of the references are Normative, not Informative.  That  
> is, this draft depends on these documents.
>
>

Fine by me.

Thanks,
Alissa

>
>
>
>
>