Subject: [ietf-privacy] Terminology doc - privacy definition and intro

From: Rhys Smith <[email-masked]>
Date: Wed, 27 Jul 2011 11:25:36 -0400

(Sorry, long email alert!)

So recently I've been thinking about privacy, this document, and our recent conversions on this list.

Firstly, I think the introduction section of the document could do with tweaking. Currently it's not really an introduction but rather a statement of context. And it doesn't really state the purpose of the document. So someone coming in from the privacy cold, as it were, looking for assistance when writing their I-D, needs a more gentle introduction, and to understand how this document can help them.

As discussions on this list have proven, defining privacy is a hard problem. In fact, as a part of my PhD a few years ago I spent a long time looking at privacy, and wrote a journal paper looking at it's history and meaning ([1] if anyone is interested in the topic). So I've felt a lot of pain trying to do just that. So as I've suggested before, I think attempting to do so is folly; instead we just discuss that fact, frame the context precisely, and discuss privacy specifically in this context.

However, rather than just make criticisms and vague suggestions, I've crystallised my thoughts by writing a strawman of an alternative introduction more of the form that I personally would like to see in the document. Forgive the roughness, I've written this at the back of a WG meeting while half-listening to what's going on. Thoughts?

=====

1. Introduction

Privacy is a concept that has been debated and argued throughout the last few millennia by all manner of people, including philosophers, psychologists, lawyers, and more recently, computer scientists. Its most striking feature is that nobody seems able to agree upon a precise definition of what it actually is. Every individual, every group, and every culture have their own different views and preconceptions about the concept - some mutually complimentary, some distinctly different. However, it is generally (but not unanimously!) agreed that the protection of privacy is "A Good Thing".

Even within the specific content of computing and computer science, there are still many facets to privacy. For example, consideration of privacy in terms of personal information is distinctly different from consideration of privacy in a GIS sense: in the former a loss of privacy might be framed as the uncontrolled release of personal information without the subject's consent, while in the latter it might be the unsolicited computation of the location of an individual within a certain degree of accuracy.
 
In order to discuss privacy in any meaningful way a tightly defined context needs to be elucidated. The specific context of privacy used within this document is that of "personal data" - information about an individual stored and/or transmitted electronically. This context is highly relevant since a lot of work within the IETF involves defining protocols that can potentially transport (either explicitly or implicitly) personal data and can therefore either, by dint of design decisions when creating them, enable either privacy protection or result in privacy breaches. In this specific context, discussions of privacy largely centre around the handling, use, and minimisation of the collection, release, and usage of such personal data.

Work in this area of privacy and privacy protection over the last few decades has centred on the idea of data minimization; it uses terminologies such as anonymity, unlinkability, unobservability, and pseudonymity. These terms are often used in discussions about the privacy properties of systems.

The core principal of data minimization is that the ability for others to collect any personal data should be removed. Often, however, the collection of personal data cannot not be prevented entirely, in which case the goal is to minimize the amount of personal data that can be collected.

Data minimization is the only generic strategy to enhance individual privacy in cases where valid personal information is used. Other techniques have been proposed and implemented that aim to enhance privacy by providing misinformation (inaccurate or erroneous information, provided usually without conscious effort to mislead or deceive) or disinformation (deliberately false or distorted information provided in order to mislead or deceive). However, these techniques are out of scope for this document. Data minimization is also the only generic strategy to enable unlinkability if we are excluding providing misinformation or disinformation, since all valid personal data inherently provides some linkability.

Thus, this document aims to establish a basic lexicon around privacy so that IETF contributors who wish to discuss privacy considerations within their work can do so using terminology consistent across the area. Note that it does not attempt to define all terminology, rather it just establishes terms to some of the most common ideas and concepts. The hope is that this will facilitate document authors to more easily discuss privacy considerations of their work.

=====

Alongside this, I would personally agree with Alissa's point way back when of the need to also define terminology around the usage of personal data (primary use, secondary use, primary purpose, secondary purpose, retention, sharing, etc). I don't think you can discuss terminology of how to minimise PII release without being able to also discuss terminology its ultimate potential usage categories.

I'm around all week if anyone wants to discuss the wonderful world of privacy and privacy protection...

Kind Regards,
Rhys.

[1] http://www.rsmith.org.uk/publications/ecom_res_rhyssmith.pdf
--
----------------------------------------------------------------------
Dr Rhys Smith                                   e: [email-masked]
Engineering Consultant: Identity & Access Management  (GPG:0xDE2F024C)
Information Services,
Cardiff University,                            t: +44 (0) 29 2087 0126
39-41 Park Place, Cardiff,                     f: +44 (0) 29 2087 4285
CF10 3BB, United Kingdom.                      m: +44 (0) 7968 087 821
----------------------------------------------------------------------

---

From: Scott Brim <[email-masked]>
Date: Wed, 27 Jul 2011 11:59:02 -0400

On Wed, Jul 27, 2011 at 11:25, Rhys Smith <[email-masked]> wrote:
> In this specific context, discussions of privacy largely centre around the handling, use, and minimisation of the collection, release, and usage of such personal data.

Not necessarily minimisation -- since I release different pieces of
information about myself to selected parties all the time.  Rather,
it's about _control_.  IMHO change minimisation to control and you're
good.

Scott

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Wed, 27 Jul 2011 18:06:34 +0200

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott Brim
Sent: 27 July 2011 16:59
To: Rhys Smith
Cc: [email-masked]
Subject: Re: [ietf-privacy] Terminology doc - privacy definition and
intro

On Wed, Jul 27, 2011 at 11:25, Rhys Smith <[email-masked]> wrote:
> In this specific context, discussions of privacy largely centre around
the handling, use, and minimisation of the collection, release, and
usage of such personal data.

Scott

BMC>

I agree with minimisation. Excess collection may lead to excess
processing. Collecting/using the minimum needed is a good principle as
it encourages that  any additional  processing information is justified.

Bryan

---

From: Scott Brim <[email-masked]>
Date: Wed, 27 Jul 2011 12:27:59 -0400

> it encourages that  any additional  processing information is justified.

Bryan: minimising the information I share is easy: I reveal nothing to
anyone ever.  That doesn't solve many problems, does it?  So
minimisation is not the goal.  What matters is being able to control
what you reveal (what you must reveal) so that you can reveal only
what you think should be.

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Wed, 27 Jul 2011 18:37:08 +0200

-----Original Message-----
From: Scott Brim [mailto:[email-masked]] 

BMC> Is it easy to control? If a process is created that utilises  extraneous - as in not absolutely needed-  information then soon it may be defacto required and you and others will 'need' to provide it.

Minimisation is pertinent to our recent work in mobility. Being able to identify a subscribers geo-location is needed. But to what extent is my location needed?  To determine my location to the minimal amount to provide the connection OR to the maximal amount to create/add additional LBS?

Bryan

---

From: David Singer <[email-masked]>
Date: Wed, 27 Jul 2011 12:02:07 -0700

comments inline...

> Privacy is a concept that has been debated and argued throughout the last few millennia by all manner of people, including philosophers, psychologists, lawyers, and more recently, computer scientis…

maybe add "and often, people only realize what it was when they feel that they have lost it"

> 
> Even within the specific content of computing and computer science, there are still many facets to privacy. For example, consideration of privacy in terms of personal information is distinctly different from consideration of privacy in a GIS sense:

using an acronym this early on isn't great

> In order to discuss privacy in any meaningful way a tightly defined context needs to be elucidated. The specific context of privacy used within this document is that of "personal data" - information about an individual stored and/or transmitted electronically.

oh, ow.  This leans towards "personally identifiable information" which, in turn, leads to "well, it wasn't *about* Rhys when I collected it, it was anonymized".  I think we're going to have to learn to be careful with personally *derived* information, which is quite a bit wider, alas. The ability to correlate, de-anonymize, and so on, means that "information *about* an individual" is too narrow.

> The core principal of data minimization is that the ability for others to collect any personal data should be removed. Often, however, the collection of personal data cannot not be prevented entire…

"collect only the appropriate amount of personally derived data, and then provide the appropriate level of care, visibility, and control over the collected data"?

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Jul 2011 06:28:56 +0900

On Thu, Jul 28, 2011 at 4:02 AM, David Singer <[email-masked]> wrote:

> > Privacy is a concept that has been debated and argued throughout the last
> few millennia by all manner of people, including philosophers,
> psychologists, lawyers, and more recently, computer scientists. Its most
> striking feature is that nobody seems able to agree upon a precise
> definition of what it actually is. Every individual, every group, and every
> culture have their own different views and preconceptions about the concept
> - some mutually complimentary, some distinctly different. However, it is
> generally (but not unanimously!) agreed that the protection of privacy is "A
> Good Thing".
>
> > Even within the specific content of computing and computer science, there
> are still many facets to privacy. For example, consideration of privacy in
> terms of personal information is distinctly different from consideration of
> privacy in a GIS sense:
>
> > In order to discuss privacy in any meaningful way a tightly defined
> context needs to be elucidated. The specific context of privacy used within
> this document is that of "personal data" - information about an individual
> stored and/or transmitted electronically.
>
> oh, ow.  This leans towards "personally identifiable information" which, in
> turn, leads to "well, it wasn't *about* Rhys when I collected it, it was
> anonymized".  I think we're going to have to learn to be careful with
> personally *derived* information, which is quite a bit wider, alas. The
> ability to correlate, de-anonymize, and so on, means that "information
> *about* an individual" is too narrow.
>

+1 Personally derived information is potentially more important and has
greater impact.

>
> > The core principal of data minimization is that the ability for others to
> collect any personal data should be removed. Often, however, the collection
> of personal data cannot not be prevented entirely, in which case the goal is
> to minimize the amount of personal data that can be collected.
>
> "collect only the appropriate amount of personally derived data, and then
> provide the appropriate level of care, visibility, and control over the
> collected data"?
>

+1

> what you think should be.

+1 Being able to selectively disclose one's information is very important
in
forming intended relationship with the party or recognition by the party.
Just minimizing the information from the point of view of the receiving
party will not do the job.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 27 Jul 2011 23:56:20 +0200

On Jul 27, 2011, at 11:28 PM, Nat Sakimura <[email-masked]> wrote:

> +1 Personally derived information is potentially more important and has greater impact. 

Yes, I consider correlation of data over time, across layers or across different sources as the potential biggest problem because most (all?) users will not be aware of the potential for collusion, at the same time this is very hard to capture in a way that leads to workable guidelines for ID authors.

Things that come to mind are:

- limit storing of information (protect against correlation over time)
- don't use identifiers on one layer to generate identifiers on other layers (correlation across layers)
- targeted identifiers (correlation across sources)
- minimize information to what is needed to provide the service (ditto)

Klaas

> +1 Being able to selectively disclose one's information is very important in 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: Rhys Smith <[email-masked]>
Date: Wed, 27 Jul 2011 18:08:15 -0400

Thanks for all of the comments so far. I think all suggestions are good and could be worked into what I came up with.

I should stop here though and say that this is of course Mark and Hannes' document, and it's up to them whether they'd like to accept something based off of my text into it. If they are, the comments received so far obviously need addressing - and as I said, that text was written pretty quickly and I'm sure could be tidied up a bit as well...

Hannes - I'm happy to help you out with the document if you'd like - both with the intro and by providing feedback on the rest of it - I think there are lots of places further on in the doc where the language could be tidied up, at the very least.

R.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 28 Jul 2011 22:49:32 +0200

* Rhys Smith wrote:
>Firstly, I think the introduction section of the document could do with
>tweaking. Currently it's not really an introduction but rather a
>statement of context. And it doesn't really state the purpose of the
>document. So someone coming in from the privacy cold, as it were,
>looking for assistance when writing their I-D, needs a more gentle
>introduction, and to understand how this document can help them.

I would turn this the other way around and say that it's not very clear,
neither from the document nor otherwise, what assistance is needed, what
problems people have and which problems people would like to see solved.

http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0234.html is
an example from this week, HTTP caching can be abused to enable cookie-
like tracking, but the specification does not say so. Is that a problem,
should IETF documents always point out such possibilities for abuse? If
so, then that is primarily a policy problem, not a terminology problem.

My impressions is that most privacy-related problems in the context of
IETF documents are not terminology problems. What I mainly see is that
the people who come up with new protocols and programming interfaces are
wired or trained to consider the privacy implications of their ideas.

A while ago for instance someone proposed a web browser notification or
status that would indicate to a web page whether the device is currently
used by a human user (so an instant messaging application could mark the
user as being away or present automatically for instance). The proponent
couldn't see any privacy implications with that.

