Architectures of Privacy Protection

Protecting the privacy of a user while still providing a viable location-based service remains a large and complex task. Providing users with reassurances about the protection of their privacy is important. Privacy considerations in the area of location services will remain an important component that determines its success. It is likely that a better understanding of the area through research will help provide technological solutions that improve user experience or data protection. Similarly, legislative protections that enhance privacy will continue to develop as location services for the Internet become more prevalent. Once user preferences are understood and codified, the network architectures for enforcing these preferences need to be understood. How privacy is stored and enforced both affect the overall privacy architecture.

Each one of these architectures has the same four logical entities:

• The Rule Maker is the entity responsible for making the rules. Typically, the subject of the location information-the Target-also makes the decisions necessary to create the rules. The Rule Maker codifies the rules, possibly as a common-policy document, and makes them available to the Rule Holder.
• The Rule Holder stores rules. Usually, the Rule Holder provides an interface that allows the Rule Maker to modify the rules over time. The Rule Holder also makes rules available to the Rule Evaluator. In addition, Rule Holder is responsible for ensuring that rules are protected. Rules include information that could reveal private information about an individual; therefore, they are also subject to restrictions that ensure that only authorized entities can retrieve the information.
• The Rule Evaluator checks whether a specific request for location information is permitted. The Rule Evaluator acquires rules from a Rule Holder and evaluates those rules against a set of information about the request. The Rule Evaluator produces an authorization decision.
• The Rule Enforcer takes an authorization decision and either permits or blocks a request for location information. This role is usually assumed by an entity on the request path that can block requests that are not permitted.

The architectures concentrate on the delivery part of location. Architectural choices relating to the way that privacy rules are communicated, stored, and enforced are critical to providing a general and viable location service.The following description below outlines a number of options based on the four roles already identified. It can be seen that these options can coexist, which provides users with a choice about how their location information is used.

Minimal Architecture

Minimal Architecture Of Privacy Protection

The advantage of this architecture lies in its simplicity. The only protocol interface that needs to carry privacy-related information exists in the access network between the LIS (Location Information Server) and the device. This simplicity ensures a greater chance of success, both in terms of achieving deployment and in protecting privacy.

Centralized Rule Management

Architecture Of Centralized Rule Management

Privacy rules can be made accessible to the LIS over secure HTTP. The Device provides a URL to the LIS when it requests a Location URI and establishes a context. The LIS retains the role of Rule Evaluator and Rule Enforcer and, indeed, from the LIS's perspective the device appears to continue in the role of rule holder while, in fact, it is actually just a proxy for the centralized privacy profile manager. The interface provided to the user to apply updates to the profile can be as simple as an FTP or a web form. In some cases, proprietary tools are provided to assist in the management of rules. There are also protocols designed for the management of rules documents, such as XCAP, which can be used to more efficiently update rules. This architecture can be supported concurrently with the minimal architecture as explained above. The LIS only needs to be able to de-reference a URI to retrieve rules in addition to being able to accept rules directly from the device.

Delegating Rule Evaluation

Architecture Of Delegating Rule Evaluation

This architecture provides some additional protection to a user's privacy preferences. Because the Rule Evaluator role is delegated, the LIS does not gain access to the user's privacy rules. This additional protection may be desirable if the user does not trust the access network enough to provide this information. A benefit of this option is that the PPR already exists in the 3GPP architecture, which means that the same node can be used to make decisions for the cellular network and the Internet. This option can be provided to a user through the use of a PPR URI within the framework for HELD protocol. This URI type is not yet defined, but it could be used in place of a ruleset URI to request that the LIS use the PPR. Note that this logical architecture also supports an implementation where the device itself adopts the role of rule evaluator. It can do this by hosting the delegate URI itself. This allows a kind of hybrid implementation where the privacy holder role may be as per either of the first two models.

Privacy with a Presence Service

Architecture Of Privacy With A Presence Service

The presence service option is a special case of those architectures that rely on the LIS directly. In order to use the presence service in this manner, the user must provide rules to the LIS that authorize the presence service. This is an effective means of delegating the privacy roles to the presence service; the presence service now protects privacy before the request reaches the LIS.

Architecture Combinations

Combination Of Architectures

A combination of the different configurations is also possible if the privacy rules provided to the LIS include clients other than the presence service. A combination of the two is likely for special cases like i2 emergency, where the Rule Maker role is filled by legislation. Legislation is not always going to affect the presence service, only the LIS is guaranteed to fall within its jurisdiction.

The choice of architecture is left to a user of the service, the provider of their device, the operator of the service, or all of these in concert. How the choice is made depends on the requirements of user, and how they use location services. The form in which location is provided (by-value versus by-reference), the rules applied (or otherwise) to the acquisition of that location information by applications, and the need to associate any user identity with the location information are very dependent on circumstances. For this reason, and because the population and needs of users come and go arbitrarily within a given public Internet access network, the LIS function associated with those networks will need to be able to support all of the models described. Disparate services are able to concurrently interact with the LIS in different ways, each of which is best suited to that particular application. To support maximum flexibility, the mixture of models used at any given time must be made at the discretion of the user, with regard to any prevailing legal obligations for that operator.