As many of you know, Kathy Brade and I have been working on a Firefox add-on named Tor Launcher, which will function as a Tor process manager and controller for TBB (replacing Vidalia). See: https://trac.torproject.org/projects/tor/ticket/6009
Currently, Tor Launcher provides access to the basic Tor network settings that are needed by TBB users. We would like some feedback on the Network Settings dialog (accessible from within the browser after it starts up) and on a "first run" wizard that we have created based on a suggestion from Greg Norcie. A collection of screenshots is available here:
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/
If you are in a hurry, just look at these two:
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/FromBrowser/networ... (settings dialog as seen from inside the browser)
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard... (composite of all of the wizard panels).
Thanks to everyone who has provided input so far.
Mark Smith:
Currently, Tor Launcher provides access to the basic Tor network settings that are needed by TBB users. We would like some feedback on the Network Settings dialog (accessible from within the browser after it starts up) and on a "first run" wizard that we have created based on a suggestion from Greg Norcie. […]
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/FromBrowser/networ... (settings dialog as seen from inside the browser)
I wonder if it does not make more sense to put the proxy Type first instead of last. I have seen HTTP proxies, at least, labeled like "http://proxy.example.org:3128". So being able to enter the type, which is specified at the start of the URL, before the host might be better.
Is the use of the first person the best way to word the labels? It's not "me" who uses a proxy to access the Internet, it's the computer that is in front of me. It might not even be mine…
"Enter one or more bridge relays in the form address:port": pluggable transports will use an extra word. The current label is misleading.
I'm not sure about how useful is the big blue question mark icon just before that. Is it an active button? In that case it's not clear enough from the screenshot, so it might not appear to a user.
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard... (composite of all of the wizard panels).
Does it make sens to write "Tor browser bundle" instead of simply "Tor browser"? Given this window will be integrated in the browser, and that there is no other visible software, it might just avoid some confusion.
"If you are not sure how to answer this question, look at the Internet settings in another browser to see whethever you are using a proxy": I have a feeling this might not be the best advice. Asking users to open another browser enhance the likelyhood of them making mistakes. I remember Firefox being able to dig connection settings in other browsers. Can't such piece of code reused to get a suggestion?
"Enter a comma-separated list of ports that are allowed by your firewall": I find the "your firewall" pretty ironic for most cases I know. One's university firewall will not be exactly theirs.
In the bridge relay help panel, should https://briges.torproject.org/ and bridges@torproject.org be made clickable links? This text is missing that bridges can be asked at the help desk. Should pluggable transports be mentioned in any ways?
"Your browser will open after you are connected": this is misleading. It should say "The Tor Browser" instead of "Your browser". It is not the user's usual browser. I think it's also worth being more specific than "you are connected" because it might be understood as "connected to the Internet". Something like "The Tor Browser will open once successfully connected to the Tor network", maybe.
Should the short user manual be added to this picture somewhere?
On Fri, May 3, 2013 at 11:53 AM, Lunar lunar@torproject.org wrote:
Mark Smith:
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard... (composite of all of the wizard panels).
"If you are not sure how to answer this question, look at the Internet settings in another browser to see whethever you are using a proxy": I have a feeling this might not be the best advice. Asking users to open another browser enhance the likelyhood of them making mistakes. I remember Firefox being able to dig connection settings in other browsers. Can't such piece of code reused to get a suggestion?
It would be great if we could add some code to check whether or not the user is using a proxy. If this is not possible, we will have to think about some text for this screen that does not confuse anyone or lead to mistakes.
"Enter a comma-separated list of ports that are allowed by your firewall": I find the "your firewall" pretty ironic for most cases I know. One's university firewall will not be exactly theirs.
I guess "the" might be a better fit.
Should pluggable transports be mentioned in any ways?
I don't think we should confuse users too much by listing all the different options they have for connecting (no bridge, bridge, obfs2, obfs3).
Should the short user manual be added to this picture somewhere?
We could link to it, just like we're linking to bridges.tpo and bridges@tpo. Other options might be to include it in the bundle or re-use the text as part of a help screen.
On the contrary, I think you should list them all under an menu item called advanced connections. Users who need these connections will have them and those that don't, probably won't know what they are and thats ok.
On Fri, May 3, 2013 at 5:41 PM, Runa A. Sandvik runa.sandvik@gmail.comwrote:
On Fri, May 3, 2013 at 11:53 AM, Lunar lunar@torproject.org wrote:
Mark Smith:
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard...
(composite of all of the wizard panels).
"If you are not sure how to answer this question, look at the Internet settings in another browser to see whethever you are using a proxy": I have a feeling this might not be the best advice. Asking users to open another browser enhance the likelyhood of them making mistakes. I remember Firefox being able to dig connection settings in other browsers. Can't such piece of code reused to get a suggestion?
It would be great if we could add some code to check whether or not the user is using a proxy. If this is not possible, we will have to think about some text for this screen that does not confuse anyone or lead to mistakes.
"Enter a comma-separated list of ports that are allowed by your firewall": I find the "your firewall" pretty ironic for most cases I know. One's university firewall will not be exactly theirs.
I guess "the" might be a better fit.
Should pluggable transports be mentioned in any ways?
I don't think we should confuse users too much by listing all the different options they have for connecting (no bridge, bridge, obfs2, obfs3).
Should the short user manual be added to this picture somewhere?
We could link to it, just like we're linking to bridges.tpo and bridges@tpo. Other options might be to include it in the bundle or re-use the text as part of a help screen.
-- Runa A. Sandvik _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, May 3, 2013 at 3:44 PM, Andrew F andrewfriedman101@gmail.com wrote:
Users who need these connections will have them and those that don't, probably won't know what they are and thats ok.
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
Runa A. Sandvik:
On Fri, May 3, 2013 at 3:44 PM, Andrew F andrewfriedman101@gmail.com wrote:
Users who need these connections will have them and those that don't, probably won't know what they are and thats ok.
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
Having non-pluggable transports bridges while there are flashproxies and obfs3 seems redundant to me. It's very difficult to write appropriate documentation to justify use of regular bridges (only reason: there are more of them, less times you get a "we currently don't have any") while there is obfs3. Same for obfs2, why bother if there is obfs3?
I think the root cause of this problem is, that there is no mechanism for bridges about available updates and no easy (enough) way to update themselves to the latest pluggable transport.
So I think the best way is to abandon non-pluggable transports bridges and to upgrade them. Is that planed?
On Fri, 3 May 2013 16:05:15 -0400 "Runa A. Sandvik" runa.sandvik@gmail.com wrote:
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
One answer is the user shouldn't care. Tor Browser should automatically loop through the various kinds of connectivity and just connect. non-obfs bridges really should get wholly replaced with obfs bridges en masse.
Another thought is with flashproxy in the pluggable transports bundle, what percent of flashproxies work by default with no user config needed?
I wonder if we could extrapolate that percentage to a larger "what if we did relay by default?" for all bundles...
Thus spake Andrew Lewman (andrew@torproject.is):
On Fri, 3 May 2013 16:05:15 -0400 "Runa A. Sandvik" runa.sandvik@gmail.com wrote:
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
One answer is the user shouldn't care. Tor Browser should automatically loop through the various kinds of connectivity and just connect. non-obfs bridges really should get wholly replaced with obfs bridges en masse.
Yes that's true, ideally the user shouldn't have to care, or enter random data into text fields, except as last resort.
However, we can't just probe everything because we don't want to probe for the public Tor network if you're censored. Best case: client IPs that are observed to probe various known Tor transports get targeted for more agressive censorship (the censor could just fail any unrecognizable traffic for N minutes after someone touches a public Tor IP, for example). Worst case: Targeted exploits are deployed that aim to subvert their computer in general, via Tor or otherwise.
It's tempting to say this means we should have either just two bundles or perhaps just an "I'm censored" checkbox at startup.
But then, even if we probe our list of pluggable transport types, if one of them is blockable, we still advertise that we're a Tor user by touching it. Such client IPs can then again be treated differently in terms of more agressive policies, or exploits.
It seems like this means we need users to at minimum understand the nature of their censorship and what mechanism they expect to actually *work* in their location (based on word of mouth, forum posts, etc).
Does this mean we should provide a different bundle for each mechanism? Or does this mean we should aim for one bundle that just allows the user to pick their best guess at the mechanism?
This wizard/first run UI dialog is a version of the "You pick the mechanism that works". Unfortunately, at this state, this means the user actually has to enter data. I agree this isn't optimal.
One could imagine a future version where they just check "Flashproxies work for me!" or "Obfsproxy works for me!", and then their browser makes the appropriate bridge discovery connections using that transport to bootstrap from a number of directory servers, possibly encoded in their Tor Launcher addon (if it can update successfully), or entered by support software (BridgeFinder or some other stegenographic non-Tor browser addon).
Another thought is with flashproxy in the pluggable transports bundle, what percent of flashproxies work by default with no user config needed?
Not sure. :/
Another question that I also don't know the answer to (but maybe you do): Do any of these existing mechanisms in the Wizard (HTTP proxies, using only 80/443, or vanilla Tor Bridges) still work in a significant sense?
I imagine Tor bridges still work a lot of places, but do we care enough at this point? Should we focus our development *only* on pluggable transports?
If the answer really is "Bridges and HTTP proxies don't work well enough for us to care about them anymore," then that would eliminate this entire discussion, and we could table figuring out the first-run UI until we have mechanisms that actually work, and ask the users to choose among those.
I think though that quite a few people still use vanilla Tor Bridges successfully, right?
I wonder if we could extrapolate that percentage to a larger "what if we did relay by default?" for all bundles...
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/175-automatic...
We could do this same thing to promote uncensored Tor clients to various types of pluggable transports.
On Sat, May 04, 2013 at 02:09:33AM -0700, Mike Perry wrote: | Thus spake Andrew Lewman (andrew@torproject.is):
| > One answer is the user shouldn't care. Tor Browser should automatically | > loop through the various kinds of connectivity and just connect. | > non-obfs bridges really should get wholly replaced with obfs bridges en | > masse. | | However, we can't just probe everything because we don't want to probe | for the public Tor network if you're censored. Best case: client IPs | that are observed to probe various known Tor transports get targeted for | more agressive censorship (the censor could just fail any unrecognizable | traffic for N minutes after someone touches a public Tor IP, for | example). Worst case: Targeted exploits are deployed that aim to subvert | their computer in general, via Tor or otherwise. | | It's tempting to say this means we should have either just two bundles | or perhaps just an "I'm censored" checkbox at startup.
I think this might be the right direction. The person running Tor knows two things: if they're worried about someone monitoring their network right now, and how technical they are (and their desire to tweak settings).
The UI could thus start:
"Should Tor do our best to figure out how to get connected, at risk of drawing attention and response if you're on a heavily-monitored network?"
[I need to be careful, I'll configure things (Recommended) ]
[ Probe the network (Riskier) ]
[ I'm not sure, please help me decide]
Thus spake Adam Shostack (adam@homeport.org):
On Sat, May 04, 2013 at 02:09:33AM -0700, Mike Perry wrote: | Thus spake Andrew Lewman (andrew@torproject.is):
| > One answer is the user shouldn't care. Tor Browser should automatically | > loop through the various kinds of connectivity and just connect. | > non-obfs bridges really should get wholly replaced with obfs bridges en | > masse. | | However, we can't just probe everything because we don't want to probe | for the public Tor network if you're censored. Best case: client IPs | that are observed to probe various known Tor transports get targeted for | more agressive censorship (the censor could just fail any unrecognizable | traffic for N minutes after someone touches a public Tor IP, for | example). Worst case: Targeted exploits are deployed that aim to subvert | their computer in general, via Tor or otherwise. | | It's tempting to say this means we should have either just two bundles | or perhaps just an "I'm censored" checkbox at startup.
I think this might be the right direction. The person running Tor knows two things: if they're worried about someone monitoring their network right now, and how technical they are (and their desire to tweak settings).
The UI could thus start:
"Should Tor do our best to figure out how to get connected, at risk of drawing attention and response if you're on a heavily-monitored network?"
[I need to be careful, I'll configure things (Recommended) ]
[ Probe the network (Riskier) ]
[ I'm not sure, please help me decide]
I like this direction. I think it can capture all of our concerns.
Right now, "Probe the network" would just mean "Try the public network". Later, it can mean more extensive probing (of perhaps a selected subset) of pluggable transports. At that point, we could break it out into "My Internet connection is not censored or filtered" and "I am censored: Probe some common circumvention mechanisms for me (Risky)"
That would capture Naif's request of having a one-click option that allows people to just connect to the public network if that works for them (which is still the lion's share of our userbase), and has an explicit option to help people through any confusion.
I think we're getting closer!
On Sat, May 04, 2013 at 12:54:35PM -0700, Mike Perry wrote: | > I think this might be the right direction. The person running Tor | > knows two things: if they're worried about someone monitoring their | > network right now, and how technical they are (and their desire to tweak | > settings). | > | > The UI could thus start: | > | > "Should Tor do our best to figure out how to get connected, at risk of | > drawing attention and response if you're on a heavily-monitored | > network?" | > | > [I need to be careful, I'll configure things (Recommended) ] | > | > [ Probe the network (Riskier) ] | > | > [ I'm not sure, please help me decide] | | I like this direction. I think it can capture all of our concerns. | | Right now, "Probe the network" would just mean "Try the public network". | Later, it can mean more extensive probing (of perhaps a selected subset) | of pluggable transports. At that point, we could break it out into "My | Internet connection is not censored or filtered" and "I am censored: | Probe some common circumvention mechanisms for me (Risky)" | | That would capture Naif's request of having a one-click option that | allows people to just connect to the public network if that works for | them (which is still the lion's share of our userbase), and has an | explicit option to help people through any confusion. | | I think we're getting closer!
What else does it need?
Btw, th framework I used is the NEAT/SPRUCE approach to usable warnings, described here:
http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postatt...
Thus spake Adam Shostack (adam@homeport.org):
On Sat, May 04, 2013 at 12:54:35PM -0700, Mike Perry wrote: | > I think this might be the right direction. The person running Tor | > knows two things: if they're worried about someone monitoring their | > network right now, and how technical they are (and their desire to tweak | > settings). | > | > The UI could thus start: | > | > "Should Tor do our best to figure out how to get connected, at risk of | > drawing attention and response if you're on a heavily-monitored | > network?" | > | > [I need to be careful, I'll configure things (Recommended) ] | > | > [ Probe the network (Riskier) ] | > | > [ I'm not sure, please help me decide] | | I like this direction. I think it can capture all of our concerns. | | Right now, "Probe the network" would just mean "Try the public network". | Later, it can mean more extensive probing (of perhaps a selected subset) | of pluggable transports. At that point, we could break it out into "My | Internet connection is not censored or filtered" and "I am censored: | Probe some common circumvention mechanisms for me (Risky)" | | That would capture Naif's request of having a one-click option that | allows people to just connect to the public network if that works for | them (which is still the lion's share of our userbase), and has an | explicit option to help people through any confusion. | | I think we're getting closer!
What else does it need?
Well, this is a difficult piece of UI, but it is not a large one.
I think we need to dial in the actual verbage for the strings and the help text for this first-run Wizard, and the specific stages and steps we actually need for the first time, vs what we can additionally ask if network bootstrap fails (the firewall question, for example), vs what should we present in the more compact UI in the settings menu. It's all the same UI, just different presentations.
We also need to freeze the strings as early as we can to avoid driving the translators nuts (or worse, end up with misplaced/inaccurate strings). Commonality for strings between UI elements might be nice here.
On ther other hand, we also need to be careful not to over-engineer it, so as to delay getting this into the hands of people who currently cannot use gettor (because of the Vidalia+TBB bundle size). As I said previously, we burned 4 months deliberating the "Don't touch the network" option before, and still ended up with something we're not satisfied with.
It is my belief this is because the underlying circumvention and bridge discovery mechanisms simply require too much user input right now, and no amount of deliberation over the UI to support these systems will truly solve that problem.
So far, this has led me to decree that "Let's just keep this damn thing simple enough to capture what we can actually do now, and worry about pluggable transports, probing, and autodiscovery later."
If everyone really believes should instead decide about as much as we can up front, we should design the general structure of the Wizard such that it is enough to handle both the situation now, and once we have more sophisticated pluggable transport and bridge discovery machinery.
However, if this process even begins to smell like it's going to take more than a week (let alone 4 months) before we can arrive at a solution we can deploy in an alpha, I'm going to cut it off. At that point, it would be better just to design a new Wizard once the transport discovery and probing mechanisms are actually ready, and we better understand their exact form, capabilities, and configuration requirements.
Mike Perry:
We could do this same thing to promote uncensored Tor clients to various types of pluggable transports.
I asked this some time ago: "[tor-talk] anonymity: bridge users vs. entry guard users" [1]
If everyone only uses pluggable transports... That's quite an interesting idea. You wouldn't need to ask the question if ones prefers to connect to the public Tor network or or to use pluggable transports anymore.
I think everyone using bridges would make uncensored users more dependent on bridge authorities and give more power to bridge authorities, thus make Tor less safe for uncensored users. More centralization, once you decide to put down the bridge authority, there is more usable Tor network.
If using pluggable transports were the default and the public Tor network an advanced option, it would still make Tor less anonymous for uncensored users, because more people who actually don't depend on pluggable transports, are using them, and fewer are using the good old entry guard mechanism.
So this is also a network design / political decision.
[1] https://lists.torproject.org/pipermail/tor-talk/2012-May/024378.html
On Sat, May 04, 2013 at 02:09:33AM -0700, Mike Perry wrote:
Thus spake Andrew Lewman (andrew@torproject.is):
On Fri, 3 May 2013 16:05:15 -0400 "Runa A. Sandvik" runa.sandvik@gmail.com wrote:
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
One answer is the user shouldn't care. Tor Browser should automatically loop through the various kinds of connectivity and just connect. non-obfs bridges really should get wholly replaced with obfs bridges en masse.
Yes that's true, ideally the user shouldn't have to care, or enter random data into text fields, except as last resort.
However, we can't just probe everything because we don't want to probe for the public Tor network if you're censored. Best case: client IPs that are observed to probe various known Tor transports get targeted for more agressive censorship (the censor could just fail any unrecognizable traffic for N minutes after someone touches a public Tor IP, for example). Worst case: Targeted exploits are deployed that aim to subvert their computer in general, via Tor or otherwise.
Aside, there are this ticket and blog post, about how it may be hard to optimize for both use cases at once.
"Config option to declare whether you're using bridges for reachability or for security" https://trac.torproject.org/projects/tor/ticket/4624 https://blog.torproject.org/blog/different-ways-use-bridge
David Fifield
Andrew Lewman:
On Fri, 3 May 2013 16:05:15 -0400 "Runa A. Sandvik" runa.sandvik@gmail.com wrote:
I disagree. The Tor help desk sees a ton of requests from users saying that Tor is unable to connect, and the simple fix is to give them a bridge or two. Not all users know what they need to connect, and not all users will know the difference between bridge, obfs2, and obfs3.
One answer is the user shouldn't care. Tor Browser should automatically loop through the various kinds of connectivity and just connect. non-obfs bridges really should get wholly replaced with obfs bridges en masse.
Probing doesn't work well for people in countries where using Tor is dangerous.
I think you should completely drop the "hide Tor from your ISP, because it's dangerous in your country" use case. It's an arms race you already lost and conceptually always can easily lose against endless data retention with retroactive policing. Even if you had a perfect unbreakable obfsproxy working perfectly for private bridges, 100% always hiding Tor would still be a complicated bootstrap problem no regular user in those countries won't be able to solve.
Quote Jacob Appelbaum (in context of private obfuscated bridges) [1]
Some pluggable transports may seek to obfuscate traffic or to morph
it. However, they do not claim to hide that you are using Tor in all cases but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing.
[1] https://mailman.boum.org/pipermail/tails-dev/2013-April/002950.html
On 5/3/13 4:10 PM, Mark Smith wrote:
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard... (composite of all of the wizard panels).
While i've still not tried running it, i think that's very important to have a "default way" where the user with just "1 click" is online.
I mean that the wizard should provide as a first option a question that ask the end-user something like: - Start Browsing - Custom Settings
That way you will reach two kind of users: - The ones that are OK with the default (or just doesn't know) - The ones that require some custom settings (if they need it, they know)
The overall usability improvement would be very powerful because the user, from clicking to the application is just "1 step forward" with no additional complex question asked (from the end user perspective).
Fabio
p.s. Following this improvement, from usability perspective i think that the most important steps are: - Making a comfort loader during the loading of Tor Hidden Services (to avoid bad white page effect while waiting) - Improving the Windows Installer (with a sort of installer guiding the end-user to the extraction process up to an open-browser) - Make Mac OS X DMG packaging for distribution (rather than ZIP)
Sweet! However I think this Wizard is a super-technical version of something that should be much simpler if we intend to be targeting non-technical users.
Feedback: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
Question 1 (this is literally the first thing a user will see when launching, right?) is a super-technical question. How is a user supposed to know if they're using a proxy? If we're targeting users who barely know what a browser is, I don't think these instructions are good enough. But any instructions would be wrong IMO. Surely there's some way to query this information from the system, no? On linux, looking at environment variables; on Windows there are system functions.
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
What percentage of users are a) affected by this question and b) understand it? I suspect it's very, very low, and therefore not worth dedicating a screen to. Every additional screen is a monumental amount of pain for a non-technical user to read, try to think through, and then ultimately guess at hoping they get something right. If something, anything, doesn't work - they will think back through all the screens they guessed at, and give up figuring it's way too hard to figure out.
What's the behavior of firewalls failing? Some drop packets (timeout) and others reject, right? If a connection on port 6-thousand-whatever hits one of those cases, retry on 80 or 443. Put up a cool animated gif that makes the user think their computer is fighting hard to get them online. Bonus points for having it actually represent the packet getting lost or being rejected.
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
I don't think this represents sufficiently that this is *Optional*. That (most) users will not need to fill this in.
I think we should think about the security and privacy implications of an approach that can be referred to technically as "try a bunch of shit".
1) If a user wants to use a proxy (e.g. an SSH tunnel) and we don't abide by that, they will leak network traffic, this is bad. It's also probably reasonably common for technical folks. 2) If a user must use a proxy - trying a non-proxied connection doesn't really matter, it'll just be dropped. It's very unlikely this will cause an alert or raise suspicions, especially when the net admin has created a chokepoint (the proxy) where she can do all the logging and analytics she wants.. (Anyone disagree?) 3) If a user must have their traffic exit on certain ports, and we try a different port - the firewall will drop it, and again, unlikely to cause an alert or raise suspicions. 4) If a user *wants* to have their traffic exit on a port, and we don't abide by it, that's bad. But I don't think this is super common. Well, maybe it is, maybe people prefer port 443.
So I think the best course of action would be to try and handle everything except to bridge screen automatically, with perhaps some [Advanced] button in the bottom left that these settings are hidden behind. Get the proxy settings automagically, and try some port probing.
-tom
Tom Ritter:
Sweet! However I think this Wizard is a super-technical version of something that should be much simpler if we intend to be targeting non-technical users.
Feedback: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
Question 1 (this is literally the first thing a user will see when launching, right?)
As a tester I can say, the answer is: yes.
Thus spake Tom Ritter (tom@ritter.vg):
Sweet! However I think this Wizard is a super-technical version of something that should be much simpler if we intend to be targeting non-technical users.
Feedback: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
Question 1 (this is literally the first thing a user will see when launching, right?) is a super-technical question. How is a user supposed to know if they're using a proxy? If we're targeting users who barely know what a browser is, I don't think these instructions are good enough. But any instructions would be wrong IMO. Surely there's some way to query this information from the system, no? On linux, looking at environment variables; on Windows there are system functions.
This is made more difficult by the fact that a proxy+Tor (or even proxy+bridge) sometimes works in places that censor Tor.
In those situations (which are the real reason we're asking *before* connecting - we don't want those people to touch the public Tor network before giving them the option not to), simply checking their system proxy settings might not be sufficient. The user only needs their proxy to make Tor work.
I'm not sure how common this still is anymore. DPI gear may have all advanced enough by now to automatically unwrap the proxy header?
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
What percentage of users are a) affected by this question and b) understand it? I suspect it's very, very low, and therefore not worth dedicating a screen to. Every additional screen is a monumental amount of pain for a non-technical user to read, try to think through, and then ultimately guess at hoping they get something right. If something, anything, doesn't work - they will think back through all the screens they guessed at, and give up figuring it's way too hard to figure out.
This is a good point. I see no harm in dropping this question on first-run until bootstrap fails, or otherwise get it out of the way or make it an optional step somehow...
http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/screen...
I don't think this represents sufficiently that this is *Optional*. That (most) users will not need to fill this in.
That's true. We should indicate to users that if they are not censored, they can click Connect.
Perhaps like Naif said, we can simply ask them that at the beginning somehow, too. Might clutter things, though.. I'd rather first try to think harder about which wizard panes are truly optional for a first-run, like you have done.
So I think the best course of action would be to try and handle everything except to bridge screen automatically, with perhaps some [Advanced] button in the bottom left that these settings are hidden behind. Get the proxy settings automagically, and try some port probing.
I'm inclined to agree (I was hesitant to split up the initial dialog into a full 3 pane wizard if we could find a way to avoid it), but we need to get someone who is studying censorship systems or aware of the situation on the ground to chime in here and tell us that the Proxy+Tor or Proxy+Bridge approach is becoming significantly less effective at evading censorship systems these days.
Mike Perry:
In those situations (which are the real reason we're asking *before* connecting - we don't want those people to touch the public Tor network before giving them the option not to), simply checking their system proxy settings might not be sufficient. The user only needs their proxy to make Tor work.
Thought has been put into this before: - https://trac.torproject.org/projects/tor/ticket/2905 - https://trac.torproject.org/projects/tor/attachment/ticket/2905/xxx-no-publi...
Seems that knowledge has been ignored when planing how tor-launcher should look like.
Thus spake adrelanos (adrelanos@riseup.net):
Mike Perry:
In those situations (which are the real reason we're asking *before* connecting - we don't want those people to touch the public Tor network before giving them the option not to), simply checking their system proxy settings might not be sufficient. The user only needs their proxy to make Tor work.
Thought has been put into this before:
https://trac.torproject.org/projects/tor/attachment/ticket/2905/xxx-no-publi...
I was there for that disaster of a ticket, and wrote that outline. It took a solid month of endless discussion and back and forth (and 4 months wall-clock time) just to get that outline, and after all of that, people were still barely able to agree that the outline reflected the situation, let alone what they wanted to do with their own sub-project.
Seems that knowledge has been ignored when planing how tor-launcher should look like.
You'll note that from Line 75 of that outline you linked (that I wrote) describes exactly what this is: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/FromBrowser/networ...
This thread is about exploring the idea of breaking that window into a Wizard and/or minimizing it further, because usability people have told us that a single pane with all of those questions is overwhelming at startup.
As for the rest of that outline, I'm not going through that mess again. The underlying Tor support for it is decided and implemented, and that was all that mattered in the first place anyway. Other projects that want to have their own Tor configuration can simply disable Tor Launcher, or patch it to do what they want.
-
Adam Shostack -
adrelanos -
Andrew F -
Andrew Lewman -
David Fifield -
Fabio Pietrosanti (naif) -
Lunar -
Mark Smith -
Mike Perry -
Runa A. Sandvik -
Tom Ritter