1. natural language assisted by a privacy rule guide tool (text processing tool)
2. structured list tool

These two methods were compared with the privacy rule being created in natural language in a unguided fashion.

Questions

Would the system design support exceptions?

The system will support the ability to create policies including exceptions or based on exceptions

How to match the policy with precise legal language?

A specialization tool to be able to parse the language as defined by legal experts. for example, the use of the word "may" could be defined and controlled by legal experts.

Is it possible for users to try to negociate privacy policy with corporations?

Collaboration with P3P research group at CMU on such possibility.

Relationships between rules?

Develop policy critic (analyze a single rule then pair of rules and also multiple rules across policy)

Putting People in their Place: An Anonymous and Privacy-Sensitive Approach to Collecting Sensed Data in Location-Based Applications
Karen P. Tang, Pedram Keyani, James Fogarty, Jason I. Hong

Privacy is generally treated as a fidelity tradeoff in the context of user-centric application.

What about location-centric applications?

This study took for exemple, a commercial application Zipdash that uses mobile phones reports GPS information for traffic purpose

Zipdash: Use Fidelity tradeoff?

it would not work for this application and for similar location-centric application. If the location information become less precise, then the location service may become unusable.

Need for a new way to protect privacy while providing location-centric service: Hitchhiking system

Project Hitchhiker

Key: Location is the entity of interest

Hitchhiking approach to Zipdash

Only reports GPS location for place of interests

Exemple: Coffee shop

1. device senses wifi location
2. anonymously reports wifi data to server
3. infers room availablility

3 out of 7 aspects of the Hitchhiker system were presented

Client Computation

Standard approach: always track
Hitchhiker solution: only reports when in location of interest (Ex: meeting room in a corporate building)

Location spoofing

problem: addition of fake location to be tracked (private office described as meeting room)
defense: location of interest approval by the user

Link identifiers to a person

Problem: service can link identifiers of location to a person
Solution: do not rely on server provided identifiers but on sensed physical identifiers (ex: Wi-Fi Mac Address rather than location identification stored in location service)

Other threats:

• Query anonymity
• Live reports vs. Offline
• Transport Layer attack
• Denial of Service attack
• Timing-based attack

Conclusions & Questions

The Hitchhiker system assume minimum trust level of the location service provider.
One of the questions was whether malicious clients were more of a issue that malicious servers.
The researchers presented two mechanisms to limit the impact of malicious clients on the Hitchhker:

• Use IP address to prevent many places from being reported in a short time.
• Seed databased with false data (non-existent MAC address) and ban reports that include false identifiers.

One attendee made the remark that even though the system may not solve all the issue on the client side, it is often better to limit the role of the location service (server) in the process.