From a7b0521f8082fe5995c120d955e7290ab726f355 Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Tue, 28 Nov 2023 13:31:50 -0500 Subject: [PATCH 1/7] Drop Shared Workers This API allows a third-party to break out of storage partitioning, but not the concept of party itself. First-party SharedWorkers have access to SameSite=Strict cookies, so we cannot allow access. There is discussion about allowing access to requestStorageAccess inside SharedWorkers instead: https://github.com/privacycg/storage-access/issues/157 --- idl.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/idl.md b/idl.md index ff86a0c..e9cd9cf 100644 --- a/idl.md +++ b/idl.md @@ -15,7 +15,6 @@ dictionary StorageAccessTypes { boolean createObjectURL = false; boolean revokeObjectURL = false; boolean BroadcastChannel = false; - boolean SharedWorker = false; }; interface StorageAccessHandle { @@ -29,5 +28,4 @@ interface StorageAccessHandle { DOMString createObjectURL((Blob or MediaSource) obj); undefined revokeObjectURL(DOMString url); BroadcastChannel BroadcastChannel(DOMString name); - SharedWorker SharedWorker(ScriptURLString scriptURL, optional (DOMString or WorkerOptions) options = {}); }; From 59af7fd267cdf668d1ddff24387c986003a27353 Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Tue, 28 Nov 2023 13:34:57 -0500 Subject: [PATCH 2/7] Update README.md --- README.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index c050ee9..26274ab 100644 --- a/README.md +++ b/README.md @@ -28,11 +28,11 @@ There has been increasing [developer](https://github.com/GoogleChromeLabs/privac ### [Example 1](https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124) -A developer embeds chat.com on two of their sites site-a.com and site-b.com. chat.com uses Shared Workers to maintain a user session. +A developer embeds chat.com on two of their sites site-a.com and site-b.com. chat.com uses IndexedDB to maintain a user session. ### [Example 2](https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/fybXzBdwCAAJ) -This SaaS product has a heavy reliance on shared workers and this would break customer use cases. Shared workers are used to coordinate Web RTC signaling and websocket management which is critical for the app. For example, the shared worker is used to support seamless multi-tab use cases and acts as a gatekeeper for managing audio and notifications if there are multiple instances of this app open (i.e., only a single tab can host an audio). +This SaaS product has a heavy reliance on Broadcast Channel and this would break customer use cases. Broadcast Channel is used to coordinate Web RTC signaling and websocket management which is critical for the app. For example, the channel is used to support seamless multi-tab use cases and acts as a gatekeeper for managing audio and notifications if there are multiple instances of this app open (i.e., only a single tab can host an audio). ## Proposed Solution @@ -69,6 +69,10 @@ We could change third-party context’s StorageKey to be the first-party one so Service workers have [cache-based history sniffing attacks](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1C-2_23104_paper.pdf). Extending cross-site unpartitioned storage access to service workers would open up increased vulnerabilities and be somewhat confusing due to the way FetchEvent and other background events are not tied to an endpoint, thus first-party Service Workers will not be exposed in third-party contexts after an rSA call. +### Shared/Dedicated Workers + +Shared and Dedicated Workers have access to SameSite=Strict cookies. This API does not otherwise grant access to those cookies in a third-party context, so it should not allow access to first-party worker pools. + ## Privacy & Security Considerations In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Service Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. From a722f4da1f3977118a7f1c5f73ec2eb1d830e920 Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Tue, 28 Nov 2023 13:35:28 -0500 Subject: [PATCH 3/7] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 26274ab..263c89d 100644 --- a/README.md +++ b/README.md @@ -75,6 +75,6 @@ Shared and Dedicated Workers have access to SameSite=Strict cookies. This API do ## Privacy & Security Considerations -In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Service Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. +In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. Without this extension, we would in effect be pushing developers to migrate storage to cookies. This would have negative security implications as they are exposed in HTTP Requests and partitioned per-site instead of per-origin. Although the storage capacity is greater via non-cookie storage, not much information would need to be passed to simply achieve linking a first and third-party context. From 9198fca4508f7a86e10232881a3651c4de77f39f Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Thu, 30 Nov 2023 09:08:21 -0500 Subject: [PATCH 4/7] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 263c89d..cbb9875 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ There has been increasing [developer](https://github.com/GoogleChromeLabs/privac ### [Example 1](https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124) -A developer embeds chat.com on two of their sites site-a.com and site-b.com. chat.com uses IndexedDB to maintain a user session. +A developer embeds chat.com on two of their sites site-a.com and site-b.com. chat.com uses Shared Workers to maintain a user session. ### [Example 2](https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/fybXzBdwCAAJ) From 4b81ad80045d7c00b9669ef185442a0cafd79f7a Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Thu, 30 Nov 2023 09:08:44 -0500 Subject: [PATCH 5/7] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cbb9875..33e7cec 100644 --- a/README.md +++ b/README.md @@ -75,6 +75,6 @@ Shared and Dedicated Workers have access to SameSite=Strict cookies. This API do ## Privacy & Security Considerations -In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. +In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Service Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. Without this extension, we would in effect be pushing developers to migrate storage to cookies. This would have negative security implications as they are exposed in HTTP Requests and partitioned per-site instead of per-origin. Although the storage capacity is greater via non-cookie storage, not much information would need to be passed to simply achieve linking a first and third-party context. From 9382c3bc3bf351a50d9f838c167015810eff2590 Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Thu, 30 Nov 2023 09:10:58 -0500 Subject: [PATCH 6/7] Update README.md --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 33e7cec..281e20a 100644 --- a/README.md +++ b/README.md @@ -69,12 +69,12 @@ We could change third-party context’s StorageKey to be the first-party one so Service workers have [cache-based history sniffing attacks](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1C-2_23104_paper.pdf). Extending cross-site unpartitioned storage access to service workers would open up increased vulnerabilities and be somewhat confusing due to the way FetchEvent and other background events are not tied to an endpoint, thus first-party Service Workers will not be exposed in third-party contexts after an rSA call. -### Shared/Dedicated Workers - -Shared and Dedicated Workers have access to SameSite=Strict cookies. This API does not otherwise grant access to those cookies in a third-party context, so it should not allow access to first-party worker pools. - ## Privacy & Security Considerations In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Service Workers (which will not be supported in this extension) we believe non-cookie storage and communication APIs don't enable any capability that could not be built with cookie access. Without this extension, we would in effect be pushing developers to migrate storage to cookies. This would have negative security implications as they are exposed in HTTP Requests and partitioned per-site instead of per-origin. Although the storage capacity is greater via non-cookie storage, not much information would need to be passed to simply achieve linking a first and third-party context. + +### Shared/Dedicated Workers + +Shared and Dedicated Workers have access to SameSite=Strict cookies. This API does not otherwise grant access to those cookies in a third-party context, so it should not allow access to first-party worker pools. An extension to support Shared and Dedicated Workers without SameSite=Strict cookies should be considered for future inclusion. From 9707fd30d2f8cdd37c0d84d503120785b33cc059 Mon Sep 17 00:00:00 2001 From: Ari Chivukula Date: Thu, 30 Nov 2023 09:27:05 -0500 Subject: [PATCH 7/7] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 281e20a..b07a4a0 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ There has been increasing [developer](https://github.com/GoogleChromeLabs/privac A developer embeds chat.com on two of their sites site-a.com and site-b.com. chat.com uses Shared Workers to maintain a user session. -### [Example 2](https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/fybXzBdwCAAJ) +### [Example 2](https://github.com/wanderview/quota-storage-partitioning/issues/9) This SaaS product has a heavy reliance on Broadcast Channel and this would break customer use cases. Broadcast Channel is used to coordinate Web RTC signaling and websocket management which is critical for the app. For example, the channel is used to support seamless multi-tab use cases and acts as a gatekeeper for managing audio and notifications if there are multiple instances of this app open (i.e., only a single tab can host an audio).