Merge pull request #4 from arichiv/sw

Drop Shared Workers

README.md

@@ -30,9 +30,9 @@ 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 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
 
@@ -74,3 +74,7 @@ Service workers have [cache-based history sniffing attacks](https://www.ndss-sym
 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.

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 = {}); 
 };