tbb-dev

tbb-dev@lists.torproject.org

447 discussions

Good Morning Precipitant
by mark bollinger 24 Mar '17

24 Mar '17

I was wondering what is the best way to sign up to volunteer? I have experience and knowledge in I.T. also would love to help anyway I can. Any advice would be greatly appreciated!

2 1

A proposal for redesigning Tor-Launcher for better usability
by irykoon 13 Mar '17

13 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone! I am Iry. Currently, I have been working on the anon-connection-wizard, a Python-clone of the Tor Launcher which aims at providing Tor users with a graphical instruction on configuring the Tor. During the development process, I realized some problems shared by both anon-connection-wizard and Tor-Launcher. Therefore, I would like to post my proposal here, in a hope to let Tor-Launcher developer also realize the problems. I have noticed that it may be too late to give the feedback since there is a deadline (March 3rd) for it, accoding to this discussion: https://lists.torproject.org/pipermail/tbb-dev/2017-February/000473.html But please let me if there is anything I can help! The proposal for redesigning anon-connection-wizard which was firstly posted on Github: https://github.com/Whonix/anon-connection-wizard/pull/ 3 # Background Currently, I have been working on the anon-connection-wizard, a Python-clone of the Tor Launcher which aims at providing Tor users with a graphical instruction on configuring the Tor. The application is especially helpful for users who live in Tor-censored area. This is because those users can only connect to the Tor network with the help of other censorship circumvention tools which include but are not limited to Tor bridges, pluggable transports and other third party Internet censorship circumvention tools like Lantern and VPN. # Problem Statement However, the current instruction provided by the anon-connection-wizard and Tor launcher may not be clear enough. That is to say, users are very likely to not be able to correctly connect to the Tor network even with the help of their instruction. # Related Research A detailed and published [research](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-5 8.pdf) conducted in 2015 also addressed the problem [1]. In that research, the researchers firstly did a small-scale user behavior experiment on the Tor Launcher for Tor Browser Bundle 5.0.3. And then, they redesigned the user interface of it basing on their observation on users’ behaviors and the direct feedback from the users. After finishing the redesign of the Tor launcher, they conducted a 124-participant experiment which aimed at examining the effectiveness of their redesign. The result showed an approximately 10 percentages of improvement in success rate and a 100 percentages of reducing on the time to success when comparing their redesign of Tor Launcher with the original one. For reasons I do not know, their [redesigned Tor Launcher](https://github.com/nmalkin/tor-launcher) [2] has not been adopted by the Tor project. However, since anon-connection-wizard is a clone of the Tor Launcher, it may be able to benefit from the recommendations and suggestions offered by that research. # Other Improvement If you believe the redesign of the anon-connection-wizard is a good idea, I also have some other recommendations. The current Tor Launcher mainly focuses on helping users circumvent the Internet censorship by Tor-supported methods like bridges and obfuscation technology. However, in areas under strict censorship, those methods may not be sufficient to help users to circumvent the Internet censorship. For example, in countries like China, the [only](https://www.torproject.org/docs/pluggable-transports) usable Tor-supported censorship circumvention method is “meek-amazon” [3], which also does not grantee working all the time. Besides, meek has not been [supported](https://phabricator.whonix.org/T386 ) by Whonix yet [4], making people in China or other heavily-censored area hard to connect to Tor only with the help of those Tor-supported censorship circumvention methods. In fact, people in those area usually use some third-party censorship circumvention tools to connect to the Tor network. Two main options are Virtual Private Network and proxy-based censorship circumvention tools like Psiphon3 and Lantern. Unfortunately, the Tor Launcher and the current anon-connection-wizard have not provided users using those third-party censorship circumvention tools with sufficient instructions. To clarify the problem, the following two examples simulate those users’ experience: 1. Alice uses a VPN to bypass the Internet censorship. One day she wants to try using the Tor. The first question asked by anon-connection-wizard is to describe her situation. Although knowledgeable users know she can connect to the Tor network “directly” using that VPN, Alice, as a first-time user may find “This computer’s Internet connection is censored” described her situation better. 2. Similarly, Bob uses the Lantern software to connect to the free Internet. One day he wants to try using the Tor. After choosing the configure option, Bob is asked if he’s connection to the Tor-network is censored. Naturally, Bob answers yes to that question and then he is asked to configure bridges in order to connect to the Tor network. After finishing that step, he is asked if he needs a proxy to connect to the Internet. Of course Bob does not think he needs one because he just checked the weather on the Internet without even knowing what proxy is. However, we know that the bridges will not be very helpful for Bob and all he has to do is to set proxy to use Lantern. What’s even worse? Even if Bob knows he does not need a bridge but a proxy setting to connect to the Tor network, the next step is still not easy for him. Since every time the proxy setting is auto-configured by Lantern client, Bob even does not know which port Lantern is listening on. Bob also does not know what is the proxy IP of Lantern. Bob does not know what 127.0.0.1 or local-host means. Bob is not sure if he needs an username and a password for his proxy. All the confusing questions make Bob frustrated. With the last hope, Bob tries to visit the URL provided by the anon-connection-wizard for help. But this does not work neither because the Tor website is also blocked. # Alternative Choice The two examples above illustrates how confusing the current instructions in anon-connection-wizard is. However, one may argue that we can use an online documents to instruct users how to configure it correctly instead of redesigning the anon-connection-wizard. Although I agree that an online documentation can be helpful to users, I do not think it can replace the redesign of the anon-connection-wizard because it makes anon-connection-wizard meaningless. Beside the potential connection issue to the online documents, if a large amount of users have to see online documents to configure anon-connection-wizard, they can see an online guideline on how to configure the torrc file manually instead. # My Position According to the argument above, I would like to propose a redesign of the current anon-connection-wizard which aims at improving its usability. I hope that my work will help more people to connect to the Tor network efficiently and successfully. # Research Schedule My planning research schedule is as follows: 1. Generate ideas on redesigning the anon-continence-wizard users interface, basing on the recommendations from outside sources, problems discussed above and suggestions from other people (11/March/2017-12/March/2017); 2. Present the planning redesign to public to receive feedback (12/March/2017); 3. Implement the redesign (12/March/2017-17/March/2017); 4. Prepare for the user behavior experiment, including recruitment and setting up environment (18/March/2017-20/March/2017); 5. Conduct the experiment (21/March/2017); 6. Process and analysis the experiment data (22/March/2017-24/March/2017 ); 7. Write the research report (25/March/2017-29/March/2017). # References [1] Fifield, David et al. "Tor’S Usability For Censorship Circumvention". N.p., 2017. Web. 11 Mar. 2017. [2] "Nmalkin/Tor-Launcher". GitHub. N.p., 2017. Web. 11 Mar. 2017. [3] The Tor Project, Inc. "Tor Project: Pluggable Transports". Torproject.org. N.p., 2017. Web. 11 Mar. 2017. [4] “T386 Meek Pluggable Transport". Phabricator.whonix.org. N.p., 2017. Web. 11 Mar. 2017. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYxjVjAAoJEKFLTbxtzdU8Xu0P/2R9yvQSxVQe3SFm8ww1Bcjc z7hVw6JsaQR62yCC2zyxRjAbUEJ/22+taUMKunnGRKUpzhk3PcYLS3lzvk5/Bg+C Og+q7Z2J1puPfhYfKQg7IeFIuoLzGj4u7dBFw8+uSXk0P4512qKANhBV/EI8/+Zo vJV5Qvmhot8pDEladAStXzult0Bufe2SxY626ECfih98ysOpLJnCIwiAXXeswoy/ k4h/nsjaXzemattGBsH6lf41lIv2bsNfH78QMmTKjoAe1j3FazDWXRR52LjiR+CS xsdg9f1hLiJYp9wslsasdQKH07TyqJdHNjlJ7PLwkCnnGhKF4IQpgVOB41jTL7/f smLK6Suo/lyST3Vic+opkFZEl8lodgh30G6pog9t63hYMeKA1wdoP5YH+8rZ8Et8 RCMzYBnsCPGP2/I7l3V52sO6An8lMalGO1yfJI05NA+ZtVCSEGJpeqwLhviNX/fq HcEVf+DIhk/KSrBvFB7qGxz6d13KJDUHJ1kkkRHKi5GywjWbNxf9kA/CNgK5VAxU 7HxBZfILK0t2E24SPqNkLEy97cAgR4O5Avcrow9C0gB+wN0JSXVpmBk+t2A3hZsf bZD2XCa+vxq/kH1bFJpq+QEpsN19E2clU8GEkcCqDKFZrYW6jVbRxYiILXZzvBGR 4dP1V5n0xsowmfCC+4pL =EFLv -----END PGP SIGNATURE-----

