December 2017 - tor-project - lists.torproject.org

Are there countries where using Tor is illegal?
by Cristian Consonni 12 May '25

12 May '25

Hi, (Sorry if this question has already been asked in the past, feel free to point me to the relevant resources.) I know that the legal FAQs by the EFF state that: «we believe that running a Tor relay — including an exit relay that allows people to anonymously send and receive traffic — is legal under U.S. law.»[1] I also know there is a list of countries for which there is legislation that exclude communication service providers from liability. They are indicated in the Legal of the Tor Exit Guidelines page[2], they are USA, Germany, Netherlands, Austria, France, and Sweden. >From some articles in the press[3a][3b] it may be illegal - depending on how you interpret the wording[*] - to use Tor (and other technologies such as VPNs or proxies) in the UAE, with fines ranging in the millions of dirhams (hundreds of thousand of dollars). A couple of weeks ago it was discussed - on this list as well - that a law was introduced to the state parliament to ban Tor[4a][4b]. This follows a case of some months ago of a Russian Tor exit node operator being arrested for inciting mass riots and terrorism[4c][4d]. The idea of blocking VPNs or Tor seems to have already been considered in the past[4e]. This infographic about pluggable transports[5] suggests access to the Tor network is censored or limited in China, Uzbekistan, Iran, and Kazakhstan. Tor being censored orblocked may be different from it being illegal. What about other countries? Is there a place where I can find more about this topic? Cristian [1]: https://www.torproject.org/eff/tor-legal-faq.html.en [2]: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines [3a]: http://www.emirates247.com/news/emirates/dh500-000-fine-if-you-use-fraud-ip… [3b]: http://news.softpedia.com/news/people-caught-using-vpns-tor-or-proxies-in-t… [*]: «Whoever uses a fraudulent computer network protocol address (IP address) by using a false address or a third-party address by any other means for the purpose of committing a crime or preventing its discovery» [4a]: https://lists.torproject.org/pipermail/tor-talk/2017-June/043293.html [4b]: https://trac.torproject.org/projects/tor/ticket/22055 [4c]: https://lists.torproject.org/pipermail/tor-talk/2017-April/043109.html [4d]: https://techcrunch.com/2017/04/24/dmitry-bogatov-tor-russia/ [4e]; https://torrentfreak.com/vpn-and-tor-ban-looming-on-the-horizon-for-russia-… [5]: https://www.torproject.org/images/PT/2016-07-how-to-use-PT.png

4 3

"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

Intent to Minimise Effort: Fallback Directory Mirrors
by teor 09 Jan '18

09 Jan '18

