Subject: Re: [ietf-privacy] Fwd: New Version Notification for draft-iab-privacy-considerations-03.txt

From: Nikos Fotiou <[email-masked]>
Date: Thu, 9 Aug 2012 00:48:29 +0300

Dear all,
This the first time I send something in this list, so I ask you
beforehand to excuse me if this mail is out of scope.

I was reading draft-iab-privacy-considerations-03.txt and I found it
very interesting. However I have the feeling that Section 5 does not
take into account the advances of the “private data analysis” research
field. To my understanding research efforts in this field argue that
data minimization and anonymization are not always enough, bringing as
an example the incidence of the AOL anonymized logs. What is proposed,
in order to protect users' privacy, is to lower the “data utility” by
adding “noise”.

IMHO a useful guideline for protocol designers would have been to
encourage them to design protocols that can tolerate a level of noise
(obscurity if you will) in the data provided by the users.

Best,
Nikos Fotiou

On Thu, Jul 19, 2012 at 5:37 PM, Alissa Cooper <[email-masked]> wrote:
> Feedback on this draft is welcome.
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: July 16, 2012 3:04:37 PM EDT
>> To: [email-masked]
>> Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
>> Subject: New Version Notification for draft-iab-privacy-considerations-03.txt
>>
>>
>> A new version of I-D, draft-iab-privacy-considerations-03.txt
>> has been successfully submitted by Alissa Cooper and posted to the
>> IETF repository.
>>
>> Filename:      draft-iab-privacy-considerations
>> Revision:      03
>> Title:                 Privacy Considerations for Internet Protocols
>> Creation date:         2012-07-16
>> WG ID:                 Individual Submission
>> Number of pages: 36
>> URL:             http://www.ietf.org/internet-drafts/draft-iab-privacy-considerations-03.txt
>> Status:          http://datatracker.ietf.org/doc/draft-iab-privacy-considerations
>> Htmlized:        http://tools.ietf.org/html/draft-iab-privacy-considerations-03
>> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-iab-privacy-considerations-03
>>
>> Abstract:
>>   This document offers guidance for developing privacy considerations
>>   for inclusion in IETF documents and aims to make protocol designers
>>   aware of privacy-related design choices.
>>
>>   Discussion of this document is taking place on the IETF Privacy
>>   Discussion mailing list (see
>>   https://www.ietf.org/mailman/listinfo/ietf-privacy).
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
>
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: Robin Wilton <[email-masked]>
Date: Wed, 8 Aug 2012 23:07:51 +0100

Hi Nikos,

I think that's a very interesting idea. Like you, I also think we probably underestimate the extent to which data minimisation and anonymisation techniques genuinely obscure personal data. And yet very often, they are the only answers to the question "What is 'Privacy By Design?'"...

It could be that introducing noise or fuzziness into personal data is another candidate. Certainly, current laws describing 'personal data' omit a lot of data types that can adversely affect privacy - so rather than wait for the law to redefine 'personal data', perhaps we should change the nature of the data as you suggest.

Yrs.,
Robin

Sent from my iPod

---

From: Ashok Malhotra <[email-masked]>
Date: Wed, 08 Aug 2012 15:37:51 -0700

In the Geolocation work, one of the features that was discussed was an option that would
provide an indistinct location such as the town or the county or perhaps even only the country.
This adds fuzziness although not noise.  If you add noise then, in the location case, you could end
up with an incorrect location which may not be acceptable

All the best, Ashok

On 8/8/2012 3:07 PM, Robin Wilton wrote:
> On 8 Aug 2012, at 22:48, Nikos Fotiou<[email-masked]>  wrote:
>
>> Dear all,
>> On Thu, Jul 19, 2012 at 5:37 PM, Alissa Cooper<[email-masked]>  wrote:

---

From: Rhys Smith <[email-masked]>
Date: Wed, 8 Aug 2012 23:49:40 +0100

There are a few different approaches to this idea of data perturbation, but they are not always applicable, as Ashok points out. Typically this is mainly done in the database world where people are more interested in statistics over data sets rather than particular data elements. In this case, there are a few approaches - you can add "noise" with essentially a mean of zero thus not affecting the overall stats, you can swap data between data elements, and so on. These approaches do end up changing the statistical information eventually though, so it's usually a trade-off between privacy and utility (as always).

I personally think it might be worth quickly mentioning the idea, but not in too much detail, just providing a link for further reading - this is a rich research topic in its own right and probably a bit much for most people…

Best,
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: SM <[email-masked]>
Date: Wed, 08 Aug 2012 16:30:30 -0700

Hi Ashok,
>perhaps even only the country.

That can be described as granularity.  It is not mentioned directly 
in the draft.  There may be some indirect references in some of the text.

Regards,
-sm

---

From: Nikos Fotiou <[email-masked]>
Date: Thu, 9 Aug 2012 02:48:13 +0300

I will argue with Robin that "current laws describing 'personal data'
omit a lot of data types that can adversely affect privacy". Take for
example the work of Xie at al. about "De-anonymizing the Internet
Using Unreliable IDs",
(http://research.microsoft.com/pubs/80964/sigcomm09.pdf) who managed
to track hosts  using their application layer activity.  As another
example (and since we are talking about Internet protocols), I believe
a user would not experience any problem if in every HTTP request was
providing different, but compatible, user-agents (and in some cases
even non-existing user-agents) (Yen et al. in "Host Fingerprinting and
Tracking on the Web: Privacy and Security Implications"
(http://research.microsoft.com/pubs/156901/ndss2012.pdf) mentioned
that “ 60%-70% of HTTP user-agent strings can accurately identify
hosts in our datasets”)

Finally there are already networking applications in which such ideas
are applied. Take for example the "Differentially Private
Network-Trace-Analysis Tools", developed by Microsoft
http://research.microsoft.com/en-us/downloads/b25759f8-db91-48a0-a1b5-87c21f9e3292/
A network mangement protocol based on "fuzzy data" seems realistic to
me.

Best,
Nikos

---

From: Nikos Fotiou <[email-masked]>
Date: Thu, 9 Aug 2012 02:51:51 +0300

I will *agree with Robin

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Aug 2012 17:49:35 -0700

> up with an incorrect location which may not be acceptable

Speaking as someone intimately involved in the research into location
"fuzzing", the geopriv working group came to an interesting set of
conclusions:

First and foremost, don't bother.  Every algorithm we developed could
be easily attacked or circumvented by someone who has more information
than the fuzzer.  We had some good algorithms that would be really
effective at hiding the location of someone who is moving randomly
across salt flats, desert or ocean.  For real-world applications those
same algorithms sucked.  Human beings are just far too predictable.

Now I don't know this for certain, but - intuitively - this same
conclusion most likely applies to other aspects of data minimization.

--Martin

---

From: Ashok Malhotra <[email-masked]>
Date: Thu, 09 Aug 2012 04:48:43 -0700

Fascinating!  So if the Geolocation says "Boston" your algorithms, based on past
behavior I presume, can pinpoint the location.
All the best, Ashok

On 8/8/2012 5:49 PM, Martin Thomson wrote:
> On 8 August 2012 15:37, Ashok Malhotra<[email-masked]>  wrote:

---

From: David Singer <[email-masked]>
Date: Thu, 09 Aug 2012 16:10:02 -0700

> behavior I presume, can pinpoint the location.

well, all sorts of heuristics can be used.  Are the locations plausible?  If the algorithm is to add random noise to each location, you'll get cases where the user appeared to have moved absurdly fast between two locations.  If the locations are associated with photos, what's the closest plausible actual location for the image?  

In general, the more data points (successive locations) supplied, the more data you are supplying, and the easier it is to sift noise from signal.  This is generally true, alas, and if you add in real-world knowledge (e.g. that it's unusual to be in the middle of an ornamental lake, or move at 200 mph in a city), further noise removal is possible.

I have the same intuition on other data as well; fuzzing that will be amenable to de-noising techniques…e.g. fuzzing the contents of a shopping cart (doing 'harmless' like-substitutions for some items) will probably reveal the ones that you have substituted as being 'less likely', and so on, and easier to detect if have previous fuzzed carts from the same person.  and so on.

>> conclusion most likely applies to other aspects of data minimization.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Robin Wilton <[email-masked]>
Date: Fri, 10 Aug 2012 09:58:07 +0100

Hmm - but unacceptable to whom? There are definitely times when I am perfectly comfortable self-asserting a false location. In fact, I'd go further and say that in general, I have no use for location-based services…
To be honest, I think service providers often get the location-based services argument the wrong way round; what's useful to me, as a user, is the ability to go online and locate something (say, a restaurant) regardless of *my* current location. (So, for instance, I can find out where my hotel in San Diego for next week is, even though I'm in the UK). I am less interested in passively disclosing my location so that I can be told what is in my immediate vicinity.

I take Martin's point about location fuzzing: the fact that I state a false location on Twitter won't fool someone who carefully monitors the times at which I tweet… they will quickly figure out that either I often tweet at 3 in the morning, or I'm not where I claim to be. But I think we should be careful about how we frame the problem and the potential goals. It is almost certainly not realistic to aim make it impossible for anyone to de-identify any data about me: in privacy terms, it's more viable to aim to raise the threshold of data needed for *some* third parties to infringe my privacy. The EU Article 29 Working Group implies this with its findings on what constitutes personal data. Their view is that some items of data (such as an IP address) are sometimes personally identifiable and sometimes not, depending on whether a third party is in a position to link them to other data items. Thus, as far as my ISP is concerned, my IP address is easy to link with a subscriber address… whereas to most other third parties, it is a relatively fuzzy identifier.

Bottom line: I'm not sure if the required action here is further research work or changes to the draft, but I do think the problem would benefit from being explored and defined more fully…

HTH,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Rhys Smith <[email-masked]>
Date: Fri, 10 Aug 2012 10:43:17 +0100

My 2c - as I said in my last message, I think the most the draft should do is mention that data perturbation is an option, and give links to further material. When we discuss anonymisation we don't go into detail about the various methods that can be used to achieve it. We shouldn't with this either. The draft is not about defining *how* to achieve privacy, but to discuss what privacy is, give an overview of ways of protecting it (but not in any detail), and to provide guidance on how to talk about privacy.

There are various methods available to achieve the effect of "fuzzing" data, each of them fairly dependent on the domain in use. E.g. algorithms to achieve it across large data sets to achieve privacy of single tuples are completely different to those that achieve geographic privacy for a user for geo-located data which are completely different to those attempting to achieve privacy by putting false traffic into something like an anonymisation network (e.g. Tor) to hinder traffic analysis, etc etc etc. So a full discussion about it would probably be a full journal paper in its own right. In fact, a full discussion about data perturbation per domain is a journal paper in its own right, or indeed, a whole class - cf. http://theory.stanford.edu/~nmishra/cs369-2004.html for statistical databases, the geopriv discussions for geographic information, etc.

I'm very wary of introducing major new topics into the draft, given past feedback has been that it's already too complex. The privacy considerations draft needs to kept as short and snappy as possible if it's going to have any chance of the IETF community reading it, understanding it, and using it.

So my opinion, just to restate - is that the draft should mention that data perturbation is an option, and give links to further material. Couple of paras at most.

R.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's education and research network

---

From: Robin Wilton <[email-masked]>
Date: Fri, 10 Aug 2012 11:49:31 +0100

That works for me… it's compatible with further discussion that doesn't result in changes to the draft's scope of contents.

R

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Fri, 10 Aug 2012 12:59:37 +0000

I would use this discussion to provide some 'small' edits to the document.

I would offer that to  explain that  the correlation of separate items of information will be used by  those who wish to circumvent the privacy desires of a user fits within the document.
This is then justification for using only the minimal amount of data needed for a specific  function or protocol to help minimise the risk. Correlation also justifies the  assertion of false information and  therefore designers need to be aware  of the existence of such false information.

Bryan

PS

I agree this may also need further research. Perhaps there  is need  for  personal 'misinformation' services. Just as  there are products to switch your TV and or lights on to infer you are at home to deter burglar's? I would imagine that  the value would come from intelligent rather than random misinformation? Only the justice authorities would need to know which were accurate and which were misinformation.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin Wilton
Sent: 10 August 2012 09:58
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-privacy] New Version Notification for draft-iab-privacy-considerations-03.txt

Hmm - but unacceptable to whom? There are definitely times when I am perfectly comfortable self-asserting a false location. In fact, I'd go further and say that in general, I have no use for location-based services...
To be honest, I think service providers often get the location-based services argument the wrong way round; what's useful to me, as a user, is the ability to go online and locate something (say, a restaurant) regardless of *my* current location. (So, for instance, I can find out where my hotel in San Diego for next week is, even though I'm in the UK). I am less interested in passively disclosing my location so that I can be told what is in my immediate vicinity.

I take Martin's point about location fuzzing: the fact that I state a false location on Twitter won't fool someone who carefully monitors the times at which I tweet... they will quickly figure out that either I often tweet at 3 in the morning, or I'm not where I claim to be. But I think we should be careful about how we frame the problem and the potential goals. It is almost certainly not realistic to aim make it impossible for anyone to de-identify any data about me: in privacy terms, it's more viable to aim to raise the threshold of data needed for *some* third parties to infringe my privacy. The EU Article 29 Working Group implies this with its findings on what constitutes personal data. Their view is that some items of data (such as an IP address) are sometimes personally identifiable and sometimes not, depending on whether a third party is in a position to link them to other data items. Thus, as far as my ISP is concerned, my IP address is easy to link with a subscriber address... whereas to most other third parties, it is a relatively fuzzy identifier.

Bottom line: I'm not sure if the required action here is further research work or changes to the draft, but I do think the problem would benefit from being explored and defined more fully...

HTH,
Robin

Robin Wilton

email: [email-masked]<mailto:[email-masked]>
Phone: +44 705 005 2931
Twitter: @futureidentity