Embedded Application With Origin Trial 3P Tokens Setup

[jkintscher]

Hi Mike, thanks for setting up this repo as a place for feedback and support about the deprecation trial!

We are currently working on updating an integration of ours that relies on cross-origin storage access for authentication to work with partitioned storage access.

However, due to the way the integration had been implemented, we have so far not found a way to properly leverage the DisableThirdPartyStoragePartitioning origin trial to temporarily restore its functionality as we’re actively looking for a more holistic fix.

Since the integration is used by hundreds of third-party vendors (seemingly requiring hundreds of unique OT tokens) and has millions of daily page views, we’d like to ask for any insight you can give us into how our current setup might work in the interim under the origin trial and to help us avoid breakage once Chrome 115 is released, thus allowing us to properly rebuild the integration.

---

Here’s how the integration is currently set up:

We, a.com, have an integration that we provide to many third-parties, e.g. vendor.com, that allows them to embed our functionality in their websites.

To do so, a script provided by us at a.com/integration.js would be included in the third party’s website ①.

The script renders some UI ② through which, upon user interaction, we fetch the full implementation from our host at a.com/ui and inject it into the page into an iframe ③.

Since the functionality is private and scoped to a specific user, the required credentials are attempted to be read from localStorage ④.

Should no credentials exist or subsequent API requests with them (after ⑤a) fail, the integration opens a new window ⑤b via a sign in button and loads our standalone sign in UI at a.com/sign-in.

Upon successful authentication, that window stores the credentials in Storage ⑥ and then closes itself after notifying the opener to reload, i.e. go back to ④.

With Storage Partitioning for localStorage, this of course no longer works as the credentials in ⑥ get written to a partition keyed as a.com+a.com, while our embedded integration attempts to read them from vendor.com+a.com in ④.

---

Since our vendors embed the initializer script on their website ① voluntarily, we can use that to inject the <meta http-equiv="origin-trial" /> tag with a qualifying OT token before loading the actual integration in ③ (as per the developer-guide), thus unpartitioning the storage access in ④ and successfully reading the tokens written in ⑥.

However, we tried using a 3P token for this but that did not seem to help in our use case: We generated a single, 3P token for origin a.com, embedded it in a.com/ui (as per the developer-guide), but that did not grant the unpartitioned access we needed in ④ in Chrome Version 114.0.5735.198 (Official Build) (arm64) on macOS with Experimental third-party storage partitioning enabled. So, it is our current understanding that this means we would have to generate one OT token for every single vendor that uses our integration, and inject all those tokens into all vendor sites before we load our integration, i.e. in ②.

That leads me to three questions:

1. Are our above assumptions and overall understanding of Chromium’s current approach to Storage Partioning correct?
2. Should a third-party OT token work for our embedded page? Even though we tried it without success, our configuration might have been wrong. Or is this currently just broken due to https://bugs.chromium.org/p/chromium/issues/detail?id=1441411 ?
3. If not, is there any (other) way the embedded script could opt out of Partitioning itself, without us having to inject OT tokens for all vendors known to us into the parent origin, i.e. the vendor’s site, first?

Given our large number of vendors to date—with new ones being able to start using the integration at any time—that process wouldn’t be scalable.

We are, of course, actively working on changing our approach to authentication and the integration in general, but we will not be able to do so before Chromium 115 rolls out to the general public.

Any help is greatly appreciated, especially given the timeline of the roadmap 🙏

[miketaylr]

Hi @jkintscher, sorry for the delay in responding, was on a plane all day yesterday.

that did not grant the unpartitioned access we needed in ④ in Chrome Version 114.0.5735.198

Would you be able to re-test in Chrome 115 beta? Support for 3P tokens was added then:

https://chromiumdash.appspot.com/commit/b6b84b75277c5e0b4dd4a2fcefcf700952aa7473

cc @arichiv

[jkintscher]

Thanks for getting back to us! Using the beta channel indeed got the generated 3rd Party token to work when injected via the integration.js script. Awesome 🙌

However, there is a second way the integration can be used, and that’s via our Chrome extension (using MV3). That can be installed by any user and it then injects the same script as a content script on several matched URLs. In that scenario, I still had to generate non-3P tokens for each origin the extension can inject the script on in order to opt them out of Partitioning.

That may or may not be expected, or due to our more unconventional approach that adds yet another layer to the setup.

In the meantime, we might have found a solution that embraces Storage Partitioning without actually breaking our authentication flow! Since a general fix is of course preferable to relying on the Deprecation Trial, we’re currently focusing our attention on that. Should it not pan out, I’ll be happy to provide some more details on the extension setup in case that’s helpful.

Thanks again for the tip with the beta channel, and your help in general!

[arichiv]

If you're injecting a script with the goal of including a deprecation trial token that un-partitions all third-party contexts then it is expected you would need a first-party deprecation trial token per top-level origin. a third-party token is just good for unpartitioning the storage of a specific third-party origin (and any descendant iframes).

Seems like this is resolved? Let us know if there's anything else.

[jkintscher]

If you're injecting a script with the goal of including a deprecation trial token that un-partitions all third-party contexts then it is expected you would need a first-party deprecation trial token per top-level origin. a third-party token is just good for unpartitioning the storage of a specific third-party origin (and any descendant iframes).

That was super helpful, thank you for the additional context, @arichiv!

Seems like this is resolved? Let us know if there's anything else.

Yes, thanks to both your help and some further experimentation, we found a way to get everything into shape before Chrome 115 stable! In the end, we didn’t need to use any of the OT tokens to opt out of partitioning and instead found a sustainable solution that embraces it properly.

[miketaylr]

Glad to hear it!