- tbb-dev - lists.torproject.org

Tor Browser 5.0 tag update
by Mike Perry 01 Jul '15

01 Jul '15

Hey everyone, I updated tags on the 5.0 items that should likely see an alpha/soft release before we push 5.0 out to all of our 4.5 users. They are viewable here: https://trac.torproject.org/projects/tor/query?keywords=~tbb-5.0a&status=!c… (Note the addition of a tbb-5.0a tag, along side tbb-5.0a-highrisk). If you're looking for something to work on, these tickets should be highest priority at the moment. I also updated the July radar tags: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~Tor… https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~Tor… Nicolas - I did not actively include tickets for you in that list. There are a few tbb-testcase tickets in ff38-esr you might consider: https://trac.torproject.org/projects/tor/query?keywords=~ff38-esr&status=!c…. Also feel free to pick anything from the changelog for 5.0a3, or any other ff38-esr ticket that you feel you could easily create a test for and is important to test/ensure going forward. You can also grab any gitian-related tickets that seem useful, as well (I won't get to #15864 this week, for example, so you can grab that if you want, and Georg is going on vacation next week, so anything gitian-related he hasn't finished by then is probably also fair game). -- Mike Perry

1 0

Remaining loose ends for 5.0a3
by Mike Perry 25 Jun '15

25 Jun '15

Hello all, I went on a merge rampage earlier today merging everything that seemed ready for 5.0a3. A few loose ends remain, though. Here's a quick list of the remaining things we need to wrap up somehow, broken down by person. Arthur: * https://trac.torproject.org/projects/tor/ticket/13670 - Probably shouldn't be merged until mcs's concerned are fixed (ideally with the proper URI-like cache key). Either that, or we just let it sit out. * https://trac.torproject.org/projects/tor/ticket/15646 - We should probably go with this patch as-is for now and fix it later, unless Arthur has time to update it tomorrow. My preference is for fixing up #13670 for it to be good enough to go in 5.0a3 though. Pearl Crescent: * https://trac.torproject.org/projects/tor/ticket/16397 - This patch did not apply against FF38. It seemed to only be against the stable? * https://trac.torproject.org/projects/tor/ticket/16300 - Either needs revision or we need to disable the BroadcastChannel API via pref. Either one is fine with me. My preference is on #16397 getting done first. Phoul: * https://trac.torproject.org/projects/tor/ticket/16268 - Blocking on transifex Georg: * https://trac.torproject.org/projects/tor/ticket/16351 - Needs binutils patch? Unclear on what we need here. Georg/Myself: * https://trac.torproject.org/projects/tor/ticket/16005 - Is the patch breaking the game, minimal mode itself, or something else? If disabling webgl.min_capability_mode doesn't make the game work, then either something about our build process or your system is at fault, and not this patch. I say merge it in that case (or ask for secondary review). * Still need to fix up Torbutton somehow.. Should we create a branch from some commit in the history, or are all the merged changes for FF38 OK for FF31 and 4.5.x? - Either way, we'll need to handle the window resizing pref for 4.5.3. Myself: * https://trac.torproject.org/projects/tor/ticket/16403 - Need localization to propagate the new params - How do we handle localization of the stable torbutton? New branch? * Still need to rebase onto the June 30th Firefox release tags. Anything I missed? -- Mike Perry

2 1

Hardening checks exceptions
by Nicolas Vigier 22 Jun '15

22 Jun '15

Hello, In the tests that we are doing on Tor Browser releases to check the hardenning of binary files, I am planning to add exceptions for the following files for the following tests (which are currently failing): RELRO: TorBrowser/Tor/PluggableTransports/meek-client TorBrowser/Tor/PluggableTransports/meek-client-torbrowser TorBrowser/Tor/PluggableTransports/meek-client-torbrowser TorBrowser/Tor/PluggableTransports/obfs4proxy stack_canary: libmozalloc.so libnssckbi.so libplc4.so libplds4.so TorBrowser/Tor/libstdc++.so.6 TorBrowser/Tor/PluggableTransports/Crypto/Cipher/_ARC4.so TorBrowser/Tor/PluggableTransports/Crypto/Cipher/_XOR.so TorBrowser/Tor/PluggableTransports/Crypto/Util/_counter.so TorBrowser/Tor/PluggableTransports/fte/cDFA.so TorBrowser/Tor/PluggableTransports/meek-client-torbrowser TorBrowser/Tor/PluggableTransports/twisted/python/_initgroups.so TorBrowser/Tor/PluggableTransports/twisted/runner/portmap.so TorBrowser/Tor/PluggableTransports/twisted/test/raiser.so TorBrowser/Tor/PluggableTransports/zope/interface/_zope_interface_coptimizations.so PIE: TorBrowser/Tor/PluggableTransports/meek-client TorBrowser/Tor/PluggableTransports/meek-client-torbrowser TorBrowser/Tor/PluggableTransports/obfs4proxy DEP/ASLR (Windows): TorBrowser/Tor/PluggableTransports/_ctypes.pyd TorBrowser/Tor/PluggableTransports/_hashlib.pyd TorBrowser/Tor/PluggableTransports/_socket.pyd TorBrowser/Tor/PluggableTransports/_ssl.pyd TorBrowser/Tor/PluggableTransports/bz2.pyd TorBrowser/Tor/PluggableTransports/Crypto.Cipher._AES.pyd TorBrowser/Tor/PluggableTransports/Crypto.Hash._SHA256.pyd TorBrowser/Tor/PluggableTransports/Crypto.Hash._SHA512.pyd TorBrowser/Tor/PluggableTransports/Crypto.Random.OSRNG.winrandom.pyd TorBrowser/Tor/PluggableTransports/Crypto.Util._counter.pyd TorBrowser/Tor/PluggableTransports/Crypto.Util.strxor.pyd TorBrowser/Tor/PluggableTransports/flashproxy-client.exe TorBrowser/Tor/PluggableTransports/flashproxy-reg-appspot.exe TorBrowser/Tor/PluggableTransports/flashproxy-reg-email.exe TorBrowser/Tor/PluggableTransports/flashproxy-reg-http.exe TorBrowser/Tor/PluggableTransports/flashproxy-reg-url.exe TorBrowser/Tor/PluggableTransports/fte.cDFA.pyd TorBrowser/Tor/PluggableTransports/fteproxy.exe TorBrowser/Tor/PluggableTransports/M2Crypto.__m2crypto.pyd TorBrowser/Tor/PluggableTransports/meek-client-torbrowser.exe TorBrowser/Tor/PluggableTransports/meek-client.exe TorBrowser/Tor/PluggableTransports/obfs4proxy.exe TorBrowser/Tor/PluggableTransports/obfsproxy.exe TorBrowser/Tor/PluggableTransports/pyexpat.pyd TorBrowser/Tor/PluggableTransports/python27.dll TorBrowser/Tor/PluggableTransports/select.pyd TorBrowser/Tor/PluggableTransports/terminateprocess-buffer.exe TorBrowser/Tor/PluggableTransports/unicodedata.pyd TorBrowser/Tor/PluggableTransports/w9xpopen.exe TorBrowser/Tor/PluggableTransports/zope.interface._zope_interface_coptimizations.pyd

2 2

Prioritization/timeline tags for ff38-esr work
by Mike Perry 12 Jun '15

12 Jun '15

Georg and I have finally filed the full set of tags for the ff38-esr work, based on the developer documentation review and the Mozilla bugtracker review. Everything should be in this tag now: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~ff3… I also broke out the set of things we really need to have ready for 5.0a3 on June 30th: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb… Those tickets represent major proxy safety audit work, patch rebase work, build system bugs, and major functionality bugs. Basically those bugs are blockers for us deploying a safe, usable, functioning TBB 5.0a3 based on Firefox 38. The set of bugs that really want to get fixed in some kind of alpha release before 5.0-stable are: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb… We should aim to get those bugs fixed for 5.0a3, but if a lot of them still end up remaining after 5.0a3, we'll want to consider either another alpha sometime in July, or do a "soft launch" release of TBB 5.0 before August 11th, so we don't have to autoupgrade 4.5.x users to it right away. The code freeze for 5.0a3 will be June 23, though we can probably slip a couple things to as late as June 25. In other words, we've got about 2 weeks left to get through that essential list and make a dent in tbb-5.0a-highrisk. -- Mike Perry

1 0

MathML disabling in Tor Browser
by Arthur D. Edelstein 10 Jun '15

10 Jun '15

Frédéric Wang posted the following comment on bugzilla.mozilla.org about Tor Browser's disabling of MathML. I'm posting it here in case it's useful: > I'm curious to know what was the reasoning to put MathML in that category [Medium-Low] and whether the Mozilla MathML/Security teams should do something to provide more security guarantee on MathML to Tor people. > > The "Medium-Low" level seems to only disable features related to executable code (javascript & java) while MathML is essentially a complex rendering of text so it should be treated at the same level as layout, graphics & fonts (e.g. the latest public critical issue I'm aware of is https://www.mozilla.org/en-US/security/advisories/mfsa2014-59/, which is actually really from the "DirectWrite font handling"). > > The iSEC study does not even mention vulnerability of MathML while it says that "the SVG components have been the host of several exploitable bugs in the past several years" and recommends to "disable at the Low or Medium security level"... but your link says it is only disabled in High mode. > > Also, the iSEC study says it rely on the exploit analysis, but a quick search on https://www.mozilla.org/en-US/security returns far less results (two) for MathML than for SVG. And actually a search for "graphite" also returns two crashes too: https://www.mozilla.org/en-US/security/advisories/mfsa2012-64/ > > Finally, the iSEC study seems to take into account the number of websites using a given feature, but MathML does not seem less popular than graphite or svg opentype fonts.

1 1

Orfox Updates
by Amogh Pradeep 04 Jun '15

04 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Build updates with Orfox. Building Firefox for Android on the current tor browser dev branch[1] caused some problems with the app that it produced. Finding a fix to this seemed almost impossible with the limited log that the app produced and so I decided to apply patches manually from the GECKO380esr_2015050513_RELBRANCH to get the tb branch. A set of news updates related to this process can be found at the Orfox news [2] page. Eventually, after going through all the patches and testing out the applications it was producing, I managed to boil it down to one file that was causing the problems, toolkit/xre/nsXREDirProvider.cpp . This file seems to be modified as a patch to bug 9173 [3] . Currently I've replaced this with the esr38 release branch file. I'd like to know whether this is fine, if not, what other fix can be found for this problem. My current working branch can be found on my github [4] and the branch for Orfox [5] is there as well. Firefox for Android has multiple network implementations that work at the Java/Android layer, a report of that can be found on the Orfox project page [6], [7]. I am working alongside mozilla to speed up fixing these issues as well [8]. [1] https://github.com/arthuredelstein/tor-browser/tree/tb_GECKO380esr_20150505… [2] https://dev.guardianproject.info/projects/orfox-private-browser/news [3] https://trac.torproject.org/projects/tor/ticket/9173 [4] https://github.com/amoghbl1/tor-browser/tree/orfox-tb_GECKO380esr_201505051… [5] https://github.com/amoghbl1/Orfox [6] https://dev.guardianproject.info/attachments/download/1580/firefox-for-andr… [7] https://dev.guardianproject.info/news/219 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1169421 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVb9nxAAoJELm/SSKdtjUkSe8H/3fpinRtQBYVBKDbfT2Fw9hF Hp0GT82qdg6rqsouDeL8AVrjfHkf5GFr25i0RuFKxF14O3L7qhC4U2NbKbq5oEPH GfJtNs4EGJbk0x1/Dn5aOZMAU/fmgnH6wf/vrPDl/kTBzp/U4mRsPTSOcD0lUEZP kp7Dsu5YYBGcbmb7oB32fUCim4bWYPi8ScYcBEsT7ENFyOt1msGcNOj/bAKx9+6I lyhrtbuiAkf6jPVjC4a46XB5WWtC5S01Ht05Y+AHlL/EsmwKM9Tvxpas7HQIMW2F EQdKjVKwO20zUn185JsiKKXiEW6kUlqSqnpSQhIGOBZRt4oivAOZLZPNaFsqzkI= =JRkf -----END PGP SIGNATURE-----

2 1

Build Failures on ESR38
by Tom Ritter 02 Jun '15

02 Jun '15

Per irc today. I confirmed I did not run out of disk space on the vm. I have 11G free of 15. I have 2 GB of RAM, I'm not sure if that is the problem or not. Below are five last-many-lines of logs of failures of tor-browser: http://pastebin.com/LyMRhKdV http://pastebin.com/mRMP2FVH http://pastebin.com/8L3cFMU5 http://pastebin.com/D7eLB65y http://filebin.ca/23mLDScVCsKJ/build.log (most recent, full log) -tom

2 2

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 11 May '15

11 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