Use case for Storage Access API providing access to unpartitioned 1st party cookie

[jsnajdr]

In a DM convo about the fact that the Chrome storage partitioning doesn't currently plan to implement the Storage Access API, @wanderview encouraged me to share some use cases where our product (WordPress.com website hosting) is using unpartitioned third party cookies to deliver valuable user experience and features. And where the Storage Access API, as implemented by Safari and Firefox, lets us continue to deliver that experience with just one extra confirmation prompt.

On the wordpress.com domain, there runs a web app that lets the user create and manage one or more websites running WordPress. The actual website runs on a custom domain, e.g., example.com. The user is logged into wordpress.com and has first party session cookies for that domain.

Now, when the user navigates to the example.com site, the site wants to detect that its admin is visiting. And display an "Adminbar" on the top, and an expandable Notifications panel:

This Notifications panel is an iframe loaded from wordpress.com domain, makes Fetch/XHR requests to the wordpress.com domain, and is authenticated with wordpress.com cookies. Which are third-party in this context.

This feature stops working completely when third-party cookies are blocked or partitioned. The iframe embedded in the example.com page doesn't know the user is logged into wordpress.com and has no way of knowing that. And it's the right thing that it doesn't have that knowledge because otherwise wordpress.com would have a tracking capability.

Note that the example.com origin is an untrusted environment. It can run arbitrary third-party code via downloaded plugins. Therefore we must protect the user’s cookie/token and private communications with wordpress.com, which may include actions and notifications from all of their sites, from example.com code running in the browser or the server back-end.

That's why the Notifications panel cannot be implemented as running on the example.com origin and accessing only REST endpoints running on example.com. The cross-origin iframe is providing a "trusted execution environment" inside an untrusted page.

Solving this with Storage Access API
If the Storage Access API is available, we can solve this issue quite easily: after opening the Notifications panel, first show an info box that the feature requires first-party access to wordpress.com cookies. After the user approves the access, we can proceed to load the notifications and show the Notifications UI.

The access we need is read-only: we only ever need to read the first-party unpartitioned cookie. We don't need any write access there. And the cookie doesn't need to be readable by scripts: it can be HttpOnly. But the cookies needs to be SameSite=None -- that's the only requirement where the cookie is not "strict" in any sense.

Another fact worth pointing out is that the user has already visited wordpress.com as a first party, logged in there, and visits the site on a regular basis. The Safari and Firefox implementations use this as a heuristic to decide whether to show the user a prompt on requestStorageAccess at all, or to reject the request right away.

[wanderview]

Thanks! In our DM chat you also mentioned needing access to read 1st party localstorage. Is that still the case, or is reading a cookie adequate for your use case?

[jsnajdr]

That depends on how exactly we would implement authenticating the Fetch/XHR requests. It can be a cookie that the browser attaches automatically, or some OAuth token stored in local storage and attached by JS as Authorization header. We can make both work, but some flexibility would be welcome.

[wanderview]

Just as an update here, we are actively thinking about this use case but don't have anything we can publish publicly yet.

[cfredric]

Time for another yearly update: Chrome has now announced plans to implement the Storage Access API, and I wrote up details of how Chrome's implementation will work here. Please take a look, and let us know if that will address your use case in Chrome. (My understanding from your description is that it will address your need, but just want to double-check.)

[jsnajdr]

Thanks @cfredric for the update 👍 I can confirm that Chrome's planned implementation will work for us. The user, an owner/admin of a WordPress.com-hosted site, will be routinely interacting with wordpress.com as a first party, so when another site will want to embed a widget from wordpress.com, she will be presented with a prompt and can grant access. The permission will likely never time out, because it will be renewed on each new first-party interaction with wordpress.com.

[cfredric]

Hi @jsnajdr - I want to clarify that the user's activity on wordpress.com (directly) will not renew the storage-access permission grant. Only the user's interaction with the Notifications panel itself (when embedded in example.com), or similar wordpress.com content embedded in example.com, will renew the permission grant.

[jsnajdr]

Thanks for the clarification, I misread the document the first time. That behavior is also fine for us, we intend to show embedded UIs to the users and expect them to interact with the UIs. In our view, top-level activity would be a stronger condition for renewal.

[helenyc]

Thanks @jsnajdr - could you please elaborate on why "top-level activity would be a stronger condition for renewal" from your perspective? Chrome is interested in maintaining positive user experiences, so we're interested in hearing other perspectives on different potential signals.

[jsnajdr]

could you please elaborate on why "top-level activity would be a stronger condition for renewal" from your perspective?

By "stronger" I didn't mean "better", but rather "less likely to be satisfied". If the user opens the popup that embeds Notifications UI from wordpress.com, it's almost certain they will interact with it. On the other hand, top-level interaction with wordpress.com in near future is also likely, but the probability is smaller.

[sysrqb]

What is the expected behavior when Partitioned cookies are present in the cookie jar, and Storage Access is granted? The current proposal describes the general behavior as:

Partitioned cookies should be accessible regardless of any choices the user has made via the Storage Access API in the given context.

But it's not obvious that this is what web sites expect, and this raises questions about cookies that conflict. Is the current thinking about this behavior already described somewhere that I missed?

[jsnajdr]

What is the expected behavior when Partitioned cookies are present in the cookie jar, and Storage Access is granted?

Then the document has access to both cookie jars, the partitioned and unpartitioned one. If each jar contains a cookie with the same name, both cookies will be sent with requests, both will be visible in document.cookie etc.

This "conflict" behavior is not new, you can already have cookies with same name but different path or domain. If both paths or domains match the current document's location, both cookies are sent. Partitioned is just a new item in cookie's unique key.

[johannhof]

Yeah this is an established behavior for cookies and mostly shakes out of the way that the Retrieval Algorithm works. That there can be multiple cookies with the same name but otherwise different attributes is more explicitly acknowledged in the Storage Model which is also referenced in the CHIPS spec.