Re: [tor-dev] First-time tails/tor user feedback
Hi, Andrew Lewman wrote (21 Apr 2012 14:42:54 GMT) : > I spent the past week in Sweden, attending the Stockholm Internet > Forum, http://www.stockholminternetforum.se/, for part of it. I made > a number of tails 0.10.2 usb sticks for people on request. I also > asked a lot of people their impressions of Tor and Tails. I received > a plethora of feedback. [...] Thanks a *lot*, Andrew, for this testing and feedback! Much appreciated. Please go on. I'm sorry we did not reply to this earlier with words, but as you'll see bellow, we replied with actual changes to some of these issues. > # First issue: Language selection > The first issue was on the language selection screen. 4 of 8 people > were confused why it was called "Debian Live System" and not "Tails > Live System". 8 of 8 knew what language selection meant, but weren't > sure how this mapped to Tails. The language selection specific should be fixed by Tails >= 0.11 (no language menu anymore in bootloader), the "Debian Live" confusing message is fixed in Tails >= 0.12 (custom Tails syslinux menu). > # Second issue: wifi and tor browser > The tor browser starts up before the wireless is configured. > The tor browser then reports a proxy error. This is not the case anymore in Tails >= 0.11: iceweasel is started only after the network was successfully configured. > With some prompting, all 8 figured out the wifi and then didn't know > what to do. Tor does keep trying to load, and takes forever because > it needs to download the entire directory. Users have no feedback as > to what's going on behind the scenes because vidalia is hidden. I'm a bit surprised, since a notification about the time being sync'd, and this operation being necessary for Tor to work properly, should be displayed quite early since Tails 0.10.1. > 8 of 8 waited patiently for something to happen on the screen. OK. > # Third issue: green onion > 3 of 8 people saw the green onion appear in the menu bar up top. These > three people hovered over it and saw the 'Connected to the Tor Network' > message. No one knew to double-click on it to get a menu of other things > to do. No one knew to right-click on it to get the drop-down menu. They > were presented with the default check.torproject.org 'congratulations' > page and then sat there. Hmm... they were asked "to browse to their favorite site", and did not do anything once they were presented a web browser? I'm at a loss... Any suggestions how we could make their experience better? > # Fourth issue: check.tpo is not helpful > 8 of 8 people saw the default check.torproject.org site telling them > 'congratulations. Your browser is configured to use tor.' 7 of > 8 people asked 'where is my browser?' The one who didn't ask this > question was already a firefox user and recognized the interface. OK, this clarifies. So, this is a problem of our iceweasel not looking enough like "a" web browser, apparently. Oops. Probably check.tpo should be rephrased (s/your/this/, to start with) so that it's clearer That Thing is the web browser that's configured to use Tor. > 0 of 8 understood what the IP address message meant. Comments ranged > from 'is that different than my current IP address?' to 'what's an > ip address?' > As an aside, when showing someone TBB on their own laptop, they saw > the check.tpo site, and then went to Safari and started it up. > When asked why they did this, the answer was 'safari is my browser. > this says your browser is configured to use tor.' This tends to confirm the need to s/your/this/ IMHO. > # Fifth issue: exit relay congestion/failures > 8 of 8 people tried to get to their own sites. 'I wonder what my > site looks like when I'm anonymous' was the most common comment (5 > of 8). For 6 of 8 people, their site didn't load at all, and tor > browser reported their site was unreachable. All 6 then tried to go > to google search in their own language; meaning google.es, > google.se, etc. For 3 of those 6, this didn't work either. They gave > up and assumed tor was broken or was censoring their destinations. > [...] > The user has no feedback as to why their site didn't work. And tor > assumes everything is working fine. Wow, this is much worse than any experience I've had :/ I'm not sure how we can help from Tails' side. > When asked "please find a video you like", they all went to youtube. > Most of the videos they wanted to see resulted in 'This video is > currently unavailable.' 8 of 8 assumed it was because youtube was > blocking tor, not because the video is flash-required. 2 of > 8 started randomly clicking videos suggested by youtube to see if > any of them worked. Eventually, 2 of 8 got videos to work with > youtube and were amazed it worked at all. OK, this is clearly suboptimal, to say the least, but it's so much better than it was before 0.10... > # Sixth issue: no flash, no warning > 2 of 8 people had flash apps on their website. 4 of 8 had ad banners > that used flash. All were surprised a
Re: [tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch
On 7/16/12 2:15 AM, Ondrej Mikle wrote: > On 07/15/2012 02:56 PM, Arturo Filastò wrote: >> I would like to follow up on the discussion we had in Florence on some >> design choices behind OONIB. >> >> In particular the most controversy was around using HTTP or rsync. > [...] > >> # What properties we would like it to have >> note: these are not ordered. >> >> * Efficient even over high latency networks. >> >> * Ease of integration for third party developers. >> >> * Expandable to support requirements of new tests we develop. >> >> * Anonymous >> >> * Secure > Even though you will probably not end up using this, it may be a good idea to > know that it exists: > > ZeroC Ice - http://www.zeroc.com/ice.html There are a bunch of very fancy and nice libraries out there to do RPC like things that support a variety of languages. Another one I am very fond of is ZeroMQ, but I think we should not start worrying about supporting such advanced and scalable libraries at this time. This is the reason why I stated at the beginning of the requirements that we should "so we will look at it as if it were running only on one central machine". The scalability issues will be dealt with once we have properly defined the problem scope. Making the node communication rely on Zero(C|MQ) can be something that we integrate without having to require clients to change their behavior. I think the overall feeling from the responses is that going for something like an HTTP RESTful API is what we are looking for. HTTP is a well understood technology and I have quite some experience in designing and building RESTful APIs based on twisted (cyclone) and this is also what is used in other [1] projects [2] belonging [3] to the [4] Tor community [5]. Moreover by looking at how the reporting systems of other network measurements tools worked [5] we found that almost all of them used an HTTP API to collect reports [6][7][8][9]. I see this as an indication that such a strategy is the best practice. For the time being we should go for something simple like this and once we encounter major scalability/performance bottlenecks we can quantify them and figure out what the best path to a solution may be. If you were the developer of a censorship detection tool would you like to have to report to anything that is not a RESTful HTTPs API? - Art. [1] https://github.com/mmaker/APAF [2] https://github.com/gsathya/pyonionoo [3] https://github.com/globaleaks/Tor2web-3.0 [4] https://github.com/globaleaks/GLBackend [5] https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionTools [6] https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionTools/Herdict#Howdoesthereportingsystemwork [7] https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionTools/Netalyzr#Howdoesthereportingsystemwork [8] https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionTools/NeuBot#Reportingsystem [9] https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionTools/ProjectBismark#Reportingsystem ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First five Tor tech reports
On Thu, Jul 12, 2012 at 6:12 AM, Karsten Loesing wrote: > here are the first five metrics tech reports that I'd like to turn into > Tor tech reports (see #5405 for the idea behind this). I'd like to offer some typographical improvements -- it looks like these are being generated with mostly default LaTeX settings, which are not great for PDFs that people will mostly read online. Some of the graphs are also very hard to read (dashed lines don't work very well for plots that jump up and down a lot). I see that there is a git repository for the sources, can I just clone it, make changes, and put the diffs somewhere? What would be most convenient for you? zw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First five Tor tech reports
On 7/18/12 5:12 PM, Zack Weinberg wrote: > On Thu, Jul 12, 2012 at 6:12 AM, Karsten Loesing > wrote: >> here are the first five metrics tech reports that I'd like to turn into >> Tor tech reports (see #5405 for the idea behind this). > > I'd like to offer some typographical improvements -- it looks like > these are being generated with mostly default LaTeX settings, which > are not great for PDFs that people will mostly read online. Oh, that would be very useful. Maybe we can come up with a template for all Tor tech reports. > Some of > the graphs are also very hard to read (dashed lines don't work very > well for plots that jump up and down a lot). Right. There's always the trade-off between using colored graphs which don't go well when printed and dashed/dotted lines which are at least equally useful on screen and on paper. I'm open to suggestions there. (Note that the graph sources are in a different Git repository than the LaTeX sources.) > I see that there is a git repository for the sources, can I just clone > it, make changes, and put the diffs somewhere? What would be most > convenient for you? I just committed the LaTeX sources of these reports very quickly to my new public tech-reports repository: https://gitweb.torproject.org/user/karsten/tech-reports.git If you can clone the branch and put yours somewhere from where I can pull, that would work best. git format-patch also works fine. Once reports are ready for "publication", I'll merge things into the official tech-reports.git repo. Thanks! Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Vidalia Report - Week 8
Last fortnight, I had got the add, remove and edit Hidden Service functionality working. I have been working on fixing a few UI issues - sizing, input sanity check and a browse button for selecting directory. I'm beginning work on the bandwidth scheduling plugin. I've been trying out the ways of doing it through relaybandwidthrate and will be starting on the UI. [1] https://github.com/feroze/vidalia-plugins/commits/hiddenservice ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2012 10:08 PM, Isis wrote: > On Mon 16 Jul 2012 at 02:15, thus spake Ondrej Mikle: >> On 07/15/2012 02:56 PM, Arturo Filastò wrote: >>> >>> # What properties we would like it to have note: these are not >>> ordered. * Efficient even over high latency networks. * Ease of >>> integration for third party developers. * Expandable to support >>> requirements of new tests we develop. * Anonymous * Secure > >> Even though you will probably not end up using this, it may be a good >> idea to know that it exists: > >> ZeroC Ice - http://www.zeroc.com/ice.html [...] > > Oh man. It's not Twisted, that's for sure. :) > > Though, it seems that much of Ice is redundant if we are already packaging > Twisted. Perhaps we could use their code as reference, and just write out > the methods we need in Twisted to avoid the extra dependency? If you are packaging/using Twisted, then yes, Ice is redundant (unless someone planned to differentiate "signaling" from "data" protocol, for example). >> It can optionally use TLS, interface definition for RPC and structures >> is written only once (each language binding then loads it and maps it to >> native object of its own as "usual" method calls or attributes). > >> Advanced features include asynchronous calls, at-most-once semantics (it >> can retry RPC call for methods that are marked "idempotent", i.e. whose >> multiple invocation is same as one invocation), persistence via Ice >> Freeze (might work for the file storage, not sure how big are your files, >> internally it's implemented on top of BerkeleyDB), forward/backward >> compatibility among versions of your API (up to a limit)... > > Becoming more convinced. Do you know off the top of your head which > protocol it uses? HTTP also, I would assume? At low-level, it has its own protocol, it's not HTTP (it actually won't work over HTTP). > Side note: What are we going to do for countries which block/monitor/MITM > SSL connections? If I'm not mistaken, hasn't it been the case that these > places have still allowed ssh? Should we have some sort of append-only > scp-like fallback? Does Ice have that? Unfortunately, there's no fallback in Ice for that (its firewall-evading also uses SSL/TLS which is not useful here). Maybe I misunderstood Arturo's requirement that said TLS or TorHS was considered for encrypted/authenticated transport. Ondrej -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJQB0TbAAoJEAy6xNgMZCEgyVUIAKpcZjXVqaxDFmtyYUlyonv8 snXCsW0IX93ywpP63SIpleTPAl3Yp4T7Ng6wZKjpMJ/N2xEo7o5GGHl9Z2YVnUyY Kgp6/FZPkHZv0PmDSVKANleJPTP+CR4LemkcezLiMnpSQ7kv7mIXpVsKbgTJ9B5L AFa/mWj/YCAJT8I108pteCLZDFEaDEdciM5Bl4Kp6hoiiouyDPRjF2/fC/YWVTfL DBmo6m8Wq3ZemlLW3At5dvYOct9gQgYyZgq8DWXVFzKx0JzfQ1rXoO4ovZFoLh7D fnVtjjSaWMOHhscdIS4zx5x9Q4J4QQtwyK0pKBnZwq6DF1J2FPuMxg/jP4v+UrE= =31rD -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/18/2012 04:46 PM, Arturo Filastò wrote: > On 7/16/12 2:15 AM, Ondrej Mikle wrote: >> On 07/15/2012 02:56 PM, Arturo Filastò wrote: >>> I would like to follow up on the discussion we had in Florence on some >>> design choices behind OONIB. >>> >>> In particular the most controversy was around using HTTP or rsync. >> [...] >> >>> # What properties we would like it to have note: these are not >>> ordered. >>> >>> * Efficient even over high latency networks. >>> >>> * Ease of integration for third party developers. >>> >>> * Expandable to support requirements of new tests we develop. >>> >>> * Anonymous >>> >>> * Secure >> Even though you will probably not end up using this, it may be a good >> idea to know that it exists: >> >> ZeroC Ice - http://www.zeroc.com/ice.html > > There are a bunch of very fancy and nice libraries out there to do RPC > like things that support a variety of languages. [...] > > Moreover by looking at how the reporting systems of other network > measurements tools worked [5] we found that almost all of them used an HTTP > API to collect reports [6][7][8][9]. I see this as an indication that such > a strategy is the best practice. Since it's already implemented, it's reasonable to keep it that way. > For the time being we should go for something simple like this and once we > encounter major scalability/performance bottlenecks we can quantify them > and figure out what the best path to a solution may be. Sure (though this transition is always PITA once it is necessary). > If you were the developer of a censorship detection tool would you like to > have to report to anything that is not a RESTful HTTPs API? Hmm, for some reason I remembered there was some debate on stateful requirements on the API but can't seem to find it. Ondrej -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJQB1IXAAoJEAy6xNgMZCEgWHgH/i2i+FPxco4xIsOeDLtbMO13 DZQ7iWTih9QGnSk+qk55BUGuzEzvAv2OAMECgD2KnM+VCDe/mHXNME/+87dZpd4s hwp5B9BrUmanAs75FSELOXUsMH3WGNn1hXls+rdgvcfweTyCs7+BOnkTkT5Ni/rl XHdyn1BQsNPfb3MIUc6ZsEWy45QoHXcJwPoaKdfCHaBsKV1WzD7+NeR9JAWUTJ1u pj0idqgUKJqgsxCnCr2r7DcgHg41wGci5cIENMVSraGHUb+Is94PRICXPunU/3Lz 3uiCmZ/9KPl20fVBQd/vhB4tHNdoXlIZw7NJELtwKgjONmneS0zUqJsMNasNU+Q= =1+b3 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
