[tor-bugs] #9127 [BridgeDB]: Users can't ask for ipv6 bridges with the new bridgedb interface

[Tor Bug Tracker & Wiki]

#9127: Users can't ask for ipv6 bridges with the new bridgedb interface
----------------------+-----------------------------------------------------
 Reporter:  asn       |          Owner:     
     Type:  task      |         Status:  new
 Priority:  normal    |      Milestone:     
Component:  BridgeDB  |        Version:     
 Keywords:            |         Parent:     
   Points:            |   Actualpoints:     
----------------------+-----------------------------------------------------

Comment(by asn):

 Replying to [comment:3 sysrqb]:
 > Replying to [comment:2 asn]:
 > > also cc'ing sysrqb in case he cares
 >
 > Thanks :)
 >
 > hrm. Do "typical" users know the difference between ipv4 and ipv6? Or,
 more specifically, do we expect a normal user to know that she needs ipv6
 addresses? At this point, until told otherwise, I assume a typical user
 will go to bridges.tpo, retrieve bridges, paste them into Vidalia, and
 hope for the best. If someone knows they need bridges that have ipv6
 addresses, then I *think* they should be able to navigate a slightly more
 complex interface (and I do mean slightly more complex).
 >
 > My initial thought of an updated design is:
 >
 > Typical User:
 > - Loads bridges.torproject.org
 > - Reads Steps 1 and 2. Clicks on "Get Bridges"
 > - This then loads a second page that has a link at the top that says
 "Just give me bridges!" and a section that says "Advanced Options". User
 clicks "Just give me bridges".
 > - A page with a captcha then loads, user enters captcha, user gets
 bridges
 >
 > Advanced User:
 > - Loads bridges.torproject.org
 > - Reads Steps 1 and 2. Clicks on "Get Bridges"
 > - This then loads a second page that says "Just give me bridges!" and a
 section entitled "Advanced Options". User reads further on the page and
 sees a checkbox for ipv6 and a dropdown menu for obfs2 and obfs3.
 > - User selects the options she needs and clicks a "Get Bridges" button
 > - A page with a captcha then loads, user enters captcha, user gets
 bridges
 >
 >
 > This description probably doesn't do my imaginary page justice, but
 hopefully it gives you some idea of the flow I'm picturing. Basically, add
 a new page in between index.html and bridges.html, this middle page
 contains a large "Just give me bridges!" link which goes straight to
 bridges.html. This intermediate page also contains a section which
 includes "advanced options" which, I expect, most users will ignore.
 >
 > Thoughts? Does this stray too far from KISS?

 I like the idea.

 I generally like the idea of making BridgeDB a bit more like a database
 (so that you can do stuff like "Give me a bridge that supports obfs3 and
 has IPv6") using checkboxes and dropdown menus. I'm afraid of two things
 here:

 a) This design should not leak too many bridges. A user should not be able
 to get too many bridge addresses just by clicking checkboxes and dropdown
 menus. For example, with the naive implementation of this design, a user
 would be able to get N normal bridges by default, and then he would be
 able to get some more IPv6 bridges when he clicks the IPv6 checkbox, and
 then some more when he plays with the drop down menu. How can we minimize
 the amount of bridges leaked with this system?

 b) What is the implementation pain for this scheme? And how many users
 will it benefit? Designing the system to be leak-proof, implementing it
 and writing the web code might take some time. Is it worth designing such
 a system just for the advanced users? Also, would the ring-based design of
 BridgeDB work well with a database-like design, or would it need a
 redesign of the ring code?

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