User- Controllable Privacy and Security for Pervasive Computing

1
User- Controllable Privacy and Securityfor
Pervasive Computing
Jason I. HongCarnegie Mellon University
2
The Problem

• Mobile devices becoming integrated into everyday
  life
• Mobile communication
• Sharing location information with others
• Remote access to home
• Mobile e-commerce
• Managing security and privacy policies is hard
• Preferences hard to articulate
• Policies hard to specify
• Limited input and output
• Leads to new sources of vulnerability and
  frustration

3
Difficult to Build Usable Interfaces
(a) (c)
4
Our Goal

• Develop better UIs for managing privacy and
  security on mobile devices
• Simple ways of specifying policies
• Clear notifications and explanations of what
  happened
• Better visualizations to summarize results
• Machine learning for learning preferences
• Start with small evaluations, continue with
  large-scale ones
• Large multi-disciplinary team and project
• Six faculty, 1.5 postdocs, six students
• Roughly 1 year into project

5
Application Domains

• Contextual Instant Messaging
• People Finder
• Access Control to resources
• Some Challenges
• Not being burdensome or annoying
• Finding right balance of expressiveness and
  simplicity
• Helping users understand capabilities and
  limitations
• Providing enough value so that people will use
  our apps!
• Security privacy our main concern, but not to
  users

6
Outline

• Motivation
• Contextual Instant Messaging
• People Finder
• Access Control to Resources

7
Contextual Instant Messaging

• Facilitate coordination and communication by
  letting people request contextual information via
  IM
• Interruptibility (via SUBTLE toolkit)
• Location (via Place Lab wifi positioning)
• Active window
• Developed a custom client and robot on top of AIM
• Client (Trillian plugin) captures and sends
  context to robot
• People can query imbuddy411 robot for info
• howbusyis username
• Robot also contains privacy rules governing
  disclosure

8
Contextual Instant MessagingPrivacy Mechanisms

• Web-based specification of privacy preferences
• Users can create groups andput screennames into
  groups
• Users can specify what each group can see

9
Contextual Instant MessagingPrivacy Mechanisms

• Notifications of requests

10
Contextual Instant MessagingPrivacy Mechanisms

• Social translucency

11
Contextual Instant MessagingPrivacy Mechanisms

• Audit logs

12
Contextual Instant MessagingEvaluation

• Recruited ten people for two weeks
• Selected people highly active in IM (ie
  undergrads ?)
• Each participant had 90 buddies and 1300
  incoming and outgoing messages per week
• Notified other parties of imbuddy411 service
• Update AIM profile to advertise
• Would notify other parties at start of
  conversation
• Any predictions of results?

13
Contextual Instant MessagingResults

• Total of 242 requests for contextual information
• 53 distinct screen names, 13 repeat users

14
Contextual Instant MessagingResults

• 43 privacy groups, 4 per participant
• Groups organized as class, major, clubs,gender,
  work, location, ethnicity, family
• 6 groups revealed no information
• 7 groups disclosed all information
• Only two instances of changes to rules
• In both cases, friend asked participant to
  increase level of disclosure

15
Contextual Instant MessagingResults

• Likert scale survey at end
• 1 is strongly disagree, 5 is strongly agree
• All participants agreed contextual information
  sensitive
• Interruptibility 3.6, location 4.1, window 4.9
• Participants were comfortable using our controls
  (4.1)
• Easy to understand (4.4) and modify (4.2)
• Good sense of who had seen what (3.9)
• Participants also suggested improvements
• Notification of offline requests
• Better notifications to reduce interruptions
  (abnormal use)
• Better summaries (User x asked for location 5
  times today)

16
Contextual Instant MessagingCurrent Status

• Preparing for another round of deployment
• Larger group of people
• A few more kinds of contextual information
• Developing privacy controls that scale better
• More people, more kinds of information

17
Outline

• Motivation
• Contextual Instant Messaging
• People Finder
• Access Control to Resources

18
People Finder

• Location useful for micro-coordination
• Meeting up
• Okayness checking
• Developed phone-based client
• GSM localization (Intel)
• Conducted studies to see how people specify
  rules ( how well)
• See how well machine learning can learn
  preferences

19
People FinderMachine Learning

• Using case-based reasoning (CBR)
• My colleagues can only see my location on
  weekdays and only between 8am and 6pm
• Its now 615pm, so the CBR might allow, or
  interactively ask
