cc @DCtheTall

Hi, This is Harsh from VWO and we provide A/B testing solutions to our customers.
FPS is something that can be really helpful for us. Hence, I wanted to share our use case here.
A lot of times we come across clients that have multiple domains and want to run an A/B test across multiple domains. Now the tricky situation here is that we need to maintain the same user experience across all of the domains.
For ex - If a user views a red banner on A.com then he should also see that same red banner on B.com
Here A.com and B.com are owned by the same entity.
To do this we need to drop a third-party cookie.
But as we know, going forward we won't be able to access third-party cookies on B.com that were created on A.com

Additionally, Being an A/B testing company we are categorized as SAAS. Thus, we can't be added to the FPS of other companies.

Now, here comes the FPS + CHIPS integration into the picture.
As far as we can understand, In CHIPS the sites present in the FPS set will match with the partition key and thus, will be considered indistinguishable. Consequently, members will share all third-party cookies. This will allow us to access the necessary cookie.
But unfortunately, we are not able to get both of them working together even after using requestStorageAccessFor
As a side note - I would also like to mention that A/B testing is very time sensitive and covert i.e. the user should not get to know that they are a part of an A/B test. Thus, a rapid permission grant would be necessary while any prompting mechanisms will be unfeasible for us.

Tested implementation - A.com and B.com are in a FPS. we created a third-party (visualwebsiteoptimizer.com) cookie on A.com with:-
Path=/; Secure; SameSite=None; Partitioned
Now on B.com we called rSAF to get permission. We were able to create a network request for A.com and first-party cookies of A.com were getting attached to the network request but third-party cookies of A were not directly accessible on B.com

Flags for - Storage Access API, Enable First-Party Sets, and Paritioned Cookies were also enabled.

Hi Harsh, thank you for the feedback and use case! Currently CHIPS partitioned cookies are not joined through the usage of either FPS or the Storage Access API, though given feedback like yours we think that this might be a capacity that would be helpful to the Web Platform (this is what this issue is tracking).

A solution that I think would currently work for your use case is to CNAME your endpoint to a "service" domain for both A.com and B.com, e.g. testing.B.com (or an entirely new domain that is under ownership of your customer). Those domains could live in a common FPS and testing.B.com could have access to 3PC via rSAFor.

I recognize that this is not the optimal path as you might want to continue using the visualwebsiteoptimizer.com domain and setting up a CNAME for customers might not be a great experience. So, I think it's good to have developer reports like this to inform potential improvements to the APIs going forward. More broadly (and slightly off-topic), for A/B testing, have you evaluated the Shared Storage API, which has documentation specifically for that use case?

Hi Johann,
Thank you for the suggestion, I have looked into them -

1. CNAME
   Yes, you are right this might not be a great experience for customers as most of our user base consists of people who are not very tech-savvy. Hence, they might be unable to get this configured easily.

2. Shared Storage
   It looks like this API leans more towards A/B testing of embedded content which is very different from our use case. In our product, we do direct DOM manipulations based on the variation the end-user became part of. Thus, this might also be unfeasible.

According to this article
https://developer.chrome.com/en/docs/privacy-sandbox/chips/#first-party-sets-and-cookie-partitioning
It looked like FPS+CHIPS might be a feasible solution for us. So, do let us know if there's any update on this integration or if there are other proposals.

Looks like one my previous issue thread is more suited for this topic so copy pasting the same here.

It seems like there is a missing co-ordination between how FPS + Chips + Storage partition are working currently.

To add in more details: here is the current production use case for my customer

• site11.com, site22.com are the enterprise customer domains
• connect11.com is a SaaS app which gets embedded on customer domains and it makes use of login cookies and also hosts a shared worker which basically acts a gatekeeper for managing audio, notification if there are multiple instances of this app open(meaning only one browser tab could be the owner for playing audio and the states are managed within shared worker) along with multiplexing backend requests and broadcasting the response on all the open tabs. Shared worker is mainly used to support seamless multi-tab use case.

