Opened 6 years ago

Closed 5 years ago

#9446 closed task (fixed)

Support enabling/disabling Pluggable Transports

Reported by: bastik Owned by:
Priority: Medium Milestone:
Component: Applications/Torbutton Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If #9445 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, controlling PTs would be awesome.

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by bastik

Please have a look at the image [PNG] attached to #9445 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.

comment:2 Changed 6 years ago by lunar

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.

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

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

comment:4 Changed 6 years ago by bastik

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

comment:5 Changed 5 years ago by dcf

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.