Re: Consultation on revised IETF Privacy Statement

Jay Daley <jay@ietf.org> Wed, 04 December 2019 19:00 UTC

Return-Path: <jay@ietf.org>
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 6234C12097A for <ietf@ietfa.amsl.com>; Wed, 4 Dec 2019 11:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 B2psPn3nllwI; Wed, 4 Dec 2019 11:00:42 -0800 (PST)
Received: from macbook-pro.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 50EC5120961; Wed, 4 Dec 2019 11:00:41 -0800 (PST)
From: Jay Daley <jay@ietf.org>
Message-Id: <5CC83C2E-F728-431E-8C75-9D0E0D5AB6A4@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1DD46C1C-901C-4CA8-BD60-E956F7479349"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Consultation on revised IETF Privacy Statement
Date: Thu, 05 Dec 2019 08:00:38 +1300
In-Reply-To: <27d747e6-4b54-32e6-5ceb-d305b07c03c9@cs.tcd.ie>
Cc: ietf@ietf.org
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <157541908820.4734.11549038582739661941.idtracker@ietfa.amsl.com> <27d747e6-4b54-32e6-5ceb-d305b07c03c9@cs.tcd.ie>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Kn4lAVoqre-gjweau9hAkjawBDg>
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, 04 Dec 2019 19:00:45 -0000

Hi Stephen

> On 4/12/2019, at 11:42 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 1. What is a "privacy context"? I'm not a GDPR specialist
> (thankfully:-) but have read bits about it and that's
> not a well-defined term for me. I think I do know what it
> means but want to check - if the IAB say keeps a file of
> comments received on people who've volunteered for some
> position, are we saying that data is covered by this
> policy or not? OR, does this entire policy only really
> apply to the public-facing IETF etc web sites and their
> logs etc?

While the new version tries to use plain english as much as possible, this is the one area where we need explicit legalese.  A privacy context relates to the full range of activities undertaken so everything is covered.  The NomCom comments you mention are indeed an exception that needs to be called out.

> 
> 2. "Our Commitment to Privacy" - that subsection is only
> about transparency, suggest renaming it to "Our Commitment
> to Transparency." (That's not really a nit - there's a
> significant proportion of our industry that publishes
> what I believe are fake claims saying they are committed
> to privacy, so we don't want to smell like that at all;-)

Yes, that was changed by the lawyers to a standard term and you’re quite right that in our context it is inappropriate.  "Our Commitment to Transparency" works.

> 
> 3. Whose "personal data" are comments submitted to the
> nomcom feedback page?

Agreed, that’s an exception to be listed.

> 
> 4. The list of personal data is odd. Regarding an I-D
> as personal data seems wrong in any case. I suspect
> there may be a lack of definition somewhere here but
> maybe it's ok to ignore that.

The general definition of personal data is anything that can be used to identify, through linkage, a real person.  IDs are well established as personal data unless specific precautions are taken, and since we can’t know that we will use the safest definition.

> 
> 5. Pictures. I don't think this policy is consistent
> with the red lanyards policy at IETF meetings. The text
> here seems like it's over-riding that saying "we can
> do whatever we want with pictures from meetings."

Agreed. This section was not changed in any detail and so that issue has always been there, but it can be tidied up now.

> 
> 6. Sale of data. I like that bit:-) But please extend
> it a little e.g. to "We do not sell your personal data,
> or any data, nor do we monetize any data in any way,
> such as by "renting" or making access available for
> a fee." There have been many cases of companies making
> what seem clear statements but where it turns out that
> they do have "partners" and do end up making money from
> people's data while still claiming that they don't "sell"
> that.

"nor do we monetize it in any way" works.

> 
> 7. "Our websites do not alter their behavior according to
> the value of a browser Do Not Track (DNT) setting." Is
> that new? (I forget sorry.) I don't like it anyway (even
> though DNT is a crap specification:-). If someone emits
> that signal we ought honour it unless we cannot.

This again is a clause that has been there for a while and only changed to make it clearer.  While DNT has differing levels of support it is a clear specification and DNT specifically only applies to third-party tracking not first-party tracking.  In other words, we track you on our sites only as those are a single privacy context and do not enable you to be tracked between our context and a different context nor do we attempt to track you from another context to ours.  I do not think it appropriate to use our own custom definition, even if we believe that’s what people expect and given that first-party tracking can be disabled by other means.

> 
> 8. "We use services from Cloudflare to support some of
> their websites." s/their/our/?

Noted.

> 
> 9. I'm not keen on the "go find cloudflare's policy
> yourself" statement. It'd be better if we had a pointer
> to that and if we were clear that it applies to
> www.ietf.org <http://www.ietf.org/> but not ietf.org <http://ietf.org/> or tools or datatracker
> etc as applies. CF do after all have >1 policy and
> tracking down which applies to www.ietf.org <http://www.ietf.org/> may be
> non-trivial.

Ok, we can look at that.

> 
> 10. Stuff we don't share ought probably include feedback
> to nomcom and other appointing bodies (e.g. IAB/IESG).
> The ANRP and ANRW also involve reviews that some might
> consider sensitive. Some but not all of those use web
> based tools. Some will involve such feedback/comment
> being sent on closed mailing lists.

I’ve had similar comments privately and these will be addressed.

> 
> 11. Not asking we fix now, but, for a future version,
> can we think about setting a policy for deleting old
> data? I'm not sure anyone needs the payment info I
> used for IETF35:-) If we already have such a policy,
> then saying that here would be good.

The LLC is working on a records retention policy, which should be out soon (couple of months?), which will cover that.

