Age Out Of Granted Storage Access

johnwilander commented 4 years ago

Mozilla's documentation on differences between Safari's and Firefox's implementation covers the difference explained below albeit with a slightly incorrect description of Safari's behavior.

Safari: Granted storage access is aged out when website data is deleted by the tracking prevention feature itself which triggers after 30 days of Safari use without user interaction. Successful use of the Storage Access API resets that counter.

Firefox: Granted storage access is aged out after 30 calendar days regardless of usage patterns.

I don't think the age out is a crucial part of the API so I'm fine leaving it as a browser choice in the spec.

Brandr0id commented 4 years ago

Agreed, leaving this specifiable by the implementer makes sense to me. Even within Chromium there may be different embedders that wish to have different time constraints on these grants.

ehsan commented 4 years ago

That sounds fine to me as well. BTW I updated that wiki page to fix the description of Safari's behaviour, apologies for our mistake!

johnwilander commented 4 years ago

I added a section called "Scope of Storage Access" in https://github.com/privacycg/storage-access/commit/32e1d3f46c8780f51966ed5880a981eab88d3136. As noted there, if storage is frame-specific, it's not clear how age-out beyond the lifetime of the page (or iframe) could work.

jameshartig commented 4 years ago

Resetting the expiration based on successful usage seems like it would solve #8 and would prevent people from having to login every 30 days. Would we be willing to add something to the spec about that or would that also be up to the implementation?

johnwilander commented 4 years ago

Resetting the expiration based on successful usage seems like it would solve #8 and would prevent people from having to login every 30 days. Would we be willing to add something to the spec about that or would that also be up to the implementation?

WebKit’s implementation already does this, for that reason. Granted storage access through the Storage Access API counts as user interaction as first party (=renews the time stamp) in the eyes of ITP.

Since I don’t think any other browser is deleting website data based on user interaction like ITP (true?), I’ve been reluctant to add such details. I’ll add such a section if there is interest from other implementers.

johannhof commented 3 years ago

On Firefox side we would like to suggest automatically renewing storage access in any of the following cases:

On successful use of the storage access API (in a cross-origin iframe)
On any user interaction with a cross-origin iframe that already has storage access granted (this is to avoid developers hanging storage access requests onto unrelated button clicks as a hack to renew storage access, or having to show interstitial "yes I want to keep the site working" buttons)

We could standardize on these (the renewal mechanism) and leave the expiry mechanism (after x days of y kind of usage) implementor-specific.

Note that in Firefox "losing storage access" is technically a different thing than getting storage "purged" through the deletion mechanisms that both Firefox and Safari implement. However, the criteria for the two events are essentially the same (no user interaction in 45 days) and they are somewhat coupled in our code base. So this is very similar to Safari now, to the point where it might make for a good developer experience to call out the deletion mechanism explicitly.

johnwilander commented 2 years ago

On Firefox side we would like to suggest automatically renewing storage access in any of the following cases:

On successful use of the storage access API (in a cross-origin iframe)

On any user interaction with a cross-origin iframe that already has storage access granted (this is to avoid developers hanging storage access requests onto unrelated button clicks as a hack to renew storage access, or having to show interstitial "yes I want to keep the site working" buttons)

I think this is good. Two notes:

I assume that "successful use of the storage access API" means "being granted storage access through the API." Being denied could also be "successful use." :)
"Any user interaction with a cross-origin iframe" should be an alternative to the above point, so that user agents don't have to do both.

That should ensure that interaction in a cross-site iframe counts as first party interaction if the interaction either results in storage access or happens during storage access.

We could standardize on these (the renewal mechanism) and leave the expiry mechanism (after x days of y kind of usage) implementor-specific.

Note that in Firefox "losing storage access" is technically a different thing than getting storage "purged" through the deletion mechanisms that both Firefox and Safari implement. However, the criteria for the two events are essentially the same (no user interaction in 45 days) and they are somewhat coupled in our code base. So this is very similar to Safari now, to the point where it might make for a good developer experience to call out the deletion mechanism explicitly.

bvandersloot-mozilla commented 2 years ago

I assume that "successful use of the storage access API" means "being granted storage access through the API." Being denied could also be "successful use." :)

Your assumption is correct. A user deny will not count here.

"Any user interaction with a cross-origin iframe" should be an alternative to the above point, so that user agents don't have to do both.

I don't see how this alternative is different. If you are renewing a permission, isn't it required that the iframe already has the storage access granted?

We added the changes suggested by @johannhof to our implementation in Firefox, shipped in Firefox 97.

johannhof commented 1 year ago

Standardizing the "renewal" mechanism (which we should still do) is somewhat blocked on #121 as that would tell us how to tell the browser to renew the permission or storage access map.

privacycg / storage-access

Age Out Of Granted Storage Access #5