The way it's working today is - customer opens site11.com which loads the embedded connect11.com. and connect11.com opens up a login popup and spins up a shared worker and all works happily. customer could either navigate to site22.com or open multiple site11.com all works.

with Privacy sandbox proposals , here is how i'm thinking about the new flow

Chips

would now add partition into the login cookie, most likely to adopt to CHIPs - connect11.com now needs to do the login process in an hidden iframe so that the cookies are set against the site11.com and the embedded connect11.com would continue to have access to cookie and works

Storage partition

• Strangely shared worker doesn't get access to cookies anymore as chips restricted cookies within a partition. It seems like shared worker is still looking into cookies set under connect11.com without a partition which would be null in my case. My expectation here was storage partition should also follow the same CHIPS model while retrieving the cookie for the embedded context which is to look up cookie based on the partition (site11.com, connect11.com) key instead of just (connect11.com)
• and if customer loads site22.com , now there are 2 shared worker spun up with the same name which is strange too because the whole point of shared worker is to avoid this - my expectation was to have the same logic in place as CHIPS while creating a new storage partition, in this case as site22.com is recognized as the FPS site , we should have connected to the same existing shared worker instead.

FPS

• i have declared the top level sites in a FPS list to support multi top site use cases (site11.com, site22.com) and used requestStorageAccess() methods to see if i can get hold of cookies on site22.com, unfortunately that didn't work as i presume it's due to CHIPS. even in here i anticipated FPS to work along side with CHIPS. meaning if there are FPS definitions found then on site22.com , look at cookies from primary domains (site11.com + connect11.com) and make it available for site22.com as well.

As you can see above FPS + CHIPS + storage partition are not working together and making it difficult to support our customer use cases.

Is there known issue chrome is tracking on this and how is chrome thinking about addressing these differences?

Wanted to give a heads up that the Storage Access API extension OT is adding Shared Worker support in M123: https://developers.google.com/privacy-sandbox/blog/saa-non-cookie-storage

LivePerson web chat use case

Hello – I work for LivePerson, a major web chat provider for companies like Microsoft, Verizon, The Home Depot, GoDaddy, and many more.

My team, company, and our large customers like Verizon (who are currently having one of their valid use cases blocked) would GREATLY appreciate feature/effort, which I understand to be:

Unpartitioned storage scoped within an RWS. Or for the partitioned storage to be available/keyed by the whole RWS, instead of just being keyed to each domain separately in the RWS like it is now.

I think our situation below covers a valid, unhandled use case, that doesn't violate the any new privacy efforts.

Background / Context

Our web chat product is "embedded" – running as an application directly on the webpages of our customers listed above (not in an iframe), where typically we can use first party cookies / storage to store things like a user's chat identity (consumer ID), in order to maintain a conversation page-to-page, between their related website domains.

Like briefly mentioned above, some of our customers have multiple, related top-level domains (Think verizon.com and verizon-sales.com for example) where they still need a consumer's chat identity / conversation maintained across.

• Currently, our solution for that is based on using an iframe to set 3rd party storage (IndexedDB, cookie, other storage type based on best available) against our own LivePerson domain, that can then be accessed across any of the brands different domains to maintain a user's identity/conversation – it worked for a long time..
• ..but of course now with the 3rd-party cookie deprecation, and Storage Partitioning, this will not work anymore.

To be clear this is NOT an advertising tracking scenario, but simply a 3rd-party chat application scenario, that major brands are currently using.

Feature Request

What we propose is that partitioned cookies (CHIPS) and/or partitioned storage (Storage Partitioning) are automatically allowed to be accessed across the Related Website Set, without the need for the Storage Access API, nor user interaction.

In other words, the cookies or storage is able to be partitioned/accessed per Related Website Set (if one is defined), and NOT just per single domain. For our scenario, this will allow a brand to define their related website set, and us to be able to still access partitioned cookies/storage across them, in order to maintain a user's chat identity and conversation across the related website set.

