Data Practice Policy and Negotiated Use

The user experience when confronted with, say, Twitter’s Terms of Service, Rules and Privacy Policy sucks. Most people won’t even look at the verbiage before accepting. For example, if you want to sign up for Twitter, you’re presented with this:

 

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.

Requirements

1. Easily identify policy categories related to data use 
2. Drill down into usage details 
3. Identify differences between what a vendor wants and what you’re willing to give 
4. Negotiate 
• User driven
• Automated
5. Accept/reject

Details

Requirement: Easily identify policy categories related to data use

A 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 [1]:


 

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 details

Clicking or tapping the graphic brings up a more detailed set of graphics indicating usage.

 
In the example above, the graphic lets me know that Twitter may use my contact info for marketing purposes. There’s a link to the relevant section of Twitter’s privacy policy if I want to see the full text. Note that the link is just an example; the policy does not have a contacts fragment.
 
The pattern repeats for each image.
 

Identify differences between what a vendor wants and what you’re willing to give

Once we know what a vendor wants from us, we might want to compare that with what we're willing to give up. This forms the basis for negotiation. Conceptually, this is what it might look like in a browser, again using Twitter’s Privacy Policy:
 

Figure 1 

Negotiate

A 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.

Vendor	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.
Me	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.
Vendor	Ok. We won't give your information to our partners, but we'll need your phone number.
Me	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/reject

The 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.
 

Road Map

 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.

Clicking/tapping the participation graphic displays an expanded view of TOS/Privacy Policy requests.

Clicking/tapping one of the graphics in the expanded view displays a summary of the request with a link to the relevant TOS/Privacy Policy section.

As with the graphics, an open source library of code will be made available to facilitate participation in DPPN. Initially, the code will target the browser and probably consist of JavaScript and chunks of semantic markup to load, display and manage the graphics and their behaviors.

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.

For the first iteration, vendors will identify the data elements spelled out in their TOS/Privacy Policy and package them in a DPPN specified format. The elements will then be displayed in a manner similar to that in Figure 1, above. To give a user an idea of what other people have agreed to, the right hand side of the diff display may be pre-populated by a third-party rating site, such as ToS;DR2.

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.

Future Directions

• 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 Links

Transparency as a User Experience Problem
A standard information sharing label
Terms of Service; Didn’t Read
Mozilla Privacy Icons

[1] If the graphics look familiar, it’s because they’re from the Android SDK and massaged just a bit…

Dazza Greenwood and James Donaghue for their insightful comments and  suggestions.