Closed Bug 1492587 Opened 6 years ago Closed 5 years ago

Ensure the date picker does not leak user locale when "privacy.spoof_english" == 2

Categories

(Toolkit :: UI Widgets, defect, P2)

Product:
Toolkit
Component:
UI Widgets
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla68
Tracking Flags:
Tracking Status
firefox68 --- fixed

People

(Reporter: arthur, Assigned: xeonchen)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor 21787][fingerprinting][fp-triaged])

Attachments

(2 files)

Bug 1492587 - spoof date picker to en-US when pref is set;
47 bytes, text/x-phabricator-request
Details | Review
Screen Shot 2019-03-07 at 17.09.09.png
120.38 KB, image/png
Details 
In Tor Browser, we introduced a patch to spoof the locale as en-US in the Date picker when privacy.spoof_english == 2. Here's the ticket and our patch:

https://torproject.org/21787
https://torpat.ch/21787

We would like to propose uplifting this patch.
Oops, that should be https://trac.torproject.org/21787
Component: Internationalization → XUL Widgets
Product: Core → Toolkit
Priority: -- → P4
Assignee: nobody → xeonchen
Priority: P4 → P2
Whiteboard: [tor 21787] → [tor 21787][fingerprinting][fp-triaged]

spoof locale on datepicker to English when privacy.spoof_english == 2

Attachment #9042467 - Attachment is obsolete: true
Attachment #9042467 - Attachment is obsolete: false

I'd prefer to have the spoofing be part of LocaleService, than being sprinkled all around our front end code to override calls to LocaleService.

Hi Arthur,

I know Georg have already mentioned in [1], but seems the values of the date field and the picker are unlikely to leak the locale unless there's a bug in Firefox (and if it does, we should fire another bug).
So I'd like to propose this as WONTFIX, do you have any comment?

[1] https://trac.torproject.org/projects/tor/ticket/21787#comment:8

Flags: needinfo?(arthur)

Hi Gary, as we discussed in a meeting, there's a concern that the element width may vary under different locales. Would be useful to test to see if that is the case. Thanks!

Flags: needinfo?(arthur)

(In reply to Arthur Edelstein [:arthur] from comment #5)

Hi Gary, as we discussed in a meeting, there's a concern that the element width may vary under different locales. Would be useful to test to see if that is the case. Thanks!

Yeah, I'm going to close this as WONTFIX based on below statement. Please correct me and feel free to reopen this if I was wrong.

Experiment

I've tested on different locales, and according to [1] there are 4 major types of separators.
But seems Firefox only uses slash or dot.

  • Use '/' as separator: 108x22.5
    • ar
    • en-US
    • es-ES
    • fr
    • hi-IN
    • ja
    • zh-CN
    • zh-TW
  • Use '.' as separator: 108x22.5
    • de
    • fi

In [2] it's declared as |display: flex|, so I presume the width is not going to be changed.

[1] https://en.wikipedia.org/wiki/Date_format_by_country
[2] https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/toolkit/content/widgets/datetimebox.css#8

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Attachment #9042467 - Attachment is obsolete: true

(In reply to Gary Chen [:xeonchen] from comment #6)

(In reply to Arthur Edelstein [:arthur] from comment #5)

Hi Gary, as we discussed in a meeting, there's a concern that the element width may vary under different locales. Would be useful to test to see if that is the case. Thanks!

Yeah, I'm going to close this as WONTFIX based on below statement. Please
correct me and feel free to reopen this if I was wrong.

==============
= Experiment =

I've tested on different locales, and according to [1] there are 4 major
types of separators.
But seems Firefox only uses slash or dot.

  • Use '/' as separator: 108x22.5
    • ar
    • en-US
    • es-ES
    • fr
    • hi-IN
    • ja
    • zh-CN
    • zh-TW
  • Use '.' as separator: 108x22.5
    • de
    • fi

In [2] it's declared as |display: flex|, so I presume the width is not going
to be changed.

Thanks for making this experiment. If you look at our patch then you'll see that there is much more than the separator that is taken care of. For instance, we spoof the default labels that get used, say, for displaying "year" in the respective locale. If you compare id and sv-SE in this case you end up with

Tahun
år

which seem to take up quite some different space. Are you saying that's okay, too, due to |display: flex|? If so, great. Could we get a test then that makes sure this actually stays the same in the future for the things we care about here? Otherwise this feels a quite brittle to me.

Flags: needinfo?(xeonchen)

(In reply to Georg Koppen from comment #7)

Thanks for making this experiment. If you look at our patch then you'll see that there is much more than the separator that is taken care of.

Thanks for you comment. I'm not an expert on front-end, so please correct me if I'm wrong.

The patch for this issue in the Tor Browser consists two parts, one for the input field and the other part is for the date picker panel, and we don't think the latter will be necessary because web content should not able to retrieve the size of the picker, right?

For instance, we spoof the default labels that get used, say, for displaying "year" in the respective locale. If you compare id and sv-SE in this case you end up with

Tahun
år

I don't see those two words during the experiment of the given locales.
Would you tell me how to reproduce this?

which seem to take up quite some different space. Are you saying that's okay, too, due to |display: flex|? If so, great. Could we get a test then that makes sure this actually stays the same in the future for the things we care about here? Otherwise this feels a quite brittle to me.

Yes, I totally agree we should have tests to promise the size will keep the same, I can file a bug after the discussion.

Flags: needinfo?(xeonchen) → needinfo?(gk)

(In reply to Gary Chen [:xeonchen] from comment #8)

(In reply to Georg Koppen from comment #7)

Thanks for making this experiment. If you look at our patch then you'll see that there is much more than the separator that is taken care of.

Thanks for you comment. I'm not an expert on front-end, so please correct me
if I'm wrong.

The patch for this issue in the Tor Browser consists two parts, one for the
input field and the other part is for the date picker panel, and we don't
think the latter will be necessary because web content should not able to
retrieve the size of the picker, right?

For instance, we spoof the default labels that get used, say, for displaying "year" in the respective locale. If you compare id and sv-SE in this case you end up with

Tahun
år

I don't see those two words during the experiment of the given locales.
Would you tell me how to reproduce this?

I don't have a test for that but I can try coming up with one. I was just looking at the code and using the respective &date.year.label; entities and assuming that a carefully crafted website could detect the different widths of the localized entities e.g. by some elements overflowing or something. Arthur: did we test that case back then or did you patch the code just to be sure?

Flags: needinfo?(arthur)

Actually (to give you an idea about what we are concerned about), if you go to https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-nightly/ taking, say, en-US and de, you see that the second "Try it out" checkbox has a different width depending on whether it is populated with "mm/dd/yyyy" (en-US) or "TT.MM.JJJJ" (de) and I think that's measurable by the website.
Let me know if that's enough for you or if I should create an actual test.

Flags: needinfo?(gk)
Flags: needinfo?(arthur)

(In reply to Georg Koppen from comment #10)

Actually (to give you an idea about what we are concerned about), if you go to https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-nightly/ taking, say, en-US and de, you see that the second "Try it out" checkbox has a different width depending on whether it is populated with "mm/dd/yyyy" (en-US) or "TT.MM.JJJJ" (de) and I think that's measurable by the website.
Let me know if that's enough for you or if I should create an actual test.

Yes, they are:

161.067x33.5 (en-US)
157.4x33.5 (de)

Thanks for the example!

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

It seems to me there's no feasible way to obtain the dimension of the date picker, so I'm not going to patch this part but only the input field part.

Do you have any concern about it?

Flags: needinfo?(gk)

(In reply to Gary Chen [:xeonchen] from comment #12)

It seems to me there's no feasible way to obtain the dimension of the date picker, so I'm not going to patch this part but only the input field part.

How does it behave if you put it inside an iframe that resizes to fit its content? (No idea if this will work; just speculating...)

(In reply to Tom Ritter [:tjr] (On Leave) from comment #13)

(In reply to Gary Chen [:xeonchen] from comment #12)

It seems to me there's no feasible way to obtain the dimension of the date picker, so I'm not going to patch this part but only the input field part.

How does it behave if you put it inside an iframe that resizes to fit its content? (No idea if this will work; just speculating...)

Not sure if this is the case? Please see attached image.
The input field is in the iframe and the picker is not.

(In reply to Gary Chen [:xeonchen] from comment #14)

Created attachment 9049224 [details]
Screen Shot 2019-03-07 at 17.09.09.png

(In reply to Tom Ritter [:tjr] (On Leave) from comment #13)

(In reply to Gary Chen [:xeonchen] from comment #12)

It seems to me there's no feasible way to obtain the dimension of the date picker, so I'm not going to patch this part but only the input field part.

How does it behave if you put it inside an iframe that resizes to fit its content? (No idea if this will work; just speculating...)

Not sure if this is the case? Please see attached image.
The input field is in the iframe and the picker is not.

I thought that might be the case but thanks for double checking!

(In reply to Gary Chen [:xeonchen] from comment #12)

It seems to me there's no feasible way to obtain the dimension of the date
picker, so I'm not going to patch this part but only the input field part.

Do you have any concern about it?

What do you mean by "only the input field part"? Will the result solve the fingerprinting issue? That said I am not sure either why you don't just use the mechanism introduced in bug 1039069. Would we have users that hit this bug without being exposed to the prompt in bug 1039069 first? If so, this would be problematic. But if not (which I assume is the case) then one could argue that the behavior of the date picker could be bound to the result of the prompt answer (as Arthur did in the patch).

Flags: needinfo?(gk)
Attachment #9042467 - Attachment is obsolete: false

ni?me to update anti-fingerprinting wiki page after landing this.

Flags: needinfo?(xeonchen)

(In reply to Gary Chen [:xeonchen] from comment #17)

ni?me to update anti-fingerprinting wiki page after landing this.

done

Flags: needinfo?(xeonchen)
Pushed by xeonchen@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/5ce12b53d8ec
spoof date picker to en-US when pref is set; r=zbraniecki,baku

https://hg.mozilla.org/mozilla-central/rev/5ce12b53d8ec

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
status-firefox68: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
See Also: → 1880108
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: