Support enabling/disabling Pluggable Transports

If #9445 (moved) happens TorButton probably needs to support some level of control over Pluggable Transports, maybe the same level of control.

e.g. now trying to speak obfs3, as the user only tried obfs2 and could not connect.

This does not depend on #9445 (moved), controlling PTs would be awesome.

added component::applications/torbutton priority::medium resolution::fixed status::closed type::task labels

Please have a look at the image [PNG] attached to #9445 (moved) for what I have in mind.

As an alternative TorButton could get a button to reset the launch state setting (stored in about : config) of Tor Launcher to enable the user to change settings again.

Do we really need users to learn the various intrinsic details of the various pluggable transports? How would it help me to learn the difference between obfs2 and obfs3?

For Flashproxy, users need some manual configuration on their network, but I don't think “choosing” transports is the way to convey that message.

Replying to lunar:

Do we really need users to learn the various intrinsic details of the various pluggable transports?

No, everything should be enabled by default. #9445 (moved) got stripped down. Currently getting everything to work by default is much more important. Currently I don't care enough to open another ticket, which would allow such a selection on first launch.

Users don't have to learn anything, **but if **they know something, they can make their choice, without editing torrc (which I don't consider user friendly, although it works).

How would it help me to learn the difference between obfs2 and obfs3?

Users don't have to understand anything about what obfsX is or how it works, but if they know (Tor Wiki, TorBlog, friends, simply learned) that obfs2 makes them look suspicious and their connection is dead after x minutes, they can disable that easily.

I'm luckily not in the position to require a bridge or even worse on Pluggable Transports so it's hard to tell how users acquire that knowledge and if they would actually benefit from being able to choose.

Suppose a system that detects obfs2 (for example) and blacklists the target and the source of a request for some amount of time for the source. A user could not make new connections for let's say 3 hours. A single request that gets detected will result in a dead network for 3 hours; no matter how good the other transports are.

For Flashproxy, users need some manual configuration on their network, but I don't think “choosing” transports is the way to convey that message.

With WebSockets that is unfortunately true, but let's hope that changes with WebRTC.

Everything should work by default.

No need to learn or read anything for users whose use-case is agnostic about the transport.

But if, who ever got to decide, decides otherwise, so it will be.

I think this is done with #10418 (moved). "designdraft suggestion.png:ticket:9445" even fairly looks like https://people.torproject.org/~mikeperry/images/Settings.jpg.

Trac:
Status: new to closed
Resolution: N/A to fixed

closed