- tor-project - lists.torproject.org

October 2017 report for the metrics team
by Karsten Loesing 06 Nov '17

06 Nov '17

Hello Tor, hello world! Below you'll find the highlights of Tor metrics team work done in October 2017. On behalf of the Tor metrics team, Karsten Received funding [1] for some very important metrics work for the upcoming 12 months. This funding will allow us to document why we chose to do data collection, aggregation, and presentation the way we do. It also lets us specify how we're aggregating data on a level of detail that will be sufficient for others to reproduce our aggregated numbers. Initial work done with this funding is an internal collection of related questions from mailing lists and initial thoughts on structuring the documents to be written. [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor13 Attended the Tor meeting in Montreal and discussed the metrics team roadmap for the next 12 months, which will be finalized and published in November. Released CollecTor 1.4.0, metrics-lib 2.1.1, and Onionoo 4.2-1.6.0 [2] to publish the build revision of the software running on a particular Onionoo or Collector instance. Released CollecTor 1.4.1 and Onionoo 4.2-1.6.1 [3] to handle unusually structured (but valid) descriptors. [2] https://lists.torproject.org/pipermail/tor-dev/2017-October/012479.html [3] https://lists.torproject.org/pipermail/tor-dev/2017-October/012526.html Started work on metrics-bot [4], a tool to provide insights into data collected by the metrics team through Twitter [5], Mastodon [6] and IRC to boost awareness and community engagement. [4] https://people.torproject.org/~irl/metrics-bot/ [5] https://twitter.com/TorAtlas [6] https://botsin.space/@metricsbot Improved Tor Atlas by adding an alert to suggest updating Tor version on outdated relays, and also a link to the relay lifecycle blog post when a relay is less than 2 weeks old to help new operators understand more [7]. A change was also made to prepare for the removal of the $ prefixes for family fingerprints, making it easier to copy/paste these fingerprints into shell scripts [8]. [7] https://trac.torproject.org/projects/tor/ticket/23767 [8] https://trac.torproject.org/projects/tor/ticket/22261

1 0

Future of Tor Messenger
by Sukhbir Singh 04 Nov '17

04 Nov '17

Hi, As some of you may have already noticed, the Instantbird team (the chat client on which Tor Messenger is based) has announced that it will no longer maintain the user interface for Instantbird and instead will work towards improving the existing chat support in Thunderbird: http://blog.queze.net/post/2017/10/18/Thunderbird-is-the-next-version-of-In… So far, we have been maintaining two products: Tor Messenger and TorBirdy, and this change is an opportunity to consolidate those efforts into one application, which we are tentatively calling "Tor Communicator". By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. (This change will only take effect at the next ESR major version bump, in March 2018.) We would still like to stay within the Mozilla ecosystem so that we can continue making use of technologies like Tor Launcher and the secure automatic updater patches from Tor Browser. While we have not done builds for Tor Communicator yet, we expect no restrictions on the technical side as we have released "Tor Mail" bundles in the past. Tor Messenger releases have been based on Thunderbird's ESR schedule as Instantbird releases have been infrequent. This has been possible because Thunderbird and Instantbird share a common source tree in the comm-central repository. There is also the question of the future of Thunderbird itself, summarized in the "A Bright Future" section in the blog post detailing Thunderbird's future: https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/ By making this switch: - Users will get access to secure chat from Tor Messenger and secure email from TorBirdy, in a single application - Thunderbird has a single-window chat interface which is different from Instantbird (and better) - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter - Users will get a Tor Mail application which has been requested for a while The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts! -- Sukhbir

12 22

Notes from November 2 2017 Vegas team meeting
by Karsten Loesing 03 Nov '17

03 Nov '17

Notes for November 2 2017 meeting: Karsten: 1) Making good progress on integrating webstats into CollecTor, but not there yet. Roger: 1) I'm finally getting time for the Tor Research Safety Board open cases this week 2) Alison and I should conspire to pitch a "tor relay operator liaison" paid position [alison: I have lots of notes on this from the meeting and also it's on the community team roadmap!] 3) Rob Jansen and I are submitting an NSF CRI Preliminary proposal today, on Shadow enhancements 4) Rome invites 5) Still optimistic about the China work Nick: 1) kudos to Isabela for organizing inter-team roadmap-share. Let's all remember to treat it as an alpha process, and iterate. 2) more hacking, more programming, stuff goes onward. 3) Another alpha next week. Trying to do two per month. 4) It's November! PLEASE REMEMBER that many people go on vacations in December: if you need to coordinate with another human, plan accordingly! Georg: 1) Final month for Sponsor4 stuff (looking at the remaining things it still seems doable to meet the deadline modulo the moat work maybe) [isa: we did got the extension for jan 31st] Shari: 1) got some grant proposals in 2) end of year campaign going pretty well; October donations: 2014-$4,025, 2015-$22,190, 2016-$45,840, 2017-$56,664 3) emailing major donors 4) getting ready for quick trip to San Francisco next week to meet with a potential funder 5) out of the office week after next for OTF Summit in Valencia 6) starting invitation process for Rome 7) we're moving headquarters to a bigger office downstairs in the same building Alison: 1) still brainstorming a RightsCon talk 2) also thinking about a Tor State of the Onion for LibrePlanet. Will discuss more with Steph tomorrow 3) the support portal is being built! hiro, Antonela, and Isa got right to work. Phoul and I gave them the content and are standing by. :) really excited about this. 4) one more day for Montreal meeting feedback; then we'll discuss it here. 5) meeting with some tor-south folks next week to talk about LatAm Tor Meetup needs and looking for some funding for that 6) Phoul and I are working on the blog post to encourage relay operators 7) waiting on some feedback about the code of conduct draft from Erin Wyatt and the Community Council. hoping to get it out for the proposal period in another week or so. anyone who wants to view and comment on the current draft can contact me. Steph: 1) Fundraising campaign going well 2) Tommy published a post on the new dirauth 3) Working w asn on next-gen post and sharing 4) Newsletter portal is ready, hiro added to the site. Will send an issue next week and once a month including donate call to action. We'll send a fundraising email every 2 weeks 5) Phoul helped me get the Tor Animation title translated 6) Talking to Alison tomorrow about LibrePlanet submission isabela: 1) working on DRL report 2) working on inter-teams roadmaps coordination 3) organizing things at the UX team to resume meetings next week - sent a note to the UX list about it. 4) submitted modularization proposal last friday and design proposal last monday 5) was invited to be part of a panel organized by MDF at the end of the month 6) planning at being in Seattle for the holiday party :) Arturo: 1) Published a blog post on writing cross platform desktop apps: https://ooni.torproject.org/post/writing-a-modern-cross-platform-desktop-ap… 2) Reviewed tickets related to improving mobile app embedding of Tor 3) CIPIT Kenya published a post based on OONI data, examining throttling during the elections: http://blog.cipit.org/2017/10/29/internet-speed-throttling-surrounding-repe… 4) Maria will be presenting OONI at FSCONS in Oslo this week 5) Started writing a specification and threat model for the OONI Probe orchestration system 6) Doing logistics around organising the OONI presence at CCC (having a stall, ordering t-shirts and other swag, etc.)

1 0

Support team: changes in meek-amazon that may affect users
by David Fifield 01 Nov '17

01 Nov '17

Today at 18:10 UTC I turned off the CDN endpoint formerly used by meek-amazon. Tor Browser switched away from this endpoint 7 months ago (https://bugs.torproject.org/21918) but Orbot only recently switched. Just before I turned it off, the endpoint was still being heavily used, so it's possible that some users will have been suddenly disconnected. == How to fix == Users should upgrade their Tor Browser or Orbot. Tor Browser 7.0.8 Orbot 15.5 Users can use meek-azure if they need connectivity in order to upgrade. == Technical information == d2zfqthxsdq309.cloudfront.net is the old, deactivated endpoint. d2cly7j4zqgua7.cloudfront.net is the current endpoint. If a user has a custom bridge line that looks like: meek 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com they need to change it to: meek 0.0.2.0:2 B9E7141C594AF25699E0079C1F0146F409495296 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com Most users will not be using custom bridge lines like this and only need to upgrade.

2 1

Grants Update, October 2017
by Tommy Collison 01 Nov '17

01 Nov '17

Quick report on what I got up to in October. Grants: - Submitted a grant to DRL to modularize Core Tor. - Gave OTF more info about our design proposal. - Researched a whole bunch of new grants and started noodling on grants stuff for 2018. As a reminder, https://pipeline.torproject.net exists as a place where you can tell me about projects you’d do if you had the funding. What gets funded isn’t my decision, but I can do research and maybe play matchmaker with suitable foundations. Other: - We launched our end-of-year crowdfunding campaign! [1] We’ve raised over $50,000 in the first week alone (i.e. $100,000, thanks to Mozilla’s matching program). Super grateful to the rest of the comms team for their help getting this off the ground. o/ - Coordinated Tor’s participation in the Outreachy internship program. - This weekend, I’ll be down in San Francisco for the Aaron Swartz hackathon. See ya there? [2] - Dyed my hair blue [3]. [1] https://blog.torproject.org/powering-digital-resistance-help-mozilla [2] https://www.aaronswartzday.org/sanfrancisco/ [3] https://twitter.com/tommycollison/status/921781336737660928

2 1

OONI Monthly Report: October 2017
by Arturo Filastò 01 Nov '17

01 Nov '17

Hi Tor Project list, The OONI team started a new contract with the OTF in October 2017! We carried out research and published a document outlining the architecture and design considerations for the implementation of the native OONI Probe apps for Windows and macOS. We also published two research reports on internet censorship in Pakistan (in collaboration with Bytes for All, Pakistan) and on censorship events that occurred during Catalonia's independence referendum (in collaboration with Virtual Road/Qurium). We updated various test lists with URLs provided by community members, and we published a post outlining our sessions at our team meeting in Montreal. ## Research on writing OONI Probe desktop apps Over the next year we will be building native OONI Probe apps for Windows and macOS. To implement these apps, we started by making the decision of what technology stack to use, and the high-level architecture. We experimented with various solutions and documented their advantages and disadvantages. We published a blog post outlining the architecture and design considerations that we made for the implementation of OONI Probe desktop apps, as a result of research and experimentation with a variety of different libraries and approaches. This document, outlining the rationale behind our choices for the OONI Probe desktop apps, is available here: https://ooni.torproject.org/post/writing-a-modern-cross-platform-desktop-ap… ## Published research report on internet censorship in Pakistan In collaboration with Bytes for All, Pakistan, we published a research report examining internet censorship in Pakistan. This report is available here: https://ooni.torproject.org/post/pakistan-internet-censorship/ Our report includes an analysis of all OONI Probe network measurements collected from Pakistan over the last three years, between 2014-2017. The report received the following press coverage: * https://www.dawn.com/news/1364766 * https://www.dawn.com/news/1365441/internet-censorship * https://www.techjuice.pk/pakistan-blocked-200-urls-3-years-report/ * https://www.phoneworld.com.pk/more-than-200-urls-blocked-in-pakistan/ * https://ceylontoday.lk/print20170401CT20170630.php?id=32601 ## Published research report on internet censorship during Catalonia's independence referendum In collaboration with Virtual Road/Qurium, we published a research report examining internet censorship events that emerged during Catalonia's independence referendum. Our report is available here: https://ooni.torproject.org/post/internet-censorship-catalonia-independence… Community members translated our report to the following languages: * Catalan: https://ooni.torproject.org/ca/post/internet-censorship-catalonia-independe… * Spanish: https://ooni.torproject.org/es/post/internet-censorship-catalonia-independe… * French: https://ooni.torproject.org/fr/post/internet-censorship-catalonia-independe… This report received a fair amount of social media attention and some press coverage (https://www.agi.it/estero/catalogna_spagna_hacker-2278801/news/2017-10-22/) ## Wrote article on investigating internet censorship with OONI data for the Data Driven Journalism Project The Data Driven Journalism project published our article explaining how to investigate internet censorship with OONI data. Our article is available here: http://datadrivenjournalism.net/resources/ooni_data We hope that this article will help engage more data journalists with OONI data. ## Updated test lists We collaborated with community members and OTF fellows on updating various test lists. Thanks to the URLs they provided, the following test lists have been updated: 1. TM and UZ: https://github.com/citizenlab/test-lists/pull/235 2. RU, UA, Global: https://github.com/citizenlab/test-lists/pull/241 3. Global: https://github.com/citizenlab/test-lists/pull/248 4. BY: https://github.com/citizenlab/test-lists/pull/242 ## OONI team meeting in Montreal The OONI team gathered for a 4-day meeting in Montreal to reflect, regroup, hack and plan in preparation for our new contract with the OTF. We published a post including: * A summary of the main things that the OONI team is working on * All sessions hosted as part of the meeting and all session notes * Meeting outcomes This post is available here: https://ooni.torproject.org/post/ooni-team-meeting-montreal-2017/ All session notes are available here: https://github.com/OpenObservatory/gatherings/tree/master/internal/2017-10-… ## Tor meeting in Montreal The OONI team also attended the Tor meeting in Montreal, between 11th-15th October 2017. As part of this meeting, we facilitated the following sessions: * OONI and Tor Browser collaboration: https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Not… * OONI and Tor Metrics collaboration: https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/Not… ## Userbase In October 2017 OONI Probe was run 128,522 times from 1,661 different vantage points across 152 countries around the world. This information can also be found through our stats here: https://api.ooni.io/stats ~ The OONI team.

1 0

Network-team meeting notes, 30 Oct 2017
by Nick Mathewson 30 Oct '17

30 Oct '17

Hi! You can see today's meeting transcript here: http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-10-30-16.59.html Here are the updates from our pad: Network team meeting pad, 23 October 2017 Welcome to our meeting! Every monday at 1700 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: * http://5jp7xtmox6jyoqd5.onion/p/QKh0bLHntAJ1 * https://pad.riseup.net/p/QKh0bLHntAJ1 *Announcements:* * Remember, this meeting is 1700 UTC, no matter what local time is. Watch for daylight saving changes in October or November. * Team rotation: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/TeamRot… * Review-group-24 still has unreviewed tickets! https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… *Discussion topics:* * Do we want to plan a hackfest in 2018? I sent some options to the list. (teor) * *Do we want/need any additional proposals for guard-discovery other than Prop247 updates?* (See the SponsorV page for lists of guard discovery tickets and a rough roadmap - this should help us decide) * Notes from network team working sessions- is there a place to find these? [I still have the notes from the Firefox-uplifting-TB-patches-and-eventually-maybe-shipping-tor-in-private-browsing-mode meeting, and I've forgotten to type them up. I'll do that this morning and send to notes@. —isis] [note that you can also probably just photograph them and send them to notes@, if you run out of time to type. -nm] Updates: (Please use *boldface* to indicate discussion topics) teor (offline): Last week: - * - I keep seeing "Attempt to open a stream on first hop of circuit" warnings in chutney in recent master and 0.3.2, anyone know why? (#24011**)* - [NM: dgoulet notes that we removed the AllowSingleHopExits option recently. Could that be at fault?] - Proposed moving IPv6 ORPorts to the microdesc consensus (prop#283, #20916 and children), and discussed the draft proposal with the dir-auth list - Tried to help arthuredelstein diagnose Tor Browser connection timeouts: we think it's caused by overloaded exits, which probably needs some bandwidth authorities to change location, or more bandwidth authorities (#21394) - Ripped out buggy IPv6-specific v3 single onion service code, but kept support for IPv4 v3 single onion services (#23820) - We want to reduce relay bandwidth stats intervals, to make client guards harder to find using these stats (#23856) - More fun with missing microdescriptors! (#21969 and children) - Post-travel admin - Experimental PrivCount deployments, bug fixes, and feature development This week: - Experimental PrivCount onion service client descriptor fetches, intro and rend failure counts - Nudge the prop#283 thread, and once we're sure we want it, get the code reviewed mikeperry (offline - biological timezone and sleep issues): Last Week: - Recovering from illness, slowly but surely. - Wrote a plan for Guard discovery: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorV - *Please comment and/or update*it! I will check scrollback. [NM: Poked asn, teor, armadev about this.] This week: - Finishing up #23100 and #23114 (basically they need tests and asn had some trac comments as well). - If time/energy, start writing an experiment plan for the prop247 performance simulator. Nick: Last Week: - Six releases. Whee! - Reviewed and merged a bunch - Including the protover-in-rust code! - - *Are the doc/HACKING/*Rust.md documents up-to-date*? - CK: I am planning on reviewing these this week to fix up anything that isn't - [ I'm also happy to go over them. —isis] - Met with Isabela for roadmapping, planning, catch up - Helped a little with modularization proposal - worked on hsdescv3 fuzzing a little This week: - Wrap up october tasks; plan more about november. *(Remember the roadmap?)* - Review and merge more stability fixes for <= 0.3.2 - Write two or three proposals/design docs: - Improved APIs for control on mobile/embedded systems - Privcount with shamir-style secret splitting (if somebody can help figure out the math) - Ed25519 ID -> Consensus proposal - Coordinate w/ other teams on roadmap dependency issues - Follow up to Tim's n-t-s email. komlo (offline): Last week: - - Helped with the protover-in-rust merge! This week: - Work on fixing up some post-review improvements (#24029 and #24032) haxxpop: - Last week: - nothing - This week: - - Try to learn Rust and contribute something - - Maybe, I will take a look on fuzzing some http request - Tabish: This week: -Try to figure out how tor works and look at some easy tickets to find an interesting one. ahf: Last week: Sponsor 8: - Reviewed ticket #23845, #23848, and #23900. - Upstreamed some small patches to help profiling of Tor on Android to Orbot: github.com/n8fr8/orbot/pull/91 - Meeting with Isabela + Nick about the modularization proposal. - Looked into an issue in Orbot: github.com/n8fr8/orbot/issues/90 - Looked into simpleperf again with some more luck. Some sample reports can be seen at https://people.torproject.org/~ahf/sponsor8/sample-reports/ - Rebased my Orbot repository with Nathan's recent changes to upstream Orbot. - Opened #24061 (master) + #24062, #24063, #24064 and #24065 to track S8 performance work and added them to milestone spreadsheet. Misc: - Random small catch ups from notes from Montreal. This week: Sponsor 8: - Profiling of memory + CPU + battery baseline, discuss results and figure out where we should dive in first in November (#24065). - Update build instructions and hopefully get someone else to try it out. Sponsor 4: - Look into Nick's review in #22275 that got lost in all the BornHack stress in August/September. Misc: - Bug triage duty. - End of the month tasks: Harvest + Montreal reimbursement. dgoulet: Last week: - Worked on all my assigned 032 tickets which was most of my week. - Investigated the possible reasons on why we've lost ~500 Running relays in the network. I didn't want to exclude a tor bug. - Did some scheduler design work, no code yet. (#23993) - Writing an email for tor-dev@ that should go out soon about the state of connection/channel/scheduler for us to understand better the problem we are facing with the scheduler subsystem. This week: - Continue the work on 032 tickets and hopefully review some! - More progress for the scheduler work (#23993) because it might not be that small and 033 merge window is open! - Need to tackle the HS circuit timeout situation basically write down current state and discuss at least with Mike what to fix or change. catalyst: last week (2017-W43): - HackerOne triage - we might want to refine our HackerOne policy somewhat - reviewing #23816 (jittered backoff) - reviewing #23532 (add_laplace_noise()) this week (2017-W44): - follow up on some HackerOne stuff - more review of #23816 and #23532 - *how hard do we want to investigate why 0.2.9 seems not to be vulnerable to the #20532 bridge bypass?* - [NM: If we are fairly sure that the bypass doesn't happen, let's ascribe it to the big guard rewrite in 0.3.0] isis: last week: - reviewed/patched #18329 and #23594, so BridgeDB will now not distribute bridges that request not to be distributed - looked into an issue with some bridges not marked running (#23958) - started a patch for #16564 to keep bridges (with a "bridge-distribution-request" server descriptor line) out of the consensus - signed up for Tor's HackerOne * * would someone be willing to answer some questions about triage? * * * there's TB bugs in there, do we triage those? is there another account for TB? * * * there's non-security bugs in there, do i just make normal tickets for those? * * * how does giving people credit for finding bugs work? do i just credit them for any bug, even if it's not a vuln? * this week: - getting integration tests for moat to pass (#15957) - - more roadmap, making tickets, triaging - - spec writing Isabela: Last week: - submitted the modularization proposal - met with Nick to talk about the team roadmap - specially november and december tasks. This week: - working with team leads on inter-team roadmap sharing - will send emails on this later today - sponsor8 report for august and september

1 0

Notes from October 26 2017 Vegas team meeting
by Karsten Loesing 27 Oct '17

27 Oct '17

Notes for October 26 2017 meeting: Alison: 1) The code of conduct draft is being reviewed by the Community Council and Erin W right now. Anyone else who wants to review it before the proposal period on tor-internal can reach out to me directly. 2) I'd like to put together a Tor talk for RightsCon (I don't need to be the one to deliver it). Ideas about what talk we could give there? https://www.rightscon.org/submission-guidelines/ 3) Yay, the Core Contributor guidelines are in effect and people are using them! 4) I'm going to be reaching out to more people to join the Speakers Bureau. If you know of someone who wants to give Tor talks, ideally someone who speaks a language other than English, please send them my way. 5) Phoul and I are working on a blog post to encourage more relay operators. 6) Trying to help out where I can with the Primavera Hacker Tor Meetup 7) Finishing the Community Team roadmap! 8) Surveys are pouring in from the meeting. I'll send a reminder today. Nick: 1) Stable releases are out, again; new alpha to follow. 2) Team dividing energy between 0.3.2 stabilization stuff and 0.3.3 stuff. 3) Have been hanging out with Isabela yesterday and today to do planning, roadmapping, etc. 4) Currently under review 5) We should have optional rust code that actually _does_ something in Tor within the next couple of weeks 6) Several branches for mobile improvements implemented; waiting for review. Mobile developers, do the patches for #23845 and #23900 look like they will do what you want? Isabela: 1) working on the inter-teams roadmap sharing plan: https://storm.torproject.org/shared/3nodOOVmxGzmtuIxSiZoyO4jWtqmTyzqBpvE1bp… 2) finishing up Modularization proposal - deadline is tomorrow (friday) 3) got NCE for sponsor4 - new deadline is Jan 31st 4) had a great time meeting with Nick here at his house cover a lot of stuff related to team organizing and work planning. 5) network speed test metrics collection time - need to spam ppl to do that Arturo: 1) Preparing a blog post documenting the design and architecture decisions for the OONI Probe desktop apps to be released tomorrow 2) Making progress on the desktop apps development front 3) Did a weekend doing design stuff with Elio in Rome 4) Published an article on using OONI data on Data Driven Journalism: http://datadrivenjournalism.net/resources/ooni_data Karsten: 1) Finished our team roadmap draft for other teams to review and tell us what else we're missing and for us to learn from other team roadmaps what else we should be doing. 2) Working on patch releases for most of the metrics tools due to an alternate Tor implementation publishing (valid) descriptors that are unlike the ones that Tor publishes. Steph: 1) We launched our fundraising campaign. Tommy has been a huge help! 2) Outreachy application period has closed, so we’re going through applications. We’ll make a decision by Tues 3) Planning a blog post on the new dirauth with Tommy. 4) RightsCon subs are due Nov 24 Shari: 1) end-of-year campaign 2) what to do about Tor messenger 3) new office for Seattle 4) DRL submission for modularization 5) meeting with other groups on dealing with harassment 6) going through Outreachy applications Brad: 1) Reviewing expense reports from Montreal and analyzing final invoice from venue 2) Closing books through September 30 and filing compliance reports 3) Working with CPA firm to finalize audit & tax return 4) Working with Jon to implement new system for managing swag inventory 5) Progress Report for Sponsor 8 Georg: 1) Rightscon brainstorming 2) Roadmapping work 3) Tor Browser releases for donation campaign

