-
Notifications
You must be signed in to change notification settings - Fork 2
/
index.html
93 lines (67 loc) · 9.69 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
<!DOCTYPE html>
<meta charset="utf-8">
<title>Third Party Cookies Must Be Removed</title>
<script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c">
</script>
<script class="remove">
var respecConfig = {
specStatus: "draft-finding",
editors: [
{
name: "Amy Guy",
url: "https://rhiaro.co.uk",
company: "Digital Bazaar",
},
{
name: "Daniel Appelquist",
company: "W3C Invited Expert",
},
{
name: "Hadley Beeman",
company: "W3C Invited Expert",
},
],
group: "tag",
wgPublicList: "www-tag",
github: "w3ctag/web-without-3p-cookies",
format: "markdown",
localBiblio: {
"EWP" : {
title: "Ethical Web Principles",
href: "https://www.w3.org/2001/tag/doc/ethical-web-principles/",
publisher: "W3C",
},
},
};
</script>
<body class="informative">
<section id="abstract">
Third-party (<abbr title="also known as">AKA</abbr> cross-site) cookies are harmful to the web, and must be removed from the web platform. This finding explains why they must be removed, and examines the challenges in removing them. We highlight some use cases that depend on third-party cookies and offer some examples of designed-for-purpose technologies that can replace them. Specification authors are expected to ensure they do not undermine the benefits of removing third-party cookies when proposing new web platform technologies.
</section>
<section id="sotd">
This document is an agreed finding and reflects the consensus of the <abbr title="Technical Architecture Group">TAG</abbr>.
</section>
## Introduction
We consider privacy a core design principle and differentiator for the web platform (see: [Ethical Web Principles](https://www.w3.org/TR/ethical-web-principles/#privacy), [Unsanctioned Web Tracking](https://www.w3.org/2001/tag/doc/unsanctioned-tracking/), [Private Browsing Modes](https://www.w3.org/2001/tag/doc/private-browsing-modes/), [Privacy Principles](https://www.w3.org/TR/privacy-principles/), [Security & Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/)).
Many browsers have restricted third-party cookies (see: [Webkit](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/), [Mozilla](https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/)). Unfortunately, [not all browsers have followed suit](https://privacysandbox.com/intl/en_us/news/privacy-sandbox-update/). The TAG calls for all browsers to drop support for third-party cookies, as this provides an opportunity to further improve the privacy preserving features of the web platform.
Removing third-party cookies from the web platform is not without complications. There are use cases for third-party cookies that need to be preserved, and pitfalls we need to be careful to avoid while doing so. This document sets out some aspects that specification editors and implementors should be aware of in order to make sure we ultimately [leave the web better than we found it](https://www.w3.org/TR/design-principles/#leave-the-web-better) after third-party cookies are removed.
## Why remove third party cookies?
Cookies were [originally designed](https://www.rfc-editor.org/rfc/rfc2109.html) for recognizing repeat visitors to a website, but they were soon repurposed for use cases like: login and single sign-on; tracking state (like putting shopping choices into a cart); tracking to better target advertising; detecting fraud; measurement and attribution of ad clicks. Third party cookies (cookies set by someone other than the website being used) have introduced additional vectors for cookies to be used as a data collection mechanism across web sites. This increase in data collection and sharing about people using the web - often in a way that is opaque or incomprehensible to a web user - results in decreased individual and collective privacy.
[Third-party cookies](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-11#name-third-party-cookies) in particular are a key technology supporting tracking networks, which have been [identified as a major threat to privacy](https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-privacy-considerations). These tracking networks entail concentrating data in the hands of - and thus giving greater power to - intermediaries with a presence across many sites, away from the individual sites a person is actually visiting. This centralizing effect has repercussions on innovation and accountability, beyond what is in scope for discussion here.
We maintain that [security and privacy are essential](https://w3ctag.github.io/ethical-web-principles/#privacy) on the web; a reduction in privacy also has implications for [freedom of expression](https://w3ctag.github.io/ethical-web-principles/#expression), [supporting healthy communities](https://w3ctag.github.io/ethical-web-principles/#community) and the [enhancement of individual control and power](https://w3ctag.github.io/ethical-web-principles/#control).
## Use cases previously met by third-party cookies
Some features of the web that people have come to expect, and which greatly improve user experience, currently depend on third-party cookies, and continuing to support these use cases is important. It is better to approach this with replacement technologies that are designed-for-purpose and built to respect user privacy. Any proposal that acts as a general-purpose replacement for third-party cookies would need to be accompanied by evidence that it does not recreate the same issues.
Some recent good examples of the designed-for-purpose approach include:
* [FedCM](https://github.com/w3ctag/design-reviews/issues/718). Third-party cookies have been used to support single sign-on. FedCM is a set of technologies built to support identity federation, without replicating all functionality of third-party cookies.
* [CHIPS](https://github.com/w3ctag/design-reviews/issues/654). The goal of CHIPS is to allow state, without supporting correlation or tracking between web sites which don't know they are collaborating, for example, when embedding third-party services like customer service webchat.
In all cases, it is important to continually review how such proposals might interact with other emerging or proposed APIs. Be aware that a set of new technologies which carry minimal risk individually, could be used in combination for tracking or profiling of web users.
## Leaving the web better than we found it
We support removing third-party cookies from the web platform, and we embrace the opportunity to improve the privacy features of the web. When we review new technologies to replace third-party cookies, we need to ensure that the replacements do not recreate the same pitfalls to privacy.
The TAG considers each new technology proposal *both* individually, *and* as they fit together with the web platform as a whole. The web must be cross-platform, so multi-implementer (multi-browser) support and developer support for privacy-related specifications is essential if they are going to achieve the goal of increasing privacy on the web. When we consider whether something makes the web platform better, we should be explicit about what the baseline for comparison is. Is a proposal better for privacy when compared to usage of third-party cookies? Or when compared with a web free from third-party cookies altogether? What about when some user agents restrict third-party cookies, but others do not?
Many varied proposals are being incubated in W3C Community Groups (e.g., [PATCG](https://patcg.github.io/), [Privacy CG](https://github.com/privacycg/), [WICG](https://wicg.io/)) as well as outside (e.g., [Privacy Sandbox](https://www.privacysandbox.com/)), and in these incubation stages multi-stakeholder support, consensus, and possible timelines for standardization are uncertain, and far from guaranteed.
We want to emphasize that as any replacement proposals progress, implementations should have a strong commitment toward, and reasonable time frame for, removing third-party cookies.
We are also wary of new mechanisms being introduced that could be abused together with cookies, fingerprinting surface or other tools, for greater privacy invasion.
Given this context, we see an urgency to have a strict timeline for the removal of third-party cookies.
All proposers of new web platform technologies are expected to be able to explain and justify the benefits and trade-offs of their proposal. It is particularly important that proposals which aim to fill gaps left by the removal of third-party cookies provide clear and concrete evidence that individual and collective privacy is still preserved; especially proposals which involve profiling, cross-context recognition, or otherwise aggregating or sharing of web user data between parties. We encourage that proposals claiming to improve privacy on the web platform undergo independent review and analysis; the burden of proof is on the proposers, not reviewers, to justify additions and changes to the web platform. The benefits to web platform users of the removal of third-party cookies must not be undermined by user agents or site authors in other ways.
We are strongly in favor of innovations to build sustainable business models on the web platform, but an in-depth discussion of the various possibilities are outside of the scope of this document. From an architectural standpoint, web standards should avoid encoding particular business models that are available to authors, publishers, and web content creators.
In conclusion, when accommodating changes caused by the removal of third-party cookies, we should avoid introducing new technologies that, when deployed either individually or in combination, effectively preserve the status quo of harmful tracking and surveillance on the web.