FR: Request header to indicate storage access

[lghall]

Currently, the server has no way of knowing whether a particular document request was initiated from an iframe without storage access. Many applications wish to serve a different page when the requested frame does not have storage access, to prompt the user for access (for example, we do this in Google Docs on Safari and Firefox). Currently, we’re forced to do this check on the client. It would be preferable if there could be a request header indicating whether the given request is from a context that does not have storage access.

[annevk]

Can't you tell this from a cookie?

[lghall]

Maybe I'm misunderstanding the suggestion, but we want to disambiguate between "The user is not logged in" and "The request is coming from a frame without storage access".

[annevk]

If you use a different cookie for "got storage access" and "got storage access and user logged in" that seems possible to achieve. One thing that might be tricky is identifying a partitioned context. https://github.com/w3c/webappsec-fetch-metadata/issues/80 and variants aim to address that, although not much progress has been made recently.

[cfredric]

If I understand correctly, a cookie-based approach doesn't really solve the problem @lghall is describing, since the server would have no way to distinguish a new user (or new device) which doesn't yet have cookies from an existing user/device that just hasn't granted storage access yet.

My first thoughts for this issue are of:

1. Fetch Metadata
2. User-Agent Client Hints

Adding a new Fetch metadata header would work AFAIK, but would mean the browser always leaks the "has storage access" bit (which may be fine, since its value would change so often). A new UA-CH header would require an extra round-trip, but would avoid leaking that bit by default.

[miketaylr]

User-Agent Client Hints

(nit: this would probably just be a client hint, not a user-agent client hint - since it has nothing to do with the User-Agent string)

[cfredric]

Hi - I've published a proposal for HTTP request/response headers that I believe would satisfy this 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 share the underlying issue here (which is also partially captured in #189 ) for Google Classroom add-ons (3P EdTech embeds in classroom.google.com). @cfredric has already captured the problem description accurately in explainer.

[remko]

Our EdTech tool is embedded in several contexts, including Google Classroom add-on (as @DavidScales mentioned).

I want to confirm that @cfredric 's proposal looks good to us:

• For our Google Classroom add-on, "Key Scenario 1" would apply, because we want to restore previously authenticated sessions (without the client-side check first) so we don't need to go through the sign-in flow for these.
• We are also embedded as an LTI tool. LTI is basically an IdP-initiated OpenID connect flow in an iframe. The difference between this flow and the add-on flow is that the iframe needs to first redirect from our domain back to the IdP domain before being redirected back to our domain. We need to preserve a cookie across this redirect (amongst others for CSRF mitigation). This means "Key scenario 2" also applies to us.

One thing I wanted to point out is that the LTI flow's final step can be a form POST instead of a GET, i'm not sure if this has an impact on the retry behaviour.