Subject: [Geopriv] Comments on draft-barnes-geopriv-lo-sec-05 (part 1: Sections 1 and 2)

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Mar 2009 00:58:24 -0500

Hi authorship collective,

I must say that while I like some of the changes and additions, it appears that this edit isn't yet complete.  There are a lot of cases where it appears that text from the previous version still exist without being updated to align with the basic paradigms that have changed.

I was hoping that I'd be able to say that the document would be ready for publication this time.  Unfortunately, I don't think that it is ready.  There are a lot of minor issues that need to be resolved before this document works as a coherent whole.

My review is a stream-of-consciousness type review since there is quite a lot to say and organizing it is not worth my time.  I'll pick the important bits up as I go and bring them up front.  For the rest you'll have to sort through the muck to get to the useful bits.

==Review highlights

The LR role has been moved to the "ultimate end point", a decision that I question.

The description of the "positioning protocol" needs to proscribe its role more clearly.  It's not clear if this is LCP, or something that happens behind that.  If it's what we've been calling LCP, the "positioning protocol" can observe the same privacy constraints as any other interface, with caveats that recognise (a) the Target's permission to acquire information about its own location and (b) it's role as a Rule Maker.  If it's something new, then it should be separated from the rest of the discussion.

==Details

Section 1.

s/Second, this document should provide/Second, this document provides/
 - self-deprecation has its place, but not here

Section 1.2.

It's rare to see a document from a technical organization that contains such socially and morally sensitive discussion.  This section is really helpful.  However you need to take care not to lose your audience.  Too many technical folks - hard-nosed pragmatist types in particular - have little motivation to consider these issues and any objectionable text is likely to result in them losing interest.

I'd also recommend finding a way to shorten this section, even though it might seem like it is already as short as it can be.  What you are trying to say is that there are aspects of location that make privacy extremely important.  Maybe a short enumeration of the various aspects (continuous availability, connection with activities, surveillance, etc...) up front would help get the message through thick skulls.

I don't think that it helpful to exaggerate the importance of location information.  I think that the following sentence needs restructuring:

   While other kinds of data
   could arguably be considered more sensitive than location information
   in certain contexts -- an individual's medical records or bank
   statements, for instance -- these kinds of data provide mere
   snapshots of an individual's activities at discrete moments in time,
   or within discrete aspects of their lives.  	

This sentence structure leads me to instinctively object to your argument.  Any "for instance" used should be usable directly in the ensuing assertion.  However, when I test the assertion that medical records are less significant than location information (a "mere snapshot" or not) I find the assertion to be false.

Section 1.3.

The "must" in this sentence isn't a real must in this context since this implies some sort of constraint that prevents this inherent in the architecture:

   The privacy protections in the Geopriv architecture
   are largely provided by virtue of the fact that recipients of
   location (...) are informed of relevant privacy rules, and must only use
   location in accordance with those rules.

The fragment after the comma could be removed.  The rest of the paragraph can address the problem of enforcement.  Right now, I don't believe that it does.  Suggest something like:

   Geopriv specifications require that recipients respect privacy rules.  No technical means of enforcing privacy rules are provided by the architecture; however, Section 4 describes limited means of using technical constraints to protect privacy.

Section 2.

I don't like the name "receipt" for the third phase, since it implies a passive component of distribution.  "use" would be preferable in absence of a better suggestion.

I would also suggest "acquisition" for the first phase, since the term "positioning" implies something more than what is done by a HELD or DHCP client.

I'd also like to see a brief discussion of the three phases up front - even if the names are self-explanatory.  If it is that important, move it up from 2.1.

The last paragraph starting with "Within this framework..." seems to be attempting to cover both "usage rules" and "access control rules".  In doing so, it gets tangled.  There are a great many aspects that need to be dealt with.  This paragraph should either be comprehensive summary or just a hint that there are multiple aspects where "security" is important.

Section 2 has a minor case of ascii-art rot.

Section 2.1 actually helped me understand something about RFC4119.  Isn't that sad?  The referenced authorization policy document in the RFC 4119 structure is an access control document.  That particular realization helps greatly in understanding its use - I still think that it's useless, but with the interpretation I get from the examples here at least it isn't useless, ineffectual and ambiguous all at once.  'tis a shame it took an example for that to be clear though.

Section 2.2

Check the definition of Rule Maker - the last two sentences are a little contradictory.  s/, however, //

Definition of LG: s/the figure above/Figure 1/

Definition of LS: s/receives and distributes/distributes/

Definition of LR: I know that you've made a conscious decision to move away from the LS -> LR/LS -> LR/LS -> LR model from previous versions but I think that it undermines your message.  An intermediate location server is a location recipient that is still bound by the usage rules.  However, the presence of access control rules allows any LR to become an LS.  Remove "ultimate" - anyone that receives location information is a recipient: "An entity to which location information is distributed."

The removal of LR from all but the terminal phase is - I believe - a mistake.  There is no way of knowing for certain who or what is "the" last recipient.  (Re)distribution is a use.  Location Servers are location recipients, unless they are Location Generators.  That is a very simple model that works.  I see no reason to change it.

