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

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

14 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

Re: [tbb-dev] Request for feedback on grant proposal related to usability
by Mike Perry 03 Aug '15

03 Aug '15

I will not be back in time to devote any cycles to this before Monday. isabela: > Hello folks, > I haven't got any votes for a good time to meet yet. I am wondering if > tomorrow (Friday) is too soon. Would be better to have feedback via email? > > My problem is time :) since we will need to submit it soon. Also I would > love to incorporate people's feedback before my next meeting with > SecondMuse (next Tuesday). > > I did went through the doc and added *a lot* of new things there to give > it more shape. Even if you have already taken a look at it, I would > suggest to look again :D because there is much more there from me and > from secondmuse as well. > > Anw, Let me know if I should add more dates for later in the week in > doodle or .. > > Thanks, > Isabela > > > On 07/29/2015 04:47 PM, isabela wrote: > > Hello there, > > > > I am emailing you because I would like to get some feedback on a > > proposal we are trying to put together for SIDA. This proposal is focus > > on usability work, and we are applying with SecondMuse (some of you > > might know them already). > > > > Is a 4 years contract, but not a lot of money. You can find more > > information here: > > > > https://docs.google.com/document/d/1wQ1Dzbe6g8xJYsvO9goOoG90LAfIJYxLrbB2uCo… > > > > What is there is just a draft of an idea on how we could build an user > > centered development process for Tor Browser, which is to bring > > usability checks (user feedback) to early on in the development cycle. > > To achieve that, I thought we could do it with our alpha releases. > > > > I left this to the second year of the contract tho, because I thought we > > could use the first year to give priority to fix a big broken window for > > usability, which is our website. So, I am proposing that during the > > first year, while SecondMuse does their needfinding work, we can redo > > our site. > > > > I met with Elizabeth from SecondMuse yesterday and we will be updating > > this draft with, refining more the idea, we hope to do it by EOD on > > Thursday. So I recommend checking it again :) > > > > Here is a doodle for trying to figure out when is a good time to meet. > > The deadline for this proposal is August 10, this is why I am trying to > > schedule this so soon: > > http://doodle.com/h87zeh3bzcye665c > > > > For this meeting I would very much appreciate if we focus on 'what' more > > than on 'how'. The goal here is to have an agreement on what we will be > > doing for this proposal, since our deadline is very soon. > > > > Let me know if you have questions etc! > > > > Thank you, > > Isabela > > > > -- > PM at TorProject.org > gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B > @isa > -- Mike Perry

2 1

Tor Browser/Tor Applications Team Meeting temporarily moved to Tuesday 18:00 UTC
by Mike Perry 26 Jul '15

26 Jul '15

The Tor Browser team meeting will be temporarily moved this week to Tuesday (July 28th) at 18:00 UTC, due to scheduling conflicts for Georg and me. Because of an additional conflict with the Tor Patch Workshop, we will likely be using #tor-project on irc.oftc.net instead of #tor-dev, as well. We're also expanding the meeting in general to open it up to anyone who is working on user-facing Tor client applications (such as Tor Birdy, Tor Messenger, Ricochet, GetTor, Satori, etc). If you work on something user-facing and want to discuss UI/UX, censorship circumvention configuration, or any related topics, please join us! The meeting format is described here: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

Re: [tbb-dev] Orfox: Porting TorButton to Android
by Nathan Freitas 21 Jul '15

21 Jul '15

On Mon, Jul 20, 2015, at 01:12 PM, Amogh Pradeep wrote: > > > On Jul 20, 2015, at 12:15 PM, Georg Koppen <gk(a)torproject.org> wrote: > > > > Nathan Freitas: > >> > >> Amogh and I are trying to figure out the shortest path to getting > >> TorButton ported to Android, such that we can have the essential privacy > >> features without having to say, port all the XUl/user interface > >> components. > >> > >> Our plan is to remove all XUL components (for now) since those would > >> need to be written for the mobile specific XUL on Android, and they seem > >> to be helpful but not absolutely required. > > > > I don't think this is true. "New Identity" comes to mind which does not > > work if you just remove all XUL related things. Window resizing/Screen > > size spoofing is another feature. And there are probably a bunch of > > others as well. > > The “New Identity” feature can be replaced for mobile, since Orbot > handles all the tor connections, I think it would be possible to add this > functionality through NetCipher’s OrbotHelper class[0]. Agreed. For now, Orbot does this, and we don't need to expose it inside of Orfox for now. > >>> From there, hopefully all the code here: > >> https://gitweb.torproject.org/torbutton.git/tree/src/components > >> > >> should work in the mobile context. However, there could be problems > >> based on not all of the JS/DOM API being the same. Since we also don't > >> run our own instance of Tor within Orfox, none of the control port > >> specific JS is relevant. > >> > >> If anyone on this list can help us prioritize the JS components to > >> required vs nice to have, that would be helpful. > > > > See the "Bug 1506 PX" comments where the "X" is in the range of 0-5 (0 = > > low prio, 5 = high prio) which got included a while a ago. This is, > > however, missing the latest Torbutton improvements. But it might be a > > good start and we could use the momentum to categorize the newer code > > accordingly as well. > > Much of the extra control port JS could be modified to talk to the Java > layer which communicates with Orbot which in turn handles these > connections. This is a lot of work though, might be a good idea but. We must decide which functionality is required or just nice to have. Screen size spoofing is complicated because mobile screens are radically different and change quite a bit, and inherently you want the screen to work with the display, else users will be annoyed. This may be an area where we just can't match Tor Browser's anti-fingerprinting features. Otherwise, Amogh and I will work through the Bug 1506 comments. Thanks!

2 1

Orfox: Porting TorButton to Android
by Nathan Freitas 20 Jul '15

20 Jul '15

Amogh and I are trying to figure out the shortest path to getting TorButton ported to Android, such that we can have the essential privacy features without having to say, port all the XUl/user interface components. Our plan is to remove all XUL components (for now) since those would need to be written for the mobile specific XUL on Android, and they seem to be helpful but not absolutely required. >From there, hopefully all the code here: https://gitweb.torproject.org/torbutton.git/tree/src/components should work in the mobile context. However, there could be problems based on not all of the JS/DOM API being the same. Since we also don't run our own instance of Tor within Orfox, none of the control port specific JS is relevant. If anyone on this list can help us prioritize the JS components to required vs nice to have, that would be helpful. Thanks!

3 2

Orfox User Agent
by Georg Koppen 03 Jul '15

03 Jul '15

[moving this part to tbb-dev, and CCing Nathan as I am not sure if he is subscribed to this list] "Orfox does not currently include the mobile versions of HTTPS Everywhere, No Script and the Tor Browser Button, but these we will be added shortly, now that we have discovered how to properly support automatic installation of extensions on Android (https://dev.guardianproject.info/issues/5360) Orfox includes a “Request Mobile Site” option that allows you to change the user-agent from the standard Tor Browser agent to a modified Android specific one: “Mozilla/5.0 (Android; Mobile; rv:31.0) Gecko/20100101 Firefox/31.0″. (https://dev.guardianproject.info/issues/5404) This is useful for being able to see the mobile version of a website, but does reduce the amount your browser blends in with other browsers." We had this User Agent discussion briefly during our last meeting on Monday and I thought it might be quite appropriate to discuss this design decision in more detail. I think using the Tor Browser User Agent by default costs Orfox more than it helps at the moment and think it should get switched to the mobile one instead. The major cost here is usability and the gain is questionable at the moment as 1) it is possible to detect Orfox as it does not ship the same extensions as Tor Browser 2) it is probably possible to detect Orfox as it is running on Android and there are platform based differences we don't tackle yet (for some we have on our radar see: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb… 3) there are APIs only on Android available (see: e.g. https://bugs.torproject.org/10286 to name just one) which aids in making a distinction between desktop and mobile browser 4) even if APIs are available both on Desktop and Android they might provide results showing clearly that a user is running Orfox (think for instance about the faking of screen dimensions and the result on some displays with a lower resolution) While it might help against getting identified in some server logs I think a better strategy might be to push the usability of Orfox as hard as possible in order to get users not annoyed by weird wbesite rendering. This has two advantages: 1) You get more users that could help you shaking out bugs due to 1) you get 2) A larger set of people being in the Orfox group somewhat mitigating the different user agent It might be reasonable to somehow move to a Tor Browser user agent later on or have this as an explicit design goal but first the above points should be fixed or we should have at least a clear understanding on how hard it actually is singling the Orfox group out. Georg

1 0

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