Re: [tor-bugs] #10538 [Tor bundles/installation]: Think of PTTBB's pluggable transport interface

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

#10538: Think of PTTBB's pluggable transport interface
------------------------------------------+-------------------
     Reporter:  asn                       |      Owner:  erinn
         Type:  task                      |     Status:  new
     Priority:  normal                    |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:
Actual Points:                            |  Parent ID:
       Points:                            |
------------------------------------------+-------------------

Comment (by mikeperry):

 Replying to [comment:4 sysrqb]:
 > Replying to [comment:3 mikeperry]:
 > > The above is too much complexity on the TBB side for my tastes. I want
 this as simple as possible on the client side. To me, this means adding
 just a "Use default bridges" radiobutton (#10418), and otherwise
 preserving the "cut and paste lines exactly from BridgeDB" behavior.
 > >
 >
 > The Help button actually provides a good description, I think. I hope
 people actually use it.
 >
 > > The bridge type selection complexity should also be on the bridgedb
 side, IMO. I also strongly believe that defaulting to auto-probing/trying
 every PT type every time with TBB is very foolish behavior for censorship
 circumvention. This makes me think that by default, bridgedb should hand
 out only one type of bridges. It should have some explanatory text that
 tells the user to try another type if the default type doesn't work (by
 providing a link to the next most commonly functional PT type), and to how
 stick with that type in the future.
 >
 > I think this is putting too much of the burden on the user. In addition,
 as the arsenal of PTs continues to grow, the logic required to provide
 users with the correct PT will become a bit rediculous. Does tor need to
 try every bridge it is told? Maybe #5018 doesn't go far enough with
 respect to starting every PT as soon as it has a bridge and they should be
 start one at a time.

 Hrm. I think we can still keep this simple (from a UX perspective) if we
 think about it. I don't believe that a user should be using more than one
 PT type at a time. If we maintain that property, perhaps we can simplify
 the UX.

 One option is to impose a priority ordering on PT/bridge types, and remove
 "deprecated" PT protocols from the bridge list as soon as "newer" ones are
 added. This PT protocol ordering could be based on the most recently
 observed deployment counts of PTs (try the most popular, older, well-
 deployed PT types first, and then remove them and switch to newer PTs with
 smaller bridge counts, until we arrive at something that works).

 Under this model, we could have BridgeDB WebUI act as a sort of wizard.
 BridgeDB could instruct users to first try vanilla bridges, and then
 obfs2, and then obfs3, and then flashproxy, telling the user to manually
 "clear bridges" after each step. That way the ordering can change more
 dynamically, based on bridge count and PT availability. It could then give
 them a link directly to the PT type they need when they finally arrive at
 a working set.

 This may have issues (such as false positives due to heavy scraping + IP-
 based blocking), but if we're going to put effort into designing this, we
 should be conscious of the fact that the optimal direction to head in is
 towards a world where the user is only using one PT type at a time before
 moving on to the next type. We should put our thinking caps on to think of
 a flow that only requires the user to go through this discovery process at
 most once, as opposed to continually trying all bridge and PT types every
 time TBB starts or is reinstalled.

 We should also make it easy for them to communicate to their friends how
 to start from a given PT type, if possible. Provide a bookmarkable link +
 QR code at the end of the wizard maybe?

 > > I suppose the minimal logic TBB-side here would be to update any "Get
 Bridges" bridgedb links in Tor Launcher to specify the currently used PT
 types as arguments to the bridgedb URL or something.
 > >
 > > We may also want to add Tor Launcher logic to remove bridge lines that
 are obviously down/blocked (so it stops trying them on every startup), but
 that may be tricky.
 > >
 >
 > This has the potential to cause a lot of confusion and frustration,
 especially if a user has access to a private bridge that goes down and
 then they find that tor is no longer configured to use it.

 I suppose a heavier client-side option is for Tor Launcher or Tor to
 record if a particular PT type has succeeded recently. Liveness of a
 bridge can be verified by using a test circuit through a working bridge to
 a potentially blocked bridge (assuming all PTs also have working Tor OR
 ports). If the circuit succeeds but the bridge is unreachable from the
 client side (and if this happens multiple times for all bridges of a given
 PT type), then that PT type is definitely blocked by DPI. Later-
 stage/scarcer/bleeding-edge PTs could be used as first hops to confirm the
 blockage of the less scarce, but more blockable types.

 > > > BTW, I think I believe that users should not be required to know
 what 'obfs2' or 'scramblesuit' means and that they should not be exposed
 to those names (if possible) because they might get confused. The workflow
 assumes that users will copy/paste `Bridge` lines to tor-launcher without
 knowing what 'obfs3' means. That said, an "advanced" panel that allows
 people to toggle certain transports might be helpful. Also, some
 transport-specific documentation (port forwarding for flashproxy) might be
 required.
 > >
 > > I agree with the sentiment here. However, I think the browser is the
 wrong place for both PT type selection and PT-specific instructions. PT-
 specific instructions (like port forwarding) should be provided by
 bridgedb with the specific bridge type being handed out. We shouldn't
 clutter the Tor Launcher UI with such potentially ephemeral and volatile
 PT-specific details, if that is at all possible to avoid.
 >
 > I agree this should mostly be handled with bridgedb.  But your point
 about port forwarding is interesting because currently the only PT (afaik)
 that requires this is flashproxy, which is the only PT that is not
 distributed using bridgedb. I don't know what the best method is to
 educate users in this situation. Regarding the other PTs, bridgedb can
 provide the other instructions, but for now the entire process should be
 cut-and-paste. Maybe in the future it won't be so simple for all PTs.

 Hrmm well still, we should avoid having to have custom UI for each PT
 type. Is there any way to achieve that? Does Flashproxy perform UPNP or
 other NAT punching techniques by default?

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