Which is the privacy principle that requires the collection of personal information?

A person's autonomy is their ability to make decisions of their own volition, without undue influence from other parties. People have limited intellectual resources and time with which to weigh decisions, and by necessity rely on shortcuts when making decisions. This makes their preferences, including privacy preferences, malleable and susceptible to manipulation ([Privacy-Behavior], [Digital-Market-Manipulation]). A person's autonomy is enhanced by a system or device when that system offers a shortcut that aligns more with what that person would have decided given arbitrary amounts of time and relatively unlimited intellectual ability; and autonomy is decreased when a similar shortcut goes against decisions made under such ideal conditions.

Affordances and interactions that decrease autonomy are known as dark patterns. A dark pattern does not have to be intentional ([Dark-Patterns], [Dark-Pattern-Dark]).

Because we are all subject to motivated reasoning, the design of defaults and affordances that may impact autonomy should be the subject of independent scrutiny.

Given the large volume of potential data-related decisions in today's data economy, complete informational self-determination is impossible. This fact, however, should not be confused with the idea that privacy is dead. Studies show that people remain concerned over how their data is processed, feeling powerless and like they have lost agency ([Privacy-Concerned]). Careful design of our technological infrastructure can ensure that people's autonomy with respect to their own data is enhanced through appropriate defaults and choice architectures.

Privacy principles are socially negotiated and the definition of privacy is essentially contested ([Privacy-Contested]). This makes privacy a problem of collective action ([GKC-Privacy]). Group-level data processing may impact populations or individuals, including in ways that people could not control even under the optimistic assumptions of consent. For example, based on group-level analysis, a company may know that site.example is predominantly visited by people of a given race or gender, and decide not to run its job ads there. Visitors to that page are implicitly having their data processed in inappropriate ways, with no way to discover the discrimination or seek relief ([Relational-Governance]).

What we consider is therefore not just the relation between the people who share data and the parties that invite that disclosure ([Relational-Turn]), but also between the people who may find themselves categorised indirectly as part of a group even without sharing data. One key understanding here is that such relations may persist even when data is de-identified. What's more, such categorisation of people, voluntary or not, changes the way in which the world operates. This can produce self-reinforcing loops that can damage both individuals and groups ([Seeing-Like-A-State]).

In general, collective issues in data require collective solutions. Web standards help with data governance by defining structural controls in user agents and establishing or delegating to institutions that can handle issues of privacy. Governance will often struggle to achieve its goals if it works primarily by increasing individual control instead of acting collectively.

Collecting data at large scales can have significant pro-social outcomes. Problems tend to emerge when actors process data for collective benefit and for self-dealing purposes at the same time. The self-dealing purposes are often justified as bankrolling the pro-social outcomes but this requires collective oversight to be appropriate.

The user agent acts as an intermediary between a person (its user) and the web. User agents implement, to the extent possible, the principles that collective governance establishes in favour of individuals. They seek to prevent the creation of asymmetries of information, and serve their user by providing them with automation to rectify automation asymmetries. Where possible, they protect their user from receiving intrusive messages.

The user agent is expected to align fully with the person using it and operate exclusively in that person's interest. It is not the first party. The user agent serves the person as a trustworthy agent: it always puts that person's interest first. In some occasions, this can mean protecting that person from themselves by preventing them from carrying out a dangerous decision, or by slowing down the person in their decision. For example, the user agent will make it difficult for that person to connect to a site if it can't verify that the site is authentic. It will check that that person really intends to expose a sensitive device to a page. It will prevent that person from consenting to the permanent monitoring of their behaviour. Its user agent duties include ([Taking-Trust-Seriously]):

These duties ensure the user agent will care for its user. In academic research, this relationship with a trustworthy agent is often described as "fiduciary" [Fiduciary-UA]. Some jurisdictions may have a distinct legal meaning for "fiduciary."

Many of the principles described in the rest of this document extend the user agent's duties and make them more precise.

While privacy principles are designed to work together and support each other, occasionally a proposal to improve how a system follows one privacy principle may reduce how well it follows another principle.

Principle

: When confronted with an apparent tradeoff, first look for ways to improve all principles at once.

Given any initial design that doesn't perfectly satisfy all principles, there are usually some other designs that improve the situation for some principles without sacrificing anything about the other principles. Work to find those designs.

Another way to say this is to look for Pareto improvements before starting to trade off between principles.

Once one is choosing between different designs at the Pareto frontier, the choice of which privacy principles to prefer is complex and depends heavily on the details of each particular situation. Note that people's privacy can also be in tension with non-privacy concerns. As discussed in the W3C TAG Ethical Web Principles, "it is important to consider the context in which a particular technology is being applied, the expected audience(s) for the technology, who the technology benefits and who it may disadvantage, and any power dynamics involved". Despite this complexity, there is a basic ground rule to follow:

Principle

: If a service needs to collect extra data from its users in order to protect those or other users, it must take extra technical and legal measures to ensure that this data can't be then used for other purposes, like to grow the service.

This is a special case of the more general principle that data should not be used for more purposes than the data's subjects understood it was being collected for.

A service should explain how it uses people's data to protect them and other people, and how it might additionally use someone's data if it believes that person has broken the rules.

It is attractive to say that if someone violates the norms of a service they're using, then they sacrifice a proportionate amount of their privacy protections, but

1. Often the service can only prevent the norm violation by also collecting data from innocent users. This extra collection is not always appropriate, especially if it allows pervasive monitoring ([RFC7258], [RFC7687]).
2. If a service operator wants to collect some extra data, it can be tempting for them to define norms and proportionality that allow them to do so.

The following examples illustrate some of the tensions:

A person's identity is the set of characteristics that define them. Their identity in a context is the set of characteristics they present to that context. People frequently present different identities to different contexts, and also frequently share an identity among several contexts.

Cross-context recognition is the act of recognising that an identity in one context is the same person as an identity in another context. Cross-context recognition can at times be appropriate but anyone who does it needs to be careful not to apply the principles of one context in ways that violate the principles around use of information acquired in a different context. (For example, if you meet your therapist at a cocktail party, you expect them to have rather different discussion topics with you than they usually would, and possibly even to pretend they do not know you.) This is particularly true for vulnerable people as recognising them in different contexts may force their vulnerability into the open.

In computer systems and on the Web, an identity seen by a particular website is typically assigned an identifier of some type, which makes it easier for an automated system to store data about that person. Examples of identifiers for a person can be:

• their name,
• an identification number including those mapping to a device that this person may be using,
• their phone number,
• their location data,
• an online identifier such as email or IP addresses, or
• factors specific to their physical, physiological, genetic, mental, economic, cultural, or social identity.

Strings derived from identifiers, for instance through hashing, are still identifiers so long as they may identify a person.

Principle

: A user agent should help its user present the identity they want in each context they find themself in.

Sometimes this means the UA should ensure that one site can't learn anything about their user's behavior on another site, while at other times the UA should help their user prove to one site that they have a particular identity on another site.

To do this, user agents have to make some assumptions about the borders between contexts. By default, user agents define a machine-enforceable context or partition as:

• A set of environments (roughly iframes (including cross-site iframes), workers, and top-level pages)
• whose top-level origins are in the same site (but see [PSL-Problems])
• being visited within the same user agent installation (and browser profile, container, or container tab for user agents that support those features)
• between points in time that the person or user agent clears that site's cookies and other storage (which is sometimes automatic at the end of each session).

Even though this is the default, user agents are free to restrict this context as people need. For example, some user agents may help people present different identities to subdivisions of a single site.

Issue 1: Figure out the default privacy boundary for the web

There is disagreement about whether user agents may also widen their machine-enforceable contexts. For example, some user agents might want to help their users present a single identity to multiple sites that the user understands represent a single party, or to a site across multiple installations.

User agents should prevent people from being recognized across machine-enforceable contexts unless they intend to be recognized. This is a "should" rather than a "must" because there are many cases where the user agent isn't powerful enough to prevent recognition. For example if two or more services that a person needs to use insist that they share a difficult-to-forge piece of their identity in order to use the services, it's the services behaving inappropriately rather than the user agent.

If a site includes multiple contexts whose principles indicate that it's inappropriate to share data between the contexts, the fact that those distinct contexts fall inside a single machine-enforceable context doesn't make sharing data or recognizing identities any less inappropriate.

Principle

: User agents should only share and present information about the user that the user can reasonably anticipate being shared, and which directly relate to the users overt, immediate goals. User agents and sites should be conservative when deciding if information is related to a users goals; the longer the chain of reasoning used to justify data collection, the less likely for that data collection to be ethical and principled.

Examples:

• Sharing geo-location data with a map website after a user has clicked a "share my location" button has a small number of "hops" between intent and data.
• Sharing information about the user's selected DNS resolver with a site, so that the site authors can debug possible issues around tail/uncommon resolvers, has a large number of "hops" between user intent (to do a thing on the website) and collection motivation (users like our site, so users will want to share information with us to help us improve the site).

Principle

: User agents should generally not attempt to distinguish between sensitive and nonsensitive personal data; all data and personal information is likely to be sensitive to some users, often in ways unanticipated by browser vendors and site operators.

Principle

: User agents should always aim to share the minimal amount of information with a site that is needed for the user to achieve a user's goals. Data collected today can often be used in unanticipated ways in the future to enact privacy harms, even data that seems unlikely to be identifying, sensitive or otherwise privacy-harming.

Contributes to correlation, identification, secondary use, and disclosure.

Many pieces of information about someone could cause privacy harms if disclosed. For example:

• Their location.
• Video or audio from the their camera or microphone.
• The content of certain files on their filesystem.
• Financial data.
• Contacts.
• Calendar entries.
• Whether they are using assistive technology.
• ...

A particular piece of information may have different sensitivity for different people. Language preferences, for example, might typically seem innocent, but also can be an indicator of belonging to an ethnic minority. Precise location information can be extremely sensitive (because it's identifying, because it allows for in-person intrusions, because it can reveal detailed information about a person's life) but it might also be public and not sensitive at all, or it might be low-enough granularity that it is much less sensitive for many people.

When considering whether a class of information is likely to be sensitive to a person, consider at least these factors:

• whether it serves as a persistent identifier (see severity in Mitigating browser fingerprinting);
• whether it discloses substantial (including intimate details or inferences) information about the the person using the system or other people;
• whether it can be revoked (as in determining whether a permission is necessary);
• whether it enables other threats, like intrusion.

Issue(16): This description of what makes information sensitive still needs to be refined.

People have certain rights over data that is about themselves, and these rights should be facilitated by their user agent and the parties that are processing their data.

While data rights alone are not sufficient to satisfy all privacy principles for the Web, they do support self-determination and help improve accountability. Such rights include:

• The right to access data about oneself.

This right includes being able to discover data about oneself (implying no databases are kept secret) and to review what information has been collected or inferred.

• The right to erase data about oneself.

The right to erase applies whether or not terminating use of a service altogether, though what data can be erased may differ between those two cases. On the Web, people may wish to erase data on their device, on a server, or both, and the distinctions may not always be clear.

• The right to port data, including data one has stored with a party, so it can easily be reused or transferred elsewhere.

Portability is needed to realize the ability for people to make choices about services with different data practices. Standards for interoperability are essential for effective re-use.

• The right to correct data about oneself, to ensure that one's identity is properly reflected in a system.

• The right to be free from automated decision-making based on data about oneself.

For some kinds of decision-making with substantial consequences, there is a privacy interest in being able to exclude oneself from automated profiling. For example, some services may alter the price of products (price discrimination) or offers for credit or insurance based on data collected about a person. Those alterations may be consequential (financially, say) and objectionable to people who believe those decisions based on data about them are inaccurate or unjust. As another example, some services may draw inferences about a user's identity, humanity or presence based on facial recognition algorithms run on camera data. Because facial recognition algorithms and training sets are fallible and may exhibit certain biases, people may not wish to submit to decisions based on that kind of automated recognition.

• The right to object, withdraw consent, and restrict use of data about oneself.

People may change their decisions about consent or may object to subsequent uses of data about themselves. Retaining rights requires ongoing control, not just at the time of collection.

The OECD Privacy Principles [OECD-Guidelines], [Records-Computers-Rights], and the [GDPR], among other places, include many of the rights people have as data subjects. These participatory rights by people over data about themselves are inherent to autonomy.

Data is de-identified when there exists a high level of confidence that no person described by the data can be identified, directly or indirectly (e.g. via association with an identifier, user agent, or device), by that data alone or in combination with other available information. Note that further considerations relating to groups are covered in the Collective Issues in Privacy section.

We talk of controlled de-identified data when there are strict controls that prevent the re-identification of people described by the data except for a well-defined set of purposes.

Different situations involving controlled de-identified data will require different controls. For instance, if the controlled de-identified data is only being processed by one party, typical controls include making sure that the identifiers used in the data are unique to that dataset, that any person (e.g. an employee of the party) with access to the data is barred (e.g. based on legal terms) from sharing the data further, and that technical measures exist to prevent re-identification or the joining of different data sets involving this data, notably against timing or k-anonymity attacks.

In general, the goal is to ensure that controlled de-identified data is used in a manner that provides a viable degree of oversight and accountability such that technical and procedural means to guarantee the maintenance of pseudonymity are preserved.

This is more difficult when the controlled de-identified data is shared between several parties. In such cases, good examples of typical controls that are representative of best practices would include making sure that:

• the identifiers used in the data are under the direct and exclusive control of the first party who is prevented by strict controls from matching the identifiers with the data;

• when these identifiers are shared with a third party, they are made unique to that third party such that if they are shared with more than one third party these cannot then match them up with one another;

• there is a strong level of confidence that no third party can match the data with any data other than that obtained through interactions with the first party;

• any third party receiving such data is barred (eg. based on legal terms) from sharing it further;

• technical measures exist to prevent re-identification or the joining of different data sets involving this data, notably against timing or k-anonymity attacks; and

• there exist contractual terms between the first party and third party describing the limited purpose for which the data is being shared.

Note that controlled de-identified data, on its own, is not sufficient to render data processing appropriate.

Principle

: Groups and various forms of institutions should best protect and support autonomy by making decisions collectively rather than individually to either prevent or enable data sharing, and to set defaults for data processing rules.

Privacy principles are often defined in terms of extending rights to individuals. However, there are cases in which deciding which principles apply is best done collectively, on behalf of a group.

One such case, which has become increasingly common with widespread profiling, is that of information relating to membership of a group or to a group's behaviour, as detailed in 1.2.1 Group Privacy. As Brent Mittelstadt explains, “Algorithmically grouped individuals have a collective interest in the creation of information about the group, and actions taken on its behalf.” ([Individual-Group-Privacy]) This justifies ensuring that grouped people can benefit from both individual and collective means to support their autonomy with respect to data processing. It should be noted that processing can be unjust even if individuals remain anonymous, not from the violation of individual autonomy but because it violates ideals of social equality ([Relational-Governance]).

Another case in which collective decision-making is preferable is for processing for which informed individual decision-making is unrealistic (due to the complexity of the processing, the volume or frequency of processing, or both). Expecting laypeople (or even experts) to make informed decisions relating to complex data processing or to make decisions on a very frequent basis even if the processing is relatively simple, is unrealistic if we also want them to have reasonable levels of autonomy in making these decisions.

The purpose of this principle is to require that data governance provide ways to distinguish appropriate data processing without relying on individual decisions whenever the latter are impossible, which is often ([Relational-Governance], [Relational-Turn]).

Which forms of collective governance are recognised as legitimate will depend on domains. These may take many forms, such as governmental bodies at various administrative levels, standards organisations, worker bargaining units, or civil society fora.

It must be noted that, even though collective decision-making can be better than offloading privacy labour to individuals, it is not necessarily a panacea. When considering such collective arrangements it is important to keep in mind the principles that are likely to support viable and effective institutions at any level of complexity ([IAD]).

A good example of a failure in collective privacy decisions was the standardisation of the ping attribute. Search engines, social sites, and other algorithmic media in the same vein have an interest in knowing which sites that they link to people choose to visit (which in turn could improve the service for everyone). But people may have an interest in keeping that information private from algorithmic media companies (as do the sites being linked to, as that facilitates timing attacks to recognise people there). A person's exit through a specific link can either be tracked with JavaScript tricks or through bounce tracking, both of which are slow and difficult for user agents to defend against. The value proposition of the ping attribute in this context is therefore straightforward: by providing declarative support for this functionality it can be made fast (the browser sends an asynchronous notification to a ping endpoint after the person exits through a link) and the user agent can provide its user with the option to opt out of such tracking — or disable it by default.

Unfortunately, this arrangement proved to be unworkable on the privacy side (the performance gains, however, are real). What prevents a site from using ping for people who have it activated and bounce tracking for others? What prevents a browsers from opting everyone out because it wishes to offer better protection by default? Given the contested nature of the ping attribute and the absence of a forcing function to support collective enforcement, the scheme failed to deliver improved privacy.

Receiving unsolicited information that either may cause distress or waste the recipient's time or resources is a violation of privacy.

Principle

: User agents and other actors should take steps to ensure that their user is not exposed to unwanted information. Technical standards must consider the delivery of unwanted information as part of their architecture and must mitigate it accordingly.

Unwanted information covers a broad range of unsolicited communication, from messages that are typically harmless individually but that become a nuisance in aggregate (spam) to the sending of images that will cause shock or disgust due to their graphic, violent, or explicit nature (eg. pictures of one's genitals). While it is impossible, in a communication system involving many people, to offer perfect protection against all kinds of unwanted information, steps can be taken to make the sending of such messages more difficult or more costly, and to render the senders more accountable. Examples of mitigations include:

• Restricting what new users of a service can post, notably limiting links and media until they have interacted a sufficient number of times over a given period with a larger group. This helps to raise the cost of producing sockpuppet accounts and gives new users the occasion to understand local norms before posting.
• Only accepting communication between people who have an established relationship of some kind, such as being part of a shared group. Protocols should consider requiring a handshake between people prior to enabling communication.
• Requiring a deliberate action from the recipient before rendering media coming from an untrusted source.
• Supporting the ability for people to block a party such that they cannot send information again.
• Pooling mitigation information, for instance shared block lists, shared spam-detection information, or public information about misbehaving actors. As always, the collection and sharing of information for safety purposes should be limited and placed under collective governance.

Principle

: When any actor obtains consent for processing from a person, the actor should design the consent request so as to learn the person's true intent to consent or not, and not to maximize the processing consented to.

Attempts to obtain consent to processing that is not in accordance with the person's true preferences result in imposing unwanted privacy labour on the person, and may result in people erroneously giving consent that they regret later.

Principle

: An actor should avoid interrupting a person's use of a site for consent requests when an alternative is available.

Examples of alternatives to interrupting users with consent requests include:

• Considering the information sharing norms in the site's audience and category, and requesting only consent that is appropriate to the purpose of the site. (For example, a photo sharing site's users might expect to be prompted for consent to share their uploaded work.) Sites should consider conducting user research on people's expectations for how data is processed.

• Relying on a global opt-out signal from the user agent.

• Delaying a prompt for consent until a user does something that puts the request in context, which will also help them give an informed response.

Principle

: It should be as easy for a user to check what consent they have given, to withdraw consent, or to opt out or object, as to give consent.

Notifications and other interruptive UI can be a powerful way to capture attention. Depending on the operating system in use, a notification can appear outside of the browser context (for example, in a general notifications tray) or even cause a device to buzz or play an alert tone. Like all powerful features, notifications can be misused and can become an annoyance or even used to manipulate behaviour and thus reduce autonomy.

Principle

: A user agent should help users control notifications and other interruptive UI that can be used to manipulate behavior.

User agents should provide UI that allows their users to audit which web sites have been granted permission to display alerts and to revoke these permissions. User agents should also apply some quality metric to the initial request for permissions to receive notifications (for example, disallowing sites from requesting permission on first visit).

Principle

: Web sites should use notifications only for information that their users have specifically requested.

Web sites should tell their users what specific kind of information people can expect to receive, and how notifications can be turned off, when requesting permission to send interruptive notifications. Web sites should not request permission to send notifications when the user is unlikely to have sufficient knowledge (e.g. information about what kinds of notifications they are signing up for) to make an informed response. If it's unlikely that such information could have been provided then the user agent should apply mitigations (for example, warning about potential malicious use of the notifications API). Permissions should be requested in context.

