Cross domain local storage using iframes - "Block third-party cookies"

Question

There are already a few questions related to using the local storage with iframes to be able to share data across different domains. However, none of them addresses the issue when the "Block third-party cookies" is enabled.

Currently, by default now Chrome uses the option "Block third-party cookies in Incognito" which breaks the localStorage use within iframes whenever you use the incognito mode.

Is there any workaround for this problem? We're using post message to send the data for the iframe.

Clausen

What you're proposing sounds like exactly what security settings like that exist for, which is to protect people's privacy from things like poorly implemented iframes gaining access to data the user is unaware of. I don't know the answer for sure, but my guess is that without hacking, there is no work around. – Ardell

Answer 1

I want to add my two cents here because all replies to this question completely miss the point of what's being asked. Take what I have here with a grain of salt, it's based on the most recent versions of Chromium and my personal experience, but maybe it can help someone understand the mess Chromimium has made.

Obscure Chromium Setting

First and foremost the setting within Chromium applications does not explicitly state that local storage or anything regarding "data" will be impacted by "blocking third-party cookies".

Ironically this setting used to actually explain that third-party cookies and data would be blocked, but in recent versions no longer mention data anymore, just cookies.

Is local storage a Cookie?

No. Local storage has nothing to do with cookies, and therefore the option for "blocking third-party cookies" is disingenuous because it lacks describing that local storage will also be blocked.

Local Storage data is stored by the browser for a particular domain. This data is not shared or exposed in any way.

So does local storage have "third-party data"?

No, there is also nothing "third-party" about local storage.

In context of cookies, a "third-party cookie" is a cookie for a domain that was created by a different domain, hence being "third-party". This allows domains to inject data into cookies that get sent to a different domain, which could be useful if you want to let that other domain know something, though this could also become nefarious. This essentially was a way of two domains to have a communication channel based on the user's session, but it becomes a privacy concern because it enables these domains to communicate in context of the user.

What does "third-party" mean for local storage? Nothing. Local storage is bound to the domain that's accessing the storage object - there is no "third-party" mechanism when setting or retrieving data from local storage since it is always in context of the window frame where the code is executing.

This further exasperates the problem: Why does "blocking third-party cookies" prevent local storage which is neither "third-party" nor a "cookie"?

So what does this setting do to local storage?

The "block third-party cookies" setting will block, as the name suggests, third-party cookies, but will also block local storage within an embedded iframe document. The embedded page will not be able to access the local storage property and will throw "Access denied" exceptions when the web page attempts to do so.

Blocking third-party cookies will have no impact to websites since it's used as a mechanism to share information with no returned output and no dependency of success. If your app uses local storage, it will likely break without it.

What's the security concern?

Doesn't that make sense that an embedded page can't access the local storage?

As other comments have incorrectly stated is that accessing the local storage within an embedded iframe would essentially enable cross-domain data access.

This is incorrect. The localStorage property is unique to the window variable of the frame, it is not unique to the parent domain. In other words, if you have an embedded iframe it will have a separate local storage than the parent window. This is because local storage is unique to the domain for which the code is executing in, and therefore there is no "cross-domain" access happening as part of it.

There must be other ways this is a security concern

As other comments have mentioned, the ultimate concern is leaking data across domains. So how can this happen?

It is technically possible to access the local storage property bi-laterally - child iframes can access their parent's window property and vice-versa, parent frames can access embedded iframe window objects, however Chromium blocks this by default. I tried turning off all security settings within Chromium and could not directly access the localStorage property in a parent/child or child/parent direction.

In the context of Chromium I have no reason to believe that local storage can be accessed across domains in any way unless it's explicitly instructed by the frame source page using a special header.

So why does Chromium block local storage in iframes?

Perhaps it made sense at a time before local storage became what it is today, or before accessing iframe window properties from relative frames was prevented.

Ultimately if Chromium implements local storage properly, there should be no possibility of cross-domain access without the hosting website being explicitly configured to allow such behavior. See FireFox for an example of this done properly.

What should Chromium do?

Separate out blocking local storage into it's own setting, and it should be disabled by default because there is very little reason to outright disable the entire feature that breaks a website.

Asaph

This issue is driving me nuts. I agree with every point you made... localStorage should not be blocked under 3rd party cookies setting. Apps that have been written to use localStorage (like the one I have to fix) but are allowed to be embedded in other sites are going to have to find a new way to handle this situation and there is no good alternative. Everything I find points to using window.postMessage() but I'm not trying to talk between frames. I want to store a user's preferences between sessions. The data is used ONLY by the app, not by an ancestor. Total nightmare. – Bloomy

Dumb question: is there any change the server could make to solve this? e.g., would a certain CORS response allow local storage to work correctly? – Corder

One thing that could be done is to build a storage on runtime, which behaves exactly like localStorage, but it'll miss the point as it'll not have any persistence. But I agree ideally the Chromium team should make separation of concerns and just block the damn cookies 🍪 – Cherida

The same way a cookie can be abused to track a user across domains, local-storage can. Not to mention the risk of leaking IP if one always uses a VPN to access website X but when they visit website Y with an iFrame of website X w/o a VPN, they've leaked their true IP to X given their past cookie/local-storage. – Unopened

Answer 2

The behavior you are describing sounds exactly like the pattern of behavior the Third-Party Cookie Block is intended to prevent.

There have been numerous changes in Chrome (and other browsers) regarding cookies and iframe.

The basics of what is changing is there is now a 'SameSite' cookie policy, where Only cookies set as SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections.

Also in safari, the third-party frame will have to request access to the storage API before the cookie will be accessible.

Firefox is using a partitioned approach to the storage, and so the frame will behave as normal unless you then open your application as a new window then the cookie store may or may not follow depending on how the new window was created.

Cookie Status is an excellent resource to track how third party cookies work in the different browsers and what you should change to make it work.

Godolphin

Answer 3

This is a little confusing because while LocalStorage is NOT a Cookie, as you can see from the links below LocalStorage access and cookie access is lumped into 'storage access' by the browser developers. So they are not the same, but they are both types of storage and impacted by new third party storage requirements.

Is there Third Party Local Storage?

Yes, in the following scenario this is considered 'third party':

• Web Page on Domain A loads an iframe from DomainB
• DomainB iFrame writes to LocalStorage for Domain B.

Open a new browser tab and navigate to Domain B. You will note the value you wrote there is absent. If you open up Storage Inspector in Chrome, it will say "third-party" due to origin: Domain A. If you attempt this sort of thing in Firefox, it will say state partition is being utilized in the console.

Here is the documentation from Mozilla

Here is the Chrome Documentation

Note you CANNOT share local storage between DomainA and DomainB directly, you would have to use JavaScript and postMessage and specifically disable browser protections.

You can see it in action at this site.

Can I turn it off?

In order to have this work you need to alter chrome://flags/#third-party-storage-partitioning in Chrome and network.cookie.cookieBehavior in FireFox (note the documentation specifically calls out LocalStorage, it's not just cookies)

Personally, I wouldn't recommend it.

Arsenide