1740329 - Salesforce application gives misleading error message due to dFPI

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P2)

Description

[Kathleen Wilson]

Salesforce seemingly randomly displays the following error message on Firefox Nightly (noticed in FF 95, continuing in FF 96).

We can't display this page because your browser blocks cross-domain cookies. Try again with a different supported browser.

When the error message starts happening, I am able to get it to stop by turning off Enhanced Tracking Protection via the shield icon in the Firefox address bar.

Explanation by Dan Veditz: "Standard" is fine, doesn't need to be "off". The problem is dynamic First-Party Isolation (dFPI) which is newly part of "Strict" in nightly.

Screenshots are available here: https://bugzilla.mozilla.org/show_bug.cgi?id=1712018#c17

Comment 1

[Daniel Veditz [:dveditz]]

Specifically we're seeing this on our Common CA Database app at https://ccadb.my.salesforce.com/, which appears to involve resources from *.salesforce.com and *.visualforce.com (and maybe *.force.com, too?). The initial login works fine, but after several hours (maybe when an oauth token needs to be refreshed?) we get the above message.

I don't know if Salesforce will fix this on their end by using the Storage Access API, or if we need a compat-shim of some kind for safeforce apps. Can't really call it a "bug" in dFPI -- this is just a natural consequence. There are few enough users of CCADB that we could just instruct them all to turn off dFPI or add cookie exceptions for the domains involved, but I'm pretty confident all the ".my.safeforce.com" apps (and maybe more salesforce things) are going to have this issue. That's a whole ton of users judging by their revenue numbers

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to Kathleen Wilson from comment #0)

Explanation by Dan Veditz: "Standard" is fine, doesn't need to be "off". The problem is dynamic First-Party Isolation (dFPI) which is newly part of "Strict" in nightly.

I misspoke. dFPI ("Total Cookie Protection") has been part of "Strict" tracking protection since Firefox 86, and in those versions switching to "Standard" would fix the problem. The change in Nightly 95 (not riding the trains) is that dFPI is the default all the time even in "standard" tracking protection mode. Switching to "Standard" will not fix the problem in Nightly. Options until fixed on the Salesforce side include

1. add Tracking Protection exceptions (turned off) for the salesforce domains
2. add cookie exceptions ("Allow") for the salesforce domains
3. use "Custom" tracking protection and change the cookie setting to turn off dFPI everywhere

This may be a useful blog post for someone trying to make their site compatible with dFPI:
https://hacks.mozilla.org/2021/02/introducing-state-partitioning/

dFPI has been the default in Private Browsing since Firefox 89.

Comment 3

[Tim Huang[:timhuang]]

I guess our storage access redirect heuristics granted the storage access during the login and this makes it work at the beginning. However, the permission only lasts for 15 mins. So, the issue starts appearing after the permission expired.

I think the right solution is to ask salesforce to use Storage Access API, but there are things we can do to mitigate this issue. For example, we can extend the permission expired time to 30 days. We had a discussion regarding this before and we think this is a reasonable change and can reduce breakages to a certain extent. Or we can try to add a shim for this. However I don't have an account, so I cannot test this to see if a shim is available here. But, from what I saw in https://ccadb.my.salesforce.com/, there is a login button and we probably can add a shim when the user click the login button.

Comment 4

[Kathleen Wilson]

