Subject: [Geopriv] More info about draft-ietf-geopriv-policy-18.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 12 Jan 2009 18:23:41 +0200

Hi Tim, Hi Lisa, 

Richard asked me to be a bit more explicit about the changes we have made 
to the Geolocation Policy document. 

The version that left the working group, if I looked it up correctly, 
was version -08: 

After the IESG comments the document went back to the working group and 
now we are at version -18:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-18.txt

Here is the diff: 
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-geopr
iv-policy-08.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-geopriv
-policy-18.txt
or
http://tinyurl.com/76apny

Many of the IESG comments were made against version -12. 
Here is the diff: 
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-geopr
iv-policy-12.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-geopriv
-policy-18.txt
or
http://tinyurl.com/8p68k5

Anyway, here are the three DISCUSSes in more detail with a more detailed
feedback. In any case, you raised somewhat challenging issues. 

*** Sam's DISCUSS: 
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/719
17/

>
>
> Hi.
>
> I'm trying to think about the mechanisms in section 6 of the geopriv
> document for reducing the granularity of location.  I'm wonder though
> how effective these mechanisms are in cases where in addition to
> getting one-time location information I'm also seeing transitions in
> location information.
>
> As an example if I see a transition from one building to a near by
> building, I may well know much more about the civic location than
> granularity.
>
> Similarly, I'm wondering how much information monitoring transitions
> in geodetic location would help me in discovering where someone is in
> the best case.  I.E. where they are near a discontinuity in the
> rounding.
>
>
> If these concerns are real, I expect to see a discussion in the
> security considerations at the very least.  Depending on how serious
> they are, we may need to work on mechanisms that do better.

Based on discussions on the list with Sam (and other GEOPRIV members) 
we added additional text in the security consideration section of the draft,

namely: 
"
   When the Target is moving then the location transformations reveal
   information when switching from one privacy region to another one.
   For example, when a transformation indicates that civic location is
   provided at a 'building' level of granularity.  Hence, room numbers,
   floors etc. would be hidden.  However, when the Target moves from one
   building to the next one then the movement would still be
   recognizable as the disclosed location information would be reflected
   by the new civic location information indicating the new building.
   With additional knowledge about building entrances and streets it
   would be possible to learn a certain amont of information.  It is
   therefore important to ensure that selected privacy regions are not
   chosen too small when mobility is a concern and that a random number
   to is added to the position of the Target, with an absolute value of
   half the privacy region.  The latter aspect is only applicable for
   geodetic information or when geodetic information is translated to
   civic information by the Location Server.
"

*** Tim's DISCUSS:
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/718
93/

> Interdependencies between the civic and geodetic location information adds
> complexity that should be addressed in the Security Considerations
section.  I
> am specifically worried about situations where differences in precision
> between the two location forms results in information leakage.  I also see
> opportunities for error in the specification of rulesets in the two
location
>formats, but it is unclear whether choosing a single form for rulesets is a
> practical alternative.

The document allows policies to be expressed for civic and for geodetic
location 
information. Location might come from different sources and these sources
might
produce civic or geodetic location information. As such, it is difficult for
us
rule out one of the two. The complexity of providing translating one
location 
format to the other one is largely put to the respective server providing
the 
location based services. Google Maps and Nokia Maps, for example, provide 
such a capability.

It is true that there is likely to be some impression when this
transformation 
takes place. In a more general sense, there are many factors that 
introduce errors into the measurements when obtaining location in the first
place. 
More details can be found in the following document: 
http://tools.ietf.org/id/draft-thomson-geopriv-uncertainty-02.txt

As such, the only guidance to user's creating these authorization policies
is 
to consider these errors and avoid specifying too precise boundaries. For
example, 
it might be a bit unrealistic to specify a totally different privacy policy
when 
being at home vs. outside the building. There is a good chance that the
location 
determination technique (or a potential transcoding afterwards) is not able
to
correctly capture the shape of the home. 

I could add a discussion about this subject to the draft but it is quite
likely
that the user's are not going to read these IETF documents. 

Please let me know how to capture this aspect in a satisfactory way. 

*** Lisa's DISCUSS
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/717
88/

> These mechanisms are too complicated and don't give enough thought to how
> different user-agents are going to interact.  In particular, one should
> imagine setting a privacy policy with one user agent and then trying to
edit
> it with another.
>
> It seems that geo-spatial policy creation requires some kind of user
interface
> that includes a map.  Is that correct?  Are devices without maps then
unable
> to modify or even read policies?
>
> I am not sure that the polygons are as cut-and-dried as they appear.  I'd
like
> to understand better:  - how one knows what is the inside of the polygon,
and
> what is the outside  - ... how that interacts with poles and other
problems
> mapping 2D to a sphere  - how the altitude stuff works at all with client
GUIs
>  - when is altitude known and unknown, independent of knowing a rough
long/lat
> position  - whether you can define a polygon for "Alberta" and one for
> "Saskatchewan" and have any point be in one or the other or completely
outside
> both -- but not *inside* both, and not stuck in-between
>
> When it comes to users viewing policies created in the past, the lack of
> human-readable labels and comments is going to be a real usability
problem.
>
> What happens when a user or user-agent creates a non-sensical
geo-political or
> geo-spatial location?
>
> Are all geo-political elements *really* allowed in conditions?  One
possible
> non-sensical policy would be "Show my location unless I'm in seat 32A". 
> Aren't there any restrictions here?
>
> How are user agents supposed to handle mixed geo-spatial and civic
location
> conditions? How would that be displayed or represented in a list of policy
> elements?
>
> With the dependency on geopriv-revised-civic-lo, this can't complete yet
anyway.

You provided us with a number of tough questions. We modified the document
quite 
substantially to address them. 

Based on your feedback we have modified the conditions and the actions of
the 
policy rules. Conditions now include only 2 D location and the polygon
capability 
was replaced by a circle. 

On the action side we replaced the previously contained 3D gelocation
location 
transformation also with a 2D circle. The consequence is a much simpler
transformation operation that is also much simpler to understand for users. 

As discussed on the GEOPRIV mailing list when your review was posted, we
assume
that a map is available to create these policies. The user interface with
all
these policy mechanisms is certainly challenging and investigations
regarding 
usability will have to continue. This certainly includes consistency checks 
regarding the information provided by the user. 

We did not add comment elements to the Common Policy mechanism as it would
require us to re-visit Common Policy. We might do that when more
implementation 
and deployment feedback is available. 

Regarding the dependency on geopriv-revised-civic-lo: Luckily, this document

is published by now already: http://www.ietf.org/rfc/rfc5139.txt

If these changes are not sufficient I only have one other proposal, 
namely to change the type of document from "Standards Track" to
"Experimental". 

Ciao
Hannes

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

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Jan 2009 11:59:21 -0800

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 20 Jan 2009 22:28:10 +0200

thanks for your response. 

	I've reviewed the -18 version of this document in order to clear my
DISCUSS position. 

	I believe these are the main scope changes since -12: 
	 - Polygon of any type replaced with circle only
	 - Altitude use removed
	I am happy to see these conditions simplified, I'm sure it will lead
to better interoperability between two clients viewing/modifying the same
rules.  
	
[hannes] Good to hear that. 

	Two issues I had in my DISCUSS were not addressed.  The first
unaddressed issue was that civic location conditions can easily be
nonsensical.  I don't see how the policy server would return an appropriate
error if the civic-condition could not be interpreted, or was interpreted in
a way that was not useful as a condition.  
	
[hannes] Got the point. I have to figure out what error handling
capabilities are provided by XCAP as this is one way to upload these
authorization policies. Will come back to you on this issue. 

	The second unaddressed issue was my recommendation to have names,
labels or titles on conditions.  To explain a bit further, this is important
even in the case of only one client accessing a geopriv ruleset: it's to
help the user identify rules and conditions and make sense of them later.  

	To extend an example from the spec:

	   <?xml version="1.0" encoding="UTF-8"?>
	   <ruleset
	     xmlns="urn:ietf:params:xml:ns:common-policy"
	     xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
	     xmlns:gml="http://www.opengis.net/gml"
	     xmlns:gs="http://www.opengis.net/pidflo/1.0">

	     <rule id="BB56A19">
	       <conditions>
	         <gp:location-condition>
	<gp:label>Within one mile of the Lusty Lady Theatre</gp:label>
	
	           <gp:location profile="geodetic-condition">
	             <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	               <gml:pos>-34.410649 150.87651</gml:pos>
	               <gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
	               </gs:radius>
	             </gs:Circle>
	           </gp:location>
	         </gp:location-condition>
	       </conditions>
	       <transformations/>
	     </rule>
	   </ruleset>

	The only part here that a client could display to the user in a list
