[tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from O/S
--------------------------------------+-----------------------------------
 Reporter:  zinc                      |          Owner:  pospeselr
     Type:  defect                    |         Status:  needs_information
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  TorBrowserTeam201708      |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+-----------------------------------

Comment (by mcs):

 Replying to [comment:22 gk]:
 > However, after thinking more about this patch I have a bigger concern.
 What is it defending against? I mean, what prevents a rogue extension from
 flipping our pref and just read the values we tried to hide? (I know I
 suggested the pref approach first and should probably have thought more
 about it and not just have recommended the "standard thing" when Firefox
 patches are concerned).
 >
 > One could argue that's not possible with the new WebExtensions-based
 add-ons (which is correct) but then I bet those extensions are not allowed
 to extract the info we want to hide in the first place either (but I could
 be wrong about that). So, should we just say this will be fixed when we
 switch to Firefox 59? And, if we really want to defend against that in the
 ESR 52 cycle we would just rip out the offending code (not bothering about
 upstreaming the patch)?

 So maybe just add #ifdefs for ESR52 to remove the code? I'd still feel
 better if the info was never read (and thus present in memory) in ESR 59
 and later, but in theory the info should not be accessible to
 Webextensions.

 > mcs: What about your refactoring concerns?

 That concern is fairly minor; we could just wait and see what Mozilla says
 if or when we try to upstream the patch. And we can change our approach
 later if upstreaming does not happen (and therefore we would need to
 maintain a patch forever).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13398#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online