[tor-bugs] #5273 [Firefox Patch Issues]: Update TBB design doc for 2.3.x

[Tor Bug Tracker & Wiki]

#5273: Update TBB design doc for 2.3.x
----------------------------------+-----------------------------------------
 Reporter:  mikeperry             |          Owner:  mikeperry                    
     Type:  defect                |         Status:  needs_review                 
 Priority:  major                 |      Milestone:  TorBrowserBundle 2.3.x-stable
Component:  Firefox Patch Issues  |        Version:                               
 Keywords:  MikePerry201302d      |         Parent:                               
   Points:                        |   Actualpoints:  16                           
----------------------------------+-----------------------------------------

Comment(by mikeperry):

 Replying to [comment:42 gk]:
 > Here comes the second bunch of comments to section 3 - the end to the
 document in chronological order:

 Ok, I think I've fixed most of these. You can double check when the
 website gets updated. The new design doc will claim to be current as of
 Torbutton 1.5.1 (rather than 1.5.0).

 > 3.1.4) I think you can delete that point as that is better viewed as one
 of the myriads of means to reach 3.1.6 and not a separate goal (that is
 quite good reflected by "zero in" which you used in both sections (btw. is
 it "zero in" or "zero-in"?)

 Yep. Deleted. Also added some phrasing to 3.1.6 (now 3.1.5) to capture
 this idea too.

 > 3.2.4) I am wondering if that adversary described there is still the one
 you assume when you are talking about a passive forensic local adversary.
 If I as an adversary have intermittent or constant physical access, well,
 then I have more options than just passively monitoring something... Maybe
 a comment or a hint like you did with 3.3.3 would help here.

 Well, 3.2.4 is just about positioning. See the corresponding attack vector
 in 3.3.4, which I updated to mention both complete code-exec compromise
 and passive forensics.

 > 4.5.2) It was a bit confusing to me that the cache domain attribute is
 using the FQDN and not the url bar origin (i.e. the second-level DNS name)
 especially as the Tor Browser is following that url bar paradigm in almost
 all the other cases (and is only mentioning that one MAY use the FQDN as
 url bar origin). A sentence or two explaining this "discrepancy" might be
 good here.

 I added a phrase. I pretty much chose FQDN because it was the simplest
 option.

 > 4.6.4) While reading that remote fonts are excluded from the defense now
 I remembered:
 >
 > {{{
 > When Gecko displays a page that uses web fonts, it initially displays
 text using the best CSS fallback font available on the user's computer
 while it waits for the web font to finish downloading.  As each web font
 finishes downloading, Gecko updates the text that uses that font.  This
 allows the user to read the text on the page more quickly.
 > }}}
 >
 > on https://developer.mozilla.org/en-US/docs/CSS/@font-face. Have you
 tested that a remote server cannot fool you here? The question is: Does
 the font defense get triggered even if the local fonts are just
 placeholders for remote fonts? I am not sure whether there are different
 code paths for genuinely loading a local font and having it just as a
 placeholder and whether your defense works in both cases. Just a
 thought...

 I have actually observed this behavior happen visually, but I have not
 tested it with code. We do update the actual font rule itself (as the
 nsStyleRule member of nsRuleNode) to /only/ list the font-face font before
 font rendering, so I'd be surprised if you could still probe specific
 fonts this way. My guess is that what happens is that you get /the/ system
 generic font, the same one you get with browser.display.use_document_fonts
 set to false. But it would be a good test to do, especially if we also
 verify that inherited font rules can't somehow alter this fallback
 behavior. Both are probably something content window JS can inspect with
 getComputedStyle(), if it manages to win the race to inspect the element
 before the font is downloaded.

 > 4.7) The GeoIP wiki token URL is probably a GeoIP wifi token URL, right?
 (at least "geo.wifi.access_token" makes that plausible)

 Yeah. Typo.

 > 4.8.7) It seems to me that closing the Tor Browser is not early enough
 as there are numerous add-ons that start network activity way before the
 browser.js code is running. But I am not sure if that justifies an own
 Design Goal section here which states that one tries to patch the Tor
 Browser in a way that it is guaranteed to only start network activity if
 Tor is up, running and used.

 I am confused what you mean here. We don't actually kill the Firefox
 process, and we consider addon network activity out of scope... I tried to
 clarify a couple things in this section, though.

 > A) While reading "[...] based on the assumption that link-click
 navigation indicates user consent to tracking [...]" I was suddenly
 thinking about element.dispatchEvent() and friends. I am wondering whether
 there is really the possibility to keep a user clicking on a link
 separated from JavaScript "clicking" on a link and whether therefore the
 link-click criterion is really useful here. Have you looked into that?

 No. I would consider this as part of #3600, as an automated cross-origin
 redirect vector. We should probably work on enumerating those, as that
 will probably help us decide what to do there. I updated the ticket with a
 (probably partial) list of vectors.

 > A.1.1) Either "Referer or "referer" should be used but not both (I tend
 to the former).

 Fixed.

 > The idea with making the Referer explicit (and how to do it) is a really
 good one! And for the record: it was not mine as your comment 35 indicates
 :)

 Heh, yeah, but you kept hounding me about it long enough to find some kind
 of solution. ;)

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