1924008 - Zelle bank-transfer-service won't load in Nightly, at sfcu.org (due to network.cookie.cookieBehavior.optInPartitioning being default-enabled now)

Status: NEW

(Web Compatibility :: Privacy: Site Reports, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Log in to your bank or credit union that supports Zelle for money-transfers (https://www.sfcu.org/ in my case)
2. Click to open Zelle.

ACTUAL RESULTS:
Blank page.

EXPECTED RESULTS:
Successful load of Zelle UI.

mozregression points to https://bugzilla.mozilla.org/show_bug.cgi?id=1915383 as the regressor here.

If I revert the effects of that bug by setting network.cookie.cookieBehavior.optInPartitioning to false, then I get EXPECTED RESULTS.

(I don't know how broadly Zelle uses the same framing/authentication strategy across various banks, so I'm not sure if this affects all Zelle usages vs. just the one at SFCU.)

Comment 1

[Daniel Holbert [:dholbert]]

(the regressing pref-flip landed in the 132 nightly cycle, but fortunately it enabled the pref in a Nightly-only way ( https://hg.mozilla.org/mozilla-central/rev/272abc23ad36 ), so we can mark this disabled for 132 now that it's on beta.)

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1915383

:timhuang, since you are the author of the regressor, bug 1915383, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Maire Reavy [:mreavy]]

FYI: I could not repro this bug with Wells Fargo nor Bank of America.

Comment 4

[Daniel Holbert [:dholbert]]

Dan/Tim: let me know if there's any data that'd be useful for me to gather, or configuration that'd be useful to test here, to assist in getting this addressed or papered-over. (happy to hop on Zoom if synchronous investigation is worthwhile/useful too.)

Comment 5

[Donal Meehan [:dmeehan]]

Pref: network.cookie.cookieBehavior.optInPartitioning

Comment 6

[Daniel Holbert [:dholbert]]

I just retested and confirmed that this does still affect Nightly (unless I flip the aforementioned optInPartitioning pref to false).

One additional note for folks testing this in the future: today I happened to be initially testing with Mozilla VPN turned on (using Houston TX as my exit node), and that prevented Zelle from from working in any browser/configuration on my machine -- Zelle would render a page saying that the request was blocked, with status 403 showing up in DevTools' network pane. I suspect Zelle (or some piece of it) might block known VPN exit nodes, or at least certain ones where they've seen suspicious traffic, perhaps. Anyway - after I turned off my VPN, I was able to repro the same results described in comment 0 (blank zelle UI in the default configuration, working Zelle UI when I flip the pref.

Comment 7

[Tim Huang[:timhuang]]

Hi Daniel,

Could you share which domains received partitioned cookies and storage access when you encountered the issue? The Devtool console log should show the message Partitioned cookie or storage access was provided to <URL>....

Comment 8

[Tim Huang[:timhuang]]

Oh, sorry.

We should check the message Cookie has been rejected because it is foreign and does not have the “Partitioned“ attribute instead but not the one I mentioned before.

Comment 9

[Daniel Holbert [:dholbert]]

The log message doesn't mention the domain, but I imagine the URL of the script is sufficient; if not, let me know.

I just performed the STR and the first such message in my console is:

Cookie “.AUTH” has been rejected because it is foreign and does not have the “Partitioned“ attribute.      RemoteAccess

...where "RemoteAccess" is linked to this URL: https://ppl.ibanking-services.com/PP_FIS-9995/RemoteAccess

There are 4 distinct versions of this log message for that^ URL (with differently named cookies), and then there are two copies of this message for these two URLs:
https://ppl.ibanking-services.com/PP_FIS-9995/Zelle/ZellePay/Home/ac0798b0-6733-47a3-b80c-784ff9bde79c
https://cds-sdkcfg.onlineaccess1.com/common.js

Comment 10

[Daniel Holbert [:dholbert]]

Additionally: simply at login to the SFCU web-banking site (before trying to launch Zelle), I get some other copies of that same cookie-has-been-rejected message. Nothing obviously breaks when these appear, but they might conceivably be associated with downstream breakage, whether Zelle or elsewhere...

Here are those URLs:
https://q2smart.q2ebanking.com/ecom/spaces/serve?company=5105&space=10&user=210353&containerId=ember73&_=1738170378126
https://sdk-cdn.onlineaccess1.com/sdk-nginx-prd/sdkcdn/sdk-q2-accounts-prd-6a9ef001/Accounts/assets/index.html?tct-id=Accounts_AccountWidget.Accounts.AccountWidget&tct-maxHeight=&tct-maxWidth=&tct-outlet-name=Accounts_AccountWidget#/account-block

Comment 11

[Tim Huang[:timhuang]]

Thanks,

Could you check if setting the pref network.cookie.cookieBehavior.optInPartitioning.skip_list to https://sfcu.org,https://ibanking-services.com can fix the issue?

Comment 12

[Daniel Holbert [:dholbert]]

Yes, that does indeed fix the issue.