Re: Location fuzzing

Doug, some methods were previously discussed on the list (see below).   
I'll check on the current status of these approaches....  John

On Nov 8, 2009, at 5:52 PM, Thomson, Martin wrote:

> There is an alternative method in:
>
> http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-03#section-4.4
>
> This discusses a method that could be used to prevent some of the  
> basic attacks on a “fuzzed” location.  It’s basically the same  
> algorithm, but it prevents accidental reveals of location through  
> multiple requests by maintaining a fixed offset at any one  
> location.  There’s a method described for hiding the fixed offset.
>
> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org 
> ] On Behalf Of Richard Barnes
> Sent: Sunday, 8 November 2009 9:37 PM
> To: public-geolocation@w3.org
> Cc: Doug Turner
> Subject: Location fuzzing
>
> Hey all,
>
> I got a question from Doug a little while ago about location  
> fuzzing, and thought the whole group might be interested in the  
> response.
>
> The current approach we're taking in GEOPRIV is described in this  
> document:
> <http://tools.ietf.org/html/draft-ietf-geopriv-policy-21>
> Geodetic fuzzing is in Section 6.5.2 ...
> <http://tools.ietf.org/html/draft-ietf-geopriv- 
> policy-21#section-6.5.2>
> ... and fuzzing of civic addresses is in Section 6.5.1:
> <http://tools.ietf.org/html/draft-ietf-geopriv- 
> policy-21#section-6.5.1>
>
> These techniques start from a slightly different place than the W3C  
> Geolocation API:
> -- Geodetic location is given by a shape (e.g., point, circle,  
> ellipse, polygon, arc-band), rather than a single point with a radius
> -- Civic location is given by an RFC 5139 address structure
>
> The geodetic fuzzing algorithm take two inputs:
> 1. A shape representing the user's estimated location, and
> 2. A "fuzzing radius" F in meters
> From these, you generate the fuzzed result in the following way:   
> First, you choose a random "baseline circle" that  (1) has a radius  
> at least F, and (2) covers the input shape (the user's location).   
> The shape you return is then any shape that contains the baseline  
> circle.  If there are multiple requests for the user's location,  
> then the return shape may be varied (as long as it still contains  
> the baseline circle).  If the user moves outside the baseline  
> circle, then you choose a new random baseline circle.   Example here:
> <http://geopriv.dreamhosters.com/fuzz.pdf>
>
> This algorithm guarantees that all an observer gets by averaging/ 
> intersecting is the baseline circle, which has the minimum required  
> uncertainty.  If the target is moving, then you can add enough  
> jitter to obscure this to some extent, and you don't run into  
> boundary issues (like you do with "rounding" or "fixed grid"  
> approaches).
>
> This kind of maps on the the "point+uncertainty" construct that's in  
> the current Geolocation API spec, if you make the mental equivalence  
> "point+uncertainty = circle".  In this analogy, the center of the  
> baseline circle is a random fixed offset from the real location, and  
> the returned points will cluster roughly around the baseline circle  
> (with uncertainty values big enough to cover the baseline circle.
>
> The civic fuzzing works by restricting the set of civic address  
> elements that are returned to a predefined set.  The draft defines  
> six levels (full, building, city, region, country, none); for  
> example, the region level includes the "country" element as well as  
> the "A1", "A2", and "A3" hierarchical elements.
>
> Hope this helps,
> --Richard
>
>
>
>
>
>

Received on Wednesday, 24 March 2010 17:36:51 UTC