Hi!

We had our second Tor Browser meeting in 2018. Here is the meeting transcript:

http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-15-19.00.log....

And the notes from the pad are:

Monday, January 15, 2018

Discussion: -What about Taler (https://taler.net/en/ ) integration into Tor Browser? -Who wants to be the PoC for Pari's helpdesk reports (following it, amending it with tickets we already track, making sure it is correct from a browser side etc.)? (Richard volunteered) -I want to establish some feedback mechanism within the team by doing a 1to1 with each team member, say at least once a year. I plan to start this round end of June 2018

mcs and brade: Last week: - Worked on Moat integration loose ends (#23136). - incorporated activity spinner image from Antonela (#24696). - added support for multiple bridges returned by BridgeDB. - reviewed dcf's patch for #24642 (cannot use TOR_PT_EXIT_ON_STDIN_CLOSE) - Attended the UX + Tor Browser meeting on IRC. - Read the Android Torbutton and Tor Launcher proposals. - Investigated the Tor Launcher aspects of #24826 (compressed consensus diffs stall Tor Browser launch). - Worked on #24421 (Temporarily allow all this page and New Identity). - Helped with triage of new tickets.

Planned for this week: - After a test server is deployed by the Network Team, test and put Moat integration code out for review. - Comment on Matt's Android Tor Launcher proposal. - Do more debugging for #24421 (Temporarily allow all this page and New Identity). - Work on about:tbupdate issues (#21850 and #24578; avoid using a query string),

Georg: Last week: -fought my backlog -ticket review (and partially merge): #24702, #23911, #23892, #24842, #21245, #22343, and #18691 -made a bit progress on our mingw-w64/clang-based toolchain (#21777) -wrote a patch for #23916 -worked on the Tor Browser design doc update (#21256) -worked on the proposal for the toolbar redesign and better understanding of security features -started to think about our android reproducible builds and updates for Tor Browser on Mobile

This week: -release preparations for 7.5 and 8.0a1 -more reviews -finish design doc update (#21256); aimed for Friday this week -further work on the proposal for the toolbar redesign and better understanding of security features -think about some improvements to our release signing scripts

arthuredelstein

Last week:

- Worked on rebasing tor-browser.git to mozilla-central. I am about 2/3 of the way through. Once all patches are rebased, I will set up on a nightly automatic rebase script.

- Made a list of patches we should try to upstream for ESR60. I will send the list to tbb-dev and update bugzilla where needed.

- Attended the Mozilla/Tor UX video meeting and a second meeting with Mozilla uplift team on fingerprinting patch triage.

- Checked in https://bugzilla.mozilla.org/show_bug.cgi?id=1384309

This week:

- I will continue to work on the rebase, and also push forward any upstreaming patches that look feasible.

- Try to move forward on https://trac.torproject.org/24309 (tor circuit door hanger)

- If there is time, I also want to look at https://trac.torproject.org/14952 (HTTP2 audit/patching)

boklm: Last Week: - Worked some patches for: - #24842 (debug builds are missing libasan.so.2 and libubsan.so.0) - #18691 (switch Windows builds from precise to jessie) - #24879 (enable fetching of new commits by default for nightly builds) This Week: - follow the fpcentral setup - make our testsuite run on nightly builds - look again at some improvements to our release signing scripts (#24331) - review #23916 (Create a new MAR signing key for Tor Browser) - help with building of the new releases

igt0: Last Week: - PoC Tor Button for Mobile(basically, I moved the code to the tor-browser.git and started to integrate with the Firefox build system). - Updates in the Tor Button proposal - Reading about how tor-android( https://github.com/n8fr8/tor-android) works This Week: - Finish the PoC - Review sysrqb proposal - Updates to the tor button proposal

pospeselr:

Last Week:

- investigated more avenues regarding #15559 (Range requests used by pdfjs are not isolated to URL bar domain); conclusion I've come to is there no nice surgical fix here

- pdf.js seems to require the nsISystemPrincipal for range-based requests to work properly

- the JS Context the range-requests run in are missing the original principal and first-party domain information needed to be put on the correct circuit

- looks like the best that can be done is to just disable range-based requests, but at the cost of pdf performance

- will no longer be able to read pdfs as they load, the whole thing has to be downloaded

This Week:

- it's easy enough to disable range-request, so will have a patch up for this later today

- will find some other (hopefully simpler) fingerprinting bug to work on

Georg