Change of Address (√)

Way back in 2006 or so, in the first Project VRM meetings, our canonical use case was ‘change of address’; that is to say, we wanted individuals to have the ability to update their address in one place and have that flow to multiple suppliers.

That seemed easy enough, so we thought at the time; all that’s needed is:

– a data store controlled by the individual

– a user interface

– an API that allowed organisations to connect

We did not note the need at the time, but there probably should have been one around ‘standardised data sharing terms’ so that organisations would not get tied in legal knots signing many different contracts to cover themselves as they would need to do.

So, 12 or so years later, that proved to not be quite so easy….. I think our most flawed assumption was that organisations would see this as a good thing and be willing to get involved.

No matter, the reason for my post is to flag that individual driven change of address can now be done at Internet scale, albeit yes we still need to crack the adoption issue. There are also then a number of downstream use cases, e.g. where the address change must be verified.

Here’s a visual of how change of address works in the JLINC environment; the same principles could apply in other environments. The critical dependency is that both parties (individual and organisation) have their own data-sets that they voluntarily connect to each other.

Beyond the fact that this plumbing now demonstrably works at scale, I think the most interesting thing that has emerged from the JLINC deployment is the Standard Information Sharing Agreement. The requirement here is to have an agreement that works for both parties; here is the initial one built for JLINC. The expectation is that these will evolve over time and likely become life aspect/ sector specific (e.g. Health); but critically they will not mimic the current model where each organisation invents their own. The secondary function that I believe makes this scale is the ability to record every single data exchange that takes place should either or both parties need to refer to that downstream.

So, we can now tick the box around ‘change of address’, at least as working plumbing. The better news still is that the same plumbing and approach works for any type of data, or any data flow (so organisations sending data to Alice too). At least it should not take another 12 years to make that next use case work, which incidentally was ‘Intentcasting’; i.e. an individual being able to articulate what they are in the market for without losing control over that data.

How customers help companies comply with the GDPR

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, AnnenbergPageFair) 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.

The Only Way Customers Come First

— is by proffering terms of their own.

That’s what will happen when sites and services click “accept” to your terms, rather than the reverse.

The role you play here is what lawyers call the first party. Sites and services that agree to your terms are second parties.

As a first party, you get scale across all the sites and services that agree to your terms:

This the exact reverse of what we’ve had in mass markets ever since industry won the industrial revolution. But we can get that scale now, because we have the Internet, which was designed to support it. (Details here and here.)

And now is the time, for two reasons:

  1. We can make our leadership pay off for sites and services; and
  2. Agreeing with us can make sites and services compliant with tough new privacy laws.

Our first example is P2B1(beta), which might best be called #NoProfiling:

With #NoProfiling, we proffer a term that says—

This does a bunch of good things for advertising supported sites:

  1. It relieves them of the need to track us like animals everywhere we go, and harvest personal data we’d rather not give anybody without our permission.
  2. Because of #1, it gives them compliance with the EU’s General Data Protection Regulation (aka GDPR), which allows fines of “up to 10,000,000 EUR or up to 2% of the annual worldwide turnover of the preceding financial year in case of an enterprise, whichever is greater (Article 83, Paragraph 4),” or “a fine up to 20,000,000 EUR or up to 4% of the annual worldwide turnover of the preceding financial year in case of an enterprise, whichever is greater (Article 83, Paragraph 5 & 6).”
  3. It provides simple and straightforward “brand safety” directly from human beings, rather than relying on an industry granfalloon to do the same.
  4. It lets good publishers sell advertising to brands that want to sponsor journalism rather than chase eyeballs to the cheapest, shittiest sites.
  5. It provides a valuable economic signal from demand to supply in the open marketplace.

We’ll have other terms. As with #NoProfiling, those will also align incentives.