tor-project January 2018

tor-project@lists.torproject.org

20 participants
27 discussions

Notes from network team meeting, 29 Jan 2018
by Alexander Færøy 30 Jan '18

30 Jan '18

Hello! Our meeting IRC logs can be found at: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-29-18.00.html Pad copied below ---------------- Network team meeting pad, 29 January 2018 La lettre N formait sans doute l'initiale du nom de l'énigmatique personnage qui commandait au fond des mers ! --- Jules Verne, _VINGT MILLE LIEUES SOUS LES MERS_ Welcome to our meeting! Mondays at 1800 UTC on #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see anything you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! Note the meeting location: #tor-meeting on OFTC! (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) Meeting notes from previous weeks: * https://lists.torproject.org/pipermail/tor-project/2018-January/001639.html * https://lists.torproject.org/pipermail/tor-project/2018-January/001644.html Old Announcements: - Let's have some proposal discussions. Isis kicked off the process here: https://lists.torproject.org/pipermail/tor-dev/2017-December/012666.html - We are planning a single-day pre-planned highly-focused hackfest before the Rome Tor meeting - teor: pre-Rome hackfest venue is confirmed - komlo: Should there be a Rust update/planning session? What should we prepare/do beforehand to help this be planned/highly-focused? - On the roadmap spreadsheet: Please take February tasks. (If somebody else has already taken something you want, please talk to them and/or add yourself too.) https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdr… Announcements: * 0.3.3.x is in feature-freeze. No new features (except for #24902, which has permission.). * No 0.3.4.x patches will be merged till the window opens on Feb 15. * Please, work on bugfixes! It would be great to have this release release on time. (Planned date is 15 April) * Support for 0.3.0.x will end on 1 Feb. * There are tons of tiny 0.3.3.x tickets. Maybe if you can do one of them in <X minutes for some small X, you should just do it? * Review group 31 is open! https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… -- please help all your colleagues' tickets get reviewed. Discussion: * There are over 200 open tickets in 0.3.3.x. Some are bugs we should fix. Some we should defer to 0.3.4.x. Some should get tossed into the aether. Suggested process? * We have way too many open tickets left in 0.3.3.x, including ones that are assigned to people. Is this how it should be? Where, if anywhere did we go wrong? How to do better in 0.3.4.x? * There are still tickets left in 0.3.2.x. What shall we do with them? Let's get them done soon. * Looks like 28 May - 1 June 2018 and 4 June - 8 June 2018 are good dates for a hackfest. Which week do we want to do a hackfest? (4 - 8 June is just before Mozilla All-Hands) Which city/country? Does anyone want to help organise it? [teor can do some of the organising] [dgoulet: Replied offering my help][isa can help too] Nick: * Last week: - Released 0.3.3.1-alpha, including review and merge of lots of last-minute patches. - Reviewed #24902 a bunch. - Began big triage on remaining 0.3.3.x tickets. - Grabbed many small 0.3.3.x tickets and did them. - Talked w isis et al about TLS1.3. - Tried OpenSSL 1.1.1's git master branch (openssl is not yet released). Found various bugs. Navigated openssl's contributor license agreement and code review bureaucracy * This week: - Missing Monday and Tuesday: in a meeting with mozilla folks in Boston, brain-dumping all the Tor internals. - More triage on 0.3.3.x and 0.3.4.x. - More bugfixes, review, merging. teor: * Last week: - (experimental) PrivCount bug fixes and client descriptor fetch stubs - Still keeping my relays operating and supporting relay operators - Did not get time to review or revise much Tor code - The test network started running new IPv6 consensus methods 27 & 28 (The microdescs and microdesc consensus changed, nothing crashed) - Read up on general floating point issues, and read Rust's Rand f64 impl - It was a short week for me due to a local public holiday * This week: - Fix some more experimental PrivCount bugs - Implement and test experimental PrivCount onion service stats - Make a trac user page that lists the tickets I'm working on in priority order - Maybe I will get time to review or revise tickets this week asn: [Not sure if I will be present in meeting tonight. Woke up pretty early.] Last week: - More review on #24902. Found some bugs and wrote another unittest for it. - Coded #24896 and it's now on needs_review. Works fine on my HSes. - Did some research stuff. Met with a researcher who is interested in integrating PIR with HSDirs. Helped them out with chutney and gave them a few pointers on the tor codebase. - Opened a few prop224 tickets of bugs I encountered: #24972, #24976, #24977 Also reviewed's nick's patch for #24972. - Opened #24973 which might be yet another way that clients overwhelm the network. This week: - Bug triage and coverity duties. - Work on prop279 (name system proposal). - More prop247 or whatever else needs work/reviewing. dgoulet: * Last week: - Finalized code for #24902. An v4 branch now exists. Been running for at least 5 days now so I think it is getting more and more in a state to be merged upstream. - Small review on #24914 - Opened #24962, a parent ticket for most of our Tor2web DoS issues. And also two child tickets. - Bug found by arma while reviewing #24902, I opened #24975 for it. * This week: - Address reviews on #24902. I expect this to be much less work than last week thus allowing me to put time in other things. - 0.3.3.x bug triage. - Ticket work for which I really need to have them in a better state: #22781, #24554 and #24975. isabela: - got extension from sponsor4 - working on email/agreement to isis, suggested by nick. - sponsor8 Q4 report - reading pwr research on .onion / also planning on digesting our user testing results (probably on thursday/frida) and starting to put together a write up of it - team meeting on March 11 **different from team hackfest on the 10th** - this should be for retrospective, roadmapping etc. [sent email about it] catalyst: Last week (2018-W04): * reviewed #24484 * worked on making us have a better-functioning github repo * our "official" github repo is building on Travis CI now! * CoC review * sick day spent in Urgent Care again (very persistent respiratory infection) This week (2018-W05): * review tickets * CoC and Statement of Values feedback * more github adjustments as needed * draft some text about how people should interact with our github repo * try to get enough uninterrupted time to focus on #24661 Mike: Last week: - Fixed a couple purposed-related warn bugs from the vanguard prototype - Began brainstorming things the controller could do This week: - Write a README for the vanguard controller; make it more usable for 0.3.3 alpha users - Maybe start cleaning up prop247? ahf Last week: Sponsor 8: - Convert DTrace programs to SystemTap to allow more people to use it. - Spend some time getting SystemTap to work on my laptop in Qubes VM's. - Looked into some old discussions from the WebKit community on memory profiling. Misc: - Found and fixed #25026. - Got approval for Rome traveling, aiming for arriving the 7th and leaving the 16th. - Some Torsocks compatibility issue on some Linux'es. Hello71 submitted a patch that includes a fix for this in #24967 (+ some macos issues). - Read up on the prop#279 (naming layer) and especially around using it with catch-all TLD's. This week: Sponsor 8: - Begin initial memory optimization work on smartlist_t usage. - After Tim's suggestion: look into struct padding size. - Collect some baseline information for event loop usage. Misc: - Going to FOSDEM on Friday. Wont be online after 12 UTC until the evening. Limited communications over the weekend. - End of the month reporting. isis last week: - last few bugs in moat #24432 - google shut down access to my appengine account for the moat reflector - implementing prop#249 (#24986) - worked on the TLS 1.3 proposal - organised the steps to getting to a post-quantum secure circuit-layer handshake and made tickets for each #24985 this week: - schedule proposal meetings - more prop#249 work - get moat accounts shifted over to TPO ownership -- Alexander Færøy

