Storage Access renewal and permission lifetime

[jagadeeshaby]

Following up from here - https://github.com/privacycg/storage-access/issues/176

@cfredric - Could you elaborate more on the permission life time.

I have a similar use case where my customers use a SASS application provided by us, say if the user interacts with the page and clicks request access explicitly to grant permission, i see that these permissions are valid up to 30 days. How exactly this 30 days being calculated? is it the days since requestStorageAccess() invocation? Can i keep renewing the permission by invoking requestStorageAccess() to avoid prompts every 30 days?

[cfredric]

How exactly is this 30 days being calculated?

Chrome's implementation calculates the permission lifetime as 30 calendar days from the time that the permission is granted - i.e. from the document.requestStorageAccess or document.requestStorageAccessFor invocation. (I believe Safari counts "days of browser usage", but Chrome does not; Chrome just counts calendar days.)

Can i keep renewing the permission by invoking requestStorageAccess() to avoid prompts every 30 days?

No. Calling document.requestStorageAccess (when you have already been granted permission previously) does not renew the lifetime of the permission in Chrome. In order to renew the permission grant lifetime, your application's iframe must get user activation, e.g. from a click, as a signal that the user intends to keep using the embedded application.

[jagadeeshaby]

In order to renew the permission grant lifetime, your application's iframe must get user activation, e.g. from a click, as a signal that the user intends to keep using the embedded application.

Meaning user has to go through the same 2 steps process like a) user interaction to request access and then grant access via permission popup?

Yes our customers always interact with this Iframed SASS application on a daily basis.

[cfredric]

Meaning user has to go through the same 2 steps process like a) user interaction to request access and then grant access via permission popup?

No - just interaction with the iframe is sufficient to renew the permission, there's no need to call document.requestStorageAccess again and no need to show a permission dialog again.

[jagadeeshaby]

Awesome, thank you, that helps, technically if my customers keep interacting with the embedded site , they do get access to storage indefinitely :)

Sorry to spam on this issue there are few follow up questions here , let me know i can cut separate issue for this

• do we have any definitive timelines on this release (unpartitioned, non first party cases) - need this for all the customer communications and plan accordingly.
• also do you know any downside of going with this approach as opposed to CHIPS or first party sets?
• Does this work seamlessly if enterprise customers turn on 3rd party cookie access?

[cfredric]

do we have any definitive timelines on this release (unpartitioned, non first party cases) - need this for all the customer communications and plan accordingly.

Nothing yet. We posted an Intent to Prototype which gives some info on our planned timeline, but isn't firm. I (or a colleague) will post an Intent to Ship when we're ready, and I'll add a link to it to the Announcements section here.

also do you know any downside of going with this approach as opposed to CHIPS or first party sets?

CHIPS doesn't give access to unpartitioned cookies, but doesn't involve a prompt either. So:

• If your application needs to have access to the same cookies when embedded under a.com as it has under b.com (or when not embedded at all), then you need unpartitioned state, and CHIPS won't solve your problem (since it is about partitioned state).
• If your application doesn't need to access the same cookies under a.com as when embedded under b.com (or when not embedded at all), then you don't need unpartitioned cookie access, and CHIPS may be a viable approach for you. Since partitioned state poses less of a privacy risk than unpartitioned state, CHIPS doesn't need to prompt the user -- so if you can rely exclusively on CHIPS, you can provide a better user experience (by avoiding a prompt).

First-Party Sets is useful if your embedded application needs access to unpartitioned state while embedded in a site that it is related to.

• If the top-level site and the embedded site are in the same FPS, then Chrome automatically accepts the permission prompt on behalf of the user. So your app gets a better UX (by avoiding the prompt) and gets unpartitioned cookie access.
• If the top-level site and the embedded site aren't in the same First-Party Set (which I would guess is the case for your application, since it is a SaaS project and your customers' sites are likely not in the same FPS as your site), then First-Party Sets can't help you, unfortunately.

Does this work seamlessly if enterprise customers turn on 3rd party cookie access?

In Chrome, if third-party cookies are accessible, document.requestStorageAccess() should immediately resolve; document.hasStorageAccess() should return true. I invite you to try out Chrome Canary (or Chrome Dev, once it updates to M117) and see if its behavior works for you!

enterprise customers

If you are specifically thinking about enterprise customers, you should also be aware that there are Chrome Enterprise policies that can help with cookie access. In particular, CookiesAllowedForUrls and FirstPartySetsOverrides. Note that these enterprise policies come with their own tradeoffs, e.g. that they can only be used on enterprise-managed devices. Does the use case you have in mind involve only managed devices?

[jagadeeshaby]

Thank you so much for all the quick answers.

Nothing yet. We posted an Intent to Prototype which gives some info on our planned timeline, but isn't firm. I (or a colleague) will post an Intent to Ship when we're ready, and I'll add a link to it to the Announcements section here.

do you know if this comes before chrome deprecating 3p cookies ? (2024, Q1 - 1% globally)

I invite you to try out Chrome Canary (or Chrome Dev, once it updates to M117) and see if its behavior works for you!

Thank you.

that they can only be used on enterprise-managed devices. Does the use case you have in mind involve only managed devices?

Not sure i understand this limitation. Our customers use google chrome enterprise versions, so they should have access to to these policies?

[cfredric]

do you know if this comes before chrome deprecating 3p cookies ? (2024, Q1 - 1% globally)

In the I2P my colleague announced our intention to ship in or near M117 (desktop) and M119 (Android), which should be in Q3-Q4 of 2023 according to Chrome's release schedule. Our intention here hasn't changed - but we'll keep you posted in the Announcements section here when we have something more to say.

Not sure i understand this limitation. Our customers use google chrome enterprise versions, so they should have access to to these policies?

If you (or someone else) is managing the users' Chrome clients, then you (or the admin) can control what enterprise policies are installed and active for those users. The users themselves don't have direct control over the enterprise policies, if I understand correctly.

[cfredric]

I'm going to close this issue since I think I've answered your questions, but feel free to reopen or open new issues as needed.