Organize the document coherently

[jyasskin]

Since our document started as a concatenation of two independent documents, at some point we'll need to refactor the whole thing into a coherent whole. I'm starting to get a picture of how we might do that, which I'll outline here.

1. Introduction
2. Interesting Definitions
   1. People
   2. Data
   3. Parties
   4. Acting on Data
   5. "purpose" and "means" definitions, from later sections.
3. User Agents
4. Identity
   1. Cross-context recognition, possibly mixed together with the Identity section
5. Ethical Data Use
   1. Personal Control and Autonomy
   2. Contexts
   3. Opt-in, Consent, Opt-out, Global Controls

   4. 73

   5. Sensitive information disclosure
   6. Unexpected profiling
   7. Collective issues
6. Intrusive behavior
7. Powerful capabilities
8. Boring Definitions

I think we could further reorganize the sections under "Ethical Data Use" by thinking about how the grounds for lawful processing, for example from the GDPR map to the principles we'd like organizations to use when deciding how to process data. For example, data use is ok if it's clear to the user that it's necessary to do what they asked; freely-given consent makes data use ok; data use to protect user safety is generally ok; use that's in-line with contextual expectations is generally ok; etc.

[darobin]

I've been thinking along similar lines, but one thing that I've been wondering about is if it might be worth taking a minute to think about the audience and how that relates to the structure. We sort of did the standard standard thing of starting with definitions and basically writing for implementers. Depending on who this is for, that could prove daunting. (I'll note however that laws work that way too: you get all the definitions first, which you'll never remember, and then the rules.)

I don't have a set or preferred answer yet, I just got to that point after mulling over more contextualised approaches.

[dmarti]

Two of the most important audiences are

• venture capitalists

  • chief marketing officers

  Both are interested in investing with medium or long time horizons, and would prefer a more future-proof startup or in-house project over one that is likely to keep working only until mainstream web developers fix whatever incompletely implemented privacy principle was enabling it.

[darobin]

Ok — I took a stab at a reorg along different lines, the idea being to make it more narrative from why do we even care, to what even is this, to what can we even do about it. I wrote out some bits to give context; the lists of items are parts that get moved around from the doc (definitions or sections).

This is a significant change of angle because it treats privacy as a means to an ends in designing a Web that is explicitly for people and to balance out power structures. I like this kind of approach, but it's perhaps more explicitly political than has been typical of TAG docs.

Privacy Principles — Robin Remix

This is a quick and dirty rewrite following Jeffrey's invitation and our recent discussion about how to present the content better than through the concatenation of two documents. I am only including sketches of the content to give a sense for where they fit and why; it's not a proper rewrite.

Why Privacy

The Web is for everyone. This means that it needs to be built to serve people and to serve human values. One of the ways in which the Web can serve people is by protecting them in the face of asymmetries of power.

Information is power. It can be used to predict and to influence people, as well as to design online spaces that control people's behaviour. What's more, automation renders information more efficient.

Privacy is about the rules that govern information flows, and more precisely it is about how these rules constrain and distribute the power of information between different actors. Struggles over privacy are struggles over the rules that govern the power of data, they are about data governance. The focus of this document concerns leveraging this power differential against people, but the same techniques are also used to leverage the power of information against other entities, such as companies or governments.

There are always privacy rules — the question is which ones best serve human values. So privacy is instrumental to using data in service of a space designed for everyone.

A data system designed for people is one in which people remain effectively able to reason about what is known about them. This means working to prevent hidden parties from acquiring such information, preventing any party from acquiring too much information about a person particularly in cross-referencing from multiple sources, restricting applications of this data that are hostile to people. [this needs all kinds of better phrasing]

Move here:

• automation asymmetry
• Opt-in, Out, Consent, Global opt out
• Personal Control and Autonomy (parts of)
• dark patterns
• privacy labour

What Is Privacy

Establishing privacy as rules for the power of data within an institutional framework, using CI to describe rule system, agents, structures. This might benefit from some Ostrom too. Keep in mind to make context a set of purposes.

• The Parties
  • party, first party, third party
  • service provider or processor
  • data controller
• Contexts & Privacy
  • purpose, means
  • context (and sub-notions)
  • defining privacy
  • tracking

How To Implement Privacy

A principled overview of how to make the rules real.

Privacy Threats on the Web

• High-Level Threats
• Unwanted Cross-Context Recognition
• Sensitive information disclosure
• Unexpected profiling
• Intrusive behavior
• Powerful capabilities
• vulnerable person (considering including here as a threat similar to a11y failures: people who design in ablist ways — otherwise it can go next to dark patterns above)

It's Your Browser

What the UA can do to protect from asymmetries.

• User Agents
  • trustworthy and related

Browser Protections

This is a discussion of what we can expect browsers to do.

• Identity
  • cross-context recognition
  • machine-enforceable context, partition

Data Processor Protections

This is a discussion of some practices that entities processing data can apply, not all of them good.

• de-identified and controlled de-identified
• FIPs
• Vegas Rule

Data Governance

This covers the rules & institutions that might not be supported directly by browsers, but that we expect from hunman-centric systems that. Also how this relates to trust and how trust gets created.

This would include collective governance for security systems. Maybe also mention that consent is individualistic and imbalances of power can often be best redressed using collective tools.

• Collective Issues
  • POSIWID
  • legibility
  • legitimate & illegitimate
  • reflexivity
  • data governance

Appendix: Common Concepts

This section contains definitions for terms mentioned in the document that are not defined before they are used. The idea is that, if a term is common enough that people will naturally understand it but that it could nevertheless benefit from a strict definition in order to provide a common foundation for debate, then it goes here.

• person
• personal data
• processes, shares, sells

Notes

• Add MaxG to the acks for the serendipitous discussion that helped this structure gel.
• Update reference to Salmoé's work

[sandandsnow]

@jyasskin and @darobin thank you for proposing some ideas for restructuring the document. I like the approach of identifying privacy threats on the Web + discussing the various ways these threats are or can be addressed + the set of W3C privacy principles for the Web. I might move principles to the middle or even right up front. I'm less convinced that the document should discuss at length "why privacy". This is an important topic, but not for this document. On the topic of "what is privacy", I would rephrase to something more along the lines of "what does privacy mean on the Web" or "what is Web privacy" or ...