Created attachment 323460 [details] Answer to some questions about building a custom Tor Browser from a Tor Browser developer www-client/torbrowser is currently based on Firefox 13, while, currently, the official Tor Browser Bundle is based on Firefox ESR (10.0.x). Using a more recent version of the browser could look more secure but actually is not a good idea from the anonimity point of view. As can be seen from the Tor Browser design document [1], great attention is paid to minimize the differences between different Tor Browser users, this way tracking an user becomes much harder, and each one appears as a random, unidentifiable person in the middle of all the Tor Browser users. Obviously not all the Tor Browser users are using the most recently released version, but ideally that would be the best for the user. If we use a specific version of Firefox, which is different from the official one, we're creating a small pool of (identifiable) people as a Tor user, using the Gentoo ebuild, and this is clearly unwanted. There are tons of well-documented ways to detect the real version of the browser. Using a more recent version of Firefox is OK only for testing purposes and in those context where anonimity is not important, but if we want to offer a good degree of anonimity to our userbase we should definetly use the same version of Firefox as in the official Tor Browser Bundle. Attached you can find the answer to some of my question about building a custom Tor Browser from a Tor Browser developer. Among the other questions I've asked which version should we use, and the answer is pretty clear: "The most recent release is best." I'm available to write and mantain and ebuild for www-client/torbrowser based on Firefox ESR. [1] https://www.torproject.org/projects/torbrowser/design/
I've added the stable version of torbrowser to my overlay. https://github.com/MeisterP/poncho-overlay/tree/master/www-client/torbrowser https://github.com/MeisterP/poncho-overlay/tree/master/www-misc/torbrowser-profile
Good, even if probably your overlay is off-topic here. Other notes about how the ebuild should be: * The following USE flags should not be configurable, and should be set as follow: -pgo -debug -bindist -custom-optimization -crashreporter webm ipc system-sqlite -wifi -test -debug * There's no real reason to have tor-profile separated from torbrowser, they should always go together. * The name is "Tor", not "TOR" or "tor". Tor developers are quite strict on this. * Check that all the other build options are as similar as possible to the official ones for Tor browser 2.2.38-2 [1], for instance "--disable-maintenance-service" and "--disable-crashreporter" should be set. In the next days I'll try to review more deeply your ebuild and make some tests. [1] https://gitweb.torproject.org/torbrowser.git/blob/b88ec22d0627b680c97da93706d12f63684f79dc:/build-scripts/linux.mk https://gitweb.torproject.org/torbrowser.git/blob/b88ec22d0627b680c97da93706d12f63684f79dc:/build-scripts/config/dot_mozconfig
On the tor-dev ML thread you opened no one was concerned about build-time options. also "Whoa - that sounds like madness." from your attachment is no answer. > www-client/torbrowser is currently based on Firefox 13, while, currently, > the official Tor Browser Bundle is based on Firefox ESR (10.0.x). Using a > more recent version of the browser could look more secure but actually is > not a good idea from the anonimity point of view. There is no proof of this. > Obviously not all the Tor Browser users are using the most recently released > version, but ideally that would be the best for the user. If we use a > specific version of Firefox, which is different from the official one, we're > creating a small pool of (identifiable) people as a Tor user, using the > Gentoo ebuild, and this is clearly unwanted. There are tons of > well-documented ways to detect the real version of the browser. Again, we still don't have any good word from the tor developers that different build-time options WILL cause increased vulnerability or impact anonymity. If we assume that, then the ebuild is useless and WILL be removed from the tree. > Using a more recent version of Firefox is OK only for testing purposes and > in those context where anonimity is not important, but if we want to offer a > good degree of anonimity to our userbase we should definetly use the same > version of Firefox as in the official Tor Browser Bundle. Anarchy said that the biggest problem is that it remains out of sync with fx-releases as far as vulnerabilities go. Merging torprofile back in is actually planned.
Created attachment 323562 [details] Chat on IRC (irc://irc.oftc.net:6667/tor-dev) with a Tor Browser developer about this bug
(In reply to comment #3) > On the tor-dev ML thread you opened no one was concerned about build-time > options. > > also "Whoa - that sounds like madness." from your attachment is no answer. I've asked on the #tor-dev IRC channel for an opinion, and another Tor Browser developer answered the same. > > www-client/torbrowser is currently based on Firefox 13, while, currently, > > the official Tor Browser Bundle is based on Firefox ESR (10.0.x). Using a > > more recent version of the browser could look more secure but actually is > > not a good idea from the anonimity point of view. > > There is no proof of this. In the next few days I'll try to put up a simple web page able to detect the official Tor Browser from our ebuild, and maybe I'll also be able to detect if the webm USE flag is enabled. > If we assume that, then the ebuild is useless and WILL be removed from the > tree. That's definetely an option, even if I really like the idea of having Tor browser in Portage. > > Using a more recent version of Firefox is OK only for testing purposes and > > in those context where anonimity is not important, but if we want to offer a > > good degree of anonimity to our userbase we should definetly use the same > > version of Firefox as in the official Tor Browser Bundle. > > Anarchy said that the biggest problem is that it remains out of sync with > fx-releases as far as vulnerabilities go. I've been told (on the #tor IRC channel) that is unusual that the official Tor Browser runs out of sync with Firefox ESR. If it was like this when you checked, it was an exception. > Merging torprofile back in is actually planned. Good!
(In reply to comment #5) > (In reply to comment #3) > > On the tor-dev ML thread you opened no one was concerned about build-time > > options. > > > > also "Whoa - that sounds like madness." from your attachment is no answer. > > I've asked on the #tor-dev IRC channel for an opinion, and another Tor > Browser developer answered the same. <mikeperry> I don't know why we chose the build options we did That's useless. > > > > www-client/torbrowser is currently based on Firefox 13, while, currently, > > > the official Tor Browser Bundle is based on Firefox ESR (10.0.x). Using a > > > more recent version of the browser could look more secure but actually is > > > not a good idea from the anonimity point of view. > > > > There is no proof of this. > > In the next few days I'll try to put up a simple web page able to detect the > official Tor Browser from our ebuild, and maybe I'll also be able to detect > if the webm USE flag is enabled. > Until then this bug is invalid, cause bugzie is not for discussion. I have currently masked torbrowser outdated.
(In reply to comment #6) > <mikeperry> I don't know why we chose the build options we did > > That's useless. He's just saying that he doesn't know why those particular build options have been used, but he agrees with me that all the Tor Browser should look the same for anonimity reasons. Moreover he clearly states we have to use Firefox ESR, he couldn't be clearer on that. > > In the next few days I'll try to put up a simple web page able to detect the > > official Tor Browser from our ebuild, and maybe I'll also be able to detect > > if the webm USE flag is enabled. > > > > Until then this bug is invalid, cause bugzie is not for discussion. I've attached a simple JS which detects 3 things: 1) If we're using Tor Browser checking Components.interfaces, which is disabled in "0001-Block-Components.interfaces-lookupMethod-from-conten.patch" [1]. 2) If you're using Firefox 12+, checking the CSS -moz-text-align-last property, which has been introduced in FF12 [2] 3) webm support. Here are some results: * Tor Browser 2.2.38-2 (current release, based on Firefox 10.0.7): Tor Browser: true ff12+: false webm: true * Tor Browser 2.3.20-alpha-1 (based on Firefox 14): Tor Browser: true ff12+: true webm: true * Gentoo Tor Browser (based on Firefox 13, USE flag webm disabled): Tor Browser: true ff12+: true webm: false * Firefox 10.0.7: Tor Browser: false ff12+: false webm: true [1] https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/src/current-patches/firefox/alpha/0001-Block-Components.interfaces-lookupMethod-from-conten.patch [2] https://developer.mozilla.org/en-US/docs/CSS/text-align-last
Created attachment 323596 [details] Simple HTML page testing Tor Browser, FF12+ and webm support
(In reply to comment #8) > Created attachment 323596 [details] > Simple HTML page testing Tor Browser, FF12+ and webm support Your script tells me nothing, if a user decides to disable webm support that is their choice not yours or anyone elses.(In reply to comment #6) > (In reply to comment #5) > Until then this bug is invalid, cause bugzie is not for discussion. > > I have currently masked torbrowser outdated. I agree with hasufell on this issue, the bug is invalid, we can add support for an esr build, but I do not see what that has to do with the testing builds.
(In reply to comment #9) > (In reply to comment #8) > > Created attachment 323596 [details] > > Simple HTML page testing Tor Browser, FF12+ and webm support > > Your script tells me nothing, if a user decides to disable webm support that > is their choice not yours or anyone elses.(In reply to comment #6) I'm able to distinguish a normal Tor Browser user from a Gentoo Tor Browser user, and if you read the design document and all the other attachments you can understand that it's a bad thing from the anonimity point of view. webm is just a secondary problem here. For webm: we can leave that USE flag, but I'd suggest to explictly say that disabling webm has anonimity implications. > > (In reply to comment #5) > > Until then this bug is invalid, cause bugzie is not for discussion. > > > > I have currently masked torbrowser outdated. > > I agree with hasufell on this issue, the bug is invalid, we can add support > for an esr build, but I do not see what that has to do with the testing > builds. I never said that the ebuild using a more recent version of Firefox should be removed, they should just be masked and would be still useful for testing purposes, but not for anonimity. Moreover it'd be nice to use the same version as the official development version in Tor Browser, which currently is Firefox 14, not 13. But that's a secondary thing. So you want me to open a new bug saying that we also need an ESR ebuild? That's basically what I'm asking here, so maybe it's simpler to change the title. If I submit an ESR ebuild, would you commit it?
As a user I don't understand what is current state of torbrowser in Gentoo? Gentoo will not package it after Nov 5? Users should move the not-so-anonymizing current ebuild to the personal overlays if they want to continue using torbrowser in Gentoo?
I'm not going to maintain it anymore (at least not in the tree). Another developer has to step up otherwise I will remove it, cause it's not appropriate for security related packages to lay around outdated.