1 0

Tor Browser team meeting notes, 29 Jan 2018
by Georg Koppen 30 Jan '18

30 Jan '18

Hi! We had another Tor Browser meeting yesterday in #tor-meeting. Here is the meeting transcript: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-29-18.59.log… And the notes from the pad are: Monday, January 29, 2018 Discussion: - Tor patch uplift plan - Sessions we want to have for the team meeting day GeKo: Last week: 1) Finished design doc update (#21256) 2) Finally finished debugging (#22256) and posted a backported patch for review 3) Dealt with release and post-release work (going over blog comments/new tickets etc.) 4) Continued writing the "Redesign of Tor Browser's security controls"-proposal 5) Some reviews 6) tjr: do you have https://bugzilla.mozilla.org/show_bug.cgi?id=1392604 on your radar too? Or should we try to deal with it for ESR 60? (GeKo: We poke ourselves I guess) This week: 1) More reviews 2) Finish the proposal and post it to tbb-dev for further discussion 3) Get back to work on #21777 (new clang-based toolchain for Windows cross-builds) 4) Get back to get the sandbox running on Windows 64bit (#24197) 5) Work on exempting .onions from mixed content warnings (#23439) 6) Look at tor launcher proposal 7) Monthly team admin stuff tjr: mcs/brade: Can you explain https://trac.torproject.org/projects/tor/ticket/19121 / https://gitweb.torproject.org/tor-browser.git/patch/?id=a4341a6 to me? from mcs: We reinstated a check that Mozilla removed. With the hash check in place, all MAR files that are applied must be "advertised" in the update.xml metadata. Mozilla views this check as unnecessary because all MAR files are signed. We were more comfortable keeping the check in case there is some kind of update attack that we did not think of that removing the check makes possible. gk and mikeperry might have something specific in mind (gk agreed that we should reinstate the check). GeKo: nothing specific, but with that check an attacker has to break more than the signing in at least a bunch of scenarios and given that automatic updates are pretty important to safeguard we felt having two independent systems in place makes more sense. tjr: So we're protecting against an attacker than can a) send the wrong update files b) forge or bypass the mar signatures but can't c) send their own update.xml file (which isn't cryptographicly verified and only contains a list of hashes?) Why could they do (a) but not (c)? Spectre Stuff More timer stuff Lots of JIT stuff landed MinGW Sandbox almost uplifted! (GeKo: I wonder whether we don't need to take care about the SANDBOX_EXPORTS or whether we want to have this uplifted as well) Fixed several mingw build breaks that popped up Wrote a (rudimentary) Binary Transparency auditor for Moz's in-progress BT stuff Arthur, Richard and I quick-triaged ~200 tor bugs Have some followup from this we will talk about in our Tuesday-same-time-as-this meeting All P1 bugs we are trying to get into 60: https://mzl.la/2DyHp6B All P2 bugs we are going to try and get into 61-62: https://mzl.la/2E7hzrH (GeKo: I think I want to work on the remaining .onion mixed content bug and get both pieces upstreamed into ESR 60) tjr: Is that https://bugzilla.mozilla.org/show_bug.cgi?id=1382359 ? I'll P1 it and assign them to you if so (GeKo: yes, that's the bug) mcs and brade: Last week: - Did some testing of Tor Browser 7.5-build3 and 8.0a1-build3 on OSX (focused on the updater). - Looked at icons and branding some more: #10888 (Mozilla trademarks still remain in some about: urls) #24578 (about:tbupdate popup notification formatting error) - Posted a patch for #24159 (Torbutton version check does not deal properly with platform specific checks). - After Isis fixed a server-side problem, we were able to resume work on #23136 (Moat integration). We found a meek client/Tor Browser issue that dcf is helping us solve. We found a problem where BridgeDB is not returning any bridges which Isis will need to help us solve. Planned for this week: - More work on #23136 (Moat integration). - Work with dcf to solve the meek client/Tor Browser SOCKS optimistic data bug. - Assist Isis as needed with the "no bridges returned" bug. - Review and comment on some of "our" bugs that are listed in Arthur's Uplift Tracker. - Triage the Tor Launcher bug list (set priorities, close outdated tickets). igt0: Last Week: - Sent patch moving Tor Button to Tor Browser repository (#25013) - Removed Tor Button from the Tor Browser build (#25013) - Continued work on Integrating Tor Button in the Tor Browser mobile version (#24855) This week: - Work in the (#24855) - I still need to investigate https://bugzilla.mozilla.org/show_bug.cgi?id=1415595 from tjr: While this would be nice, I think the protections provided by fortify source are small enough that it isn't a huge priority. Just my opinion. pospeselr: Last Week: - continued work on #22794 (Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.) - Jury Duty - met with tjr and arthur re tor uplift This Week: - finish #22794 - begin work on tor uplift patches sysrqb: Last week: Continued working on Orfox patches. - Running mochi, junit, etc tests take a painfully long time - Mochitests fail when the Android App is not the focused UI element - After running the mochitests on a headless server, I finally found why all the UI tests were failing: https://people.torproject.org/~sysrqb/screenshot3.png - Debugged and patched some failing tests Worked a little on TorLauncher on Mobile (thinking about how we should integrate it) Read about HTTP/2 (over the weekend) and started thinking about how we can evaluate it and enable pieces of it Also read about QUIC and started thinking about how Tor can prepare for that This week: Finally finish the Orfox patches and request review Work on a branch tor-browser-build for TBA (Tor Browser for Android) Review Tor Browser uplift patch list tjr: Do you have mozilla try access? Might be useful/faster for unit tests, especially if you have n changes you want to test independently. sysrqb: Nope, but that sounds extremely useful. GeKo mentioned that last week, too, but I don't know how I should go about requesting access (igt0 will probably appreciate having access too) arthur: I got access following these instructions: https://wiki.mozilla.org/ReleaseEngineering/TryServer#Getting_access_to_the… Also I use https://github.com/mozilla/moz-git-tools which allows you to use git to push to the try servers. tjr: Yea, do that and send me the bug you file and I'll nominate you. sysrqb: sweet! thanks! I didn't actually think about looking for a doc about how to do it...will do! boklm: Last week: - published the new releases - finished #6119 (FPCentral) and all sub-tickets - started fixing some testsuite issues This week: - Fix upload of nightly builds to https://nightlies.tbb.torproject.org/ and enable testsuite on nightly builds - Fix testsuite issues to have all tests passing - Start working on #18867 (Ship auto-updates for Tor Browser nightly channel) - Will be afk next monday (but should be there for the meeting) arthuredelstein: Last week: Opened lots of bugzilla tickets Updated torpat.ch Created uplift patches for 1433357, 1433507, 1433509. Working on 1432983 Continued to rebase patches for mozilla-central This week: Uplift, uplift, and away! More rebasing Also want to look at HTTP/2 -- sysrqb: would be useful to chat about this - from sysrqb: ack yes isabela: - working with sponsor4 on extension - we got it, just need new contract to sign etc. also working with network team / isis on organizing their work for finishing this deliverable - sponsor8 report due wed - meeting with arthur and geko on wed 1900utc (confirmed? antonela said that works for her) on circuit display work (GeKo: works for me) (arthur: wfm too) Georg

