1582356 - ill-formatted date in error message for user

Status: RESOLVED DUPLICATE of bug 1546625

(Firefox :: Security, defect, P5)

Description

[Evgeny A. Permyakov]

Attachment: Screenshot_20190919_083602.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

load a page with certificate causing firefox to believe that erroneous date might be set on the user's machine. Ubuntu/KDE 18.04

Actual results:

On loading page with expired certificate FF observed that ssl certificate is invalid and shown an error message with date. The date, however, was generated in format "mm.dd.yyyy" despite the fact that the system tray clock shows it in "dd/mm/yy" format
LC_* is set to ru_RU.UTF-8.
LANG=en_US.UTF-8
LANGUAGE=en_US
(the disagreement is intentional)

see the screenshot. Compare date as in tray (upper right corner) and the message generated by FF. the disagreement in formatting is confusing.

Expected results:

the error message should have contained data in dd/mm/yy format/order or even using system date formatting like "Чт сен 19 08:49:32 MSK 2019". Anyway, it should not conflict with system date formatting.

Comment 1

[Andrei Purice]

Hi there Evgeny,

If I may, I would suggest re-testing the issue while in Safe Mode. You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .

Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .

If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 2

[Evgeny A. Permyakov]

Attachment: Screenshot_20190925_221926.png

I invoked a fresh instance of firefox with clean profile folder with command

firefox -profile c:\path\to\temporary-folder -no-remote -new-instance

and visited https://expired.badssl.com/ (ssl certificate for this domain is delibirately kept expired)

The error message still has date ill-formatted (see fresh screenshot attached)

Comment 3

[Andrei Purice]

Hey Evgeny,

I have the same date format as you do and the issue doesn't occur for me. When i access the 2nd site (https://expired.badssl.com/) i get the warning with the same date as set.

Where do you access the site from? Home/office? because there might be restrictions for certain sites imposed by the internet service providers.
Does the warning occur if you access the site from another location?

Comment 4

[Evgeny A. Permyakov]

Where do you access the site from? Home/office?
Both.
The first site dealt with their cerificate problem, so we have to deal with badssl, on which I see the same behaviour . The error itself isn't a problem, the format of the date is. With badssl I have the same format of the date on two Ubuntu machines with different DEs. It's confused the hell out of me.

If we have discrepancy in error format, but not the site, the problem obviously is caused by mistreatment of difference of configuration. Maybe, FF mistreats LC_* family of variables or maybe FF L10N functions inconsistently. I lack resources and qualification to test the problem further, but I'm concerned it might go deeper than this rather minor hiccup.

If you wish, give me the paths of the files you want me to post and diagnostic commands to run. I use Kubuntu 18.04 at home and Ubuntu 16.04 at office.

Comment 5

[Evgeny A. Permyakov]

(In reply to Evgeny A. Permyakov from comment #4)

Where do you access the site from? Home/office?

Damn, wrong formatting. Quote meant to end before "Both"

Comment 6

[Andrei Purice]

I will set a component so that the dev team can get involved and have a look at it.
If you feel the component is not right please change it accordingly.

Comment 7

[Johann Hofmann [:johannh]]

Hey Zibi, we're using Intl.DateTimeFormat to format the date here https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/browser/base/content/aboutNetError.js#7

So this seems more like an issue with the i18n APIs to me. What do you think? (Is this an issue at all?)

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

In all chrome-context you should use mozIntl (which is a wrapper over Intl). It's accessible via Services.intl.* and documented https://firefox-source-docs.mozilla.org/intl/dataintl.html#services-intl

Comment 9

[Johann Hofmann [:johannh]]

This is not a chrome context.

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

In that case we have to follow the locale we expose to the Web, which in this case is en_US.

The docs I linked have more detailed explanation of the tradeoff.

Comment 11

[Johann Hofmann [:johannh]]

Ah, I see, thanks for adding that documentation. So, if we wanted to get the perfect date format, we would have to send it down from the parent. That's good to know but probably not a priority for us right now.

Comment 12

[Evgeny A. Permyakov]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #10)

In that case we have to follow the locale we expose to the Web, which in this case is en_US.

Just to clarify: at this context, FF currently grabs primary locale declaration (in this case en_US) and ignores LC_DATE (in this case ru_RU). Also, if I understand it right, there is a proper date formatter somewhere else, but making it work in this context isn't trivial. Did I understand this right?

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

It's a bit more complicated.

We currently have only one "default" locale in JS context, so we can't separate out like POSIX does with LC_ALL vs LC_DATE. We expose your app locale - if you're using Firefox en-US (in other words, your UI is in en-US) that's the locale which we'll expose to JS context.

Comment 14

[Zibi Braniecki [:zbraniecki][:gandalf]]

Here's a bug about differentiating the locales in JS context - bug 1482269.

Comment 17

[Ángel]

I was welcomed the other day by an error claiming that the certificate expired 02/11/2020. Completely confusing since that's still three weeks away. Unless using American dates.

I think Mozilla should use textual months on all these places.

Answering to zbraniecki on bug 1601841 comment 11 when Farquhar proposed the same thing, I don't mind if it's displayed as 8 Aralık 2019 or December 8, 2019. The goal is that it is unambiguous. If I use a mixture of en-US and tr, I probably understand both the words December and Aralık. Even if I don't, it'd be obvious I am missing something and relatively simple look up what the weird word means. As opposed to thinking you understand what is going on (like believing the date when it expired was yesterday) and taking a security decision (whether to bypass the error or not) based on that. while it actually tried to convey something completely different.

Note that I am just advocating for non-ambiguity, the code may still be wrong from an UI point of view (showing the month at the wrong position, or a mixture of languages) but it should be clear what it is throwing to the user. It would be specially useful for the use cases of en-US builds by people outside the US (as mentioned by Gijs on bug 1601841 comment 8) as well as those that enabled some extra fingerprinting resistant knobs if they interacted with it.

Comment 18

[Eemeli Aro [:eemeli]]

This will get fixed in bug 1734217 by this change, which does effectively what's suggested in comment 17:

https://phabricator.services.mozilla.com/D155951#inline-859545