1746031 - "Storage_access" permission is not asked again if allowed once

Status: NEW

(GeckoView :: General, defect, P2)

Description

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 1

[Paul Zühlcke [:pbz]]

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.

Comment 2

[Tim Huang[:timhuang]]

Hi Arturo,

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

Comment 3

[Arturo Mejia [:amejia]]

(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 :)

Comment 4

[Jonathan Almeida [:jonalmeida]]

Adding this back to GV triage.

Comment 5

[Emily Toop (:fluffyemily)]

Arturo, do you have a priority for this issue?

Comment 6

[Arturo Mejia [:amejia]]

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

Comment 7

[Arturo Mejia [:amejia]]

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

Comment 8

[Chris Peterson [:cpeterson]]

I see the same behavior in Firefox desktop, so

Comment 9

[Chris Peterson [:cpeterson]]

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.

Comment 10

[Chris Peterson [:cpeterson]]

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.

Comment 11

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 12

[Chris Peterson [:cpeterson]]

(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.

Comment 13

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 14

[Paul Zühlcke [:pbz]]

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.

Comment 15

[Chris Peterson [:cpeterson]]

Attachment: site-permissions-door-hanger.png

(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?

Comment 16

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 17

[Chris Peterson [:cpeterson]]

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.

Comment 18

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 19

[Chris Peterson [:cpeterson]]

(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.

Comment 20

[Chris Peterson [:cpeterson]]

105

Comment 21

[[:owlish] 🦉 PST]

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)

Comment 22

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 23

[Chris Peterson [:cpeterson]]

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

Comment 24

[Chris Peterson [:cpeterson]]

108

Comment 25

[Chris Peterson [:cpeterson]]

109

Comment 26

[Zac McKenney [:zmckenney]]

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.

Comment 27

[David Lawrence [:dkl]]

Moving to General