Thus spake Adam Shostack (adam@xxxxxxxxxxxx): > 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev