1825238 - document.hasStorageAccess() returns true but no storage access

Status: RESOLVED INVALID

(Core :: Privacy: Anti-Tracking, defect)

Description

[Akash]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

As part of the federated SSO process, I am using the Storage Access API to get access to unpartitioned storage+cookies from 3rd party site.
I have followed the instructions of below 2 documentations to implement my feature,
https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API
https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using

As per instruction, I am

• invoking document.hasStorageAccess() to check the storage access status
  • if it returns 'true', I am continuing with the next step of our process using unpartitioned storage+cookie data.
  • otherwise requesting access via document.requestStorageAccess() along with user click event and continuing with next step based on its resolution.

Actual results:

The mentioned logic have been working fine so far (up to Firefox version 108) until Firefox version 109 was released in last January.
Now, with later version (109 onwards), the code cannot access to any unpartitioned storage/cookies data anymore even if the document.hasStorageAccess() returns 'true' with no errors.

Expected results:

I am expecting to have access to unpartitioned storage/cookies once the document.hasStorageAccess() returns 'true'.

Comment 1

[Emma Zühlcke [:emz]]

Since Firefox 109 (Bug 1800960) the Storage Access API in Firefox only grants first party storage access to cookies. Any other storages, such as sessionStorage, localStorage, indexedDB etc. remain permanently partitioned.

Does your code rely on unpartitioned access to storages? Unpartitioned cookie access after the storage access grant should continue to work as expected.

Comment 2

[Emma Zühlcke [:emz]]

While the MDN page has not been fully updated to reflect the changes yet (sorry! We have an open pull request for that) the spec mentions that the API only impacts cookies: https://privacycg.github.io/storage-access/#storage

Comment 3

[Akash]

Hi Paul,
Thanks for reverting promptly!
Yes, our code relies on the access to unpartitioned localStorage (along with cookie) too so that we can retrieve the storage+cookie data, which we have saved before as first party, from an iframe embedded inside a 3rd-party.

Just to make it clearer, I should share the whole picture of the flow of execution,

• First, we save localStorage 'X' and cookie 'Y' from first party site say, 'www.first-party.com'
• Then, we have a 'www.third-party.com' that embeds the iframe to connect to 'www.first-party.com' and retrieve the above data using Storage Access API.
• At the time of loading of the iframe, we call document.hasStorageAccess() which initially returns 'false', so we call document.requestStorageAccess() along with a prompt to user for allowing access.
• Based on the access given, we reach out to 'www.first-party.com' server and process the cookie 'Y'.
• Then, we reload the iframe which calls document.hasStorageAccess() again and this time we expect it to return 'true' (It is still doing that in Firefox 109)
• Finally, base on that returned value 'true', we retrieve storage data 'X' (which was working till version 108, and now in version 109, there is no access to it)

Hope I could paint the picture clearer.
Would you please suggest how we can get around the issue in new versions of Firefox?

Comment 4

[Akash]

(In reply to Paul Zühlcke [:pbz] from comment #1)

Since Firefox 109 (Bug 1800960) the Storage Access API in Firefox only grants first party storage access to cookies. Any other storages, such as sessionStorage, localStorage, indexedDB etc. remain permanently partitioned.

Does your code rely on unpartitioned access to storages? Unpartitioned cookie access after the storage access grant should continue to work as expected.

Hi Paul,
Sorry, I should have replied to your thread rather than adding separate comment below.
Please go through the details of the execution flow in my new comment.
And, as you confirmed, after requesting for unpartitioned data access via API, we are able to see the unpartitioned cookies but not the localStorage data.

Please suggest if there is any work around to resolve it.

Comment 5

[Akash]

Hi,
Is the there any update or suggest on the solution (based on above comment) please ?

Regards,
Akash Mandal

Comment 6

[Emma Zühlcke [:emz]]

Sorry for the late response, I missed your reply. You can use the "Request information from" feature at the bottom of a bug to make sure things don't get lost.

Thanks for providing a more detailed example!
Unfortunately there is not workaround for storages (including localStorage) specifically. They will always remain partitioned in third-party contexts to prevent tracking. If you want to transmit data in the way you described you need to rely on cookies (+ Storage Access API) or store your state server side. Depending on your use case you may be able the exchange data with the iframe via window.postMessage.

I'll mark this bug as INVALID since the API is working as intended. This however doesn't mean that your use case isn't valid. If you have an interesting use case beyond what's already captured here I'm sure PrivacyCG would like to hear about it.