I started working on privacy in 2017 when I joined a payments company called Stripe as a security engineer and helped us implement compliance with the EU’S GDPR. Since then, American companies have built increasingly complex and bespoke systems in order to comply with not just the GDPR but a spreading patchwork of domestic privacy laws like California’s CCPA.
Under these laws, consumers have new and very powerful rights to our data, and compliance has successfully given consumers back a lot of autonomy and control over our data and our lives. The ability to access the data that companies have about us has made it easier to understand who knows what about us and how; the ability to delete our accounts and trust that the associated data is also deleted because it’s required to be so, by law, has given us back control over who we let keep our data; and the ability to opt out of the sale of our data has given us back some control over what we let them do with it.
However, this power is a double-edged sword. I always describe the results of a data access request as an “identity theft packet.” Another person who gets a copy of my data access request from a merchant can see every purchase I’ve made from them; anyone who gets a copy of my data access request from a rideshare provider can see every ride I’ve taken, and probably figure out where I live and work, where my kids go to school, who my doctor is—the list goes on. Even the ability to delete that rideshare account, if it fell into the wrong hands at the wrong time, could be catastrophic.
Our goal in building the Data Rights Protocol (DRP) is to make it easier for consumers to make data rights requests across corporate America, and easier for businesses to handle them, by standardizing how they are made. However, in doing so we must not also make it easier for bad actors to get consumers’ information and use it to bad ends.
In this post, I’ll walk through some of the key security considerations which we think are inherent in this system, and how we’re planning to address them in order to keep consumers safe as we exercise our rights.
An example use of the Data Rights Protocol
Imagine that I’m a California resident (1) and a customer of California’s most infamous fictional company, Acme Products Corp (2). I like Acme’s products, but they’ve sold my mailing address to a number of other companies, who are now sending me a lot of paper catalogs for things I don’t want.
I want to tell Acme that I don’t want them to sell my data to other companies for marketing purposes any more (an “opt out” under the CCPA). We call Acme a “Covered Business,” and they are required to honor my request under California law.
With the existence of the DRP network, I no longer need to go directly to Acme’s web site and figure out how they’ve chosen to let me request to opt-out. Instead I go to a consumer-facing organization, like the Permission Slip app created by Consumer Reports, which we call an “Authorized Agent,” and ask them to request the opt-out from Acme on my behalf.
However, in order to facilitate handling data rights requests like my opt-out request, Acme works with a software service provider, who receives and manages those requests from consumers on Acme’s behalf. We call this software service provider chosen by Acme a “Privacy Infrastructure Provider,” and this type of outsourcing is already very common across American businesses.
This means that there are now several organizations between me and Acme, though, which raises a few concerns, and the first concern is the biggest—when Acme receives my request, how can they know it’s really me making the request, and not someone else?
The very short answer is that, as a member of the DRP network, Acme relies on the Authorized Agent, in this case Permission Slip, to verify that I really am who I say I am. The DRP network has an established set of standards for what kinds of information about me need to be verified, and how the Authorized Agent needs to go about verifying them.
That just leads to another problem, though: If Acme relies on an Authorized Agent to verify my identity, how can Acme be sure that any request they receive is really from a specific Authorized Agent, and not from someone else, either another Authorized Agent or someone not part of the DRP network entirely?
Digital signatures and participant directories to ensure request integrity
To ensure that Acme can verify that a consumer’s data request is really being sent by the Authorized Agent who is claimed to be sending it, we’re making use of a technology called “asymmetric-key cryptography” or “public-key cryptography,” a little bit of mathematical magic which has been around since the mid-1970’s and is used to secure everything from your credit card transactions to this very web page.
Basically, each Authorized Agent has a secret number which they can use to digitally sign your request when they send it to Acme. Without itself knowing the secret number, Acme can still verify that only that Authorized Agent’s secret could have been used to generate that signature, and that your request hasn’t been tampered with in transit. (Like I said: a little bit magic.)
However, to verify this, Acme needs access to a public, shareable number which corresponds to this Authorized Agent’s secret number, and needs to know that this number is associated with this Agent. It would be fine to share these numbers by hand if there were only a handful of Authorized Agents—and in fact that’s where we’re starting, in the beta test phase—but we hope that there will be lots of agents and covered businesses, and distributing the numbers for all Authorized Agents with all Covered Businesses becomes unwieldy.
We also plan that there will be lots of Covered Businesses like Acme which use the DRP network, and Authorized Agents need to be able to figure out how to send requests to all of them without necessarily ever having interacted with them before.
In our current plan to solve this conundrum, the DRP network will run two directory services, one for Authorized Agents to look up Covered Businesses, and the other for Covered Businesses to look up the public number associated with each Authorized Agent so it can verify that requests really came from that Authorized Agent.
Each Authorized Agent or Covered Business only needs to register once, with the DRP network, and is then immediately and fully part of it and able to send or receive requests, to or from any other entity in the network, safely. Authorized Agents and Covered Businesses don’t need to build relationships with each other individually, since the directories and the DRP network connect them all.
…And that’s the story so far…
This is only a small part of the work that we’re doing to ensure that the DRP network is safe and works correctly for everybody involved. What other security guarantees would you like from a common protocol for data rights? Let us know on GitHub or via our feedback form.
(1) The Data Rights Protocol is designed around the California Consumer Privacy Act from the start—since we’re being incubated under Consumer Reports, a US nonprofit, our focus is on domestic privacy laws.
(2) Not the mid-Atlantic supermarket chain, or the hand tools company, or the furniture company—the coyote-gadget-supply company.