1 0

Fwd: [tor-project] [important] Trac usage and alternatives survey
by Georg Koppen 08 Mar '17

08 Mar '17

Hi! If you like/dislike dealing with our bug tracker then the Trac survey (see below) might be of interest to you. In any case we'd be happy to get feedback about our bug tracker deployment. Georg -------- Forwarded Message -------- Subject: [tor-project] [important] Trac usage and alternatives survey Date: Thu, 2 Mar 2017 18:37:08 +0100 (CET) From: Silvia [Hiro] <hiro(a)torproject.org> Reply-To: tor-project(a)lists.torproject.org, hiro(a)torproject.org Organization: Tor Project To: tor-project(a)lists.torproject.org Hi everyone, as some of you might already know we have been working on a survey to see if we can identify possible Trac alternatives. The original question was: should we continue to patch Trac until we love it, or should we look around for a tool that might be able to do what we need? The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with). So please take your time to answer the survey (it doesn't take longer than 2/3 minutes) https://storm.torproject.org/shared/mgNGJd30HpN8IL5XvoC4QhloRgDGLcpr6VzR89b… For any questions/doubts/rants feel free to write or ping me. -silvia _______________________________________________ tor-project mailing list tor-project(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Feedback on design decision for Tor Launcher
by isabela＠riseup.net 02 Mar '17