That is, the Target is a recipient if it acquires location information from a remote LG, but that LG then requires an LS to accomplish that.  There are special circumstances and conditions for conveyance to the Target itself.  You can break description of those special bits into its own section that doesn't need to be dealt with straight away.

The text in the middle of the definitions mentions "three types of protocols" in a list lead-in, then proceeds to define other things first.  That's probably an ordering mistake.

Definition of privacy rule: the first sentence is good, but there's no mention of the new distinction between usage and access control rules.  The second sentence tries to provide details but doesn't really cover everything, better to reference earlier discussion or drop it.

Positioning Protocol?  Why not use location configuration protocol and avoid minting a new term?  Or is this something else?  Because that isn't clear until too late (for me anyway).  For an LCP, I don't see that there is much need to distinguish this from distribution/conveyance from the privacy perspective.  All the same rules apply - the only thing special about this interaction is authorization, which has a default rule.

A conveyance protocol is the primary component of the distribution phase.  This is not mentioned.  Likewise, rules protocols are a way of moving rules separate to the LO "lifecycle".

Section 2.3

There is an inconsistency between what is shown in examples and the last paragraph here.  The LG and LS interactions described refer to what lcp-ps calls a LIS, but this name is never used - I think that it's a useful label in relating the model to reality.  

Somewhat unrelated.  James is right: access control rules are a subset of usage rules.  After reading this, I'm thinking that we don't need retransmission-allowed at all.  Shocking?  Here's how it goes: without rules describing how you are permitted to distribute a location object, don't distribute it.  It's really quite simple.  Presence or absence of rules is your retransmission-allowed.

...to be continued...

Cheers,
Martin

------------------------------------------------------------------------------------------------
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]

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 12 Mar 2009 17:25:35 -0400

Martin,

Thanks very much for the review. While we are digesting it, John and I  
wanted to toss out a few changes we would like to see that we didn't  
quite get to before the submission deadline:

1. Integrate the hold-over text from the previous version with the  
rest of the document and make it consistent with the new text (as you  
suggest).

2. Clarify the distinction (or lack thereof) between the LG and the  
initial LS. The discussion amongst the authors on this point lasted  
well into the drafting process, which resulted in some murkiness.

3. Clarify who has location at the end of the positioning process (the  
Target, the LG, or an initial LS) and make sure this discussion is  
consistent throughout.

4. Do a quick intro in section 1 to the kinds of things that privacy  
rules can offer, for example, "you can allow your spouse to learn your  
exact location all of the time, allow your boss to learn your  
approximate location only some of the time," etc.. This has tripped us  
up in talking to outsiders about Geopriv, but right now the first  
mention of what rules can do is not until page 21 (and some readers  
may not get that far).

5. Push the introduction of protocols down from section 2 to section 3  
so as not to be introducing so much terminology all at once.

I agree that the document ended up longer than it should have been, so  
it would be nice to be able to pare it down a bit in the next revision  
as well. I don't yet have a plan for how to do that but we will keep  
it in mind as comments start to come in.

We will respond to your individual comments shortly.
Alissa

On Mar 12, 2009, at 1:58 AM, Thomson, Martin wrote:

> I must say that while I like some of the changes and additions, it  
> appears that this edit isn't yet complete.  There are a lot of cases  
> where it appears that text from the previous version still exist  
> without being updated to align with the basic paradigms that have  
> changed.
>
> I was hoping that I'd be able to say that the document would be  
> ready for publication this time.  Unfortunately, I don't think that  
> it is ready.  There are a lot of minor issues that need to be  
> resolved before this document works as a coherent whole.
>
> My review is a stream-of-consciousness type review since there is  
> quite a lot to say and organizing it is not worth my time.  I'll  
> pick the important bits up as I go and bring them up front.  For the  
> rest you'll have to sort through the muck to get to the useful bits.
>
> ==Review highlights
>
> The description of the "positioning protocol" needs to proscribe its  
> role more clearly.  It's not clear if this is LCP, or something that  
> happens behind that.  If it's what we've been calling LCP, the  
> "positioning protocol" can observe the same privacy constraints as  
> any other interface, with caveats that recognise (a) the Target's  
> permission to acquire information about its own location and (b)  
> it's role as a Rule Maker.  If it's something new, then it should be  
> separated from the rest of the discussion.
>
> ==Details
>
> Section 1.
>
> It's rare to see a document from a technical organization that  
> contains such socially and morally sensitive discussion.  This  
> section is really helpful.  However you need to take care not to  
> lose your audience.  Too many technical folks - hard-nosed  
> pragmatist types in particular - have little motivation to consider  
> these issues and any objectionable text is likely to result in them  
> losing interest.
>
> I'd also recommend finding a way to shorten this section, even  
> though it might seem like it is already as short as it can be.  What  
> you are trying to say is that there are aspects of location that  
> make privacy extremely important.  Maybe a short enumeration of the  
> various aspects (continuous availability, connection with  
> activities, surveillance, etc...) up front would help get the  
> message through thick skulls.
>
> I don't think that it helpful to exaggerate the importance of  
> location information.  I think that the following sentence needs  
> restructuring:
>
> This sentence structure leads me to instinctively object to your  
> argument.  Any "for instance" used should be usable directly in the  
> ensuing assertion.  However, when I test the assertion that medical  
> records are less significant than location information (a "mere  
> snapshot" or not) I find the assertion to be false.
>
> Section 1.3.
>
> The "must" in this sentence isn't a real must in this context since  
> this implies some sort of constraint that prevents this inherent in  
> the architecture:
>
> The fragment after the comma could be removed.  The rest of the  
> paragraph can address the problem of enforcement.  Right now, I  
> don't believe that it does.  Suggest something like:
>
>   Geopriv specifications require that recipients respect privacy  
> rules.  No technical means of enforcing privacy rules are provided  
> by the architecture; however, Section 4 describes limited means of  
> using technical constraints to protect privacy.
>
> Section 2.
>
> I don't like the name "receipt" for the third phase, since it  
> implies a passive component of distribution.  "use" would be  
> preferable in absence of a better suggestion.
>
> I would also suggest "acquisition" for the first phase, since the  
> term "positioning" implies something more than what is done by a  
> HELD or DHCP client.
>
> I'd also like to see a brief discussion of the three phases up front  
> - even if the names are self-explanatory.  If it is that important,  
> move it up from 2.1.
>
> The last paragraph starting with "Within this framework..." seems to  
> be attempting to cover both "usage rules" and "access control  
> rules".  In doing so, it gets tangled.  There are a great many  
> aspects that need to be dealt with.  This paragraph should either be  
> comprehensive summary or just a hint that there are multiple aspects  
> where "security" is important.
>
> Section 2.1 actually helped me understand something about RFC4119.   
> Isn't that sad?  The referenced authorization policy document in the  
> RFC 4119 structure is an access control document.  That particular  
> realization helps greatly in understanding its use - I still think  
> that it's useless, but with the interpretation I get from the  
> examples here at least it isn't useless, ineffectual and ambiguous  
> all at once.  'tis a shame it took an example for that to be clear  
> though.
>
> Section 2.2
>
> Definition of LR: I know that you've made a conscious decision to  
> move away from the LS -> LR/LS -> LR/LS -> LR model from previous  
> versions but I think that it undermines your message.  An  
> intermediate location server is a location recipient that is still  
> bound by the usage rules.  However, the presence of access control  
> rules allows any LR to become an LS.  Remove "ultimate" - anyone  
> that receives location information is a recipient: "An entity to  
> which location information is distributed."
>
> The removal of LR from all but the terminal phase is - I believe - a  
> mistake.  There is no way of knowing for certain who or what is  
> "the" last recipient.  (Re)distribution is a use.  Location Servers  
> are location recipients, unless they are Location Generators.  That  
> is a very simple model that works.  I see no reason to change it.
>
> That is, the Target is a recipient if it acquires location  
> information from a remote LG, but that LG then requires an LS to  
> accomplish that.  There are special circumstances and conditions for  
> conveyance to the Target itself.  You can break description of those  
> special bits into its own section that doesn't need to be dealt with  
> straight away.
>
> The text in the middle of the definitions mentions "three types of  
> protocols" in a list lead-in, then proceeds to define other things  
> first.  That's probably an ordering mistake.
>
> Definition of privacy rule: the first sentence is good, but there's  
> no mention of the new distinction between usage and access control  
> rules.  The second sentence tries to provide details but doesn't  
> really cover everything, better to reference earlier discussion or  
> drop it.
>
> Positioning Protocol?  Why not use location configuration protocol  
> and avoid minting a new term?  Or is this something else?  Because  
> that isn't clear until too late (for me anyway).  For an LCP, I  
> don't see that there is much need to distinguish this from  
> distribution/conveyance from the privacy perspective.  All the same  
> rules apply - the only thing special about this interaction is  
> authorization, which has a default rule.
>
> A conveyance protocol is the primary component of the distribution  
> phase.  This is not mentioned.  Likewise, rules protocols are a way  
> of moving rules separate to the LO "lifecycle".
>
> Section 2.3
>
> There is an inconsistency between what is shown in examples and the  
> last paragraph here.  The LG and LS interactions described refer to  
> what lcp-ps calls a LIS, but this name is never used - I think that  
> it's a useful label in relating the model to reality.
>
> Somewhat unrelated.  James is right: access control rules are a  
> subset of usage rules.  After reading this, I'm thinking that we  
> don't need retransmission-allowed at all.  Shocking?  Here's how it  
> goes: without rules describing how you are permitted to distribute a  
> location object, don't distribute it.  It's really quite simple.   
> Presence or absence of rules is your retransmission-allowed.
>
> ...to be continued...
>
> Cheers,
> Martin
>

--
----------------------------------------------------
Alissa Cooper
Chief Computer Scientist
Center for Democracy and Technology
202 637 9800 x110
[email-masked]
http://www.cdt.org/