Proposal: Support a shared state for tab groups

[dpenning]

Proposal: Add tabGroups.tabGroup.shared

Summary
Chromium is adding the concept of a shared group. Shared groups allow users of the browser to share a collection of tabs in their tabstrip with other users.
On Chrome this feature will update tabs in realtime across multiple logged in users and across all clients for these users.
In its current state we only plan for extensions to access information about whether the group is shared or not.
Document Metadata
Author: [email protected]
Sponsoring Browser: Chrome
Contributors: [email protected]
Created: 2025-01-15
Related Issues:

Motivation

Objective

Some browsers may want to restrict access to certain parts of the api as a result of the tabs affiliation with a shared group. Without the extensions knowledge of this shared state, the extension developer will not have an understanding of why querys or commands failed.

Use Cases

Extensions that provide heavy interaction/mutation on tab groups may want to exclude access to shared groups through their extensions.

Specification

Schema

chrome.tabGroups.tabGroup.shared
a boolean field which will denote whether the group is in a shared state or not.
chrome.tabGroups.query
the queryInfo parameter will accept a new fieldshared bool optional
When provided the tab groups query will filter based on the shared states of the group.
chrome.tabGroups.onUpdated
a method that is currently fired when a group is udated, will also fire when the group's shared state changes.

Behavior

New restrictions may be placed on shared groups for security and privacy purposes. This is not limited to the tabGroups API and could extend to chrome.tabs and other related API surfaces. The restriction would result in an error that "the action can not be performed due to the object being in a shared state." or a similar error message.

New Permissions

no new permissions

Manifest File Changes

no new manifest fields

Security and Privacy

Exposed Sensitive Data, Abuse Mitigations, and Additional Security Considerations

This proposal only exposes existing state for a given group. All exposing of sensitive data, abuse mitigations and additional security considerations should be applied to the "shared" feature itself, and this is something likely to be different per browser vendor.

Alternatives

Existing Workarounds

Extensions developers currently need to rely on error handling in order to handle issues that arise from restrictions on "saved and synced" groups. These will also apply, and more restrictions may be put in place for "shared" groups

Open Web API

the tabGroups functionality is purely a browser feature, which is why we only expose this information through the extensions API

Implementation Notes

Other browser vendors have similar implementations of groups, however im not currently aware of any implementation of this shared state exposure for extensions.

[Rob--W]

This looks like a filled-in proposal template (https://github.com/w3c/webextensions/blob/main/proposals/proposal_template.md). Such proposals are usually added to the proposals/ directory via pull request. Did you mean to open a pull request with the content? The process is documented at https://github.com/w3c/webextensions/blob/main/proposals/proposal_process.md

I note that neither Firefox nor Safari have an implementation of the tabsGroups extension API at the moment, so perhaps a lighter version (having a proposal of a small change) here would be good enough.

[dpenning]

ill go ahead and post a PR for this, we just wanted to make sure it was referencable in your meeting on thursday which is why I added it through issues.