Hi Jorge,
I think that this proposal falls short of what we need. I have one major concern, plus a few relatively minor issues.
Major issues
I see no mention of how to address continuous movement in this algorithm. It would appear that continuous movement could reveal the location of the target with an extremely high degree of accuracy - the same problem that we have had with all previous algorithms. This just has the added virtue of being more complicated (though--to its credit--not significantly).
Minor issues
In general, the algorithm is given with too little explanation about what its goals are and how it seeks to achieve those goals. More specifically:
Grid selection is left to the example, which is not appropriate. Obviously, it doesn't matter as long as an implementation uses the same method each time, but you could say that.
The method used in the example for selecting a grid doesn't offer any guidance on when to switch grids, except to say that it shouldn't be done often. That implies to me that there is a need for hysteresis in the algorithm, which is not ideal.
How does one choose for the 'or' in C2, C4, C5 and C7? I consider this to be almost as important as above. [Please, if we go with this, include a picture of C1-C8. It helps greatly to be able to map this out.]
More explanation on why sqrt(3)/6 [or 1/(2*sqrt(3))] is selected would be nice. On first analysis, 1/2*sqrt(2) [1/sqrt(8)] seems a better fit, since this gives equal areas within the cell. If I consider that the corner regions are joined in groups of four and the "OR" regions are joined in groups of two. 'p' and 'q' were selected so that C2, C4, C5 and C7 have double the area given to the corner regions. That seems logical, but I really don't know what that really buys me other than an elegant tessellation pattern [1]. Nor should I have had to work so hard to reach that conclusion.
This last is a minor fault that I forgot about in my own proposal: Any grid origin is likely at zero longitude. The point that is 180 degrees east or west of that is going to be special. A naïve implementation will reveal - by discontinuity - when someone is crossing the 180th meridian. The problem is not that the algorithm fails to produce a result, it's that the result is bad. This is relatively easy to fix, but it does need an explicit mention so that it doesn't get forgotten.
--Martin
[1] Would a tiler have to use different numbers to ensure that they have enough space for grouting? I think it likely...
On 2010-10-28 at 06:48:03, Jorge Cuellar wrote:
> Hi all,
>
> last week Hannes and I met in Munich to discuss the Geolocation
> Policy draft. We decided to write a text to address the raised
> concerns regarding the location obfuscation algorithm. The
> problem is both when movement occurs and an update of the
> obscured location is necessary, and also when repeatedly the
> same location is visited and different obscured locations are
> provided.
>
> The new draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-22.txt
>
> The idea of the proposed algorithm is that only a fixed set
> of "cells" are used and the points in those cells are
> indistinguishable. Only one variant of a general type of
> algorithms is presented here, The details of the construction of
> the grids and the calculations are spelled out for the so called
> Mercator "secant projection",
> (http://en.wikipedia.org/wiki/Scale_%28map%29#Secant.2C_or_modified.2C_
> projections).
>
> You might also find the following slide sets interesting:
>
> http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-
> policy/Literature/Privacy%20of%20Location%20Information.ppt
>
> http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-
> policy/Literature/Algo%20for%20Location%20Information-Choices.ppt
>
> Ciao,
> Jorge
> _______________________________________________
> 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
