Seen when testing the new storage_access prompt in Fenix.

Like for other permissions Fenix / Focus have their own permissions manager which allows users changing over time whether a content permission is allowed or blocked.

Saw that:

• once the permission is granted GV would not call again onContentPermissionRequest and so if the user changes their mind they will not be able to block the request
• if the permission is blocked then GV would call onContentPermissionRequest for every new request allowing users to potentially change their mind.

Saw that if I remove all site permissions which also clears the data stored in gecko then a previously allowed storage_access permission is asked again so maybe we could workaround this but it seems like there is another permission manager layer in GV/Gecko that is not needed and a better fix would be to have GV fire the onContentPermissionRequest everytime and let the client respond with the up-to-date permission status.

Desktop also has this two stage permission management when it comes to site permissions (i.e. permissions shown to the user). It behaves similar to your description. The main permissions backend is nsIPermissionManager, but site permissions have a wrapper SitePermissions.jsm with some added functionality.
I'm not familiar with how exactly permisssions are integrated in GeckoView, but it may look similar.
SitePermissions can access permissions from nsIPermissionManager and can show UI for it. However, if a permission is already set, we will not receive a callback on a storage access request, because we don't have to show a prompt.

Hi Arturo,

This looks like an issue about GV handling storage access permission. Would you be able to take a look? Thanks.

(In reply to Tim Huang[:timhuang] from comment #2)

Hi Arturo,

This looks like an issue about GV handling storage access permission. Would you be able to take a look? Thanks.

Tagging some members of the GV team :)

Adding this back to GV triage.

Arturo, do you have a priority for this issue?

I think P3 is good priority, it is something that will be good to address but not something that at the moment is urgent.

As we are moving forward to enable TCP in Fenix, I think we should increase the priority the bug.

IIUC, I see the same behavior in Firefox desktop, so this behavior is either by design or this bug also affects desktop.

On Steven Englehardt's Storage Access test page (https://senglehardt.com/test/dfpi/storage_access_api.html), I allowed requestStorageAccess in column 3 (different site, cross-origin iframe). I see the "Allowed Temporarily" permission in the door hanger for the site after I allowed requestStorageAccess, but even if I remove the permission in the door hanger and restart Firefox, requestStorageAccess will succeed without showing a prompt.

I'm asking the Anti-tracking team if this is the expected behavior.

Petru, were you testing Fenix/Focus with dom.storage_access.auto_grants = false and dom.storage_access.max_concurrent_auto_grants = 0?

I forgot to disable auto_grants when testing on desktop, so even after I removed the site's cross-site storage permission, Firefox was still auto-granting permission. After I disabled auto_grants and remote the permission, Firefox desktop prompts me for storage access, as expected.

So is this GV bug that we're auto-granting permission even after the user has removed the permission in Fenix?

Paul Zühlcke says the cross-site storage permission should expire have 30 days. The user should get a prompt after that.

Petru, were you testing Fenix/Focus with dom.storage_access.auto_grants = false and dom.storage_access.max_concurrent_auto_grants = 0?

Yes, I think I set dom.storage_access.auto_grants = false to make sure I'll get the prompt for allowing cross-site cookies.
But I tested now on desktop and the bug is reproduceable even without this step.
The bug being that once I allow cross-site cookies and then select the option to "Clear cookies and site data" (and even after refreshing/accessing senglehardt.com/.. in another tab) when checking whether cross-site cookies are allowed I see that they are.
"Clear cookies and site data" clears all other permissions so I as a user would expect the cross-site cookies permission to be cleared also.

(In reply to Petru-Mugurel Lingurar [:petru] from comment #11)

Yes, I think I set dom.storage_access.auto_grants = false to make sure I'll get the prompt for allowing cross-site cookies.
But I tested now on desktop and the bug is reproduceable even without this step.

Reproducible on desktop with dom.storage_access.auto_grants = true?

The bug being that once I allow cross-site cookies and then select the option to "Clear cookies and site data" (and even after refreshing/accessing senglehardt.com/.. in another tab) when checking whether cross-site cookies are allowed I see that they are.
"Clear cookies and site data" clears all other permissions so I as a user would expect the cross-site cookies permission to be cleared also.

IIUC, that is the expected behavior with dom.storage_access.auto_grants = true (the default value). auto_grants is supposed to bypass the cross-site permission door hanger. You need to set dom.storage_access.auto_grants = false to ever see the door hanger.

Tested now https://senglehardt.com/test/dfpi/storage_access_api.html on Firefox desktop - 103.0b5:

• 4th column - known-tracker.englehardt-tracker.com and dom.storage_access.auto_grants = true (default)

  • tapping hasStorageAccess() I get false

  • tapping requestStorageAccess() doesn't show the prompt and immediately grants access

  • tapping hasStorageAccess() I get true

  • click the lock in the toolbar -> Clear cookies and site data, refresh the webpage:

    • tapping hasStorageAccess() I get true
      This doesn't seem expected. When first visiting this webpage without previously tapping requestStorageAccess() I would get false.
      As a user I expect Clear cookies and site data to also remove the data about cross site cookies.

• 3rd column - englehardt-tracker.com and dom.storage_access.auto_grants = false

  • tapping hasStorageAccess() I get false

  • tapping requestStorageAccess() shows the prompt and I tap Allow to grants access

  • tapping hasStorageAccess() I get true

  • click the lock in the toolbar -> Clear cookies and site data, refresh the webpage:

    • tapping hasStorageAccess() I get true
      This doesn't seem expected. When first visiting this webpage without previously tapping requestStorageAccess() I would get false.
      As a user I expect Clear cookies and site data to also remove the data about cross site cookies.

The storage access state is stored as a permission and "Clear cookies and site data" does not clear permissions. I think this is expected, we also don't clear other permissions, such as geolocation, notification etc. when clearing site data.

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

The storage access state is stored as a permission and "Clear cookies and site data" does not clear permissions. I think this is expected, we also don't clear other permissions, such as geolocation, notification etc. when clearing site data.

Firefox desktop's address bar has a site permissions button that can clear cross-site cookie permissions (see the attached screenshot), but Firefox Android's address bar only has the "Clear cookies and site data" button, which does not clear site permissions. Android users need to go to Firefox's Settings menu > Site permissions > Exceptions to clear the cross-site cookie permissions for the englehardt-tracker.com test site. Then clicking the "requestStorageAccess" button on the senglehardt.com test page will prompt the user again.

@ Petru: I think we can close this bug as invalid (working as designed). Do you agree? Or am I missing a step in this bug?

Sorry, should have sticked to testing on Fenix and should have added more details when first filing this.
This issue is about the users being able to easily change the cross-site cookies permission after it has been set as they can easily do with any other.
For example the camera permission can be retracted by going to Settings -> Site permissions -> Exceptions (from the default "Ask to allow") -> tap on the wanted address -> change or clear permisson. Video - https://drive.google.com/file/d/1_MASPP_zknT_d0coYFOpEpnmiHcaErKO/view?usp=sharing

For easily testing the same steps for cross-site cookies I set in about config:

• dom.storage_access.auto_grants: false - not necessarily needed but allows to always get the prompt for storage access requests.
• network.cookie.cookieBehavior: 5 - to enable TCP in normal browsing

After first granting storage access for in the 3rd and 4th column from senglehardt.com/test/dfpi/storage_access_api.html by using the same steps from above for retracting the camera permission even if I set the cross-site cookies permission to be "Blocked" or if I clear the permission when checking again in the website I see storage access is still allowed. Video - https://drive.google.com/file/d/1LHqu5k5F1tvtbNPJHYDuc2n4U0RxlEo3/view?usp=sharing

Clearing the status for the cross-site cookies permissions is though possible if clearing all permissions. Video - https://drive.google.com/file/d/1cBkMYpqc741fLtNrEDqs-sCBtp2vzB_x/view?usp=sharing

So the cross-site cookies permission has a different behavior than the others and not being able to easily block a once granted permission feels like even a security risk for me.

Thanks for the videos. I can reproduce the bug you describe. After allowing requestStorageAccess on senglehardt.com:

• If I Clear permissions on all sites in Settings > Site permissions > Exceptions, then requestStorageAccess on senglehardt.com will prompt again. This is the expected behavior and the same as desktop. This is behavior you captured in your third video.
• But if I select senglehardt.com in Settings > Site permissions > Exceptions and then clear permissions only for that site, then hasStorageAccess is still auto-granted on senglehardt.com. This is not expected behavior and is not the same as desktop. I'm now stuck: senglehardt.com has cross-site cookie permissions but I have no way to clear the permission because senglehardt.com is no longer listed in Settings > Site permissions > Exceptions! This is the behavior you captured in your second video.

Do you think this is a bug in Fenix's permissions manager? Or in Gecko's or GeckoView's handling of cross-site cookie permissions on Android? Should we move this bug to the Fenix issue tracker?

As always, I am testing with prefs dom.storage_access.auto_grants = false and network.cookie.cookieBehavior = 5.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1746031#c1 the issue lies in how this particular permission - the storage access one is handled in GeckoView / Gecko.
There seem to be another layer of permission management for this particular permission and so even if the client (Fenix) makes the request to change a permission, the call which would work for all others does not work for the storage access permission.
It seems like this should be handled upstream of Fenix which makes the right calls (the same as for any other permissions) but they don't produce the same result in GeckoView/Gecko.

(In reply to Petru-Mugurel Lingurar [:petru] from comment #18)

It seems like this should be handled upstream of Fenix which makes the right calls (the same as for any other permissions) but they don't produce the same result in GeckoView/Gecko.

In that case, I'll ask a GeckoView engineer to debug in our next sprint. I don't think this is a blocker for our TCP experiment in v103, but we should try to fix it before v106.

105

So, to summarize:

STR:
1. Set dom.storage_access.auto_grants to false
2. Set dom.storage_access.max_concurrent_auto_grants set to 1
3. Open https://senglehardt.com/test/dfpi/storage_access_api.html
4. Grant permission in columns 3 and 4
5. Revoke the permissions [for websites individually] *
6. Reload https://senglehardt.com/test/dfpi/storage_access_api.html
7. Check permissions.
8. Expected: prompt asking for the permission

• Unlike on desktop, Fenix has 2 ways of revoking permissions, revoke for all the exceptions which works as expected, and revoke for each exception individually which has the bug (on step 8 instead of prompting, silently grants the permsission)

Petru, is that correct? (Just to make sure)

Yes. That is correct for Fenix.
Seems like the site permission we have in Fenix only applies to "if the storage access prompt should be shown"
While Gecko handles "if storage access should be allowed".
So when in Fenix we revoke the permission for the prompt to be shown it will have no effect for the storage access permission.

Since we plan to ship TCP in 106, we should try land this fix in Nightly 106 or uplift to Beta 106.

108

109

This ticket seems related to 1814188 because users aren't seeing their preferences being saved. Also flagging that in ticket 1814188 it sounds like it is mostly in Private Mode in case that relates to changes needed in this ticket.