-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CHIPS integration with First-Party Sets #94
Comments
cc @DCtheTall |
Hi, This is Harsh from VWO and we provide A/B testing solutions to our customers. 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. Tested implementation - A.com and B.com are in a FPS. we created a third-party (visualwebsiteoptimizer.com) cookie on A.com with:- 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,
According to this article |
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
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
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
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 caseHello – 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:
I think our situation below covers a valid, unhandled use case, that doesn't violate the any new privacy efforts. Background / ContextOur 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.
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 RequestWhat 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.
Please let me know if you have any questions, feedback, and/or concerns. Thanks! |
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?
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).
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:
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!
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. 👍🏾
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.
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:
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? |
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.
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 Maybe, we might have to require sites wanting to use this API be listed on some new property on the RWS (e.g.,
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!
|
|
[Note: This issue captures an open question related to the changes proposed in PR #91 and summarized on issue #92]
With the changes to First-Party Sets (FPS) proposed in #92, the previously defined integration of CHIPS with FPS needs to be re-examined. As per the previous proposal:
When a cross-site embed sets a cookie with the Partitioned attribute, the partition key was computed based on whether the top-level document’s “site” (top_level_site) was in an FPS or not.
The new proposal instead requires sites to invoke Storage Access API to explicitly request mediation by the browser to grant cookie access for domains within a set. This allows browsers to apply different policies/handling for each request. Sharing a CHIPS partition across multiple domains will need to move to a similar model of an explicit API invocation that is mediated by the browser, instead of happening by default.
To help inform how we think about a new integration for FPS and CHIPS, could developers, testers, or stakeholders provide examples of their use cases that rely on an integration of CHIPS and FPS?
The text was updated successfully, but these errors were encountered: