Context Fabric: Privacy Support for Ubiquitous Computing

1. Group for User Interface Research University of California Berkeley Context Fabric:Privacy Support for Ubiquitous Computing Jason I. Hong

2. Ubiquitous Computing Scenario • Diversity of devices • Mobile and embedded • Many kinds of interactions • Many kinds of sensors • All networked together

3. Privacy and Ubicomp • Tension: information can be used for great benefit and great harm • Privacy is the most often-cited criticism of Ubicomp • “The Boss That Never Blinks” [San Jose Mercury News 1992] • What is new here is the scale of Ubicomp • Past: costly to collect, store, and use info • Future: everywhere, always on, far easier to collect data

4. Problem • Hard to create privacy-aware Ubicomp systems • Hard to analyze privacy • What should the privacy goals be? • Which system interactions should we focus on? • Hard to implement privacy-aware systems • What are the basic abstractions? • What are the privacy mechanisms?

5. Solution Overview • Approximate Information Flows • Framework for analyzing privacy in terms of info flow • Minimize flow out of sensitive data, maximize flow back in of how that data is used • Context Fabric, infrastructure for privacy-aware apps • InfoSpaces, repositories of personal data • Operators, reusable mechanisms for managing info flow • Evaluation through building apps • Person Finder & Building Emergency Response

6. Talk Outline • Motivation • Privacy and Managing Information Flows • Architectural Overview of Context Fabric • Applications Built with Context Fabric • Conclusions

7. Defining Information Privacy • Different kinds of privacy • Territorial, Bodily, Communications, Information • Information Privacy conflates many issues • Security, Confidentiality, Anonymity • Defining Information Privacy [Westin 1967] • “Privacy is the claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others” • My work is on providing end-users with greater control and understanding

8. Out In Out In Privacy & Managing Information Flows • Control & understanding hard due to how info flows • Examples • Collecting info without person knowing • Sharing (or selling) info without person knowing • Design Goal: Manage information flows by • Minimizingflow of outgoing sensitive data (control) • Maximizingflow of incoming data about use (understanding) You Service Providers

9. Example of Managing Information Flow • Lines at Museums • Current Events • Recommendations • Route Finder Bob, Provides Real-time Tourist Info Alice, a Tourist Carol, a Tour Operator • Sets up tour packages • Wants demographics • Wants places visited • First time touring France • PDA, GPS, maps, wireless

10. Example of Managing Information Flow Bob, Provides Real-time Tourist Info Alice, a Tourist • Reads a review • Finds Bob's website • Skims privacy policy • Decides to try

11. Example of Managing Information Flow Bob, Provides Real-time Tourist Info • Basic service • Demographics + City • Events, museum lines • Gold service • Demographics + GPS • Recs, route finder • Will sell aggregated data Alice, a Tourist

12. Example of Managing Information Flow Bob, Provides Real-time Tourist Info Alice, a Tourist • Opts for Basic Service • Logs outgoing data

13. Example of Managing Information Flow Bob, Provides Real-time Tourist Info • Lower Precision • Aggregate • Garbage Collect • Log outgoing Carol, a Tour Operator

14. Approximate Information Flows • Approximate Information Flows is a framework for analyzing information flows in Ubicomp systems • Two questions: • When does data flow to others? • Strategies for protecting that data?

15. When Does Data Flow to Others • Collection, when data is gathered • Ex. When Alice gets her location data (ex. GPS) • Access, when data is first requested or provided • Ex. Alice sends her location data to Bob • Second use, sharing data after access • Ex. Bob shares data with Carol

16. Strategies for Protecting Data • Prevent privacy violations from occurring • Ex. Refuse request, Turn off device • Minimizing flow out of sensitive data • Avoid potential privacy risks • Ex. Lowering precision, Notification • Minimizing flow out & maximizing flow in • Detect any privacy violations • Ex. Internal and Third party audits of Bob and Carol • Maximizing flow in about how data is used • I am focusing on Avoidance & Detection

17. Social Market Legal Technical & Non-Technical Solutions • Privacy cannot be managed by Technology alone • Appropriate Technology can make it easier for other forces to act Lessig, “Architecture of Privacy” Privacy Technology

18. Talk Outline • Motivation • Privacy and Managing Information Flows • Architectural Overview of Context Fabric • Applications Built with Context Fabric • Conclusions

19. Assumptions • Pessimistic case: Designers and service providers don't care or are trying to violate users' privacy • My work is on Optimistic case: Designers and service providers trying to deploy privacy-aware apps • Minimize privacy risks (perceived and real) for their users • Market, Social, Legal Forces support optimistic case • Market: Toysrus.com • Social: Code of ethics for Doctors • Legal: EU Data Protection • Ex. AT&T m-life uses privacy as a key selling point

