[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13019 [Tor Browser]: New locale fingerprinting capabilities in FF31ESR

#13019: New locale fingerprinting capabilities in FF31ESR
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  tbb-team
  mikeperry              |     Status:  needs_revision
         Type:  defect   |  Milestone:
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  ff31-esr, tbb-fingerprinting,
  Browser                |  MikePerry201409R, TorBrowserTeam201410
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:5 mikeperry]:
 > There are a couple issues with this patch. You shouldn't need to store
 the current locale just to have something to do in
 DefaultJSLocaleSetter::Run() when the pref is empty. If the pref is empty,
 just do nothing. This eliminates the need to export JS_GetDefaultLocale()
 as well.

 My thinking is that it is nice to be able to set this pref at runtime. So
 if the user sets the pref to empty at some point, then the original locale
 will be restored. That's why we need to store the original locale on
 startup. Otherwise we would have to require restarting the browser
 whenever the pref is changed.

 > But beyond this, there's actually two bugs in the storage of this locale
 information. In the case of DefaultJSLocaleSetter::jsLocale, you leak it
 on XPCOM shutdown. In the case of DefaultJSLocaleSetting::systemLocale,
 you are keeping a pointer to a static buffer, so that subsequent calls to
 setlocale may cause this memory to get replaced with something else. It
 probably will always contain the actual current locale, but this seems a
 bit sloppy to rely on.

 Thanks for catching these two bad mistakes. I believe I've fixed them in
 the new patch version, added above. I also changed the implementation to
 use Preferences::RegisterCallback/UnRegisterCallback, which is more
 concise than the nsIObserver approach.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13019#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs