- tbb-dev - lists.torproject.org

Moving next Tor Browser meeting to April 3, 1800 UTC
by Georg Koppen 29 Mar '18

29 Mar '18

Hi! We'll move the next Tor Browser meeting to April 3 (which is the Tuesday next week), 1800 UTC as there are some jurisdictions where April 2 (Easter Monday) is a public holiday. The meeting location is, as usual, #tor-meeting on the OFTC IRC network. Georg

3 4

Intent (Request?) To Remove: privacy.firstparty.isolate.restrict_opener_access
by Tom Ritter 28 Mar '18

28 Mar '18

Back in https://bugzilla.mozilla.org/show_bug.cgi?id=1319773#c20 we decided to create this pref to allow Tor Browser to relx it's FPI back to it's old version, which allowed opener access. As far as I can tell, there was never a need to do this. This pref _can_ be used to debug one specific instance of FPi login failures. But it's also a confusing edge case that it doesn't seem we need to support anymore. If I remove it, it will still be present in 60 ESR. -tom

2 1

Compiling Firefox with mingw-w64/clang
by Georg Koppen 26 Mar '18

26 Mar '18

Hi all! We need to switch away from our mingw-w64/gcc-based toolchain for our Windows builds in the near future as Mozilla's Rust-based Stylo can't get compiled with it anymore.[1] We have time to do this switch during the ESR 60 cycle and I guess this is needed, too, as I anticipate at least a bunch of reproducibility issues and probably other bugs we have not found yet/not thought about. I am not done yet with the Stylo bug but I thought I write up some instructions for those who want to try out this new toolchain (and I even know of someone already showing interest :) ). I've been using https://github.com/mstorsjo/llvm-mingw. `master` should basically work although I am right now still on commit 48af4af2c3f7aad1b0d58c82fe38c8d44996d912. 1) Building llvm/clang ---------------------- First we need to get all the needed llvm/clang/lld sources: git clone https://github.com/llvm-mirror/llvm.git cd llvm git checkout ea4dd0b9197d95bd52b54f18666bdd8ff60238af cd tools git clone https://github.com/llvm-mirror/clang.git git clone https://github.com/llvm-mirror/lld.git cd clang git checkout 09a80cc504e13cd931d86446f194d4a0ddf89e8f cd ../lld git checkout 1493087f49cd388f501f0b802ac7c1e1796d2f29 cd ../../../ Now, make sure you skip the arm and aarch64 targets in build-llvm.sh by patching the script to use -DLLVM_TARGETS_TO_BUILD="X86" only. Then doing a /path/to/llvm-mingw/build-llvm.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 2) Dealing with the res format ------------------------------ Install the proper $ARCH-w64mingw32-windres binary with your Linux package management tool and rename it to $ARCH-w64-mingw32-windresreal. We need that as the tool LLVM provides (llvm-rc) is not mature enough to deal with the res format. (This step is explained in the README.md) 3) Install the wrappers ----------------------- Go into the llvm-mingw directory and patch install-wrappers.sh to install the needed wrappers just for your architecture. E.g. if you are building on x86_64, do ${ARCHS:=${TOOLCHAIN_ARCHS-x86_64}} then run ./install-wrappers.sh /path/to/your/install/prefix 4) Build mingw-w64 ------------------ First we need to get the mingw-w64 sources: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 cd mingw-w64 git checkout 6c676fa4cf13e86127cb350349ced94ce4288497 cd .. We use the build-mingw-w64.sh script in the llvm-mingw repo to build the mingw-w64 part. There are two patches needed to this script a) Again, as in 3) ARCHS need to get adapted. b) Firefox does not compile using ucrtbase yet. So, we need to remove '--with-def ault-msvcrt=ucrtbase' and 'FLAGS="$FLAGS --with-default-msvcrt=ucrtbase"' Now, again doing a /path/to/llvm-mingw/build-mingw-w64.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 5) Build compiler-rt -------------------- The sources first again: git clone https://github.com/llvm-mirror/compiler-rt.git git checkout 97adb78eaae40595d052cfa76514db8256063bea cd .. Now, we use the build-compiler-rt.sh script in the llvm-mingw repo to build the compiler-rt part. There are two patches needed to this script: a) Again, as in 3) ARCHS need to get adapted. b) If ARCHS does not include i686 then we can omit a respective symlink by commenting it out ( #ln -sf i686-w64-mingw32 $PREFIX/i386-w64-mingw32 ) Then, doing a /path/to/llvm-mingw/build-compiler-rt.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 6) Building libcxx ------------------ Getting the sources git clone https://github.com/llvm-mirror/libunwind.git git clone https://github.com/llvm-mirror/libcxxabi.git git clone https://github.com/llvm-mirror/libcxx.git cd libunwind git checkout 86ab23972978242b6f9e27cebc239f3e8428b1af cd ../libcxxabi git checkout 05ba3281482304ae8de31123a594972a495da06d cd ../libcxx git checkout a351d793abce1ecaead0fd947fe17f75b0c41ae5 cd .. Now, we use the build-libcxx.sh script in the llvm-mingw repo to build the all three pieces. Again, just the ARCHS part in it needs to get adapted. Afterwards we can do /path/to/llvm-mingw/build-libcxx.sh /path/to/your/install/prefix and it should build all the things and install the results in the prefix directory. That's it! Now, pick a mozilla-central revision that still allows disabling Stylo and use the .mozconfig and patches attached to the Mozilla bug[1] to get the whole piece built. Note, the above is from memory and looking at the scripts again. Attached is the patch I have in my llvm-mingw repo. The commits outlined in this mail are the ones I have used, though, as I needed to work around some bugs. The setup should not be too complicated but I am glad to help if anyone got stuck. Georg [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1390583

1 0

MOZ_DISABLE_NONLOCAL_CONNECTIONS
by Tom Ritter 26 Mar '18

26 Mar '18

45 seconds ago I just learned about the environment variable MOZ_DISABLE_NONLOCAL_CONNECTIONS that we use in our testing environment. It feeds through to one real location in the browser: nsSocketTransport2 https://searchfox.org/mozilla-central/rev/8976abf9cab8eb4661665cc86bd355cd0… This isn't a sandbox. If an attacker has code execution (parent or content process) they can make network connections manually from system libraries and will never touch this code. But it might be a way to add (some) assurance about browser features accidentally bypassing the proxy. So I'm wondering if this is something Tor Browser can set for defense in depth. In fact, it's already in esr52: https://dxr.mozilla.org/mozilla-esr52/search?q=AreNonLocalConnectionsDisabl… I tried to get Tor Browser to unset the proxy but couldn't seem to get it to work; is there a patch that prevents this? It would be interesting to remove the patches tagged 'tbb-proxy-bypass' (on https://torpat.ch/uplift) and see if this prevented (some) of those. -tom

3 3

Daily users of Tor Browser
by sajolida 23 Mar '18

23 Mar '18

I originally wrote wrote to metrics-team@ but they redirected me to you. I wanted to have a (rough) number of daily users of Tor Browser to compare it to the daily users of Tails (instead of comparing it to the daily users of Tor as a whole). I went up to "Update pings" in "Tor Browser downloads and updates": https://metrics.torproject.org/webstats-tb.html But I have a hard time interpreting this number from the description of the metric: « Update pings and update requests are requests made by Tor Browser to check whether a newer version is available or to download a newer version. » How often Tor Browser is pinging for updates? Once a day? Every time it starts? I also understand from #22346 that I should rather use the numbers after the big drop around January 20.

2 1

Next Tor Browser meeting on March 26 at 1800 UTC in #tor-meeting
by Georg Koppen 17 Mar '18

17 Mar '18

Hi all! Some of you might wonder whether we'll have our regular Tor Browser sync on the coming Monday. As we said before we started travelling to Rome, we'll skip that one and would have our next meeting on Monday, March 26. Note that we adapt the meeting time slightly as well as we'll have daylight saving time by then in the US and Europe. Thus, the next meeting will be on Monday, March 26 at *1800* UTC in #tor-meeting on the OFTC network. Georg

1 0

Work left before releasing the first alpha for Tor Bowser on Android
by Georg Koppen 14 Mar '18

14 Mar '18

Hi all! While doing roadmapping on Sunday we decided to work towards getting our first alpha for Tor Browser on Android out in July this year. Sitting together today we discussed what needs to be done by then. The blockers for that release are: 1) The first alpha should not be based on Firefox ESR but on the regular release channel which we tend to follow for the mobile Tor Browser 2) We need to make sure there are no proxy bypasses possible 3) We need good hints for our users that this is an alpha, possibly showing the missing features (UX team help) Moreover, the following things should have been investigated by then: a) What do we want to do with the updater/updating users in case we want to not only use Google's Play Store but have the browser availale in F-Droid and on our website as well? b) Are the first-party-isolation and fingerprinting defenses on Android working if the respective preferences are flipped? That means we don't plan to include Torbutton nor Tor Launcher right now, which should happen later. Neither are we planning to have the reproducible build of that browser ready by then. This is planned for the second alpha scheduled for September. Let me know if I forgot something or whether the above does not make any sense. Georg