20. Building Privacy-aware Apps Today • P3P (Platform for Privacy Preferences) • Focuses on communicating policy and obtaining consent • Privacy Mirrors • GUIs for helping people understand how system is tracking • No control over how information flows or how to build • Cricket Location Beacons • Does not deal with sharing of information • Ubicomp infrastructures [ParcTab system, Context Toolkit] • No support for privacy or end-user control • Today, would have to be done in ad hoc manner

21. Architectural Requirements • Easy to create privacy-aware Ubicomp apps • Low barrier to entry • Make it simple for programmers, admin, end-users • Easy to add or modify app-specific privacy controls • Easy for end-users to control and understand • Easy to share info at level users comfortable with

22. Operators High-Level Architecture Bob's Information Tourguide App Bob's Service Alice's Information Loc (GPS) GPS

23. High-Level Architecture Bob's Information Tourguide App Bob's Service Operators Alice's Information Loc (City) Loc (City) Loc (GPS) Loc (GPS) GPS

24. High-Level Architecture Bob's Information Tourguide App Bob's Service Events Operators Alice's Information Tuple Loc (GPS) GPS

25. InfoSpaces Name • Key abstraction is the InfoSpace • Represents data about a single entity • Like an object with dynamic properties • Decentralize data, put in user’s hands • Implemented as a TupleSpace • InfoSpaces contain Tuples • Represents single piece of data • Sensors & Apps can add or query Tuples • Default value is UNKNOWN • Tuples can point to other InfoSpaces Alice’s InfoSpace Loc Activity Room 525’s InfoSpace Temp Sound Level

26. Tuples • Metadata • Data type (ex. "location") • Data format (ex. "edu.berkeley.soda.room") • Values • Value (ex. "525" with 88% confidence) • Link to InfoSpace (ex. "http://guir.berkeley.edu/rooms/525/") • Privacy Tag • When this Tuple should be garbage collected • Who to notify on second use

27. Operators • Pieces of chainable code for manipulating Tuples • Designed for reusability and extensibility

28. Alice’s InfoSpace Tuple Tuple Tuple Tuple Tuple Tuple Operators • Pieces of chainable code for manipulating Tuples • Designed for reusability and extensibility • In-Operators modify incoming tuples • Ex. Check that we are only receiving data we are allowed to see ("please don't pass on to other people") In Operators Source

29. Alice’s InfoSpace Tuple Tuple Tuple Tuple Tuple Tuple Operators • Pieces of chainable code for manipulating Tuples • Designed for reusability and extensibility • In-Operators modify incoming tuples • Out-Operators modify outgoing tuples • Ex. Lowering precision of data Out Operators Sink

30. Alice’s InfoSpace Tuple Tuple Tuple Tuple Tuple Tuple Operators • Pieces of chainable code for manipulating tuples • Designed for reusability and extensibility • In-Operators modify incoming tuples • Out-Operators modify outgoing tuples • On-Operators run periodically on tuples in InfoSpace • Ex. Garbage Collection On Operators

31. Suite of Privacy Techniques • Privacy Techniques for Managing Info Flows • Lowering Precision • Access Control • Logging and Periodic Reports • Privacy Tags • Garbage Collection • All implemented as in-, out-, or on-operators

32. 56°N 36°E Privacy TechniqueLowering Precision • Problem: Some tuples provide too much info • Solution: Lower precision of data • Minimize flow of outgoing data by reducing quality • Tourist Example • "Alice is at 56°N 36°E" => "Alice is in Paris" • Implemented as out-operator using a region lookup Paris Marseilles

33. Privacy TechniqueAccess Control • Problem: Want to provide different info in different situations • Tourist Example • Let Bob see my location at city level only • Emergency Response Example • Let firefighters see my room location when I am in Soda Hall • Other Examples • Let all people in Soda Hall see my location at floor level • Let co-workers see my location if between 9AM and 5PM

34. Privacy TechniqueAccess Control • Solution: Fine-grained control through Conditions • Conditions • Age of data –Data Format • Requestor Domain –Data Type • Requestor ID –Current Time • Requestor Location • Actions • Lower Precision –Allow • Set (fake value) –Hide (data is removed) • Invisible (no out data) –Timeout (fake network load) • Interactive –Deny (forbidden)

35. Privacy TechniqueLogging and Periodic Reports • Problem: Need better understanding of who knows what about you for auditing purposes • Solution: Logs and periodic reports

36. Privacy TechniqueLogging and Periodic Reports • US Federal Trade Commission recently established National Do-not-call list for telemarketers James Haverly 404-333-3456 Jason Hong 510-345-3456 Tommy Horn 212-567-8910 • Question: What guarantees do we have that telemarketers will not use this list to spam people? • Answer: Seed with fake data, monitor phone calls to fake entries, punish violators (detection)

37. Privacy TechniqueSeeding Fake Data and Periodic Reports Bob, Provides Real-time Info • Alice, EPIC, or Consumer Reports sends fake data • Checks they are receiving periodic reports properly • Also monitors for spam and other misuses Alice, a Tourist

