Subject: [Geopriv] I-D Action:draft-ietf-geopriv-policy-16.txt

From: [email-masked]
Date: Sun, 15 Jun 2008 11:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title           : Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-geopriv-policy-16.txt
	Pages           : 35
	Date            : 2008-06-15

This document defines an authorization policy language for
controlling access to location information.  It extends the Common
Policy authorization framework to provide location-specific access
control.  More specifically, this document defines condition elements
specific to location information in order to restrict access based on
the current location of the Target.  Furthermore, it offers location-
specific transformation elements to reduce the granularity of the
returned location information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-16.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jun 2008 21:20:02 +0300

This version of the document aims to address the previously discussed 
"location fuzzing" aspect (see 
http://www.ietf.org/mail-archive/web/geopriv/current/msg05669.html).

Richard and I used some face-to-face time during the interim meeting to 
phrase some text based on the goal Henning stated in his initial mail 
(see link above).

Let us know whether this document addresses the raised issue.

Ciao
Hannes

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 15 Jun 2008 19:08:51 -0500

I think that this will work.  It satisfies all of the stated goals and the other one, which is that it is easy to explain.

There is only one little addition that I'd like to suggest:

   ...; while the returned shape may change from one query to another, the chosen circle remains constant.  

Changes to:

   ...; while the returned shape may change from one query to another, as long as the Target does not move, the chosen circle remains constant.

I think that we need to acknowledge that things move.  I don't think that there needs to be anything more than that.  If F is 1000m, then a movement of 2m shouldn't cause a new circle to be chosen, but we can leave it up to implementations to decide when to pick a new circle.  If you disagree, then we could make it:

   ...; while the returned shape may change from one query to another, as long as the Target does not move outside the circle, the chosen circle remains constant.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Monday, 16 June 2008 4:20 AM
> To: [email-masked]
> Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-policy-16.txt
> 
> > 	Title           : Geolocation Policy: A Document Format for
> Expressing Privacy Preferences for Location Information

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Sun, 15 Jun 2008 19:48:24 -0500

Martin,

I agree.  I would propose a small modification of your text:

"
...; while the returned shape may change from one query to another, the 
chosen circle remains constant as long as the Target's location (whether 
point or region) remains within circle.
"

And add a clarification to the end:

"
When the Target's location moves outside the chosen circle, the LS MUST 
choose a new random center point.
"

This makes the whole paragraph as follows:

"
For each rule in the policy specification containing a <provide-geo> 
element, the LS chooses a circle with a radius F given by the 'radius' 
attribute of the <provide-geo> element.  The center of the circle is 
chosen randomly, under the constraint that the circle MUST contain the 
Target's location, which may be a point or another location shape.  In 
response to queries matching this rule, the LS MUST return a shape 
containing this circle; while the returned shape may change from one 
query to another, the chosen circle remains constant as long as the 
Target's location (whether a point or a region) remains completely 
within the circle.  An LS may, for example, store the location of the 
center or compute it based on a hash function that includes the target's 
identity.  When the Target's location moves outside the chosen circle, 
the LS MUST choose a new random center point.
"

Thanks for pointing out that this case needs to be covered,
--Richard

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 16 Jun 2008 14:23:47 -0400

<comments below>

>choose a new random center point.
You seem to be suggesting that a new returned shape is selected 
precisely when the Target's location leaves the previously returned 
shape. I believe this has undesirable privacy properties.

Let's say the returned shape for the first query is rectangle A below 
(I'd use a circle but my attempts at ASCII-Art circles look horrible):

+-----+
|     |
|     |
|  A  |
|     |
|     |
+-----+

Now let's say that a watcher makes a second and a third query and gets 
rectangle A again. However, on the fourth query he gets rectangle B:

+-----+
|     |
|  A  |
|     |
|  +--+--+
|  |  |  |
+--+--+  |
   |     |
   |  B  |
   |     |
   +-----+

Assuming that the time between queries is relatively short, the watcher 
can infer the following: (1) The target is not in the intersection of A 
and B [because if he was, the returned region would not have changed]; 
and (2) The target is likely near the border of rectangle A because he 
probably isn't moving fast enough to have reached the far corner of 
rectangle B. Therefore, the watcher can infer that the target is most 
likely in the following region C:

+-----+
|     |
|  A  |
|     |
|     +-+
|     | |
+--+--+ |
   |  C |
   +----+

(Which represents a much lower uncertainty than just saying the target 
is in rectangle B).

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Jun 2008 15:10:10 -0500

Matt,

How would you propose resolving this?

I suspect that there may not be a solution to this problem in terms of 
choosing the returned shape, given the condition that the returned area 
MUST contain the target's location.  At the very least, the text as it 
stands maintains whatever uncertainty is *input* to the LS -- the target 
can enforce a minimum uncertainty level by PUBLISHing a fuzzed-up 
location in the first place.

--Richard

Matt Lepinski wrote:
>> ...; while the returned shape may change from one query to another, 
>> the chosen circle remains constant as long as the Target's location 
>> (whether point or region) remains within circle.
>> "
>>
>> When the Target's location moves outside the chosen circle, the LS 
>> MUST choose a new random center point.
>> "
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jun 2008 23:15:26 +0300

We actually described this issue in the draft.

See Section 12 of 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-16.txt.

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 16 Jun 2008 16:32:06 -0400

Richard,

I agree that there may not be a perfect answer here. Given the 
cautionary text currently in the security considerations section, I'm 
content with the text Martin proposed,

However, I don't like mandating that the circle MUST NOT change as long 
as the target stays within the circle. In particular, I don't think we 
should rule out implementations that, upon receiving a new published 
location, probabilistically determines whether to return the previously 
returned circle [region] or to randomly select a new circle. (I haven't 
worked out the details, but I can imagine such a probabilistic system 
having nice privacy properties).

- Matt L.

Richard Barnes wrote:

> choosing the returned shape, given the condition that the returned 
> area MUST contain the target's location.  At the very least, the text 
> as it stands maintains whatever uncertainty is *input* to the LS -- 
> the target can enforce a minimum uncertainty level by PUBLISHing a 
> fuzzed-up location in the first place.
>
> --Richard
>
>
>
> Matt Lepinski wrote:
>
>> <comments below>
>>
>> Richard Barnes wrote:
>>
>> Now let's say that a watcher makes a second and a third query and 
>> gets rectangle A again. However, on the fourth query he gets 
>> rectangle B:
>>
>> +-----+
>> |     |
>> |  A  |
>> |     |
>> |  +--+--+
>> |  |  |  |
>> +--+--+  |
>>   |     |
>>   |  B  |
>>   |     |
>>   +-----+
>>
>>
>> Assuming that the time between queries is relatively short, the 
>> watcher can infer the following: (1) The target is not in the 
>> intersection of A and B [because if he was, the returned region would 
>> not have changed]; and (2) The target is likely near the border of 
>> rectangle A because he probably isn't moving fast enough to have 
>> reached the far corner of rectangle B. Therefore, the watcher can 
>> infer that the target is most likely in the following region C:
>>
>> +-----+
>> |     |
>> |  A  |
>> |     |
>> |     +-+
>> |     | |
>> +--+--+ |
>>   |  C |
>>   +----+
>>  
>>  
>>
>> (Which represents a much lower uncertainty than just saying the 
>> target is in rectangle B).
>>
>>
>>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Jun 2008 16:14:04 -0500

Matt,

How about the following modification:

"
...; while the returned shape may change from one
query to another, the chosen circle remains constant as long as the
Target's location (whether a point or a region) remains unchanged. ... 
If the Target's location moves within the chosen circle, the LS MAY 
choose a new random center point, but when the Target's location moves 
outside the chosen circle, the LS MUST choose a new random center point.
"

Making the whole paragraph as follows:

"
For each rule in the policy specification containing a <provide-geo>
element, the LS chooses a circle with a radius F given by the 'radius'
attribute of the <provide-geo> element.  The center of the circle is
chosen randomly, under the constraint that the circle MUST contain the
Target's location, which may be a point or another location shape.  In
response to queries matching this rule, the LS MUST return a shape
containing this circle; while the returned shape may change from one
query to another, the chosen circle remains constant as long as the
Target's location (whether a point or a region) remains completely
within the circle.  An LS may, for example, store the location of the
center or compute it based on a hash function that includes the target's
identity.  If the Target's location moves within the chosen circle, the 
LS MAY choose a new random center point, but when the Target's location 
moves outside the chosen circle, the LS MUST choose a new random center 
point.
"

--Richard

Matt Lepinski wrote:
>   ...; while the returned shape may change from one query to another, as 
> long as the Target does not move, the chosen circle remains constant.
>

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 17 Jun 2008 13:41:50 -0400

Richard:

That sounds reasonable.

Also, given that the radius is an integer, it seems that this section 
(6.5.2) is the right place to attach a unit to the radius (I assume the 
semantics we want is 'meters').

- Matt Lepinski

Richard Barnes wrote:

> identity.  If the Target's location moves within the chosen circle, 
> the LS MAY choose a new random center point, but when the Target's 
> location moves outside the chosen circle, the LS MUST choose a new 
> random center point.
> "
>
> --Richard
>
>
>
>
> Matt Lepinski wrote:
>
>> Richard,
>>
>> as long as the Target does not move, the chosen circle remains constant.
>>
>> However, I don't like mandating that the circle MUST NOT change as 
>> long as the target stays within the circle. In particular, I don't 
>> think we should rule out implementations that, upon receiving a new 
>> published location, probabilistically determines whether to return 
>> the previously returned circle [region] or to randomly select a new 
>> circle. (I haven't worked out the details, but I can imagine such a 
>> probabilistic system having nice privacy properties).
>>
>> - Matt L.
>>
>> Richard Barnes wrote:
>>
>>> Matt,
>>>
>>> I suspect that there may not be a solution to this problem in terms 
>>> of choosing the returned shape, given the condition that the 
>>> returned area MUST contain the target's location.  At the very 
>>> least, the text as it stands maintains whatever uncertainty is 
>>> *input* to the LS -- the target can enforce a minimum uncertainty 
>>> level by PUBLISHing a fuzzed-up location in the first place.
>>>
>>> --Richard
>>>
>>>
>>>
>>> Matt Lepinski wrote:
>>>
>>>> <comments below>
>>>>
>>>> Richard Barnes wrote:
>>>>
>>>>> ...; while the returned shape may change from one query to 
>>>>> another, the chosen circle remains constant as long as the 
>>>>> Target's location (whether point or region) remains within circle.
>>>>> "
>>>>>
>>>> Let's say the returned shape for the first query is rectangle A 
>>>> below (I'd use a circle but my attempts at ASCII-Art circles look 
>>>> horrible):
>>>>
>>>> +-----+
>>>> |     |
>>>> |     |
>>>> |  A  |
>>>> |     |
>>>> |     |
>>>> +-----+
>>>>
>>>> intersection of A and B [because if he was, the returned region 
>>>> would not have changed]; and (2) The target is likely near the 
>>>> border of rectangle A because he probably isn't moving fast enough 
>>>> to have reached the far corner of rectangle B. Therefore, the 
>>>> watcher can infer that the target is most likely in the following 
>>>> region C:
>>>>
>>>> +-----+
>>>> |     |
>>>> |  A  |
>>>> |     |
>>>> |     +-+
>>>> |     | |
>>>> +--+--+ |
>>>>   |  C |
>>>>   +----+
>>>>  
>>>>  
>>>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Jun 2008 13:54:18 -0400

> semantics we want is 'meters').

