From a22e9259c1167f1b0894617f251410110032282a Mon Sep 17 00:00:00 2001 From: Shuran Huang <89418275+shuranhuang@users.noreply.github.com> Date: Wed, 12 Jan 2022 14:53:54 -0500 Subject: [PATCH 1/2] Update explanation of Clear Site Data in README.md Update the text of how clearing site data on FPS membership change will be different from a site sending Clear-Site-Data header. --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 3ff2dc6..9fb0db8 100644 --- a/README.md +++ b/README.md @@ -230,11 +230,13 @@ User agents need not perform this normalization on the domains in their static l # Clearing Site Data on Set Transitions Sites can change which First-Party Set they are a member of. We need to pay attention to these transitions so that they don’t link user identities across all the FPSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one First-Party Set to another when it changes its set membership. -In order to achieve this, site data needs to be cleared on certain transitions. The clearing should behave like [`Clear-Site-Data: "*"`](https://www.w3.org/TR/clear-site-data/#grammardef-), which includes cookies, storage, cache, as well as execution contexts (documents, workers, etc.). We don’t differentiate between different types of site data because: +In order to achieve this, all site data needs to be cleared on certain transitions, including cookies, storage, cache, as well as execution contexts (documents, workers, etc.). We don’t differentiate between different types of site data because: * A user identifier could be stored in any of these storage types. * Clearing just a few of the types would break sites that expect different types of data to be consistent with each other. +The [`Clear-Site-Data: "*"`](https://www.w3.org/TR/clear-site-data/#grammardef-) specification has useful algorithms for this, but we believe it's important and safe to clear across partitions when FPS membership changes, [unlike when a site sends Clear-Site-Data](https://github.com/w3c/webappsec-clear-site-data/issues/66).  + Since member sites can only add/remove themselves to/from FPSs with the consent from the owner, we look at first-party set changes as a site changing its FPS owner. If a site’s owner changed: From 3af38a08236abfdf6191bcb9fa1ac20d44379925 Mon Sep 17 00:00:00 2001 From: Shuran Huang <89418275+shuranhuang@users.noreply.github.com> Date: Tue, 19 Apr 2022 16:40:25 -0400 Subject: [PATCH 2/2] Update the content based on the comments. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 9fb0db8..dab3f1a 100644 --- a/README.md +++ b/README.md @@ -230,12 +230,12 @@ User agents need not perform this normalization on the domains in their static l # Clearing Site Data on Set Transitions Sites can change which First-Party Set they are a member of. We need to pay attention to these transitions so that they don’t link user identities across all the FPSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one First-Party Set to another when it changes its set membership. -In order to achieve this, all site data needs to be cleared on certain transitions, including cookies, storage, cache, as well as execution contexts (documents, workers, etc.). We don’t differentiate between different types of site data because: +In order to achieve this, the browser would need to clear site data of all domains that had certain set transitions, including data that is partitioned. The data type includes cookies, storage, cache, as well as execution contexts (documents, workers, etc.). We don’t differentiate between different types of site data because: * A user identifier could be stored in any of these storage types. * Clearing just a few of the types would break sites that expect different types of data to be consistent with each other. -The [`Clear-Site-Data: "*"`](https://www.w3.org/TR/clear-site-data/#grammardef-) specification has useful algorithms for this, but we believe it's important and safe to clear across partitions when FPS membership changes, [unlike when a site sends Clear-Site-Data](https://github.com/w3c/webappsec-clear-site-data/issues/66).  +When FPS membership changes for a certain site, we believe it’s important and safe to clear its unpartitioned data and all third-party resources partitioned with this site being the top-level. Otherwise this site could store its data in a partition of another site that is not part of the FPS and reclaim it after clearing. We are still discussing whether to clear all this site’s data partitioned by other top-levels [#87](https://github.com/privacycg/first-party-sets/issues/87). Since member sites can only add/remove themselves to/from FPSs with the consent from the owner, we look at first-party set changes as a site changing its FPS owner.