search

WICG / first-party-sets

https://wicg.github.io/first-party-sets/
290 stars 75 forks source link

Storage Access API suitability for FPS use cases #97

Open helenyc opened 2 years ago

helenyc commented 2 years ago

[Note: This issue is related to the changes proposed in PR #91 and summarized on issue #92.]

We propose retiring the SameParty cookie attribute proposal and requiring calls to the Storage Access API to utilize set membership. This promotes active, rather than passive, cookie access grants, allowing browsers to make privacy-conscious access decisions on behalf of their users. The Storage Access API (or requestStorageAccess) is currently used by other browsers to facilitate cross-domain cookie access.

Can developers use requestStorageAccess (inside iframes, gated on user activation of iframe) to viably replace SameParty use cases? If not, will the rSA-for-site proposal be able to meet all of developers’ needs?

ChadKillingsworth commented 2 years ago

The requirement of user interaction is going to reduce the effectiveness of this proposal or lead to very reduced user experiences. My company is one of the main 3 financial service providers for US based banks providing online banking services to over 8 million US users. The following pattern is used widely in the industry:

First Party Sets Iframe Example

Using Request Storage Access for Site without requiring user interaction would allow the pattern to continue to function. If I am reading the proposals correctly, with the addition of requiring user interaction, these user experience cannot be maintained for traditional server-side rendered applications. Single Page Applications will be able to work as user interaction would almost always occur (though page refreshes may lead to odd experiences).

Specific use cases that I see as important to maintain:

Currently, providers have been issuing instructions for Safari and Firefox users on how to disable 3rd party cookie blocks to continue having full access to their online banking content. As Safari in particular does not allow this on a per-site basis, this is lowering the privacy protections for users substantially across all sites they visit. My hope was that with FPS there was a path forward that maintained privacy protections.

johannhof commented 2 years ago

@ChadKillingsworth that is very interesting, thank you for the concise explanation! One question that came to my mind immediately is that it seems like statementprovider.com is a differently owned/operated entity than bankname.bank, and also a shared service site that multiple different bank "parties" would use. This seems outside of scope of both the new and old FPS, unless I'm making some false assumptions here.

If that's true, I think it's interesting to consider which other APIs could preserve this use case. I'm thinking about partitioning (CHIPS), particularly. Can you share more about how the user would authenticate with statementprovider.com? Does it happen in a separate tab?

ChadKillingsworth commented 2 years ago

Differently owned and operated entity is a difficult concept to reconcile in this industry. bankname.statementprovider.com (the full subdomain) is operated by a different provider, but the users on that subdomain and the data therein is wholely owned by the bank. There is no desire to track or identify a user across different subdomains (in fact we work hard to prevent that from happening by accident).

These are typically SAS type engagements and a variety of providers collaborate to create a single experience on behalf of a bank (or credit union). This setup is a matrix of thousands of financial institutions and a few hundred providers which makes true first party DNS and certificate entries impractical for most. Tennant specific subdomains are fairly common however and I do see as a valid path forward.

Looking through the CHIPS APIs, I think it will help with some (but not all) of the use cases. Authenticated iframes look to be handled by CHIPS, but session keepalive requirements on related domains do not. Namely all the issues outlined in the readme for CHIPS would impact that case. FPS seems like a much closer fit.

johannhof commented 2 years ago

@ChadKillingsworth That means, if I understand correctly, that bankname.statementprovider.com needs to access the same cookies on at least two different top-level sites (one of which is online.bankname.bank). Could you describe what the other top-level site(s) would be and how they would fit in the user journey? I'd love to understand this flow better!

Thank you!

ChadKillingsworth commented 2 years ago

I'd be happy to outline that. To help make this make sense, I'm going to use the real domain names in use by one of our demo banks so that the domain names make sense: Garden-FI.

Primary Top-Level Navigation Contexts

These sites are never framed. Each site may be provided by a different service provider, but they are fully branded to the bank. Users on these sites are never associated to users on other banks.

Secondary Sites - Both Framed and Top-Level

These sites provided authenticated content within the online banking experience. Of special note is that these sites only provide fully authenticated experiences. Most don't have any sort of public page at all. They exist solely to augment the online banking experience.

Each can be a different SAAS provider, but the bank will always have a unique tenant and users are never associated across tenants. The vast preferred method by banks is that these sites be framed and that the main branding and navigation be housed by the online banking experience. In some cases these sites are top-level navigation, however users get confused in that case because they don't know how to get "back" to the main online banking site. Coordinating a consistent design and navigation across providers is also challenging which is another reason banks prefer this content to be framed.

Since these sites require authentication through the main online banking site, I'll provide domain names but not actual links:

There are several more possibilities here. I've just listed the most common ones.

Current State

As 3rd party cookie support has been phased out some browsers, providers have told users either how to disable 3rd party cookie blocks (which on Safari is unfortunately global) or simply recommend a different browser.

I've been watching the FPS proposal with great interest for quite some time as a potential solve for the US banking industry. However the recent proposal changes have left me pretty discouraged because it seems that the use cases needed are being once again prohibited. Financial service provider companies serve smaller banks and credit unions. Each site individually is too small to show up on any Top XXX type list, but in aggregate these providers can each offer services to millions of users. My hope is that a privacy-preserving path can be found that preserves the current experience.

If you need more information than what I have described here, I'd be happy to have further discussions. My email on my GitHub profile is public.

johannhof commented 2 years ago

@ChadKillingsworth for secondary sites, given that these have to be authenticated somehow, I assume that the authentication parameters will be passed in either via postMessage or query parameters on the iframe/top-level navigation URL, is that correct?

How frequently do you think users would see a flow where a secondary site has both an "authenticated embed" and a top-level page and requires shared state between them via 3rd party cookies?

ChadKillingsworth commented 2 years ago

I don't know that I can objectively quantify how often this is used. It's also hard for me to determine what the effect without it would be. For instance, to date Safari has blocked all cookies in the iframe completely. Partitioned cookies would fix that. With partitioned cookies though, a top-level navigation even to the embedded site would not share cookies. However, re-authenticating the user (through a traditional OAuth2 flow for instance) could restore pretty much any needed state. It would however require significant re-architecture of some of these systems to support those workarounds.