May 2015 - tbb-dev - lists.torproject.org

Using topic branches for Tor Browser patches
by Nicolas Vigier 15 Dec '15

15 Dec '15

Hello, Currently on tor-browser.git, each Tor Browser release has a single branch that includes all our patches. This is simple, however it makes it difficult to test each patch individually, and see which patch is responsible for which test failure. For instance, the patch to add preference overrides causes many tests to fail, probably because many tests don't expect the default preferences to change: 31.7.0esr pass all tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5bbe47119ac0 31.7.0esr + preference overrides patch fails many tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fdc349fbbf5f After discussing about this quickly with intrigeri last week, I have been thinking about a different way to organize the patches: maybe we could use one branch for each topic, and merge all those branches in a single branch when we prepare the release. The naming of the branches could be: - ${firefox_version}/base: the commit for the firefox version we are using. - ${firefox_version}/${topic_name}: A branch containing patch(es) on a specific topic. $topic_name can be a bug number and/or a short description. We can submit those branches to Mozilla Try to see if they break some unit tests. - ${firefox_version}/${tbb_version}/${topic_name}: The same as the previous one, but for a topic that we only want to include in a specific Tor Browser version. - tor-browser-${firefox_version}-${tbb_version}-1: The branch that we use to build Tor Browser. This branch is based on ${firefox_version}/base, and includes merges of all branches matching ${firefox_version}/[^/]* or ${firefox_version}/${tbb_version}/[^/]*. As an exemple, I have converted a few patches from tor-browser-31.7.0esr-4.5-1 to this new naming in this git repository: https://github.com/boklm/gecko-dev/branches/all With all topic branches merged to this tor-browser-31.7.0esr-4.5-1 branch: https://github.com/boklm/gecko-dev/commits/tor-browser-31.7.0esr-4.5-1 I also started submitting some of them to Mozilla Try: 31.7.0esr/2874-Block-Components.interfaces-from-content: https://treeherder.mozilla.org/#/jobs?repo=try&revision=91cd13cf0ac7 (some mochitest tests failing) 31.7.0esr/2950-Make-Permissions-Manager-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f8cb0c1984e (tbb-tests/browser_tor_bug2950.js failing) 31.7.0esr/2949-Make-Intermediate-Cert-Store-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=139538724d04 (no test failing) 31.7.0esr/3547-Block-all-plugins-except-flash: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c75fb4685994 (some xpcshell, mochitest, mochitest-chrome, reftest failing) 31.7.0esr/3229-Make-content-pref-service-memory-only-clearable: https://treeherder.mozilla.org/#/jobs?repo=try&revision=344873ae1513 (1 xpcshell test failing) 31.7.0esr/TB2-Provide-an-observer-event-to-close-persistent-connections: https://treeherder.mozilla.org/#/jobs?repo=try&revision=93af45d5111a (no test failing) 31.7.0esr/2875-Limit-device-and-system-specific-CSS-Media-Queries: https://treeherder.mozilla.org/#/jobs?repo=try&revision=32244f089736 (still running at the moment) 31.7.0esr/2872-Limit-the-number-of-fonts-per-document: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4abfb45bba86 (still running at the moment) We could also have some helpers scripts to make management of all those branches easier: - a script to merge / list all topic branches that have not yet been merged into their tor-browser-${firefox_version}-${tbb_version}-1 branch. - a script to push / list all branches that need to be pushed for a firefox or tbb version to a remote git repository. - a script to rebase all patches from a previous firefox version to a new firefox version. What do you think about this idea ? Nicolas

1 7

Reminder: Meeting postponed until Tuesday
by Mike Perry 25 May '15

25 May '15

Just a reminder that the TBB meeting will be at 18:00 UTC on Tuesday, due to the US holiday. -- Mike Perry

2 1

Memory Allocators
by Tom Ritter 19 May '15

19 May '15

