- tor-dev - lists.torproject.org

Too many cooks spoil the broth---or: how about we clean up the wiki?
by Karsten Loesing 11 Jun '11

11 Jun '11

Hello everyone, <rant>Today I looked at our wiki to add roadmaps for some products and realized what a mess the wiki is. This wasn't obvious to me, because I stopped using the wiki long ago, well, because it was such a mess. But boy, it has become worse!</rant> I think the main problem is that there's no obvious structure in the wiki, so everyone just adds their stuff anywhere, maybe thinking that someone else will move it to the right place. The other problem is that there's no such person cleaning up. Here's my plan: I'd like to rename (possibly a lot of) wiki pages so that the naming scheme implies a kind of wiki structure. I'd also add a page saying where stuff should go, and we'll beat up everyone not adhering to the structure in a joint effort. By the way, what happens if we rename wiki pages? I guess Trac will update all internal links, but external links (e.g., from the website) will be broken? We could fix our own website, but other websites would still be broken. How bad would that be? Here's a suggested naming scheme. In this scheme, there are three top-level directories (or rather, page prefixes): - doc/ contains all documentation for Tor users, relay operators, and the community in general. This is the stuff that people would usually expect in a wiki. - org/ contains deliverables promised to our sponsors, meeting plans, product roadmaps, project progress, etc. This stuff is in the wiki to make Tor development as transparent as possible. In theory, non-developers wouldn't require write permissions to these pages. - trac/ contains Trac's own documentation that it generously dumped into our Tor wiki. In theory, nobody would require write permissions to these pages. I'll go through the existing wiki pages and say where they should go. The following pages would move to doc/ (e.g., "DNS Hijacking" would become "doc/DNS Hijacking"): DNS Hijacking HTTPSEverywhere/SSLObservatorySubmission ImportantGoogleChromeBugs OnionCat TorALaymansGuide TorFAQUnanswered TorInChroot TorToggle UsingTorWithVservers badRelays badRelays/trotskyIps talks talks/MoscowState2010 TheOnionRouter TheOnionRouter/AnonymousPublicSpeech TheOnionRouter/BIND TheOnionRouter/BandwidthLimitChangeController TheOnionRouter/BlockNonTorTrafficDebian TheOnionRouter/BlockingDiagnostics TheOnionRouter/BlockingIrc TheOnionRouter/CentralizedTorServer TheOnionRouter/ConnectOverSSH TheOnionRouter/ContestEntries TheOnionRouter/ContestEntries/DesignFeedback TheOnionRouter/CronBandwidthLimit TheOnionRouter/DebianLive TheOnionRouter/EmbeddedTips TheOnionRouter/ExitEnclave TheOnionRouter/FAQUnanswered TheOnionRouter/FireFoxTorPerf TheOnionRouter/FirefoxRemoteDNS TheOnionRouter/GoodBadISPs TheOnionRouter/Gsoc2009 TheOnionRouter/Gsoc2009/ThandyTorrents TheOnionRouter/HiddenServiceNames TheOnionRouter/HowTo_post_on_or-talk_mailinglist TheOnionRouter/LegalStuff TheOnionRouter/LiveCDBestPractices TheOnionRouter/MacOSXUpgradeToTrunk TheOnionRouter/OpenbsdChrootedTor TheOnionRouter/OpenbsdChrootedTorControlScript TheOnionRouter/OpenbsdChrootedTorScript TheOnionRouter/OperationalSecurity TheOnionRouter/Portable_Tor TheOnionRouter/PreventingDnsLeaksInTor TheOnionRouter/Preventing_Tor_DNS_Leaks TheOnionRouter/PrivoxyConfig TheOnionRouter/PrivoxyPatches TheOnionRouter/Publicfile TheOnionRouter/ReducedExitPolicy TheOnionRouter/RemailingAndTor TheOnionRouter/RunTwoPrivoxys TheOnionRouter/SshPortForwardedTor TheOnionRouter/SummerOfCode TheOnionRouter/SupportPrograms TheOnionRouter/SupportPrograms/Polipo TheOnionRouter/TSocksPatches TheOnionRouter/TermsObserved TheOnionRouter/TorAbuseTemplates TheOnionRouter/TorExitNodeHowto TheOnionRouter/TorGuideUniversities TheOnionRouter/TorInChroot TheOnionRouter/TorInChroot-new TheOnionRouter/TorInTheMedia TheOnionRouter/TorMirror TheOnionRouter/TorOnDebian/PackagesForArchitectures TheOnionRouter/TorShirt TheOnionRouter/TorWin32TorWS TheOnionRouter/TorALaymansGuide TheOnionRouter/TorDNSExitList TheOnionRouter/TorFAQ TheOnionRouter/TorIPCOP TheOnionRouter/TorifyHOWTO TheOnionRouter/TorifyHOWTO/EMail TheOnionRouter/TorifyHOWTO/FTP TheOnionRouter/TorifyHOWTO/InstantMessaging TheOnionRouter/TorifyHOWTO/IrcSilc TheOnionRouter/TorifyHOWTO/Misc TheOnionRouter/TorifyHOWTO/Misc/Putty TheOnionRouter/TorifyHOWTO/Putty TheOnionRouter/TorifyHOWTO/SystracePolicy TheOnionRouter/TorifyHOWTO/WebBrowsers TheOnionRouter/Torouter TheOnionRouter/Torouter_notes TheOnionRouter/Torwin32DNS TheOnionRouter/Transocks TheOnionRouter/TransocksifyingTor TheOnionRouter/TransparentProxy TheOnionRouter/VMWareThroughTor TheOnionRouter/VerifyingSignatures TheOnionRouter/WebProxyHowto TheOnionRouter/Wikipedia TheOnionRouter/WindowsBufferProblems CodingForTor CodingForTor/CodingInC CodingForTor/CodingInR CodingForTor/LoggingAndDocumentation CodingInC CoreTorTracUsers build build/AddingBuildSlaves build/BuildSignoff build/ListOfPackages dev/HowToReleaseTor dev/SupportPolicy dev/SupportPolicy_v2 The following pages would move to org/meetings/: 2010TorAnnualDevMeeting 2011MiniDevMeeting 2011MiniDevMeeting/notes 2011StockholmHackfest 2011TorAnnualDevMeeting The product roadmaps that are not there yet would go into org/roadmaps/. Everything related to project management would go into org/projects/: TorAgileProcess projects/HowWeDoProjectManagement projects/ProjMgt/SetUpProjectMgt Products projects/ProductsandAssignments projects projects/2009FinancialandComplianceAudit projects/BridgeDB projects/CalculateDirreqShares projects/EmailAutoResponder projects/ExperimentalBridgeBundles projects/Infrastructure projects/Metrics projects/Metrics/DesignAndDeployDescriptorDatabase projects/Metrics/ImproveMetricsPortal projects/Metrics/PublishMetricsDataAndTools projects/Metrics/SafelyCountClients projects/Thandy projects/Tor projects/TorBrowserBundle projects/TorBrowserBundle/Alpha projects/TorBrowserBundle/OSX projects/TorBrowserBundle/OSX/Security projects/TorBulkExitlist projects/TorButton projects/TorCheck projects/TorFlow projects/TorStatus projects/Tor/MultithreadedCrypto projects/Weather projects/arm projects/mirror projects/mirror/torrent projects/vidalia The deliverables promised to our sponsors would go into org/sponsors/: sponsors sponsors/SponsorA sponsors/SponsorB sponsors/SponsorD sponsors/SponsorD/December2010 sponsors/SponsorD/June2011 sponsors/SponsorD/March2011 sponsors/SponsorD/September2010 sponsors/SponsorE sponsors/SponsorE/PhaseOne sponsors/SponsorF sponsors/SponsorF/Year1 And finally, the following pages are about using Trac and would go into trac/ (it's possible that Trac wouldn't like us renaming some of its pages, but I guess we'll find out): InterTrac InterWiki RecentChanges TitleIndex TracAccessibility TracAdmin TracBackup TracBrowser TracCgi TracChangeset TracEnvironment TracFastCgi TracFineGrainedPermissions TracGuide TracImport TracIni TracInstall TracInterfaceCustomization TracLinks TracLogging TracModPython TracModWSGI TracNavigation TracNotification TracPermissions TracPlugins TracQuery TracReports TracRevisionLog TracRoadmap TracRss TracSearch TracStandalone TracSupport TracSyntaxColoring TracTickets TracTicketsCustomFields TracTimeline TracUnicode TracUpgrade TracWiki TracWorkflow WikiDeletePage WikiFormatting WikiHtml WikiMacros WikiNewPage WikiPageNames WikiProcessors WikiRestructuredText WikiRestructuredTextLinks WikiStart That's it. I realize there are lots of cooks on this list, so I expect there will be feedback. Thanks, Karsten

4 8

Re: [tor-dev] Tor and BGP integration
by Arturo 09 Jun '11

09 Jun '11

Hello, This seems to me like a really neat idea! Reading from real time BGP feeds is not a simple task and I think it might be a bit of an overhead for the average Tor user. On the other hand it could be a good idea to have some nodes run tools to generate exit policies or at least provide BGP routing information in a easy to consume format for the tor clients to use. I have been doing some experimenting on getting and analysing BGP information and these are the resources that I have found useful: - http://archive.routeviews.org/ - For getting raw MRT format BGP feeds and also the output of `bgp show ip` - http://www-01.pch.net/resources/data/routing-tables/archive/2011/ - Routing information from other "probes" - https://github.com/hellais/PyRT - A quick patch I made to make PyRT work on python > 2.3 (useful for parsing MRT format files), original: https://research.sprintlabs.com/pyrt/ IXPs: - http://www.pch.net/resources/data/routing-tables/looking-glass/ - https://www.peeringdb.com/private/index.php - Very complete database on peers and ASN information. They also provide a very nice API for interacting with their database. I have been working on some python code for adding BGP support to blockfinder. It basically just parses the results of the `bgp show ip` command outputs obtainable from route views and stores the routing paths inside a database. It needs to be cleaned up a bit, but if you are interested in using it I can hack on it some more. Let me know of the progress you make :) - Arturo `hellais` > Hello from Iceland, > > Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference > and this idea is the result of a bit of feedback from some network operators > here. > > Tor needs a way to be friendly to large network operators who wish to enable > exiting to anonymous communication for their networks. These network > operators are happy to allow anyone to pass traffic to their relays as entry > nodes, middle nodes and even limited exit nodes. > > Linus and I have been discussing methods of automating this process and of > course BGP integration makes a lot of sense. Generally, a network operator > has a set of AS numbers for their network blocks and as they want people to > connect to many of their services, it helps quite a bit to allow exiting to > those services from their own Tor relays. > > We came up with two main ideas for making this happen. > > One method would be to write a program where given an AS number and a BGP > feed, we parse all of the advertised network blocks and emit exit policy > lines that accepts all traffic for the AS. This would allow for a web > service similar to BulkExitList.py for network aware exit policy generation > and relay operators would simply need to add this to their Tor configs > manually. For mostly static networks, a cronjob would be fine and Tor > doesn't need to know about AS numbers internally. > > Another method would be to write a controller that watches for BGP network > updates and Tor would add relevant exit policy lines for any configured AS. > This would allow any Tor relay to dynamically learn about network changes if > it has access to a BGP feed patched into a controller. This could be > implemented by adding some configuration options to Tor that let Tor know > which AS numbers matter to which router. It may also allow for the router to > auto learn it's own likely family network but it lacks any kind of > bi-directional confirmation, still it seems useful information to have... > > It would be fantastic if someone offered a hidden service NORDUNet BGPMon > feed. This would help enable the first method of generating network aware > exit policies; this would also help with the development of AS awareness in > Tor itself. In the future, I imagine that it makes a lot of sense for > circuit building to be BGP aware as mere netblocks will not be very useful > in an ipv6 world, they're already mostly irrelevant. > > Anyway, food for thought. Linus and I will probably hack on some of these > ideas in the near future. > > All the best, > Jake

1 0

[Patch] common/procmon.c
by Gisle Vanem 02 Jun '11

02 Jun '11

Hi list! I've been staring at this file for some time trying to find the elusive compile-error (MingW-gcc v4.50) on Win_XP). The bug was a missing comma (!) and a typo ('err_msg' at line 277 changed to 'err_msg'). I've also changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? --- Git-latest\src\common\procmon.c Thu May 26 19:30:24 2011 +++ common/procmon.c Tue May 31 22:54:14 2011 @@ -252,7 +252,7 @@ if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else ------------- Sorry, no git patch. I'm a git newbie. Gisle V.

2 1

[PATCH] Signed-off-by: Gisle <gvanem@broadpark.no>
by Gisle 01 Jun '11

01 Jun '11

An elusive compile-error (MingW-gcc v4.50 on Win_XP); a missing comma (!) and a typo ('err_msg' at line 277 changed to 'errmsg'). Aso changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? Btw. This is my 1st ever 'git commit', so it better work. --- src/common/procmon.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/common/procmon.c b/src/common/procmon.c index 8fcc1af..5c10e9a 100644 --- a/src/common/procmon.c +++ b/src/common/procmon.c @@ -252,7 +252,7 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else -- 1.7.0.2.msysgit.0

2 1

Control-port circuit event/status format
by Robert Ransom 01 Jun '11

