An Architecture for PrivacySensitive Ubiquitous Computing

1
An Architecture for Privacy-Sensitive Ubiquitous
Computing
G r o u p f o r User Interface Research
University of California Berkeley

• Jason I. Hong

2
The Origins of Ubiquitous Computing

• Whats wrong with Personal Computers?
• Too complex and hard to use
• Too demanding of attention
• Too isolating from other people
• Too dominating of our desktops and our lives
• Ubiquitous Computing Project at Xerox PARC
• Advances in wireless networking, sensors, devices
• Observations of how people use tools in practice
• Make computers a natural part of everyday
  interactions

3
The Origins of Ubiquitous Computing
4
Emerging Examples of Ubicomp

• Never Get Lost
• Find Friends
• Emergency Response

5
But What About My Privacy?

• Never Get Lost
• You walk past a restaurant and your cellphone
  rings with the specials of the day
• Find Friends
• Family is already very close to you, so if
  theyre checking up on yousort of already
  smothering and this is one step further.
• It could tell when you were in the bathroom,
  when you left the unit, and how long and where
  you ate your lunch. EXACTLY what you are afraid
  of.
• Emergency Response
• I dont see how a government or an organization
  will not come up with an excuse to use location
  info for another purpose.

Flood of Location-Based Spam
Never Hide From Friends and Co-Workers
Constant Surveillance
6
Our Research in Ubicomp Privacy

• Fundamental Tension
• Ubiquitous Computing can be used for great
  benefit
• Ubiquitous Computing can be used for great harm
• Privacy may be greatest barrier to long-term
  success
• Why hasnt this been addressed yet?
• Privacy an issue since inception, but little has
  been done
• Has to address many issues simultaneously
• Social and Organizational, Interaction Design,
  Technical
• My approach
• What are the privacy concerns in ubicomp?
• What is good interaction design for privacy?
• What are better ways of building
  privacy-sensitive apps?

7
What is Privacy?

• Lots of perspectives on privacy
• US Constitution, UN Decl. Human Rights,
  Hippocratic Oath
• Influenced by Legal, Market, Social, and
  Technical forces
• Privacy is not just Orwell
• From Big Brother to Little Sisters
• Media sensationalization of worst-case scenarios
• Privacy is not just computer security
• Adversaries? Friends, family, co-workers,
  acquaintances
• Anonymity? Friends already know your identity
• Secrecy? We share personal info with friends
  all the time
• Damage? Risk may be undesired social obligations
• I am approaching privacy from an HCI perspective

8
An HCI Perspective on Privacy

• The problem, while often couched in terms of
  privacy, is really one of control. If the
  computational system is invisible as well as
  extensive, it becomes hard to know
• what is controlling what
• what is connected to what
• where information is flowing
• how it is being used
• what is broken (vs what is working correctly)

• Make it easy to share
• the right information
• with the right people (or service)
• at the right time

The Origins of Ubiquitous Computing Research at
PARC in the Late 1980s Weiser, Gold, Brown
9
What are End-User Privacy Needs?

• Lots of speculation about privacy, little data
  out there
• Analyzed survey of 130 people on ubicomp privacy
  prefs
• Analyzed nurse message board on locator systems
• http//allnurses.com
• Examined papers describing usage of ubicomp
  systems
• Examined existing and proposed privacy protection
  laws
• EU Directive, Location Privacy Act 2001, Wireless
  Privacy Act 2004
• Interviewed 20 people on various location-based
  services
• Did not mention the word privacy unless they
  did first

10
End-User Privacy Needs

• Value proposition
• Simple and appropriate control and feedback
• Plausible deniability
• Limited retention of data
• Decentralized architectures
• Special exceptions for emergencies

Alices Location
Bobs Location
11
How to Design for Privacy?

• Given this design space, how to cover them well?
• Five Pitfalls in Designing for Privacy PUC 2004

12
Obscuring Actual Flow

• Users should understand what information is being
  disclosed to whom

Who is querying my location? How often?
Requestor informed of disclosure Requestee sees
each request
13
Configuration over Action

• Designs should not require excessive
  configuration to manage privacy
• Right configuration hard to predict in advance
• Make privacy a natural part of the interaction
  flow

14
Lacking Coarse-Grain Control

• Designs should not forego an obvious, top-level
  mechanism for halting and resuming disclosure
• Traveling employees may want their bosses to
  be able to locate them during the day but not
  after 5 p.m. Others may want to receive coupons
  from coffee shops before 9 a.m. on weekdays but
  not on weekends when they sleep in. Some may want
  their friends alerted only when they are within
  one mile, but not 10 miles.
