Skip to content

Commit c9a52b4

Browse files
wbambergElchi3chrisdavidmillsestelle
authored
Add privacy primer (#44877)
* Add privacy primer * Updates, add privacy policy * Apply suggestions from code review Co-authored-by: Florian Scholz <fs@florianscholz.com> * Apply suggestions from code review Co-authored-by: Florian Scholz <fs@florianscholz.com> Co-authored-by: Chris Mills <chrisdavidmills@gmail.com> * Update files/en-us/web/privacy/privacy_primer/index.md Co-authored-by: Chris Mills <chrisdavidmills@gmail.com> * Update files/en-us/web/privacy/privacy_primer/index.md Co-authored-by: Florian Scholz <fs@florianscholz.com> * Add more detail on types of personal data * Add an examplpe of de-identification * Mention third-party cookies * Link to Learn Privacy * Clarify guidelines for requesting data * Clarify cross-context * Update files/en-us/web/privacy/privacy_primer/index.md Co-authored-by: Estelle Weyl <estelle@openwebdocs.org> * Update files/en-us/web/privacy/privacy_primer/index.md Co-authored-by: Estelle Weyl <estelle@openwebdocs.org> * Update files/en-us/web/privacy/privacy_primer/index.md Co-authored-by: Estelle Weyl <estelle@openwebdocs.org> * Add a bit about why privacy matters --------- Co-authored-by: Florian Scholz <fs@florianscholz.com> Co-authored-by: Chris Mills <chrisdavidmills@gmail.com> Co-authored-by: Estelle Weyl <estelle@openwebdocs.org>
1 parent 58c8020 commit c9a52b4

1 file changed

Lines changed: 129 additions & 0 deletions

File tree

  • files/en-us/web/privacy/privacy_primer
Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
---
2+
title: Privacy primer
3+
slug: Web/Privacy/Privacy_primer
4+
page-type: guide
5+
sidebar: privacy
6+
---
7+
8+
This guide is an introduction to privacy for web developers. It provides an overview of the principles that a website needs to follow in order to respect the privacy of its users.
9+
10+
It is largely based on the principles listed in the [W3C Privacy Principles](https://www.w3.org/TR/privacy-principles/) statement, but unlike that document, this guide covers only principles that apply to web developers, not those that apply to browser developers or standards designers.
11+
12+
It's split into three main sections:
13+
14+
- [Why privacy matters](#why_privacy_matters)
15+
- [Working with a user's personal data](#working_with_personal_data)
16+
- [User recognition and tracking](#user_recognition_and_tracking)
17+
18+
## Why privacy matters
19+
20+
Respecting the privacy of your users is important in the first place because it is, ethically, the right thing to do.
21+
22+
It also enables you to build trust with your users, who will value your services more. Conversely, the bad publicity arising from privacy violations can be very damaging.
23+
24+
Finally, it's very likely that you will be _required_ to follow many of the principles in this article, due to legislation such as the European Union's [General Data Protection Regulation (GDPR)](https://gdpr.eu/) and the [California Consumer Privacy Act (CCPA)](https://www.oag.ca.gov/privacy/ccpa).
25+
26+
## Working with personal data
27+
28+
Websites often have a legitimate need to collect and process a user's personal data. To be respectful of a user's privacy, a website must align the data they collect and the way they use it with the user's intentions. That is, they should only collect data that the user intends to share, and they should only use it in the way that the user intends for it to be used.
29+
30+
### Personal data
31+
32+
Personal data is defined in the [General Data Protection Regulation (GDPR)](https://gdpr.eu/article-4-definitions/) as:
33+
34+
> any information relating to an identified or identifiable natural person
35+
36+
This includes:
37+
38+
- Data that can be directly used to identify a person, such as a name, social security number, date of birth, or address.
39+
- Physical attributes, such as height, eye color, or ethnicity.
40+
- Societal data such as religion or political affiliation.
41+
- Any other information that is associated with a person, such as medical, financial, or employment information.
42+
43+
### Requesting personal data
44+
45+
Websites should collect only personal data that the user wishes to provide, and collect only the data that they actually need. For example, a shopping site might allow people to make purchases without creating an account: this means the site doesn't collect as much personal data, and also reduces friction for shoppers.
46+
47+
When requesting data, websites should:
48+
49+
- Clearly explain what they are asking for and how it will be used.
50+
- Design user interfaces that honestly attempt to discover the user's true intent. This means that user interfaces should not attempt to manipulate users into sharing more data than they really intend to, for example by making it easier to share data than not to share it, or by asking users to agree to terms that they could not be expected to understand.
51+
52+
### Using personal data
53+
54+
Websites should use personal data only for the purposes they specified when requesting it.
55+
56+
If possible, before sites use personal data, they should process it in such a way that individual users are not identifiable: this process is called _de-identification_. For example, a site could use and share only data aggregated across many individuals, instead of a collection of individual data points.
57+
58+
Websites should protect the personal data that they collect from unauthorized access by third parties. This typically means that stored personal data should be encrypted, and that personal data should only be transmitted using a secure protocol such as TLS. If unauthorized access is detected, the website should notify the user as soon as possible.
59+
60+
Websites should delete personal data once they no longer need it.
61+
62+
### Allowing users to manage their data
63+
64+
Websites should allow users to manage the personal data that they have provided. This includes the ability to:
65+
66+
- Access, correct, export, and delete any stored personal data.
67+
- Withdraw any consent that they have given about how their data should be used.
68+
69+
Websites should make it as easy for users to perform these actions as it is for them to share their data in the first place. That is, websites should not make it easy for users to share data but hard for them to delete it.
70+
71+
Websites should not retaliate against users who exercise these rights. For example, if a user withdraws consent to the use of their data, and the website then denies access to a service that does not depend on that data, this could be considered retaliation.
72+
73+
### Publishing a privacy policy
74+
75+
Websites should publish a privacy policy to help users understand how the site will use their data. The policy should describe:
76+
77+
- What personal data the site collects.
78+
- How the data will be used.
79+
- Steps the site takes to protect data from unauthorized access.
80+
- Any third parties with which the site will share the data, including a declaration that the site will ask for user consent before sharing.
81+
- The duration for which the site will keep the data before it is deleted.
82+
- How the user can view and manage their data.
83+
84+
## User recognition and tracking
85+
86+
**User recognition** is the act of realizing that an identity belongs to the same person as another identity observed previously. Websites often have a legitimate need to recognize users. For example, a library website needs to be able to show the user which books they have checked out, and to do this they need to know that this user is the same user who checked out those books. Websites typically use [cookies](/en-US/docs/Web/HTTP/Guides/Cookies) to implement this.
87+
88+
Recognizing a user is sometimes called _tracking_ a user.
89+
90+
### Tracking techniques
91+
92+
Websites can use various techniques to track users. The W3C document [Unsanctioned Web Tracking](https://www.w3.org/2001/tag/doc/unsanctioned-tracking/) distinguishes two categories of technique:
93+
94+
1. Those that are based on explicit web standards, such as [cookies](/en-US/docs/Web/HTTP/Guides/Cookies) or other [client-side storage APIs](/en-US/docs/Web/API/Web_Storage_API).
95+
2. Those that are not, such as {{glossary("fingerprinting")}}, that typically exploit information leaked by unrelated Web APIs. This second category constitutes _unsanctioned tracking_.
96+
97+
Websites should **only use techniques in the first category** to track users. The reason for this is that techniques in the first category are visible and can be controlled by users, either directly in the browser or through extensions. For example, a user can see which cookies have been set and can clear them, or an extension can automatically block cookies or clear cookies in certain situations.
98+
99+
Even when individual users don't take advantage of these controls, privacy researchers and advocates can identify and highlight tracking which uses these explicit techniques. This helps the development of tools and regulations that can help protect the privacy of all users.
100+
101+
Unsanctioned tracking is also sometimes called _covert tracking_ to emphasize that it is hidden from user visibility and control.
102+
103+
### Cross-context tracking
104+
105+
Recognition may connect observations in the same context or may connect observations in different contexts. A _context_ is defined subjectively as an environment which users consider to be different from other contexts.
106+
107+
Typically, a context maps to a {{glossary("site")}}, so:
108+
109+
- A site understanding that two separate requests to itself are from the same user typically represents same-context recognition.
110+
- A site understanding that a request to itself is from the same user as a request to a different site typically represents cross-context recognition.
111+
112+
However, this isn't necessarily the case, because the definition of a context is subjective: a user might interpret two sites as a single context. For example, a user might think of "interacting with my bank" as a single context, even if it might involve interacting with multiple sites (for example, `my-bank.example.co.uk` and `my-bank.example.com`).
113+
114+
To respect a user's privacy, **sites should avoid cross-context tracking unless the user intends for it to happen and can control whether it does**.
115+
116+
A good example of a situation in which cross-context tracking is legitimate is [federated login](/en-US/docs/Web/Security/Authentication/Federated_identity), in which a third-party {{glossary("identity provider")}} needs to recognise a user who is trying to sign into a different site. In this situation, the user intends for the third party to recognise them.
117+
118+
Websites typically implement cross-context tracking using [third-party cookies](/en-US/docs/Web/Privacy/Guides/Third-party_cookies).
119+
120+
### Tracking prevention in web browsers
121+
122+
Most web browsers implement some form of tracking prevention. Although the details are not always the same, tracking prevention policies broadly follow the principles outlined above. That is, browsers try to prevent unsanctioned tracking as much as possible, and all cross-context tracking, except in specific legitimate cases.
123+
124+
This means that, by following the principles listed above, sites can ensure that they work in as many browsers as possible.
125+
126+
## See also
127+
128+
- [Privacy principles](https://www.w3.org/TR/privacy-principles/#dfn-context) (W3C)
129+
- [Learn Privacy](https://web.dev/learn/privacy) (web.dev)

0 commit comments

Comments
 (0)