Subject: [Geopriv] geopriv-policy requirements

From: "Richard L. Barnes" <[email-masked]>
Date: Sat, 27 Nov 2010 14:28:46 -0500

I'm concerned that we're trying to solve every possible fuzzing problem with geopriv-policy.  Three that I remember off the top of my head:
A. Stationary targets
B. Moving targets
C. Patterns of motion (repeated visits averaged over time)

As earlier versions of geopriv-policy show, "class A" algorithms that only address the first can be pretty simple.  As you try to address the other two, you end up with something like the most recent version of -policy or draft-thomson-geopriv-location-obscuring.  

I would like to suggest that the base policy document doesn't need to address all of these problems. Advanced "class B/C" algorithms are clearly an active area for research and development, and the algorithm that the server applies is not a requirement for interoperability.  The policy document format only describes the user's preferences; the server can reject policies or warn the user, but that's related to the policy *protocol* and the server's local policies.

A more concrete proposal:
1. Roll back the fuzzing algorithm to a simple "class A" algorithm
2. Document how this algorithm can fail in "class B/C" situations
3. Provide informative references to more advanced strategies, such as draft-thomson-geopriv-location-obscuring or a new draft with Jorge's algorithm.

Thoughts?

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 29 Nov 2010 07:23:24 +0800

This is the only sensible approach at this stage.  I suspect that there will be myriad "attacks" on any solution that is put forward and the only option is to spend a lot time in analysis.

The basic stationary scheme seems reasonable.  Add a random offset, increase uncertainty to obscuring distance.

I'd like to at least provide some limited protection for movement.  By suppressing reports where the known location has moved less than the obscuring distance (or something like that) a lot is gained.  This might reveal average speed with increasing accuracy, but it prevents simple interpolation.

This does nothing for C, but that's the point where things start to get complicated anyhow.

--Martin

On 2010-11-28 at 06:28:46, Richard L. Barnes wrote:
> I'm concerned that we're trying to solve every possible fuzzing problem
> with geopriv-policy.  Three that I remember off the top of my head:
> A. Stationary targets
> B. Moving targets
> As earlier versions of geopriv-policy show, "class A" algorithms that
> only address the first can be pretty simple.  As you try to address the
> other two, you end up with something like the most recent version of -
> policy or draft-thomson-geopriv-location-obscuring.
> 
> I would like to suggest that the base policy document doesn't need to
> address all of these problems. Advanced "class B/C" algorithms are
> clearly an active area for research and development, and the algorithm
> that the server applies is not a requirement for interoperability.  The
> policy document format only describes the user's preferences; the
> server can reject policies or warn the user, but that's related to the
> policy *protocol* and the server's local policies.
> 
> 3. Provide informative references to more advanced strategies, such as
> draft-thomson-geopriv-location-obscuring or a new draft with Jorge's
> algorithm.
> 
> Thoughts?
> 
> --Richard
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv