Ability to get localStorage value from third party iframe always blocked?

[csnate]

Ability to get localStorage value from third party iframe always blocked?

[annevk]

We cannot exclude localhost from these rules. It's used for non-developing purposes as well.

[annevk]

I was just being precise that reading nor writing is blocked. You are simply seeing different storage as a result of partitioning. If you were to get an exception then you would be blocked (and perhaps have a tracking domain).

[csnate]

Cool, never hurts to ask ;)

What about the rest of the question? Is that the intention to block localStorage read access from an iframe on a third party domain when it was set by the third party domain previously?

[annevk]

Access ought to be partitioned, as per the README. If it's actually blocked (i.e., writing fails) that might be because your domain is classified as some kind of tracking domain in certain user agents.

[csnate]

Writing to localStorage isn't blocked - I can see that the token is written to localStorage on auth.example.com if I go to any page there. It's reading localStorage from auth.example.com when it's in an iframe on app.example.com. I believe this is the specific scenario outlined in point 1 of the readme here, namely "Beyond visiting, it can also allow A to infer specific state from B that depends on the user". In this case, I need A to read from B specific state about the user, namely that they have an authentication token. If that is the intention here, then I'll need to implement a different solution to get the user's token and store it on app.example.com as well.

Where can I check to see if my actual domain is listed as a tracking domain?

[johannhof]

Are you saying that localStorage isn't accessible between top-level auth.example.com and auth.example.com embedded on app.example.com? That behavior (origin- vs. site-scoped storage) is specific to Safari right now, see https://bugs.webkit.org/show_bug.cgi?id=247565

[csnate]

@johannhof - that is what is happening and it's happening on Chrome 115. We only stared seeing it recently and randomly as only a subset of users are being opted-in to chrome://flags/#third-party-storage-partitioning = enabled, and developers started reporting that they weren't able to login/authenticate anymore when developing locally.

@annevk - I'm not seeing any exceptions, only undefined for the value from localStorage.getItem('token')

Oddly enough, we have one other application that is on a different domain (app2.example.com) that also authenticates against auth.example.com and we saw this behavior with Safari last year, so I already have a solution in place that should work for this specific scenario as well.

Also of note, our existing solution does not work if third party cookies are disabled.

[johannhof]

@csnate to be clear, are auth.example.com and app.example.com actually cross-site in reality (i.e. different domains, like auth.com and app.com)? Then yes that's the intended effect of Storage Partitioning. Can you apply the solution you used for your other domain here as well?

[csnate]

In our specific scenario, yes - they are app.example.com and localhost. In the other scenario, they are different sub domains - app.example.com and foo.example.com.

And thanks for the confirmation/information. I thought this was working as intended, but wanted to make sure before I went ahead with a little more complicated solution.