[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #4562 [Pluggable transport]: Write a pluggable transport deployment roadmap

#4562: Write a pluggable transport deployment roadmap
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  asn                      
     Type:  project              |         Status:  needs_revision           
 Priority:  normal               |      Milestone:  Sponsor G: March 31, 2012
Component:  Pluggable transport  |        Version:                           
 Keywords:                       |         Parent:                           
   Points:                       |   Actualpoints:                           
---------------------------------+------------------------------------------
Changes (by karsten):

 * cc: erinn, chiiph, aagbsn, ioerror (added)


Comment:

 Some comments:

  - The document doesn't have an author name nor contact information.
 Please consider putting in your name and email address.
  - Should Section 2 have its own subsection for saying what changes are
 required to Vidalia, maybe as new first subsection?  If these changes are
 already made, great, but I think they should be stated in this roadmap.
 Speaking of Vidalia, are there plans to configure obfsproxy on the server
 side?
  - In Section 2.1, how will BridgeDB distribute obfuscated bridge
 addresses?  Will users specifically ask for them instead of non-obfuscated
 bridge addresses, or will BridgeDB include an obfuscated bridge address or
 two in every response?  If there are different transports, will BridgeDB
 tell you one address per transport, or will the user have to ask for a
 specific transport?  I'm sure there are even smarter questions about
 possible BridgeDB designs, but I think they should be discussed in Section
 2.1 or on Trac and referenced here.
  - Maybe add a remark that statistics mentioned in Section 2.2 won't be
 deployed on a 0.2.3.x timeframe.
  - Sections 2.2 and 2.4 talk about a future that is farther away than 2.1
 and 2.3.  Would it make sense to have Section 2 talk about the future in 3
 --6 months and a new Section 3 talk about the future after that?  If not,
 feel free to ignore this suggestion.
  - In Section 3 you talk about updating obfsproxy on the server side.  Are
 there any plans to have an Obfsproxy Bridge Bundle of some sort?  Or will
 the Tor Bridge Bundle contain obfsproxy by default?
  - In the short-term future as sketched in Section 4, you say that users
 will download the Obfsproxy Browser Bundle and put in addresses obtained
 from BridgeDB.  Will the bundle still contain any hard-coded addresses by
 then?
  - Instead of hacking the bibliography with custom `\bibitem`, please
 consider using footnotes for URLs.

 We should also get feedback from the people who're actually affected by
 the planned changes.  erinn, chiiph, aagbsn, and ioerror come to mind.
 Adding them to Cc.  What do they think?

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