• Protecting the Cellphone User's Right to Hide
• New York Times Feb 5 2004

Did I set it right? How do I know?
Simple, leaves no doubt in users mind that it is
doing what they think it is
15
How to Build Applications Better?

• A toolkit providing UI and systems support, to
  simplify construction of privacy-sensitive
  ubicomp apps
• Cover the end-user privacy needs
• Embody good interaction design principles wrt
  privacy
• Be useful for application developers
• Context Fabric
• Architecture and suite of mechanisms for managing
  privacy
• Prevent Strong guarantees on your personal
  data
• Avoid Better user interfaces for managing
  privacy
• Detect Finding over-monitoring or accidental
  disclosures
• Will go over key architectural points

16
Locality

• Keep personal data close to end-users
• Move from centralized systems to decentralized
  ones
• Capture, store, and process personal data on my
  computer
• PlaceLab

• Works indoors and
• in urban canyons
• No special equipment
• Privacy-sensitive
• Rides the WiFi wave

17
PlaceLab
52000 Nodes (3Megs)
18
PlaceLab
500 Nodes
19
Locality

• MiniGis Server for processing location locally

Country Name United States Region Name
California City Name Berkeley ZIP Code
94709 Place Name Soda Hall Lat Lon 37.8756,
-122.25711
20
Locality

• MiniGis Server data sources
• USGS State Gazetteer
• Names in USA
• 2m records 650 megs
• States, Cities, Places
• Places hardest to get
• Airports schools useful, lava, quicksand,
  hammocks less so
• 3 undergrads scouring Berkeley
• Research opportunity in open, distributed naming
  of places

• GEOnet Names Server
• Names outside USA
• 5.5m records 700megs
• Regions, Cities, Places

21
InfoSpace Diary

• InfoSpace stores your personal information
• Static info, like name and phone
• Dynamic info, like current location and activity
• Runs on your personal device or on a trusted
  service
• Local sources (ex. PlaceLab) can update dynamic
  info
• Can choose to expose different parts to different
  people services

22
Confab Architecture
Request
How to make users aware of and be able to
control the flow of personal info?
23
Observations on Disclosure Prefs

• Visibility and control without overwhelming
  end-users?
• Who is requesting information is most important
  factor
• Either I trust someone with my information or I
  don't.
• I trust the person to know how to exercise
  discretion.
• Time is an essential aspect for maintaining
  control
• Work people can know my information during work
  hours. Home/SO people can know my information
  always.
• Can set prefs before, during, or after a request
• During case easy to understand, but can overwhelm
• After case easy to setup, but can lead to
  accidental disclosures

24
Access Notifications People
25
Access Notifications Services
26
Access Notifications

• Initial Evaluations
• Iterated with 7 people for understandability and
  reactions
• Ex. Find friend, location-enhanced tourguide,
  emergency response
• Results
• For most part, worked well (but still too much
  text)
• Some distinctions in how often information is
  shared

Giving a GPS location once or twice does not
provide enough information for an invasion of
privacy but if GPS location is shared every 2
seconds, there is a potential for an invasion of
privacy. No need for continuous update of
location. Only in a race or a marathon (where
staying on track is essential) would continuous
update be helpful.
27
Users Conceptual Model
Emergency Response
I continuously share personal info with another
person or service
Others request personal information from me
I send personal information to others
28
Design Space

• PlaceBar

29
Confab Architecture
Find Friend
Pull
Access
Tourguide
Push
Access
How to control what happens to your info once it
leaves your InfoSpace?
30
Privacy Tags

• Digital Rights Management for Privacy
• Like adding note to email, Please dont forward
• Notify address - notify-abc_at_cs.berkeley.edu
• Time to live - 5 days
• Max number of sightings - last 5 sightings of my
  location
• Libraries for making it easy for app developers
• Requires non-technical solutions for deployment
• TrustE, Consumer Reports, Amazon ratings

31
Architectural Analysis

• Prevent
• Capture and process personal information locally
• PlaceLab, MiniGis
• Minimizes risk of mission creep (ex. SSNs)
• Avoid
• Interfaces for feedback and control over personal
  information
• Access Notifications / PlaceBar
• Detect
• Finding problems
• Access Notifications
• Privacy Tags (processed on requestors side)

32
Application Developer Support

• Want to make it easy for app developers too
• Extensibility through chainable operators

