Re: [Geopriv] Privacy of Location Information: The IntendedRecipient

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Wed Nov 12 2008 - 06:32:32 EST

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
>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 plumber@acme.com is the same person as
>joe@acme.com if acme.com has a user translation mechanism, but
>is not the same as recipient as carpenter@acme.com.
>
>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
>divorce@1-800-lawyer.com . The recipient is any node in the
>domain, chosen by whatever logic the company has implemented.
>
>
>Henning
>
>On Nov 6, 2008, at 7:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>
>> 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 "
>> other parties. When the value of this element is 'yes',
>>
>> 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:bob@example.com">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
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 12 Nov 2008 13:32:32 +0200

This archive was generated by hypermail 2.1.8 : Wed Nov 12 2008 - 06:35:44 EST