Update after chatting with Kathleen: when she did clear-recent-history in comment 10 she didn't include 'offline website data', which possibly was used to restore cookie values ( ¡speculation alert! ). She tried again making sure to nuke all the data and again could reproduce the log-in problem when `network.cookie.sameSite.laxByDefault` was set to `true`. My guess about comment 9 ( ¡speculation alert! ) is that Kathleen had some old cookies that were set without the SameSite=lax attribute, so that production database continued to work, and that earlier today the session token or some such cookie expired. When it was replaced it picked up the SameSite=lax default and then she ran into the problem. Salesforce's advice in comment 0 is designed for very old browsers, and isn't going to work for the SameSite=lax problem (at least, not in Firefox). They need to update that advice, and update their code to work in a SameSite=Lax world. > If you run into this error in the CCADB there is no need to change browsers. Making one of the following changes should resolve the error in your browser: > [1] Add the servers *.salesforce.com, *.force.com, and *.visualforce.com to your browser's cookies exception list > [2] Configure P3P for your browser > [3] Change your browser settings to allow third-party cookies I changed bullets to numbers in the above so I could reference them below: 1. This advice solves the problem of blocking 3rd party cookies, but it doesn't change the attributes on a cookie and therefore won't solve the SameSite-lax-by-default issue. 2. MS removed support for P3P from Windows 10 [more than 5 years ago](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/mt146424(v=vs.85)) and no one else supported it. 3. Again, this only helps if 3rd party cookie blocked was the only problem. It's a simpler but global version of #1 For users who *do* block all 3rd party cookies, or use a browser with some kind of tracking protection that blocks 3rd party cookies the advice in comment 1+3 would be useful. But SalesForce also need to support SameSite. In Chrome there is no longer a way to turn off the "SameSite=lax by default" behavior [since Chrome 94](https://www.chromium.org/updates/same-site?pli=1) , and presumably the same in Edge/Opera/Brave.
Bug 1712018 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Update after chatting with Kathleen: when she did clear-recent-history in comment 10 she didn't include 'offline website data', which possibly was used to restore cookie values ( ¡speculation alert! ). She tried again making sure to nuke all the data and again could reproduce the log-in problem when `network.cookie.sameSite.laxByDefault` was set to `true`. My guess about comment 9 ( ¡speculation alert! ) is that Kathleen had some old cookies that were set without the SameSite=lax attribute, so that production database continued to work, and that earlier today the session token or some such cookie expired. When it was replaced it picked up the SameSite=lax default and then she ran into the problem. Salesforce's advice in comment 0 is designed for very old browsers, and isn't going to work for the SameSite=lax problem (at least, not in Firefox). They need to update that advice, and update their code to work in a SameSite=Lax world. > If you run into this error in the CCADB there is no need to change browsers. Making one of the following changes should resolve the error in your browser: > [1] Add the servers *.salesforce.com, *.force.com, and *.visualforce.com to your browser's cookies exception list > [2] Configure P3P for your browser > [3] Change your browser settings to allow third-party cookies I changed bullets to numbers in the above so I could reference them below: 1. This advice solves the problem of blocking 3rd party cookies, but it doesn't change the attributes on a cookie and therefore won't solve the SameSite-lax-by-default issue. 2. MS removed support for P3P from Windows 10 [more than 5 years ago](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/mt146424(v=vs.85)) and no one else supported it. 3. Again, this only helps if 3rd party cookie blocking was the only problem. It's a simpler but global version of #1 For users who *do* block all 3rd party cookies, or use a browser with some kind of tracking protection that blocks 3rd party cookies the advice in comment 1+3 would be useful. But SalesForce also need to support SameSite. In Chrome there is no longer a way to turn off the "SameSite=lax by default" behavior [since Chrome 94](https://www.chromium.org/updates/same-site?pli=1) , and presumably the same in Edge/Opera/Brave.
Update after chatting with Kathleen: when she did clear-recent-history in comment 10 she didn't include 'offline website data', which possibly was used to restore cookie values ( ¡speculation alert! ). She tried again making sure to nuke all the data and again could reproduce the log-in problem when `network.cookie.sameSite.laxByDefault` was set to `true`. My guess about comment 9 ( ¡speculation alert! ) is that Kathleen had some old cookies that were set without the SameSite=lax attribute, so that production database continued to work, and that earlier today the session token or some such cookie expired. When it was replaced it picked up the SameSite=lax default and then she ran into the problem. Salesforce's advice in comment 0 is designed for very old browsers, and isn't going to work for the SameSite=lax problem (at least, not in Firefox). They need to update that advice, and update their code to work in a SameSite=Lax world. > If you run into this error in the CCADB there is no need to change browsers. Making one of the following changes should resolve the error in your browser: > [1] Add the servers *.salesforce.com, *.force.com, and *.visualforce.com to your browser's cookies exception list > [2] Configure P3P for your browser > [3] Change your browser settings to allow third-party cookies I changed bullets to numbers in the above so I could reference them below: 1. This advice solves the problem of blocking 3rd party cookies, but it doesn't change the attributes on a cookie and therefore won't solve the SameSite-lax-by-default issue. 2. MS removed support for P3P from Windows 10 [more than 5 years ago](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/mt146424(v=vs.85)) and no one else supported it. 3. Again, this only helps if 3rd party cookie blocking was the only problem. It's a simpler but global version of #1 For users who *do* block all 3rd party cookies, or use a browser with some kind of tracking protection that blocks 3rd party cookies, the advice in bullets 1 and 3 would be useful. But SalesForce also needs to explicitly support SameSite to get `SameSite=None` behavior. In Chrome there is no longer a way to turn off the "SameSite=lax by default" behavior [since Chrome 94](https://www.chromium.org/updates/same-site?pli=1) , and presumably the same in Edge/Opera/Brave.