Subject: [Geopriv] Location obscuring feedback

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 1 Jul 2011 09:20:28 +0800

After a fair bit of neglect on my part, I asked Matt if I could share this email.  It's good feedback.  In it, he describes some of the challenges that face us if we want to do location obscuring properly.

--Martin

On 2011-04-04 at 14:20:15, Matt Duckham wrote:
> Martin,
> 
> Thanks for this. I think the draft does look good, clear and very 
> carefully thought through. Some comments:
> 
> * Constraints to movement: You already anticipated my first 
> criticism-- -that the spaces we navigate through almost always present 
> known constraints to movement, and these may be exploited by a privacy 
> attack. I think in general the principles you adopt might reasonably 
> be translated to network spaces, even thought the geometry embedded in 
> the specific methods would not. For example, one might interpret the 
> distance parameter as, say, total *length* of network in which a 
> person may be located with uniform probability (as opposed to radius 
> of circle in which a person may be located with uniform probability). 
> It would potentially not be too difficult to derive similar procedures 
> to the planar geometric ones suggested in this case. But of course, 
> one would need to in some way link this into information about the 
> network that constrains movement, which does leave some questions 
> unanswered. In short
> * Distance as a proxy for privacy: Distance can be, I think, a poor 
> proxy for level of privacy. In particular, for two of the main threats 
> from lack of privacy---intrusive inferences (about what activities I 
> am engaged in) and physical harm (by someone who can locate 
> me)---distance does not correlate especially well with level of 
> privacy. In dense downtown NY city, for example, the same obfuscation 
> radius presumably affords me much more protection from these threats 
> (and so greater level of privacy), than it does in upstate New York. 
> In some senses this is related to above: rather than heterogeneous 
> constraints to movement across space, the point here is about the 
> heterogeneous density of features/activities I might be engaged in across space.
> * Role of obfuscation methods: I wasn't quite sure what the role of 
> the methods provided for obscuring location were: as examples, or as 
> an exhaustive set of options? The latter strikes me as dangerous--- 
> although the privacy threats have been carefully analyzed in the 
> draft, I think it highly likely that further ingenious methods for 
> subverting these privacy protection methods could be designed, given a 
> little time and motivation. So, I would expect that the standard aims 
> to provide the framework for obscuring location, with perhaps some 
> examples of obfuscation techniques, but leaves the details of how 
> location is obscured to individual systems and service providers. 
> Perhaps this is what you aim for, and I am just not familiar enough with the material.
> * Temporal issues: Also as I have argued in [2], which you mention, I 
> think the static case is *relatively* easy to deal with compared to 
> the dynamic case. The draft does consider carefully temporal issues, 
> but I have the feeling that there are many more (maybe innumerable) 
> ways in which one might attack privacy through integrating data from 
> repeated observations of an individual (e.g., constraints to movement, 
> conservation of momentum, maximum speed, goal directed movement, and 
> even coordinated movement, see below). There is one other paper I 
> wrote that started looking at this 
> http://www.geosensor.net/papers/duckham06.GISCIENCE.pdf. As for the 
> previous point, I doubt it is possible to come up with in advance any 
> single method for obfuscation that can anticipate all these potential 
> attacks. So presumably the standard needs to provide the underlying 
> structure for obfuscated location-based services, but also allow lots 
> of room for new innovation and adapting to unforeseen privacy threats.
> * Invasion of privacy across groups: Human movement is highly 
> coordinated. If I know about the movements of groups of individuals 
> (even if these are obfuscated) that also presumably provides a good 
> basis for attacking privacy. I didn't really see anything in the draft 
> about this issue---what happens if as an attacker I am able to relate 
> locations not just over time but also over multiple individuals?
> 
> Anyway, I don't think there even exist many good answers to some of 
> these questions yet, and no doubt you have already been thinking about 
> some or even all of these issues. In short, I see several important 
> problems---ways in which techniques in the standard could fail or 
> become bypassed through too many simplifying assumptions; but, under 
> the circumstances (of a very complex problem, with no complete 
> solutions yet in existence) I think the draft is nice, and makes a 
> good fist of providing practical steps to protect location privacy, 
> and highlighting many of the fundamental issues (e.g., threats through 
> inferences across multiple times, uniform probability across 
> obfuscation regions, etc.)
> 
> I hope that helps, happy to discuss further any points that come up...
> 
> bw Matt
> 
> 
> On Mon, Mar 21, 2011 at 4:19 PM, Thomson, Martin 
> <[email-masked]> wrote:
> 
> 
> 	Hi Matt,
> 
> 	I'm glad to see that you are aware of our efforts.  I read some of 
> your earlier work on the topic.  It's certainly the best of the
> (limited) reading that I have done.
> 
> 	Your opinion on the direction of the work that we are pursuing with 
> regards to obfuscation would be greatly appreciated.
> 
> 
> http://tools.ietf.org/html/draft-ietf-geopriv-policy-23#section-6.5.2
> 
> http://tools.ietf.org/html/draft-thomson-geopriv-location-obscuring-02
> 
> 	The goal of each of these algorithms is to retain accuracy while 
> reducing precision.
> 
> 	I'm afraid that our earlier efforts were little better than that in 
> Ardagna [1], which I fear is quite poor with respect to solution.
> These latter examples might be a little better.
> 
> 	We willfully violate your principles [2] as a necessity - the 
> algorithms are designed to be run without the sort of knowledge that 
> might be used to attack them.  Thus, we might be making a good 
> solution for ships on the open ocean and desert trekkers without any 
> real hope, but that doesn't mean we're not going to keep trying.
> 
> 	Regards,
> 	Martin
> 
> 	[1] http://portal.acm.org/citation.cfm?id=1770566
> 	[2] http://geosensor.net/papers/duckham10.SPRINGL.pdf
> 
...