Closed Bug 1561322 Opened 5 months ago Closed 4 months ago

UI locale is detectable by button width

Categories

(Firefox :: Untriaged, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 70
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.

Whiteboard: tor 24056
Whiteboard: tor 24056 → [tor 24056]

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.

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).

Flags: needinfo?(gandalf)

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.

Flags: needinfo?(gandalf) → needinfo?(l10n)

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.

Flags: needinfo?(l10n)

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.

Flags: needinfo?(acat)

Updated patch double-packaging HtmlForms.properties and trying to only spoof strings that are content accessible.

Flags: needinfo?(acat)

Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1649a1d82212
Allow spoofing strings in HTML forms r=baku,Pike

Keywords: checkin-needed
Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/70615649c46f
Port bug 1561322 - Include @RESPATH@/res/locale/layout/HtmlForm.properties in package-manifest.in. rs=bustage-fix
You need to log in before you can comment on or make changes to this bug.