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

2. Mar 10 20042 The Origins of Ubiquitous Computing What’s 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. Mar 10 20043 The Origins of Ubiquitous Computing

4. Mar 10 20044 Emerging Examples of Ubicomp Never Get Lost Find Friends Emergency Response

5. Mar 10 20045 “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 they’re checking up on you…sort 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 don’t 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. Mar 10 20046 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 hasn’t 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. Mar 10 20047 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. Mar 10 20048 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)” The Origins of Ubiquitous Computing Research at PARC in the Late 1980s Weiser, Gold, Brown Make it easy to share: the right information with the right people (or service) at the right time

9. Mar 10 20049 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. Mar 10 200410 End-User Privacy Needs Value proposition Simple and appropriate control and feedback Plausible deniability Limited retention of data Decentralized architectures Special exceptions for emergencies Alice’s Location Bob’s Location

11. Mar 10 200411 How to Design for Privacy? Given this design space, how to cover them well? Five Pitfalls in Designing for Privacy [PUC 2004]

12. Mar 10 200412 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. Mar 10 200413 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. Mar 10 200414 Lacking Coarse-Grain Control Designs should not forego an obvious, top-level mechanism for halting and resuming disclosure “[T]raveling 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 user’s mind that it is doing what they think it is

15. Mar 10 200415 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. Mar 10 200416 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 ABC – Works indoors and in urban canyons – No special equipment – Privacy-sensitive – Rides the WiFi wave

17. Mar 10 200417 PlaceLab ~52000 Nodes (3Megs)

18. Mar 10 200418 PlaceLab ~500 Nodes

19. Mar 10 200419 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. Mar 10 200420 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. Mar 10 200421 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. Mar 10 200422 Confab Architecture InfoSpace Diary InfoSpace Diary LocNamePlaceLabTourguideFind FriendMiniGis How to make users aware of and be able to control the flow of personal info? Request

23. Mar 10 200423 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. Mar 10 200424 Access Notifications People

25. Mar 10 200425 Access Notifications Services

26. Mar 10 200426 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. Mar 10 200427 Continuous Discrete Push Tourguide E911 PullFind Friend 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. Mar 10 200428 Continuous Discrete Push ??? PullAccess Notifications Design Space PlaceBar

29. Mar 10 200429 Confab Architecture InfoSpace Diary InfoSpace Diary LocNamePlaceLab Tourguide Find Friend MiniGis How to control what happens to your info once it leaves your InfoSpace? Access Pull Push

30. Mar 10 200430 Privacy Tags Digital Rights Management for Privacy –Like adding note to email, “Please don’t forward” –Notify address- notify-abc@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. Mar 10 200431 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 requestor’s side)

32. Mar 10 200432 Application Developer Support Want to make it easy for app developers too Extensibility through chainable operators Programming Support Debugging Operators Active Properties In Operators InfoSpace Diary InfoSpace Diary Out Operators On Operators Garbage Collect Coalesce Periodic Reports Invisible Enforce Access Check Privacy Tag

33. Mar 10 200433 Application Developer Support ConfabClient –Java client-side API for accessing InfoSpaces –add, remove, query Active Properties –Stores and can automatically update values localuser.location localuser.activity localuser.name OnDemandQuery PeriodicQuery Static Berkeley, CA Busy Jason

34. Mar 10 200434 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) #Classes Lines of codeComments Confab 320 1700028000 PlaceLab 10 800500 MiniGis 15 30002000 Shared Libs 230 1200015000

35. Mar 10 200435 Putting it Together Lemming Location-enhanced Messenger

36. Mar 10 200436 Putting it Together Lemming Location-enhanced Messenger

37. Mar 10 200437 Putting it Together BEARS Emergency Response Server Field studies and interviews with firefighters [CHI2004] Finding victims in a building –“You bet we’d 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. Mar 10 200438 Putting it Together BEARS Emergency Response Server Trusted third party (MedicAlert++) Data Sharer Location Building BEARS Service Link 1 2 Trusted BEARS Third- Party Trusted BEARS Third- Party Location 3 4 Medic Alert++ Medic Alert++ Loc “ABC” On Emergency

39. Mar 10 200439 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. Mar 10 200440 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. Jason I. Hong jasonh@cs.berkeley.edu http://guir.berkeley.edu/confab G r o u p f o r User Interface Research University of California Berkeley Thanks to: DARPA Expeditions Intel Fellowship NSF ITR Siebel Systems Fellowship PARC Intel Research http://placelab.org

42. Mar 10 200442 Backup Slides

43. Mar 10 200443 Five Pitfalls

44. Mar 10 200444 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. Mar 10 200445 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. Mar 10 200446 #1 – Obscuring Potential Flow Users can make informed use of a system only when they understand the scope of its privacy implications

47. Mar 10 200447 #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. Mar 10 200448 #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. Mar 10 200449 #4 – Lacking Coarse-Grain Control Designs should not forego an obvious, top-level mechanism for halting and resuming disclosure “[T]raveling 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. Mar 10 200450 #5 – Inhibiting Established Practices Designs should not inhibit users from transferring established social practices to emerging technologies 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." 1. University and Ramona 2. Palo Alto 3. Custom… 9.Ignore for now