Consider exposing environment id to script

[inexorabletash]

Noted in w3c/ServiceWorker#1263 (comment)

There are potential use cases for exposing the environment's id to script e.g. as self.clientId. Per @wanderview "Probably discussed in the odd comment or two in various SW issues"

Since that would likely end up in HTML, filing the issue here for tracking purposes.

[spanicker]

We have a need for clientId as well as lastClientId.
For the Lifecycle usecase, see: WICG/page-lifecycle#4

Could this issue be used to track both or should I file separate issue?

[domenic]

This seems like a reasonable place to track both, although if e.g. it becomes clear there's consensus on clientId while lastClientId ends up being controversial, then we can split it.

[spanicker]

Sounds good.
To clarify "lastClientId" should only be exposed when the tab was previously discarded.
(there may be privacy, security implications to always exposing it)
Should it be called "discardedClientId" perhaps?

[inexorabletash]

Bikeshedding: @matto mentioned offline that we may not want to call this "clientId" outside of SWs since these thingies aren't "clients" except in a SW context. self.environmentId maybe?

[wanderview]

Well, I think there is some desire to expose the Clients API to window and worker contexts in addition to service workers. See w3c/ServiceWorker#955.

(Also, I think that was the wrong @mattto.)

[ralphch0]

As an additional data point, for our product having a unique identifier for pages that is easily accessible without jumping through hoops would be great.

We report latency/logging info from the service worker as well as the page. We log the client id in each, in order to link the data together either locally (by sending a message from the page to the SW), or on the server (by merging the two logs).

We're also experimenting with the WebLocksAPI OriginTrial (https://github.com/inexorabletash/web-locks), and it exposes a client id to identify the lock holder. We'd really like to be able to have a consistent identifier across these APIs, and it would be quite helpful if the ClientsAPI is also exposed from all contexts.

In some earlier, more hand written iteration of our locking system (before WebLocks), we had to use the SW Clients API to verify if the lock holder tab was still open. Pages needed to always talk to the SW to figure out their own id, and to find out whether another tab (by client id) was still open. Bringing all of this to the context of the page, would avoid adding extra complexity for cross-tab features.

[jakearchibald]

I think we should expose (something like) the clients API to all contexts, but rereading the threads again, I'm not sure it's what you want.

If I'm reading correctly, the uses cases all want to identify which 'session' a window client is part of.

We already kinda have the concept of a session for session storage. It currently uses the "top level browsing context", but since it's supposed to survive discards and crashes, the top level browsing context isn't the right thing (WICG/page-lifecycle#26).

Would something like this work?

Create the concept of a "browsing session". This would effectively represent a tab, including crashed and discarded tabs. The "browsing session" of an iframe would be the top level tab. Maybe dedicated workers could have a browsing session, but shared & service workers would not.

Update session storage to use the new "browsing session". Session storage would be keyed by origin in the browsing session. This means session storage should survive discards and crashes.

Each "browsing session" has "parent browsing session". If a link is opened in a new tab, the new tab's "parent browsing session" will be the "browsing session" of the opener, or null if the tab wasn't opened from another tab. This relationship explains where session storage copies its data from.

Then we should expose this to JavaScript. Something like:

• session.id - An id for this client's "browsing session".
• session.parentId - An id for this client's "parent browsing session".

IDs would probably need to be unique for origin + "browsing session", but I'm not 100% sure.

We could also add sessionId and parentSessionId to the clients API, along with ways to match clients by these IDs.

WDYT? I think this would give you what you're looking for, and also fix WICG/page-lifecycle#26.

[ralphch0]

In our case, we actually want to identify that page load (i.e. matching what the service worker sees as a new navigation), and not necessarily the top level context. For example, we want to join diagnostic data logged to server from the service worker, with logging done from the page (including iframed pages).

[jakearchibald]

@ralphch0 yeah, a page's client ID should be exposed somehow.

This issue should really be two issues I think.

[annevk]

Is this affected by Cross-Origin-Opener-Policy? Or would that solely depend on whether that affects sessionStorage? Does requestStorageAccess() change the ID?

(It would also be good to have some documented rationale as to why these identifiers are not problematic from a privacy or security standpoint.)

[jakearchibald]

Or would that solely depend on whether that affects sessionStorage? Does requestStorageAccess() change the ID?

Assuming that session storage is already doing the right thing privacy-wise, it seems like a good thing to copy. I haven't thought about it enough, but given that you can put an ID in session storage, it shouldn't be introducing anything new.