Any idea what percentage of users just click without reading Twitter’s terms? It’s probably pretty small. (Somewhat related to this, Jakob Nielsen states that “people read only about 10% of the text that they supposedly ‘agreed’ to.”) Assuming that users actually care about how their information is going to be used, here’s the question:
How can I quickly see, understand and negotiate what I’ll be giving up when I click ‘I accept the Terms of Service’ on a website or mobile application?
Here’s one approach to answering the question.
- Easily identify policy categories related to data use
- Drill down into usage details
- Identify differences between what a vendor wants and what you’re willing to give
- User driven
DetailsA web site or mobile app provider demonstrates transparency about their data practices. How? They show a graphic that indicates their participation in and conformance to Data Practice Policy and Negotiated Use (let’s call it DPPN). The graphic needs to be understood by people coming from diverse cultural backgrounds; in other words, ubiquitous like these:
Adoption by the large web properties will help move the images into the lingua franca of the web. Here’s an example of a basic DPPN participation graphic :
Clockwise from the upper left…
Social graphic indicates use of address book, email, text messaging, etc.
Location graphic indicates the use of location information.
Network graphic indicates the use of Wi-Fi, NFC, Bluetooth, cell, etc.
Security graphic indicates application/site access to device information
Each of the sub-images represents a common data use category. The image can also convey to the viewer information about which data use categories are covered by the web site’s policies. For example, something like this:
The highlighted images indicate that the app or web site makes use of your social, location and network data.
Categories are constrained to a subset of common expressions of data use practice. The categories are limited in order to provide a practical basis for implementation and will form the basis for automating identification and negotiation.
Identifying the categories will require a critical analysis of privacy and TOS documents related to mobile application and web site access. One approach to identifying the data use policy categories is to crowd source the effort. (See Minimal marketable feature 2)
Drill down into usage detailsClicking or tapping the graphic brings up a more detailed set of graphics indicating usage.
The pattern repeats for each image.
NegotiateA web site or mobile app provider demonstrates their goodwill by allowing you to decide what to give up in return for access to their offerings. However, this is not a one-sided conversation.
Negotiation emphasizes relationship. Relationships change over time and are dynamic. One of the aspects of a relationship is trust. Relationships are built over time and through shared experiences. Participation in negotiated access helps build trust between users and vendors.
Imagine this dialog.
If you want access to our services, you need to tell us your name, phone number and email address. We’ll share these with our partners so we and they can more effectively sell you products and services.
I’m willing to let you have my name and email address but not my phone number. I’m also willing to let you send me marketing email but don’t want you to give my information to your partners.
Ok. We won't give your information to our partners, but we'll need your phone number.
It’s a deal.
What we’re looking for is a way for this exchange to happen in an automated fashion with the goal of producing good, rather than optimal outcomes.
Accept/rejectThe outcome of a negotiation will be either accept or reject. If accept, then the agreed upon information is entered or retrieved (say from a data locker via UMA) and provided to the vendor.
Getting to common data use policies and automated negotiation will take some time. To demonstrate the value of DPPN, implementation should occur iteratively with prioritized delivery of the smallest bits of functionality that will deliver value to users and vendors - minimal marketable features (mmf).
Minimal marketable feature 1
I want to quickly see and understand what information a web site or mobile app wants from me in order to use its services. This follows requirements 1 and 2.
Vendors will display a graphic indicating their participation in and asserting conformance to DPPN. The set of DPPN graphics will be open sourced.
Minimal marketable feature 2
I want to know what the differences are between what the vendor is asking for and what I’m willing to give. This satisfies requirement 3.
An end goal of DPPN is to allow users to create policies for the most common data use scenarios for use in automated negotiation. This will require some effort to identify and group elements of common data use practice.
Minimal marketable feature 3
I want to negotiate with the site/app what information I’m willing to give up for access to the service/functionality.
Negotiation is automated, generally transparent to the user and is centered on user policies built around common expressions of data use practice. As mentioned above, getting to common data use policies and automated negotiation will take some time. Therefore, the initial release of DPPN will simply present the user with an accept/reject choice.
Assuming that vendors will initially display only required information, an accept decision means that the user agrees to give the vendor all that they’re asking for. Similar to mmf 2, user selections and outcome (accept/reject) could be sent anonymously to a third-party rating site. This would have the added benefit of crowd sourcing data for analysis of TOS/Privacy Policies.
Selections and outcomes would also be saved to the user’s local storage for subsequent analysis and as evidence in the event of a vendor’s non-conformance to DPPN. Access to the saved data could be provided via a DPPN web site or mobile app.
Vendors could register with the rating site for access to data relevant to their service(s), providing them with a feedback loop they can use to build trust and gain loyal customers.
- Undertake the analysis of TOS/Privacy Policies to surface common expressions of data use practice. The results may prove useful in most data use scenarios with one outcome likely to be a taxonomy of data use practices. We’re attempting to provide a 90% solution, ignoring outliers.
- Research appropriate negotiation strategies and approaches. Again, the goal is to produce ‘good enough’ outcomes.
Interesting LinksTransparency as a User Experience Problem
A standard information sharing label
Terms of Service; Didn’t Read
Mozilla Privacy Icons
 If the graphics look familiar, it’s because they’re from the Android SDK and massaged just a bit…