01 Jun '11

Subject: Control-port circuit event/status format Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit event to all controllers that send ‘SETEVENTS CIRC’ to Tor? Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit state in response to a ‘GETINFO circuit-status’ control-port command? Robert Ransom

1 0

Code Review (arm) - Initial commit for the menu code
by Damian Johnson 28 May '11

28 May '11

Hi all. Kamran and I are gonna doing code reviews publicly so if you're interested and spot issues we miss then feel free to chime in. -Damian Change: https://gitweb.torproject.org/user/krkhan/arm.git/commitdiff/5fd9b5f74a86eb… > ARM_CONTROLLER = Controller(stdscr, stickyPanels, pagePanels, menu) What sort of persistent state will the menu require? If we can make it a popup function (like "showHelpPopup()") that would be preferable (less parameter juggling). But if you expect it to remember something between menu requests then this makes sense. > menu.draw() Maybe rename this to "showMenu()"? The draw method is part of panel which threw me off a bit. > self._rootEntry = (entry and isinstance(entry, ParentEntry)) and entry or DEFAULT_ROOT Interesting pattern, but it's kinda hard to read (or make sense of unless you've seen it before). Maybe something a little less compact would be clearer? if entry and isinstance(entry, ParentEntry): self._rootEntry = entry else: self._rootEntry = DEFAULT_ROOT > titles = map(attrgetter('title'), self._rootEntry.children) This took me a couple minutes with the interactive interpretor to make sense of too. Maybe list comprehension instead of the attrgetter would help? titles = [menuItem.title for menuItem in self._rootEntry.children] > titlewidth = max(map(lambda title: len(title), titles)) + 2 Neat. Honestly I'm greener than I should be with lamdas. The pattern I'd use for this is... titlewidth = max([len(entry) for entry in titles]) + 2 but up to you. The later is more familiar to me but I'm not sure which can claim the best readability. > # total number of titles that can be printed in current width Why are you giving all titles equal distance? Does this make it look better? I'd assume that would be best to have dynamic widths, leaving some entries unprinted if we run out of room (this is done all around so I can get you an example if you'd like). I'm thrilled you're taking variable screen sizes into account! > titleformat = curses.A_NORMAL > > if index == self._selection[0]: > titleformat = curses.A_STANDOUT Alternative option... titleformat = curses.A_STANDOUT if index == self._selection[0] else curses.A_NORMAL > popup.win.addch(top, left, curses.ACS_VLINE) > popup.win.addstr(top, left, entry.title.center(titlewidth), titleformat) > popup.win.addch(top, left, curses.ACS_VLINE) Noooooooo! Don't do this! If you can help it _never_ draw to the raw curses window. If this ever attempts to draw outside the curses window it will crash. The panel class has safe proxies for everything that you should need. In this case... popup.addch(top, left, curses.ACS_VLINE) popup.addstr(top, left, entry.title.center(titlewidth), titleformat) popup.addch(top, left, curses.ACS_VLINE) will do the same. There's, of course, exceptions like popup.win.box() and popup.win.refresh() (those are safe). > DEFAULT_ROOT = ParentEntry(title="Root", children=( I've been defining constants outside of classes so they can be easier to spot at the top of files. However, this is just a stylistic preference of mine - if you prefer constants to be a class attribute then that's fine. > for index in self._selection: > if isinstance(entry, ParentEntry): > entry = entry.children[index] > else: > break > > if isinstance(entry, LeafEntry): > entry.callback(entry) It looks like if self._selection is an invalid path you do nothing? Maybe we should log something or raise an exception... Your usage of named tuples and index lists will, I think, make this harder and more confusing than it needs to be. Instead I'd suggest a MenuItem class that has... getLabel() -> text for the option isLeaf() -> boolean for if we're a leaf or not getSubmenu() -> returns a list of MenuItems below it - either an empty list or None if a leaf node (whatever makes most sense to you) getParent() -> parent MenuItem next(), prev() -> returns a MenuItem instance for the next or previous option for the menu list we're in select() -> event handler Constructing the menu will be a little more interesting, but rendering it, navigation, and selection will all become trivial. It'll also avoid the situation where _selection is out of sync with _rootEntry (for that matter, we wouldn't need a rootEntry...).

2 2

was my LDAP account ever setup?
by Nathan Freitas 25 May '11

25 May '11

Seems like this ticket is still open: https://trac.torproject.org/projects/tor/ticket/3068 and I am problems like this: git remote add public ssh://git-rw.torproject.org/n8fr8/orbot git push public master Permission denied (publickey). fatal: The remote end hung up unexpectedly thx!

1 0

Re: [tor-dev] arm - new identity ...
by Damian Johnson 23 May '11

23 May '11

Hi Dominik. Sounds good, we should keep this simple (at least for the first version) so lets go with #2 and #3. Developing this should be pretty straight forward... 1. Add "sendNewnym", "isNewnymAvailable", and "getNewnymWait" methods to 'src/util/torTools.py'. All of these should be very easy. 2. Add a handler for sending a newnym in 'src/cli/headerPanel.py'. This is done by overwriting the "handleKey(self, key)" method - for an example see just about any of the other panels. I'm currently working on another feature for the header panel (reattaching to tor instances) so there might be a handler here by the time you start. I'm fine with F5. From the curses documentation it sounds like you can compare the keycode to the curses.KEY_F5 constant. 3. Adding the newnym to the header panel - this will be the hardest part (but still not too difficult). This will only be visible when we're a non-relay, and involves filling in... https://gitweb.torproject.org/arm.git/blob/HEAD:/src/cli/headerPanel.py#l259 Normally this could say something like "Press F5 for a new identity", then after they send a newnym instead display "Building circuits (newnym signal unavailable for X seconds)". 4. Coordinate with Kamran for the menu option. Maybe we want to somehow make it disabled while sending a newnym is unavailable? > - mumble with krkhan (and you?) I'm looking forward to it. We should be able to set this up next week. Cheers! -Damian On Mon, May 23, 2011 at 7:04 AM, dominik <d.schuetzdeller(a)gmx.de> wrote: > hello atagar, > im sorry for not sending this email yesterday. my vserver hoster has reset > the wrong vserver and caused some trouble =( > ... anyway > > i had 3 ideas realizing this: > 1. build a new "page" > that page should contain possibilities for adding nodes to use (entry or > bridges, relay and exit). it should also contain > some informations about flags from that nodes; especially if that node is > a known bad node. there should also be a > new identity button. > 2. implement it within the menues krkhan is working on > as i now heard krkhan is working on a menu, what would be the best and > user friendliest way for implementing the > stuff in there and create some masks for the according informations to be > put in there. > 3. using a hotkey for some things like "new identity" > first of all i thought about using the "f5"-button as a hotkey for using > new circuits. i like the idea of using the same hotkey > as it is used in the browser. > that new identity thing how ever needs to have a check whether the node > where it runs on is a client or some other thing. > > ok... before you are going to ask how i am going further - this is what my > todo list says: > - delete torsh from monitoring programs in the thesis > - describe whether there is a magical setup for nagios for ~6 different > nodes or not ... > - describe and edit features for arm > - search an elegant way for recreating a new circuit in pytorctl > - mumble with krkhan (and you?) > - based on the things said i am going to begin implementations (from > saturday on fulltime) > > after all my decision of working on arm after my thesis still is the same... > even if python3 has a weird utf8 handling. > i will also work on torsh as a fun project > > best regards > dominik > > > > > > >

1 0

Re: [tor-dev] [tor-commits] [tor/maint-0.2.2] The first argument for a libevent callback should be evutil_socket_t
by Robert Ransom 23 May '11

23 May '11

On Mon, 23 May 2011 05:18:07 +0000 (UTC) nickm(a)torproject.org wrote: > commit 1e69c60dccc358a7146c2b5e7825ea729498b41b > Author: Nick Mathewson <nickm(a)torproject.org> > Date: Mon May 23 01:12:00 2011 -0400 > > The first argument for a libevent callback should be evutil_socket_t > --- > src/common/procmon.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/common/procmon.c b/src/common/procmon.c > index cee956a..bd25bc1 100644 > --- a/src/common/procmon.c > +++ b/src/common/procmon.c > @@ -34,7 +34,7 @@ typedef int pid_t; > /* Currently we need to poll in some way on all systems. */ > > #ifdef PROCMON_POLLS > -static void tor_process_monitor_poll_cb(int unused1, short unused2, > +static void tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, > void *procmon_); This will break the build on libevent 1.x systems (until you merge your bug3270 branch that #defines evutil_socket_t on such systems). Robert Ransom

1 0

Tor meets real users
by Andrew Lewman 19 May '11

19 May '11

A short while ago, I did a training for some activists from a country that is hostile to the Internet. These people were some of the more technical people from their community. There was a mix of Windows and OS X laptops in the session. English was their third language, for added fun. I walked them through finding tor browser bundle, downloading it, verifying it, unzipping it, and starting it. Here was the first problem. They couldn't find tbb on the download page. Their comments were that all these files and releases on the page were confusing. They wanted just one thing to look at, pick their operating system, and go. And they wanted the one thing to automatically detect their language preferences for tbb. I ended up pointing them at tpo/torbrowser, which they also thought was confusing. The aforementioned desires weren't satisfied on this page, but at least they could find their preferred language. They all commented that back home, a 24MB file was too big, and can't they get it via bittorrent or some other piecemeal way? A 24mb file would take hours to download. Once they finally downloaded it, they all double clicked on their resulting zip file. In fact, all of the mac people ended up downloading the windows tbb and unzipped it correctly. In all cases, their operating system handled the zip file correctly. After fixing the mac people with mac tbb, we moved on to the next step. None of them had pgp installed, and therefore no way to verify the .asc and zip file. Most of them figured out to click inside the resulting folder and start the 'start tor browser' program. For all of the macs, the tbb didn't start. The people had to restart the system and then clicking on 'start tor browser' worked as expected. As tbb was starting up, nearly all of them clicked on 'start tor browser' one to three times more, because they didn't see anything starting up. In fact, it was starting, it just wasn't instantaneous. I worry about forcing a splash screen that announces "I'm using Tor!" on the screen, but at the same time, it would let users know that tbb is starting. Once vidalia started, no one waited for tbb firefox to start, but rather started their own browser and tried to use it. Once tbb firefox started up, in some cases, minutes later, they were confused. Why didn't tbb firefox start right away instead of this useless vidalia control panel? A few of them felt the need to explore the vidalia control panel since we showed it to them. As if to say, 'there are buttons you are showing me, I just click and explore.' Once tbb firefox started, they were ok with using firefox over tor just fine. The first thing many of them did was to login to facebook or gmail over tor to see if it was different. None of them verified the ssl cert presented for facebook or gmail logins. For those that did login to gmail, gchat didn't work due to the lack of Flash in tbb firefox. We then tried to configure their chat clients for tor. Adium on the mac was fairly easy. The variety of clients on windows wasn't so easy. A few wondered about logging in over ssl, but never did because the services didn't offer it (aol, msn, gchat). I showed the windows people pidgin, but they liked their native apps and didn't see why one multi-protocol app was better. The experience continued through pidgin with OTR, installing pgp for email and verifying files, and a general talk about openssl certificates, what they mean, and what verification of a cert entails. The relevant tor experience was what I wanted to communicate and for us to start thinking through ways to address it. Perhaps Mike's desire for a anonymous browser is a correct path for usability and better anonymity for the user. I believe torfox and torora have both come to the same conclusion (at different times) as well. -- Andrew pgp 0x74ED336B

6 8