of multiple rules/conditions is the label; the OGC and GML values aren't
human readable.  

	In many cases, the label can be populated automatically: the
software could show a map to the user, let them pick a point and a radius,
and fill the rule condition in as "Within 1500 m of Kearny and Broadway, San
Francisco" or "Within 1500 m of a point in San Francisco".   The user would
be the one likely to change or set the label to "When I'm near the strip
club" or some such meaningful phrase.

	There may be some field defined in common-policy that can already be
used for this purpose, in which case it would be great if the doc could
point that out and recommend its consistent use as a human mnemonic label. 

	In any case, I'm not an implementor of this stuff and unsure of
exactly how this is going to be implemented and used, so I'm planning on
clearing my DISCUSS now.

	Lisa

[hannes] I extended the schema to support this label. I guess I
misunderstood your idea previously. I thought you wanted a label at a
different place that would have required changes in Common Policy. 

Ciao
Hannes

	On Jan 12, 2009, at 8:23 AM, Hannes Tschofenig wrote:

		Hi Tim, Hi Lisa, 
		
		Richard asked me to be a bit more explicit about the changes
we have made 
		to the Geolocation Policy document. 
		
		The version that left the working group, if I looked it up
correctly, 
		was version -08: 
		
		After the IESG comments the document went back to the
working group and 
		now we are at version -18:

		Here is the diff: 

		

		
		Anyway, here are the three DISCUSSes in more detail with a
more detailed
		feedback. In any case, you raised somewhat challenging
issues. 

		*** Sam's DISCUSS: 

			Hi.

			I'm trying to think about the mechanisms in section
6 of the geopriv

			document for reducing the granularity of location.
I'm wonder though

			how effective these mechanisms are in cases where in
addition to

			getting one-time location information I'm also
seeing transitions in

			location information.

			As an example if I see a transition from one
building to a near by

			building, I may well know much more about the civic
location than

			granularity.

			Similarly, I'm wondering how much information
monitoring transitions

			in geodetic location would help me in discovering
where someone is in

			the best case.  I.E. where they are near a
discontinuity in the

			rounding.

			If these concerns are real, I expect to see a
discussion in the

			security considerations at the very least.
Depending on how serious

			they are, we may need to work on mechanisms that do
better.

		Based on discussions on the list with Sam (and other GEOPRIV
members) 
		we added additional text in the security consideration
section of the draft,
		
		namely: 
		"
		  When the Target is moving then the location
transformations reveal
		  information when switching from one privacy region to
another one.
		  For example, when a transformation indicates that civic
location is
		  provided at a 'building' level of granularity.  Hence,
room numbers,
		  floors etc. would be hidden.  However, when the Target
moves from one
		  building to the next one then the movement would still be
		  recognizable as the disclosed location information would
be reflected
		  by the new civic location information indicating the new
building.
		  With additional knowledge about building entrances and
streets it
		  would be possible to learn a certain amont of information.
It is
		  therefore important to ensure that selected privacy
regions are not
		  chosen too small when mobility is a concern and that a
random number
		  to is added to the position of the Target, with an
absolute value of
		  half the privacy region.  The latter aspect is only
applicable for
		  geodetic information or when geodetic information is
translated to
		  civic information by the Location Server.
		"

		*** Tim's DISCUSS:

			Interdependencies between the civic and geodetic
location information adds

			complexity that should be addressed in the Security
Considerations

		section.  I

			am specifically worried about situations where
differences in precision

			between the two location forms results in
information leakage.  I also see

			opportunities for error in the specification of
rulesets in the two

		location

			formats, but it is unclear whether choosing a single
form for rulesets is a

			practical alternative.

		The document allows policies to be expressed for civic and
