The Arcology Garden

Securing and Standardizing Data Rights Requests with a Data Rights Protocol

Contents

This is the proposal and outline for a talk I gave at USENIX PEPR 2023 which you can watch here.

For nearly 90 years, Consumer Reports has been doing independent product testing, public education, consumer advocacy and consumer-oriented research. Since 2019, the Consumer Reports Innovation Lab has been engaged in research on data privacy and digital security. We have engaged in applied research IoT security, VPN security and privacy, broadband access and in consumer data rights. Our data rights research research has shown a need for consumer-focused tools which enable them to access these rights, and Consumer Reports has been building an Agent Application to enable this. We ran multiple research experiments while building this product, and the confluence of this research and development has lead to the creation of the Data Rights Protocol, a technical standard for the interchange of data rights requests.

We Asked Consumers to Opt Themselves Out

In 2020, we asked consumers in California to submit "Do Not Sell" requests to 234 data brokers in the California AG's data broker registry. Businesses which are deemed to be selling data under the California ruling are required by the California Consumer Privacy Act to have a "clear and conspicuous" link labeled "Do Not Sell or Share My Personal Information" on their website which should lead consumers to an easy to use opt-out process.

Our research showed that half the time the consumers left the study "somewhat dissatisfied" or "very dissatisfied" with companies' opt-out processes. Each site's opt-out system was tested by three consumers, and in 42% of cases, one of the tree testers was unable to find that "clear and conspicuous" Do Not Sell link. In 13% of cases, all three testers failed to find this link on a data broker's site.

Consumers were required to do everything from provide email addresses, phone numbers, selfies, or copies of government IDs, all the way to installing the Data Brokers' 3rd party app to access data controls. Some Consumers reported that in these processes they were required to sign up for an account with the Data Broker in order to opt out, and one was even added to a marketing list afterwards based on the data they submitted in these opt-out requests.

2020-data-broker-study-1.png

Nearly half of the consumers in this study left the study waiting or unsure if their Do Not Sell requests had been successful.

We delivered policy recommendations to the California Attorney General and learned important lessons from this study. Asking consumers to do one-off data requests simply does not scale and barely works in practice. Since this study, the California Attorney General's Data Broker registry has doubled in size, and consumers' time and energy have not.

What if Consumer Reports handled the hard parts?

After asking consumers to make these requests on their own, Consumer Reports ran a number of studies around an under-utilized aspect of the California Consumer Privacy Act, the Authorized Agent provisions. The CCPA allows consumers to authorize third-parties to submit data rights requests on their behalf, so Consumer Reports ran a study in 2021 to see how this worked in practice.

We collected authorization from 124 consumers ran a study submitting Do Not Sell to 21 companies, a mix of well-known brands, data brokers, and companies known for high-impact use of personal information. Nearly all of these companies had implementation problems with respect to the authorized agent opt-out process, and we worked with some of them through the study to improve their process and our interface with them.

Our study revealed that businesses were broadly unprepared to handle agent requests, and while many were willing to adapt their processes to enable this, some were outright hostile to working with Consumer Reports. We found that just over half ultimately confirmed to us or to the consumer that they stopped the sale of at least some data in response to the opt-out submission.

But what about Access and Deletion Requests?

While "Do Not Sell" requests are seen as a bit of "table stakes" for businesses participating in the data economy, Access and Deletion requests have a higher bar of validation and a higher cost of implementation. The CCPA is unique in US consumer privacy bills in that it allows California consumers to authorize agents to perform even these requests on their behalf.

So in 2022 Consumer Reports tested this as well by helping 104 consumers submit Data Subject Access or "Right to Know" Requests. Because Consumer Reports is not currently in the position to safely handle the data that could be included in these requests, our outreach to the companies was explicit that the results of the data subject access requests should be sent directly to consumers, and many of the businesses had to adapt their compliance workflows to ensure this.

As a result of this requirement, our ability to help consumers understand what was in the results of the access request were limited, and consumers were often confused by what was in the result of the access requests. Or what was not in the data request. They had little recourse to gain insight or transparency. One of our volunteers remarked afterward "They told me they checked by had nothing -- which is odd because I shop there, I even have their [store] credit card."

Even though we did not have access to the data packets themselves, receiving metadata about the processing of the requests would be valuable because over time we could provide statistical information to consumers about businesses' data handling. However, in more than half of the cases, business did not information Consumer Reports of the state of the data requests and ultimately only one quarter were affirmatively fulfilled.

Introducing Permission Slip

Throughout all this research, Consumer Reports has learned that consumers want a consistent and transparent interface. We learned that to provide that transparency, metadata about the requests to each business need to be reported to the agent and tracked over time. Consumer Reports began to develop a mobile application called Permission Slip to enable this Authorized Agent capability at scale.

The most common ways to develop an agent application right now is to either send automated emails straight from the consumer's mail provider or to have a complicated manual process behind the scenes. While the former allows the agent to scale up quickly and effectively, businesses often look at such automated requests with suspicion, and often times they refuse to treat them as legitimate data rights requests and respond by sending consumers to consumer-centered workflows.

Permission Slip is based around the latter idea; when consumers sign up, they verify their identity with Consumer Reports and sign a legal document granting Consumer Reports a limited power of attorney to submit these data rights actions, and then a team collects the pending requests from our back-end service, and submits them to businesses directly while working with them to streamline these "bulk" data requests. Consumer Reports is a brand that is trusted by consumers and businesses and we believe we are in a unique position to guide the industry towards better solutions.

We entered a private beta period earlier this year and have scaled up to over 10,000 users and hundreds of thousands of opt-out and deletion tests in this pre-launch testing. With a single click, a consumer can now submit "do not sell" requests to a significant portion of the data brokers in the California Data Broker Registry, and then scroll through a list of consumer brands which they may no longer wish to do business with and delete their data and close the account with similar ease.

But how do we scale up to build something which even more consumers can take advantage of? It's clear that automation and standardization of these flows is a key component and this lead to the birth of the Data Rights Protocol.

The Birth of the Data Rights Protocol

To reiterate, Consumer Reports has learned through applied research that consumers want to exercise their data rights but they are disempowered by technical and procedural issues. We learned that businesses have little technical or legal foundation to trust the fidelity of agent requests, forcing many of them to process each request by hand or direct consumers to use existing time-consuming workflows. And we learned that businesses providing those bespoke processes makes it difficult for consumers to meaningfully access their rights.

We believe that with the right affordances, authorized agents can serve as a trustworthy intermediary between consumers and businesses. We have encapsulated those affordances in a standardized workflow to streamline the interchange of data rights requests.

drp-system-dimensions.png

We are developing and deploying a holistic system across three dimensions. Each of the implementing parties' technology, business, and legal requirements are aligned within the protocol and the rules of a participatory network to ensure a healthy system which people are actually willing to implement and operate. A technical protocol defines the "nuts and bolts" of request interchange which can be laid on top of existing privacy compliance workflows. A lightweight framework of operating rules ensures that consumers' data and businesses' processes can be protected from abuse. And a participatory network of businesses representing the entire lifecycle of a request ensures we are building a system which people can actually implement and trust.

The Data Rights Protocol

The "nuts and bolts" of the DRP are pretty simple. Our research has allowed us to build a request processing schema and a state machine which captures the flow of the average data rights requests. These requests are straightforward encoding of the consumer's identity and the rights they are exercising, while still being flexible enough to allow for businesses to conduct in-house identity verification or account authorization, and to handle "weird" request states like processing delays.

We have implemented DRP with fairly boring technology choices. The API is a set of five HTTPS endpoints. The "exercise" endpoint contains information defining the regulatory environment the user is submitting the requests from and what rights they wish to exercise, along with a standard encoding of the consumer's identity.

text
POST /v1/data-rights-request
base64(<signature> {
  "meta": {
	  "version": "0.9"
  },
  "regime": "ccpa",
  "exercise": "sale:opt-out"
  "name": "Jane Doe"
  "email": "jane.doe@example.com"
})

You can see here that Jane Doe is making a CCPA "Do Not Sell" request.

This information is bundled up, signed, and then encoded in a way that can safely be transferred over the internet. With the help of Complex Systems Group's Kevin Riggle, we built a simple yet robust security model. The messages are signed using a public-domain encryption API called libsodium. libsodium has implementations and bindings in many programming languages, has commercial support, and is specifically designed to avoid cryptographic disasters common in other signature APIs like PGP, JWT, or OpenSSL.

