Cookies That Go the Other Way

[24 May 2019: A year after I wrote this post, Global Consent Manager an indirect descendant of the work described below, is in the world and doing the job. Check 'em out.]

The web—or at least the one we know today—got off on the wrong hoofs. Specifically, I mean with client-server, a distributed application structure that shouldn't subordinate one party to an other, but ended up doing exactly that, which is why the web today looks like this:

Image removed.

Clients come to servers for the milk of HTML, and get cookies as well.

The original cookie allowed the server to remember the client when it showed up again. Later the cookie would remember other stuff: for example, that the client was a known customer with a shopping cart.

Cookies also came to remember fancier things, such as that a client has agreed to the server's terms of use.

In the last decade, cookies also arrived from third parties, some for site analytics but mostly so clients could be spied on as they went about their business elsewhere on the web. The original purpose was so those clients could be given "relevant" and "interest-based" advertising. What matters is that it was still spying and a breach of personal privacy, no matter how well its perpetrators rationalize it. Simply put, websites and advertisers' interests end at a browser's front door. (Bonus link: The Castle Doctrine.)

Thanks to the EU's General Data Protection Regulation (GDPR), which comes into full force this Friday, that kind of spying is starting to look illegal. (Though loopholes will be found.) Since there is a world of fear about that, 99.x% of GDPR coverage is about how the new regulation affects the sites and services, and what they can do to avoid risking massive fines for doing what many (or most) of them shouldn't have been doing in the first place.

But the problem remains structural. As long as we're just "users" and "consumers," we're stuck as calves.

But we don't have to be. The web's underlying protocol, HTTP, is distributed and collaborative. It doesn't say we need to be subordinate to websites, always consenting to those sites' terms and policies. It doesn't even say we have to be calves to the websites' cows. Consent can go the other way.

And so can cookies. So let's bake some.

Such a cookie would say exactly what the client does and does not consent to. For example, our client might consent to first-party cookies for the site's own purposes, but to no third-party cookies.

There is already work underway. It began with a session on April 5th at the Internet Identity Workshop. Here's a shot of the whiteboard there:

Image removed.

And here are the session notes, on the IIW wiki.

That was followed by three days of hacking in and around MIT, starting here. The first code is from Sam Curren, on GitHub here. In the readme, Sam lists among the to-dos "Add cookie generating logic for IABE consent cookies." IABE refers to IAB Europe, which created advertisingconsent.eu (503'd as I write this), where there live clues to how a cookie of the client's own could speak to servers running IAB Europe code, turning off the "consent-walls" now going up in front of countless websites, as the GDPR approaches.

So this is a recruitment post. We're looking for help with this. If you're up for that, talk to me. Or go ahead and jump in at GitHub.

Doc Searls is editor-in-chief of Linux Journal, where he has been on the masthead since 1996. He is also co-author of The Cluetrain Manifesto (Basic Books, 2000, 2010), author of The Intention Economy: When Customers Take Charge (Harvard Business Review Press, 2012), a fellow of the Center for Information Technology & Society (CITS) at the University of California, Santa Barbara, and an alumnus fellow of the Berkman Klien Center for Internet & Society at Harvard University. He continues to run ProjectVRM, which he launched at the BKC in 2006, and is a co-founder and board member of its nonprofit spinoff, Customer Commons. Contact Doc through ljeditor@linuxjournal.com.

Load Disqus comments