1 0

Notes from January 25 2018 Vegas team meeting
by Karsten Loesing 26 Jan '18

26 Jan '18

Notes for January 25 2018 meeting: Alison: 1) Code of conduct discussion is progressing well! I hope we can begin voting sometime next week. 2) Coordinating guest lecturers for LFI. 3) Giving a talk at Georgetown this Friday. 4) Tor Meeting stuff. Will send out an email about the open days to the meeting list soon. 5) Who is submitting talks for the HOPE CFP? We should have a coordinating meeting. Georg: 1) Tor Browser 7.5 is out! I am happy with it so far and have been especially happy about the good work we did with the UX-team. Karsten: 1) We'd like to get support with proofreading and editing documentation for Sponsor 13. Very rough estimate is 50,000 words for 30 specifications for reproducing Tor Metrics graphs or tables with 1,000 words each on average and 1 technical report of 20,000 words. Should we contract this out to somebody, ask a friendly Tor person whose first language is English to do this for us, or just do our best at writing? [Answer: Start by asking Tommy, and consider contracting this to somebody else later in the process.] 2) Made a very first step forward towards writing documentation for Sponsor 13. 3) CollecTor module to sanitize Tor web server logs almost complete. Last tests are running, might get this done by end of this month. 4) Can I create EC2 accounts for iwakeh and irl to do resource-intensive metrics tasks? We once had a that Tor employees/contractors could have such accounts as long as they keep their usage below 30$/month. But that policy is 2.5 years old and predates Shari's time at Tor. Is it still a good policy? [Answer: yes, do it if it's appropriate and really that cheap.] Nick: 1) Putting out an alpha today; another alpha to follow in 5-14 days. 2) Deferring more stable releases until we can get dgoulet's #24902 anti-dos code tested in an alpha. 3) Meeting with Mozilla folks on Monday/Tuesday to brain-dump about Tor internals. Probably will have limited net presence. 4) Scrambling to get 0.3.3.x freeze period to go well. Mike: 1) Continuing work on guard discovery defenses. Arturo: 1) We are releasing a new version of the OONI Probe app, that definitively changes the name from ooniprobe to OONI Probe 2) Made a lot of progress in terms of implementing the revamped OONI Explorer 3) We have established a new partnership with Tuwindi Foundation (Mali), see: https://twitter.com/OpenObservatory/status/956167750874992645 4) Migrating our database and improving the latency of OONI Explorer and API is moving forward well 5) Thanks to the localisation lab and many community members some new strings for OONI Probe have been translated to 10 languages. 6) We will be hosting a OONI workshop in Kampala (Uganda), we have been preparing the training material and correcting assignments for the course 7) Several test lists (NG, UG, SS) have been updated thanks to URLs provided by community members

1 0

Notes from network team meeting, 22 Jan 2018
by Nick Mathewson 25 Jan '18

25 Jan '18

Hi! Meeting logs are available at http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-22-18.01.html Pad copied below: ------- Network team meeting pad, 22 January 2018 Andre-Louis paused. "The less we mention names perhaps the better." --- Rafael Sabatini, _Scaramouche_ Welcome to our meeting! Mondays at 1800 UTC on #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see anything you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! Note the meeting location: #tor-meeting on OFTC! (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) Meeting notes from last week: * are on the tor-project list, send on 17 January 2017 ( https://lists.torproject.org/ was down when I checked) Old Announcements: - Tor 0.3.2.9 came out on 10 January 2018 - Soon it will be It is now time to triage 0.3.3.x tickets. Please make yourself the owner of tickets in that milestone that you will do. - The meeting time is now 1800 UTC. - Let's have some proposal discussions. Isis kicked off the process here: https://lists.torproject.org/pipermail/tor-dev/2017-December/012666.html - We are planning a single-day pre-planned highly-focused hackfest before the Rome Tor meeting - teor: pre-Rome hackfest venue is confirmed - komlo: Should there be a Rust update/planning session? What should we prepare/do beforehand to help this be planned/highly-focused? Announcements: - On the roadmap spreadsheet: Please take February tasks. (If somebody else has already taken something you want, please talk to them and/or add yourself too.) https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdr… - review-group-29 is open, there are 2 tickets left in needs_review: https://trac.torproject.org/projects/tor/query?status=needs_review&keywords… - review-group-30 is open, there is 1 ticket left in needs_review: https://trac.torproject.org/projects/tor/query?status=needs_review&keywords… - We still need head count in the team rotation: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/TeamRot… - 0.3.3 freeze today! Please work on bugs in 0.3.3 as they come up, so we can release it on time! Discussion: - teor: Do we still want a hackfest in May? I need to book flights in the next week or two. I have made a pad so we can pick dates: https://pad.riseup.net/p/0RxS2ZcRe9Eb http://5jp7xtmox6jyoqd5.onion/p/0RxS2ZcRe9Eb - teor: do we want to implement Tor2web overload defences at HSDirs and Intro Points? They can be off by default. But if the load gets worse, we will want them deployed on most of the network before we activate them. Context: https://trac.torproject.org/projects/tor/ticket/24902#comment:16 [dgoulet] I've asked the same question on comment:17 on if we should have them all and backported or only RP and merge the other ones later. teor: - Last week: - Implemented the Tor part of (experimental) PrivCount onion service descriptor fetches - Keeping my relays operating and supporting relay operators - Did not get time to review or revise code, but did review community documents - Damian started on ORPort support for Stem, using Endosome as a scaffold: https://gitweb.torproject.org/stem.git/commit/ Stem now speaks link-layer Tor cells (the link layer is the lowest layer, the higher layers are circuits and streams). - This week: - Implement and test experimental PrivCount onion service stats (This is the last experimental PrivCount feature) - Make a trac user page that lists the tickets I'm working on - Get the test network running new IPv6 consensus code - Maybe I will get time to review or revise tickets this week - It's a short week for me, because Australia has a holiday on the date of the colonisation of Sydney Nick: - Last week: * Worked towards stable releases * Reviewed and merged lots of things for 0.3.3, including vanguards experiment branch * Fixed scan-build * Worked more on getting Tor to be happy restarting in-process - This week: * Release 0.3.3.1-alpha * FEATURE FREEZE BEGINS. (The anti-DoS work has permission to break the freeze.) * Talk with Isis about TLS1.3 work * Merge more things * Continue experiments on killing off ancient clients. * Fix as many bugs in 0.3.3 as possible. * Work on restart-in-process work * Book all travel to Rome dgoulet: - Last week: * My time has been again devoted to DoS mitigation. The ticket is #24902. On Sunday, I've finalized code for the 3 defenses mentionned in the ticket and put the 0.2.9 branch under review. * Starting addressing the review with many fixup commits. * I've opened couple of tickets: #24952 and #24914 * Reviewed and worked on #24895 to have it backported cleanly. * Rome booking is done for me! - This week: * Very high priority for me is #24902 to be merged in 033 as a beta test run and at the same time finalize the 029 branch as we fix things. * If the above can be achieved, I can go back to a more regular work schedule of reviewing tickets, patches and continuing my tor tasks. * Many things have been delayed on my parts and pushed to 034 so I want to go over tickets and mark them accordingly as well as the roadmap. * Profile 032 fast relays to hunt down any high CPU usage that tor-relays@ has been reporting lately (might not only be caused by the DoS). * If time permits, finalizing #24554 which addresses couple important things that needs to be fixed in the scheduler mainly #24700, #23579 and the removal of a lot of memory allocation in the scheduler run. Meeting logs here: ahf Last week: Sponsor 8: - Got SystemTap to work via the 'sdt-inteface' (A DTrace compatible interface to defining probes) such that tracing works on macOS, FreeBSD, and Linux. - Got systemtap to work on device, but it was painful, and just showed the same results as I could reproduce on 32-bit desktop Linux. - Started writing some notes to discuss memory optimization and how far we are interested to go at the expense of code simplicity. Misc: - Reviewed #24652, #21074 - Bug triage This week: Sponsor 8: - Finish memory optimization document. - Discuss initial memory optimization strategies and begin implementing them. - Land systemtap compatible dtrace code. Misc: - Book Rome travel. isis: from dec 19 - now: - prevent bridgedb from handing out bridges in the same /16 (or ::/64) - proposal writing (migration to TLS 1.3) - revised the large create cell proposal to meet concerns/ideas raised in discussion meeting this week: - check in on moat deployment stuff and fix any remaining config problems - organise proposal meetings - phone call with ian to discuss ntor changes - start working on the large create cell implementation - TLS 1.3 meeting in a couple hours catalyst: Last week (2018-W03): - Travis CI workarounds (#24863) - looked a bit more at STACK stuff (#24423) - CoC feedback - slowly recovering from illness This week (2018-W04): - #24661 - look into making our GitHub presence a bit more real - Rome travel stuff - monitor CoC feedback as needed isabela: sponsor4 - I will ask for extension, Matt Finkel and the TB team are helping me figure out how much more time to ask. Hope to request it asap. sponsor8 - Q$ report time. Deadline is Jan 31st. I will start to put things together for it this week. .onion user test - Antonella and I decided to include a test for India meetup, Antonela executed it and just shared results, we will share more soon as we digest it. I will be in seattle Thursday/Friday asn: Last week: - #13837 and #23101 are now merged! Spent some time reviewing and testing this feature this past week. - Spent time reviewing and analyzing the DoS mitigation subsystem of david and roger. Did some review, wrote some unittests, found some bugs. - Reviewed #24894, #24946 - Had a meeting with a researcher about integrating PIR in HSDirs. Helped him with code and chutney/shadow. Likely doing another meeting in a week or two. - Had a meeting with some people who want to implement prop279 on core Tor. Discussed the proposal, made a small implementation plan and planning to meet again in a week or two. - Started hacking on #24896. This week: - More work on the DoS issue since that's the main priority of the network right now. Also finalize #24896. - I have a bunch of prop224 from my service that I need to start analyzing and filing. [dgoulet]: You have log for the non decodable descriptor issue? - Synch up on prop247 with mike. Mike: Last week: - Finishing touches on #13837 and #23101 to get them merged - Updates to vanguards.py to improve circuit length checks and some othe stuff - Wrote fix for a spurious log_warn introduced by #13837 (See #24946) This week: - vanguards.py improvements, prototypes, README, packaging, etc. pastly: Tried 0.3.2.9 in Shadow. Doesn't work out of the box (no surprise). There's a few places Tor assumes it is not 1970, 1972, or 1985. That's not good for Shadow (shadow starts time at unix timestamp 0 AKA jan 1st 1970) Coming up: Work will ya'll to see about not making these assumptions or making Shadow work better. related: - log with two nonfatal asserts http://paste.debian.net/hidden/fd2ce05f/ - probably dangerous/broken/stupid patch that makes hs_get_time_period_num not fail due to it being period number 0 in 1970 http://paste.debian.net/1005897/ - opened #24961

1 0

Tor Browser team meeting notes, 22 Jan 2018
by Georg Koppen 23 Jan '18

23 Jan '18

Hi all! We had the weekly Tor Browser meeting yesterday in #tor-meeting. Here is the meeting transcript: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-22-19.00.log… And the notes from the pad are: Monday, January 22, 2018 Discussion: What to do about the Mozilla team meeting Wens nights Worth making a separate one? Probably can just use this one for now. GSOC Projects? tjr intends to keep the Crash Reporter one up; but took down the 'Making Tor Browser faster' one Will ask Shari for cloud resources if we get anyone tjr: Spectre Stuff I'm working on Timer stuff, taking a lot of my time Moz intends to pursue Fuzzyfox, might land (off or on) somewhere in the post-60 timeframe. JIT Mitigations landing in 59: children of https://bugzilla.mozilla.org/show_bug.cgi?id=1430049 MinGW Going to try and get back in front of this for 60. Beginning with Sandbox uplift, children of https://bugzilla.mozilla.org/show_bug.cgi?id=1230910 for tracking Also trying to uplift these all the way to chromium Besides Sandbox, what is and is not high-priority for me to uplift in 60 for build stuff? Yes: Get the #&$(@& thing running: https://bugzilla.mozilla.org/show_bug.cgi?id=1411401 Yes but not me: Stylo Yes: x64 Patches https://gitweb.torproject.org/tor-browser.git/patch/?id=5aa8644 Any others? https://gitweb.torproject.org/tor-browser.git/patch/?id=ba9e5d6 <- don't need this Yes: Fix the TaskCluster integration on not-central-trees Ideally: jemalloc https://bugzilla.mozilla.org/show_bug.cgi?id=1420350 Ideally: x64 in Task cluster No: WebRTC Discussed Rome in the Sandboxing meeting Related/Unrelated, the timeframe for https://bugzilla.mozilla.org/show_bug.cgi?id=1322426 WAS 'Behind a pref in 61, enable for release in 63' but is now "This will not be happening in the near term, due to staffing changes. It’s not yet clear when or if this will occur." Will need to re-triage Mozilla bugs and plans =( Have a lot of 'For 60' things to work on, so if you have some of those yourself, please let me know. My intention is to search for the whiteboard tags [tor OR fingerprinting which gives this list: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A%5Btor%20OR%20fin… mcs and brade: Last week: - Reviewed Android Torbutton and Tor Launcher proposals and replied on the tbb-dev "Tor Button Proposal" thread. - Found the root cause and proposed a fix for #24421 (Temporarily allow all this page and New Identity). - Posted patches for #21850 (Update about:tbupdate patch for e10s) Planned for this week: - If there is anything we can do to help, assist Matt with #24432 (meek/Moat tunnel) . - After #24432 is fixed, test and put the Tor Launcher Moat integration code out for review. - Work on #24578 (about:tbupdate popup notification formatting error). - Work on #24159 (The Torbutton version check does not deal properly with platform specific checks). - Triage the Tor Launcher bug list (set priorities, close outdated tickets). igt0: Last week: - Moved Tor Button to the browser/extension folder (build system, add files to allowed dupe) - Migrated the chrome.manifest to use jar.mn - Added Tor Button in the tor button mobile omni.jar - Updated the Tor Button Proposal This Week: - Verify why torbutton-logger is not printing debug messages in the console (mobile) - Update the overlay components to work in the mobile browser when needed. (about:addons, extensions, about:tbupdate[maybe not needed, Android has its own thing about updates]) (the work is being made here: https://github.com/igortoliveira/tor-browser) boklm: Last week: - helped with building the new releases - made some patches for #24924, #24931 - opened #24921 to create https://nightlies.tbb.torproject.org/ This week: - publish the new releases - finish fpcentral setup/integration in testsuite to be able to close all fpcentral tickets - enable testsuite on nightly builds and fix any issue in the tests sysrqb: Last Week: - Opened some tickets for Tor Browser for Android (TBA), based on Orfox bugs - Re-wrote some Orfox commits - Wrote a revised TorLauncher proposal - Started looking at Moat - Ran into some problems during Orfox rebase - Investigated Firefox preferences parsing This week: - Finishing Orfox/TBA branch with squashed/rebase/rewritten patches - Investigating why a couple firefox prefs are not overwritten: - On desktop, app.update.staging.enabled is not set correctly - On mobile, browser.casting.enabled is not set correct - Probably look more at Moat server-side pospeselr: Last Week: - Posted a 'fix' for #15599 (by fix I mean it just disables the broken feature) - Started work on #22794, synced with Yawning - made travel plans for Rome - got setup with mozilla testing TryServer This Week: - Get ae patch up for #22794 - JURY DUTY Wednesday -> Friday arthuredelstein: Last Week: - Worked on rebasing to mozilla-central and nightly rebase. Getting closer! - Worked https://trac.torproject.org/projects/tor/ticket/22343 (Save As) - Here's my proposed list of bugs to work on for uplift: https://mzl.la/2E1eVn2 (Deadline, roughly March 12) This Week: - Continue on rebasing - Try to rebase #22343 - Work on uplifting patches - Look at https://trac.torproject.org/projects/tor/ticket/24918 GeKo: Last Week - release preparations and working on the Tor Browser design doc update This Week - finish the design doc update and work on the toolbar and security indicator improvements proposal isabela: 2 months extension for sponsor4 sponsor8 Q4 report - I will probably ping some mobile folks and geko to make sure I collected all the tickets etc antonela did user testing in India! o/ Tor Launcher new UI (tested text interpretation of our new copy) and .onion http/https states icons comprehension - will share more soon also want to check if arthur/geko can meet about tor circuit (probably next week) ux team will help with the blog post for the release - add stuff about the Tor Launcher new UI Georg

1 0

Notes from January 18 2018 Vegas team meeting
by Karsten Loesing 19 Jan '18

19 Jan '18

Notes for January 18 2018 meeting: Alison: 1) I spoke to librarians at the University of Washington this week. It was great! 2) Sukhbir will give two Tor talks in India over the weekend. 3) Work continues on the relay operator wiki. 4) Working on some ideas for how the open hack days at the meeting could go. Will share soon. 5) Also incorporating other feedback from the Montreal survey into Rome meeting planning. 6) Fielding lots of questions about LFI. 7) CoC proposal is out! I am going to work on incorporating some of the latest feedback today. 8) Preparing to speak at Georgetown next week. Roger: 0) Arturo, can I ask you to call the (three) Rome hotels and tell them you have a strange American friend who wants a 19 degree room and tell me which one laughs the least? 1) I'm revising the penn-sow.pdf after initial feedback from the funder ("make it more researchy"). 2) Follow-up from last week about relay operator meetup planning Georg: 1) Preparing Tor Browser 7.5 and 8.0a1 releases Nick: 1) Mostly working on software. 2) Stress as usual with upcoming feature freeze for 033. But with luck we'll get a guard-discovery mitigation (vanguards) and a DoS mitigation soon? DoS mitigation may be allowed postfreeze. Mike: 1) Yay software. No distractions :). Karsten: 1) Spent a few days refactoring the graph history code in Onionoo, which will help fix a recent bug and also make this code more maintainable in the future. 2) Continued implementing the web log sanitizer for CollecTor. 3) Realized that we cannot keep implementing new features and that we instead need to focus more on our paid deliverables. Brainstormed some good ideas together with Isabela today to fulfill our commitments without disappointing other folks too much. Arturo: 1) Released a new version of OONI Probe mobile with support for testing IM apps: https://twitter.com/OpenObservatory/status/953316589494968320 2) OONI Probe CLI now speaks to the OONI Probe desktop and it's possible to start tests from the desktop app 3) Had various incidents in our infrastructure related to the rollout of the Spectre and Meltdown patches: https://github.com/TheTorProject/ooni-sysadmin/issues/196, https://github.com/TheTorProject/ooni-sysadmin/issues/197 4) Progress on implementing revamped OONI Explorer 5) Preparing OONI reading materials and assignments for the participants of an upcoming research workshop in Uganda 6) Heads up, if you need me to do things related to the Rome dev meeting, let me know soon, as this Saturday I am leaving for Africa and will not be in Rome until March isabela: 1) sponsor9 plans are out o/ 2) sponsor4 - preparing to ask for extension and finished work completion reports 3) User Testing in India this Saturday! RSVP sold out in 1 day (total 25ppl) - more information here: https://docs.google.com/document/d/1KdnEsAlXdkQT4EBsRUAEgzqz5lkdmjNBUB29YfE… 4) Support site tasks are moving on, soon something should be up for people to look at. todo list we are using is here: https://pad.riseup.net/p/support-tpo 5) Picking up on sponsor8 Q4 report. 6) Next week I am in Seattle for grant/funding meeting 7) Next week - work on Tor Launcher new ui release Shari: 1) personnel stuff 2) hiring new CG&FO 3) pulling together some stuff for board (Anyone have ideas for a good video meeting platform that is secure and stable? [What are the requirements? How many people need to be doing video, is it only voice and video or also screen sharing? Is installing extra software OK? ~ Arturo] installing extra software is okay. we're talking about 10 people. we don't need screen-sharing, although that's a nice feature. it doesn't have to be free) 4) following up with Pineapple guy 5) pulling some materials for Tommy for grant report he's working on Steph: 1) Working through backlog from holiday 2) Published / sharing volunteer spotlight on Alec that Tommy wrote 3) Editing copy on style guide website - looks cool! 4) Publishing post on onion services to encourage sites to use EOTK next week. Will personally reach out to some sites. Antonela made an awesome graphic for it and the guide to running a relay! 5) Talking to Rob about the paper on onion service popularity measurement 6) Preparing for upcoming NYC meetup, meeting tomorrow

