Breaking the Privacy Stalemate - Transparency

Stop trying to get websites to explain themselves; instead, build tools that explain them

Here’s the follow up post elaborating on the idea for a browser extension transparency tool – a tool which would help make transparency work in ways that privacy notices can’t. The key premise is we should stop trying to get websites to explain themselves; instead, build tools that explain them. Below, I walk through the vision, product features, design principles and development strategies for a tool that would do just that.

And let’s give “the tool” a name: how about the “Navigator”? Calling it “The Tool” isn’t very evocative, plus it reminds me of an unfortunate college freshman (not me) who got tagged with that nickname. What I have in mind is a digital sextant – a tool for helping people find their way using no more than patterns in points of light.

But first, we need a time machine. About 25 years ago, I was part of a conversation about how technology could provide users with a way to see what was going on with their data under the hood, without requiring consumers to be particularly technical. That project didn’t take off as many of us hoped, but why it didn’t pan out is useful to understanding what might actually work now.

As some of you will remember, the “Platform for Privacy Specification” was an Internet protocol designed starting in the late 90’s and codified by the W3C standards body in 2002. The aim was described as “to enable an expanded ecosystem in which web sites would consistently inform web user agents of personal data collection intentions and web users would configure their individual user agents to accept some practices automatically without the user having to read the policy or to prompt the user for further instruction when the site’s practice exceeded the users’ prior election.”

P3P was a response to the same concerns I identified here – visitors to websites were in the dark about what those sites were doing with their data. P3P also envisioned expanding options for user control by enabling browsers to compare user preferences against website policies, potentially warning users or allowing them to limit data exchanges (like cookies) if they didn’t like what they saw. Lorrie Cranor, a professor at Carnegie-Mellon, shouldered a lot of the work on this idea but it was a collective endeavor.

There were some really cool prototypes like Privacy Bird, which used a simple green‑yellow‑red icon to indicate whether a site’s privacy policy matched user preferences. And it did get some traction via Microsoft, who built P3P into the Internet Explorer 6 browser. IE6 introduced user-configurable privacy settings tied to P3P and used P3P compact policies to decide whether to accept or block cookies, especially third-party cookies, and surfaced machine-readable privacy summaries to users.

Some stakeholders thought this could eventually lead to greater user control of not only privacy but online identity (who am I, how do you know, and what do I say is OK to do with my data?). One of those stakeholders was me and a coalition of companies for which I was the public policy spokesperson, and at the time we were all pretty jazzed about the idea.

Eventually, though, the music ended. The general idea is still useful in some ways – the IEEE just this past January codified standards on machine-readable privacy notices – but alas, P3P was not built to scale. Despite being an elegant idea, it’s now an obsolete protocol. And Internet Explorer was officially retired in 2022.

There’s not space in this post to go through all the reasons it didn’t take off so I’m going to stick to the three things that matter most for the “Navigator” – things we can now address. First, P3P envisioned a symmetry that doesn’t exist (if it ever did). User browsers could indicate privacy preferences and websites could ignore them; the only rule was a website had to declare its own practices (and abide by its declaration). Second, it assumed users would take the time to configure detailed privacy preferences in advance. Especially when consumers aren’t aware of what’s at stake, that’s unlikely. Third, P3P required websites to do stuff they wouldn’t otherwise do, i.e., make a privacy notice machine readable.

I relate all this history because what I’ve described for a “Navigator” tool may seem similar but it’s actually the opposite in many ways. First, it assumes the Thucydides rule about “power will do what it wants” applies. Rather than assume symmetry between websites and their visitors, Navigator assumes a power imbalance, meaning user preferences won’t dictate website behavior.

Secondly, what is different from 2002 in a big way, is AI. Because of AI, the analysis of privacy notices and the rendering of natural language interpretations is viable in ways it simply wasn’t at the time of P3P’s launch (yes, AI can, and at some point almost certainly will, make mistakes, and I’ll come back to that point). But we now have tools that can interpret messy, inconsistent signals in real time without relying on cooperation.

Third, Navigator doesn’t require websites to do anything, and it doesn’t require users to do anything other than click the button. There’s low probability the US market would get websites to reliably self-report in a machine-readable format across the entire open web. US websites are already haphazard in tracking opt-outs via browser tools – such as the Global Privacy Control – and that’s legally required in several states. Let websites go work on GPC compliance and we can work on transparency without bothering them to make technical changes.

With all of that on the table, here’s what a Navigator browser extension would look like, at the foundational principles layer, the technical layer and the UX layer.

Basic Principles

· Entirely free and open source (save for maybe UX innovations and branding)

· Stateless – processes only strictly necessary data, with no persistent data storage.

· UX prioritizes elegance over functionality.

o One click for a clean panel with relevant information.

o Non-technical, plain English responses

· Factual responses, neutral in tone, double checked and not overstated.