02 Mar '17

Hello TBB team! and Linda ;) I would like to ask your feedback on some feature decisions we have to make for Tor Launcher. We got fund to work on improving Tor Launcher user experience. We are going to use Linda's paper as our reference on how we will go about that. We might add some new things on the top of the suggestions she makes on her paper, I know Linda herself has some stuff she wants to consider that is not there. But! This email is a question on a more specific thing, a question that comes out whenever one talks about Tor Launcher is 'why not automate it?'. And our sponsors are asking us that exactly question. I am in favor of making it easier for the user that will prefer not to deal with settings, but I am also a big fan on making sure our users are safe. As I believe you all are! Our sponsors are asking for the PT selection part of the launcher to be automated. For us to test the user network and figure out the best solution to get the user connected to the Tor network - we could leave an option for those users who would prefer to go through settings and configure it as they will. That said, Linda has specific design considerations that lead her to decide against that because of user security. https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016#Designc… Another thing to consider is that we this will already obtain enormous gains with the improvements we will be doing at the Tor Launcher step, even without this automation piece. Linda's paper shows that. So, I would prefer we don't base this decision on 'gains' for Tor (of course automation will increase metrics is the easiest growth hack trick) but to base it on the user and their security. What we are looking for here is feedback on those points on 'design considerations' to make sure we are not missing anything here. Does the threats there has enough weight for us to not consider automation? Does anyone think different or has other points we are not considering? We would like feedback on this soon as we have a deadline (March 3rd) to decide on what to do about this feature request. Thanks! Isabela ps: Linda is updating her paper once that is done we will share with y'all o/

5 12

Re: [tbb-dev] Feedback on design decision for Tor Launcher
by Linda Naeun Lee 27 Feb '17

27 Feb '17

