tbb-dev May 2014

tbb-dev@lists.torproject.org

7 participants
2 discussions

Current thoughts on tb-manual presentation
by Matt Pagan 30 May '14

30 May '14

Hello tbb-devs. Here are a few divergent thoughts on presenting the Tor Browser manual in a sensible manner for Tor Browser users. Please provide feedback regarding whether any of these seem reasonable/feasible. &&&&&& 0) Include a pdf file in an easy to locate place in the Tor Browser directory. Con: As discussed a couble IRC meetings ago, the major obstacle here is that most Mac users do not know how to turn their Tor Browser app into a directory, and so they would never see it. Not so good. 1) Replace the help desk email label in tor-launcher with a button, which, when clicked, tells the user's system to open a local pdf file with the system's default pdf viewer. A con to this approach is that I don't know if it is even possible at all; that is, I'm not sure if JS is capable of detecting what the default application for a filetype is or, if it's not, I'm not sure it's capable of just "opening a file" that needs to be opened with a specific, local application. 2) The same as 1) but ship evince with Tor Browser and onClick, open a pdf file with something like an `evince tb-manual.pdf` command. A con to this approach would be that this might not work at all for various non-Gnome GNU/Linux users. Also the Tor Browser is that much bigger. 3) Replace the help desk email label in tor-launcher with a button, which, when clicked, opens a XUL window (like window.open) that contains nothing but an iFrame which loads the the local index.html file (from which the user can then navigate to all the other html pages because of the manual's design) con: ??. This seems like a pretty possible thing to do right now. Is it? I could not actually get my implementation of this idea even close to working, but I also introduced a lot of new moving parts at once, and I'm still getting the hang of debugging. This seems like it would be the most user-friendly workflow of these various approaches. 4) Make the Tor Browser manual prominently available for download on the Tor Browser download page as a pdf. cons: Now users have two things to verify to make sure they didn't just download malware. Who's really going to do that for a pdf file, anyway? I think most users are quite used to a download being one thing, and not two (or three). I'm not sure it's reasonable to expect that all users will download a separate manual. This is not a great workflow. Users could just open the pdf file in the browser they used to download Tor Browser, though. 5) Direct users to https://tb-manual.torproject.org/, which weasel just set up. This could either be done from the download page or a non-wired link in tor-launcher. cons: I think fewer users would actually see the manual this way, and this distribution method would probably be less effective at reducing load on the help desk for similar reasons to 4). We've had the the Short User Manual on our web infrastructure for some time and most users do not know it exists. Although maybe that was an advertising problem? ****** I'm not a huge fan of 4) or 5), as they don't actually solve the problem of distributing a manual with Tor Browser. I've included them for completeness, nonetheless. Also there are probably ways of getting the tor browser manual in the hands of users that I'm not thinking of. Any other ideas? Do you like any of the above ideas? The relevant ticket here is https://trac.torproject.org/projects/tor/ticket/11698 -- Matt Pagan PGP: 0xE9284418E360583C

6 20

Looking at tor browser connections
by Nicolas Vigier 16 May '14

16 May '14

Hello, While discussing during the IRC meeting last friday about mbox integration in the tests suite to monitor connections made by the tor browser, we noticed that it opens 2 connections to the dns server, and 2 to the default tor socks port even when it is set to an other port with the TOR_SOCKS_PORT environment variable: https://people.torproject.org/~boklm/tmp/tests/r/4mrXwR46_6/tor-browser-lin… So I have been looking at why it is doing this. I have been looking at the browser source code to understand why it does a dns request to resolve the hostname of the machine, and found this: https://gitweb.torproject.org/tor-browser.git/blob/90a58a42063dcd56e2943565… Before starting the browser it wants to create a lock file in the profile directory, which is a symlink pointing to the IP of the machine, so this is probably the reason why it's doing a dns request. Adding the hostname in /etc/hosts fixed the problem. Or for distributions that use libnss_myhostname (such as Fedora 20), editing /etc/nsswitch.conf to move 'myhostname' first on the hosts line. For the connections on port 9150, here is how to reproduce it: $ tar xvf tor-browser-linux64-3.6.1_en-US.tar.xz $ cd tor-browser_en-US $ sed -i s/9150/9550/ Data/Tor/torrc-defaults $ export TOR_SOCKS_PORT=9550 $ ./start-tor-browser Running 'tcpdump -i lo port 9150' in an other shell at the same time shows some connections on this port. Looking with wireshark shows that it is a connection to check.torproject.org. It only happens with a new profile on the first run (when Data/Browser/profile.default/prefs.js has not been created yet). If I create a file Data/Browser/profile.default/prefs.js to define extensions.torbutton.socks_port, there is no connection to port 9150:

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev May 2014