Subject: [Geopriv] Geo URI and privacy URI

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Mar 2009 16:15:23 -0400

I like this work, and hope we don't screw up it's simplicity and
usefulness in arcane discussions of the difference between location
representation and a URI...

A small, but useful way to bring in the geopriv privacy mechanism would
be to allow two characters at the end of the string, which when present
mean allow retention/retransmission and absence means don't, plus an
optional parameter which has a URI that returns the ruleset.

This means a naked lat/lon/altitude is a simple location with no
retention and no retransmission allowed, and no rules, and appearance of
the options gives the RM the ability to pull in the full geopriv privacy
mechanism.

I have difficulty suggesting the two characters because
retRANSMISSion and
retENT     ion have so many letters in common.

I propose R and E.

So geo:124.4,36.19R means retransmission=y and retension=n, with no
ruleset.

And geo:124.4,36.19E;priv="http:example.com/myrules" means
retransmission=n, retention=y and see example.com/myrules for the
complete ruleset

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 15:57:43 -0500

Rather than go totally arcane as Brian suggests, in the interest of human readability do two things:

1 - state that all are assumed to be public information unless the context identifies otherwise; no need to add a parameter for retransmission

2 - add an expiry attribute that states when the information is no longer valid - this isn't a single character, so expires=<iso date> would be ok.  Set a default of the heat death of the universe if you like, other options might end up being ignored.

Additional rules are pointless.  Where I see this being used, I can't see that anyone is going to implement common-policy.

Ta,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Thursday, 26 March 2009 1:15 PM
> To: GEOPRIV
> Subject: [Geopriv] Geo URI and privacy URI
> 
> _______________________________________________
> 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]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 26 Mar 2009 14:02:34 -0700

I liked Brian's reference to a larger ruleset idea. 
If you don't understand them then you are just more limited to pass location
around. As you know, the rules add more rights. 

>1 - state that all are assumed to be public information unless 
>the context identifies otherwise; no need to add a parameter 
>for retransmission
>
>2 - add an expiry attribute that states when the information 
>is no longer valid - this isn't a single character, so 
>expires=<iso date> would be ok.  Set a default of the heat 
>death of the universe if you like, other options might end up 
>being ignored.
>
>Additional rules are pointless.  Where I see this being used, 
>I can't see that anyone is going to implement common-policy.
>
>Ta,
>Martin
>
>> A small, but useful way to bring in the geopriv privacy mechanism 
>> would be to allow two characters at the end of the string, 
>which when 
>> present mean allow retention/retransmission and absence means don't, 
>> plus an optional parameter which has a URI that returns the ruleset.
>> 
>> retention and no retransmission allowed, and no rules, and 
>appearance 
>> of the options gives the RM the ability to pull in the full geopriv 
>> privacy mechanism.
>> 
>retRANSMISSion 
>> and

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Mar 2009 17:06:10 -0400

The "arcane" part is the encoding of the retransmission/retention parameters, and I'm happy to discuss other encodings.  I don't see why we should re-invent a new privacy architecture for this mechanism.  I do think that in most use cases, the default of no retransmission, no retention and no ruleset is in fact what is wanted, and when it isn't, just using what we have done is appropriate.  Specifically, I don't see why an expiry is more interesting than retransmission.  It didn't use to be.  We decided that the two most important rules where retention and retransmission.  I don't see what changes in this use case.

Brian 

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Thursday, March 26, 2009 4:58 PM
To: Rosen, Brian; GEOPRIV
Subject: RE: [Geopriv] Geo URI and privacy URI

Ta,
Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Mar 2009 17:13:05 -0400

After some of the W3C discussion and the brief discussion of the issue  
at the end of the meeting, I wonder whether fine-grained expiration  
information is really all that useful. I mentioned the logging issue -  
when logging to a file (i.e., the typical Apache configuration), it's  
not really possible to have different expiration dates for each  
request. I also can't imagine that users care to specify that the  
information expires exactly in 9 days, 3 hours and 5 minutes. Thus,  
the realistic options are probably no logging (and no debugging  
capability) and essentially infinite retention, i.e., until the last  
backup tape is destroyed. Or are backup tapes not included in retention?

Henning

On Mar 26, 2009, at 4:57 PM, Thomson, Martin wrote:

> 1 - state that all are assumed to be public information unless the  
> context identifies otherwise; no need to add a parameter for  
> retransmission
>
> 2 - add an expiry attribute that states when the information is no  
> longer valid - this isn't a single character, so expires=<iso date>  
> would be ok.  Set a default of the heat death of the universe if you  
> like, other options might end up being ignored.
>
> Additional rules are pointless.  Where I see this being used, I  
> can't see that anyone is going to implement common-policy.
>
> Ta,
> Martin
>
>> would

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 16:16:59 -0500

In the end, this has to be usable.  Does this work?

  geo:-34.406,150.882;private;nolog

Or does it need to be safe by default?

  geo:-34.406,150.882;public;cankeep

--Martin

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 26 March 2009 2:13 PM
> To: Thomson, Martin
> Cc: Rosen, Brian; GEOPRIV
> Subject: Re: [Geopriv] Geo URI and privacy URI
> 
> >> of

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Mar 2009 17:18:27 -0400

The latter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomson, Martin
Sent: Thursday, March 26, 2009 5:17 PM
To: Henning Schulzrinne
Cc: GEOPRIV; Rosen, Brian
Subject: Re: [Geopriv] Geo URI and privacy URI

--Martin

> >> retransmission=n, retention=y and see example.com/myrules for the

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Mar 2009 17:28:01 -0400

Yes, it would.

However, the combination

;public;nolog

is probably somewhat peculiar, since it gives the LR the permission to  
put it on a public web page, which might then be indexed and cached by  
Google. Safe by default seems advisable, but there's only so much you  
can do. If somebody posts a plain geo: URL to twitter or Facebook or  
emails it to the IETF list, what does this mean in terms of privacy?  
If twitter stores tweets, you can't really expect them to go look for  
geo URLs in the text and not store those. In general, I think we need  
to think more carefully about the use cases and what privacy models  
are implementable in real systems that exist today.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Mar 2009 17:28:40 -0400

Don't take Henning's problem too far.
You want the original "retention", and you want to define it as NOT
including simple logging, with some qualifying text that defines something
reasonable.

Logs kept private for 30 days should not trigger "retention" limits.
Logs on public webservers or never deleted probably do.
A simple way around the problem is to log the event, but not the data.

Brian

-----Original Message-----

--Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Mar 2009 17:35:24 -0400

> including simple logging, with some qualifying text that defines  

Then what does retention really mean? I thought one concern is  
discoverability during legal proceedings. The basic principle has to  
be "least surprise" for the user - if you promise "10 days retention",  
and then have the log appear in court, the user will start to question  
as to why bother.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 16:40:09 -0500

I'm with Henning on this one - I think that ephemeral "retention" in volatile storage for the duration of a "session" is acceptable, but no more than that.

If you are asked not to log this, then there are ways to ensure that it isn't logged.  It might require a change to the way you transfer it to avoid automatic logging, but that's an implementation concern.  If we want to prevent retention, then we can't equivocate and provide loopholes.

> Sent: Thursday, 26 March 2009 2:35 PM
> To: Brian Rosen
> Cc: Thomson, Martin; 'GEOPRIV'

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Mar 2009 17:40:40 -0400

Yep, that's my point.  Retention means you keep the log forever, so it is
discoverable.
If you do that, it's a problem.  Most logs are only kept for maybe 30 days.
I think that is okay.  You can have a packet sniffer and it would have the
same problem.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 16:47:58 -0500

30 days might as well have been forever if the site get a subpoena and it subsequently goes on court record.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 26 March 2009 2:41 PM
> To: 'Henning Schulzrinne'

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Mar 2009 17:53:40 -0400

Plus, logs are routinely (and sometimes inadvertently) backed up by  
normal operating procedures. Whatever we describe, we need to clearly  
describe the expectations in terms implementors can understand and  
work with. This may be more of a lo-sec issue, however. I have no  
objection to three levels of retention (none; 30 days; forever), if we  
can come up with a set of reasonable rules that reflect common web  
operating practices.

On Mar 26, 2009, at 5:47 PM, Thomson, Martin wrote:

> 30 days might as well have been forever if the site get a subpoena  
> and it subsequently goes on court record.
>
>>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 26 Mar 2009 14:54:12 -0700

The expression of the retention expiration is useful precisely because  
there is no "reasonable" time frame for all logging. Location-based  
ads that take a geo URI as input will likely be retained for as long  
as the advertiser has contracted for click fraud investigation  
purposes (6-12 months is popular). But if lots of geo URIs started  
showing up with shorter expirations, recipients might be incented to  
reduce those times, get rid of the geo info earlier while retaining  
other info, or substite more precise info in the logs with less  
precise info (Yahoo does this for the geo info derived from IP  
addresses in its logs). Even if every single expiration date is not  
honored, there is value in being able to express the desired expiration.