Mike, Thanks for the reply! On 2017-02-23 19:16, isabela wrote: > + Linda > > On 2/21/17 17:02, Mike Perry wrote: >> Linda Naeun Lee: >>> On 2017-02-21 06:30, isabela(a)riseup.net wrote: >>>> Hello TBB team! and Linda ;) >>>> >>>> I would like to ask your feedback on some feature decisions we have >>>> to >>>> make for Tor Launcher. >>>> >>>> We got fund to work on improving Tor Launcher user experience. >>> >>> Yay! >>> >>>> We are going to use Linda's paper as our reference on how we will go >>>> about that. We might add some new things on the top of the >>>> suggestions >>>> she makes on her paper, I know Linda herself has some stuff she >>>> wants to >>>> consider that is not there. >>> >>> :) >>> >>>> But! This email is a question on a more specific thing, a question >>>> that >>>> comes out whenever one talks about Tor Launcher is 'why not automate >>>> it?'. >>> >>> The quick answer is, "we might be able to do just as well without >>> automation, and if we can, we should!" And that they should let us >>> try. >>> >>>> And our sponsors are asking us that exactly question. I am in favor >>>> of >>>> making it easier for the user that will prefer not to deal with >>>> settings, but I am also a big fan on making sure our users are safe. >>>> As >>>> I believe you all are! >>>> >>>> Our sponsors are asking for the PT selection part of the launcher to >>>> be >>>> automated. For us to test the user network and figure out the best >>>> solution to get the user connected to the Tor network - we could >>>> leave >>>> an option for those users who would prefer to go through settings >>>> and >>>> configure it as they will. >>>> >>>> That said, Linda has specific design considerations that lead her to >>>> decide against that because of user security. >>>> >>>> https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016#Designc… >>>> >>>> Another thing to consider is that we this will already obtain >>>> enormous >>>> gains with the improvements we will be doing at the Tor Launcher >>>> step, >>>> even without this automation piece. >>>> >>>> Linda's paper shows that. >>>> >>>> So, I would prefer we don't base this decision on 'gains' for Tor >>>> (of >>>> course automation will increase metrics is the easiest growth hack >>>> trick) but to base it on the user and their security. >>>> >>>> What we are looking for here is feedback on those points on 'design >>>> considerations' to make sure we are not missing anything here. >>>> >>>> Does the threats there has enough weight for us to not consider >>>> automation? Does anyone think different or has other points we are >>>> not >>>> considering? >>> >>> I'm certainly discouraging moving it from what it is now straight to >>> an >>> automated thing, because I think that's going to take time to >>> implement such >>> a thing and we can help people a LOT just by making design changes. I >>> think >>> this is what you should emphasize. >>> >>> I think we can have WAYYYY better design than what I have in my >>> paper, too. >>> If I could redesign it now, I'd try to: 1) put everything on one >>> screen >>> (like how it is in the browser, if you go to connection settings), 2) >>> simplify even more, 3) give advice that doesn't require inputs (i.e. >>> "try >>> using X if you are in countries a,b,c"). >>> >>> Something that also isn't automated is asking something like "you are >>> about >>> to make a connection to Tor. is this okay?" or give options like >>> "connect" >>> and "connect with extra caution (this may be slower)"--and this can >>> be the >>> difference between a direct connection or use an unlisted bridge >>> running >>> some obfuscation protocol. >>> >>> I think that the threats there are not necessarily enough to deter us >>> from >>> automation. My point in the paper is that automation is not as simple >>> as >>> people think, and that this needs to be done carefully. With proper >>> tone, >>> consent, and miscellaneous things (user education, SEO-ing official >>> tor >>> mirrors, etc.), automation can be done. >>> >>> I think we can get it to be ALMOST as easy as automation if we design >>> it >>> right, though. And if we can, then we should do that instead. I have >>> no >>> evidence to support that case, but that's my two cents. We can even >>> test the >>> new design against automation (i.e. just compare it to a 100% success >>> rate >>> and how many seconds it would take to connect with an automated >>> process). >> >> First off, I agree with everything you said above, Linda. And your >> Design Considerations page captures the current set of concerns well. :) >> For brief historical context: The Tor Launcher configuration UI is the >> way it is because it was designed before Tor Browser had an updater. >> This meant that any automation would be done *every* time the user got >> a >> new copy of TBB. This was clearly unsafe and completely unacceptable, >> so >> we had to make everything an explicit choice. I didn't know this. Thanks for the information. I'm glad we have an updater now. >> Now that we do have an updater, I actually think that an optional "Try >> Everything!" button that tests all PTs (and fetches new PT bridges >> from >> a BridgeDB API via domain fronting) will definitely be safer than what >> we have now, and I think it is also likely that some form of optional >> automation (after a proper user warning) is likely to beat out >> anything >> that requires more decision points or interactions. I totally agree with this. Most (80%+) of the people who couldn't connect directly to Tor and couldn't connect with the recommended obfs3 bridge failed to connect. And they usually try the previous two options before getting the right configuration anyway. Overall, even users who don't need such fancy configurations make mistakes along the way, just because it's a foreign concept to them. I think that eliminating user error will be much safer, and I am a total advocate of this. My research can be used to see how many people this can help (i.e. "64% of attempts to connect on the first try (across different censorship environments) failed."). >> One hard part will be figuring out how to best provide the choice of >> using automated PT testing to the user, and describe the risks. Yep! This is something I can design/handle. >> Another hard part will be deciding which things to include in the >> automated testing: the public tor network, provided bridges, bridges >> from BridgeDB, or some subset/combination. Which of these things we >> include in the test will change the user's risk profile with respect >> to >> the categories you mentioned at >> https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016#Designc… Deciding what to include in the automated testing is something other people should handle. >> I do think these problems are solvable, but the reality of the >> situation >> might be that the user has to do a couple of interactions before the >> automation starts. (Like being asked where they are or what they want >> to >> test, being warned about the risks of each test, etc). It will be some >> work to design UX experiments to figure out which UX actually >> communicates this information to users without confusing them or >> scaring >> them off, but I know you're quite capable of that :). :) >> If we get painted into a corner where we don't get to do any of our >> own >> UX experiments for this, I think we should be prepared to resign >> ourselves to only automating the safest possible thing, and only after >> a >> scary warning box :/. I hope that eventually, we would get funding to do work that helps us. And I don't like the idea of funders being able to demand features from us without properly understanding the problem. We can talk about what we can do, if we are in that corner. Hopefully we won't be! (My impression is that it's still to be decided.) -- Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2

