Social Consent
Convener: Angus Logan + Kevin Marks
Notes-taker: Sarah Faulkner
Tags: UX, Consent, OAuth, Delegation,
Discussion notes:
Questions:
- How is Social Consent done today?
- What must we tell the user?
- What, Why, How Long, To Who
- How does that get communicated?
- When do we ask them to choose?
- Duration of consent? (one time vs. long time)
- Can a user consent to their friend’s data (e-mail address in contact list)?
Notes:
People are not going to read the text; they may not understand they can opt-out. We need to do the right thing with user’s data assuming this rudimentary understanding of consent.
- Maybe we’re not doing the right thing (facebook apps using user’s info in ads).
- Therefore, are there use case clusters that make sense?
- Cannot expect user to understand the architecture – are we asking users to make decisions they cannot make?
- Users understand their data and they understand the company they are given to. But does user understand the risk?
What is the rate of actual acceptance vs. users who decline consent vs. users who bail because they don’t understand – do we have data from currently live UI?
Minimal upfront consent: initial consent flow allows minimal access to data. When service wants to use the next level (post, etc.), the user is asked again to give a higher level of consent.
- But confirmation dialogues are a failure – “undo” works much better.
- Progressive escalation model – allows revoke consent (helps combat streams vs. snapshot data like e-mail).
Reputation trust model – on consent flow, you see friends’ accept/revoke info.
- Need to be careful about when you surface info collection to make sure you have a good sample (i.e. feedback field only on “revoke” page).
Need a best practices document for OAuth UI
- Existing advice: Overview of OAuth user experience article -- Search:“OAuth Goog”
Problem: can lose options – you may want to only share a subset of data, there is no “one size fits all.”
RP’s asking just at the time they want to use data can give context to the user.
- Websites are not going to want to continually interrupt the user. But it may be in the website’s best interest to not ask for everything up front, because it will scare the user.
What is the ideal experience?
- We assume that the user has a classification system where they understand where to place the app. Users are unsophisticated in who to trust.
Websites consuming data really wants users to understand what they have granted; they do not want to scare users when they do what was “consented.”
- Give the app a way to explain what they are using the data for.
Data retention policies?
- Consumer groups are asking for this; if we ignore it, it will most likely be regulated.
Facebook: going to give developers access to e-mail address. Want to give developers more trust that the relationship developing with the user will not just go away. RP’s need a way to continuously interact with the user.
UX:Minimal, reversible, understandable, expandable
Classify the application for the user: explain that the partner is a “gaming” application, so they would like to have the following information.
Have the user create their own categories of data. But this will lead to a negotiation between the user and the site – users are not informed to know whether they really want to give that permission.
Asking user “real time” – what if user is not there to give consent?
Consumers do not understand the value exchange they are getting.
Paper at SOUPS (available on website) – only thing that consumers read are nutrition labels (presented privacy policy that way and users read and understood). When requesting information, present it in this manner for max understanding.