[Geopriv] Privacy of Location Information: The Intended Recipient

From: Tschofenig, Hannes (NSN - FI/Espoo) ^lt;hannes.tschofenig@nsn.com>
Date: Thu Nov 06 2008 - 07:59:27 EST

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

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

Interestingly enough, this definition does not match with what is said
      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
(For more discussion about context in the privacy environment see

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.,

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

Geopriv mailing list
Received on Thu, 6 Nov 2008 14:59:27 +0200

This archive was generated by hypermail 2.1.8 : Thu Nov 06 2008 - 08:01:06 EST