Repository navigation
Critical feature request: partitioned cookies (CHIPS) and partitioned storage (Storage Partitioning) that can leverage Related Website Sets #314
Description
Background / Context
I work for LivePerson, a major web chat provider for companies like Microsoft, Verizon, The Home Depot, GoDaddy, and many more.
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, in order to maintain a conversation page-to-page.
However, some of our customers have multiple top-level domains (ex. verizon.com and verizon-sales.com) 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 cookies (or other storage type) 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.
Please let me know if you have any questions, feedback, and/or concerns. Thanks!
Activity
cfredric commentedon Mar 12, 2024
Thanks @kelvingraddick. Your use case looks similar to those in WICG/first-party-sets#94 and #179.
Based on your feature requests (especially "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."), you may also be interested in Shared Storage, particularly in the "known customers" use case: https://developers.google.com/privacy-sandbox/relevance/shared-storage/known-customer
kelvingraddick commentedon Mar 12, 2024
Thanks for responding @cfredric ! That is a very similar issue and seems like it would help our use case too. I don't see in the thread any changes stemming from it yet.
I did see the "known customers" use case, but in our case, we need to be able to share a "LivePerson consumer ID" across related domains to load the user's exact same conversation again, and not generically whether they just have a conversation or not. Is that something that can be done with Shared Storage API?
To me it seems like the current output gates won't allow us to store and retrieve a unique consumer ID (https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API#output_gates), but maybe there is something I am missing.
Do you have any advice on this?
cfredric commentedon Mar 13, 2024
I see, so your real requirement is for a user identifier, not just whether this user has an active conversation. In that case, that is higher-entropy data, and (clearly) provides the ability to track users unless it is partitioned somehow. This is not something Shared Storage can provide, since that API (as well as other Privacy Sandbox APIs) is specifically designed to make cross-site tracking infeasible.
With that in mind, I think your use case is a good example for WICG/first-party-sets#94, since (IIUC) you need a user identifier but you don't want it to be totally unpartitioned; you're ok with the identifier being scoped to within a single RWS, and therefore not usable for tracking outside of that RWS. (And because it doesn't enable pervasive tracking, it'd be ok to provide the identifier to your site without asking for the user's permission first, IMO.) Do I have that right?
If so, then this is definitely something I want to support; this feature request has just been on our backlog for a while, while we work on other problems.
kelvingraddick commentedon Mar 14, 2024
Yes! @cfredric this is exactly our use case, and what we need! 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.
If this is something you are considering – that is great news! My team, company, and our large customers like Verizon who are currently having this issue would GREATLY appreciate this. Like you said, I think it covers a valid use case that doesn't violate the new privacy efforts.
I will share our use case as an example in the other GitHub issue link you provided.
Please let me know if there are other possible next steps, and/or if there something I can do to help with this. Thanks!
kelvingraddick commentedon Mar 26, 2024
Hey @cfredric! Hope all is well. You mentioned "this feature request has just been on our backlog for a while" – I wanted to check if there has been any update on it or any plans for it?
Suchtar commentedon Apr 16, 2024
krgovind commentedon Aug 6, 2024
@kelvingraddick We proposed a potential API for this feature request here. Could you please provide your feedback on that thread?
krgovind commentedon Aug 6, 2024
@kelvingraddick Ah, I see you already did. Closing out this issue, but please continue to use the other thread for discussion.