Subject: Re: [Geopriv] Let us get Geolocation Policy finished!

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 May 2008 18:50:43 +0300

Hi Martin,

when Richard asked me about the status of the document I checked your 
response to my mail and noticed that it, for some reason, never made it 
to the list.

I was in fact roughly proposing what you called an alternative solution. 
Maybe my description wasn't too clear. Based on that description the 
center of returned circle is not the same as input. Instead, it is 
randomly moved in any direction.

Now, the difference seems to be that the current proposal focuses on 
letting the rule maker pick the radius of the returned informatoin vs. 
your proposal allows the rule maker to pick the distance.

This appears to be pretty similar, isn't it?

Ciao
Hannes

Thomson, Martin wrote:
> Hi Hannes,
>
> I promised you a response to this earlier.  I'll keep it brief.
>
> The changes are good, but I think that the transformation could be
> improved.  My main problem relates to the way that a user is expected to
> understand this transformation.  I'm not sure how to simply and
> succinctly explain the effect that this transformation produces.  It's
> almost as if you need to start with how you would explain to a user and
> see if you can produce that through a rule.
>
> I'll be more specific on the proposed method.  To keep this short, I'll
> use Ro to refer to the radius of the original; Ra refers to the value in
> the transformation rule, that is, the "allowed" radius.
>
> For the first case, where Ro >= Ra, the only problem that I see is that
> the centroid doesn't move.  Despite knowing well that the centroid isn't
> special, it's hard to explain that to a user.  Not seeing any effect on
> the result could cause the user some frustration.
>
> For the second case, where Ro < Ra, the actual variation in distance is
> by min(Ra/2, Ra - Ro).  The halving is a little arbitrary and only comes
> into effect when Ra > 2*Ro.
>
> To propose an alternative, I'd like to concentrate on what I'd tell a
> user: "this is the distance that the location is moved by".  Or, to
> expand: "if you were here, we move your location in a random direction
> by up to this distance".
>
> My proposal is to simplify further and not go for a "target uncertainty"
> at all.  Instead, take the number as a "fudge distance".
>
> 1) Drop altitude, take centroid and radius, make circle.
> 2) Move centroid a random distance up to T (the value specified by the
> user) in a random direction.
> 3) Increate the radius of the new region of uncertainty by T.  This new
> area will be guaranteed to cover the original area, ensuring that the
> confidence doesn't have to be reduced.
>
> It might also make sense to tweak this further by proposing a different
> method for acquiring the random distance to limit the density of the
> distribution near the original centroid.  For instance, T - (rand(1) *
> sqrt(T))^2 would even out the distribution over the resulting area.  But
> that could be left up to implementations.
>
> Cheers,
> Martin
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Hannes Tschofenig
>> Sent: Sunday, 30 March 2008 4:15 AM
>> To: GEOPRIV
>> Subject: [Geopriv] Let us get Geolocation Policy finished!
>>
>> Hi all,
>>
>> we have updated a new version of the Geolocation Policy draft. You can
>> find it here:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-15.txt
>>
>> We believe it addresses the DISCUSSes we received. The draft now
>> contains the following aspects:
>>
>> * Updated Security Consideration section to illustrate a potential
>> privacy vulnerability in a mobile scenario when a Target moves from
>>     
> one
>   
>> transformation region to another one
>>
>> * Reworked "Condition" section whereby the Polygon based condition
>> element is replaced with a Circle based condition element that is
>> simpler to use. Civic Location based condition element remained
>> unchanged.
>>
>> * Reworked the "Transformation" section: Geodetic transformation
>> subsection replaced with a mechanism that returns a circle with a
>> radius
>> that is indicated by the Rule Maker. Civic location based
>> transformation
>> unchanged.
>>
>> As part of these changes we had to clean-up a couple of other minor
>> things as well.
>>
>> Please let us know what you think. Are you OK with the suggested
>> approach?
>>
>> Ciao
>> Hannes
>>
>> PS: Here is the relevant diff:
>> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-
>> ietf-geopriv-policy-12.txt&url2=http://www.ietf.org/internet-
>> drafts/draft-ietf-geopriv-policy-15.txt
>>
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/geopriv
>>     
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>   

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 4 May 2008 18:10:37 -0500

I meant to send the response to the list, my bad.

The similarity isn't by chance - both methods are trying to obscure a
location given a single input, while attempting to be easily understood.

The difference is subtle, true, but the major difference is in whether
the centroid moves at all.  There is a set of cases (where Ro >= Ra) in
your proposal where the centroid doesn't move at all.  This may be
perceived by a user as not having protected their privacy at all.

My proposal is to always move the centroid, by up to a given distance.
That's even simpler than the process you suggested.

Cheers,
Martin

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, 5 May 2008 1:51 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Let us get Geolocation Policy finished!
> 
> Hi Martin,
> 
> > improved.  My main problem relates to the way that a user is
expected
> to
> > use Ro to refer to the radius of the original; Ra refers to the
value
> in
> >> drafts/draft-ietf-geopriv-policy-15.txt
---------------------------------------------------------------------
> ---------------------------
---------------------------------------------------------------------
> ---------------------------
> > [mf2]
> >
> >
>