WICG / first-party-sets

Home Page:https://wicg.github.io/first-party-sets/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Critical feature request: partitioned cookies (CHIPS) and partitioned storage (Storage Partitioning) that can leverage Related Website Sets

kelvingraddick opened this issue · comments

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.

top-level-site-retailexa-b1bf622bc028e

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!

Closing this as a duplicate since this was also posted on issue #94, where this is being discussed.