April 2017 - tbb-dev - lists.torproject.org

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

Proposal: extensions.update.enabled=false [tbb-fingerprinting]
by Rusty Bird 27 Apr '17

27 Apr '17

Hi, I propose to disable Tor Browser's automatic extension update, effectively freezing extension versions between releases. This would, among other things, get rid of a fingerprintable difference between mainline TB and TB with an immutable extensions directory, such as sandboxed-tor-browser, Split Browser for Qubes[1], or Tails[2]. (Currently, mainline TB uses extensions.update.enabled=true. Of the included extensions, HTTPS Everywhere and NoScript actually update, whereas Torbutton and TorLauncher already opt out by setting a bogus updateURL.) So when e.g. HTTPS Everywhere at some point updates itself to a version with new rules, a website affected by the rule changes (as a first party or as a third party) can distinguish which version is active. For NoScript, fingerprinting different versions is less obvious, but probably still possible when an update breaks or fixes some content. Downsides of disabling: - Minor improvements to HTTPSE/NoScript take a little longer to reach the user. (If there's a _serious_ security or usability issue, the TB version would have to be bumped anyway.) Upsides: - More uniform fingerprint for mainline and immutable TB - More reproducible environment for bug reports - Not affected by vulnerabilities in the extension updater - Slightly reduced exit traffic :) Rusty 1. https://github.com/rustybird/qubes-split-browser 2. Although Tails can of course be distinguished by its ad blocker.

3 4

roadmaping and tracking dependencies
by isabela 21 Apr '17

21 Apr '17

Hello TBB! As a result of organizing ourselves into teams and coordinate our efforts towards similar goals (e.g. better support for mobile users). Tor's Vegas teams are in need of better visibility of what each one is doing and better coordination of deliverables/dependencies. In order to achieve that, I am asking all Vegas teams to organize their work in a roadmap (covering at least till the end of 2017). Once that is done, I would like the team to identify possible dependencies on other teams to get your work done. For instance, I start working on it with the UX team and they are aware of some dependencies you have on them for certain deliverables: https://storm.torproject.org/shared/f9a3OwWFIyOlNrY1W9CxmxkFnlGbWvGzofJazGo… I know you have discussed and updated your roadmap at the AMS meeting. I took the liberty of pasting it from the wiki in this pad: https://storm.torproject.org/shared/gf-PXTTtFJyzrpqDoGepLwXa4Sr4JUb-hWIK6yq… If you don't have any further updates to it. I would like that you identify the dependencies you have on other teams and by when they need to be done so you can work at your deliverables. Please do it even for the ones the UX team has already identified you depend on them. The goal here is to have a full list of dependencies from each team to make sure everyone is on the same page. Once we have this list - I will help facilitate the coordination of that with the other teams. BTW - other teams might have dependencies on you too! Please let me know if you have any questions, or if you want me to hang out at your next meeting to help with it. Cheers, isabela

2 1

New fingerprinting patches
by Ethan Tseng 18 Apr '17

18 Apr '17

Hi Georg and Arthur, We have a meta bug for the fingerprinting resistance feature of Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1329996 According to this meta bug, we have 46 bugs (patches) being tracked on our side. 43 of them are open bugs at this moment. https://mzl.la/2oDC3Ap Last month in the Tor meeting in AMS, you mentioned that there are 30+ new patches for fingerprinting. Could you please help to identify these new patches? (by either providing a list or instructing us how to find out them on Trac) We will add the corresponding bugs on Bugzilla for them. -- Ethan Tseng Engineering Manager, Mozilla

2 2

TBB vs mandatory extension signing
by anonym 18 Apr '17

18 Apr '17

Hi, In Tails we've been wondering what to do about Firefox's mandatory extension signing [1] in FF52ESR since the opt-out preference that we have been using for FF45ESR will be removed from released versions. Today I found the Tor Browser's solution for tor-browser-52.0.2esr-7.0-2 in commit 584c17c1b3e07239b8dd195e8b91eefb2ff9b2f4; here's an extract: function isCorrectlySigned(aAddon) { // Add-ons without an "isCorrectlySigned" property are correctly signed as // they aren't the correct type for signing. + if (aAddon.id == "torbutton(a)torproject.org" || + aAddon.id == "tor-launcher(a)torproject.org" || + aAddon.id == "https-everywhere-eff(a)eff.org") { + return true; + } return aAddon.isCorrectlySigned !== false; } So it's a list of exceptions. In Tails we install two additional extensions we'd like exceptions for: * a localization-related extension that we generate dynamically *during build*, so signing will be impossible. * Ublock Origin, which we install from Debian, and the signature is missing. Can this list of exceptions be moved to an external file that we in Tails can modify instead? I think I have exhausted all options we have on our side. [2] -- I'd also like to ask if you have analysed the security implications of introducing this exception list since I couldn't find any such discussion on the relevant ticket [3]. So, have you? Personally I reacted on that it is a simple match vs the extension's id, e.g. something we should consider attacker-controlled. I haven't looked at the code closely, but I'd expect attackers can deliver their malicious code in extensions that only need to have that same id as some extension with an exception to completely bypass the code signing check. Think, for instance, about an "upgraded" Torbutton. Is my above hunch true? If so I think this approach is a bit dangerous: without the "mandatory" part, this code signing adds a false sense of security. IMHO this approach then either has to be improved (e.g. by also matching on a cryptographic hash of the XPI) or dropped and replaced with a different solution. I think it can be argued that just flipping the build switch that disables the extension code signing checks is preferable. Cheers! [1] https://labs.riseup.net/code/issues/11419 [2] I tried something really ugly: I adjusted our build script to unpack the two affected omni.ja files and patch in our exceptions, but there are binary versions (e.g. XPIProvider.jsm) generated from the patched files, so this doesn't work (or is there an easy way to re-generate the .jsm files?). [3] https://trac.torproject.org/projects/tor/ticket/14970

3 8

TBB gpg signing key rotation plans?
by Patrick Schleizer 18 Apr '17

18 Apr '17

Hi, do you have a schedule for changing to newer TBB gpg signing keys? I am asking, because torbrowser downloaders developers such as of torbrowser-launcher, tb-updater and sandboxed-tor-browser would ideally know about in advance. Cheers, Patrick

2 1

Safe Browsing V4 will replace V2 in Firefox ESR 59
by Ethan Tseng 11 Apr '17

11 Apr '17

Hi all, Mozilla is implementing the new spec version V4 of Safe Browsing. (Currently, Firefox uses SB V2.) We aim at rolling out SB V4 in Firefox ESR 59, which will be released early next year. And Google will shutdown SB V2 service at that time. I presume that this won't affect the Tor Browser since Safe Browsing is disabled by default in TBB according to these prefs: - browser.safebrowsing.enabled = false - browser.safebrowsing.forbiddenURIs.enabled = false - browser.safebrowsing.malware.enabled = false However, I still would like to give this heads up. -- Ethan Tseng Engineering Manager, Mozilla

1 0

First nightly builds based on ESR 52 are available!
by Georg Koppen 11 Apr '17

11 Apr '17

Hi all! We have first nightly builds based on Firefox 52.0.2esr available: https://people.torproject.org/~gk/testbuilds/tbb-nightly/ The location is a bit unusual but we hit an issue in our nightly build Gitian setup which made some tweaking to our usual build and upload process necessary. Nevertheless, please give this nightly a test if you can as we don't have much time left before the first alpha based on ESR 52 is due. Two issues with this nightly are already filed: 1) Modal windows are for some reason maximized which is pretty annyoing (#21875) 2) e10s is not activated on Linux (+ macOS I guess) (#21876) General issues we have on our radar for our ESR52 switch can be found on Trac: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… If you find more problems, especially stability issues, we'd love to hear about those. Happy testing, Georg

2 2

Next Tor Browser meeting on Monday, April 24 1800 UTC
by Georg Koppen 11 Apr '17

11 Apr '17

Hi, Due to a holiday next Monday we will skip the Tor Browser meeting on that day. The next one will be on Monday, April 24, time and place as usual: 1800 UTC in #tor-dev on the OFTC network. See you there, Georg

1 0

How to use Tor Browser for security not anonymity? How to use TBB using clearnet?
by Patrick Schleizer 10 Apr '17

10 Apr '17

TLDR: 1) How can one easily hack TBB to use clearnet? [1] (idea [2]) 2) How can one enable cookies to persist in TBB? 3) How can one re-enable the Firefox password manager in TBB so one can store passwords? To archive that I've disabled private browser and tinkered with lots of torbutton Firefox config settings to no avail. Could you please kindly advice on how to archive that? Long: Tor Browser is better hardened than regular Firefox and over time, it will be even better hardened, even sandboxed. For clearnet browsing where Tor is either not required or creating a mess (such as online banking), it would be awesome if one could use Tor Browser without going through Tor. I guess it's very safe to assume, the most users won't use TBB exclusive. They also want to use clearnet. But the value of a super hardened secure browser TBB is somewhat reduced when then using a non-hardened browser for clearnet use, which could lead to system compromise. Of course this TBB hacking for clearnet use would for now only be advise able for advancement users to not mess up a Tor Browser actually using Tor vs a Tor Browser actually using clearnet. Would be up to oneself to have some protections in place such as using a dedicated VM or computer for that purposes so that one won't accidentally confuse one browser with another. Cheers, Patrick [1] I hear, at some point in future, TBB will no longer have TCP compiled in, and only use unix domain sockets. That's awesome for TBB use with Tor, but makes TBB use with clearnet hard. Long term a solution to redirect TOR_SOCKS_IPC_PATH to clearnet would be needed. [2] Idea how to hack TBB to use clearnet. We could set these environment variables: export TOR_NO_DISPLAY_NETWORK_SETTINGS=1 export TOR_SKIP_CONTROLPORTTEST=1 export TOR_SKIP_LAUNCH=1 export TOR_SOCKS_IPC_PATH=/path/to/unix-domain-socket-file then use socat to redirect to unix domain socket file to 9150. On 9150, we could have a local ssh server running sudo apt-get install openssh-server and then use ssh to open a local socks port forwarding to our local ssh server, which then would use clearnet. sudo apt-get install openssh-client ssh -D 9150 user(a)127.0.0.1

2 1