Subject: [Geopriv] Privacy of Location Information: The Intended Recipient

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Nov 2008 14:59:27 +0200

why do we have all these discussions about SIP location conveyance and
privacy. Here are my thoughts. 

RFC 4119 http://www.ietf.org/rfc/rfc4119.txt says
"
   'retransmission-allowed': When the value of this element is 'no', the
      Recipient of this Location Object is not permitted to share the
      enclosed Location Information, or the object as a whole, with
      other parties.  When the value of this element is 'yes',
      distributing this Location is permitted (barring an existing out-
      of-band agreement or obligation to the contrary).  By default, the
      value MUST be assumed to be 'no'.  Implementations MUST include
      this field, with a value of 'no', if the Rule Maker specifies no
      preference.
"

RFC 4119 only speaks about the "recipient" in the description of
retransmission-allowed but does not indicate that the role of the
recipient might need further description in a specific using protocol. 

http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-10.txt says
what it considers a location recipient to be: 
"
   Location Recipient - Defined in RFC3693 as any entity that 
      understands geolocation (LbyR or LbyV) along a message path.  
      Does not include entities that process a message containing 
      geolocation that do not understand geolocation (i.e., layer 3 
      routers).
"

Interestingly enough, this definition does not match with what is said
in 
http://www.ietf.org/rfc/rfc3693.txt
"
      Location Recipient (LR): The entity that receives location
         information.  It may have asked for this location explicitly
         (by sending a query to a location server), or it may receive
         this location asynchronously.
"

I believe that the main problem lies in the fuzzy description of what a
recipient actually is. To make things worse, in some cases the identity
of the recipient is not known by the sender and hence we are talking
only about a symbolic description (such as emergency services network,
SIP routing infrastructure) rather than specific entities.

We might have a closer look at what the recipient could be in the
context of the basic privacy policies of RFC 4119. We have already
started to go along this path by creating "symbolic" descriptions of the
recipient (with the definition of the "Location-Routing-Allowed" token).

When we, for example, look at Creative Commons
(http://creativecommons.org/) I wonder whether we couldn't learn
something from their work (given that it is quite successful). They did
three things:

* Logos -- designing something suitable for location distribution would
be very important to get users to understand the policies. 

* Pre-defined meanings based on the following main questions that are
also important to the question of location dissemination:

  - Allow commercial uses of your location? Yes/No
  - Allow modifications of your location information? 
    (specifically using it in a different context)
    Yes/No/Yes, as long as others share alike)

* License text (automatically created based on your input)