1 0

Release schedule for TBB based on FF52ESR?
by anonym 24 Feb '17

24 Feb '17

Hi, I looked at the master ticket [0] for rebasing Tor Browser on FF52ESR, but couldn't find any sort of schedule. Is there somewhere else than Trac where I should look for such plans? Otherwise, do you have estimations for: * when to expect a development build? * when to expect the final release? This timing info is important for us at Tails, since the ESR migrations historically has required quite some work on our side. Cheers! [0] https://trac.torproject.org/projects/tor/ticket/21147

2 3

quick question on tor browser
by isabela＠riseup.net 23 Feb '17

23 Feb '17

hello tbb-dev team!! I am writing a report and i need to know how many PTs (and which ones) Tor Browser supported back in july/2014. Can someone help me dig this from git repo? Thanks! Isabela

2 2

Team meetings calendar and Tor Browser Team
by isabela＠riseup.net 21 Feb '17

21 Feb '17

Hello Tor Browser Team! I would like to share a little bit how we will be organizing the team meetings day at Amsterdam Meeting. As you might have seem at the meeting wiki: https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam#We… We are reserving a day just for the teams to meet: Thu, 23 Mar: Teams meet to work on mapping and other issues; general meeting invitees arrive; group dinner in the evening. We created a 'calendar' system to better organize this day. I bet most of you haven't use google calendar but at Twitter we did and a cool feature was to be able to see everyone's calendar so you could figure out a good time to schedule a meeting. I created a 'calendar' for us here: https://storm.torproject.org/shared/_xuQsyM7Lkssjv9gKLw2rePMn9JYhtUBx1nr5Wg… You will see that some folks have already schedule meetings on it. Please read the suggested guidelines on how to use it. Some things to keep in mind as we organize Tor Browser Team meetings: 1. In the past we used this time to organize our roadmaps 2. You might want to invite Linda to join your roadmap discussion as she will be working on some tasks with you (all ux work before building UIs etc) 3. You should think if you want invite any person who is coming to Tor Meeting and you think should be in an specific meeting (remember this day is for teams and teams invites only) - maybe would be good to include some mobile people and have a mobile roadmap meeting? Let me know if you have any questions o/ Isabela

3 3

Tor Browser and Mozilla addon verification
by bancfc＠openmailbox.org 20 Feb '17

20 Feb '17

Hi, does Tor Browser check addon code for tampering for addons downloaded from the Mozilla server?

3 6

Next Tor Browser meeting on Monday, Feb 20 1900 UTC
by Georg Koppen 09 Feb '17

09 Feb '17

Hi all, as the subject indicates there won't be a Tor Browser meeting next Monday. The next meeting will be on Monday, Feb 20 1900 UTC as usual in #tor-dev on irc.oftc.net. Georg

1 0

← Newer
1
...
24
25
26
27
28
29
30
...
45
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev