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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

 Replying to [comment:4 asn]:
 > 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?

 Well currently we don't leak any additional bridges if you request bridges
 multiple times but with different GET values, so any addition to the UI
 should not affect bridge selection.

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

 It's hard to tell. This isn't a complex addition, so we should be able to
 do this without much trouble. I think the most important reason for doing
 this (or something like it) is that we don't document the GET request
 values anywhere. We could simply document them instead, but if we don't
 have to force a user to modify the url then I think it will provide a
 better UX, which I think is what we want.

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