1 0

Crowdsourcing some guidelines for what it means to make a web site "Tor-friendly"
by Allen Gunn 17 Jan '18

17 Jan '18

Hello friends, I hope 2018 is off to a good start wherever this finds you. So for those who aren't aware, my NGO, Aspiration, advises other NGOs and activists on technology as part of our core mission. And a common piece of advice we proffer is "make sure your web site works well with Tor Browser", i.e., doesn't use Flash or overly depend on Javascript. The more I have given that advice, the more I have wondered if it was documented anywhere what it actually takes to be a "Tor-friendly" site. Big thanks to GeKo, who first confirmed for me that no such documentation seems to exist. And then for helping me to bootstrap this page: https://pad.riseup.net/p/torfriendlysite I'm writing to ask folks on this list to both add any thoughts you have on the matter, and to correct or comment on anything that's already there and doesn't seem quite right. Any contributions, both to the pad or emailed to me directly, are most appreciated. This is especially true if you know of relevant documentation anywhere else that I should be looking at. Once folks have weighed in, I will figure out where to post this on the Tor wiki and elsewhere in order to make it more broadly and reliably available. And if for any reason you think this is an ill-informed endeavor, I welcome that feedback as well :^) thanks & peace, gunner -- Allen Gunn Executive Director, Aspiration +1.415.216.7252 www.aspirationtech.org Aspiration: "Better Tools for a Better World" Read our Manifesto: http://aspirationtech.org/publications/manifesto Twitter: www.twitter.com/aspirationtech

5 9

"Capture the onion" + Tor village at next Defcon
by Roger Dingledine 17 Jan '18

17 Jan '18

tl;dr I would like to (A) design a "capture the onion" contest to get people trying to break the next-gen onion service protocol and code, and run the contest at the next Defcon; (B) craft a funding proposal to help us do A well; and (C) run a Tor village at the next Defcon too. Part A: We have this new onion service design, and one of its features is that we hope it is now impossible to discover onion addresses through in-protocol flaws. How do we know that we designed it right? How do we know that we implemented it right? Imagine if we deploy a local Tor network on the Defcon network, where random Defcon attendees can run relays. The anonymity properties would be terrible, because the trust isn't distributed over a large area and because Sybil attacks and other shenanigans are likely. But new-style onion services should be able to advertise themselves, and have their onion address remain private, even in this terrible environment. The goals of the contest would be getting people to (1) beat on our new onion service design, and (2) learn more about the Tor design and code. A proper contest has a variety of puzzles at a variety of difficulty levels. (If the only challenge were to uncover our private new-style onion addresses, most people would fail, and they would quickly become bored.) So we would want to include intermediate challenges. One example would be to run old-style onion services too, since there are known attacks against the old design. In an ideal world we'd brainstorm 15 or 20 puzzles, not all onion service related, to keep the attention of a variety of skill levels, and more importantly to raise the amount of Tor clue for people at each level. (The way you actually "capture" an onion could be by visiting the website behind it, and being given a token that proves you went to it.) Many fun contest designs include both offense and defense, i.e. they pit teams against each other rather than against the game itself. I don't know how to make use of this point, but maybe we will come up with ideas. I also pondered whether we could team up with an existing contest, e.g. ask the capture-the-flag people to be a module in their bigger plans. But capture-the-flag has been going through contortions to keep the offense from being too easy -- for example, this year they surprised people with a 27-bit architecture that uses 9-bit bytes and is middle-endian. Sounds fun if you're into that, but maybe not so useful for our needs. :) Part B: Our SponsorR program manager has expressed interest in helping to make this idea happen. In fact, it started out as his idea. He's asked us to put together proposals for the low end, the medium end, and the high end of what it would cost. (I asked him for hints on what he meant by each category, and he wouldn't commit, saying instead "whatever it would cost".) Piece one that would want attention is contest design, i.e. coming up with the puzzles, and figuring out how one would implement them, and also balancing the game so it's fun -- everybody can make progress at something, there aren't any puzzles that will destabilize the whole thing, it's clear who made the most progress, etc. Piece two would be sorting through how to harden a Tor network to survive being run in this terrible environment. We'd probably want to make the directory authorities more robust, like by making them onion services themselves, and/or making them "push" the consensus to the fallbackdirs rather than being able for pulls. This piece could involve large amounts of design and coding, so we'd want to make a roadmap and prioritize items. (We will want to declare certain types of attack out of scope for the contest, and frowned upon if people do them, but also we will want to show up with a robust network.) Piece three would be the actual operations of the contest, including deploying the network and sandboxing the components, but also including running everything during the weekend. The first year will be a learning experience all around, but the more we can learn surprising things rather than expected things, the better. :) We might also be wise to deploy the network, and parts or all of the game, beforehand for playtesting. And I bet some of the puzzles will work better if people know about them, and prepare for them, beforehand. Part B2: Now, there is a strong argument that if what we want most is an exploit on the new code, we should sign up for Pwn2Own or the like, and offer a $10k+ prize. After all, weekend contests are fun for raising interest and getting people to learn more, but in isolation they may not be an efficient way of getting people to discover complicated bugs. I think it's worth exploring both approaches, and maybe combining them in some cool way if we can think of how best to do it. Note that we already have our bug bounty program in place, and it would be very straightforward to highlight and advertise this category of bug for the top tier $3k payout, or even a higher payout if we wanted. But coordinating with a higher profile zero-day event could still bring more attention to the topic. Part C: A bunch of people I ran into at Defcon expressed interest in a Tor village next year. Rather than taking on all the logistics issues ourselves, I've instead been coordinating with organizers from two existing villages, who each have no plans to use their village space from 5pm onward each evening. This way we could have a designated "hang out and answer Tor questions" spot, with quite low logistics costs. And if we wanted to make it into something more we could. Eight years ago, when I was last at Defcon, I saw many many Tor shirts. This year I saw almost none. We have definitely been paying less attention to the American hacker scene lately than we should have been. I think it would be really great to get a huge pile of Tor shirts there next year, perhaps with a table in the Tor village, and perhaps also at already established booths like EFF and Calyx. --Roger

