March 2014 - tbb-dev - lists.torproject.org

Tor unexpectedly exited
by Matt Pagan 29 Mar '14

29 Mar '14

Even though I missed the IRC meeting today (sorry), I wanted to share that there has been a noticeable increase lately in support requests regarding a "Tor unexpectedly exited. Please restart the application." message. Users will get this message over and over when trying to start their Tor Browser. At least some of these folks are already familiar with Tor Browser ("It worked fine before"). As a response, we will usually tell users to delete their current Tor Browser and download the Tor Browser again, which seems to usually clear up the issue. I have not opened a new ticket for this issue. -- Matt Pagan matt(a)pagan.io PGP: 0xE9284418E360583C

2 2

Tor Browser version strategy
by Mark Smith 26 Mar '14

26 Mar '14

Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc. Why consider making this change? Because doing so would allow us to greatly simplify the patches needed for bug #4234 (Use Firefox updater). For the Firefox updater to work correctly, it needs to be able to check the version of an advertised update against the version of the software that is currently installed. At the same time, for add-on compatibility the browser version itself must be close to that of the Firefox release it is based on. We already have patches for #4234 that modify our Firefox build process to pass the TBB version through and use it inside all of the updater-related code (and to use the 24.x Firefox version when we need to do so). However, the patches are messy and I don't think Mozilla could ever accept them; Mozilla has no need for a bundle version that is separate from the Firefox version. If we used a version number for TBB that was close to the Firefox version number, we would not need to patch anything; we would just use our version number as THE version number. Doing this would also allow us to eliminate the torbrowser.version hidden preference. And it might help end-users who want to figure out what version of Firefox the Tor Browser is based on. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

4 7

structure TBB more like Firefox?
by Mark Smith 26 Mar '14

26 Mar '14

Mike made a comment here: https://trac.torproject.org/projects/tor/ticket/6457#comment:9 that caused Kathy and me to do some more thinking about the TBB package structure and how we can simplify the patches required for #4234 (Use Firefox updater). The purpose of this message is to get input from everyone. The question: Should we change TBB so it it structured on disk just like Firefox? In other words, can we pull the Firefox ("Browser") directory up to the top of our package? This would provide several advantages: + The patches for #4234 (Use Firefox updater) would be much smaller, which means maintenance would be easier, Mozilla would be more likely to accept the small patches we would be left with, and so on. This would be a *huge* win and it is the main reason we are asking this question. + Bugs such as #6457 (Mac dock icon problems) would disappear. + The TBB package would look less like a bundle and more like a browser that is based on Firefox. There are also some challenges that stopped us from doing this last fall. The RelativeLink wrappers perform some useful functions and it may be difficult to eliminate them entirely. Our current thinking is that we could adopt a slightly different approach for each operating system: - On Mac OS, Kathy and I think we can keep the wrapper script but eliminate the nested .app structure. This should solve the dock icon problems. The main reason we need the wrapper is to ensure that -no-remote is passed to firefox (we do not want someone to try to open TBB and have a new Firefox window open up instead, just because they happen to have Firefox running). Even if we don't make changes for Linux and Windows, it probably makes sense to do so for Mac OS since the package innards are mostly hidden from users. - On Linux, we can keep the wrapper script but move it down into the Firefox ("Browser") directory. To keep end-users from being overwhelmed by all of the files that are in the firefox directory directory, we could provide a symlink at the top and use a structure that looks like this: tor_browser_en_US/ start-tor-browser@ (symlink to Browser/start-tor-browser) Browser/ (Firefox directory) Browser/start-tor-browser (wrapper script) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox (executable) ... Note that the Firefox updater would not be able to touch anything above the Browser directory, so we can't put anything above that point that we will EVER need to update. But we can probably get away with using one symlink. - On Windows, like Linux, we have the problem of not wanting to overwhelm end-users by showing them a folder with a bunch of files in it and hoping they will locate and open the one named firefox.exe (a challenging task, given that they just installed a package named "Tor Browser"). But we could use a structure similar to what I proposed above for Linux; our Windows installer could create a shortcut that includes -no-remote, e.g., Tor Browser/ Start Tor Browser.lnk (installer-generated shortcut) Browser/ (Firefox directory) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox.exe ... If, someday, we provide a .zip package on Windows, users of it will need to create their own shortcut or they will need to find and open firefox.exe (but that means they may not neglect to include the -no-remote flag). A side note is that we do not need -no-remote if we are willing to change the Tor Browser to look like a different application (compare to Firefox), i.e., register a different window class on Windows, use a different creator code on Mac OS, etc. But there may be reasons we do not want to be different from Firefox in that way. Opinions on all of the above? Pitfalls? This change will be disruptive to developers, support people, and end-users but the long term benefits might make it worth doing. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

2 2

Tor Browser Weekly IRC meetings moved to 18:00 UTC Fridays
by Mike Perry 20 Mar '14

20 Mar '14

Due to the US Daylight Savings Time changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 18:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, March 21st. We will be snuggling up next to the Huggable^W Pluggable Transports team meeting, which is just before us at 17:00 UTC on alternating Fridays. Their next meeting is March 28th. The hope is that this will help us to work closer with them to polish up the new unified PT-enabled Tor Browser, add new transport types, and otherwise generate PLUR (yeah, I said it). For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html P.S. We may have to revisit this time again when the EU switches to "Summer Time" on March 30th. Running an hour later in the EU may start to run into people's Friday evening plans, but we'll cross that bridge once it starts burning. -- Mike Perry

1 0

Re: [tbb-dev] Collapsing TBB components on Trac
by Roger Dingledine 17 Mar '14

