Just a Theory

By David E. Wheeler

Posts about GDPR

The Farce of Consent

Cornell Tech Professor of Information Science Helen Nissenbaum, in an interview for the Harvard Business Review:

The farce of consent as currently deployed is probably doing more harm as it gives the misimpression of meaningful control that we are guiltily ceding because we are too ignorant to do otherwise and are impatient for, or need, the proffered service. There is a strong sense that consent is still fundamental to respecting people’s privacy. In some cases, yes, consent is essential. But what we have today is not really consent.

It still feels pretty clear-cut to me. I chose to check the box.

Think of it this way. If I ask you for your ZIP code, and you agree to give it to me, what have you consented to?

I’ve agreed to let you use my ZIP code for some purpose, maybe marketing.

Maybe. But did you consent to share your ZIP code with me, or did you consent to targeted marketing? I can combine your ZIP code with other information I have about you to infer your name and precise address and phone number. Did you consent to that? Would you? I may be able to build a financial profile of you based on your community. Did you consent to be part of that? I can target political ads at your neighbors based on what you tell me. Did you consent to that?

Well this is some essential reading for data privacy folx. Read the whole thing.

I myself have put too much emphasis on consent when thinking about and working on privacy issues. The truth is we need to think much deeper about the context in which consent is requested, the information we’re sharing, what it will be used for, and — as Nissenbaum describes in this piece — the impacts on individuals, society, and institutions. Adding her book to my reading list.

(Via Schneier on Security)

Token Dimensions

C’est mois, in my second post on Tokenization for the iovation blog:

These requirements demonstrate the two dimensions of tokenization: reversibility and determinism. Reversible tokens may be detokenized to recover their original values. Deterministic tokens are always the same given the same inputs.

The point is to evaluate the fields private data fields to be tokenized in order to determine where in along these dimensions they fall, so that one can make informed choices when evaluating tokenization products and services.

GDPR and the Professionalization of Tech

Happy GDPR day.

The GDPR is a big deal. It encodes significant personal and private data rights for EU subjects, including, among others:

Organizations that process personal data, referred to as “data controllers,” accept serious responsibilities to respect those rights, and to protect the personal data they process. These responsibilities include, among others:

The regulations have teeth, too; fines for non-compliance add up to a considerable financial penalty. Failure to notify in the event of a breach, for example, may result in a fine of up to €20 million or 4% of global revenue, whichever is greater.

There’s a lot more, but the details have been extensively covered elsewhere. In contrast, I want to talk about the impact of the GDPR on the internet products and services.

Impacts

In my GDPR advocacy for iovation, I’ve argued that the enshrinement of personal data rights marks a significant development for human rights in general, and therefore is not something to be resisted as an imposition on business. Yes, compliance requires a great deal of work for data controllers, and few would have taken it on voluntarily. But the advent of the GDPR, with application to over 500 million EU subjects, as well as to any and all organizations that process EU subject personal data, tends to even out the cost. If the GDPR requires all companies to comply, then no one company is disadvantaged by the expense of complying.

This argument is true as far as it goes — which isn’t far. Not every company has equal ability to ensure compliance. It might be a slog for Facebook or Google to comply, but these monsters have more than enough resources to make it happen.2 Smaller, less capitalized companies have no such luxury. Some will struggle to comply, and a few may succumb to the costs. In this light, the GDPR represents a barrier to entry, a step in the inevitable professionalization3 of tech that protects existing big companies that can easily afford it, while creating an obstacle to new companies working to get off the ground.

I worry that the GDPR marks a turning point in the necessary professionalization of software development, increasing the difficulty for a couple people working in their living room to launch something new on the internet. Complying with the GDPR is the right thing to do, but requires the ability to respond to access and deletion requests from individual people, as well as much more thorough data protection than the average web jockey with a MySQL database can throw together. For now, perhaps, they might decline to serve EU subjects; but expect legislation like the GDPR to spread, including, eventually, to the US.

Personal data rights are here to stay, and the responsibility to adhere to those rights applies to us all. While it might serve as a moat around the big data controller companies, how can leaner, more agile concerns, from a single developer to a moderately-sized startup, fulfill these obligations while becoming and remaining a going concern?

Tools

Going forward, I envision two approaches to addressing this challenge. First, over time, new tools will be developed, sold, and eventually released as open-source that reduce the overhead of bootstrapping a new data processing service. Just as Lucene and Elasticsearch have commoditized full-text search, new tools will provide encrypted data storage, anonymous authentication, and tokenization services on which new businesses can be built. I fear it may take some time, since the work currently underway may well be bound by corporate release policies, intellectual property constraints, and quality challenges.4 Developing, vetting, releasing, and proving new security solutions takes time.

Commercial tools will emerge first. Already services like Azure Information Protection secure sensitive data, while authentication services like Azure Active Directory and Amazon Cognito delegate the responsibility (if not the breach consequences) for secure user identities to big companies. Expect such expensive services to eventually be superseded by more open solutions without vendor lock-in — though not for a couple years, at least.

Ingenuity

I’m into that, even working on such tools at work, but I suspect there’s a more significant opportunity to be had. To wit, never underestimate the ingenuity of people working under constraints. And when such constraint include the potentially high cost of managing personal data, more people will work harder to dream up interesting new products that collect no personal data at all.

Internet commerce has spent a tremendous amount of time over the last 10 years figuring out how to collect more and more data from people, primarily to commoditize that information — especially for targeted advertising. Lately, the social costs of such business models has become increasingly apparent, including nonconsensual personal data collection, massive data breaches and, most notoriously, political manipulation.

So what happens when people put their ingenuity to work to dream up new products and services that require no personal data at all? What might such services look like? What can you do with nothing more than an anonymized username and a properly hashed password? To what degree can apps be designed to keep personal data solely on a personal device, or transmitted exclusively via end-to-end encryption? Who will build the first dating app on Signal?

I can’t wait to see what creative human minds — both constrained to limit data collection and, not at all paradoxically, freed from the demand to collect ever more personal data — will come up with. The next ten years of internet inventiveness will be fascinating to watch.


  1. This requirement has largely driven the avalanche of “We’ve updated privacy policy” messages in your inbox.

  2. Or to mount legal challenges that create the legal precedents for the interpretation of the GDPR.

  3. This Ian Bogost piece isn’t specifically about the professionalization of tech, but the appropriation of the title “engineer” by developers. Still, I hope that software developers will eventually adopt the Calling of the Engineer, which reads, in part, “My Time I will not refuse; my Thought I will not grudge; my Care I will not deny toward the honour, use, stability and perfection of any works to which I may be called to set my hand.” Ethical considerations will have to become a deep responsibility for software developers in the same way it has for structural and civil engineers.

  4. Like the old saw says: “Never implement your own crypto.” Hell, OpenSSL can’t even get it right.

iovation Tokenization

C’est mois, in the first of a series for the iovation blog:

Given our commitment to responsible data stewardship, as well as the invalidation of Safe Harbor and the advent of the GDPR, we saw an opportunity to reduce these modest but very real risks without impacting the efficacy of our services. A number of methodologies for data protection exist, including encryption, strict access control, and tokenization. We undertook the daunting task to determine which approaches best address data privacy compliance requirements and work best to protect customers and users — without unacceptable impact on service performance, cost to maintain infrastructure, or loss of product usability.

The post covers encryption, access control, and tokenization.