"Why can't we just use the Storage Access API with Related Website Sets?"

• Because Storage Access API requires user interaction with our iframe, and our application runs passively as code on our customers website.
• The iframe is only for 3rd-party storage and is hidden.
• We need to know if this user has a current conversation to know whether to show the conversation or an invitation, without the user clicking.
• When a user is chatting and switches to another website page, they do not expect to have to click something for the same chat to resume.
• It was stated that this scenario is not one Storage Access API was made for in the documentation here.

If you're currently using the same domain for the chat iframe on every customer, RWS won't work as you couldn't make a set with every single customer and your own domain in it (any given domain can only appear once in the RWS list so this would prevent any customer from using it, also I don't believe this is a supported case https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#set-formation-requirements). If your customer was hosting their own origin for the chat bot (chat.verizon.com) that could be in a RWS with their other domains I believe. Before we delve deeper, would something like that be possible?

@arichiv Thanks so much for the response! That makes sense. We do actually have the concept of "vanity domains" we use with some of our customers; very similar to what you said.

So I think if we could have either partitioned cookies and/or partitioned storage automatically allowed to be accessed across the Related Website Set, without the need for the Storage Access API (without user interaction), to maintian the expected user experience for their chat customers, then it would be enough to push our customers to set up vanity domains for chat.

That would be great if we could dive deeper on this – this would be a critical use case to uncover for some of our largest brands like Verizon and United Healthcare, where we simply want the chat application to persist the user's id/conversation (not marketing tracking).

Is this something that can be pursued on your side?

We are gathering feedback on this sort of use case but don't have any announcements as of yet on mitigations.

I talked to @cfredric from GoogleChrome/related-website-sets#314 and we had one potential recommendation with many caveats.

If we take the example of Customer 1 on https://example.retail/ who has two other sites they host for related services (https://myexample.retail/ and https://yourexample.retail/) and all of them want to embed a support chat provided on https://example.support/ then the current 3PCD/SP changes would diminish their ability to share data just via data in the browser.

It isn't possible to add every single customer who wants to embed https://example.support/ to a single RWS as this isn't within the supported use cases. It would allow data to be shared across all customers and not just within a customer.

It would be possible for Customer 1 to register https://chat.supportexample.retail/ and make it a CNAME of https://example.support/. It would then be possible for Customer 1 to make an RWS entry with https://example.retail/, https://myexample.retail/, https://yourexample.retail/, and https://supportexample.retail/. This would allow embeds of https://chat.supportexample.retail/ on one of the other sites to call rSA without requiring a user gesture.

