That’s what we’re starting this Thursday (26 April) at GDPR Hack Day at MIT.

The GDPR‘s “sunrise day” — when the EU can start laying fines on companies for violations of it — is May 25th. We want to be ready for that: with a cookie of our own baking that will get us past the “gauntlet walls” of consent requirements that are already appearing on the world’s commercial websites—especially the ad-supported ones.

The reason is this:

Which you can also see in a search for GDPR.

Most of the results in that search are about what companies can do (or actually what companies can do for companies, since most results are for companies doing SEO to sell their GDPR prep services).

We propose a simpler approach: do what the user wants. That’s why the EU created the GDPR in the first place. Only in our case, we can start solving in code what regulation alone can’t do:

  1. Un-complicate things (for example, relieving sites of the need to put up a wall of permissions, some of which are sure to obtain grudging “consent” to the same awful data harvesting practices that caused the GDPR in the firs place).
  2. Give people a good way to start signaling their intentions to websites—especially business-friendly ones
  3. Give advertisers a safe way to keep doing what they are doing, without unwelcome tracking
  4. Open countless new markets by giving individuals better ways of signaling what they want from business, starting with good manners (which went out the window when all the tracking and profiling started)

What we propose is a friendly way to turn off third party tracking at all the websites a browser encounters requests for permission to track, starting with a cookie that will tell the site, in effect, first party tracking for site purposes is okay, but third party tracking is not.

If all works according to plan, that cookie will persist from site to site, getting the browser past many gauntlet walls. It will also give all those sites and their techies a clear signal of intention from the user’s side. (All this is subject to revision and improvement as we hack this thing out.)

This photo of the whiteboard at our GDPR session at IIW on April 5th shows how wide ranging and open our thinking was at the time:

Photos from the session start here. Click on your keyboard’s right (>) arrow to move through them. Session notes are on the IIW wiki here.

Here is the whiteboard in outline form:

Possible Delivery Paths

Carrots

  • Verifiable credential to signal intent
  • Ads.txt replaced by a more secure system + faster page serving
  • For publishers:
    • Ad blocking decreases
    • Subscriptions increase
    • Sponsorship becomes more attractive
  • For advertisers
    • Branding—the real kind, where pubs are sponsored directly—can come back
    • Clearly stated permissions from “data subjects” for “data processors” and “data controllers” (those are GDPR labels)
    • Will permit direct ads (programmatic placement is okay; just not based on surveillance)
    • Puts direct intentcasting from data subject (users) on the table, replacing adtech’s spying and guesswork with actual customer-driven leads and perhaps eventually a shopping cart customers take from site to site
    • Liability reduction or elimination
    • Risk management
    • SSI (self-sovereign identity) / VC (verified credential) approach —> makes demonstration of compliance automateable (for publishers and ad creative)
    • Can produce a consent receipt that works for both sides
    • Complying with a visitor’s cookie is a lot easier than hiring expensive lawyers and consultants to write gauntlet walls that violate the spirit of the GDPR while obtaining grudging compliance from users with the letter of it

Sticks

  • The GDPR, with ePrivacy right behind it, and big fines that are sure to come down
  • A privacy manager or privacy dashboard on the user’s side, with real scale across multiple sites, is inevitable. This will help bring one into the world, and sites should be ready for it.
  • Since ample research (University of Pennsylvania, Annenberg, PageFair) has made clear that most users do not want to be tracked, browser makers will be siding eventually, inevitably, with those users by amplifying tracking protections. The work we’re doing here will help guide that work—for all browser makers and add-on developers

Participating organizations (some onboard, some partially through individuals)

Sources

Additions and corrections to all the above are welcome.

So is space somewhere in Cambridge or Boston to continue discussions and hackings on Friday, April 27th.