Technical standards bodies that reuse the IETF’s work sometimes describe its method as creating reusable building blocks rather than whole-system architectures that are carefully tailored to specific environments. That approach has long reflected the variety of environments in which IETF protocols are required to operate. The real utility of a building block tends to surface only after reuse starts to snowball. HTTP provides an obvious example, since it’s been transporting much more than hypertext for a decade, and its success has spurred a generation of protocol designers who have reused the most portable elements of its design.
The work of the Geographic Location/Privacy working group (GEOPRIV WG) has always been a little different because the decision to create a new type of building block was not made in response to a specific technical need. In the case of GEOPRIV, the IETF’s leadership recognised a set of problems with a series of technical proposals around location: the first was that proposals ignored the privacy implications of the release of location data, and the second was that almost all existing security mechanisms were designed around individual protocols. With the creation of GEOPRIV, the Internet Engineering Steering Group (IESG) set out to charter a group that would focus as much on the privacy implications of the data transmitted as on the successful transmission of the data itself. Moreover, the IESG recognised early that data continually leaks from one protocol to another-for example, by moving from the Web to e-mail. Therefore, it charged the group with developing a system that worked both within and across many protocols.
Key Building Blocks
The work of the GEOPRIV WG is encapsulated by the diagram at the right from draft-ietf-geopriv-arch-00.
In this model, a location generator passes information about the location of a target (such as an individual with a mobile device) to a location server, where the rules for disseminating that information are applied. A new location object (LO) is then created and passed to location recipients. That location object reflects the information that the specific recipient is permitted to have and embodies the rules governing how the recipient can use the object.
There are a number of different kinds of rules that might be applied to the location information. One key type of rule describes whether the recipient may or may not retransmit the location object to other parties. The protocol used for that transmission has no effect on the permission. It does not matter whether the retransmission is by e-mail, instant message, or broadcast; the same rules apply in every case.
To give a concrete example, imagine for a moment that our target is a student with a laptop. The location generator could be a programme on the student’s laptop that derives information from a specific type of input, such as the Dynamic Host Configuration Protocol (DHCP) messages described in RFC 4776: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. The rule maker might be the individual student, the student’s parents, or even the student’s school. Assuming for a moment that the parents are the rule makers, they would determine to whom location information could be given, what granularity of information would be available, and whether or not those receiving the information could retransmit it to others. The parents might, for example, create a rule that would allow anyone to request and receive their child’s time zone information (useful for avoiding late-night calls) and to pass that information on to others. A second rule might allow precise data to be sent to requesting family members but limit the retransmission of that information to others.
The location object created after the rules have already been applied would contain the permitted data appropriate to the requester along with any specific privacy rules. Note that the rules that get created are always grants of permission, never of denial. If a rule grants access to time zone data to all, no rules can be applied later that restrict that access; the rules can only expand to include new data. This somewhat limits the form in which rules can be described, but it also ensures that if an externally referenced rule is not available when a location object is created, the resulting object has no data that would have been removed by a rule that is missing.
The format used for carrying this information-Presence Information Data Format Location Object (PIDF-LO)-is described in RFC 4119: A Presence-based GEOPRIV Location Object Format, RFC 5139: Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO), and RFC 5491: GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations and is an extension of the format used for carrying presence information for instant messaging buddy lists. However, instead of saying “available for chat,”? “busy,”? or “bored,”? the status element carries either geolocation (latitude, longitude, and altitude) or civic location (street address, town name, and so on) plus the usage rules and, optionally, the method by which the information was derived and the identity of the provider of the information. The extension of the PIDF “status”? element with these fields means that any presence-based system should be able to quickly and easily adapt to the GEOPRIV architecture. The system is not limited to presence systems, though, and any protocol that can carry an XML MIME [extensible markup language Multimedia Internet Message Extensions] type can carry a PIDF-LO object. That means applications for e-mail and the Web start off with an advantage for adopting GEOPRIV, since each already uses MIME to determine which external programmes or subroutines should handle specific content types.
Adaptability
Even within the IETF suite, there are protocols for which XML and MIME are not part of the available tool kit. Adapting the GEOPRIV architecture to those protocols presents a significant challenge. RFC 5580: Carrying Location Objects in RADIUS and Diameter, which describes the methods by which location objects can be carried in RADIUS and Diameter, is one recent document that shows how to apply the GEOPRIV model in a situation where PIDF-LO is simply too large to fit within the protocol’s current format. While movement between this format and the existing objects requires some translation, RFC 5580’s fidelity to the GEOPRIV model means that it matches the chartered aim of avoiding protocol-specific solutions despite introducing concepts such as “home network”? and “visited network,”? which were not present in the initial work. While the RADIUS bitmaps and PIDF-LO XML snippets may look very different, the boxes and arrows in the diagram still apply.
There are additional contexts that require GEOPRIV to be adaptable, including instances when not all of its boxes and arrows are present. One example is emergency services. One of the great driving forces for making location determination ubiquitous is the need to have it available for routing emergency services, but that same force may sometimes create tension in the GEOPRIV model. GEOPRIV is built around the idea that a rule maker should control access to information about the targets for which it is responsible. In most cases, that means that an individual should have the right to control access to information about that individual’s location.
By contrast, in emergency services, the laws of a local jurisdiction can and often do set rules that do not change with the desires of the individual. The jurisdiction becomes a kind of overriding rule maker, but one whose rules are not encoded with the location itself in a unified object such as a PIDF-LO. That means location systems must track the context (an emergency versus a nonemergency situation) in order to correctly apply the relevant rules.
In other words, in the context of an emergency, there may be tremendous temptation to skip all of the steps encompassed in the GEOPRIV model. While skipping those steps in an emergency situation may be required, there is some risk that doing so might lead to skipping those steps under normal conditions. To those not familiar with the privacy concerns that gave rise to GEOPRIV, the very first step of the GEOPRIV flow looks temptingly complete: location information flows from one party to another.
That may even be the case for those familiar with only some of GEOPRIV’s more recent work, in which much of the focus has been on protocols that provide location information to location generators. An example is the proposal for a “geo”? uniform resource identifier (URI), which aims to encode a location in a format that can be carried in the same protocol slots as a Web site reference or an e-mail address. With no identity information and no rules, this URI is not a location object. When combined with other information in an e-mail or on a Web site, though, it easily takes on that role. In draft-ietf-geopriv-geo-uri-02, the authors give an example location of geo:48.2010,16.3695,183, noting in the text that it’s the address of one of their offices. While this may be a combination of identity and location of which the authors are willing to permit unlimited distribution, we can only infer that information from its inclusion in an Internet-Draft (based on the draft’s boilerplate about redistribution). The geo URI itself gives us no way to know for sure; it’s merely a reference to a location without any rules for privacy and redistribution that make location objects survive context changes with that information intact.
The fact that location objects encode those rules means they can survive those context shifts, demonstrating a key benefit of GEOPRIV’s model. Retaining that benefit, regardless of the apparent simplicity of other choices, is necessary to the future success of services based on location, as well as to minimization of the privacy issues that could flow from their wide deployment and use.
Location-Specific Privacy Risks
While location-based services raise some privacy concerns that are common to all forms of personal information, in some instances many of those concerns are heightened, while others are uniquely applicable in the context of location information.
Location information is frequently generated on or by mobile devices. Because individuals often carry mobile devices with them, location information may be used to form a comprehensive record of an individual’s movements and activities. On one hand, other kinds of data, such as an individual’s medical records or bank statements, could, arguably, be considered more sensitive than location information, since they provide snapshots of an individual’s particular activities at any given moment or specific details about certain aspects of the person’s life. On the other hand, location information may be collected everywhere and at any time-often without explicit user interaction-and that information may potentially describe both what a person is doing and where the person is doing it. The fact that an individual’s mobile device location is obtained when the person is at a bank can reveal not only that the person was at the bank but also what time it was and which branch it was. Location-based services may allow for amassing such data points about an individual’s every movement, potentially spurring the creation of richly detailed profiles of individual behaviour.
The availability of location information may also allow an individual’s whereabouts to unwittingly become more public than the person desires, with potentially serious consequences. Location information could, for example, reveal that an individual was in a particular medical clinic or government building, leading to the possibility of the sharing of sensitive information about an individual that the person never meant to have shared. The ubiquity of location information may also increase the risk of stalking and domestic violence if perpetrators are able to use-or abuse-location-based services to gain access to location information about potential victims. Additionally, access to location information raises significant child-safety concerns as more and more children are in possession of location-aware devices.
Finally, location information is, and will continue to be, of particular interest to governments and law enforcers around the world. The existence of detailed records of individuals’ movements should not automatically facilitate the ability of governments to track citizens. Unfortunately, in some jurisdictions, laws dictating what government agents must do to obtain location data are either nonexistent or out-of-date.
Privacy Paradigms
Traditionally, it is the recipients of data who decide the extent to which an individual enjoys privacy protections on the Internet. Internet users may or may not be aware of the privacy practices of the entities with which they share data. Even if they are aware, they have generally been limited to making a binary choice between sharing or not sharing data with a particular entity. Internet users have not historically been granted the opportunity to express their own privacy preferences to the recipients of their data and to have those preferences honoured.
This paradigm is problematic because the interests of data recipients are often not aligned with the interests of data subjects. While both parties may agree that data should be collected, used, disclosed, and retained as necessary to deliver a particular service to the data subject, the data subject may not agree about how the data should otherwise be used. For example, in order to receive a newsletter, an Internet user may gladly provide an e-mail address for use by a Web-based service, but the person may not want the service to share that e-mail address with others, whereas the service might profit from such sharing. From the user’s perspective, the choice between providing the address for both purposes or not providing it at all is less than ideal.
The GEOPRIV model departs from this paradigm for privacy protection. As covered earlier, location information can be uniquely sensitive. And as siloed location-based services emerge and proliferate, they increasingly require standardized protocols for communicating location information between services and entities. Recognizing both of these dynamics, GEOPRIV gives data subjects the ability to express their choices with respect to their own location information rather than allowing the recipients of the information to define how it will be used. The combination of heightened privacy risk and the need for standardization compelled the GEOPRIV designers to shift away from the prevailing Internet privacy model, instead empowering users to express their privacy preferences about the use of their location information.
The GEOPRIV work does not, by itself, offer technical means through which it can be guaranteed that location-privacy rules will be honoured by recipients. The privacy protections in the GEOPRIV architecture are largely the results of recipients of location information being informed of relevant privacy rules and of the need to use that information in accordance with those rules. The distributed nature of the architecture inherently limits the degree to which compliance can be guaranteed and verified by technical means.
By binding privacy rules to location information, however, GEOPRIV provides valuable information about users’ privacy preferences so that nontechnical forces-such as legal contracts, government consumer protection authorities, and marketplace feedback-can better enforce privacy preferences. For example, in a growing number of countries, if a commercial recipient of location information violates the location rules that are bound to the information, the recipient can be charged with violating consumer or data protection laws. When rules are not tied to location information, consumer protection authorities are less able to protect consumers whose location information has been abused.
Location information is available through more interfaces and devices than ever before, yet because of the sensitivity of location information, that relationship requires a model for conveyance that has privacy protections built in. Binding privacy rules to location information requires recipients of location information to confront privacy head-on. The building blocks GEOPRIV has created provide the materials to create adaptable frameworks that pave the way for privacy-protective location conveyance.