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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Sat Nov 08 2008 - 12:29:47 EST

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
Received on Sat, 8 Nov 2008 12:29:47 -0500

This archive was generated by hypermail 2.1.8 : Sat Nov 08 2008 - 16:35:42 EST