> 
> 12. Also for the future, I like warrant canaries. Not
> so much because we might need one but to set what I
> think is a good example. (Opinions vary on that though
> so not asking you to do it, just to note it down to
> ponder it later.)

This would be more appropriately covered in something like an annual transparency report.  I also like warrant canaries but as you say, that’s for a future discussion.

Jay

> 
> Cheers,
> S.
> 
> On 04/12/2019 00:24, IETF Executive Director wrote:
>> The IETF Administration LLC has reviewed the IETF Privacy Statement
>> [1] and proposes to introduce a new version [2].  The main reasons
>> for this are to support the introduction of web analytics, to support
>> the collection of demographic data in surveys and to make the whole
>> statement more legally compliant, easier to read and clearer to
>> understand.  This new version contains the following changes, which
>> have been reviewed by our privacy counsel:
>> 
>> 1. Significant reordering, moving of text and changing of headings,
>> with minimal change in meaning, in order to make the statement
>> clearer and easier to understand.
>> 
>> 2. The scope statement has changed from covering the IETF/IRTF/IAB to
>> identifying the specific groups that can legally be considered data
>> controllers in various data protection regimes, namely the LLC, IESG,
>> IAB, IRSG and RFC Editor, and being clear that their activities form
>> a single privacy context.  The scope uses “IETF” as a collective term
>> for all these groups, even though that is not structurally accurate,
>> as attempting to convey accurate structure in this statement is too
>> complex. “This statement sets out the privacy and data protection
>> policy of the following related organizations and groups: the IETF
>> Administration LLC ("LLC"); the Internet Engineering Steering Group
>> (“IESG”); the Internet Architecture Board ("IAB"); the Internet
>> Research Steering Group ("IRSG"); and the RFC Editor (each a
>> "Party"), which are collectively referred to in this policy as  the
>> Internet Engineering Task Force ("IETF") and whose activities
>> constitute a single privacy context.“
>> 
>> 3. The existing version contains a number of references to the
>> Internet Society (ISOC) given the legal structure that existed before
>> the creation of the IETF Administration LLC.  Those references have
>> all been removed as data will no longer be shared with ISOC and a
>> statement added for the avoidance of doubt: “For the avoidance of
>> doubt, this policy does not apply to the Internet Society (“ISOC”)
>> and its activities and practices constitute a separate privacy
>> context. ISOC should be regarded as a third-party for the purposes of
>> this policy.”
>> 
>> 4. Two new elements have been added to the list of data that may be
>> made public, which reflects existing practice.  These are “metadata
>> related to the time and frequency of your interactions with any IETF
>> system” and “message headers”.
>> 
>> 5. Added an additional example of personal data to be clear that
>> email message headers contain a lot of data “the IP address of a
>> message sender and details of the device or service used to send the
>> message, as found in email headers”.
>> 
>> 6. Added a clear statement that we do not sell data "We do not sell
>> your Personal Data".
>> 
>> 7. Added a new bullet on what data we collect to cover web analytics
>> and a new paragraph that covers what we intend to do with that data.
>> The bullet is “information provided when you interact with any IETF
>> website” and the paragraph is “We track your usage of our websites in
>> order to understand how our websites are used and how we can improve
>> them.  We do this using Javascript based tracking code, which
>> collects a limited set of technical data.  If Javascript is disabled
>> or not available in your browser then this tracking will not take
>> place and your usage of our websites should not be affected.”
>> 
>> 8. Section on Do Not Track (DNT) made clearer as previous version
>> required you to read the specification to understand it “We do not
>> enable or participate in any third-party tracking of your website
>> activity.  As no third-party tracking is enabled on our website, our
>> websites do not alter their behavior according to the value of a
>> browser Do Not Track (DNT) setting.”
>> 
>> 9. The section on the use of cookies for online transactions has been
>> made clearer “When you log into one of our websites or initiate an
>> online transaction through one of our websites then we may use
>> cookies to uniquely identify you during that session, to record your
>> preferences and to simplify the establishment of new sessions.  If
>> you disable your web browser's ability to accept cookies you will
>> still be able to browse the site but authenticated and transactional
>> services may not function.”
>> 
>> 10. A new section has been added to explain that if we collect
>> demographic information in a survey then that will only be published
>> in an aggregated form that does not allow individual identification.
>> This addition is not needed to enable collection of demographics, we
>> can do that anyway, it is solely to explain what we do if we do
>> collect it.  “We may ask you to provide demographic information (e.g.
>> age, sex, country of residence) in surveys or other information
>> gathering activities.  You are not required to provide that
>> information and your disclosure of that information to us is
>> voluntary.  We do not disclose the demographic information of
>> individuals.  We may publish aggregated information using demographic
>> data as one dimension, in which case we will aggregate at a
>> sufficient level to prevent disaggregation or deanonymization.“
>> 
>> This email now begins a two week consultation on this revised
>> statement, closing on Wednesday 18 December.
>> 
>> If you have any comments or questions then you can submit those by
>> any of the following methods:
>> 
>> * Raising an issue on the Github repository
>> https://github.com/ietf-llc/ietf-privacy-statement-consultation *
>> Direct to me at exec-director@ietf.org * To the ietf@ietf.org list
>> 
>> [1]  https://ietf.org/privacy-statement/ [2]
>> https://github.com/ietf-llc/ietf-privacy-statement-consultation/blob/master/DRAFT%20IETF%20Privacy%20Statement%202019.md
>> 
>> 
> <0x5AB2FAF17B172BEA.asc>

-- 
Jay Daley
IETF Executive Director
jay@ietf.org
+64 21 678840