User- Controllable Privacy and Security for Pervasive Computing Jason I. Hong Carnegie Mellon University

User- Controllable Privacy and Security

for Pervasive Computing

Jason I. HongCarnegie Mellon University

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

Difficult to Build Usable Interfaces

(a) (c)

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

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

Outline

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

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

Contextual Instant MessagingPrivacy Mechanisms

• Web-based specification of privacy preferences– Users can create groups and

put screennames into groups

– Users can specify what each group can see


• Notifications of requests


• Social translucency


• Audit logs

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?

Contextual Instant MessagingResults

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

0

20

40

60

80

100

120

Interruptibility Location Active Window


• 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


• 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”)

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

Outline


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

People FinderMachine Learning

• Using case-based reasoning (CBR)– “My colleagues can only see my location on

weekdays and only between 8am and 6pm”

– It’s now 6:15pm, 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)

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”

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

People FinderStudy on Rules

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

People FinderResults – Accuracy

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

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

Outline


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

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

GreyDeployment at CMU

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

GreyEvaluation

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

GreyResults of Time on Task of a Shared Kitchen Door




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

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

GreyCurrent work in Visualizations

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

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

Acknowledgements

• NSF Cyber Trust Grant CNS-0627513 • ARO DAAD19-02-1-0389 ("Perpetually Available and

Secure Information Systems") to CMU’s CyLab

Source: http://www.rudezone.com/cartoon4/wireless.html

People FinderResults – Accuracy

Documents

User- Controllable Privacy and Security for Pervasive Computing Jason I. Hong Carnegie Mellon University