> Hi Alissa, Hi Martin,
>
> 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.
This is just the algorithm that I wrote up. A grid mechanism would be OK, it merely has a different set of problems - the most significant being the border-crossing problem.
> > .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.
There are inherent properties of the algorithms that cause leakage - see the weakness below. Ideally, an algorithm doesn't have such weaknesses.
> 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.
I don't think that's true. I can have two reported locations that correspond to the same known location. None of the algorithms proposed thus far do this, but nothing prevent this.
>
> >
> > .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?
It was supposed to be a "for example" reference. It can't be normative.
> >
> > 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.
Unfortunately, if the next location has lower uncertainty, you reveal it at that point. So this doesn't work out very well.
> > 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?
Certainly.
"This produces an offset that is evenly distributed over a circular area. This reduces the chance that an adversary can choose any particular point with a higher probability of being the known location."
>
> > 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.
Correct. That means that your adversary learns the input very easily. The input is not a secret, as stated below.
> >
> > 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
