your proposed algorithm assumes that there is a trigger point that is stored with each Target & location recipient.
Jorge's algorithm did not make use of the same state requirement and instead had a grid pre-defined, as you known.
You don't seem to like the grid-based approach. Any specific reason for not using the grid-based mechanism?
We would then have an algorithm that is similar to what is currently in the document.
> .h3 Basic Assumptions
>
> A location recipient in possession of one or more reported locations
> SHOULD have no more information about any known location without
> making any assumptions about the nature of the known location.
> That
> is, an algorithm SHOULD NOT reveal any more information than its
> inputs specify to an adversary that makes no assumptions.
I am not sure how much these two paragraphs add. Everything succeeds and fails with the assumptions.
For example, if a Target moves and the reported location changes (which it certainly has to at a certain point in time in any practical setup).
This already tells the location recipient that the target is not stationary.
>
> .h2 Simple Obscuring Algorithm
>
> This algorithm takes a single distance in meters. It produces a
> reported location with circular uncertainty area of that radius or
> greater.
>
> As each known location is generated or received at the location
> server:
>
> 1. Determine the distance between the centroid of the known location
> to the trigger point. If there is no trigger point saved for this
> target and location recipient, assume this distance is infinite.
> If this distance is less than the input, do not report the location
> and end the algorithm.
>
Here it needs to be ensured that in the stationary case the distance is always aways greater than the input since otherwise the location recipient does not get location reported anymore.
> 2. Convert the known location to a circle
> [I-D.thomson-geopriv-uncertainty].
Is this a normative dependency?
>
> 3. Set the trigger point to the centroid of the known location.
>
I believe it would be more clear to re-set the trigger point in step 4 in case you end the algorithm since otherwise the re-setting it to the centroid of the known location makes no sense given that you re-set it again in a latter step.
Something like:
4. If the known location has uncertainty equal to or greater than the
input, report the known location, reset the trigger point to the centroid of the known location, and end the algorithm.
> 4. If the known location has uncertainty equal to or greater than the
> input, report the known location and end the algorithm.
>
> 5. Select two uniformly distributed random numbers [RFC4086] between 0
> and 1.
>
> 6. Set the centroid of the reported location by moving the centroid of
> the known location randomly, using the two random numbers:
>
> - The distance is determined by taking the square root of the first
> number and multiplying it by the difference between the input and
> the uncertainty (radius) of the known location.
>
> - The angle (or heading) is determined by multiplying the second
> number by 360 degrees (or 2*pi radians).
>
Could you explain your motivation for computing the distance and the angle in this specific fashion?
> 7. Set the uncertainty radius of the reported location to the input.
If you do this wouldn't the system have location reports with a radius that equals the input value.
For example, imagine that you have a system that uses GPS then the known location would have a fairly small uncertainty radius (almost always).
Hence, almost all reported locations would have an uncertainty radius that corresponds to the input of the rule maker.
>
> 8. Move the trigger point randomly by half the input using the process
> used in Step 6 with a new pair of random numbers. Save the trigger
> point for this target and location recipient.
>
> 9. Report the randomized location and end the algorithm.
>
Ciao
Hannes
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
