On 2011-05-10 at 12:33:39, Hannes Tschofenig wrote:
> > Each algorithm MUST be assigned a label. This label is used to
> identify the algorithm. Algorithm labels are added to the location
> obscuring algorithm registry (see Section x.x).
> >
> I would drop this.
Sure.
> > The algorithm MUST accept known locations with uncertainty and
> produce reported locations with uncertainty that encloses the known
> location at that time. That is, the reported location is no less
> correct than the known location.
>
> See my other mail. I would at maximum go as far as saying "SHOULD"
> here.
In your other mail you say two different things on this topic:
> I am OK with the statement that the reported location must enclose the known location.
Keeping in mind that the only way to provide any level of assurance that the reported location is "accurate" is to incorporate the uncertainty in the input.
I can handle a "SHOULD" here, but we then need to include some sort of guidance on what that really means with respect to accuracy then.
> > Any obscuring algorithm MUST accept a single input parameter of a
> distance in meters. Any other tuning parameters for the algorithm
> MUST be fixed in the definition of the algorithm.
> >
> I am not sure why this is a useful requirement as well. I believe what
> you really want to express with this requirement is that the algorithm
> has to be simple to use for the end user. When we came up with the
> idea that the user would be presenting only a single value (in the
> form of distance in meters) we thought that this would be simple enough.
> However, none of us is a user interface expert. Hence, I believe it is
> not useful to put artificial constraints on the algorithm. Imagine
> that someone comes up with a super great user interface but
> unfortunately that algorithm would require more parameters then this
> should still be allowed.
Allowing for other types of parameters will make the construction of the policy more difficult, but I'm not opposed to doing that. In that respect, it's probably best to each algorithm explicitly define its parameters rather than having discrete labels. It's harder to build and implement, but we could do that.
> > Continuous movement assumption:
> > An algorithm SHOULD obscure the location of a moving target.
> More specifically, when a target moves, a location recipient should be
> unable to determine the known location of the target at any point in
> time using only the reported locations that are output from the
> algorithm.
>
> While the adversary will be unable to determine the exact information
> about the location of the target it will learn that the target moves
> and in which direction (if we additionally assume that the algorithm
> does not lie).
> Then, with additional information (which is quite likely to be
> available) there is information about which path the target may have
> taken.
It depends on the algorithm as to how much information about movement is revealed. A coarse estimate of direction (and maybe even speed) might be derived, but that might not directly translate to revealing a path.
With enough additional information, it would be unnecessary to attack the algorithm. Ultimately, the question is how much information we are allowing an adversary to possess before the algorithm is useless. So you'll have to be more specific.
> > Frequent destination assumption:
> > An algorithm SHOULD obscure the details of a frequently visited
> location or path. For a destination that is regularly visited, the
> algorithm cannot provide the precise location of the frequented
> location.
> >
> > Any description SHOULD indicate whether the algorithm prevents a
> recipient from identifying whether different reported locations
> correspond to the same known location, and under what circumstances.
> This would permit a recipient to learn that the same location is being
> visited, even if the identity of that location is obscured.
> >
> I am not sure whether I fully understand the purpose of these two
> requirements.
>
> If a grid is large enough then there will be no path visible. In the
> other case it will be. Since the grid is a configurable parameter
> every algorithm will fail to fulfill this requirement.
>
> I would exclude these further requirements below from the current
> discussion. We should only work on these once we get a base algorithm
> finished. I have my doubt that the industry is asking us to work on
> these given the deployment status of the location obfuscation today.
> From your description it seems that they fall under the same category
> as all other requirements. I disagree with that. This is also a more
> advanced requirement that should be labelled as a MAY, if at all
> listed.
These are (an attempt at describing) precisely the problems that Jorge wanted included. That is, I don't want an adversary to learn where I live based on my obscured location that he receives every evening.
The second part is a corollary to this. That is, I want an adversary to have some uncertainty about whether I'm even going to the same place each evening. That is, the reported location he got yesterday and the one he gets today should not give the adversary any (significant) indication that they apply to the same known location.
Obviously, the simple algorithm we originally devised (all variants) failed this test. If you continually returned to the same known location, the reported location was obscured differently each time. That would allow an adversary to make a simple assumption (that these are really the same place) and recover that location with low uncertainty by intersecting all the reported locations.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