Programming Support Debugging Operators Active
Properties
InfoSpace Diary
Invisible Enforce Access
Check Privacy Tag
On Operators
Garbage Collect Coalesce Periodic Reports
33
Application Developer Support

• ConfabClient
• Java client-side API for accessing InfoSpaces
• add, remove, query
• Active Properties
• Stores and can automatically update values

Berkeley, CA
localuser.location
OnDemandQuery
localuser.activity
PeriodicQuery
Busy
localuser.name
Static
Jason
34
Implementation

• Confab, PlaceLab, MiniGis
• Java 1.5, Tomcat Web Server, MySql, Jaxen XPath
• Data
• WiFi from wigle.net and undergrads
• MiniGis from USGS, GeoNET, and undergrads
• 35 megs of data (20 megs of place data)

35
Putting it TogetherLemming Location-enhanced
Messenger
36
Putting it TogetherLemming Location-enhanced
Messenger
37
Putting it TogetherBEARS Emergency Response
Server

• Field studies and interviews with firefighters
  CHI2004
• Finding victims in a building
• You bet wed definitely want that.
• It would help to know what floor they are on.
• But emergencies are rare
• How to balance privacy constraints with utility
  when needed?

38
Putting it TogetherBEARS Emergency Response
Server

• Trusted third party (MedicAlert)

Medic Alert
Loc
ABC
ABC
On Emergency
Data Sharer
1
Location
2
Link
4
Building BEARS Service
Trusted BEARS Third-Party
3
Link
Location
Link
39
Requirements Check

• Value proposition
• Simple and appropriate control and feedback
• Access Notifications (pull) and PlaceBar (push)
• Plausible deniability
• No action, Ignore for now, and Never Allow
  appear same
• Limited retention of data
• Privacy Tags, Automatic deletion of old data
• Decentralized architectures
• PlaceLab and MiniGis
• Special exceptions for emergencies

40
Conclusions

• Investigated ubicomp privacy from many
  perspectives
• Analysis of end-user needs / interaction design
  issues
• Context Fabric architecture for privacy-sensitive
  ubicomp
• Architecture and mechanisms for managing privacy
• Locality, InfoSpace Diary, Access Notifications,
  Privacy Tags
• Protection at physical, infrastructure, and
  application layers
• Evaluation with two applications
• Use technology correctly to enhance life. It is
  important that people have a choice in how much
  information can be disclosed. Then the technology
  is useful.

41
Thanks to DARPA Expeditions Intel
Fellowship NSF ITR Siebel Systems
Fellowship PARC Intel Research
G r o u p f o r User Interface Research
University of California Berkeley
http//placelab.org

• Jason I. Hong
• jasonh_at_cs.berkeley.edu
• http//guir.berkeley.edu/confab

42
Backup Slides
43

• Five Pitfalls

44
How to Design for Privacy?

• What are good privacy-sensitive user interfaces?
• Knowing what is needed does not say how to do it
  well

45
Five Pitfalls for Designers

• Understanding
• Obscuring potential information flow
• Obscuring actual information flow
• Action
• Configuration over action
• Lacking coarse-grained control
• Inhibiting established practices

46
1 Obscuring Potential Flow

• Users can make informed use of a system only when
  they understand the scope of its privacy
  implications

47
2 Obscuring Actual Flow

• Users should understand what information is being
  disclosed to whom

Who is querying my location? How often?
Requestor informed of disclosure Requestee sees
each request
48
3 Configuration Over Action

• Designs should not require excessive
  configuration to manage privacy
• Right configuration hard to predict in advance
• Make privacy a natural part of the interaction
  flow

49
4 Lacking Coarse-Grain Control

• Designs should not forego an obvious, top-level
  mechanism for halting and resuming disclosure
• Traveling employees may want their bosses to
  be able to locate them during the day but not
  after 5 p.m. Others may want to receive coupons
  from coffee shops before 9 a.m. on weekdays but
  not on weekends when they sleep in. Some may want
  their friends alerted only when they are within
  one mile, but not 10 miles.
• Protecting the Cellphone User's Right to Hide
• New York Times Feb 5 2004

Did I set it right? How do I know?
50
5 Inhibiting Established Practices

• Designs should not inhibit users from
  transferring established social practices to
  emerging technologies

• University and Ramona
• Palo Alto
• Custom
• 9. Ignore for now

Rather than getting an immediate ring, an
answering machine comes on the line and says,
"Lee has been motionless in a dim place with high
ambient sound for the last 45 minutes. Continue
with call or leave a message."