Opened 6 years ago

Closed 5 years ago

#9127 closed task (fixed)

Users can't ask for ipv6 bridges with the new bridgedb interface

Reported by: asn Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-https, bridgedb-0.1.3
Cc: admin@…, sysrqb, isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The new BridgeDB interface doesn't allow users to ask for IPv6 bridges. Apparently, the ipv6=true GET parameter trick still works, but we shouldn't rely on users guessing it.

We should think how the "Give me IPv6 bridges" button should be integrated in the current interface.

For example, if we wanted to keep the current KISS interface, maybe we shouldn't add a new button, and instead we should just return IPv6 bridges like they are normal bridges (and expect the latest PTTBB and the user's OS to support IPv6).

Child Tickets

Attachments (2)

bridgedb_details.png (78.3 KB) - added by sysrqb 6 years ago.
A mockup for clarity
9127-BridgeDB-ipv6-mockup-2014-01-28 17-37-14.png (66.3 KB) - added by isis 5 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 6 years ago by phoul

Cc: admin@… added

comment:2 Changed 6 years ago by asn

Cc: sysrqb added

also cc'ing sysrqb in case he cares

comment:3 in reply to:  2 ; Changed 6 years ago by sysrqb

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

comment:4 in reply to:  3 ; Changed 6 years ago by asn

Replying to sysrqb:

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

comment:5 in reply to:  4 ; Changed 6 years ago by sysrqb

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

Changed 6 years ago by sysrqb

Attachment: bridgedb_details.png added

A mockup for clarity

comment:6 in reply to:  5 ; Changed 6 years ago by asn

Replying to sysrqb:

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

Sorry if I'm misunderstanding you but are you implying that this ticket can be implemented with solely UI changes? How would that happen? Don't you also have to enable the filterBridgesByIP6 filter etc. to get only IPv6 bridges from the backend?

comment:7 Changed 6 years ago by asn

mockup looks nice btw

comment:8 in reply to:  6 Changed 6 years ago by sysrqb

Replying to asn:

Replying to sysrqb:

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

Sorry if I'm misunderstanding you but are you implying that this ticket can be implemented with solely UI changes? How would that happen? Don't you also have to enable the filterBridgesByIP6 filter etc. to get only IPv6 bridges from the backend?

Nope you're correct, I need more sleep. From irc:

15:21 < sysrqb> asn: ok, so for #9127 what I said was correct but for the wrong reason. With aagbsn's hack which returns obfs2/3 and regular bridges, it includes the bridges returned by transport=obfs2 and transport=obfs3
15:21 < sysrqb> so if you requery for these specific transports, it just gives you a subset of the bridges returned without any criteria
15:22 < sysrqb> bridges.tpo doesn't return any ipv6 address by default, so you obviously get a new bridge if you request ipv6 specifically

comment:9 Changed 5 years ago by isis

Cc: isis added
Keywords: bridgedb-https added
Owner: set to isis
Status: newassigned

I mocked something up as well, but I think I like sysrqb's better because it clutters the main page less.

sysrqb, where could I find your code for this?

comment:10 Changed 5 years ago by sysrqb

I actually like both of them. I think it'll be better to have multiple options. I pushed my stuff to bug9127 in my pub repo, based on develop.

I'm not sure if we should change the way a new subclass of Resource is used for each page. It's should be unnecessary for the static pages (not including translations). But this is for another ticket.

comment:11 in reply to:  10 Changed 5 years ago by isis

Replying to sysrqb:

I actually like both of them. I think it'll be better to have multiple options. I pushed my stuff to bug9127 in my pub repo, based on develop.

Thanks, I'll check it out after I look into the current assignments.log file problem.

I'm not sure if we should change the way a new subclass of Resource is used for each page. It's should be unnecessary for the static pages (not including translations). But this is for another ticket.

I could be wrong because there might be a newer, easier way to do this, but I believe that subclassing Resource for each page is generally how it's done in Twisted. There are webapp frameworks built on top of Twisted which do a bit more of the boilerplating for you, I think, but I don't really know if they are worth using.

comment:12 Changed 5 years ago by isis

Keywords: bridgedb-0.1.3 added
Resolution: fixed
Status: assignedclosed

Sysrqb's branch was merged here, in bridgedb-0.1.3. Mine was merged here, in 0.1.1. The UI still needs a lot of work, but users can now request IPv6 and transports (and even both simultaneously, though there exist no IPv6 PT bridges yet, to my knowledge).

Note: See TracTickets for help on using tickets.