Privacy Principles

A person's autonomy is their ability to make decisions of their own personal will, without undue influence from other actors. 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 deceptive patterns (or dark patterns). A deceptive 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 defined through social processes and, because of that, the applicable definition of privacy in a given context can be 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.

What we consider is therefore not just the relation between the people who share data and the actors that invite that sharing ([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, ensuring that researchers and regulators can discover group-level abuse, 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 by collective action.

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

A 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 to 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 someone 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]):

Duty of Protection

Protection requires user agents to actively protect their user's data, beyond simple security measures. It is insufficient to just encrypt at rest and in transit. The user agent must also limit retention, help ensure that only strictly necessary data is collected, and require guarantees from any actor that the user agent can reasonably be aware that data is shared to.

Duty of Discretion

Discretion requires the user agent to make best efforts to enforce principles by taking care in the ways it discloses the personal data that it manages. Discretion is not confidentiality or secrecy: trust can be preserved even when the user agent shares some personal data, so long as it is done in an appropriately discreet manner.

Duty of Honesty

Honesty requires that the user agent try to give its user information of which the user agent can reasonably be aware, that is relevant to them and that will increase their autonomy, as long as they can understand it and there's an appropriate time to do so. This is almost never when the person is trying to do something else such as read a page or activate a feature. The duty of honesty goes well beyond that of transparency that is often included in older privacy regimes. Unlike transparency, honesty can't hide relevant information in complex legal notices and it can't rely on very short summaries provided in a consent dialog. If the person has provided consent to processing of their personal data, the user agent should inform the person of ongoing processing, with a level of obviousness that is proportional to the reasonably foreseeable impact of the processing.

Duty of Loyalty

Because the user agent is a trustworthy agent, it is held to be loyal to the person using it in all situations, including in preference to the user agent's implementer. When a user agent carries out processing that is detrimental to its user's interests and instead benefits another actor, this is disloyal. Often this would benefit the user agent itself, in which case it is known as "self-dealing". Behaviour can be disloyal even if it is done at the same time as processing that is in the person's interest, what matters is that it potentially conflicts with that person's interest. Additionally, it is important to keep in mind that additional processing almost always implies additional risk. Therefore processing that is not explicitly in a user's interest is likely to be disloyal. Disloyalty is always inappropriate.

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-Law], [Fiduciary-Model], [Taking-Trust-Seriously]; see [Fiduciary-UA] for a longer informal discussion). Some jurisdictions may have a distinct legal meaning for "fiduciary." ([Fiduciary-Law])

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.

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" ([Ethical-Web]). Despite this complexity, there is a basic ground rule to follow:

It is attractive to say that if someone violates the rules 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 rule 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 rules 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 in that context. People frequently present different identities to different contexts, and also frequently share an identity among several contexts. People may also wish to present an ephemeral or anonymous identity, which is just a set of characteristics that is too small or unstable to be useful for following them through time.

It is important to keep in mind that a person's identities may often be distinct from whatever legal identity or identities they may hold.

Recognition is the act of realising that a given identity corresponds to the same person as another identity which may have been observed either in another context or in the same context but at a different time. A person can be recognized whether or not their legal identity or characteristics of their legal identity are included in the recognition.

In order to uphold the above principle, sometimes a user agent needs to prevent recognition, for instance so that one site can't learn anything about its user's behavior on another site. Other times, the user agent needs to support recognition, for instance to help its user prove to one site that they have a particular identity on another site. Similarly, a user agent can help its user to separate or communicate identity across repeat visits to the same site.

Data minimization limits the risks of data being disclosed or misused, and it also helps user agents more meaningfully explain the decisions their users need to make.

Because personal data may be sensitive in unexpected ways, or have risks of future uses that could be unexpected or harmful, minimization as a principle applies to personal data that is not currently known to be identifying, sensitive, or otherwise potentially harmful.

Note that this principle was further explored in an earlier TAG draft on Data Minimization in Web APIs.

The many APIs available to websites expose lots of data that can be combined into information about people, web servers, and other things. We can divide that information into three categories:

1. Information that's fine to expose, for example because a person or group with sufficient authority intended to expose that information or to do something that necessarily exposes the information, or because it's not about people at all. For example:

   • The geolocation and camera APIs ask whether a person wants to expose their data.
   • The URL a person is visiting must be sent to a server in order to navigate to that URL, and known private-information-retrieval methods are too expensive to avoid that exposure.
   • The distribution of Largest Contentful Paint timings for a website is about a website rather than about the people browsing it, even if the data that informs that measure can also reveal information about people.

2. Information that we don't want to expose and have a plausible plan for removing access to. For example, browsers are gradually removing the ability to join identities between different partitions.

3. Information that we'd rather not expose, but that we don't have a plausible plan for removing access to. For example:

   • Some users are disappointed that the page they're visiting can discover which link they clicked to leave that page. We can't block that information because the page can use HTTP redirects to learn it, and redirection is a core feature of the web.
   • Some users are disappointed that a page with permission to run JavaScript can record their pattern of interaction with that page. However, the page does this by using the same events it would use to make the page interactive, so we can't block this information access either.

   These principles don't describe exactly how to distinguish acceptable information from information we'd rather not expose. API designers instead need to balance the harm to users from exposing information against the harm to users from blocking that exposure. When in doubt, designers should ensure that different user agents can help their users balance the costs in different ways.

The following subsections discuss how to review an API proposal that exposes data that provides a new way to infer each of the above categories of information. They explain how to leave the web better than you found it.

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 in Web Specifications);
• whether it discloses substantial (including intimate details or inferences) information about 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.

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 both being able to review what information has been collected or inferred about oneself and being able to discover what actors have collected information about oneself. As a result, databases cannot be kept secret and data collected about people needs to be meaningfully discoverable by those people.

• 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 another actor, 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:

1. The state of the data is such that the information that could be used to re-identify an individual has been removed or altered, and
2. there is a process in place to prevent attempts to re-identify people and the inadvertent release of the de-identified data. ([De-identification-Privacy-Act])

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 actor, 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 actor) 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 actors. 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 (the actor a person is directly interacting with) 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 make data processing appropriate.

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.

Computing devices have owners, and those owners have administrator access to the devices in order to install and configure the programs, including user agents, that run on them. Sometimes, as in the cases of an employer providing a device to an employee, a friend loaning a device to their visitor, or a parent providing a device to their small child, the person using a device doesn't own the device or have administrator access to it. Other times, as in the cases of intimate partners or one relative helping another relative with their device, the owner and primary user of a device might not be the only person with administrator access. As a program running on a device, a user agent generally can't tell whether the administrator who has installed and configured it was authorized by the device's actual owner.

These relationships can involve power imbalances. A child may have difficulty accessing any computing devices other than the ones their parent provides. A victim of abuse might not be able to prevent their partner from having administrator access to their devices. An employee might have to agree to use their employer's devices in order to keep their job.

While a device owner has an interest and sometimes a responsibility to make sure their device is used in the ways they intended, the person using the device still has a right to privacy while using it. The above principles enforce this right to privacy in two ways:

1. User agent developers need to consider whether requests from device owners and administrators are reasonable, and refuse to implement unreasonable requests, even if that means fewer sales. Owner/administrator needs must not simply trump user needs in the priority of constituencies.
2. Even when information disclosure is reasonable, the person whose data is being disclosed needs to know about it so that they can avoid doing things that would lead to unwanted consequences.

Some administrator requests might be reasonable for some sorts of users, like employees or especially children, but not be reasonable for other sorts, like friends or intimate partners. In those cases, the user agent can explain what the administrator is going to learn in a way that also says what sort of user is expected to agree. Users in other classes can then react appropriately.