o This is for legal protection as well as to support an “awareness first” design principle. That is, we want to inform so as to enable user choice, not make choices for them and leave web activity obscure.

o The Navigator would complement, not replace, existing ad tech blockers.

Design Elements – Technical Layer

Two capabilities sit at the core: tracking detection and categorization, and text analysis.

1) A Tracker Detection and Categorizer Engine

This is the component that observes what the page is actually loading. It would analyze outbound requests from the page to assess what they’re designed to do. This is similar to how ad blockers work today, and it could build on open-source elements such as the ‘Lightbox” known tracker list coordinated by Disconnect.me – available as an API – and/or coordinate with tools like Privacy Badger or Ghostery.

2) A Privacy Policy Analyzer

Bearing in mind I’m not an engineer, seems to me this component would be a set of software instructions to find the privacy notice URL, fetch that content, parse it as needed to make it analyzable (is that a word?), send the text to an LLM with a prompt to extract certain answers (such as what data is collected), double check those answers, and then render a plain English summary of key points.

Then, prompt the AI to compare and reconcile. For example, flag if the privacy notice is internally inconsistent. Or if the notice says the website doesn’t do something but the cookie, tag, or pixel that’s designed to be used for that activity is observed on the site. And then, finally, generate a plain-English explanation – again, factual and neutral – as to what it finds.

These two technical components seem to this non-technical writer to suffice to perform the primary functions. It would also need, of course, all the usual components of a browser extension, and to comply with the technical requirements and design rules of the major browsers. It could also include some functionality to explain how the user’s browser is currently set up, what options they have to set it differently, and how to do that (I’ve already used help from AI to help me adjust my browser settings, and I’m supposed to understand these things). But not much more. Keep it simple at all costs.

Design Elements – User Experience

Keep it simple at all costs is, also, what I’d recommend for the UX design. Steve Jobs studied calligraphy. He and Jony Ive made a computing interface that’s elegant. That elegance made the early Apple products great (I still have my 1987 Macintosh Classic). As Dieter Rams (the German designer whose minimalist ideas were applied to Braun appliances) famously said, “less, but better.”

Make it non-technical. Knowing that the website I’m visiting has something called “ga=GA1.2.123456789.1212000000” (or its equivalent) doesn’t raise user awareness. Responses like that could well make many people regret they cared enough to look in the first place. Unless they are fairly sophisticated at the technical aspects of website operation, in which case they are already part of the solution. We want to bring along with us ordinary, intelligent, curious people who care enough about where their data is going to ask basic questions.

In that light, Navigator would frame responses around questions users actually ask, like:

1. What does this site know about me?

2. Who else gets that information?

3. Can I stop it, and if so, how?

Framing the answers around categories – things like “first-party” or “third-party” or “analytics” – doesn’t get us where we want to go. The idea is to make the answers feel like part of a conversation.

Making the answers respond to user questions in a conversational manner helps keep responses factual and neutral. That in turn reduces the risks of legal action claiming Navigator is spreading harmful false information about the website. Responses should also distinguish between what Navigator directly observes (e.g., “this website has 14 third-party tags”) and what it infers based on known patterns (“this tag is typically used to see if what you do on the website is related to an online ad you saw elsewhere”). The Navigator is not designed to tell users what to do, just to tell them what’s happening, and do so through a chat conversation rather than a legal notice.

So to answer questions like “what does this site know about me?” Navigator would provide a few sentences about the types of tracking tools found, what data they collect, and what the privacy notice says. If Navigator finds a mismatch, it can say things like “I noticed something that doesn’t match what this site’s privacy policy says about what other parties can do with your data. Would you like to know more?” And then include links that pull up more detailed information.

Which brings me to AI. On one hand, using AI introduces complexity when I said we want simplicity. In the old cartoon “The Jetsons,” sophisticated robot can openers would go awry to throw into comic relief the fact that the manual tools worked simply fine before we got all neurotic about “modern conveniences.” In the P3P machine-readability approach, the code says what it says and that’s pretty much it. Simple.

But that simplicity was also a key weakness. P3P assumed websites could, and would, speak clearly, consistently, and honestly. The Navigator idea doesn’t assume that will be the case. AI enables a tool that can just listen to what they say and (stochastically) parrot it back.

Querying an LLM to have it summarize the notice it finds (assuming it finds the right URL and can read what’s there) involves the familiar risks of AI error. That can be addressed, though, with familiar safeguards: grounding rules so the elements of the response are linkable to original sources, legal disclaimers and notices, and periodic testing. Also, making the responses simple and structured reduces the chances that the AI goes off on a long rambling discourse.

Which is what this post is at risk of becoming, so I’ll stop here – and invite questions. Is designing this “Navigator” a helpful tactic? Could the Navigator make API calls to LLMs that are truly not linkable to a person or device? What refinements would help make what’s actually happening visible in a way ordinary people can understand? Thanks for any comments or corrections – and thanks for reading!