3 3

Tor Browser for Android Roadmap/Proposal
by Matthew Finkel 09 Mar '18

09 Mar '18

Hi, Below is the current (rough) roadmap and outline of Tor Browser for Android. There remains some uncertainly of some aspects (and timing), but we should be able to make some decisions in Rome. (Igor, sorry if you wanted to make additional changes - we can continue modifying it this next week) Thanks, Matt --------------------------------------------------------------------- The Tor Browser for Android Design Proposal and Roadmap 0. Introduction Tor Browser for Android, from here on referred to as TBA, is a new implementation of Tor Browser targeted at recent Android platforms. In addition to the existing implementation, where Tor Browser is supported on Microsoft Windows, Apple OS X, and Unix-like systems, Tor Browser for Android will provide similar functionality on Android. Currently Tor Browser is based on the most recent Mozilla Firefox ESR. Unfortunately, Mozilla does not support an ESR for Firefox for Android, therefore TBA must follow the most recent Mozilla Firefox releases. This reduces the risk introduced by using vulnerable and unsupported code, and allows leveraging Mozilla's teams for support. Tor Browser for Android will provide an implementation of the Private Browsing Mode, as documented in the Tor Browser Design[0]. Currently, the Guardian Project maintain and support Orfox as the initial implementation of TBA. The goal is using Orfox as a base and improving upon it such that TBA obtains privacy, security, and usability parity with Tor Browser (for Desktop). 1. Roadmap Over the following one year, we will work toward this goal. If we divide this time frame into quarters, we can set expectations for what will be accomplished. In Q1 2018: - Orfox patches will be reviewed and merged into tor-browser.git - Porting Torbutton for TBA will begin. - Porting TorLauncher for TBA will begin - Rebasing TBA patches onto Firefox for Android 60 will begin - A new version of Orfox will be released in parallel with Tor Browser, based on ESR 52.6 - XXX Discuss in Rome with TGP, coordinating releases In Q2: - Add TBA into tor-browser-builder and eliminate reproducibility issues - Continue porting Torbutton and TorLauncher including implementing mobile-UI - UI design discussions will take place in Rome - Investigate mobile-specific fingerprinting vectors - Release Orfox updates in parallel with Tor Browser In Q3: - TBA is fully reproducible - Release first version of TBA (alpha?) (probably based on Firefox for Android (Fennec) 60) - XXX We can considering coordinating this with an announcement at HOPE XII in July - Begin auditing GeckoView and Mozilla Focus implementation as upstream of TBA - Focus has different "look and feel", evaluate UX impact In Q4: - Release first version of TBA with TorLauncher integration 2. Design Tor Browser for Android will adhere to the Tor Browser design requirements[0] and it will maintain the same adversary model with increasing adversary capabilities. The user interface restrictions present on Android platforms introduce additional obstacles and require re-design and re-implementation of some existing Tor Browser features. However, the end result is maintaining the same "look and feel" on desktop and Android. 3. Adversary Capabilities - Attack a. Read and change Tor configuration variables through the Tor Control protocol. - An adversary (malicious application) could access the Android IPC mechanism and change the configuration values. 4. Additional Information - Supported Android versions - Android 6 and above. 5. References: [0] https://www.torproject.org/projects/torbrowser/design/

2 2

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

Pad for planing for Rome o/
by isabela 04 Mar '18

04 Mar '18

Hello TB team! I created a pad for us to create agenda and share information folks should review before Rome: https://storm.torproject.org/shared/2RXUuAa_G4_GNy5yHFt8gjFqOv2wAJeq8-_0mQm… This pad ^^ is for all the meetings on March 11th. I merged UX sync with Roadmap because: 1. I think most of the conversation is coordination of work (when Antonela needs to be done, when dev starts etc) 2. This gives 2 hrs of hanging out and talking roadmap; so there is no rush and if it ends earlier - the better :) Mobile! I added a big chunk of the language used in the proposal to describe the activities to help guide you on the discussion related to what is the final product for this project. The timeline is just a guide for you, if you want to change it, you can do it. Is better to change and have things reflect reality. Also, use the time you think you need to get the work done. We will ask for an extension to sponsor8 contract, so this will help me know how long do you need it to be. Desktop! :) I think coordination with Antonela and Mobile is good for all the UI changes coming up (work Antonela is doing under OTF grant). We sent a SOI to DRL asking money for TB team, there is a link in the pad to it. But is nothing crazy, just keeping up with Mozilla releases and implement Anto's work. I left agenda for meetings with Mozilla open - we should share with folks so it can be populated before Rome. I also left the questions to answer when doing the retrospective, you can reflect on it ;) I leave it up to the team if folks want to fill it up before Rome or after Rome. One less thing, Antonela will be with yall during the roadmap meeting. I will have to split and be with network team roadmap meeting hehe :) Let me know if you have any questions! isabela

2 1