Whenever people have the ability to cause a party to process less of their data or to stop carrying out some given set of data processing that is not essential to the service, they must be allowed to do so without the party retaliating, for instance by artificially removing an unrelated feature, by decreasing the quality of the service, or by trying to cajole, badger, or trick the person into opting back into the processing.

A person (also user or data subject) is any natural person. Throughout this document, we primarily use person or people to refer to human beings, as a reminder of their humanity. When we use the term user, it is to talk about the specific person who happens to be using a given system at that time.

A vulnerable person is a person who may be unable to exercise sufficient self-determination in a context. Amongst other things, they should be treated with greater default privacy protections and may be considered unable to consent to various interactions with a system. People can be vulnerable for different reasons, for example because they are children, are employees with respect to their employers, are facing a steep asymmetry of power, are people in some situations of intellectual or psychological impairment, are refugees, etc.

A context is a physical or digital environment that a person interacts with for a set of purposes (that they typically share with other people who interact with the same environment).

A party is an entity that a person can reasonably understand as a single "thing" they're interacting with. Uses of this document in a particular domain are expected to describe how the core concepts of that domain combine into a user-comprehensible party, and those refined definitions are likely to differ between domains.

User agents tend to explain to people which origin or site provided the web page they're looking at. The party that controls this origin or site is known as the web page's first party. When a person interacts with a UI element on a web page, the first party of that interaction is usually the web page's first party. However, if a different party controls how data collected with the UI element is used, and a reasonable person with a realistic cognitive budget would realize that this other party has this control, this other party is the first party for the interaction instead.

The first party to an interaction is accountable for the processing of data produced by that interaction, even if another party does the processing.

A third party is any party other than the person visiting the website or the first parties they expect to be interacting with.

The Vegas Rule is a simple implementation of privacy in which "what happens with the first party stays with the first party." Put differently, the Vegas Rule is followed when the first party is the only data controller. While the Vegas Rule is a good guideline, it's neither necessary nor sufficient for appropriate data processing. A first party that maintains exclusive access to a person's data can still process it inappropriately, and there are cases where a third party can learn information about a person but still treat it appropriately.

We define personal data as any information that is directly or indirectly related to an identified or identifiable person, such as by reference to an identifier ([GDPR], [OECD-Guidelines], [Convention-108]).

If a person could reasonably be identified or re-identified when data is combined with other data, then that makes that data personal data.

Privacy is achieved in a given context that either involves personal data or involves information being presented to people when the principles of that context are followed appropriately. When the principles for that context are not followed, there is a privacy violation. Similarly, we say that a particular interaction is appropriate when the principles are adhered to) or inappropriate otherwise.

A party processes data if it carries out operations on personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, , dissemination or otherwise making available, selling, alignment or combination, restriction, erasure or destruction.

A party data if it provides it to any other party. Note that, under this definition, a party that provides data to its own service providers is not it.

A party sells data when it it in exchange for consideration, monetary or otherwise.

The purpose of a given processing of data is an anticipated, intended, or planned outcome of this processing which is achieved or aimed for within a given context. A purpose, when described, should be specific enough to be actionable by someone familiar with the relevant context (ie. they could independently determine means that reasonably correspond to an implementation of the purpose).

The means are the general method of data processing through which a given purpose is implemented, in a given context, considered at a relatively abstract level and not necessarily all the way down to implementation details. Example: a person will have their preferences restored (purpose) by looking up their identifier in a preferences store (means).

A data controller is a party that determines the means and purposes of data processing. Any party that is not a service provider is a data controller.

A service provider or data processor is considered to be the same party as the actor contracting it to perform the relevant processing if it:

• is processing the data on behalf of that party;
• ensures that the data is only retained, accessed, and used as directed by that party and solely for the list of explicitly-specified purposes detailed by the directing party or data controller;
• may determine implementation details of the data processing in question but does not determine the purpose for which the data is being processed nor the overarching means through which the purpose is carried out;
• has no independent right to use the data other than in a de-identified form (e.g., for monitoring service integrity, load balancing, capacity planning, or billing); and,
• has a contract in place with the party which is consistent with the above limitations.