The first item is interesting as it puts a bit of context into the
retransmission/redistribution. 
(For more discussion about context in the privacy environment see
http://crypto.stanford.edu/portia/papers/RevnissenbaumDTP31.pdf) 

Looking back at the discussion about <retransmission-allowed> I wonder
whether the right approach wouldn't actually be the following: 

 -- Indicate explicitly who the intended recipient actually is (e.g.,
<retransmission-allowed
recipient="sip:[email-masked]">False</retransmission-allowed>

If some other entities "listen" to the conversation then they should be
considered as being not the intended recipient and therefore they
shouldn't be looking at the location at all.  

 -- Use technical mechanisms to ensure that as few parties see the
location info as possible; we have these mechanisms in place (LbyR,
various SIP security mechanisms)
 
 -- For location based routing we currently have one very real example:
Emergency Services. There the privacy aspects are addressed via
regulation (i.e., it does not matter what we put into the policies; they
will be ignored). For the other examples we do not yet have an
indication whether anyone would be using SIP for them at all. The famous
"pizza delivery" example is quite good here. I do get the impression
that for finding the right pizza place folks are less interested in
using SIP - location based routing but rather a Web-based Search Engine.
In case someone would use LoST for this then the privacy problems would
be solved as well (as we don't use identity information of the client in
the LoST query). So, for the cases where the recipient isn't really
known (the emergency services case, the pizza delivery case) we could
just apply the same mechanism as we did with the Service URN -- it
essentially defines the context. Hence, I would put as the intended
recipient something like 'urn:service:local.pizza' in there (inline what
is being proposed with
http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt). 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 8 Nov 2008 12:29:47 -0500

In my view, the basic problem is the unclear perspective of what we're  
trying to prevent and the fuzzy notion of "parties" (4119),
"entities" and probably other terms. This affects both the routing and  
the "intended recipient" discussion, and I'm talking about both below.

 From a privacy perspective, a user sending his location to roadside  
assistance (AAA, in the US) does not really care how many proxies and  
B2BUAs inspect the information before it reaches the dispatcher. He  
cares that the information isn't handed off to businesses or  
organizations unrelated to AAA. (In some cases, this is a bit more  
subtle, namely that the caller distinguishes between recipients that  
are needed to deal with the request, which would include the local  
towing company, and third parties that are not necessary, such as the  
insurance company or OnStar [to offer a subscription to their  
services].)

This notion is reflected in the usual privacy notices and opt-outs  
that banks and credit card companies offer. You don't get a choice  
about what the bank does with your account data as long as it is  
needed to satisfy the primary purpose of your business relationship  
(say, manage your checking account). You do, typically, get a choice  
whether the bank will pass your personal data to other subsidiaries  
(say, the brokerage division) or third parties that it may have  
marketing partnerships with, such as an insurance company.

Users don't understand the difference between proxies and B2BUAs. (For  
that matter, most telecom marketing folks don't, either...) But policy  
choices have to be meaningful to users, as the result is otherwise  
that either a calls fail that worked yesterday just because somebody  
replaced a proxy by a B2BUA or users and implementations will simply  
set the option to "yes" all the time, just like they blindly click on  
"Ok" in the annoying Vista UAC dialogues. Neither outcome improves  
privacy.

Thus, recipient should be defined as being congruent as to what users  
think, translated into something that can be made algorithmic. I think  
users generally think of individuals and organizations, which roughly  
correspond to SIP AORs. Thus, translating [email-masked] is the same  
person as [email-masked] if acme.com has a user translation mechanism,  
but is not the same as recipient as [email-masked].

I think the draft would be much more helpful and less angels-on-a-pin  
if it could help untangle these distinctions.

I also like Hannes' description of what *actually* happens in location- 
based routing. We sometimes have this notion that proxies just  
randomly route messages to random other proxies, but this isn't likely  
to happen in practice.

We also need to distinguish three cases:

(1) service URNs: If the UAC resolves to a URI via LoST, there may not  
be any location-based routing at all, or we get to case (3) below.

(2) outbound proxy routing: This occurs only with service URNs. The  
outbound proxy has to resolve the service URN, so there's really not  
much of a choice what to do. The intended recipient is an instance of  
the service, chosen by the outbound proxy. Calling whatever the  
outbound proxy does "retransmission" is kind of pointless, since  
prohibiting it just yields failure. (The only alternative would be to  
include two different LOs, one low-res one for routing and one high- 
res one for the LoST-chosen recipient.)

(3) destination routing: the request has an AOR like [email-masked] 
. The recipient is any node in the domain, chosen by whatever logic  
the company has implemented.

Henning

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 12 Nov 2008 13:32:32 +0200

Hi Henning, 

I very much agree in what you write. 

It would indeed be more useful to put the users of the policies in the
center of our discussions. 
Defining policies that are very technology and deployment specific might
make some of us happy but will not help the user. 

The question is how we get there and, in particular, how we determine
whether we got it right.

Ciao
Hannes

>In my view, the basic problem is the unclear perspective of 
>what we're trying to prevent and the fuzzy notion of "parties" 
>(4119), "entities" and probably other terms. This affects both 
>the routing and the "intended recipient" discussion, and I'm 
>talking about both below.
>
> From a privacy perspective, a user sending his location to 
>roadside assistance (AAA, in the US) does not really care how 
>many proxies and B2BUAs inspect the information before it 
>reaches the dispatcher. He cares that the information isn't 
>handed off to businesses or organizations unrelated to AAA. 
>(In some cases, this is a bit more subtle, namely that the 
>caller distinguishes between recipients that are needed to 
>deal with the request, which would include the local towing 
>company, and third parties that are not necessary, such as the 

>
>This notion is reflected in the usual privacy notices and 
>opt-outs that banks and credit card companies offer. You don't 
>get a choice about what the bank does with your account data 
>as long as it is needed to satisfy the primary purpose of your 
>business relationship (say, manage your checking account). You 
>do, typically, get a choice whether the bank will pass your 
>personal data to other subsidiaries (say, the brokerage 
>division) or third parties that it may have marketing 
>partnerships with, such as an insurance company.
>
>Users don't understand the difference between proxies and 
>B2BUAs. (For that matter, most telecom marketing folks don't, 
>either...) But policy choices have to be meaningful to users, 
>as the result is otherwise that either a calls fail that 
>worked yesterday just because somebody replaced a proxy by a 
>B2BUA or users and implementations will simply set the option 
>to "yes" all the time, just like they blindly click on "Ok" in 
>the annoying Vista UAC dialogues. Neither outcome improves privacy.
>
>Thus, recipient should be defined as being congruent as to 
>what users think, translated into something that can be made 
>algorithmic. I think users generally think of individuals and 
>organizations, which roughly correspond to SIP AORs. Thus, 
>translating [email-masked] is the same person as 
>[email-masked] if acme.com has a user translation mechanism, but 
>is not the same as recipient as [email-masked].
>
>I think the draft would be much more helpful and less 
>angels-on-a-pin if it could help untangle these distinctions.
>
>I also like Hannes' description of what *actually* happens in 
>location- based routing. We sometimes have this notion that 
>proxies just randomly route messages to random other proxies, 
>but this isn't likely to happen in practice.
>
>(1) service URNs: If the UAC resolves to a URI via LoST, there 
>may not be any location-based routing at all, or we get to 
>case (3) below.
>
>(2) outbound proxy routing: This occurs only with service 
>URNs. The outbound proxy has to resolve the service URN, so 
>there's really not much of a choice what to do. The intended 
>recipient is an instance of the service, chosen by the 
>outbound proxy. Calling whatever the outbound proxy does 
>"retransmission" is kind of pointless, since prohibiting it 
>just yields failure. (The only alternative would be to include 
>two different LOs, one low-res one for routing and one high- 
>(3) destination routing: the request has an AOR like 
>[email-masked] . The recipient is any node in the 
>domain, chosen by whatever logic the company has implemented.
>
>
>Henning
>
>> RFC 4119 http://www.ietf.org/rfc/rfc4119.txt says "
>> I believe that the main problem lies in the fuzzy 
>description of what 
>> a recipient actually is. To make things worse, in some cases the 
>> identity of the recipient is not known by the sender and 
>hence we are 
>> talking only about a symbolic description (such as emergency 
>services 
>> network, SIP routing infrastructure) rather than specific entities.
>>
>> started to go along this path by creating "symbolic" descriptions of 
>> the recipient (with the definition of the "Location-Routing-Allowed"
>> token).
>>
>>
>> something from their work (given that it is quite successful). They 
>> did three things:
>>
>> * Logos -- designing something suitable for location distribution 
>> would be very important to get users to understand the policies.
>>
>> If some other entities "listen" to the conversation then they should 
>> be considered as being not the intended recipient and therefore they 
>> regulation (i.e., it does not matter what we put into the policies; 
>> they will be ignored). For the other examples we do not yet have an 
>> indication whether anyone would be using SIP for them at all. The 
>> famous "pizza delivery" example is quite good here. I do get the 
>> impression that for finding the right pizza place folks are less 
>> interested in using SIP - location based routing but rather a 
>> Web-based Search Engine.
>> In case someone would use LoST for this then the privacy problems 
>> would be solved as well (as we don't use identity information of the 
>> client in the LoST query). So, for the cases where the 
>recipient isn't 
>> really known (the emergency services case, the pizza 
>delivery case) we 
>> could just apply the same mechanism as we did with the 
>Service URN -- 
>> it essentially defines the context. Hence, I would put as 
>the intended 
>> recipient something like 'urn:service:local.pizza' in there (inline 
>> what is being proposed with

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Nov 2008 08:42:48 -0500

Right now, there is little (to put it charitably...) deployment of  
GEOPRIV, and even less outside the ECRIT realm. Thus, we have to  
speculate. My general hunch would be to replace "retransmission" with  
something like

- destination AOR only ([email-masked])

- disclose to destination domain only (@aaa.com)

- service-related disclosure (AAA may disclose to Bob's Towing and  
Salvage)

- any business partner of the destination AOR (AAA may disclose to AAA  
Auto Insurance)

- public (recipient can post this on a public web page or display this  
on a Jumbotron on Times Square)

I suspect that CDT or privacy-focused organizations can help us define  
this better. The goal should be to align this to common privacy  
practices elsewhere, since lawyers and software developers understand  
those. Making up whole new systems for niche applications is unlikely  
to get us far.

Henning

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 14 Nov 2008 11:42:47 -0500

It seems to me that in a commercial context there are three categories  
of recipients that are relevant from a user perspective: the recipient  
(an individual or an organization), the recipient's business  
affiliates, and third parties with no relationship to the recipient.  
Any further granularity is likely to be overkill for most people. Even  
the middle category (affiliates) might be unnecessary, although  
privacy lawyers will argue that the existence of a contract between  
the recipient and an affiliate is material because it allows the  
recipient to impose constraints on how the affiliate can use the  
location information it receives. So the fact that AAA has a contract  
with Bob's Towing means that I as a user who trusts AAA should be more  
willing to trust my location information to Bob's Towing.

Some of the examples below go beyond the notion of expressing to whom  
location information should be retransmitted to also include why the  
information is retransmitted (I think this is also Hannes' idea of  
"context"). The destination AOR, destination domain, and public  
examples only speak to the "who" question. The other two incorporate  
the notion of the purpose of the retransmission -- service-related or  
business partnership.

While the ability to formalize and limit the purpose or context of the  
disclosure in rules is attractive, it seems somewhat impossible given  
that the reasons for a retransmission are limitless, and the user has  
minimal ability to know the options in advance. For example, AAA's  
services might require retransmission to BBB Insurance for billing,  
retransmission to BBB Insurance for future marketing purposes,  
retransmission to the local DMV for statistics-gathering, and multiple  
other purpose/recipient combinations. While it would be useful for  
some users to be able to express their preferences about each of  
these, I'm skeptical that enough people would find this valuable to  
make it worth the effort of augmenting the "who" with the "why." The  
[recipient | affiliates | others] choice probably suffices. Plus, for  
commercial LRs at least, merely adhering to the user's preferences  
about who can receive location information is probably going to be a  
big step in itself, without even getting to the question of allowing  
users to designate which retransmission purposes are allowed.

Lately I have been thinking about this from an advertiser's  
perspective, where the choices for users are even coarser (e.g., a  
blanket yes/no on whether any user data can be collected to target  
ads), so perhaps I'm jaded. But I think introducing the notion of  
context might be more trouble than it's worth.

Alissa
Center for Democracy & Technology

On Nov 12, 2008, at 8:42 AM, Henning Schulzrinne wrote:

> speculate. My general hunch would be to replace "retransmission"  
> with something like
>
> - any business partner of the destination AOR (AAA may disclose to  
> AAA Auto Insurance)
>
> - public (recipient can post this on a public web page or display  
> this on a Jumbotron on Times Square)
>
> I suspect that CDT or privacy-focused organizations can help us  
> define this better. The goal should be to align this to common  
> privacy practices elsewhere, since lawyers and software developers  
> understand those. Making up whole new systems for niche applications  
> is unlikely to get us far.
>
> Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Nov 2008 23:09:08 -0500

Thanks for your real-world perspective. From my perspective, starting  
simple with a three-choices "who" designation makes sense. This is  
also less likely to yield misunderstandings and surprises, either as  
disclosure or class-action lawsuits.

Henning

On Nov 14, 2008, at 11:42 AM, Alissa Cooper wrote:

> It seems to me that in a commercial context there are three  
> categories of recipients that are relevant from a user perspective:  
> the recipient (an individual or an organization), the recipient's  
> business affiliates, and third parties with no relationship to the  
> recipient. Any further granularity is likely to be overkill for most  
> people. Even the middle category (affiliates) might be unnecessary,  
> although privacy lawyers will argue that the existence of a contract  
> between the recipient and an affiliate is material because it allows  
> the recipient to impose constraints on how the affiliate can use the  
> location information it receives. So the fact that AAA has a  
> contract with Bob's Towing means that I as a user who trusts AAA  
> should be more willing to trust my location information to Bob's  
> Towing.
>
> Some of the examples below go beyond the notion of expressing to  
> whom location information should be retransmitted to also include  
> why the information is retransmitted (I think this is also Hannes'  
> idea of "context"). The destination AOR, destination domain, and  
> public examples only speak to the "who" question. The other two  
> incorporate the notion of the purpose of the retransmission --  
> service-related or business partnership.
>
> While the ability to formalize and limit the purpose or context of  
> the disclosure in rules is attractive, it seems somewhat impossible  
> given that the reasons for a retransmission are limitless, and the  
> user has minimal ability to know the options in advance. For  
> example, AAA's services might require retransmission to BBB  
> Insurance for billing, retransmission to BBB Insurance for future  
> marketing purposes, retransmission to the local DMV for statistics- 
> gathering, and multiple other purpose/recipient combinations. While  
> it would be useful for some users to be able to express their  
> preferences about each of these, I'm skeptical that enough people  
> would find this valuable to make it worth the effort of augmenting  
> the "who" with the "why." The [recipient | affiliates | others]  
> choice probably suffices. Plus, for commercial LRs at least, merely  
> adhering to the user's preferences about who can receive location  
> information is probably going to be a big step in itself, without  
> even getting to the question of allowing users to designate which  
> retransmission purposes are allowed.
>
>> understand those. Making up whole new systems for niche  
>> applications is unlikely to get us far.
>>
>> Henning
>
>
>
>
>
>
>
>