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

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Mar 4 16:37:47 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):

 Okay here come some comments to the first 2 sections in chronological
 order:

 1) 2.1.2 State Separation: I think there is some material criterion for
 "other browsing modes" missing. I mean the doc should give kind of a
 blueprint of a Private Browsing Mode, right? Now, if one tries to design
 such a mode for say, Chrome, with it, when is it allowed to share state to
 the content window? "If you are not in Private Browsing Mode" does not
 help here. I think a minimum criterion could be: "You are in an other mode
 if you don't have Tor enabled" But maybe there is more to it...

 2) 2.2.3 Long-Term Unlinkability: Having a requirement with a "SHOULD"
 does not seem to fit IMO. So, my first thought was to omit 2.2.3 fully,
 re-label 2.2.1 to "Identifier Unlinkability" and put the content of the
 old 2.2.3 there. But after a while I came to the conclusion that it maybe
 should be an own point but the "SHOULD" should be upgraded to a "MUST". I
 think that long-term unlinkability requirement is important as there is
 some dangerous tracking falling through the cracks if one "only" provides
 isolation to the URL bar domain. I have here first party tracking (via
 cookies or whatever) in mind done e.g. by some powerful search engine
 provider which gets used by 80% of the people and which is the only one
 they use. Against correlating all the search entries of one person via
 cookies or an other identifier only a fresh identity function seems to
 help in your current design. Therefore, it seems like a MUST to me.

 3) 2.3 Philosophy: That is kind of an informational section and all
 occurrences "MUST" and "SHOULD" seem therefore wrong to me. They belong
 into the technical sections or should be lower-case. Thus, I would e.g.
 omit the second paragraph of 2.3.3 as its first sentence is already in
 4.6.1 and the second one would fit there better, too.
 I am not sure where to put the important points about disabling the
 (system-wide) add-ons/plugins but they don't belong into 2.3.4. Thinking
 about local history storage there seems not appropriate either as that is
 a specific technical issue, too, while the section is more about broader,
 underlying and non-technical questions. I'd just delete it.

 Last sentence of 2.3.1 "tor-state". Not sure if that is a typo but I was
 wondering why it is "tor" and not "Tor".

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


More information about the tor-bugs mailing list