ESR38 isn't going to have jemalloc3. But the code is in the FF tree, well-integrated, and while I wouldn't call it 'supported', the mozilla devs are at least pretty familiar with it. I wanted to see if there was anything that would stop Tor from potentially using it even if FF isn't. The mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=762449 Their concerns are, at least: - mismatched calls to VirtualAlloc/Free: https://github.com/jemalloc/jemalloc/issues/213 (This can be resolved by a patch in comment #1 which is slower than they'd like) - performance concerns - I think there are issues on mobile platforms, but I'm not entirely clear there There are probably more, but these were the ones I was able to discern. I decided to test the performance question, with and without the patch. I ran a slew of in-browser benchmark sites on an Ubuntu desktop, running mozilla-release tag FIREFOX_38_0_RELEASE. The results are close, and it looks like the current jemalloc (2?) outperforms jemalloc3, but that jemalloc3 (even with the patch) is not significantly more painful. Both compare favorably to chromium for instance. http://imgur.com/a/A6TV9 Bigger is better for all but the last chart (which labels it in the title). If Tor wanted to consider turning on jemalloc3 in TBB, I would suggest the following: 1) Seeing if the heap isolation based on class of object (e.g. js strings/arrays) is implemented, and if not, what it would take to do so. If it's not there and it's hard to do, there's not much point to turning to jemalloc3 2) Round up the mozilla devs and lay it out as a real possibility and get their input I will work on #1 as I'm able. -tom Benchmarks: http://peacekeeper.futuremark.com http://browsermark.rightware.com/ http://dromaeo.com/ http://v8.googlecode.com/svn/data/benchmarks/v7/run.html http://octane-benchmark.googlecode.com/svn/latest/index.html http://browserbench.org/Speedometer/ http://browserbench.org/JetStream/ http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks/spinning-bal… http://www.webkit.org/perf/sunspider/sunspider.html http://krakenbenchmark.mozilla.org/index.html

2 2

FWD: privacy/security guidance docs for W3C groups
by mikeperry＠torproject.org 12 May '15

12 May '15

Yan was kind enough to send this to me as a heads up. We both agreed that the Security & Privacy questionnaire needs a Threat Model for Third Party Tracking, so that it is easier to build a single option for controlling third party tracking identifiers, like we did with our 'privacy.thirdparty.isolate' option. She suggested that we should create an issue for this at https://github.com/mikewest/spec-questionnaire/issues, describing how Tor Browser deals with this threat model, and what we would like to see in terms of how API designers should address it. Are there any other issues or suggestions we should make there, in either that document, or the fingerprinting guidance draft? ----- Forwarded message from Yan Zhu <yzhu(a)yahoo-inc.com> ----- Date: Thu, 19 Mar 2015 16:06:27 +0000 (UTC) From: Yan Zhu <yzhu(a)yahoo-inc.com> Subject: privacy/security guidance docs for W3C groups Hi technologist-ish people, The W3C has been working on some privacy and security guides for working groups to consider when writing new specs. As you probably know, it has historically been easy for new specifications to accidentally (or intentionally) introduce web tracking methods and increase browser security surface. We are trying to take steps towards preventing this by encouraging/forcing working groups to do a security/privacy self-review of specs in the future. I'd be curious to hear your feedback on the following two guides if you have any: * https://mikewest.github.io/spec-questionnaire/security-privacy/ - a general collection of security/privacy questions that groups should ask about new specs * https://w3c.github.io/fingerprinting-guidance/ - a guide to mitigating fingerprinting. I'm thinking the "Best Practices Section" could get merged into the questionnaire above. Thanks,Yan ----- End forwarded message ----- -- Mike Perry

3 3

Rationale behind the move to Disconnect Search?
by intrigeri 04 May '15

04 May '15

Hi, we're in the process of upgrading Tor Browser to 4.5 in Tails, and I noticed the migration to Disconnect Search as the default search engine. That's the kind of changes that we often have to justify in face of users and auditors, but I wasn't able to find the rationale behind this decision on the corresponding ticket [1]. I see the release announcement [2] says: > Disconnect provides private Google search results to Tor users > without Captchas or bans. And below, Georg commented: > Startpage was not happy with our traffic and showed sometimes > CAPTCHAs. Disconnect on the other hand approached us with respect to > search engine traffic and donated some money. So, just to clarify: is that the entire rationale behind this move? [1] https://trac.torproject.org/projects/tor/ticket/14490 [2] https://blog.torproject.org/blog/tor-browser-45-released Cheers, -- intrigeri

2 2