DRP requests are sent over the open internet using HTTPS, but the network is bounded by participation in a simple root of trust. The DRP operates two simple machine readable directories. One contains information about all of the agents which implement the DRP, providing businesses with contact information and cryptographic material to verify the authenticity of incoming requests. Another contains information about all of the businesses which implement the DRP, allowing agents to discover which businesses these automated requests can be sent to.

Along with the published protocol standard, the we provide implementation guides and an open source reference implementation to onboard new members and provide a test suite for interoperability testing. The service directory is operated and secured through a lightweight process using GitHub's access control features and GitHub Actions to publish the directory. One of the key features of the DRP is that it should be cheap to implement and operate, because the network will likely be operated by the implementers.

How the DRP Provides a Valuable Root of Trust

The self-governance of this network by its participants is an important part of building a system that works in practice. Ultimately, this idea will only work if businesses can trust that agents are handling the consumers' identity and agency properly, and conversely agents should be able to trust that businesses are handling these requests faithfully and with the understanding that consumers want to exercise these rights whether it is easy for the business or not.

We've created a lightweight common agreement which outlines acceptable behavior between agents, businesses, and the privacy infrastructure providers they contract with to provide these services. Agents and businesses provide each other with transparent documentation of data handling practices, privacy policies, and the like, and agents also provide documentation of their identity verification processes. This last bit of information will provide a reasonable basis of trust for businesses which do not need more than a verified email or phone number to process a request without additional out-of-band consumer verification.

The organization is governed by the participants in a "one member, one vote" model while we consider implementing a sort of "super majority" model where two of the three implementing groups -- that is agents, businesses, and privacy compliance providers -- must have a majority vote.

We are ensuring the DRP is cheap to implement and operate

Many businesses do not have the technical expertise or bandwidth to implement privacy compliance workflows themselves, and instead contract with a number of companies that provide these compliance services, companies like OneTrust, DataGrail, and Transcend. These and other privacy compliance technology providers are building DRP interfaces which integrate with their existing product portfolio, ultimately offering a "push-button" onboarding to these streamlined requests. Businesses can choose to contract with agents who handle these requests, and we aim to give that same benefit to consumers in the best way possible.

Since the earliest moments of DRP's incubation within the Consumer Reports Innovation Lab, we have partnered with these companies in an effort to reduce the complexity of accessing and acting on these important rights.

Consumers should be able to make requests through a simple, unified interface operated by trustworthy agents, and the agents should be able to verify and sign the requests on their services' back-ends and submit those requests to an interface operated either directly by the business or a technology provider they contract with, and those requests should end up side-by-side with other data rights requests.

Consumers can stop filling out dozens of bespoke forms and remembering to follow up with customer support representatives who may not be well trained in handling these requests. And businesses can stop fielding hundreds of form-filled support emails and training those customer support representatives on how to safely handle consumer identity material and their personal information. Ultimately, we believe this is a virtuous cycle where innovative engineering can build cost-effective solutions that deliver value to and build trust with consumers.

drp-agent-model.png

We are close to shipping DRP 1.0

The DRP is being evaluated, steered, and implemented by some of the largest privacy compliance tooling providers, and will be implemented by existing agent applications and new entrants in the space.

We envision a world where consumers have access to powerful data management tools which can validate the identity of the consumer and easily make attestations to businesses on behalf of those consumers. And we envision a world where businesses can click a single button in their privacy compliance suite to transparently enable DRP requests to stop spending precious paralegal time validating pictures of peoples' drivers license. And for businesses with the technical wherewithal to implement these solutions themselves, it should be easy to add the functionality to receive these requests to their privacy tooling stack and begin to receive automated data rights requests in a matter of days or weeks.

If this work excites you, it's not too late to get involved. We are looking for businesses which are interested in implementing the protocol themselves. And we are looking for businesses who are excited to see these features enabled in their existing contracted privacy compliance tooling. And finally, Consumer Reports Innovation Lab is looking for talented individual contributors to work on the Data Rights Protocol and on Permission Slip. We also are working on exciting projects in IoT and VPN security, as well as more advocacy research in data rights and other consumer issues. Visit datarightsprotocol.org or email datarightsprotocol@cr.consumer.org for more information.