--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
> <Martin.Thomson@commscope.com> 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
>
...
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
