Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Auto-grant storage access without requiring user interaction or explicit API call in cases determined to be safe #170

Open
lghall opened this issue Mar 29, 2023 · 4 comments
Labels
future Will consider for a future revision needs implementer interest Doesn't yet have enough implementer interest

Comments

@lghall
Copy link

lghall commented Mar 29, 2023

In Google Workspace, we have many use cases where embeds requiring cookies for authentication are loaded in a third-party context (for example, an embedded Google Doc which is only accessible to users within a domain). Today, that embedded content loads on Chrome without any explicit user action. After Chrome rolls out third-party cookie deprecation, we plan to use Storage Access API to allow the user to grant storage access to the embed for authentication purposes. We already use the Storage Access API approach on Firefox and Safari today.

From a user experience perspective, we would prefer if there are some cases determined to be safe by the browser, where the embedded content can be loaded without user interaction or requiring the application to make an explicit rSA call. This is already the case on Safari and FF today. We're interested in understanding whether such cases can be determined by the browser and allow us to avoid user-facing prompts in some scenarios.

@annevk annevk added the future Will consider for a future revision label Sep 5, 2023
@johannhof johannhof added the needs implementer interest Doesn't yet have enough implementer interest label Sep 5, 2023
@DavidScales
Copy link

This could also be valuable for my own use case, where my primary concern with SAA is the user dialogue.

To recap (maybe just for me) the potential states for 3P cookie opt-in behavior post deprecation seems to have 3 options:

  1. SAA is implemented & explicitly prompts user for consent
  2. SAA is implemented & the browser can implicitly grant consent based on heuristics (this could be seen as a progressive enhancement of option 1)
  3. SAA is NOT implemented and the browser implicitly grants consent based solely on proposed heuristics.

This FR (option 2) could potentially be a good middleground for my use case (3P edTech apps embedded as iframe into classroom.google.com).

The drawback of option 1 for me is the user prompt, which is not ideal for my users (underage students with limited consent ability, admin-limited Chrome settings, and high risk of confusion).

The drawback of number 3 is that it Chrome may not want to rely on heuristics entirely, either for privacy or accuracy reasons.

Option 2 could allow some flexibility for enabling Chrome to get explicit consent when it's needed, but minimize friction when it's not. This might be an oversimplification on my end.

A drawback of option 2 compared to option 3 is that developers still need to implement SAA.

@DavidScales
Copy link

Re-reading the actual FR I may have mistaken the intent. I read this as just "skip the user prompt in SAA calls sometimes" rather than "don't require SAA calls at all sometimes". But I think the points stand.

@cfredric
Copy link
Contributor

Hi - I've published a proposal for HTTP request/response headers that I believe is somewhat related to this (original) feature request: https://github.com/cfredric/storage-access-headers

Please take a look and let me know if that proposal would be helpful for this, and/or how it could be improved!

@DavidScales I don't think this proposal addresses your feature request, since IIUC you are asking for a way to skip the user prompt in non-RWS scenarios.

@DavidScales
Copy link

Thanks for this proposal @cfredric. While you're right that it doesn't address my overall concern, your proposed solution does sound like it would be helpful nonetheless. I've made a note in #130 which seems related to this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Will consider for a future revision needs implementer interest Doesn't yet have enough implementer interest
Projects
None yet
Development

No branches or pull requests

6 participants
@annevk @johannhof @cfredric @DavidScales @lghall and others