2 2

Weekly network team notes, 16 Jan 2018
by Nick Mathewson 16 Jan '18

16 Jan '18

We're halfway through the month. Here's our meeting logs: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-16-18.00.html The notes from our pad are below: ========================= Network team meeting pad, 16 January 2018 "I didn't get where I am by having reasonable goals" ― Ann Leckie, "Ancillary Justice" Welcome to our meeting! This Tuesday (usually Mondays) at 1800 UTC on #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see anything you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! Note the meeting location: #tor-meeting on OFTC! (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) Meeting notes from last week: * https://lists.torproject.org/pipermail/tor-project/2018-January/001622.html Old Announcements: - On the roadmap spreadsheet: Please take january tasks. (If somebody else has already taken something you want, please talk to them and/or add yourself too.) https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdr… - Soon it will be It is now time to triage 0.3.3.x tickets. Please make yourself the owner of tickets in that milestone that you will do. - The meeting time is now 1800 UTC. - Let's have some proposal discussions. Isis kicked off the process here: https://lists.torproject.org/pipermail/tor-dev/2017-December/012666.html - We are planning a single-day pre-planned highly-focused hackfest before the Rome Tor meeting - teor: Jon says we will have a venue for the pre-Rome hackfest - komlo: Should there be a Rust update/planning session? What should we prepare/do beforehand to help this be planned/highly-focused? Announcements: - Tor 0.3.2.9 came out last week - review-group-29 is open, there are 3 tickets left in needs_review: https://trac.torproject.org/projects/tor/query?status=needs_review&keywords… - We are planning a single-day pre-planned highly-focused hackfest before the Rome Tor meeting - teor: See the network team list for venue details. I will confirm the venue with Jon about 4 hours after this meeting. Please email me if you have objections. - We need head count in the team rotation: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/TeamRot… - Freeze next monday! Discussion: - DDoS mitigation in #24902. Basically, we need eyes on the overall design/code. If we can not let that rot for 6 months, it would be really nice because I do believe we really need this right now. - teor: - Last few weeks: - Experimental PrivCount fixes and input data preparation - Helped with network load issues - learned iptables in a hurry - Got a new fallback list merged into 0.3.2.9 - Specified a common format for the authority list and fallback list - This week: - Implement (more) PrivCount onion service stats - Get the test network running new IPv6 consensus code - I want more time to review or revise tickets, not sure if it's going to happen asn: Last week: - Helped review, fix and test #13837 and #23101. They are now in merge_ready and ready to get reviewed by Nick or others! That was lots of good work to stabilize this feature, and it represents a good manual solution for the guard discovery issue until we figure out how to do prop247 (or others) correctly. - Attended RWC. Did a lightning talk on Tor open research problems. I had a few people and researchers approach me afterwards for running a relay or doing research on Tor. I pointed them to the right mailing lists, anonbib, etc. - In RWC, I also talked with Jean Paul Degabriele about wide-block designs and some potential drawbacks of that approach (see https://www.youtube.com/watch?v=8FFVCWWpygE) - In RWC, I talked to some researchers about some potential projects on Tor+PIR. This week: - Get #13837 and #23101 merged. - Do review-group-29. - Write an email on thoughts about prop247. - I have a meeting on implementing proposal279 on Friday with some people I met IRL. - Checkout #24902 --- the DoS mitigation thing dgoulet: dgoulet: Last week: * Spent almost the entire week on circuit creation DoS mitigation. Code exists in #24902 for which I've been running it for ~5 days now. * I'm late on everything I had in the pipe and consenquently for 033 merge window. Sorry if anyone is waiting on me. This week: * Hope to regain a bit of a normal state so I can progress on other things for 033. * Work on opened tickets and review * Still need to investigate a couple of things with regards of this DoS including if Tor can open multiple connections to a relay in parallel. ahf: Last week: Sponsor 8: - Talked with David about his ideas about the current tracing subsystem in Tor and how to extend it with systemtap/dtrace. - Continued looking into container memory usage in different subsystems: protover, directory*, connection code. - Extended DTrace code with probes in different parts of the codebase: bootstrap, containers, allocators. Misc: - Read up on arma's PT/Snowflake proposal, looked at what Snowflake is/does. - Wrapped my head around dgoulet's DoS protection subsystem. - Reviewed #24641. This week: Sponsor 8: - Land DTrace code + DTrace programs to tor.git with some "simple" hooks focused around the bootstrap process. - Ensure the DTrace probes with SystemTap (DTrace'ish thing for Linux). - Test SystemTap directly on Android device. - Compile some sort of document that allows us to discuss memory optimization strategies. catalyst: Last week (2018-W02): - investigating Travis CI failures with clang (#24863) - reviewed #24423 (STACK warnings) - more work on #24661 - took Friday as a sick day due to spending all afternoon in Urgent Care -- still unwell but recovering This week (2018-W03): - monitor the Travis issues and submit workarounds if needed. any opinions on how long to wait for a fix from Travis before applying a workaround? - follow up on STACK stuff if needed - monitor CoC feedback - do some prerequisite refactoring for #24661 Nick: Last week: - followed up on proposal 285 (utf-8) - started revising proposal 286 (hibernation interface) - wrapped up review-group-28, and my part of review-group-29. - worked on STACK issues - commented on CoC discussions - Followed DoS threads - Worked on experiments for how to disable ancient zombie tor clients gracefully. - Reviewed a proposed statement of work for roger This week: - Follow up on open proposals again - Maybe open review-group-30. (If you want your 0.3.3 patches reviewed before the freeze, please review stuff in review-group-29. Especially if you haven't been reviewing so much!) - See how many quick-and-dirty 0.3.3 things I can do. - Maybe, put out some stable releases? (After discussion: No, do it next week, to get more DoS fixes in them.) - Go through codebase, looking for restart-in-process issues - check if we can improve crypto performance with omit-frame-pointer isabela: sponsor4 - figuring out how to solve the dependencies on network team sponsor8 - probably wont have time to start report this week but will see :) sponsor bucket - things are moving on thanks to Roger (reviewed his work plans etc last week) Organizing nyc meetup meeting this wed at EST 7pm on tor-meeting channel User testing on India - we want to include something related to the .onion states (give more updates on it next week)

1 0

Tor Browser team meeting notes, 15 Jan 2018
by Georg Koppen 16 Jan '18

16 Jan '18

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project January 2018