Online harassment is the "pervasive or severe targeting of an individual or group online through harmful behavior" [PEN-Harassment]. Harassment is a prevalent problem on the Web, particularly via social media. While harassment may affect any person using the Web, it may be more severe and its consequences more impactful for LGBTQ people, women, people in racial or ethnic minorities, people with disabilities, vulnerable people and other marginalized groups.

Harassment is both a violation of privacy itself and can be magnified or facilitated by other violations of privacy.

Abusive online behavior may include: sending unwanted information; directing others to contact or bother a person ("dogpiling"); disclosing sensitive information about a person; posting false information about a person; impersonating a person; insults; threats; and hateful or demeaning speech.

Disclosure of identifying or contact information (including "doxxing") can be used, including by additional attackers, to send often persistent unwanted information that amounts to harassment. Disclosure of location information can be used, including by additional attackers, to intrude on a person's physical safety or space.

Mitigations for harassment include but extend beyond mitigations for unwanted information and other privacy principles. Harassment can include harmful activity with a wider distribution than just the target of harassment.

Reporting mechanisms are mitigations, but may not prevent harassment, particularly in cases where hosts or intermediaries are supportive of or complicit in the abuse.

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

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 make 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 another actor 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.

An individual may not realise when they disclose personal data that they are vulnerable or could become vulnerable. Some individuals may be more vulnerable to privacy risks or harm as a result of collection, misuse, loss or theft of personal data because of their attributes, interests, opinions or behaviour. Others may be vulnerable because of the situation or setting (e.g., where there is information asymmetry or other power imbalances), or they lack the capacity to fully assess the risks, or because choices are not presented in an easy-to-understand meaningful way (e.g., deceptive patterns). Yet others may be vulnerable because they have not been consulted about their privacy needs and expectations, or considered in the decisions about the design of the product of service.

Sometimes communities of individuals are classed as “vulnerable”, typically children and the elderly, but anyone could become privacy vulnerable in a given context. Additional privacy protections may be needed for personal data of vulnerable individuals or sensitive information which could cause someone to become vulnerable if their personal data is collected, used or shared.

Even in populations of individuals classed as “vulnerable” (such as children), each individual is unique with their own desires and expectations for privacy. While sometimes others can help vulnerable individuals assess privacy risks and make decisions about privacy (such as parents, guardians and peers), everyone has their own right to privacy.

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.

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.

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.

Whenever people have the ability to cause an actor 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 actor 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.

Actors can invest time and energy into automating ways of gathering data from people and can design their products in ways that make it a lot easier for people to disclose information than not, whereas people typically have to manually wade through options, repeated prompts, and deceptive patterns. In many cases, the absence of data — when a person refuses to provide some information — can also be identifying or revealing. Additionally, APIs can be defined or implemented in rigid ways that can prevent people from accessing useful functionality. For example, I might want to look for restaurants in a city I will be visiting this weekend, but if my geolocation is forcefully set to match my GPS, a restaurant-finding site might only allow searches in my current location. In other cases, sites do not abide by data minimisation principles and request more information than they require. This principle supports people in minimising their own data.

User agents should make it simple for people to present the identity they wish to and to provide information about themselves or their devices in ways that they control. This helps people to live in obscurity ([Lost-In-Crowd], [Obscurity-By-Design]), including by obfuscating information about themselves ([Obfuscation]).

Instead, the API could indicate a person's preference, a person's chosen identity, a person's query or interest, or a person's selected communication style.

Sites should include deception in their threat modeling and not assume that Web platform APIs provide any guarantees of consistency, currency, or correctness about the user. People often have control of the devices and software they use to interact with web sites. In response to site requests, people may arbitrarily modify or select the information they provide for a variety of reasons, including both malice and self-protection.

In any rare instances when an API must be defined as returning true current values, users may still configure their agents to respond with other information, for reasons including testing, auditing or mitigating forms of data collection, including browser fingerprinting.