1831527 - Stale Cookie Threshold too high

Status: UNCONFIRMED

(Core :: Networking: Cookies, enhancement, P3)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cookies' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Valentin Gosu [:valentin] (he/him)]

(In reply to Tony Davis from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Tried to log into a site I use a lot
[REDACTED]
and when the cookies build up to over 40, I get a login loop, that is most likely to do with bad SAMESITE cookie options handling, or stale cookies, and I suspect it is causing a race condition with the ReCapcha code to stop robots.

Actual results:

Login loop when stale or bad/old cookies are left lying around.
NOTE: clearing this specific site's cookies (all 46 of them!) fixed this issue, BUT, see below.

Expected results:

Normal login process, with the ability to tick the "I am not a robot" box.
I would suspect (hope) that altering the PREF network.cookie.staleThreshold from the default of 60, down to 30 might help this situation, as many sites are notoriously bad at deleting or rolling out old cookies.

This seems like an issue that is very specific to this one website.
Did setting network.cookie.staleThreshold to 30 actually help?

Comment 3

[Tony Davis]

That is a difficult question to answer, because I had already cleared the cookies first, to fix the issue, before doing a bit of research, where I later found the PREF network.cookie.staleThreshold set at the default of 60.

I HAVE now set this to 30, on the Windows 10 laptop where I DO tend to browse that website regularly, but I will have to wait until I get the stale cookie build-up, which could be a month or more.

Do you have any "internals" information on this specifc (or related) PREF, that might shed more ligh on the usefulness of reducing it to 30? For instance, is this for each domain, or browser wide? Why was 60 chosen in the first place?

By the way, I HAVE seen similar issues regarding suspected stale cookies, and old/bad cookies with bad SAMESITE parameters, on other sites (notably the ASUS site, and the Australian store site COLES) affecting the ability to log in, or to not display the ReCaptcha graphic/function, although not usually a repeated loop. Of course, all sites are coded differently, and so the effects of this issue may vary a lot.

Comment 4

[edgul]

I'm a bit confused here, when you say "when the cookies build up to over 40" it sounds like you are talking about having 40 stale cookies, is that correct?

I ask because network.cookie.staleThreshold doesn't seem to have anything to do with the number of cookies purge limit, instead it looks like it's used to add a little bit of a buffer (in seconds) when determining if any given cookie is stale or not.

https://searchfox.org/mozilla-central/rev/4e6970cd336f1b642c0be6c9b697b4db5f7b6aeb/netwerk/cookie/Cookie.cpp#138-139
https://searchfox.org/mozilla-central/rev/4e6970cd336f1b642c0be6c9b697b4db5f7b6aeb/modules/libpref/init/StaticPrefList.yaml#11241-11242

Comment 5

[edgul]

Also, do you get similar behavior on other browsers for this website?

Comment 6

[Tony Davis]

Attachment: GOODGUYS BROWSER CONSOLE OUTPUT DURING LOGIN LOOP.docx

Console error log taken during the login loop issue.

Comment 7

[Tony Davis]

OK, thanks for the code snippets. I see that the value is in seconds, and that it sets 60 seconds for the stale cookie calculation, from:
bool Cookie::IsStale() const {
int64_t currentTimeInUsec = PR_Now();

return currentTimeInUsec - LastAccessed() >
StaticPrefs::network_cookie_staleThreshold() * PR_USEC_PER_SEC;

So the reported issue might NOT be to do with stale cookies as such but the sheer number of cookies being built up over time, and the error handling for SAMESITE wrong settings is causing the ReCaptcha interference. I have attached a DOCX Word file, containing the Console Log taken at the time of one of these loops. Please review and comment when you have time. I have not tried this on other browsers, as I tend to use FF all the time, unless I hit issues, and this issue is DEFINITELY triggered with high cookie numbers. The total was 46, when the error hit, not necessarily all stale.

Comment 8

[Tony Davis]

Just to add, I assume that FF checks for errors within cookie parameters within the active site being browsed FIRST, THEN checks for the "Staleness" of each one? Please confirm, and If so, I guess it is down to the site code using bad SAMESITE parameters, and generating error handling timing issues during login.

Comment 9

[Tony Davis]

Just a quick note/observation: On the laptop where I have seen this happen a number of times, the cookie counts for the GOODGUYS site has now reached the number (46) that tends to be when the problem hits. However, the network.cookie.staleThreshold pref has been at 30 (seconds) since I raised this bug report, so possibly this might have had some positive effect, and the cookie prcessing might be presented with less work to be done (i.e. ignoring stale ones), and causing less interference with the ReCaptcha code?

Comment 10

[edgul]

Can you try to replicate:

1. On another browser and
2. On firefox with all extensions disabled

It seems like this may be a website issue.

Comment 11

[Tony Davis]

Ed Guloien [:edgul] I will try to replicate on another browser, BUT it tends to happen only when there are a lot of stale cookies for that site (usually >45 or so total. There are quite low numbers of that specific site's cookies present on the other browsers, as they are only there for use when FF has problems, so the problem does not replicate on my "backup" browsers.

When it happens again, I can certainly disable the ONE active extension (Browser Guard) on the laptop FF instance, before I remove the specific site cookies, BUT, I am sure that I have done that before, when it has happended in the past, and ONLY cookies removal fixes the problem, hence trying the change for the stale cookies algorythm time check modifier, from 60 seconds to 30 seconds.