• Chose CBR over other machine learning
• Better dialogs with users (ie more
  understandable)
• Can be done interactively (rather than
  accumulating large corpus and doing post-hoc)

20
People FinderStudy on Preferences and Rules

• First conducted informal studies to understand
  factors important for location disclosures
• Asked people to describe in natural language
• Social relation, time, location
• My colleagues can only see my location on
  weekdays and only between 8am and 6pm

21
People FinderStudy on Preferences and Rules

• Another study to see how well people could
  specify rules, and if machine learning could do
  better
• 13 participants (1 for pilot study)
• Specify rules at beginning of study
• Presented a series of thirty scenarios
• Shown what their rules would do, asked if correct
  and utility
• Given option to change rule if desired

22
People FinderStudy on Rules
23
People FinderResults User Burden
Mean (sec) Std dev (sec)
Rule Creation 321.53 206.10
Rule Maintenance 101.15 110.02
Total 422.69 213.48
24
People FinderResults Accuracy
25
People FinderCurrent Conclusions

• Roughly 5 rules per participant
• Users not good at specifying rules
• Time consuming low accuracy (61) even when
  they can refine their rules over time (67)
• Interesting contrast with imbuddy411, where
  people were comfortable
• Possible our scenarios biased towards exceptions
• CBR seems better in terms of accuracy and burden
• Additional experiments still needed

26
People FinderCurrent Work

• Small-scale deployment of phone-based People
  Finder with a group of friends
• Still needs more value, people finder by itself
  not sufficient
• Trying to understand pain points on next
  iteration
• Need more accurate location
• GSM localization accuracy haphazard
• Integration with imbuddy411
• Smart phones expensive, IM vastly increases user
  base

27
Outline

• Motivation
• Contextual Instant Messaging
• People Finder
• Access Control to Resources

28
Grey Access Control to Resources

• Distributed smartphone-based access control
  system
• physical resources like office doors, computers,
  and coke machines
• electronic ones like computer accounts and
  electronic files
• currently only physical doors
• Proofs assembled from credentials
• No central access control list
• End-users can create flexible policies

29
GreyCreating Policies

• Proactive policies
• Manually create a policy beforehand
• Alice can always enter my office
• Reactive policies
• Create a policy based on a request
• Can I get into your office?
• Grey sees who is responsible for resource, and
  forwards
• Might select from multiple people (owner,
  secretary, etc)
• Can add the user, add time limits too

30
GreyDeployment at CMU

• 25 participants (9 part of the Grey team)
• Floor plan with Grey-enabled Bluetooth doors

31
GreyEvaluation

• Monitored Grey usage over several months
• Interviews with each participant every 4-8 weeks
• Time on task in using a shared kitchen door

32
GreyResults of Time on Task of a Shared Kitchen
Door
33
GreyResults of Time on Task of a Shared Kitchen
Door
34
GreyResults of Time on Task of a Shared Kitchen
Door
35
GreyResults of Time on Task of a Shared Kitchen
Door
36
GreySurprises

• Grey policies did not mirror physical keys
• Grey more flexible and easier to change
• Lots of non-research obstacles
• user perception that the system was slow
• system failures causing users to get locked out
• need network effects to study some interesting
  issues
• Security is about unauthorized users out, our
  users more concerned with how easy for them to
  get in
• never mentioned security concerns when interviewed

37
GreyCurrent work

• Iterating on the user interfaces
• More wizard-based UIs for less-used features
• Adding more resources to control
• Visualizations of accesses
• Relates to abnormal situations noted in
  contextual IM

38
GreyCurrent work in Visualizations
39
Concluding Remarks

• User-controllable privacy and security for three
  apps
• Contextual instant messaging
• People Finder
• Grey distributed access control system
• Common threads
• Simpler ways of specifying policies
• Better notifications and explanations
• Better visualizations
• Machine learning for learning preferences

40
Concluding Remarks

• Some early lessons
• Many indirect issues need to be addressed to
  study usable privacy and security (value
  proposition, network effects)
• People seem willing to use apps if good enough
  controland feedback for privacy and security
• Lots of iterative design needed

41
Acknowledgements

• NSF Cyber Trust Grant CNS-0627513
• ARO DAAD19-02-1-0389 ("Perpetually Available and
  Secure Information Systems") to CMUs CyLab

Source http//www.rudezone.com/cartoon4/wireless.
html
42
People FinderResults Accuracy