Subject: Re: [ietf-privacy] Comment: 'Privacy Considerations for Internet Protocols'

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Mar 2013 09:37:14 +0000

On 03/01/2013 05:48 AM, SM wrote:
> 
> 
> At 18:25 28-02-2013, David Singer wrote:
>> in 'privacy considerations' I think we need to explore the privacy
>> consequences of using protocols 'appropriately'.  And there are, and
>> it's no longer OK not to worry about them as we design protocols.
> 
> Yes.

+1

Personally, I have a not-worked-out theory that the kind of
risk analysis we use in security doesn't apply much to
considering privacy and that some other methodology would be
better, or is needed.

Anyone know of generic worked-out methodologies for analysing
privacy issues?

S.

---

From: Robin Wilton <[email-masked]>
Date: Fri, 1 Mar 2013 10:45:40 +0000

Actually, I think what the sentence below illustrates is that a single scenario can represent both security and privacy problems. The key to identifying them seems to me to be about expectations...

- if I expect that by using TLS and "nice long keys", I can keep my conversation secret from the government for 5 years, and they crack it in 5 minutes, then there are clearly some issues with my assumptions about algorithm strength; I'd classify that as a security problem.

- if I expect to be able to have a conversation without the government listening in, and they can and do listen in, then that's a privacy problem.

In other words, the same scenario can be both a security and a privacy problem, depending on the perspective from which you look at it.

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 1 Mar 2013, at 00:34, SM <[email-masked]> wrote:

> Hi Claudia,
> At 14:42 26-02-2013, Claudia Diaz wrote:
>> 
>> - If the gov listens to my encrypted conversations (eg, by reconstructing the conversation from the traffic), it is a security problem.

---

From: Robin Wilton <[email-masked]>
Date: Fri, 1 Mar 2013 10:54:17 +0000

Two areas that I'm aware of:

1 - There's a growing and reasonably mature body of work (mostly in the public sector) on Privacy Impact Analysis. Most of that is based on classifying data as "Personal", "Sensitive Personal" or "Neither of the above" and then assessing the risk and impact of its inappropriate disclosure.

2 - The concept of "harm" is also a key one for privacy risk models, but has distinct shortcomings. For instance, it can't deal well with data breaches where you suspect data has been lost, but you can't tell whether anything bad has happened as a result. It has also been a rather crude metric up to now, with the US, for instance, tending to rule that "harm" must be financial in order to qualify for redress. However, the "harm" model is gradually becoming more nuanced, for instance by classification into 'physical harm, financial harm and reputational harm'. A far as I'm aware, though, that kind of model has yet to be turned into a clear methodology...

HTH,

Robin

Robin Wilton

On 1 Mar 2013, at 09:37, Stephen Farrell <[email-masked]> wrote:

> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Mar 2013 11:37:06 +0000

Hi Robin,

> 2 - The concept of "harm" is also a key one for privacy risk models, but has distinct shortcomings. For instance, it can't deal well with data breaches where you suspect data has been lost, but you…

Got any references? Be good to take a peek.

I guess where I'm unsure is that the risk analysis approach assumes that
we know about vulnerabilities that affect the protocol (either specific
or possible) and we then do a coarse-grained assessment of the threat
(in terms of impact and probability of occurrence); iteratively add
countermeasures to the design, then rinse and repeat until all the
really bad stuff we know about is countered or we've run out of cycles.

That doesn't capture e.g. that an identifier that I keep using for an
extended duration can become more and more personally identifying over
time, nor that the payloads associated with that identifier might get
more (or less) sensitive over time, from a user's perspective. And
probably a bunch of other privacy related things get missed as well
for example the kinds of temporal correlation that was problematic
in the netflix case, [1] or the potential privacy concerns with
the data that a protocol accumulates over time on hosts that take
part in that protocol. (Now that I mention that, maybe there's an
approach there - to do a risk analysis not on the protocol but
on the set of data that hosts playing or watching the new
protocol can possibly accumulate over time, and also considering
the likely other protocols those hosts or watchers can see or
run?)

Basically, I'm puzzled as to how to do a good job here, but I
suspect I'm not alone;-)

BTW, this doesn't impact much on the IAB draft, I don't believe we
have anything much better we can say at this point. It might be
worth mentioning the concern with methodology in that draft though,
and I don't think that's currently done (didn't read it all again
though.)

S.

[1] http://arxiv.org/abs/cs/0610105

---

From: Claudia Diaz <[email-masked]>
Date: Fri, 1 Mar 2013 14:19:47 +0100

On 01 Mar 2013, at 01:22:12, SM wrote:
> At 15:56 26-02-2013, Eric Burger wrote:
>> So what if we just said Security Considerations must include what some people call privacy considerations? If we cannot agree on a concise definition of security vs. privacy, what is the typical draft author going to do?
> 
> Security Considerations can be stuff like "MUST implement TLS".  Privacy considerations would be about the decision of an individual.

Framing privacy as "decision-making" is useful when dealing with privacy settings/policies and user interfaces -- this is actually a usual definition of privacy in HCI (see, eg, the work from Cranor or Acquisti on feedback and awareness, privacy nudges, etc.). 

I would however think that it is too restrictive (and potentially misleading) when addressing privacy considerations more generally, and particularly in protocols that the individual does not necessarily understand in detail. 

Best
Claudia

---

From: Claudia Diaz <[email-masked]>
Date: Fri, 1 Mar 2013 14:32:35 +0100

I agree with all this and I would add other privacy problems not well captured by the "harms" approach, eg, being subject to discrimination as a result of profiles built from behavioral data. Further, focussing on quantifiable harms to the individual does not capture "harms" that affect communities or society at large rather than just individuals, eg, the erosion of basic rights and freedoms that results from intrusive mass surveillance. 

