1352720 - Endless loop while connecting to https://id.avast.com/ when OS clock is (a few minutes) ahead of server time

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P5)

Description

[Loic]

Issue reported on the French support board:
https://forums.mozfr.org/viewtopic.php?f=5&t=132520

STR:
1) Make your OS clock a few minutes ahead of the real time (supposed to be the server time, I guess)
2) Open https://id.avast.com/
3) Log in with these (guest) credentials:
Email: [e-mail]
Pwd: azerty123!

Result: endless loop while connecting to Avast's user account, loading never ends (infinite spinning circle).

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ca7974ddccc11ec992834b8563d381d16b56ee42&tochange=8cc4907776c85b5f57c1778bdd5b2a4ad8eb8055

amy — Bug 368964 - Cookie expires attribute should be absolute, not relative to server time. r=ehsan

Comment 1

[Loic]

Amy, could you check this regression issue, please. Is it expected? If yes, may Avast's team fix it on its server side?

Comment 2

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 3

[Amy Chung [:Amy]]

Hi Loic,
I can't reproduce, would I confirm the reproducing steps to you?
"Make your OS clock a few minutes ahead of the real time.", It means I change my OS clock to the time zone in French?

Thanks!

Comment 4

[Loic]

My Windows clock is synchronized with time.windows.com (UTC+2), and I just changed the clock to be 2 minutes ahead of the real time.

If it's not reproducible with your time zone, try to switch to UTC+2 + 2-3 minutes ahead.

Comment 5

[Amy Chung [:Amy]]

Hi Loic,
I found I can reproduce when I switched to UTC+2 + 2-3 minutes ahead, but the behavior is normal when I switched to UTC+2.
And expiry time is base on client time on nsCookieService::GetExpiry(), do you confirm the expiry time of cookie base on server time?

Comment 6

[squidly]

Hi,
I do not know if the attached screenshot can be useful, but the avast server cookie seems to expire 10 seconds after UTC + 2.
If we set 1 minute more in our local time -> endless loop while connecting to Avast's user account
http://pix.toile-libre.org/upload/original/1492238157.jpg

Comment 7

[Loic]

Yes, I think the issue is related to both cookies "mySessionId" and "myLocalIdSession" from the domain ".my.avast.com".
When you connect to my.avast.com with normal local time (UTC+2), these cookies are set with a expiration date UTC+2 + ~1 min ahead.

If you modify the OS clock to be UTC+2 + 30/60 sec ahead, it's still OK to connect. But if the clock is ahead 120 sec, connection fails and these cookies are not created.

So I'd say the server time is UTC+2, and expiration date set by the server for these 2 cookies is UTC+2 + 1 min. Any OS clock with time > (UTC+2 + 1 min) will fail to connect.

Comment 8

[squidly]

It remains to be seen why with an old version of firefox, there are no problems
I have tested with an old portable version and the expiration is not fixed, it is always more or less than 1 minute but on the local time of the computer nor on absolute value UTC+2, we can advance by 23 hours without it Blocks access.
Expiration time increases step by step independently of world time.
So , I don't know what thing Avast's team will have to fix on its server side ?
Can be what you name by regression issue ?

Comment 9

[Shian-Yow Wu [:swu]]

According to bug 368964 comment 14, the cookie expiration behaviors of Firefox and other browsers are as below:

Firefox(before 51): relative to server time
Chrome: relative to server time
Safari: absolute time

According to bug 368964 comment 15, using absolute time seems to be a correct behavior.

Does this issue happen in Safari browser?  If not, a possible reason could be:
Safari uses absolute time, but there is one thing different from Firefox(mentioned in bug 368964 comment 14) that "Safari would be saving the expiration of cookie as absolute time, but it didn't confirm the expiration of cookie earlier than client time that still saves this cookie to database.".
I am not sure saving already expired coookies to database is meaningful, but if that fixes the problem and doens't bring side-effects, maybe we can consider that.  What do you think, Amy?

Comment 10

[Amy Chung [:Amy]]

[Test]
1. Purpose: modify code to let the behavior of Firefox same as Safari.
   Try to comment the code about confirming the expiry time when setting cookie,
   let the cookie which already expired still can save to database.
2. Purpose: confirm the behavior of this issue on Safari.
   Test this bug on Safari.

[Result]
1. [Fail]
   i.  The cookie "mySessionId" and "myLocalIdSession" saved in database.
   ii. The situation of this bug still occurs.
2. [Fail]
   This bug also occurs on Safari.

Does the server side confirm which cookies expire?

Comment 11

[Loic]

Sorry, but I don't know how to do that and I'll not test more. I reported the bug, it's out my scope now.
As you're able to reproduce on your side, I consider you can debug without my help.

Comment 12

[Shian-Yow Wu [:swu]]

According to comment 10, the issue occurs when using Safari browser too.

Old behavior -- relative to server time
  Firefox(before 51)
  Chrome

New behavior -- absolute time
  Firefox(51 and beyond)
  Safari

This seems to be web compat issue.

Comment 13

[Eric Tsai (no more review request accepted)]

Per-discussion with :swu, current implementation on Gecko is correct (absolute time). So it would worth to contact avast to know if we can change server behavior or not.

Comment 14

[Gerry Chang [:gchang]]

Too late for 54, let's see if we can fix it in 55.

Comment 15

[Adam Stevenson [:adamopenweb]]

Pinging Lukas from Avast to let them know about this issue.

Comment 16

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 17

[Oana Arbuzov [:oanaarbuzov]]

I cold not reproduce the issue on my side. After modifying the time (my time UTC+3 + 2-3 minutes / UTC+2 + 2-3 minutes ) and signing in the site loads and I can browse it.
https://i.imgur.com/j03FAbR.png

Tested with:
Browser / Version: Firefox Nightly 104.0a1 (2022-06-29)
Operating System: Ubuntu 20.04.2

squidly can you still reproduce it?

Comment 18

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

Redirect needinfos that are pending on inactive users to the triage owner.
:denschub, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 19

[Dennis Schubert [:denschub]]

Closing as WORKSFORME based on comment 17.