Subject: Re: [ietf-privacy] Is there an official working definition for Privacy Online?

From: Dave Crocker <[email-masked]>
Date: Sun, 1 May 2016 16:11:33 -0700

On 4/23/2015 12:52 PM, Joseph Lorenzo Hall wrote:
> On Sat, Apr 18, 2015 at 12:08 AM, Christian Huitema <[email-masked]> wrote:
>> On Friday, April 17, 2015, at 9:14 AM, Dave Crocker wrote
>>> ...
>>> This translates into "privacy relates to controlling disclosure of
>>> information about a person or organization."  Then add the
>>> scope-of-control portion.
>>
>> There is indeed some fuzziness in the definition of privacy.
...
> There is emerging academic work (not published yet, so I won't cite)
> that discusses privacy as what philosophers call an "essentially
> contested concept."

If the term is to be a non-technical and vague reference, then let's 
stop using it as if it were a technical term.  Philosophical, academic 
and social terms are fine; the problem is when we use them as if they 
pertained to technical specifics.

If we intend the term to have technical utility, it's needs precise and 
useful definition.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 May 2016 14:29:51 -0700

On Sunday, May 1, 2016 4:12 PM, Dave Crocker wrote:
> 
> If the term is to be a non-technical and vague reference, then let's stop
using it
> as if it were a technical term.  Philosophical, academic and social terms
are
> fine; the problem is when we use them as if they pertained to technical
> specifics.

Well, we do use the term "security" liberally, don't we? It is certainly
just as vague, but it is useful as a section header. It encourages protocol
designers to be concerned with the broad issue of security attacks. I think
that we have consensus that protocol designers should also be concerned with
the broad issue of privacy attacks.

> If we intend the term to have technical utility, it's needs precise and
useful
> definition.

It took some time to establish categories for security attacks -- denial of
service, information disclosure, spoofing, elevation of privilege, etc. The
analysis of privacy attacks is not quite as advanced, but we start getting
broad categories, such as disclosure of the exchanged data, disclosure of
metadata, linkability of different activities, and disclosure of traffic
patterns. As we gain more experience, I expect that these categories will
stabilize.

-- Christian Huitema

---

From: David Singer <[email-masked]>
Date: Wed, 04 May 2016 16:53:08 -0700

I agree, at the moment ‘privacy’ is defined roughly as the things you miss when you realize you have lost it, which is not a usable definition; but I also agree, we’re in the process of learning.

One of the big realizations I had as a result of the W3C workshop was that we tend to equate privacy with a lack of knowledge i.e. if we could all be anonymous online, we’d be private, which while true, leaves a whole load of questions unanswered.

In the physical world, there are a whole bunch of aspects to privacy that we intuitively understand (though they may vary by culture); it’s not hard to imagine situations where people would respond ‘you just don’t do that!’. Much real-world privacy respects context, for example (if you meet your therapist at a party, you know it’s him and he knows it’s you and you both know there are certain subjects you won’t talk about).  There are also aspects of degree (people don’t mind being an accidental inclusion in someone else’s photo snapshots, but they do mind if they are featured or a video continues to include them).

So, just as security has sub-areas, I would argue that privacy does: anonymization, data minimization, respect for context, degree/quantity, and so on.

Finally, I have long pleaded that those concerned with privacy but technology-unaware — philosophers, legislators, et al. — give us more insight into this question (“what is online privacy”) and say less about technologies, as I am confident that if we understood the field and the principles better, engineers would work out what that meant in engineering and technology terms.

> On May 2, 2016, at 14:29 , Christian Huitema <[email-masked]> wrote:
> 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

Dave Singer

[email-masked]

David Singer
Manager, Software Standards, Apple Inc.

---

From: Robin Wilton <[email-masked]>
Date: Thu, 5 May 2016 08:30:55 +0000

The Internet Society has been using a definition of privacy for a number of years now, and I still think it's a good one. Incidentally, I think Dave has set a high bar with his request; privacy is a social construct that covers many aspects of the way people interact with each other... it's always going to be hard to reduce that to a single, precise technical definition, the way you might do for, say, "gross domestic product", or "mortgage". 

Privacy can also be a subjective thing (for instance, some people think it's important to draw their curtains in the evening - others don't). That subjectivity makes privacy a highly contextual thing, which, again, may make it hard to reduce to a single precise formula. But I digress... Here's that definition:

Privacy is about retaining the ability to disclose data consensually, and with expectations regarding the context and scope of sharing.

I wrote a blog post drawing out the implications of each part of that definition, here:

http://www.internetsociety.org/blog/2013/12/language-privacy

The result still may not be the precise technical definition Dave is looking for... but I think it helps make explicit the different factors to which we could apply technical solutions. For instance, can we secure the disclosure of data in such a way that the contextual nature of the disclosure is protected? What technical measures can we put in place to ensure meaningful consent? Can we technically limit the scope of a disclosure? Can we reflect the nature of the relationship between the disclosed and the recipient?

We might, of course, conclude that it's hard or impossible to achieve tho goals by the application of technology alone, but at least we'd be reaching that conclusion through a relatively systematic analysis.

Hope this helps a bit,

Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 May 2016 06:20:25 -0700

On 5/5/2016 1:30 AM, Robin Wilton wrote:
> Privacy can also be a subjective thing (for instance, some people
> think it's important to draw their curtains in the evening - others
> don't). That subjectivity makes privacy a highly contextual thing,

This is an Alice, Through the Looking Glass perspective on the term.

At the least, it means it is not a technical term, in which case using 
it in technical contexts is mostly going to cause confusion, since one 
speaker's intended meaning will differ from another listener's...

Standards work is primarily an exercise in gaining group consensus on 
technical specifics.  If 'privacy' is to be a technical term, then we 
need to agree on its specifics.  That doesn't mean the term needs lots 
of fine-grained detail.  In fact, for something this important and this 
basic, it needs as little detail as possible, while still serving to 
guide technical choices.

> Privacy is about retaining the ability to disclose data consensually,
> and with expectations regarding the context and scope of sharing.
...
 > http://www.internetsociety.org/blog/2013/12/language-privacy

This looks like an entirely reasonable and helpful definition, as I 
noted a year ago.

There are other, similarly short and focused, definitions. Each is 
reasonable.  And while the differences in the definitions probably 
matter, I think that the need to focus technical work requires choosing 
one.  If we want the term to have useful substance.

The fact that choosing one has some challenges is being used as a reason 
for not trying.  That's an ironic excuse, for an organization whose 
primary reason for being is the development of community consensus on 
non-trivial choices...

d/
-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 14:30:23 +0100

> This looks like an entirely reasonable and helpful definition, as I

It's definitely not bad:-)

I think it misses a bit though, in our context. Sometimes we just
have to expose an identifier (e.g. a source IP address) and that
can be privacy-sensitive, but there's no real way in which it's
consensual, unless one considers even connecting to the network
as consenting in some form to such exposure, which'd be odd I
think.

So while Robin's text is pretty good when I think about payloads,
it doesn't seem to cover issues with meta-data and other protocol
artefacts so well. I'm also not sure how much that'd help when it
comes to considering re-identification issues which can be very
subtle (cf. netflix competition).

But it's a good start.

> primary reason for being is the development of community consensus on

I'd be happy if someone wanted to try craft some definitional text
say in an I-D, with the goal of meeting Dave's challenge to define
privacy in a way that's useful for IETF work. I don't know
if that'd end up as an RFC, but it might, and if well-done, and if
it garnered consensus, it could be quite useful.

Cheers,
S.

---

From: Robin Wilton <[email-masked]>
Date: Thu, 5 May 2016 13:48:26 +0000

2 comments inline… 
> On 5 May 2016, at 14:30, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Thanks, Stephen - 

Very good point… metadata was definitely on the radar back then, but not high enough to feature explicitly in the definition.

I think subsequent discussion about “each layer of the network only exposing such data as is needed for it to function” goes a certain way in that direction, but you’re right, it would benefit from higher visibility.

> it garnered consensus, it could be quite useful.

I’d be happy to work with Dave and others on draft wording...

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 May 2016 07:53:23 -0700

> On May 2, 2016, at 2:29 PM, Christian Huitema <[email-masked]> wrote:
> 

+1. If people want to consider privacy as a heading under which we group a bunch of different kinds of attacks, that works perfectly well I think.

Rather than spending a lot of time to try to find a magical two-sentence definition that everyone can agree on (which I doubt is feasible), I think the time would be better spent on refining how we define the set of attacks and mitigations against them, building on or fixing what’s in RFC 6973, possibly turning bits of that into a BCP, etc. The two sentences will not be directly actionable no matter what they say, whereas a comprehensive threat model and mitigations suite could be.

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 16:12:20 +0100

On 05/05/16 15:53, Alissa Cooper wrote:
> +1. If people want to consider privacy as a heading under which we
> group a bunch of different kinds of attacks, that works perfectly
> well I think.

In the case of privacy, not all the bad things are correctly
described as attacks IMO. E.g. leaving sensitive data in a
log file for too long is not in itself an attack, but can be
risky. Only emitting packets when a user is present similarly.

I'm not even sure the risk analysis method we use for security
is the best way to try address privacy in IETF work. But I did
raise that when 6973 was being done and given that I didn't
have a better method to offer (and still don't) that didn't
make it into the doc:-)

> 
> Rather than spending a lot of time to try to find a magical
> two-sentence definition that everyone can agree on (which I doubt is
> feasible), I think the time would be better spent on refining how we
> define the set of attacks and mitigations against them, building on
> or fixing what’s in RFC 6973, possibly turning bits of that into a
> BCP, etc. The two sentences will not be directly actionable no matter
> what they say, whereas a comprehensive threat model and mitigations
> suite could be.

Maybe. I still think that an introductory part of such a document
would be better if we had some definition of what we mean by privacy
when we use the term in IETF documents. (Note: I don't think we need
the one true definition of privacy for the Internet, and I'd agree
with you that we won't get that done.)

I do like the idea of BCP'ing bits of 6973 where it makes sense to
do so regardless of whether or not we come up with some useful
definition.

S.

---

From: Robin Wilton <[email-masked]>
Date: Thu, 5 May 2016 16:09:15 +0000

Apologies for top-posting, but this is a general reply rather than point-by-point responses…

It feels like a possible goal, then, is a short piece of text which contains sufficient “hooks” to link to other material (which in turn can define specific aspects of the problem in appropriately technical/engineering terms). That might reduce the need for the short piece of text to be magical, while still giving us the means to refer to facets of the privacy problem such as risk analysis, attack models, etc..

As I say, I’d be very happy to work with Dave and others on this, though in the immediate short term I am very limited for bandwidth. 

In terms of my own expectation: if we don’t achieve the magical two-liner, but we learn something about systematic description of privacy problems in technical/engineering terms, I’ll be happy. If we get a workable, non-engineering-precision two-liner plus some paragraphs in more technical terms, I’ll be radiant. On second thoughts, that prospect may put people off.

R

PS - now considering trademarking “SPOT” for “Short Piece Of Text” - as in “this is the SPOT definition of x”.

> On 5 May 2016, at 16:12, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: David Singer <[email-masked]>
Date: Thu, 05 May 2016 13:39:02 -0700

> On May 5, 2016, at 1:30 , Robin Wilton <[email-masked]> wrote:
> 

Hm, I think it’s good, but...So, if I appear in public, I have disclosed my presence in a particular location and time; but my expectations on people recording me with video cameras, writing down what I do for posterity and the internet, and so on, is part of the ‘expectations’?  If so, we’re back in the morass, I fear — what is ‘expected’ is at least cultural and often personal.

> The result still may not be the precise technical definition Dave is looking for…

Actually, I think we need to continue to work with the vagueness; looking now for a definition is not helpful.  Looking for clarity on the concepts and aspects — “what the rules are” — I think is amenable to at least significant improvement.

David Singer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 May 2016 15:08:58 -0700

On 5/5/2016 1:39 PM, David Singer wrote:
> Actually, I think we need to continue to work with the vagueness; looking now for a definition is not helpful.

As a social term, perhaps. Social discourse uses and often needs 
vagueness and even ambiguity.

But again:  How is it possible to use a term as a technical reference, 
if there is not precision to its use?  This being the IETF, and 
'privacy' being a particularly fashionable term, the question is 
fundamental.

d/

-- 

   Dave Crocker

---

From: Nick Doty <[email-masked]>
Date: Thu, 5 May 2016 18:10:05 -0700

> Rather than spending a lot of time to try to find a magical two-sentence definition that everyone can agree on (which I doubt is feasible), I think the time would be better spent on refining how we…

+1. RFC 3552 doesn't provide a two-sentence definition of "security", but points out that the definition is not simple, but instead a common grouping of properties and threats, which get more detailed definitions in subsequent sections. Similarly, RFC 6973's terminology section does provide technical definitions of terms like unlinkability, fingerprinting, etc.

I do tend to agree with the conclusion that as a result we shouldn't be using "privacy" as a technical term on its own. Sentences in specs of the form "Feature X undermines privacy" or "Feature Y provides privacy to the end user" are either inappropriate, or more likely, incomplete. Instead: "Feature Y supports privacy by providing unlinkability of traffic between requests".

It might still be useful to refine a short definition that can be cited to speed up conversations on privacy at IETF or help in scoping work; NIST, for example, has been trying to come up with privacy engineering objectives analogous to the C-I-A triad for security.

Cheers,
Nick

---

From: Peter Schoo <[email-masked]>
Date: Fri, 6 May 2016 11:56:12 +0200

> risky. Only emitting packets when a user is present similarly.

Descriptions of privacy (and security taken as example for how to make a
privacy definition) are discussed on different levels. Robin's two-liner
needs to be applied and interpreted. Effect is that it raises
understanding, but takes time and effort to seriously discuss it, which
is good to do.

On the other hand, it helped to establish, as Christian wrote,
categories for security attacks -- denial of service, information
disclosure, spoofing, elevation of privilege, etc. Agreed attacks
categories form common ground and makes it more useful in standards.
Something similar would be useful for privacy too, as the set of
potential threat is blurred or the understanding of threats and impacts
changes with deeper discussions, more thorough investigations.

Why are these differences? Sure, the nature of security and privacy are
somewhat different.

> is the best way to try address privacy in IETF work. 

and that's why many apply privacy impact assessments, which have a
different focus when you analyse a system/service/whatsoever, e.g.
concerning time. I argue that security threats typically do not last as
long as privacy threats, they are bound to communication sessions or
periods of subscription - more overseeable. Clever data fusion can
create threats the day after tomorrow.

Security discussions sometimes comes with properties or services that
shall be provided, e.g. authentication, authorisation, confidentiality,
integrity, availability, or CIA etc. This part of a taxonomy is not
present in the privacy discussion. Like we detail security in
(permutations of) CIA, I miss detailing privacy here. Today privacy
papers often apply Anonymity, Unlinkability, Undetectability, Plausible
deniability and Confidentiality.

All of the security definition approaches are helpful, two liners,
attacks and properties. Concerning privacy we are still learning about
threats and how to categorize them, to make these categories useful for
standards. Though it might be different with finding a suitable
taxonomy, i.e. relevant to IETF, that help detailing privacy aspects.

BR
	Peter

-- 
Peter Schoo, [email-masked]

---

From: Robin Wilton <[email-masked]>
Date: Fri, 6 May 2016 12:39:34 +0000

Thanks Peter,
very useful.

I think the underlying “meta”-issue here is emerging…

If we assume that you can start with a “high-level” definition that needs to be applied and interpreted by “lower-level” descriptions and guidance, and that it is theoretically possible to acheve the desired level of precision at those lower levels, then the question then is: can the high-level definition have a degree of vagueness but still be of value?

If we can accept (at least as a working assumption) that some level of vagueness in the high-level definition can be consistent with acceptable levels of precision in the descriptive/interpretive text “further down”, then I think that will save us having to agonise over whether the “two-liner” is precise enough… it might be that it can be vague, provided it is inclusive.

In other words: you can have a (non-technical) principle, stated in non-technical and possibly vague terms, whose application can be described in precise technical terms.

Does this line of reasoning make sense, as a framework for going forward? It seems to me to allow people to contribute at various layers,  without making their contribution conditional on perfection at some layer other than the one they’re interested in.

R

> On 6 May 2016, at 10:56, Peter Schoo <[email-masked]> wrote:
>

---

From: Pranesh Prakash <[email-masked]>
Date: Tue, 10 May 2016 11:54:07 +0530

> I do tend to agree with the conclusion that as a result we shouldn't be using "privacy" as a technical term on its own. Sentences in specs of the form "Feature X undermines privacy" or "Feature Y p…

+1

I feel thinking in terms of characteristics of privacy, rather than 
"privacy" is useful, since it helps us move beyond the idea that privacy 
is an unqualified good, to viewing it as a set of characteristics that 
should be considered with seriousness during protocol design.

For instance: Anonymous communication mechanisms (a privacy 
characteristic) allow people to avoid detection while publishing 
confidential third-party communications (another privacy 
characteristic).  That violation of privacy is not something that can be 
tackled at a protocol level.  However, that to me demonstrates that 
there may potentially be inherent trade-offs and conflicts, even within 
various privacy characteristics.  Hence, viewing "privacy" as a singular 
idea makes no sense to me.

> It might still be useful to refine a short definition that can be cited to speed up conversations on privacy at IETF or help in scoping work; NIST, for example, has been trying to come up with priv…

Given the above, I don't see why a short definition is required or how 
it would be helpful.  Perhaps my problem is with the word "definition", 
while, on the other hand, listing a set of "characteristics" or 
"categories" is what would be useful (and perhaps that is what was meant).

~ Pranesh

-- 
Pranesh Prakash
Policy Director, Centre for Internet and Society
http://cis-india.org | tel:+91 80 40926283
sip:[email-masked] | xmpp:[email-masked]
https://twitter.com/pranesh