We briefly touch on this topic in a paper we just finished (discussion section). Not sure it is really relevant to this discussion as our focus is to critically compare how social network privacy is framed by computer security and HCI researchers. In case anyone is interested, it is available here https://www.cosic.esat.kuleuven.be/publications/article-2270.pdf

>>> Anyone know of generic worked-out methodologies for analysing

--------------------------------------------------------------------------
Prof. Dr. Ir. Claudia Diaz

Katholieke Universiteit Leuven                       
Dept. Electrical Engineering-ESAT / COSIC
Kasteelpark Arenberg 10, B-3001 Leuven, BELGIUM
tel: +32 16 32 18 14	fax: +32 16 32 19 69

email: claudia.diaz (at) esat.kuleuven.be
web: http://homes.esat.kuleuven.be/~cdiaz/
--------------------------------------------------------------------------

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Fri, 1 Mar 2013 15:16:05 +0000

On 01/03/2013 13:19, "Claudia Diaz" <[email-masked]> wrote:

>>> So what if we just said Security Considerations must include what some
>>>people call privacy considerations? If we cannot agree on a concise
>>>definition of security vs. privacy, what is the typical draft author
>>>going to do?
>> 
>> Security Considerations can be stuff like "MUST implement TLS".
>>Privacy considerations would be about the decision of an individual.
>
>
>
>Framing privacy as "decision-making" is useful when dealing with privacy
>settings/policies and user interfaces -- this is actually a usual
>definition of privacy in HCI (see, eg, the work from Cranor or Acquisti
>on feedback and awareness, privacy nudges, etc.).
>
>I would however think that it is too restrictive (and potentially
>misleading) when addressing privacy considerations more generally, and
>particularly in protocols that the individual does not necessarily
>understand in detail.
>
>BMC>
>
>I would offer that the decision making of the consumer is later in the
>privacy process especially in the IETF context. Our design process is
>orthogonal to the privacy choice of the consumer/user upon service
>signup/purchase.
>
>We must also remember that private data can be processed to deliver the
>service. You need to know my address to deliver the parcel, the mobile
>phone company must know my  ID and my location 0cell tower attachment- to
>connect the call etc etc.
>
>I hallucinate the following process:
>
>We define the data to be collected for a protocol/service/architecture.
>
>We then analyse the resulting list of data and determine if it 'may' be
>affected by privacy concerns.  - This is where we need to make life easier
>for ourselves by having  access to globals relevant guidance and keeping
>it up to date.
>
>We then determine if the context of its use is appropriate within the
>privacy context.
>
>In the above location example the mobile phone company 'may' not 'need'a
>more granular location to deliver the service as sold. Particularly if
>that greater accuracy is to be used to offer value added services or
>insight into the movement of the subscriber.
>They may need a more granular location to offer greater level of original
>service such as informed offload etc.
>
>We can then use the process above to design the architecture to allow the
>greater level of location processing but also recognise that the service
>may need to be offered without than granularity.
>

---

From: Claudia Diaz <[email-masked]>
Date: Fri, 1 Mar 2013 16:19:40 +0100

> connect the call etc etc.

Note that much of the research in privacy-enhancing technologies is about reducing the information that needs to be known to provide the service. For example, there are proposals for anonymous delivery of physical goods (https://www.cs.columbia.edu/~smb/papers/APOD_PETS09.pdf). Other examples in which the required information is reduced beyond what it would seem intuitive include ZK protocols, PIR, etc.

---

From: David Singer <[email-masked]>
Date: Fri, 01 Mar 2013 08:51:07 -0800

On Mar 1, 2013, at 2:54 , Robin Wilton <[email-masked]> wrote:

> 2 - The concept of "harm" is also a key one for privacy risk models, but has distinct shortcomings. For instance, it can't deal well with data breaches where you suspect data has been lost, but you can't tell whether anything bad has happened as a result. It has also been a rather crude metric up to now, with the US, for instance, tending to rule that "harm" must be financial in order to qualify for redress. However, the "harm" model is gradually becoming more nuanced, for instance by classification into 'physical harm, financial harm and reputational harm'. A far as I'm aware, though, that kind of model has yet to be turned into a clear methodology…

Yes, I think the 'harm' framing is problematic in (at least) two respects.

The first is the 'degree' problem. No-one minds if they appear in occasional photos taken by others in public places.  So you are OK with having your photo taken, then?  I can follow you around and take photos or continuous video of you, or face-recognize you in surveillance cameras?  No-one minds if the person behind them in line at a cash desk sees what they buy, or if the storekeeper remembers your favorite brand.  So it's OK to build a dossier of your complete purchase history, then?

The second is the 'prospective harm' question. We all have the instinct that our private data is something that could be used to our detriment in the future. There may be no immediate harm in an ad system keeping track of our browsing visits, purchases, and contributions, and so on.  But if that database 'falls into the wrong hands' there may be harm indeed.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: "Smith, Bill" <[email-masked]>
Date: Fri, 1 Mar 2013 17:02:30 +0000

> The second is the 'prospective harm' question. We all have the instinct that our private data is something that could be used to our detriment in the future. There may be no immediate harm in an ad…

... and then there is the issue of the combination of two (or more) anonymized data sets that are combined by "the wrong hands".

Basic principle should be to exchange the minimum amount of information required to provide service, where minimum is preferably none.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 1 Mar 2013 16:46:38 -0500

> Got any references? Be good to take a peek.

This is from a rather different context but I have found it helpful: http://www.dhs.gov/xlibrary/assets/privacy/privacy_pia_guidance_may2007.pdf

The idea of the questionnaire in section 7 of the draft was in part modeled off of this kind of thing. (Another derivative: <https://www.cdt.org/privacy/20090128threshold.pdf>)

Alissa