1 0

Tor powers digital resistance with help from Mozilla
by Tommy Collison 26 Oct '17

26 Oct '17

Hello world! Today, we’re launching our end-of-year crowdfunding campaign, highlighting the ways that Tor powers digital resistance and protects essential human rights around the world. We’re especially excited about this campaign because our friends at Mozilla are matching donations up to $500,000, meaning that donations go twice as far. More info (and links to donate) are on our blog: https://blog.torproject.org/powering-digital-resistance-help-mozilla Tor’s done amazing work in 2017, and I’m proud of what we’ve achieved. This crowdfunding campaign is an opportunity to start 2018 strong (and to get some awesome swag -- check out https://donate.torproject.org/) So, please donate if you can. If you can’t right now, please spread the word about this campaign. Tell your friends that, because of Mozilla’s matching program, there's never been a better time to donate to our favorite anonymity network. Thanks, everyone! TC

4 6

Re: [tor-project] Analyzing bwauth disagreements
by dawuud 25 Oct '17

25 Oct '17

Hi Nusenu, Tor Project, Tor community, tl;dr The Tor network is *highly* partitioned. The scanner code is located here: https://github.com/david415/tor_partition_scanner HOWEVER, the scanner needs a redesign... I have been using the WRONG methodology for scanning the Tor network for partitions in that I select relays which I think are interesting and then see how much connectivity there is between them. I instead would like to scan ALL the Tor relays (repeatedly at different times of day) and then later perform queries against the consensus to see which relays show up in interesting combinations of failures. The other failure in this approach to scanning is that it uses a fixed set of relays... and therefore the Tor consensus file used will become old and contain relays no longer in the consensus well before the scan is complete. And lastly, don't get gamed! Scanning from a single IP is a mistake and this is an obvious way to get gamed. For all these reasons my colleague Katharina and I plan to write a new better scanner of Tor network partions that is distributed, and that has a central dispatcher so that the new consensus documents will be used to inform "worker machines" which circuits to try and build. All that having been said, let me show you what my naive scan looked like a few weeks ago: 1. setup a machine running Tor and expose its control port as either a tcp port or unix domain socket with no authentication *edit* /etc/tor/torrc blah blah easy rtfm 2. install tor_partition_scanner virtualenv virtenv-orscanner . ./virtenv-orscanner/bin/activate mkdir -p code; cd code git clone https://github.com/david415/tor_partition_scanner.git cd tor_partition_scanner pip install -e . 3. get a recent consensus file Use consensus files from collector if you want others to be able to reproduce your results. here --> https://collector.torproject.org/recent/relay-descriptors/consensuses/ wget https://collector.torproject.org/recent/relay-descriptors/consensuses/2017-… 4. choose which relays you want in your scan Here I am intentionally NOT scanning 50 million tor circuits using the entire consensus. Instead I am using a simple python program written using the Stem library to parse the consensus file and give us all the realys with the Stable and Fast flags; among those we choose the top 100 in terms of consensus bandwidth. ./helpers/query_fingerprints_from_consensus_file.py 2017-09-21-23-00-00-consensus > top100.relays 5. perform scan of top 100 relays detect_partitions.py --tor-control tcp:127.0.0.1:9051 --log-dir ./ --status-log ./status_log \ --relay-list top100.relays --secret secretTorEmpireOfRelays --partitions 1 --this-partition 0 \ --build-duration .25 --circuit-timeout 60 --log-chunk-size 1000 --max-concurrency 100 9,900 two hop tor circuits are being built. As the scan runs you can tail -f the status_log to make sure its working. Only circuit build failures if any will be logged in the json log file. When the scan completes the status_log should display something like this: 2017-09-22T00:05:44+0000 [-] $BD4C647508162F59CB44E4DFC1C2B2B8A9387CCA -> $DD808ECE4F2E24F377CBE11E335ECDA196FE3B78 2017-09-22T00:05:44+0000 [-] $0966A24977A0B0DB62546C6F18F9578D97FE86F0 -> $AD00FB62A133F91009AD5F6503E5F21F594BC4C6 2017-09-22T00:05:50+0000 [orscanner#info] Finished writing measurement values to ./2017-09-22T00:05:50.492698-scan.json. 2017-09-22T00:05:50+0000 [-] Main loop terminated. 6. Load circuit build failures into sqlite db file ./bin/load.py --dbfile scan1.db -p 2017-09-22T00:03:31.610096-scan.json \ -p 2017-09-22T00:05:42.886622-scan.json \ -p 2017-09-22T00:05:50.492698-scan.json 7. Count the results echo "select first_hop, second_hop from scan_log;" | sqlite3 scan1.db | wc -l 2014 8. Attempt to eliminate false positives by retesting the failed circuits mkdir scan1 mv *.json scan1 echo "select first_hop, second_hop from scan_log;" | sqlite3 scan1.db > scan2.circuits detect_partitions.py --tor-control tcp:127.0.0.1:9051 --log-dir ./ --status-log ./status_log \ --relay-list relays_for_scan1 --build-duration .25 --circuit-timeout 60 --log-chunk-size 1000 \ --max-concurrency 100 --circuit-file scan2.circuits ./bin/load.py --dbfile scan2.db -p 2017-09-22T00:59:31.017246-scan.json -p 2017-09-22T01:04:35.491908-scan.json echo "select first_hop, second_hop from scan_log;" | sqlite3 scan2.db | wc -l 1947 still 1947 circuit build failures! Now tell the database to show us the relays involved in a circuit build timeout AND count the number of failures by first hop: sqlite> select first_hop,count(first_hop) from scan_log where status = 'timeout' group by second_hop; $4198BD138E5E11B15B05C826B427148CED7D99FE|2 $578E007E5E4535FBFEF7758D8587B07B4C8C5D06|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $7C0AA4E3B73E407E9F5FEB1912F8BE26D8AA124D|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $A6B0521C4C1FB91FB66398AAD523AD773E82E77E|18 $578E007E5E4535FBFEF7758D8587B07B4C8C5D06|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|2 $578E007E5E4535FBFEF7758D8587B07B4C8C5D06|1 $DAA3D3F6FDA962885072537E3F315086B003A6E3|3 $B5212DB685A2A0FCFBAE425738E478D12361710D|1 $0593F5255316748247EBA76353A3A61F62224903|4 $7C0AA4E3B73E407E9F5FEB1912F8BE26D8AA124D|2 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $578E007E5E4535FBFEF7758D8587B07B4C8C5D06|1 $C818C0EA0BAD90F5432DBA4EE662BCBEC39D2668|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $B5212DB685A2A0FCFBAE425738E478D12361710D|1 $578E007E5E4535FBFEF7758D8587B07B4C8C5D06|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 $4198BD138E5E11B15B05C826B427148CED7D99FE|1 sqlite> A6B0521C4C1FB91FB66398AAD523AD773E82E77E is certainly an outlier! It looks like this relay hits it's bandwidth limit several times per day... and Roger and I suspect it is failing circuit builds at certain times because it is overloaded during specific times of day due to traffic spikes. The fix of course would be to adjust the tor consensus and perhaps cap this relay's bandwidth capacity in the consensus: https://atlas.torproject.org/#details/A6B0521C4C1FB91FB66398AAD523AD773E82E… Circuit build failures also have outliers where a few relays fail more than others: sqlite> select first_hop,count(first_hop) from scan_log where status = 'failure' group by second_hop; $1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA|10 $1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA|10 $A571351082A9E04F14A0A3DF27E0637231D57B84|10 $B204DE75B37064EF6A4C6BAF955C5724578D0B32|11 $F6740DEABFD5F62612FA025A5079EA72846B1F67|10 $BF0FB582E37F738CD33C3651125F2772705BB8E8|10 $A571351082A9E04F14A0A3DF27E0637231D57B84|10 $1D3F937E2053E58C18E18D43FA5153E2A9F4DC77|99 This outlier relay 1D3F937E2053E58C18E18D43FA5153E2A9F4DC77 is also quite interesting. It also seems to hit its bandwidth limit several times per day and it's also interesting to note that it's located in the UK: https://atlas.torproject.org/#details/1D3F937E2053E58C18E18D43FA5153E2A9F4D… Show me all the tor relays that failed ALL of their circuit builds: echo "select first_hop,count(first_hop) from scan_log where status = 'failure' group by second_hop;" | sqlite3 scan2.db | grep 99 $1D3F937E2053E58C18E18D43FA5153E2A9F4DC77|99 $C793AB88565DDD3C9E4C6F15CCB9D8C7EF964CE9|99 $EF6591754F9079DD122EFC2C4B52917F625A8E5B|99 $55C7554AFCEC1062DCBAC93E67B2E03C6F330EFC|99 $87C08DDFD32C62F3C56D371F9774D27BFDBB807B|99 $BD4C647508162F59CB44E4DFC1C2B2B8A9387CCA|99 $EF6591754F9079DD122EFC2C4B52917F625A8E5B|99 $1D3174338A1131A53E098443E76E1103CDED00DC|99 $734EDDC2C04B1C0184178167ABD23AE85413212F|99 $7C0AA4E3B73E407E9F5FEB1912F8BE26D8AA124D|99 99 is used because here we scanned the top 100 and therefore each relay is involved in 99 circuit builds since relay A cannot build a circuit to itself. I hope it rings loud and clear that this is a *huge* problem for the health of the Tor network that many of the top 100 Tor relays with the Fast and Stable flags cannot even build a single Tor circuit to any of the other top 100 relays! In conclusion, many of these circuit build failures are very likely NOT the fault of the relay operators but instead this points to the failure of the current Tor Bandwidth Authority system. Not only is it old and broken, even if it was to work "properly" it would still be broken by design if: a. it's not performing circuit build tests b. it's not distributed and thus more easily gameable Katharina and I plan to conduct a more formal research project in this area and scan the entire Tor network (50 million 2-hop Tor circuits) several times at some point in the near future using a new better methodology. However even before we do that, I can tell you right now you will not like the results. It's bad news. (but fret not, Tor Project is committed to fixing the Bandwidth Authority system) And yes, I am well aware that correlating these scan results with BGP ASNs is interesting. There are many other interesting queries we can do after we've collected the data to try and find malicious/intentional network partitions. One possible positive outcome of our research could perhaps be the addition of a partition scanning component to the Bandwidth Authority System. However, as it stands right now Tor Project is prioritizing bandwidth measurements NOT partition scanning, since that is currently a maintenance pain point for the Directory Authority operators that must deal with the torflow tool. Sincerely, David Stainton On Wed, Oct 11, 2017 at 09:55:00PM +0000, nusenu wrote: > Hi David, > > dawuud: > > Also I have recently done a few small scans for 2-hop circuit > > connectivity and shared some of the results with Roger on > > #tor-dev. One theory is that many of the circuit failures are due to > > traffic spikes at certain hours of the day. > > where can I find more about that if I havn't been on #tor-dev at the time? > thanks, > nusenu

3 5