search

WICG / shared-storage

Explainer for proposed web platform Shared Storage API
Other
89 stars 23 forks source link

iFrame using own local storage #80

Closed GiackV closed 1 year ago

GiackV commented 1 year ago

An iFrame that uses its own localstorage, with a source that is different from the domain of the website it is contained, will be blocked by the 2024 third party cookies proposal by chrome, even if the iFrame do not read or use any content of the parent's storage.

My question is, will sharedstorage solve the problem and how? From what i've understood, the shared storage API (together with fenced frames) allows this particular behaviour between sites and content frames that only requires a private storage for storing data.

menonasha commented 1 year ago

Post 3cpd, local storage in iFrames will be partitioned by top level site but the iFrames themselves won't be blocked. The data in an iFrame's local storage can't be replicated across multiple top level sites but the local storage can still be used within the iFrame. Could you clarify what you mean by the iFrames being blocked and is there a specific use case you are referring to?

richard-obrien commented 1 year ago

Hi @menonasha,

I'm not the OP here but we also have this issue at BugHerd and would love some clarity.

BugHerd is a tool that allows web developers (e.g. agencies, consultants, or in-house teams) to gather feedback from their clients & stakeholders using our embedded widget (the BugHerd Sidebar). When embedded on the customer's website, the BugHerd Sidebar will only display to users who have been invited to give feedback on the project (e.g. have a Bugherd login).

Currently, we store a user's BugHerd Login session id in a cookie which we simply use to determine on page load whether the BugHerd Sidebar should appear or not for the current website visitor.

We have adapted our application significantly to support Firefox, Safari, and up until v113, Edge's implementation of the StorageAccessAPI, however the recent change to limit access to "first party sets" is very concerning.

We notice on the Mozilla documentation there is mention that the first party sets restriction "...is intended to be relaxed as the implementation is developed further". Is there anywhere we can get more clarity on what is meant by this? Also we'd really love to know if there is someone we can talk to further about this use case as the "first party sets" direction for the storage access api can severely impact our ability to deliver our product's core functionality to customers.

Cheers, Richard Head of Product @ BugHerd.

helenyc commented 1 year ago

Hi @richard-obrien - thanks for reaching out!

Chrome is supporting the Storage Access API (SAA) for First-Party Sets use cases, and also for extended use cases. You can read more about these extended use cases and Chrome's planned implementation here. Please feel free to leave questions and feedback in that repo.

Thank you!

pythagoraskitty commented 1 year ago

Closing this issue for now. If you need further clarification about Shared Storage, please either re-open it or open a new issue.