Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop Shared Workers #4

Merged
merged 7 commits into from
Nov 30, 2023
Merged
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ A developer embeds chat.com on two of their sites site-a.com and site-b.com. cha

### [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).
arichiv marked this conversation as resolved.
Show resolved Hide resolved

## Proposed Solution

Expand Down Expand Up @@ -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.
2 changes: 0 additions & 2 deletions idl.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,6 @@ dictionary StorageAccessTypes {
boolean createObjectURL = false;
boolean revokeObjectURL = false;
boolean BroadcastChannel = false;
boolean SharedWorker = false;
arichiv marked this conversation as resolved.
Show resolved Hide resolved
};

interface StorageAccessHandle {
Expand All @@ -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 = {});
};