Closed Bug 1884191 Opened 4 months ago Closed 3 months ago

Use browser history rather than session history to guide the behavior of requestStorageAccess

Categories

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

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
Firefox 123
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: enrique, Unassigned)

Details

(Keywords: priv-triaged)

Steps to reproduce:

In the context of a federated identities discovery service - SeamlessAccess (SA). 2 origins involved: SA, and a Service Provider (SP) that embeds a link to SeamlessAccess in an iframe. When visited at the top level, SA sets a cookie that is meant to be read by SA when embedded in the SP. For this, SA calls requestStorageAccess when the user clicks on the embedded link. But requestStorageAccess only prompts the user for permission if the user has previously visited SA at the top level. FF requires this visit to have happened in the current session history; in any session in which SA has been seen in an iframe before being seen at the top level, calls to requestStorageAccess are denied. Chrome doesn't seem to care for sessions in this regard, and as soon as the user has visited SA at the top level, in the next visit to the SP, requestStorageAccess will do its thing.

  • User visits SP, clicks on the SA button, is sent to SA at top level, SA sets a cookie.
  • User goes back to the same or to another SP with the SA button, and clicks on it; no permission is asked or granted.
  • User restarts the browser session, and visits SP. Same thing.

Actual results:

SA in the iframe will not get storage access permission until there is a session in which SA is visited at the top level before being visited in an iframe.

Expected results:

SA in the iframe will get storage access permission (mediated by prompting the user) if the user has ever visited SA at the top level (this is chrome's behavior).

The Bugbug bot thinks this bug should belong to the 'Firefox::Session Restore' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Session Restore

Hello! I have tried to reproduce the issue with firefox 125.0a1(2024-03-15) on Ubuntu 22.04, unfortunately I wasn't able to reproduce the issue on my end.
Could you please answer the following questions in order to further investigate this issue:

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
  3. Do you have any addons installed? If yes could you please list them?
  4. On what OS did you encounter the issue?
Flags: needinfo?(enrique)

This happens with a new profile without any addons. I am seeing this in linux (archlinux).

The code I used for the tests can be found here:

https://github.com/enriquepablo/storage-access-demo

I demoed this to Benjamin VanderSloot from Mozilla at a FedCM meeting last 5th of March, and he asked me to open an issue.

I have not tried with the latest nightly.

Flags: needinfo?(enrique)

I'm not sure which is the right component here. Moving to the localStore & session storage component - can you move it if necessary?

Component: Session Restore → Storage: localStorage & sessionStorage
Product: Firefox → Core

This probably belongs with us!

Component: Storage: localStorage & sessionStorage → Privacy: Anti-Tracking

Ben, would you be able to set the priority and severity for this bug?

Flags: needinfo?(bvandersloot)
Severity: -- → S3
Flags: needinfo?(bvandersloot)
Priority: -- → P3
Keywords: priv-triaged

This is no longer the case with firefox 124

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.