1. Introduction

The mobile Internet promises applications featuring rich content, comprising text, audio and streaming video in full color. Mechanisms of the mobile Internet both allow users to access Internet services and other server-based applications from mobile devices, and make new services possible, such as location-based and context-aware applications. Composite Capabilities/Preference Profile [CC/PP] is used to convey capability and preference information (CPI) when accessing Web resources to facilitate content adaptation to best fit the capabilities and preferences of the user agents and users. While mobile services can be of great use, privacy risks need to be considered as well. With these new protocols or services, personal data such as location data, CPI and further user attributes are transferred with messages and exposed at different nodes, such as the WAP gateway/proxy or the Origin Server’s site. Appropriate legal and technical data protection and privacy safeguards must be implemented.

At Ericsson and Karlstad University, we have investigated privacy and privacy risks in the mobile Internet, as well as technical means for enhancing the user's privacy. Particularly, we have analyzed how the P3P [P3P] protocol can be used to enforce the user’s control over the providing of CPI and location data.

2. The PiMI Prototype

In order to enforce self-determination, and to gain efficiency in ordering and transmission of personal data, CC/PP can be used in combination with P3P. These suggestions were tested within the PiMI prototype project.

2.1 Minimal Profile Conveyance

CPI is represented by means of a profile, which comprises a set of components. Each component is a placeholder for related attributes.

In [Nilsson et al. 2001], we suggest that the user define a minimal CPI profile, containing only information that she considers completely harmless, or where there is an understanding that this information may be necessary for some reason. This minimal profile can be used:

• for accessing non-P3P enabled web sites or web sites that do not meet the user's P3P privacy preferences
• for serving third party requests to the WAP Gateway for cached profiles (such as for WAP push content generation)
• for communication in the "safe-zone" before a P3P agreement (within the "safe-zone", however, no CPI is needed, so that a completely empty profile could be used instead)

The end user also has to define a full CPI profile to be used when there is a successful P3P agreement on a general basis, i.e. the site is P3P compatible, and the general information in the site’s P3P policy file suites the end user’s privacy preferences. All CPI attributes in this full profile must be agreed upon, i.e. there must be a corresponding P3P policy statement that corresponds to the end user's preferences for these attributes. Otherwise the CPI attributes will not be transmitted.

The WSP (Wireless Session Protocol) suspend and resume mechanisms can be used for retransmission of the data in the full profile that have been agreed upon.

2.2 Overview

Figure 1. PiMI Architecture

The PiMI system consists of both a proxy-based and a browser built-in P3P user-agent. The browser built-in user agent solution guarantees that the user has direct control over her privacy preferences. With the proxy-based solution, the user-agent’s communication during a P3P agreement is done from by an HTTP privacy proxy and thus takes place via wireline communication, which will reduce the number of round-trips over the air. However, as in this case the proxy has control over the user’s privacy preferences, it should be either under direct control of a trusted third party (TTP) or of the user (e.g., running on the user’s PC).

In this prototype, we only test for CPI information. However, the same principle can be used for any other kind of data to be transmitted from the device, e.g. location data, name, credit card number etc..

Both the browser built-in and proxy user-agents use the PiMI foundation classes that allow the end user to enter preferences from an HTML as well as a WML interface, and have them stored in flat files.

The comparison handler will retrieve the reference file according to the well-known location concept, find the policy file, for example the one described in [P3P & UAProf], and compare the general information (in this case access information). If there is a match, it will compare the data in the full profile, otherwise the data in the minimal profile. After this, it will either retrieve the web page, passing on the information agreed upon, or else warn the end user about the parts that failed, and ask whether she consents to providing the information anyway.

2.3 Results and Suggestions

The amount of attributes for which a P3P agreement has to be made widely exceeds the amount of attributes used in traditional web environments.

We realized that it is wise to use three categories for each CPI attribute:

• Minimal - this attribute is part of the minimal profile, and can be given away to any site
• Full - this attribute is part of the full profile, and can be given if the user’s preferences for this attribute match the site’s policy (i.e., the user gives her implicit consent)
• Never - this attribute will never be given away, without the end user's explicit consent, (i.e., the user is explicitly asked)

It is technically possible to have the end user define a range of profiles, and select among them before each transmission. However, there is a conflict between user friendliness and privacy friendliness. The principle tried in the PiMI project is one first step towards self-determination without disturbing the end user more than necessary.

2.4 Use Case

In this use case, we have an end user, Alice, who is willing to give away image capability, i.e. the fact that she can view images, and screen size, i.e. the size of the screen in pixels, in order to get a better experience when viewing a page. However, to some sites that she visits often, and to sites that will grant her access to all the information that they store, she may be willing to give away also the browser name, i.e. the name of the user agent, so that everything about the browser and its capabilities can be fetched by the origin server, and the browser version, i.e. the exact version as well. She never wants sites to know her name without asking first, even though it is stored in the device.

In the device, Alice has the following options:

• "I consider the following sites to be 'reliable': LIST OF SITES."
• "I also considers sites reliable under the following circumstances:"

"This is how I view my personal data:"

The choices above can be more granular, like "The version of my browser can be sent always, assuming it is not retained, to reliable sites assuming the recipient is only our-selves...", and so on. Making the conditions user-friendly is a challenge for usability experts, and will not be treated here.

When the agreement takes place, the first step is to decide whether or not the site is to be considered reliable. The next step is to match the data that is required in the policy, see [P3P & UAProf], and finally, the policy is matched with the preferences of the end user, and if the match goes through, Alice's data is sent. If not, Alice is asked whether she wants to submit the data anyway. This way, Alice is disturbed as little as possible, and her user-agent does what user-agents are for: handles her data according to her wishes until there is a mismatch.

3. Conclusion

A P3P Policy states: "If you would give me your data, I promise to...". The PiMI method uses P3P to day: "Give me your data, and I will...". The difference is efficiency, both in terms of lesser transactions, and in terms of less user input, which is of great importance when dealing with constrained devices. Thus, the method can be used both to enhance efficiency, and to enforce legal privacy requirements in terms of user consent.

References