Consider supporting partition state in other contexts

[DavidScales]

My use case is 3P education tech apps embedded as iframes into my top level site (classroom.google.com).

As described in that thread, the typical Identity Provider (Idp) OAuth single sign on (SSO) flow will break once 3P cookies are deprecated. In addition, a common and critical user journey for these 3P applications is for the iframe to push the user into a new top level tab, for example, to complete a learning activity that needs more screen space.

CHIPS is insufficient here for both cases:

1. For SSO, the partitioned iframe state can't access session cookies set in the top level state of the SSO pop up; the user can't sign into the iframe.
2. For new tabs, the top level tab state can't access the session cookies set in the partioned iframe state; the user journey is disconnected.

These are probably and understandably by design, but I wonder if CHIPS could ever support "transferring" or maintaining the partitioned state to a top level? For example, as a configuration in window.open().

• If an iframe could open a pop up but maintain the partitioned storage state, perhaps the SSO flow would work because the session cookie set in at the end of sign-in would be in the partitioned state and accessible to iframe when the pop up closes.
• If an iframe could open a new tab but maintain the partitioned storage state, a user being moved into a new tab would be be able to continue their journey from the iframe.

There's probably a lot of oversimplification in my assumptions here.

I am evaluating the Storage Access API as an alternative, but myself and my partners have concerns over the associated user prompt for our particular user base. CHIPS would be a simpler solution both in implementation and intention; we don't necessarily want to create and associate two user sessions (one in the iframe and one in the top level), we just need the single iframed session to be accessible in different contexts, if that makes sense.

Thanks

[krgovind]

My apologies for missing this @DavidScales. Thank you for the feedback. We've received similar suggestions in #79 and #80, and are considering this. FedCM, and Storage Access API are indeed the other solutions that are currently being discussed in the web standards space, so thank you for the pointer to w3c-fedid/FedCM/issues/467.

cc/ @cfredric @johannhof

[bvandorn]

I've been keeping tabs on a lot of these issues and have found that the Storage Access API as implemented in Chrome does not support this use case (though it is supported correctly in other browsers) - the problem being that cookies set on the users browser are not sent with a browser request after access has been granted and only after each call to request access, even if it does not require user interaction on subsequent attempts.

I've found that two cookies, one for 1P and one for 3P (as described in #51 (comment)) is the closest viable solution without venturing down the FedCM path. This does rely on the heuristics testing described in #80 (comment) working as expected - which they do seem to be in most cases.

Unfortunately with Safari not yet supporting CHIPs, we still need to rely on their implementation of Storage Access for cases where third party cookies are blocked (only enabled by default in safari private browsing at the moment)

[cfredric]

Hi @bvandorn,

Thanks for the feedback!

the problem being that cookies set on the users browser are not sent with a browser request after access has been granted and only after each call to request access, even if it does not require user interaction on subsequent attempts.

I'd like to clarify that Chrome's behavior here is intentional for security reasons, and Firefox has followed suit (Firefox's announcement). (No word from Safari yet on whether they plan to update their implementation to match the spec.)

With that said, I recognize that this restriction is very limiting; I've proposed https://github.com/cfredric/storage-access-headers to improve ergonomics and utility without regressing security. Please take a look, and see if that would allow Storage Access API to address your use case -- and if it wouldn't, please let us know why not :).

without venturing down the FedCM path

I'm also curious to hear about your evaluation of FedCM. Which parts of FedCM are attractive? Which parts make it nonviable as a solution for your use case? If FedCM granted access to unpartitioned cookies, would that make it viable for your use case?

Thanks!

[bvandorn]

Hmm, I hadn't realized Firefox had switched since I last tried that. I do see that behavior now. Presumably security reasons are the ways it can be leveraged to continue tracking the user in non-auth scenarios?

Please take a look, and see if that would allow Storage Access API to address your use case

I like the concept of the agent retrying with cookies on the user's behalf without requiring javascript, though if server work is already required, I'm not sure if I prefer this or CHIPS - probably CHIPS in a fully embedded widget because it doesn't ever require user interaction. There are a few headaches with CHIPS (such as which cookie takes precedence if a non-partitioned cookie exists and is allowed - usually in 1P situations) but you likely would never run into that when embedding, only when you are juggling an application that is both embedded and not embedded.

The use case I see still having an issue here would be a top level frame sending cookies with a request to a third party (i.e. via fetch). If the user has allowed Storage Access in the context of that site, ideally the top level would send those cookies. I do understand how this might be confusing for an end user and end up with them accidentally allowing themselves to be tracked for advertising reasons 😕 I believe requestStorageAccessFor is the intended solution for this use case, but I haven't had success trying to use it and if it has similar limitations, it might still be limited here.

That being said, both Chrome's and Firefox's heuristics have done the job effectively enough in my testing so far.

Which parts of FedCM are attractive? Which parts make it nonviable as a solution for your use case? If FedCM granted access to unpartitioned cookies, would that make it viable for your use case?

The idea and motivations behind FedCM are attractive to me, from the standpoint of federated auth itself. Right now it's not viable with lack of support and the work involved on both javascript + server side implementation, not to mention user adoption. With browser support as is, I haven't even attempted to implement, so I can't speak too much about it.

[cfredric]

Presumably security reasons are the ways it can be leveraged to continue tracking the user in non-auth scenarios?

I consider tracking risk to be a privacy concern, rather than security, per se. The security concern is about the "ambient authority" that's traditionally associated with third-party cookies; we want to instead require the iframe to explicitly choose to send those cookies (if it wants to). (This helps protect against CSRF attacks, e.g.) See here for a long discussion: privacycg/storage-access#113.

The use case I see still having an issue here would be a top level frame sending cookies with a request to a third party (i.e. via fetch). If the user has allowed Storage Access in the context of that site, ideally the top level would send those cookies.

This scenario would be supported by https://github.com/cfredric/storage-access-headers, using the Activate-Storage-Access: retry mechanism. (I think it's possible to avoid the extra round trip in some cases (discussion in privacycg/storage-access-headers#3), but I haven't written up my idea for this yet.) Apologies if the explainer didn't make that clear.

this might be confusing for an end user and end up with them accidentally allowing themselves to be tracked for advertising reasons 😕

The Storage Access API is not intended to support advertising use cases. In fact, Chrome's implementation goes beyond the Storage Access API spec and additionally rejects all document.requestStorageAccess() requests unless the user has visited the embedded site as a top level in the last 30 days (or the embedded and top-level sites are in the same Related Website Set). Our assumption is that most users will not have directly visited the ad-tech sites, let alone recently, so this requirement renders the Storage Access API effectively useless for advertisers in Chrome.

But aside from that - the Storage Access Headers proposal intentionally doesn't expose anything until the user grants the storage-access permission. So by assumption, any usage of those headers occurs after the user has already said they're okay with the site getting access to its unpartitioned data in that embedded context.

Right now [FedCM]'s not viable with lack of support

I assume you mean lack of cross-browser support, right?

not to mention user adoption.

Can you clarify what you mean by this? Are you referring to the JS changes that are required on the "relying party" site?

[bvandorn]

Gotcha, I didn't realize storage-access-headers was addressing the top level context as well. Combining that with a working implementation of requestAccessFor sounds good to me and would solve the issues presented with CHIPS 👍

The Storage Access API is not intended to support advertising use cases.

Sorry! I didn't meant to imply that, I just meant that the messaging around the request "xyz wants to use the info they've saved about you" doesn't give the end user much confidence that it's not being used for advertising. But I guess if you're accepting it anyway, you're trusting xyz and want to use it.

I assume you mean lack of cross-browser support, right?

Yes, lack of browser support. CHIPS (and storage-access-headers) are nice because the fallback is plain old 3P cookies. FedCM - and maybe I don't know enough about it to say this - requires a separate implementation that would still require the site to maintain some separate auth methods for other browsers.

that are required on the "relying party" site?

Yep, I'm referring to the "Relying Party" adoption. But I suppose that's the same with any new thing coming their way if they want to avoid their users jumping through hoops.