The timeout time for a the verification code is entirely determined by the Firefox Accounts system and can't be adjusted by the user.

If you want to leave feedback for Firefox developers, you can go to the Firefox Help menu and select Submit Feedback... or use this link. Your feedback gets collected by a team of people who read it and gather data about the most common issues.

Thank you for the feedback, and I have reposted my above question on the link provided in the hope that some kindly soul there will forward it to whoever is responsible for setting that 5 minute timeout. I was really hoping someone on this support forum would be able to do that for me, since the task is too difficult for me to undertake and follow through myself due to my personal senile cognitive disabilities

I find this issue to be one of accessibility too. There are people who may not be able to reach out for the code (that is delivered somewhat randomly late) in such short notice. I feel that Firefox is not considering handicapped people equally here.

I fail to see how the six digit code is better secured with 5 minute than 10 minute window. If it is targeted, the email is captured in milliseconds instead of minutes.

Please consider a more relaxed time window for receiving and using a security code.

Also please consider using de-facto 2FA implementations too.

Thank you for your supportive answer SirkkalaP. For me, 10 minutes would be marginally better than 5 minutes because Firefox's emails don't come directly to my client; they are collected at intervals and filtered by Gmail, so within that 5 minute timeout, I have to log in to Gmail, go to Settings, choose Accounts & Import, find Check email from other accounts, select my relevant POP3 account, and then press Check mail now. That then downloads FF's code email and I have to navigate back to Gmail's inbox, select the new message, copy the code, and paste it back in FF.

All this can take an old codger like me quite some time, and with any slip up in the process, by the time I've copied the code back in FF, it can easily have expired.

I don't understand why the life of the code needs to be quite so short. What would the consequence of setting it to say 30 minutes instead?

To clarify, I recently suggested increasing the time window. However, according the developers that maintain the system, the timeout is actually 20 minutes.

The email does say 5, but that's purely for show and the code will still work for up to 20 minutes. The email says a different time to ensure that the user enters the code before it expires, accounting for any potential delay in receiving the code.

I find it confusing to offer false information to user regarding 2FA use. It does make me wonder what else I should not trust, does it not?

There seems to be some people who think they know better than others. That is not true, they may be better informed, but not superior. I find this attitude disturbing to me.

Like I said, the time difference is there simply to account for any delay in getting the message. Certain email providers may have stricter filters that take longer to run or some may just be slow to deliver messages.

If the email was only valid for 5 minutes and it takes the user 2 minutes to get the message, the expires in 3 minutes rather than the 5 in the email. But if the code is good for 20 minutes, it's virtually guaranteed that the code will be valid for the 5 minutes listed in the email, regardless of the delay.

I'm wondering if the timeout has actually been increased in recent months. I originally started this thread some time ago when I was often finding the code had expired by the time I'd gone through all the collection procedure I describe in my earlier post. More recently that hasn't been happening; not sure whether it's due to me becoming more skilled and quicker managing my collection procedure, or someone took notice of my original complaint and lengthened the timeout.

For whatever reason, it's definitely become more manageable for me personally now.

Glad to hear that it's working better for you.

From what I've been told, the code has always been valid for 20 minutes. They just lowered the text on the email to say 5 minutes instead. Not sure what the recently improvement for you would be, but glad it's improved.

I would prefer to see the time when the code expires instead of a approximated "minutes left".

There are other very clear and precise fields in the message and it never occurred to me that the five minutes is counted from the time when I received the message.

I always expected the timeout to count from the time when the message was sent, not when it was received.

Sorry for being such a thick head, I mostly fail in communication.

SirkkalaP, It would be rather confusing and difficult to specify "the time" when a code expires because of all the time zone differences around the world.

Emails normally hardly take any time between sending and "receiving"; usually well under 1 second, but being "received" and being visible and read happen at totally different times, depending on how quickly the recipient finds and opens their messages.

I suppose after you've entered a received code and sent it back to Firefox for verifying, they compare the timestamp they recorded when they originally sent the code out, with the time now, and decide on that basis whether it's still valid or not. That way, all the checking is done at their end.

It definitely used to happen quite often in my case, that they decided the code I'd sent them was invalid or out of date. Yes, I was admittedly a bit slow going through my lengthy collection procedure, but I can't see how that could have exceeded the 20 minutes Wesley says it's always been.

I fail to see how specifying a time would be confusing or difficult as the same email already contains a localized time of the moment the user requested the code.

Here is a copy of one such email in text:

Kirjaudutko sinä sisään?

Firefox alustalla Mac OS X 10.14 Tampere, 11, Finland (arvio) IP-osoite: XXX.XXX.XXX.XXX 14.16.17 (EET) keskiviikko, 5. helmi 2020

Jos kyllä, tässä on vahvistuskoodi:

XXXXXX

Se vanhenee viidessä minuutissa.

Tämä on automaattisesti lähetetty viesti. Jos et ollut tämän tapahtuman takana, vaihda salasanasi. Lisätietoja saat Mozilla-tuesta.

Mozilla. 331 E Evelyn Ave, Mountain View, CA 94041 Mozillan tietosuojakäytäntö Firefox Cloud -käyttöehdot

The assumption that the email takes merely some seconds to send seems to contradict with my email headers.

The headers from the above message, requested 14.16.17 (EET), have these timestamps:

Received: by jutikka.iki.fi (Postfix) id E91BD3A14EA; Wed, 5 Feb 2020 14:22:46 +0200 (EET) Delivered-To: sirpete@iki.fi Received: from a59-48.smtp-out.us-west-2.amazonses.com (a59-48.smtp-out.us-west-2.amazonses.com [54.240.59.48])

Now already when the email was out of Amazon the delay is 6 minutes.

SirkkalaP said

I fail to see how specifying a time would be confusing or difficult as the same email already contains a localized time of the moment the user requested the code.

Yes, an email header may have the localized timestamp (depending on your email provider). However, it's not possible to insert that into the message itself, since the message is essentially just text. Your email provider doesn't scan incoming messages for dates or times so that it can localize them for you.

If you think of an email as a regular letter you would send through regular mail, that's a pretty accurate picture of what an email is like. The person types of the letter and puts it in the mail. The receiving post office stamps it with the time received, which is local for that location.

It's also important to remember that when you send a letter through the regular mail, it takes time for the post office workers to actually deliver it to the user. Email is often the same.

The receiving time in the email header may be different then the time that the email actually appears in the user's inbox. It would depend on what spam and security filters the email needs to go through. That's most noticeable on custom email domains, which may have stronger email filters and/or slower email exchange systems.

I appreciate your help, thank you for taking your time to address this.

I am sorry, but the text with timestamp was from the message body (albeit encoded in the multipart, but still), not from the headers. I literally copypasted the text I received from Firefox from the email window.

I most certainly do not have 6 minute delays on my normal email traffic. I can only assume that the Firefox account service or SMTP provider somehow delays the email in my case.

I would rather compare email to a postcard, not a letter, as the contents are not protected by an envelope from prying eyes.

My email storage provider is Gmail, however the email runs through two spam filters and a forwarding service that allows me to use my .fi ending address. Again these work in seconds most other time. However this means that the SMTP needs to connect over ocean, if the AWS region is us-west-2 as the headers imply.

The headers of the email indicated that first contact was 14:22:46 (EET) and the Date header states 12:16:17 (UTC).

Maybe we should bring this to a closure on my behalf.

It seems to me that there is more than 5 minutes delay in delivering Firefox Code emails. I do not see such delay normally in most other services that send tokens to me.

Firefox seems to allow more than 5 minutes to use the code, counting from the creation of the code (mentioned in the email body as a timestamp).

Firefox email body states that the code is valid for five minutes.

The headers of email indicate that first SMTP-server outside AWS is contacted about 6 minutes since the Date header of the email.

This is all fine for me for now, but I fear the day I fail to use my Firefox any more.

Thank you for taking the time to clarify this and thanks for working on such a great and long standing open source project. You have my respect and gratitude.