Re: [tor-bugs] #14429 [Tor Browser]: Automated rounding of content window dimensions

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#14429: Automated rounding of content window dimensions
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  arthuredelstein
  arthuredelstein        |     Status:  needs_revision
         Type:  defect   |  Milestone:
     Priority:  normal   |    Version:
    Component:  Tor      |   Keywords:  tbb-fingerprinting-resolution, tbb-
  Browser                |  torbutton, TorBrowserTeam201505R,
   Resolution:           |  GeorgKoppen201505R
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:111 gk]:
 > Part 2
 >
 > Minor things and general thoughts
 >
 > -s/linux/Linux
 > -The comment in `sortBy()` is confusing as least *is* best in this case
 if I understand that right
 > -`if (!stop)` on line 443 is redundant as the while clause is only
 running if `!stop`
 > -Why is the loop in `updateDimensions()` running 8 times? Does this just
 happen to work?

 It's only supposed to run once, except in some special situations, such as
 when DPI != 100%. Possibly there is a bug where it is running in other
 situations.

 > -There is something wrong with the `Even more unfortunately` sentence on
 line 407ff.
 > -The comment for `canBeResized()` should mention "not minimized" for
 completeness sake as well
 > -the `};` on line 499 is wrongly indented.
 >
 > I am wondering about usability issues for people that need to zoom
 certain websites to be able to read them  better/at all. Just leaving the
 site to search something and coming back is destroying the previous zoom
 and they have to start over.

 That's a good point. Possibly the native fix you suggested can deal with
 this, or we could try to store a zoom level per site.

 > And what I mentioned in an earlier comment. Have you thought about
 possible timing side-channels given that the code is quite resource
 hungry. Could an attacker induce the resizing logic and get information
 out of it?

 Now that I've removed periodic updates, I don't think this code is
 consuming any resources, except when the user is actively resizing the
 window. But you have a specific attack in mind that I'm not thinking of?

 > Could we avoid roping the zoom in to fix corner cases (and it seems
 given the DPI on Windows issues) and think about fixes in native code
 instead? Does that make sense?

 I think it does make sense and it should probably be what I look at next.

 > And, finally: This is really nice work, Arthur, really appreciated! Just
 in case my comments and corner cases I find/found seem to be overly
 negative.

 Thanks, Georg! I didn't see it as negative -- I really appreciate your
 careful bug-finding and comments. If you hadn't found these problems now,
 the reaction from users would be much more painful! :P

 I'm going through each point carefully and working on fixes.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14429#comment:115>
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