for geodetic
		location 
		information. Location might come from different sources and
these sources
		might
		produce civic or geodetic location information. As such, it
is difficult for
		us
		rule out one of the two. The complexity of providing
translating one
		location 
		format to the other one is largely put to the respective
server providing
		the 
		location based services. Google Maps and Nokia Maps, for
example, provide 
		such a capability.
		
		It is true that there is likely to be some impression when
this
		transformation 
		takes place. In a more general sense, there are many factors
that 
		introduce errors into the measurements when obtaining
location in the first
		place. 
		More details can be found in the following document: 

		As such, the only guidance to user's creating these
authorization policies
		is 
		to consider these errors and avoid specifying too precise
boundaries. For
		example, 
		it might be a bit unrealistic to specify a totally different
privacy policy
		when 
		being at home vs. outside the building. There is a good
chance that the
		location 
		determination technique (or a potential transcoding
afterwards) is not able
		to
		correctly capture the shape of the home. 
		
		I could add a discussion about this subject to the draft but
it is quite
		likely
		that the user's are not going to read these IETF documents. 
		
		Please let me know how to capture this aspect in a
satisfactory way. 
		
		*** Lisa's DISCUSS

		

			These mechanisms are too complicated and don't give
enough thought to how

			different user-agents are going to interact.  In
particular, one should

			imagine setting a privacy policy with one user agent
and then trying to

		edit

			it with another.

			It seems that geo-spatial policy creation requires
some kind of user

		interface

			that includes a map.  Is that correct?  Are devices
without maps then

		unable

			I am not sure that the polygons are as cut-and-dried
as they appear.  I'd

		like

			to understand better:  - how one knows what is the
inside of the polygon,

		and

			what is the outside  - ... how that interacts with
poles and other

		problems

			mapping 2D to a sphere  - how the altitude stuff
works at all with client

		GUIs

			- when is altitude known and unknown, independent of
knowing a rough

		long/lat

			position  - whether you can define a polygon for
"Alberta" and one for

			"Saskatchewan" and have any point be in one or the
other or completely

		outside

			both -- but not *inside* both, and not stuck
in-between

			When it comes to users viewing policies created in
the past, the lack of

			human-readable labels and comments is going to be a
real usability

		problem.

			What happens when a user or user-agent creates a
non-sensical

		geo-political or

			geo-spatial location?

			Are all geo-political elements *really* allowed in
conditions?  One

		possible

			non-sensical policy would be "Show my location
unless I'm in seat 32A". 

			How are user agents supposed to handle mixed
geo-spatial and civic

		location

			conditions? How would that be displayed or
represented in a list of policy

			elements?

			With the dependency on geopriv-revised-civic-lo,
this can't complete yet

		anyway.
		
		You provided us with a number of tough questions. We
modified the document
		quite 
		substantially to address them. 
		
		Based on your feedback we have modified the conditions and
the actions of
		the 
		policy rules. Conditions now include only 2 D location and
the polygon
		capability 
		was replaced by a circle. 
		
		On the action side we replaced the previously contained 3D
gelocation
		location 
		transformation also with a 2D circle. The consequence is a
much simpler
		transformation operation that is also much simpler to
understand for users. 
		
		As discussed on the GEOPRIV mailing list when your review
was posted, we
		assume
		that a map is available to create these policies. The user
interface with
		all
		these policy mechanisms is certainly challenging and
investigations
		regarding 
		usability will have to continue. This certainly includes
consistency checks 
		regarding the information provided by the user. 
		
		We did not add comment elements to the Common Policy
mechanism as it would
		require us to re-visit Common Policy. We might do that when
more
		implementation 
		and deployment feedback is available. 
		
		Regarding the dependency on geopriv-revised-civic-lo:
Luckily, this document
		
		is published by now already:
http://www.ietf.org/rfc/rfc5139.txt
		
		If these changes are not sufficient I only have one other
proposal, 
		namely to change the type of document from "Standards Track"
to
		"Experimental". 
		
		Ciao
		Hannes

	--- Scanned by M+ Guardian Messaging Firewall --- Messaging
Architects sponsors The Spamhaus Project.