How do you remember that you are supposed to forget?
By: Stephen Graham @ AnonTech
While designing some data subject access request (DSAR) capabilities for our personal information management platform, ViziVault, we ran into an interesting challenge regarding "the right to be forgotten." Conceptually, the right is easy to understand and makes perfect sense. If someone wants a company to get rid of all the data they have about them, they have a right to request this of the company who then must comply (if the company is under a qualifying data privacy regulation). However, when it came time to design & implement this capability, we ran into some interesting challenges.
We interpret the right to be forgotten as having two fundamental actions for a company to comply:
Delete all of the data for a particular person
Stop collecting & processing any additional data for this person
Taken in isolation, both pieces are easy. Removing the data for a specific person is easy (assuming you know how to find it all). And to stop collecting and processing new data for a person is easy as well. Your collection & processing processes simply need to be updated to ensure they are allowed to operate against each person before doing so.
Put together, though, is where we ran into our challenge. If we have deleted all of the information about a particular person, how then do we then identify this person to remember not to process their data if it comes in again? How can we satisfy both conditions of the right to be forgotten?
We are not privacy lawyers, and so we are not sure if there is a precedent for this already or how well our proposed solution would stand up in court. We decided we would reach out to the community with this question and solicit feedback. If you do have thoughts or information regarding this, please leave comments below or contact us at firstname.lastname@example.org. We would love to hear all opinions on the matter!
We decided that it must be acceptable to retain a minimum amount of information about a person in order to identify the fact they they have invoked their right to be forgotten. A similar analogy would be akin to the national "do not call" list in the US. In order to know that a person would like to not receive solicitation phone calls, a company must retain that person's phone number in order to remember not to call them. We decided that our platform would retain the minimum amount of identifying information to track individuals in a right to be forgotten database, but remove all other information about that individual. When new data comes in, that database will be referenced, and if the new data matches a person on the list, it will be discarded and no further processing will occur on that individual.
Additionally, we decided to use a cryptographically-secure, deterministic hashing algorithm to render the data unusable except to check if an individual's identifying characteristics match against the stored hash for that person when run through the same algorithm. This method has been used for storing & checking password information by authentication processes for years. It's not perfect - if an attacker obtained access to the hashes, they could still guess identifying information, or cross-reference it from another source, and check when they get a hit, but the data cannot be decrypted or made visible otherwise. We also revoked all outside read permissions from this database. The check is performed through a REST-based API method, which has the only access to this database, and the hashing is performed client-side so that no identifying characters leave the caller's domain.
It may not be perfect, but from an implementation standpoint, we could not figure out how to fully forget someone and still be able to prevent future collection & processing without retaining some minimal set of information about the people who have invoked this right. Again, we are not privacy lawyers ourselves, and so we would very much welcome any debate, discussion, or information on this topic. Please do leave comments below and/or e-mail us directly at email@example.com.