A different Customer 2 could do something similar, and make an RWS entry with their origins (https://example.pub/, https://examples.pub/, and https://otherexample.pub/), the final of which would have a CNAME subdomain of https://example.support/ for their support chat embed.

NOTE: The Customer 1 and Customer 2 support embeds would not share any data between them as they are on different origins. This is better for security but break existing assumptions.

NOTE: If Customer 1 CNAME'd https://chat.example.retail/ to https://example.support/ and added it to the RWS instead, this would work the same way but can leak cookies from https://example.retail/ to https://example.support/, which likely isn't desirable. For security it's better if the new CNAME subdomain is on a new origin with no other cookie usage.

NOTE: The RWS limit is 5 associated sites https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior (I don't believe service sites apply to this use case as rSA is not auto-granted). This may not be enough for your existing customers even before they consider adding a new domain that CNAMEs to the support chat, and this will not scale if other services need a similar solution to yours.

Given the amount of drawbacks in this possible solution we are still examining other options.

@cfredric thanks! Understood

Yeah, we hope to have a solution where our customers can each define their RWS including the domains they need data shared across, AND including a sort of "vanity" domain (ex. chat.xxxx.xxxx) that we can use with them, like you mentioned.

Like you mentioned, we DON'T need our Customer 1 and Customer 2 to share data, we just need Customer 1 to be able to share data within their own RWS without user prompt and without user interaction/gesture. If the user needs to click on something when they cross to another site in the RWS, then it will break the expected continuity (we need to be able to ID this user to the show the same conversation again automatically).

Are you saying the below option exists right now already for under 5 associated sites in an RWS?

It would be possible for Customer 1 to register https://chat.supportexample.retail/ and make it a CNAME of https://example.support/. It would then be possible for Customer 1 to make an RWS entry with https://example.retail/, https://myexample.retail/, https://yourexample.retail/, and https://supportexample.retail/. This would allow embeds of https://chat.supportexample.retail/ on one of the other sites to call rSA without requiring a user gesture.

Because here it seems to say a user gesture is always required for Storage Access API, with or without RWS: https://developers.google.com/privacy-sandbox/3pcd/storage-access-api#how_is_the_storage_access_api_different_when_used_with_rws

Ah, I think you're right I should have said it bypassed just the prompt.

Hey @arichiv and @cfredric! - just checking in to see if there has been any progress or update in the plan for supporting our use case?

We have been gathering feedback from some of our larger customers. Some are willing to invest in setting up a RWS, and host an iframe (and we use rSA), but the R.O.I for them is questionable, as it's still requiring a user gesture, which greatly regresses the user experience. They (and their users) expect their conversation to continue on a different RWS domain automatically. (1) So it would be great if at least the user gesture requirement could be relaxed in an RWS.

One other solution I'd like to suggest, (2) would be to have all cookie/storage partitioning based on the whole RWS website list, and not just the individual domain. Would be great if this worked for partitioned cookies and/or other partitioned storage (both would be great).

• That way SAA/rSA can remain the way it is for other use cases it more aligns to (we wouldn't need it in that case), and our use case could be covered safer without causing privacy/tracking issues. Our customers could set up their RWS, and when cookies/storage is set, it is partitioned across the RWS for us to access/persist the chat experience only within the RWS.

Please let me know your thoughts on the 2 proposals above, and/or any other ideas/updates! The pressure to solve this for our consumers is mounting, so we appreciate any form of support, and the support so far!

@DCtheTall and I are discussing it and hope to have a proposal of some kind in the first half of this year.

We likely won't be able to pursue option (2) as it would cause too many partitioning inconsistencies between browsers (as only Chrome supports RWS at the moment) and requires some sort of data loss when sites enter or exit the RWS.

Thank you everyone who contributed feedback to the discussion. We are taking this use case seriously and are working on a potential solution that meets Privacy Sandbox’s standards for both privacy and usability.

In order to do so, we are hoping you all could chime in on two design questions we have regarding your use cases:

1. Would only being able to use non-HTTP storage (e.g., IndexedDB or Local Storage; but not cookies) meet your use cases?
2. Assuming a cross-site iframe in an RWS had access to RWS-specific storage (in addition to its default storage), would it meet your use case if the RWS-specific storage were transient to a given browsing session (data would need to be copied to the default storage to be persisted across browser restart)?
   Would a graceful degradation on browsers not supporting RWS be acceptable; or is interoperability a key consideration?

For technical reasons, it would allow us to ship this API more quickly if RWS storage only includes a select subset of JavaScript storage APIs and is transient. Below we have a toy example of how this may look:

// This storage `handle` provides access to a transient partition that is shared
// across a Related Website Set.
let handle = await requestStoragePartitionSharedAcrossRelatedSites(
    {localStorage: true});

Getting feedback from the community on this will help guide the direction of the design for our solution to this particular use case.

@DCtheTall Thanks so much for sharing this potential solution!

Would only being able to use non-HTTP storage (e.g., IndexedDB or Local Storage; but not cookies) meet your use cases?

That would meet our use case described earlier (for LivePerson web messaging/chat)! We have a 'cascading' storage type selection mechanism that prioritizes IndexedDB, so in 99% of cases we weren't using cookies to persist data cross-domain before anyway. 👍🏾

Assuming a cross-site iframe in an RWS had access to RWS-specific storage (in addition to its default storage), would it meet your use case if the RWS-specific storage were transient to a given browsing session (data would need to be copied to the default storage to be persisted across browser restart)?

LivePerson's messaging conversations between consumers and brands are "async", meaning they can persist indefinitely without closing them (similar to a Facebook Messenger conversation). It would be better if the RWS-specific storage could persist across browsing sessions, so that no matter which RWS site the consumer comes back to for the brand in a new session, they will be able to get their same conversation back.

However, it would still be very beneficial to our use case even if the storage was transient only to a given browsing session, especially if it can be delivered more quickly that way. Persisting across browser sessions would be nice to have, but not critical enough if it stops or slows down this effort.

Would a graceful degradation on browsers not supporting RWS be acceptable; or is interoperability a key consideration?

Chrome is most of the consumer-base for us, so we are prepared to have graceful fallbacks in place for other browsers. 👍🏾

Regarding the JavaScript example you gave, that looks great!!

TL;DR; from LivePerson web messaging perspective, this proposal would greatly help our product and our customers, who are currently have pressure to solve this. We appreciate the support so far!

Questions:

1. Would the proposed solution not require user interaction and user prompt?
2. Would the proposed solution still require a vanity domain for our chat customers to go into the RWS, since our LivePerson domains can't be in RWS more than once? ex. chat.customer-domain.com
3. How quickly could you do/trial something like this if it's non-cookie and transient to browser session like you mentioned?

Thanks so much!

@arichiv @DCtheTall @cfredric Hello! Just checking in to see if there has been any progress or update in the plan for supporting the proposed solution? Also, any feedback on my last questions?

1. Would the proposed solution not require user interaction and user prompt?

We are hoping that a prompt would not be required as the data is transient and scoped by the RWS of the top-level-origin, but before proposing this change formally and receiving feedback no specifics can be promised.

2. Would the proposed solution still require a vanity domain for our chat customers to go into the RWS, since our LivePerson domains can't be in RWS more than once? ex. chat.customer-domain.com

No and maybe.

No, we don't want to require a vanity domain be created to allow ListPerson to be added to the associatedSites RWS property. If we had that requirement there would be little reason to build the API as the cross-site iframe in the RWS could just call requestStorageAccess.

Maybe, we might have to require sites wanting to use this API be listed on some new property on the RWS (e.g., originsAllowedToCallRequestStoragePartitionSharedAcrossRelatedSites) to ensure the consent of the RWS itself, but whether that would be required (or if duplicate origins could or could not be added cross-RWS) is unclear.

3. How quickly could you do/trial something like this if it's non-cookie and transient to browser session like you mentioned?

I can't promise anything, especially since our timelines changed recently, but H1 2025 is probably in the ballpark.

@arichiv makes sense / thanks for the response!

I can't promise anything, especially since our timelines changed recently, but H1 2025 is probably in the ballpark.

1. Are you saying initiatives like this one are being slowed/delayed due to the announcement not to deprecate 3rd-party cookies?

2. In light of the announcement not to deprecate 3rd-party cookies, do you think it is a valid solution now for our web chat use case to instead leverage 3rd-party cookies to persist our users identity/conversation across domains? (..as opposed to using non-cookie storage that is currently being domain-isolated by Storage Partitioning). And/or maybe at least an alternative until we have the solution proposed here(?).

1. We expect to share further updates and details in the near future.

2. While we can't predict what exact user preferences will be, it’s important for businesses and developers to prepare for a likely increase in Chrome browsers without support for third-party cookies, and continue to invest in privacy-enhancing technologies.

@arichiv hey Ari, hope all is well. Just checking back again to see if there has been any progress on the proposed solution in this thread? I see above it might have been discussed at W3C TPAC.

It was discussed, I think @DCtheTall can follow up when there is more to share