38. Privacy TechniqueSeeding Fake Data and Periodic Reports Bob, Provides Real-time Info • Wants assurances Carol won't abuse data • Notifies Carol • Create fake people with email addresses • Monitors results for abuses Carol, a Tour Operator

39. Privacy TechniquePrivacy Tags • Problem: Need a way of controlling data after it has left one’s InfoSpace (second use) • Solution: Tag each tuple with usage preferences • Email Analogy • “Please don't forward this to anyone else” • “Please delete this in three days” • Example Privacy Tags • For Bob and only Bob • Garbage collect if data over week old • Garbage collect if user leaves Soda Hall • Who to notify on violations (Ex. jasonh@cs.berkeley.edu)

40. Privacy TechniquePeer Enforcement of Privacy Tags Bob’s InfoSpace Delete in 7 days Loc PTag Alice’s InfoSpace Loc Carol’s InfoSpace PTag Bob has data he shouldn't Loc PTag

41. <ContextTuple dataformat="edu.berkeley.soda.room" datatype="location" description="Represents location of an entity" entity-name="Jason Hong" timestamp-created="2003.Mar.12 10:10:30 PST" timestamp-received="2003.Mar.12 10:10:30 PST" tuple-id="tmp14975.xml"> <Values> <Value value="525" link="http://guir.berkeley.edu:8080/infospace/soda525/" confidence="0.88" /> <Value value="527" link="http://guir.berkeley.edu:8080/infospace/soda527/" confidence="0.12" /> </Values> <Sources> <Source dataformat="edu.berkeley.soda.room" datatype="location" link="http://guir.berkeley.edu:8080/sim/loc/map.jsp" source-name="Soda Hall Location Simulator" timestamp-out="2003.Mar.12 10:10:30 PST" value="525" /> </Sources> <PrivacyTags notify-address=“im:jas0nh0ng@yahoo.com"> <GarbageCollect can-aggregate="true" notify="true"> <Where max-age-of-data="48 hours" /> <Where current-location=“not edu.berkeley.soda.*" /> </GarbageCollect> <SecondUse allow="false" notify="true" /> </PrivacyTags> </ContextTuple> Architectural Overview • Tuples <PrivacyTags notify-address="im:jas0nh0ng@yahoo.com"> <Aggregate allow="true" notify="true" /> <GarbageCollect> <Where max-age-of-data="48 hours" /> <Where current-location="not edu.berkeley.soda.*"/> </GarbageCollect> <SecondUse allow="false" notify="true" /> </PrivacyTags>

42. Architectural Details • InfoSpaces • Leverages web servers, HTTP • Ex. http://www.cs.berkeley.edu/~jasonh/infospace • Push data to edge, to where end-users have control • Low barrier to entry for admin, programmers, & end-users • Operators • Separate functionality into composable components • Easy for programmers & end-users to add or modify • Tuples • Uses XML docs vs. mobile objects or RPC (hidden state) • Transparent data model easy to view & understand

43. Implementation Details • All written in Java 1.4 • http://sourceforge.net/projects/confab • 410 Source classes • 18500 Lines of Code • Uses Apache Tomcat web server • Other infrastructure has been built using my APIs • Liquid Distributed Querying package • C++ Confab-lite PDA version (subset of full version)

44. Talk Outline • Motivation • Privacy and Managing Information Flows • Architectural Overview of Context Fabric • Applications Built with Context Fabric • Conclusions

45. Applications • Person Finder • Like AT&T m-life's Find Friends app but for web • Building Emergency Response Service • Based on field studies with firefighters • Currently using Wizard of Oz simulations for data rather than actual sensors • Make sure on right track before devoting time to sensors • Sensors being deployed in Berkeley now

46. Building Emergency Response Service • One of a suite of applications we are developing • Keep track of people in a building • Help building managers check if a building is clear in the event of an evacuation • Help firefighters understand where people are • Also provide reasonable privacy protection • People don't like to be tracked • Emergency situations relatively rare • Ensuring that data is used properly

47. Field Study and Iterative Design with Firefighters • What are big problems sensors can help with? • Four month field study, 30+ hours • Iterative prototyping and evaluation with firefighters • Gives the tools we build a better chance of succeeding Firefighters said knowing where people were in building would help determine their strategy

48. Building Emergency Response ServiceSoftware Prototype 1 General Purpose Apps Building General Use InfoSpace Location Beacons Emergency Response InfoSpace Emergency Response Apps Alice’s InfoSpace Alice’s Personal Info

49. Building Emergency Response ServiceSoftware Prototype 1 Building General Use InfoSpace Location Beacons Emergency Response InfoSpace Alice (Room) Alice’s InfoSpace

50. Building Emergency Response ServiceSoftware Prototype 1 Building General Use InfoSpace Location Beacons Emergency Response InfoSpace Out Alice’s InfoSpace Alice (Room)