On the other hand, I wonder if, for simplicity's sake, it might make  
sense to make any rules params optional if the geo URI is contained  
within a PIDF-LO (along the lines of what Jon suggested during the  
meeting). Then you could get the nice simple geo format and the full  
policy.

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 16:59:21 -0500

You could allow for rules overriding, which (I think) is what you are suggesting.  Some care might be needed to avoid complications or misinterpretations that arise.

---

From: John Morris <[email-masked]>
Date: Thu, 26 Mar 2009 15:05:33 -0700

+1 to Alissa (perhaps not a surprise)...  but for historical 
interest, I have pasted below excerpts from three 2003 e-mails in 
which Henning and I discussed this same topic....  John

At 11:01 AM -0500 11/11/03, Henning Schulzrinne wrote:
>Date: Tue, 11 Nov 2003 11:01:13 -0500
>From: Henning Schulzrinne <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: [Geopriv] Questions on pidf-lo
>
>After another reading and some hallway discussions, a few questions 
>on PIDF-LO:
><snip>
>3) Retention
>
>Normal operating procedure is that databases are backed up. Am I 
>liable if a location object accidentally makes it onto the backup 
>tape? (Example: retention is 24 hours; LO arrives at 8 pm; backup is 
>run at midnight. I can't tell the backup routine to not backup that 
>entry.)
>
>Worded in its current vagueness, I'm afraid that any large entity 
>who has any exposure at all would be foolish to accept any object 
>that in any way restricts retention and distribution.
>
>Henning

At 12:34 PM -0600 11/11/03, John Morris wrote:
>Date: Tue, 11 Nov 2003 12:34:32 -0600
>To: Henning Schulzrinne <[email-masked]>
>From: John Morris <[email-masked]>
>Subject: Re: [Geopriv] Questions on pidf-lo
>Cc: "[email-masked]'" <[email-masked]>
>
>Henning, you won't be happy with how I would answer these questions. 
>See inline.  John
<snip>
>>3) Retention
>>
>>Normal operating procedure is that databases are backed up. Am I 
>>liable if a location object accidentally makes it onto the backup 
>>tape? (Example: retention is 24 hours; LO arrives at 8 pm; backup 
>>is run at midnight. I can't tell the backup routine to not backup 
>>that entry.)
>>
>>Worded in its current vagueness, I'm afraid that any large entity 
>>who has any exposure at all would be foolish to accept any object 
>>that in any way restricts retention and distribution.
>
>My answer is that big entities will have to cope.  In the U.S. at 
>least, we have not yet resolved the train wreck that occurs between 
>privacy and routine backup tapes.  If the info is in a backup tape, 
>it can be obtained through subpoena, law enforcement request, etc.
>
>And yes, I do think that companies are moving toward a more 
>considered backup strategy that takes privacy and other legal 
>obligations into account.  It will be a slow transistion, but I 
>think it will happen.
>
>So any entity concerned about this type of exposure should decide 
>that certain information should simply not be retained in databases 
>that are routinely backed up.  I strongly do not think we should 
>allow geopriv to say "do not retain the info longer than the rule 
>permits (except routine backups don't count)."
>
>>Henning
>
>John

At 2:56 PM -0500 11/11/03, Henning Schulzrinne wrote:
>Date: Tue, 11 Nov 2003 14:56:58 -0500
>From: Henning Schulzrinne <[email-masked]>
>To: John Morris <[email-masked]>
>Cc: "[email-masked]'" <[email-masked]>
>Subject: Re: [Geopriv] Questions on pidf-lo
>
>John Morris wrote:
>
>>Henning, you won't be happy with how I would answer these 
>>questions. See inline.  John
>
>I'm actually happy with *any* consistent and implementable answer. 
>I'm mostly concerned that implementors are given insufficient 
>guidance in the spec.
>
<snip>
>>My answer is that big entities will have to cope.  In the U.S. at 
>>least, we have not yet resolved the train wreck that occurs between 
>>privacy and routine backup tapes.  If the info is in a backup tape, 
>>it can be obtained through subpoena, law enforcement request, etc.
>>
>>And yes, I do think that companies are moving toward a more 
>>considered backup strategy that takes privacy and other legal 
>>obligations into account.  It will be a slow transistion, but I 
>>think it will happen.
>>
>>So any entity concerned about this type of exposure should decide 
>>that certain information should simply not be retained in databases 
>>that are routinely backed up.  I strongly do not think we should 
>>allow geopriv to say "do not retain the info longer than the rule 
>>permits (except routine backups don't count)."
>
>As long as we say "this includes backup media", I'm fine - I'm just 
>for clarity. We can't remove every ambiguity, but that's no excuse 
>not to be precise where we can.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Mar 2009 18:12:23 -0400

I'm sorry, but after 6 years we're no closer to this happening.  
However, anything that requires running non-standard web setups seems  
like a non-starter. No wonder that W3C doesn't take GEOPRIV seriously...

Henning

On Mar 26, 2009, at 6:05 PM, John Morris wrote:

>>> least, we have not yet resolved the train wreck that occurs  
>>> between privacy and routine backup tapes.  If the info is in a  
>>> backup tape, it can be obtained through subpoena, law enforcement  
>>> request, etc.
>>>
>>> that certain information should simply not be retained in  
>>> databases that are routinely backed up.  I strongly do not think  
>>> we should allow geopriv to say "do not retain the info longer than  
>>> the rule permits (except routine backups don't count)."
>>

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 28 Mar 2009 13:22:09 -0400

I might be about to get too philosophical here, but...

In some sense the entire Geopriv privacy architecture could be  
considered a "non-starter" for the same reason you suggest below: it's  
meant to encourage location recipients to change their current  
behavior. If it didn't require behavior change, it wouldn't have any  
utility.

Again, I think retention-expires has value even if all that results  
from it is that a recipient thinks twice about its logging policy, or  
clarifies its disclosures about its logging policy, or realizes that  
people care about its logging policy. IMO, defining a strict semantic  
that results in this kind of reaction is preferable to creating a  
loophole in the semantic that could potentially swallow all of its  
value.

On Mar 26, 2009, at 6:12 PM, Henning Schulzrinne wrote:

> However, anything that requires running non-standard web setups  
> seems like a non-starter. No wonder that W3C doesn't take GEOPRIV  
> seriously...
>
> Henning
>
>>> After another reading and some hallway discussions, a few  
>>> questions on PIDF-LO:
>>> <snip>
>>> 3) Retention
>>>
>>>> we should allow geopriv to say "do not retain the info longer  
>>>> than the rule permits (except routine backups don't count)."
>>>
>>> As long as we say "this includes backup media", I'm fine - I'm  
>>> just for clarity. We can't remove every ambiguity, but that's no  
>>> excuse not to be precise where we can.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Mar 2009 14:20:54 -0400

But the IETF is an engineering organization, not a political lobbying  
organization, so practicality matters. As I've pointed out, a strict  
interpretation of the retention policy means that only no logging at  
all is possible, since you can't reasonably purge logs at different  
time intervals. It's a bit much to expect a company to completely re- 
architect their web server, if the alternative is to ignore GEOPRIV.  
I'd be really surprised if any company in the location space thinks  
about GEOPRIV at all...

It's pretty clear that, after 6 years, we've had minimal impact in the  
pieces that require location privacy, so it might be time to ask why.  
I'm all for the goals of ensuring privacy, but relying on "everybody  
should be doing it the way we want to" is not a road to success. There  
is nothing magic about the policy primitives that we cooked up in the  
early GEOPRIV days; given their lack of impact, it might be useful to  
consider ideas that achieve privacy goals, but more closely reflect  
how real network services work, as opposed to expecting everyone to  
change.

As defined currently, logging has to be seen as retention, so we  
either need to specify that it somehow doesn't apply as long as the  
site has a logging policy stated (or some other reasonable  
definition), or expect to be ignored.

Henning

On Mar 28, 2009, at 1:22 PM, Alissa Cooper wrote:

> considered a "non-starter" for the same reason you suggest below:  
> it's meant to encourage location recipients to change their current  
> from it is that a recipient thinks twice about its logging policy,  
> or clarifies its disclosures about its logging policy, or realizes  
> that people care about its logging policy. IMO, defining a strict  
> semantic that results in this kind of reaction is preferable to  
> creating a loophole in the semantic that could potentially swallow  
> all of its value.
>
>>>>> liable if a location object accidentally makes it onto the  
>>>>> backup tape? (Example: retention is 24 hours; LO arrives at 8  
>>>>> pm; backup is run at midnight. I can't tell the backup routine  
>>>>> to not backup that entry.)
>>>>>
>>>>> Worded in its current vagueness, I'm afraid that any large  
>>>>> entity who has any exposure at all would be foolish to accept  
>>>>> any object that in any way restricts retention and distribution.
>>>>
>>>> I'm actually happy with *any* consistent and implementable  
>>>> answer. I'm mostly concerned that implementors are given  
>>>> insufficient guidance in the spec.
>>>>
>>> <snip>
>>>>> My answer is that big entities will have to cope.  In the U.S.  
>>>>> at least, we have not yet resolved the train wreck that occurs  
>>>>> backup tape, it can be obtained through subpoena, law  
>>>>> enforcement request, etc.
>>>>>
>>>>> So any entity concerned about this type of exposure should  
>>>>> decide that certain information should simply not be retained in

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 28 Mar 2009 15:34:14 -0400

I agree with Henning.  I'm perfectly happy, and willing to work on,
mechanisms to expose and implement privacy controls, but I don't think they
can be forced down an unwilling throat.  The example of logging is apt.  If
you have an organization that is willing to rewrite the Apache log code to
exclude the location information, or purge it, fine, I'm all for it.  To
build a system which requires someone else to do that, and have every
organization that uses location have to deploy that mechanism is, uh, not
going to happen. Period.  Scream all you want.  

We have way too much experience that writing MUST in a document doesn't work
if the MUST is impractical or expensive to implement.  It gets ignored, and
we suffer when our reality does not match our documents.  See 3261, MUST
IMPLEMEMT re TLS.  What happens when we stand on principal and not work on
practical is NATs and W3C location.

What we have is impractical.  You can't readily implement it.  Not enough
people care, and there is no reasonable way to change that.  If you want to
try, talk to a legislator, not an engineer.  We need mechanisms that are
optional, but easy to implement if you want to.
  
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Saturday, March 28, 2009 2:21 PM
To: Alissa Cooper
Cc: 'GEOPRIV'; John Morris
Subject: Re: [Geopriv] Geo URI and privacy URI

Henning

---

From: [email-masked]
Date: Sun, 29 Mar 2009 12:01:50 -0400 (EDT)

All -

There is a Open Mobile Alliance document titled, "LIF Privacy Guidelines".
This document was developed over a period from 2001 to 2002. Considerable
discussion (both legal and philosophical) and numerous use cases
documented. This document and its contents might be useful in this
discussion.

Go to http://www.openmobilealliance.org/tech/affiliates/lif/lifindex.html
and clink on "download" for Privacy Guidelines and then agree to the terms
of use.

Cheers

Carl

---

From: Richard Barnes <[email-masked]>
Date: Sun, 29 Mar 2009 22:28:36 -0400

Carl,

Thanks for the pointer.  I knew of the LIF/OMA Privacy Checking Protocol 
(PCP, aptly :) ), but last I heard, that was not widely implemented (and 
possibly deprecated).

Also, I note with appropriate irony that the terms of use for the 
document you referenced contain the following paragraph:

"
Open Mobile Alliance's Privacy Policy

You consent to the collection, processing and storage by Open Mobile 
Alliance of Your personal information in accordance with the terms of 
the Open Mobile Alliance's Privacy Policy, which is available at 
http://www.openmobilealliance.org/privacypolicy. You agree to comply 
with all applicable laws and regulations, and the terms of Open Mobile 
Alliance's Privacy Policy, with respect to any access, use and/or 
submission by You of any personal information in connection with this 
Web site.
"

... this being the standard Web privacy model -- site decides 
unilaterally -- in contrast to the Geopriv model, in which the site at 
least makes an informed decision.

Cheers,
--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 30 Mar 2009 17:52:57 -0500

PCP is dead.  It has been removed from later versions of enablers.  My impression was that no one was implementing it.

> Behalf Of Richard Barnes
> Sent: Sunday, 29 March 2009 7:29 PM
> To: [email-masked]
> Cc: 'GEOPRIV'; John Morris; Henning Schulzrinne
> > Go to
> http://www.openmobilealliance.org/tech/affiliates/lif/lifindex.html
> it's
> or
> backup
> entity
> than
> answer.
> at
> enforcement
> decide

---

From: [email-masked]
Date: Tue, 31 Mar 2009 04:15:17 -0400 (EDT)

Correct - but PCP was not based on the privacy guidance document . . .

Interesting point on the irony :-)

Thanks

Carl

> PCP is dead.  It has been removed from later versions of enablers.  My
> impression was that no one was implementing it.
>