17 Mar '14

[Sorry for breaking threading; just joined the list and couldn't find an In-reply-to header to use to fake it.] I see the thread is mostly quiet, and it would be great for it to go somewhere, so let me jump in with my own colors for the bike shed. Geko said: > Erinn Clark said: > > - Firefox Patch Issues > > agreed. Agreed. > > - Quality Assurance and Testing(?) > > I wonder if that one really fits here (in the long run!?) as it is > probably meant as a component which covers the QA and testing of all the > (sub) projects we (The Tor Project) have. At least that is my impression > when I look at > https://people.torproject.org/~boklm/automation/tor-automation-review.html > Sure, the TBB is probably the most important one but there are other > projects outlined that are, if at all, only loosely related to it. I think this one should probably stay separate, and hopefully in the future it will grow to be larger and more diverse. > > - TIMB > > Hmm... Not sure what currently is or will be tracked with this component > but that's a different bundle which does not have Firefox patch issues > and does not have Torbutton. So, I am wondering if there is so much > overlapping here. Maybe we can start without it and see how it goes? And this one should stay separate too, since it is specifically not Tor Browser Bundle. > > - Tor Launcher > > Mmmm... I think I'd want to start with it included: TBB is currently the > only one using Tor Launcher. We might want to evaluate this decision > later if we have other bundles using it. Maybe there are not so many > additional things they need to merit an own Tor Launcher component as we > currently have and we could keep it in the tbb-bugs component? Tough one. You will be unhappy either way here. On the theory that Tor Launcher is used by an increasing number of projects that aren't TBB (Tails, TIMB, maybe Torbirdy), I'd be inclined to keep it separate. > > - Tor bundles/installation > > Agreed. This is the most important one to do something about. > > - TorBrowserButton > > Agreed. Yep. Why not Torbutton while we're at it? I guess more broadly, the Torbutton component should be triaged and then lit on fire. > While it is good to fold them into one component to send notifications > to a list, I don't want to miss the ability to search for specific > "subcomponents". Not sure whether there is a good way to do that with > Trac. We (at least I) currently use keywords e.g. for it (see the > "gitian" keyword as example) which kind of works. I can live with that > but am not sure if it is still usable when we only have one big > component (and a lot of keywords). We faced exactly this situation with the 'Tor' component -- we've adopted the unofficial policy of adding keywords tor-client, tor-relay, tor-hs, tor-auth, etc to help people who liked the old "many components" model. But we're slowly finding that we don't need to do that anymore. > > 2. Pick a time and method to begin collapsing things, which will inevitably > > (and IMO necessarily) involve huge amounts of triaging. Yay. --Roger

2 1

PoC of using Mallard for the Tor Browser User Manual
by Lunar 12 Mar '14

12 Mar '14

Hi! On #11124 [1], you will find a proof-of-concept of using Mallard [2] to create the future Tor Browser User Manual. I really like it. It would be great to have an opinion of the TBB team. [1]: https://bugs.torproject.org/11124 [2]: http://projectmallard.org/ -- Lunar <lunar(a)torproject.org>

3 4

How much the Tor Browser is still a Bundle?
by Lunar 12 Mar '14

12 Mar '14

Hi! We usually call Tor's flagship product the “Tor Browser Bundle”. But since Tor Browser 3 and our departure from Vidalia, I'm having a harder time going on calling it a “bundle”. This is really obvious with the Mac OS X version, where users now interact with only a single icon, called “Tor Browser”. One concrete example is the logo and the wording that is visible in the configuration wizard. The logo says “Tor Browser Bundle” and the text right next to it says “Before the Tor Browser Bundle tries…”. Couldn't we just drop the “Bundle” here? For another small unconsistency, the wizard window title is “Tor Network Settings”. (Also, “bundle” is super painful to translate properly in French… but that's a side effect.) -- Lunar <lunar(a)torproject.org>

5 13

Collapsing TBB components on Trac
by Erinn Clark 03 Mar '14

03 Mar '14

Hello everyone! During the dev meeting we had many interesting discussions and agreements about how to proceed as the ultimate TBB dev team. One of them involved collapsing as many components as possible into a single Tor Browser Bundle component on Trac. To this end, we have a new mailing list called tbb-bugs[1] and I've created a Trac user called tbb-team which has tbb-bugs(a)lists.torproject.org as its email address. The idea is to have the huge component have its owner as tbb-team, so that we are able to see all of the bugs assigned to it via the mailing list and then assign the bugs to individuals as needed. We will revisit this topic at the next dev meeting in June to see if it's working out and, if not, figure out a different solution. We need to make a few decisions and commit to a few actions now: 1. Which components do we collapse into the huge TBB component? Here's a list of all of the current Trac components that are candidates: - Firefox Patch Issues - Quality Assurance and Testing(?) - TIMB - Tor Launcher - Tor bundles/installation - TorBrowserButton When we discussed this at the dev meeting it seemed unclear whether Tor Launcher and TIMB would fit into such a component. I'm not sure why they wouldn't -- please share your thoughts. 2. Pick a time and method to begin collapsing things, which will inevitably (and IMO necessarily) involve huge amounts of triaging. We could do this all-at-once with a batch modification to each agreed upon component and then try to deal with the resulting mess later, or we could go component-by-component and try to triage each one of them. It might be easier to do this in smaller teams, 1-3 people, for specific smallish amounts (1-2h) of dedicated time a few times a week. Or we could schedule some insane 8h block where it's all hands on deck. Does anyone have a strong opinion about the best way to organize this? If not, what are your preferences? Thanks, Erinn [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-bugs

3 2