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

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Mar 8 20:31:03 UTC 2013


#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 gk):

 Here comes the second bunch of comments to section 3 - the end to the
 document in chronological order:

 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"?)

 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.

 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.

 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...

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

 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.

 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?

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

 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
 :)

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


More information about the tor-bugs mailing list