(In reply to Tim Huang[:timhuang] (PTO until 11/16) from comment #3)

but there are things we can do to mitigate this issue. For example, we can extend the permission expired time to 30 days. We had a discussion regarding this before and we think this is a reasonable change and can reduce breakages to a certain extent.

That should definitely reduce the breakage, and I'm happy to test that.

Or we can try to add a shim for this. However I don't have an account, so I cannot test this to see if a shim is available here. But, from what I saw in https://ccadb.my.salesforce.com/, there is a login button and we probably can add a shim when the user click the login button.

Would that change be specific to CCADB? I am more concerned about all of the other Salesforce users.
(I can tell the CCADB users how to configure their browsers to use CCADB, so limited impact there. I view CCADB as a canary for other Salesforce users on Firefox.)

Comment 5

[Tim Huang[:timhuang]]

(In reply to Kathleen Wilson from comment #4)

(In reply to Tim Huang[:timhuang] (PTO until 11/16) from comment #3)

but there are things we can do to mitigate this issue. For example, we can extend the permission expired time to 30 days. We had a discussion regarding this before and we think this is a reasonable change and can reduce breakages to a certain extent.

That should definitely reduce the breakage, and I'm happy to test that.

We have a pref that allows us to adjust the expired time, which is privacy.restrict3rdpartystorage.expiration_redirect. You could manually change this to 30 days to see if the problem mitigates.

Or we can try to add a shim for this. However I don't have an account, so I cannot test this to see if a shim is available here. But, from what I saw in https://ccadb.my.salesforce.com/, there is a login button and we probably can add a shim when the user click the login button.

Would that change be specific to CCADB? I am more concerned about all of the other Salesforce users.
(I can tell the CCADB users how to configure their browsers to use CCADB, so limited impact there. I view CCADB as a canary for other Salesforce users on Firefox.)

The shim can apply to all matching domains for salesforece.com as long as the login process is similar. But, it's expected that it could be different across Salesforce users. So, the ideal solution would be that Salesforce uses StorageAccessAPI. We should contact them about this.

Peter, would you be able to contact Salesforce about this to see if they are interested in supporting StorageAccessAPI?

Comment 6

[Peter Saint-Andre [:stpeter]]

I've reached out to my best contact at Salesforce and will report back.

Comment 8

[Kathleen Wilson]

Attachment: Screen Shot 2022-03-17 at 9.41.31 AM.png

This is happening in Firefox release (v98) now!

CCADB is a Salesforce cloud instance. To be clear, it's not the CCADB that I'm worried about (that's a rather small community). What I'm worried about is that Salesforce users (across all instances that use common tools from force.com and visualforce.com) will see this message unless they have added the cookie exceptions to their Firefox browser settings.

Rather than saying "Try again with a different supported browser." Salesforce should point people to https://help.salesforce.com/s/articleView?id=sf.pages_browser_security_settings.htm&type=5 or give similar instructions about which domains to add to their third-party cookie exceptions list in their browser settings.

Adding salesforce.com, force.com, and visualforce.com to the cookies exception list solves the problem.

The issue here is about the error message telling users to try again with a different browser.

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

Tim, are you the right person to re-visit this one?

Comment 10

[Tim Huang[:timhuang]]

Tom, would you be able to check if Shim script is helpful here?

Comment 11

[Thomas Wisniewski [:twisniewski]]

In general, if there is a login button, we can shim around it, yes.

Unfortunately in this case it seems each site can use its own login solution, as CCADB has their own login page which POSTS to their own subdomain for login. I suspect that don't want to make a shim which applies on every related subdomain, and tries to guess their possible login buttons. That leaves us having to shim on a site-by-site basis as we discover them.

Comment 12

[Kathleen Wilson]

Attachment: Screen Shot 2022-03-23 at 11.37.17 AM.png

Just FYI that my Salesforce admin filed a Salesforce Support Case about this.
We have also done so in the past, but each time the Salesforce Support Case would just get closed as us not using a supported browser. Now that the problem is in release, maybe they will do something about it...

Comment 13

[Kathleen Wilson]

Just FYI that our Salesforce Support Case is going to be closed for the following reason: "Unfortunately Salesforce Support can only assist with break/fix solutions. For any suggestions to our product or the messaging it provides, I would recommend reaching out to your account team with these suggestions or our idea exchange."

So someone from Mozilla should try to find an alternative path for working with Salesforce to updated their error message.

Comment 14

[[e-mail]]

Kathleen and Cameron Could not reproduce issue. According to Kathleen she tried to reproduce in FF 99.0.1and was not able to reproduce it

Last was an issue in FF 98