UI locale is detectable by button width
Categories
(Firefox :: Untriaged, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: acat, Assigned: acat)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tor 24056])
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Steps to reproduce:
Browser locale is detectable by measuring the width of a button <input type="submit">
without a value property, which gets a default text that depends on the browser language. We have a patch for this in Tor Browser which would like to upstream.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
I realized that resource://gre/chrome/en-US/locale/en-US/global/layout/HtmlForm.properties
which the patch is using for spoofing is not available in localized desktop builds. I just tested with langpacks, where it is available.
Would it be feasible to make en-US/locale/en-US/global/layout/HtmlForm.properties
available in localized desktop builds? (AFAIK in Android builds this is not an issue, since they are multilocale).
Comment 3•6 years ago
|
||
Would it be feasible to make en-US/locale/en-US/global/layout/HtmlForm.properties available in localized desktop builds?
My initial guess is that it would take a lot of work to refactor how we build Firefox to include en-US resources for .properties in every build, but I'm going to redirect the question to Axel, who's better positioned to make such evaluations.
Comment 4•6 years ago
|
||
I'm not sure banning all of HtmlForm.properties is the right solution. There's stuff like file picker dialogs, which shouldn't web-sniffable at all, and thus, IMHO, should stay localized.
We'll want to have something for Fluent eventually, too.
One way might be to change the call sites to say eMAYBE_FORMS or so, and then to set that to the localized forms one when obfuscation isn't on.
I think a better solution would be to find a way to size the localized UI controls so that they don't show that they're localized.
From a packaging POV, you'd need to double-package the HtmlForms.properties, once for l10n, and one in content, and then refer to the one in content for hard-coded strings. That'll require some whitelisting of that file to be double-packaged, too.
Comment 5•6 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:acat, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 6•6 years ago
|
||
Updated patch double-packaging HtmlForms.properties
and trying to only spoof strings that are content accessible.
Assignee | ||
Comment 7•6 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a963c79057b00206af0b948fc1daa61a8ae35e6
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1649a1d82212
Allow spoofing strings in HTML forms r=baku,Pike
Comment 9•6 years ago
|
||
bugherder |
Comment 10•6 years ago
|
||
Updated•6 years ago
|
Description
•