Hi, Fallback directory mirrors help Tor clients find the tor network, and take load off Tor directory authorities. [0] Since Tor 0.2.8, I've generated a fallback directory mirror list every 6 months or so. I'd like to minimise the amount of effort I put into this in future. (But I think it's valuable, so I won't abandon it.) I'm happy to spend half a day every 6 months to update the input lists and run automated checks on a bunch of relays [1]. But contacting relay operators to agree to go on the list (opt-in), or check their relay details, is a time-consuming process. Here's what you can do to help: * We ask relay operators to opt-in. We could ask them to opt-out (contact us to be taken off the list) instead. The opt-in list hasn't been updated for about a year, so we will have to switch to opt-outs soon to get enough good fallbacks. - If we do opt-ins, who is going to contact relay operators? - If we do opt-outs, how do we make sure operators know they can opt-out? - (And how do we make sure we get stable relays?) * I wrote down the opt-in process in [1]. Maybe it's too complicated. - Can you design a better process? * If you're good at mail merges or scripting mail, that's one way we could contact a bunch of relay operators without it being time-consuming and error-prone. - Can you do mail merges? (I can't!) * We can improve the fallback script to make it easier to use. (See [1] and [2].) - Can you write python? If anyone wants to help out with any of these things, let me know. I'm going to do a fallback directory mirror refresh some time in the next few weeks. About 12% of fallbacks have failed, and it looks like this is placing extra load on the directory authorities. [3] There's already a ticket for it [4], and I'm happy to do a minimal refresh. If we don't get 150 fallbacks from a minimal refresh, I'll switch to opt-out and see how that goes. [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [1]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [2]: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… [3]: https://lists.torproject.org/pipermail/tor-relays/2017-August/012886.html [4]: https://trac.torproject.org/projects/tor/ticket/22271 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

4 7

Notes from December 21 2017 Vegas team meeting
by Karsten Loesing 22 Dec '17

22 Dec '17

Notes for December 21 2017 meeting: isabela: 1) we need Tor weatherperson - someone to keep an eye on the network and see what relay is misbehaving, or when metrics starts to go crazy and dig in to figure out ssup. Or in other words someone to do what dgoulet has been doing on the top of everything else he does 2) after traveling and non-stop meetings (very productive btw) together with my computer breaking - I got behind on some work but I hope to get those done specially the priorities: emailbundle+onionservices otf proposal, Sida work plan and sponsor4 invoice reports 3) will be in SF jan 2nd to 5th working from somewhere (not sure where yet) in case ppl want to meet. 4) Roadmaps! - how are teams with coordination with other teams for dependencies etc? Roger: 1) Israel talks went well. I visited Palestine too. Though now I'm sick. 2) I've rebooted the "circumvention pass-through funding" discussion. 3) Alison, Steph, should we do the transition of frontdesk to an alias? Anything still blocking that? (Answer: they figured out a way to make rt more fun to use, so need to switch it to an alias at this time.] Alison: 1) recruiting for Library Freedom Institute (libraryfreedomproject.org/lfi) !!!!! and working on curriculum design. blog post is going up about this on Friday. deadline for applicants is February 1. anyone who wants to see the curriculum so far is welcome to contact me. 2) Pari is ready to start sending user issues updates to tor-project(a)lists.torproject.org. 3) Phoul and I are adding more to the support portal content based on what Pari found. 4) working on relay ops wiki with Phoul, nusenu, irl and others (https://trac.torproject.org/projects/tor/wiki/OperatorsTips and #24497). I hope we can finish the remaining TODO items and then publish a short blog post announcing this very soon. Eventually this documentation will live on community.torproject.org 5) code of conduct draft will go out for proposal after the break 6) prepping for January Sponsor 9 tasks 7) speaking at University of Washington and Georgetown in January 8) Phoul is working on some issues with Transifex that's causing problems with getting our downloads page translated Steph: 1) Campaigned hard to raise 5k to see someone eating an onion in the Tor office. We got $20,000 (not counting Mozilla’s match). The Seattle office filmed, and I edited. We sent an email and tweeted almost hourly 2) Tommy, Shari, and I are finishing up final EOY fundraising items. 3) I’ll be creating a one pager on Tor which dispels “dark web” concerns for donors to use internally to be ready end of Jan/ early Feb. 4) Scheduling content to go out over the break. Will keep checking in with social media Mike: 1) Working with Isa, Suhke, and Tommy on stories and concept note 2) Trying to wrap up guard-related tickets for 0.3.3 Shari: 1) Met with auditors. Trying to get 990 out the door before the holiday. 2) Lots of end-of-year campaign stuff. 3) Contacting major donors next week to remind them to give before year is up. Karsten: 1) Changed ExoneraTor to only serve completed dates, which excludes the current day and the day before that. 2) Released Onionoo 5.0-1.9.0 which removes $ from fingerprints in family fields. 3) Changed metrics-web from being a Tomcat web application to shipping with an embedded Jetty. 4) Put out internal releases of metrics-web and ExoneraTor to facilitate development for new contributors. 5) Published blog post on Relay Search improvements: https://blog.torproject.org/we-made-big-improvements-searching-relays 6) Started looking into OONI's vanilla Tor data analysis, but need more time for a useful response. Nick: 1) Working on DoS issues, trying not to have extra work looming over us for next week. 2) I've nearly lost track of roadmap stuff; going to spend any remaining time this week on organizing things for early 2018. 3) Aiming for stable 0.3.2 on 8 Jan. Arturo: 1) Preparing the OONI CCC presentation: https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8923.html 2) Most of our team is not going to be very available in this period for festivities + 34C3

1 0

Ongoing DDoS on the Network - Status
by David Goulet 21 Dec '17

21 Dec '17

Greetings, Earlier this month, many relay operators started noticing huge loads on their relays both in terms of traffic and memory consumption leading to relays malfunctionning or even dying in some cases. We've started looking at this in depth in the last few days. It turns out that many relays (not all) are under a distributed denial of service (DDoS) attack which makes them use a lot of memory ultimately making the operating system stop the process or becoming unreliable because of the resource pressure. This has lead to some relays to restart, being shutdown or becoming so unstable that they would fall in and out of the network. You can see here on the Metrics portal the consequences of this ongoing attack: https://metrics.torproject.org/relayflags.html?start=2017-09-20&end=2017-12… Among other things, it is badly affecting relays with the HSDir flag because once they restart, it takes 96 hours before they get the flag back. This affects the reachability of hidden services and thus the UX of .onions. We've been analyzing some relays being flooded to understand what is going on and how to fix it. The good news is that we are fairly confident that we know what is happening and we are currently testing some fixes to address the situation. In the meantime, if your relay is under heavy memory pressure that is tor is taking a huge amount of RAM making your machine fail to operate properly, you can set the MaxMemInQueues option in your torrc file to a reasonable upper limit which limits the amount of memory used by tor. At least 2GB if you can for a fast relay is usually a good value for tor to operate properly and not degrading performance too much. With this, if the memory usage reaches that limit, tor's OOM (Out Of Memory handler) will kick in and cleanup what it can. It is still possible that your relay goes above the limit, it is one of the thing we are currently investigating. However, it should not grow indefinitely. Thanks everyone and we'll hopefully resolve the situation soon! David -- aFJe0kbRB1zZXgwFQIvBG0Skn3xAsDGxVQsAiguKjY8=

1 0

Tor Browser team meeting notes, 18 Dec 2017
by Georg Koppen 19 Dec '17

19 Dec '17

Hi All! We had our last Tor Browser meeting in 2017. Here is the meeting transcript: http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-12-18-19.00.log… And the notes from the pad are: Monday, December 18 Discussion: -next ESR will potentially be Firefox 60 sysrqb: Last week: - Reviewed and cherry-picked orfox commits onto 52.5.2esr-7.5-2 - manual testing on android emulators is successful, so far - Started looking at unit testing - I'll push a public branch today for review - Began looking at XUL->WebExtension migration for tor-launcher This week: - Push branch for review - Continue testing - Compare orfox and TB for Android fingerprinting with Panopticlick mcs and brade: Last week: - Completed code reviews for: - #23104 CSS line-height reveals the platform - #23016 "Print to File" does not create the expected file - #24398 Plugin-container exhausts memory - #21847 Update copy for security slider to be consistent with mobile - Provided patches for: - #24623 revise "country that censors Tor" text - #24624 tbb-logo.svg may cause network access - Worked on Moat integration for Tor Launcher (#23136). Planned for the remainder of 2017: - Take some time off to celebrate Christmas with our family. - Help with code reviews and bug triage. - More work on Moat integration and other aspects of the new Tor Launcher UI. - The code is nearly done. To do: - Test proxy support. - File tickets for any remaining loose ends. - Make the code available for preliminary review. - BUT: there is no public server with which to test :( igt0: Last Week: - Looked into Tor Button and make sure we can use WebExtension (https://paste.debian.net/plain/1001343) - Looked into tbb-tests to verify what tests are missing for the Tor Button * drag and drop filter test (src/components/dragDropFilter.js) * Content policy (src/components/content-policy.js [there is a fix for gecko, however it would be great to double check]) - Updated the #22084 (merged) This week: - Write tests for Tor Button - Start the tor button for mobile proposal GeKo: Last Week: -Release preparations -Reviews (thanks to mcs/brade for the help) -Wrote a fix for #21847 -Looked again into Cloudflare's Privacy Pass -Took up again work on updating design document This Week: -Signing 7.5a10 -Work on the design document -Work on #24421 -Traveling on Thursday, and planning to take Friday off boklm: Last Week: - Mozilla All Hands This week: - publishing 7.5a10 - will ping sysadmins about #24585 and check if anything more is needed - work on other tbb-rbm tickets arthuredelstein: Last Week: - Mozilla All Hands This week: - #23930 (mac font crash) - #18101 (windows and mac file dialog leaks) - #22343 Save as FPI - #14952 Enable H2. And I will be afk for the week of Dec 25 - Jan 1. - pospeselr: Last Week: - Mozilla All Hnads This Week: - #15599 (pdf.js range-based requests using default circuit) tjr: Last Week: - Mozilla All Hands - Learned a tiny bit more about Canvas Fingerprinting (namely that 40%+ of FF users on Windows already do software rendering) - Fusion stuff sent to the list - The sandboxing team would like to remove --disable-sandbox sometime in the future, so uplifting the sandbox patches is medium-term priority - There is early discussion about using a broker process (on Windows at least) which would enable flexibility to sandbox the parent process isabela: Last week: - Mozilla All Hands - lots of good conversations and exciting things going on This week: - mobile folks meeting - topic: gecko view and the android roadmap for 2018 (ux team and mobile team cooperation) - mcs + brade -> can we sync with isis on wednesday at 2000UTC on #24636 and #24637 (or any other blocker you might have for moat integration) - for anyone who cares we are having another sync on .onion states this wed at 1900 utc Georg

1 0

Meeting notes, network team meeting, 18 Dec
by Nick Mathewson 19 Dec '17

19 Dec '17

Hi! Our transcript is available at http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-12-18-17.59.html . I copy-paste our pad below: ========== Network team meeting pad, 18 December 2017 "Why," Leo's eyes widened with delight, "it's an engineering problem after all!" -- Lois McMaster Bujold, _Falling Free_ Welcome to our meeting! Every Monday at 1700 UTC 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/2017-December/001598.html Old Announcements: - On the roadmap spreadsheet: Please take december/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. - The _free() patch got merged so I would like to bring this to everyone attention: doc/HACKING/CodingStandards.md -> Allocator conventions - Tor 0.3.2.7-rc (or alpha) came out last week - Let's have some proposal discussions. Isis kicked off the process here: https://lists.torproject.org/pipermail/tor-dev/2017-December/012666.html Announcements: - 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? - review-group-27 is open, there are only 2 tickets left https://trac.torproject.org/projects/tor/query?status=needs_review&keywords… - No regularly scheduled network-team meetings on 25 Dec through Jan 5. Next team meeting is 8 Jan 2018! - Please check in with the roadmap; december is almost over as a working month! What isn't getting done? How are we doing? Discussion: - How shall we revise the 0.3.2.x schedule? - And should we revise the 0.3.3.x schedule accordingly? 18:31 <+nickm> how about we aim for jan 8 for stable (if possible), and delay feature-freeze by 1 week on 0.3.3? - strategy/plan for addressing current network issues. dgoulet, nickm, teor, isis try to figure it out. teor: - Last week: - PrivCount fixes and performance improvements - Admin for collecting research data - Got an equal-area projection for metrics maps (thanks, cyperpunks!) It's been deployed at https://atlas.torproject.org/#map Gosh, the southern hemisphere is big. And we have almost no relays south of the tropic of cancer. - Various security stuff and code reviews and helping volunteers - Booked flights for Rome - Tried to kick off the fallback directory rebuild, but didn't get time to review the tickets - This week: - It is a short week for me, I am on all-volunteer time / holidays from Wednesday onwards - Work on getting the test network running new IPv6 consensus code - Revise some of the IPv6 patches - Rebuild fallback directory mirrors, along with whoever is around at the time (pastly, Hello71, let's make a time to do fallbacks? Or talk on tor-dev@?) How about this week's patch party? (pastly) - Review some other volunteer tickets asn: Last week: - Reviewed mike's #13837 and #23101. - Restarted coding the prop247 simulator. Requires more work!! - Reviewed #23271 from ffmancera. - prop224 work: Develop and review on #24595. Worked on #24610. - Met with David Stainton, Moritz and others. Talked about relay load balancing and bandwidth dirauths. People are sad about the state of the network: some relays are overloaded while others idle, many overloaded relays cant even establish circuits to each other. Need to do something about it: deploy bwscanner and start thinking about peerflow. What about isis' bridge bandwidth scanner? This week: - Second round review of mike's #13837 and #23101. - More work on prop247 simulator. - Try to make a plan forward for the bw auth work. I'm really hoping we can find someone to work on this!!! Nick: Last week: - Reviewed a panoramix design thing for dawuud - Finished rust privcount proof-of-concept implementation - Read a bunch of rust documentation - Released 0.3.2.7-rc - Made progress on diagnosing and fixing 23847 (Make sure Tor can shut down via control port, and start again in same process). It's not perfect now, but at least it doesn't automatically crash like it used to! It'll be cool if mobile devs try it out - Diagnosed 24367 (Changing pluggable transports (during start-up) in Tor Browser is broken) and tried to fix it. Fix is either wrong, or incomplete. - Fix other issue encountered while looking at code for above. - Review, review; merge, merge. This week: - Try to help with dos issues, if I can - Try to finish a working fix for 24367 - Review review; merge, merge. - Revise recent needs_Review tickets - Check-in with december roadmap; december is nearly done. Mike: Last week: - Updated #13837 and #23101 based on asn and dgoulet's code reviews - Reviewed #24613 - Fixed a memory leak in the circuitstats unit tests. - What is the official valgrind options/leak checking thing? valgrind --leak-check=full --show-leak-kinds=all has lots of noise. This week: - Continued #13837 and #23101 updates - #244847 isabela: Last week: - met with nick, ahf and catalyst on sponsor8 Q4 work - was at Mozilla All Hands This week: - sent update to list about follow ups from Mozilla All Hands - isis - bugs #24636 and #24637 are blocking TB team on moat integration [please prioritize these, the TB team deadline is getting close] - need to follow up on all sponsor8 discussion from last week - sync on .onion states experience w/ asn, antonela and geko [wed at 1900] [asn: sounds good] komlo (offline): - Last week: - Submitted #23881 (tor logging) for re-review. - This week: - Pick the next piece that will be helpful to improving support for Rust in core tor. I wonder if #24249 (minimal automated mechanism to keep C/Rust types in sync) will be a good next step? Especially toward making future/current Rust work in core tor easier to maintain. If there is other low-hanging fruit that will be more helpful, let me know. - Helping on #24030, which someone picked up as their first tor ticket (which is great) ahf Last week: Sponsor 8: - Uploaded patches for event loop metrics (#24605). - Looked into testing if the monotime fixes have helped us on 32-bit arm: https://people.torproject.org/~ahf/sponsor8/20171217/ (#24613 + #24374) - Status meeting with Catalyst, Nick, and Isa! Misc: - Looking into the HSv3 service issue(s) that David is now digging into. This week: Sponsor 8: - Talk with Nick about next steps with CPU optimizations: - Remaining udivdi3 issues? - SHA3 ? - See if I can get Shadow to run on device/emulator to be able to run more deterministic experiments on Android. - Finish my script to `bench` tests individually with automatically generated graph+report.txt from Simpleperf. - Finish Q4 reporting (missing the benchmark info). Misc: Going to 34c3 between christmas and NYE, back Tuesday the 2 of Jan. 2018 catalyst: Last week (2017-W50): - sponsor 8 status meeting - helped review STACK patches some more - looked more at delaying descriptor downloads if we'd get stuck without a live consensus where we need one - looked at failing offline Rust builds in Travis (thanks isis!) - upgraded my virtualization infrastructure (with minor obstacles) - fighting medical billing bureaucracy This week (2017-W51): - more work on delaying descriptor downloads - somehow need a cheap way to ask guard subsystem whether it would need a live consensus to make progress; this would get called from periodic callbacks so counting smartlist entries each time probably isn't a great idea - vacation 12/22 (also 12/25-1/1 along with most of TPI) dgoulet: Last week: - HS IPv6 work starting with the unify link specifier ticket #22781. - Some scheduler work on #24554. - Investigated #24011 but wasn't able to figured it out :S - Dirauth have been notified and they are now broadcasting the consensus param hsdir_spread_store=4. #24425 - Investigated #24610 HS bug and tried to come up with a fix. This week: - Try to wrap up #22781 hopefully and continue the IPv6 HS work (see tor-dev@ thread about it that teor started). - Follow up on #24554. - Review group and ticktets for 032. - Do some more triaging on 033. isis: last week: - proposal discussion meeting for prop#249 - began writing a proposal to migrate to TLS 1.3 - began writing a proposal to use ECDH+SIDH for relay-to-relay TLS connections - worked on #23886 (fn pointers to ed25519-dalek), - #24608 (cargo issue causing build troubles for us), - several moat/spec bugs #24433 - how do we want to do low-level external crypto dependencies in our rust code? (i.e. sha2/sha3 getrandom()) [nickm: i have thoughts here; let's talk on tor-dev after the meeting? ] - this week: - vacation starting friday (through NYE)

1 0

Notes from December 14 2017 Vegas team meeting
by Karsten Loesing 15 Dec '17

15 Dec '17

Notes for December 14 2017 meeting: Alison: 1) our Outreachy intern Pari is doing an amazing job organizing user issues and support questions to eventually share monthly with tor-project@ 2) Library Freedom Institute is now seeking applicants for the June 2018 cohort! libraryfreedomproject.org/lfi. 3) gonna send the draft of meeting invites to tor-internal today 4) working on the Tor relays wiki (#24497) Georg: 1) The security releases (Tor Browser 7.0.11 and 7.5a9) got out, finally 2) The blog post about our Fastly usage got out, finally 3) Preparations for another alpha release next week 4) Resumed review of Cloudflare's Privacy Pass extension Nick: 1) new tor rc probably comes out right after this meeting Mike: 1) Nothing new to report Shari: 1) preparing for board meeting on Monday 2) quick application for Pineapple Fund yesterday 3) editing Rose Foundation grant (due Friday) 4) getting ready to meet with auditors next week 5) trying to reschedule one-on-one with Dan Meredith 6) lots of year end stuff, including personally emailing lapsed major donors in the next two weeks 7) lots of loose ends Karsten: 1) Revised IPv6 servers statistics module after importing descriptor archive since 2007. Currently under review. Hope is to deploy by end of the year. 2) Made a list of tasks we'd like to complete by end of the year. Counting 12 tasks, where ~6 would be good, more would be better. Arturo: 1) We have been working on unbricking OONI Explorer and it's starting to present fresh data since today. See: https://github.com/TheTorProject/ooni-sysadmin/issues/176 2) Published a new version of the documentation on how to contribute test lists: https://ooni.torproject.org/get-involved/contribute-test-lists/ 3) Made a PoC implementation of our new website in next.js to compare it against another possible solution based on gatsby. We will pick one of the two by next week: https://github.com/OpenObservatory/ooni-website/tree/next.js, https://github.com/OpenObservatory/ooni-website/tree/gatsby 4) Landed an important pull requests for the OONI Probe backend that will allow us to dynamically provision test lists: https://github.com/TheTorProject/proteus/pull/29 Brad: 1) Closed out the books through November 30 2) Prepared financial reports for upcoming board meeting 3) Gathering financial info for Rose Foundation grant 4) Sue emailed program employees with their new time allocation budgets and cc'd the individual responsible for approving their time 5) Updating a schedule that tracks employee PTO time earned/used; planning to distribute individual info to employees for verification by end of the month 6) Meetings with reps from ADP, our domestic payroll service

1 0

NYC meetup notes
by George 15 Dec '17

15 Dec '17

Posting to tor-project@ as recommended: Greetings all. Just a quick note on the NYC event focused on running relays. The goal isn't to build a labor-intensive meetup, but rather to have bi-monthly events which address different aspects of the project's work while simultaneously connecting with different audiences. The meeting was structured with a 20 min or so presentation, followed by over an hour of discussion. The vast majority of people in the room spoke. There was a short wrap-up at the end. At least half the attendees went to the bar afterwards for more discussion, which is a good barometer for the level of interest. The discussion covered a very vast array of topics, from recommended hardware and local ISPs, to how DNS works on the Tor network and consensus, and that great old topic about the life of a relay from birth. A core person from HOPE was there, and we informally got an ok for a free table. At least we're on the radar. There were 22 people in the room, which wasn't bad for the first meeting. The Tor blog post was great to have, as were the posts to relays@ and talk@, but we should figure out how to broaden the reach for the next one. I wasn't personally disappointed, but I assumed the attendance was going to be higher. If we can begin to loosely build networks in a number of locations, we are in a better position to engage the larger community. Local networks could allow the TPO to respond to different external events more effectively, such as a remote censorship crackdown. It could mean, in a place like NYC, having more hands on deck to manage a table at HOPE. It doesn't have to be just in places where there are core TPO people, once a general approach propagates, but people in places like SF, Seattle, Berlin, Amsterdam, Santiago or in university towns should definitely consider at least a one-off event, catered to educated guesses of what would be relevant. But to reemphasize, it's a lot of effort to maintain a full-blown user group with, say, monthly meeting, speakers, etc. We don't have to set the bar so high. Periodic events, without necessarily maintaining any strong continuity between them, is possible since there is such a large critical mass of vaguely Tor-engaged people. Responding to different censorship events, for instance, can be addressed more effectively with loose networks of familiar people. If the next event attracts a different audience, maybe focused on TB, or PTs, some development topic, or whatever, then great. Casting and recasting a net bringing in new people who maybe aren't interested in the last meeting starts to give more people better familiarity with TPO, and encourages them to increase their commitment. There are other side effects. The notions about Tor being some USG front, or whatever loopy ideas thrive the internet, weakens when people interact with others using or contributing to the TPO. Conspiracy theories die hard in the real world. I am apprehensive about proposing new mailing lists, as it can disperse audiences from talk@ and relays@, in our case. But there may come a time when a low-volume NYC list, for example, makes sense to address more local concerns, such as discussing ISPs, data centers, relay installfests, etc. At this point, I'd argue that keeping it in the current channels probably makes the most sense. Input from others onlist encouraged. This is a more general issue everyone can brain dump into. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682

5 6

Network team weekly meeting notes, 11 Dec 2017
by Nick Mathewson 12 Dec '17

12 Dec '17

Hi! You can find the logs for our weekly network team meeting at http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-12-11-18.00.html Our notes are below: ============ Network team meeting pad, 11 December 2017 “I did not mean to break that planet it was just in the way when I came into being and I fixed it and I said I was sorry and the planet said OK so since I’m supposed to learn from stuff like that I will tell you don’t break planets, especially the ones with living things on them, or at least fix them if you do break them. Also, don’t go in black holes, no matter how much they look like cute little Nahas. They are not cute! They are actually very bitey and kind of mean. Also just OK I do not want to talk about any of this anymore.” -- The Awakened Kingdom, N. K. Jemisin Welcome to our meeting! Every Monday at 1700 UTC 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/2017-December/001582.html Old Announcements: - On the roadmap spreadsheet: Please take december/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. Announcements: - We are planning a single-day pre-planned highly-focused hackfest before the Rome Tor meeting - komlo: Should there be a Rust update/planning session? What should we prepare/do beforehand to help this be planned/highly-focused? - review-group-27 is open, there are 5 tickets left https://trac.torproject.org/projects/tor/query?status=needs_review&keywords… - Let's have some proposal discussions. Isis kicked off the process here: https://lists.torproject.org/pipermail/tor-dev/2017-December/012666.html - No regularly scheduled network-team meetings on 25 Dec through Jan 5. - The _free() patch got merged so I would like to bring this to everyone attention: doc/HACKING/CodingStandards.md -> Allocator conventions - Tor 0.3.2.7-rc (or alpha) comes out Thu or Fri Discussion: - Does anyone want to help refresh the fallback directory mirrors? It's pretty easy, and you get to thank a whole bunch of relay operators. https://lists.torproject.org/pipermail/tor-dev/2017-December/012674.html [Pastly is interested! So is hello71!] - teor: - Last week: - PrivCount release and deployment - Revise the client code for IPv6 in microdesc consensus (#23827) - Revise a fix for bridge descriptor caching and retries (#24392) - Review the metrics IPv6 relay graphs (#23761) - Asked for an equal-area projection for metrics maps (#24563) Anyone remember the scene from The West Wing? Well, I'm living it. https://en.wikipedia.org/wiki/Gall%E2%80%93Peters_projection#In_popular_cul… - Emailed Jon about a venue for the pre-Rome hackfest. Awaiting a response. - Various security stuff and code reviews and helping volunteers. - This week: - Fix a bug in PrivCount where I confused "first to close" and "first to open" - Admin for collecting research data - Book flights for Rome - Work on getting the test network running new IPv6 consensus code - Maybe start implementing onion service client counts for experimental PrivCount? - Maybe revise node_get_{prim,ipv6}_{or,dir}port() so the unit tests work again (#23975) asn: Last week: - Another week of mostly code reviewing: + Reviewed mike's #23101: "Predict and build specific HS purpose circuits (rather than GENERAL)". + Reviewed #23603, #23459, #23271. - Attended UX+onion meeting and did some relevant work: + Updated the Onion-Location HTTP proposal: https://lists.torproject.org/pipermail/tor-dev/2017-December/012660.html + Posted some analysis on #23247 on the padlock/onion states of onion+HTTPS. - Slowly started work on guard discovery again: https://lists.torproject.org/pipermail/tor-dev/2017-December/012657.html - Opened #24544 for some leftover prop224 spec issues pointed out in [tor-dev]. This week: - Continue review/testing of prop247/SponsorV tickets. - Continue guard discovery work. Get the simulator run again. - Continue Onion+UX work. Mike: Last week: - Finished up #23100 and #23114 for merged (Thanks asn and Nick!) - Did a bit more work on #13837 in response to asn and dgoulet's code review This week: - Fix a memory leak that turned up in #23114 in the unit tests.. - Work on #13837 and #23101 - Try to find time to help review code Nick: Last week: - Worked on future sandbox strategy - Finished reviews and merges for review-group-26. (Lots of code!) Opened rg27. - Finished rewrite of free() functions. #24337 - Worked on several 0.3.2.x fixes - Worked on privcount-in-rust proof-of-concept code - komlo: If you want extra eyes on this afterward, I can help review - Worked on migrating xmit-time on channels to do less 64-bit division. Needs more work; got a false start. This week: - Meeting about wide-create cells - Follow-up about utf8 proposal (deferred) - Follow-up about privcount proposal (deferred) - Follow-up about hibernation proposal (deferred) - Release 0.3.2.7-{alpha? rc?} - Review and merge, review and merge. - See how much progress I can make on #23847 (make tor in-processs restartable.) - List sponsor8 tickets for isabela (with ahf and catalyst) dgoulet: Last Week: - #23709 got merged so very happy about this. Will allow me to continue to tackle child tickets of #23993. - Worked on a patch for #24554 which makes specific scheduler data to be stored in a channel_t. Big side effect is removing memory allocation from the scheduler main loop. - Found the cause of #24346 which was all along #23603 that just got merged this morning \o/. - Discussion on the security list. I've started an initial patch proposed by teor, nothing working yet. I'll need to put more time on this. - Reviewed review-group-27 tickets. - All my 032 tickets have been finalized This Week: - Be available for the 032 milestone and hopefully an -rc release this week. Still some tickets in there that we might want to try to resolve or explicitly postpone before the stable release. - A wise move on my part would be to start seriously the IPv6 support for HSv3. I'll go over the opened ticket and sync up with teor. - Maybe some scheduler work if time permit it. #23993 is the parrent ticket and maybe fixing stuff in #24554 once I get a review. My next move is #23744 but that depends on #24554 to be merged. komlo (offline): - This week: - I will finish #23881, I didn't have the chance to work on it last week - Thinking over which Rust work should be done next (excluding build pipeline tasks) in order to have a stable development environment for Rust-by-default/Rust-only implementations (will send an email with this for feedback). pastly: did: acted as a wall for dgoulet to bounce ideas off of todo: review #24554 for dgoulet todo: contact teor about helping build fallback directory mirror list ahf Last week: Sponsor 8: - Added patches for Android logging (#24362) - Been working on comparing progress with the reporting simpleperf does with focus on the monotime_coarse_absolute_msec() patches by Nick (#24374). - Switched over to using the `tor-android` repo for building native targets for Orbot. Misc: - Fixed Coverity issue: #24543 - Reviewed #22703, #24427 - Bug triage rotation duty. This week: Sponsor 8: - Finish event loop metrics patches. (nickm: how are they now?) - Upstream patches to `tor-android` for slightly easier compilation and to include bench/tests on devices. (nickm asks: do you mean "from" tor-android?) - Do Q4 reporting to Isa. - Status meeting with Sponsor 8 people and Isa. catalyst: Last week (2017-W49): - looked into Tails time sync issues and how they might relate to our bootstrapping related clock skew problems - looked at #24337 (*_free() macros) - looking at delaying descriptor fetches when they'd be useless (#2878) - tagging more sponsor8 stuff This week (2017-W50): - #2878 - collecting info about misleading bootstrap phases that bootstrap can hang on - out 12/15 and 12/22 (also 12/25-1/1 like many people); will occasionally check email but probably not IRC - other sponsor8 bookkeeping Hello71: - meson? https://cgit.alxu.ca/tor.git/commit/?h=meson&id=a0a6f3c4d0a0fb5f4d5bf2a27bc…

1 0