Already covered earlier in 6.5.2.:
"The value of the 'radius' attribute expresses the radius in meters."

--RLB

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 17 Jun 2008 14:02:17 -0400

Oh yeah, sorry for missing that in -16

- Matt

Richard Barnes wrote:

>> (6.5.2) is the right place to attach a unit to the radius (I assume 
>> the semantics we want is 'meters').
>
>
>>> Target's location (whether a point or a region) remains unchanged. 
>>> ... If the Target's location moves within the chosen circle, the LS 
>>> MAY choose a new random center point, but when the Target's location 
>>> moves outside the chosen circle, the LS MUST choose a new random 
>>> center point.
>>> "
>>>
>>>> cautionary text currently in the security considerations section, 
>>>> I'm content with the text Martin proposed,
>>>>
>>>> another, as long as the Target does not move, the chosen circle 
>>>> remains constant.
>>>>
>>>>> I suspect that there may not be a solution to this problem in 
>>>>> terms of choosing the returned shape, given the condition that the 
>>>>>>> When the Target's location moves outside the chosen circle, the 
>>>>>>> LS MUST choose a new random center point.
>>>>>>> "
>>>>>>>
>>>>>> precisely when the Target's location leaves the previously 
>>>>>> returned shape. I believe this has undesirable privacy properties.
>>>>>>
>>>>>> border of rectangle A because he probably isn't moving fast 
>>>>>> enough to have reached the far corner of rectangle B. Therefore, 
>>>>>> the watcher can infer that the target is most likely in the 
>>>>>> following region C:
>>>>>>
>>>>>> +-----+
>>>>>> |     |
>>>>>> |  A  |
>>>>>> |     |
>>>>>> |     +-+
>>>>>> |     | |
>>>>>> +--+--+ |
>>>>>>   |  C |
>>>>>>   +----+
>>>>>>  
>>>>>>  
>>>>>>