Another example is the "geo location" programming interface. A user may
tell the browser "this time it's okay to disclose the location", and the
user may additionally say "next time this web site asks, it's okay too".
The first time the user encounters such a prompt, he is very likely to
do something where disclosing the information makes sense, and the site
being seemingly reasonable he might trust to deactivate future prompts.

It's obvious that the user would not realize in this context that he'd
be agreeing for the site to constantly monitor his movements without him
knowing, and sites that make reasonable use of this feature would object
to the browser saying in the prompt "do you want to constantly monitor
your movements" as that is not what the reasonable sites want to do, but
that does not stop people active in the standards community from asking
to be able to tell whether users checked the "don't ask next time" box.

Now the Working Group there as a whole realized this problem and so the
feature is not available, but it's unpopular these days to explain such
issues so a rationale for the absence of this feature is not given in
the specification. Similarily, it does not discuss risks such as that a
third party analytics or ad script could, for instance, wrap the geo lo-
cation API, so the ad or analytics provider learns the location of the
user every time a site that embeds their services obtains it.

There are terminology problems that I can think of, but I largely do not
encounter them in protocol specifications and where I do, I am unsure it
would be right for the IETF to address them in some meaningful form. For
instance, the boundaries between "anonymous", "pseudonymous", and a form
of "personally identifying" are often unclear, but the terms are legally
significant and I don't see people from cultures that have very relaxed
views regarding these terms finding consensus with people from cultures
that have rather stringent views regarding them within the IETF.

So I am more looking for something that helps people being more aware of
issues, understand them better, perhaps come up with good policies for
authors of protocol specifications, but providing "definitions" of terms
does not strike me as very useful at this point (conveying ideas behind
terms is important, but you can do this without overly sharp bounds). If
we develop a clearer idea of what the goals are, I think it should be
much easier to explain "privacy" or whatever term needs explaining.

>Privacy is a concept that has been debated and argued throughout the
>last few millennia by all manner of people, including philosophers,
>definition of what it actually is. Every individual, every group, and
>every culture have their own different views and preconceptions about
>the concept - some mutually complimentary, some distinctly different.
>However, it is generally (but not unanimously!) agreed that the
>protection of privacy is "A Good Thing".

To me, "privacy" is an english word that's overused due to the lack of
other terms that take context better into account, leading to running
gags such as the impossibility to define it strictly. In german, we do
not have one singular word I could use in a translation of the text a-
bove. And the idioms that are used in german instead, are not seen as
hard to define as far as I am aware. I think it would be wrong to have
text in a RFC that doesn't translate well, but I am unsure how to take
that plus the desire to use the term for english natives into account
if you keep the scope broad like that.

It seems likely to me that an IETF document would not go into details
concern german "Intimsphäre" (something that contains your innermost
thoughts, feelings, health and sexlife, things people maintain tight
control over; a higher level concept would be "Privatsphäre", an area
in life where people develop undisturbed by external influence), but
rather "Datenschutz" (safeguarding, insulation, protection of data).

You would find for instance that on Wikipedia en:Privacy links to the
de:Privatsphäre article, but on web sites, where you would expect some
link to a Privacy Policy, you'll typically find a "Datenschutz" link,
but then the "privacy settings" would be "Privatsphäre-Einstellungen"
(which is largely a localization problem, much like "social networks"
typically translate "sharing" as "teilen" which means "dividing" as
much as "sharing", a divisor is a Teiler, for instance).

Point being, by narrowing what aspect of "privacy" might be relevant
to IETF processes, we can offer a much better, coarser, definition,
that readers can better relate to than saying that philosophers have
a hard time grasping the concept but it's a good thing.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Jul 2011 16:58:56 -0400

Hey Bjoern

I believe you have not seen that this terminology document comes with another document, a guidelines document: 
http://tools.ietf.org/html/draft-morris-privacy-considerations-03

At the IAB plenary this Monday we tried to explain the purpose (on a high level), see 
http://www.ietf.org/proceedings/81/slides/plenaryt-14.ppt

In a nutshell, we would like to have a more consistent way to talk about privacy in IETF documents. This requires two aspects: 
 * terminology, and 
 * additional guidance on what to write about. 

Ciao
Hannes