tor-project September 2017

tor-project@lists.torproject.org

20 participants
33 discussions

"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

Mozilla "All Hands" coordination
by Roger Dingledine 05 Oct '17

05 Oct '17

Hi folks, Some of us have been invited to the upcoming Mozilla All-Hands meeting in Austin in December: https://wiki.mozilla.org/All_Hands/Austin Georg (gk@torproject) is coordinating our plans, to be sure to have enough of the right people there. We think it would be wise to get a good cross-section of the Tor world there -- not just a pile of browser devs. So, if you (a) got an invite, or (b) would like to go as a Tor person, please let Georg know. The deadline for answering their invites is Oct 5, so be sure to do it with enough time before that deadline. (Technically it is not an invite, but rather a nomination for an invite, and then on Oct 5 they'll do some internal process to decide actual invites.) --Roger

3 3

Notes from September 28 2017 Vegas team meeting
by Karsten Loesing 02 Oct '17

02 Oct '17

Notes for September 28 2017 meeting: Karsten: 1) We accidentally left MeetBot running for a couple of days after out last team meeting in #tor-dev which led to logging the channel all the time and which prevented the network team from using MeetBot. I can't rule out that we'll make the same mistake again, nor can other teams. Should we move all public team meetings to #tor-meeting instead and use MeetBot there? I'm happy to do it, but it makes even more sense if most/all teams do it. Conclusion: yes, we're going to try it. Roger will send mail to tor-project explaining the plan. [Update 2017-09-30: Turns out we did *not* log half a week of #tor-dev; we just confused MeetBot in a way that it did not allow the network team to start a new meeting: http://meetbot.debian.net/tor-dev/2017/tor-dev.2017-09-21-14.29.log.html] 2) We're currently meeting in Berlin to make a team roadmap for the next 12 months. We're probably going to publish it next week and discuss it with other teams in Montreal. Alison: 1) Montreal meeting planning continues apace. I'm still soliciting ideas for the working sessions. 2) Lots of prep for my IMLS grant. I hope to have the application for participants completed this week. 3) Outreachy applications are rolling in. 4) Helping Isa find volunteers for Sponsor8 activities. Roger: 1) Mozilla all-hands meeting, let's tell people a plan for who should be there. Plan: Roger will mail tor-project@. 2) Brad: I'm doing an NSF proposal, due Oct 10. You could influence the budget allocations. 3) Membership secretary is in place: Damian is our new membership secretary. 4) OONI and Tor bundling: their mobile version doesn't have Tor in it, because iOS. That's sad, and we should help them fix it. Plan: have a session in Montreal to nail down whatever short term fixes we can do. 5) I'm doing a poor job as execdir-to-frontdesk conduit. I wonder if we should try listing the frontdesk on the contact page, with a big warning next to it. Plan: I will work with Alison to craft an amazing sentence for the contact page, and we'll swap frontdesk in and execdir out. 6) What did we do with the FOSDEM invite answers? Plan: The comms@ team is going to discuss how we coordinate talk proposals so we can be proactive rather than just trying to respond. Also, some proposals need to draw from many parts of Tor, so we need a shift in how we as an org approach them. Georg: 1) Releases should get out pretty soon; the alpha Tor Browser contains the missing content sandboxing and the first Tor alpha in the 0.3.2 series 2) I started reviewing the Cloudflare CAPTCHA bypass extension 3) Who is doing the CCC talk coordination? <- I'll start a thread on tor-internal to get the decision process going [GeKo] Nick: 1) We're moving forward on various projects in the Network team: mostly trying to fix bugs for the 0.3.2.x release series. 2) Remember: Isis and Ahf are putting out the next 0.3.2.2-alpha release. 3) Did we wind up with a boston PT meeting plan? Steph: 1) doing pre-work for Montreal speaker training. Talking with Lyndon again today about press. 2) Outreach apps coming in. Alison, Tommy, and I participated in a twitter chat this week. 3) doing prep with GR for fundraising campaign, giving feedback on acknowledgement letters. chatting again today. 4) helping with OONI comms, following launch process. Iran report blog post coming today 6) mapping out blog content calendar with Tommy, KIST post will go out early next week (held back bc of lots of content this week). Post on onion testing coming up 7) joining publiccode.eu call that publicly financed software developed for the public sector be made Free and Open Source Software Isabela: 1) working on sponsor8 indicators for Q1 2) coordinating tasks for designer proposal with TB team and UX team - writing activities and future plans summaries for tommy to use in the proposal (due oct 4th) 3) working with network and tb team on sponsor4 tor launcher new experience 4) Linda is finishing up website redesign mocks for me to get it printed for Montreal discussion session / Antonella is also helping out the team, she is creating components from bootstrap using our style guideline (colors fonts etc) - this will be super helpful for anyone that wants to build sites or pages for their projects following our guidelines 5) Hiro is one of the 'consumers' of Antonella's bootstrap resource - she is working on newsletter archive and signup/unsubscribe pages - she is also finishing up our survey tool (which we will use for a brand survey for onion browser and a needs finding survey for network team) 6) DRL responded to modularization proposal from core tor - we need to reduce budget from 900k to 700k, and apply as cost extension of current sponsor8 grant. Arturo: 1) We launched ooni-run: https://run.ooni.io yay! 2) Just published the Iran report: https://ooni.torproject.org/post/iran-internet-censorship/ 3) We have been discussing how to make the life easier for mobile developers that want to integrate Tor into their app, using MK as a test case. See: https://github.com/measurement-kit/measurement-kit/issues/86 4) Deploying OONI API and the new pipeline this week. Shari: 1) working on end-of-year fundraising 2) anything to bring up about Montreal? 3) mapping Tor - will add this to the Montreal meeting agenda under the title "Tor on a bus."

2 1

OONI Monthly Report: September 2017
by Arturo Filastò 29 Sep '17

29 Sep '17

# OONI Monthly Report: September 2017 The OONI team completed all deliverables for its current contract with the OTF. ## Stable release of Measurement API We released the stable version of OONI's new measurement API, which is available here: https://api.ooni.io/. The OONI API is based on the stable release of our data processing pipeline, which has been re-engineered over the last year to detect censorship events around the world faster and more accurately. We added the following to the OONI API: * API endpoints for listing and filtering anomalous measurements * API endpoints for downloading full reports We changed the following: * Reverse sorting in `by_date` view and hide measurements from time travellers * Better API documentation thanks to redoc based on OpenAPI 2.0 * Improve request validation thanks to connexion base on OpenAPI * Oonify the UI * Better testing ## Stable release of the OONI data processing pipeline We now have a much stronger data processing pipeline (https://github.com/TheTorProject/ooni-pipeline/pull/62). The scheduling of the pipeline is based on Airflow which is more robust than our prior luigi based solution. By doing this we have been able to reduce the number of silent outages going undetected for weeks. The new version of the pipeline allows for much quicker feedback and interation, allowing us to run meaningful SQL queries that return result within minutes (not hours). This is also the foundation for building our new OONI measurements API. We feel confident that the pipeline is going to easily scale to up to 100 GB of network measurement data per day. The current rate is of ~20GB of measurements per day and we are able to process this amount of data within an hour (~10 min for compression, ~10 min for sanitisation, ~30 min for inserting it into the DB), so we have some margin for scaling up to 100GB a day without significant modifcations to our infrastructure. Currently the data is being processed in 24 hour batches, but based on the stats above, we are aiming to reduce that to 12h, 8h and eventually 1h. The pipeline has been designed to be modular and allow us to easily ingest network measurement data from other projects too. Currently the pipeline is analysing the data looking for blockpages and signs of DNS manipulation. We have plans for adding heuristics for detecting also more advanced insights in future versions. For the future of the pipeline see: https://github.com/TheTorProject/ooni-pipeline/milestone/2 ## Implement visualisations for the measurements interface Elio Qoshi has started working for OONI as a designer. With him we have started to define the overall design and style of all OONI related content. Some of this work has been integrated into our living style guide available at the following URL: http://openobservatory.github.io/design. Part of the work also includes data visualisations that are used to visualise OONI data (see, for example, the BarChart component). ## Data visualisations for reports and blogs Thanks to the work on the design front, we have started creating templates and guidelines for making charts that much such a task easier in the future. See: https://github.com/OpenObservatory/design/issues/2. We created data visualizations based on our new style guide that are included in the following reports: 1. Cuba: https://ooni.torproject.org/post/cuba-internet-censorship-2017/#findings 2. Iran: https://ooni.torproject.org/post/iran-internet-censorship/#findings ## Published research report on internet censorship in Iran In collaboration with ASL19, ARTICLE 19, and Small Media, we published a research report on internet censorship in Iran. The report is available here: https://ooni.torproject.org/post/iran-internet-censorship/ We also published a summary of the report on the Tor blog: https://blog.torproject.org/internet-censorship-iran-findings-2014-2017 ## Stable release of Orchestrator We released the stable version of Probe Orchestration. This features: * Support for sending push notifactions to all mobile probes that include a message * Support for having them run custom tests via the OONI Run custom URI scheme * Better unittesting that also speak to the database to ensure everything is working as expected See: https://github.com/TheTorProject/proteus/pull/28 For the time being we have decided to postpone including support for instrumenting probes to run measurements, following possible security concerns, see: https://github.com/TheTorProject/proteus/issues/24. Once we have come up with a more solid specification and a proof of concept implementation of this scheme, we would greatly appreciate feedback and maybe a third party security audit of our proposed approach. ## OONI Run We released OONI Run, a custom URI scheme for OONI Probe mobile apps that enables users to: * Engage others with testing the sites and running the OONI Probe tests (included in OONI mobile apps) of their choice * Embed an OONI Probe widget to monitor the blocking of their site around the world OONI Run is available here: https://run.ooni.io/ We also published a blog post that explains OONI Run: https://ooni.torproject.org/post/ooni-run/ ## Community We hosted our monthly community meeting on https://slack.openobservatory.org on 29th September 2017 at 14:00 UTC. We discussed the following: 1. OONI Run: Questions and feedback 2. Announcement of OONI API release: Questions ## Userbase In September 2017 ooniprobe was run 81,258 times from 1,595 different vantage points across 149 countries around the world. This information can also be found through our stats here: https://api.ooni.io/stats ~ The OONI team

1 0

UX team September summary
by Linda Naeun Lee 29 Sep '17

29 Sep '17

Hi all, September was another successful month for the UX team. This month, we: - met in person in NYC and designed torproject.org. (ticket <https://trac.torproject.org/projects/tor/ticket/22121>, archive of wireframes <https://drive.google.com/open?id=0B36YkvDtVNK_MU5ObVhEY1JBRUE>) - agreed on the new design of Tor launcher, and getting the progress bar to behave correctly and have nice icons (launcher design ticket <https://trac.torproject.org/projects/tor/ticket/23261>, progress bar behavior ticket <https://trac.torproject.org/projects/tor/ticket/22266>, icons ticket <https://trac.torproject.org/projects/tor/ticket/23486>) - finalized the Onion Browser branding survey and started to build the survey application to host the survey ourselves (ticket <https://trac.torproject.org/projects/tor/ticket/23376>) - started to work on a live style guide with all the bootstrap elements stylized in a Tor way (ticket <https://trac.torproject.org/projects/tor/ticket/23411>, preview prototype <https://marvelapp.com/6c5ce44>) - updated the metrics website with new style guidelines (ticket <https://trac.torproject.org/projects/tor/ticket/23383>) - started to building the Tor monthly newsletter (ticket <https://trac.torproject.org/projects/tor/ticket/23437>) Yay, Linda N. Lee Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2

1 0

Yes, dist.torproject.org is messed up
by Roger Dingledine 29 Sep '17

29 Sep '17

Since you're all about to encounter a user asking you this question: Yes, https://dist.torproject.org/ is messed up. And yes, there are new versions of Tor Browser out today, and they are all trying to update, and they are now all giving their users confusing errors like "The update could not be verified" and "The requested URL /torbrowser/7.0.6/tor-browser-linux64-7.0.6_en-US.tar.xz was not found on this server." The short answer is to sit tight and wait, and everything should sort itself out over the coming 24 hours. Unless you're one of the few people who can help fix it, in which case, please help us make everything sort itself out. :) --Roger

1 1

notes from usdoj panel talk
by Roger Dingledine 29 Sep '17

29 Sep '17

Hi folks, Last week I was on a panel with a bunch of US Department of Justice prosecutors who specialize in child exploitation cases. I wrote notes for all the things I wanted to say, and of course my plan didn't stay intact once the panel discussions began, but here are the notes for posterity. Maybe they will be useful next time I (or you!) find ourselves in this situation. --Roger Three points as general Tor intro: * Tor's history, including funding -- NRL, EFF, State Dept, Darpa, NSF * Two pieces to the "metadata security" that Tor provides: the core Tor component that hides your IP address, and Tor Browser which deals with application-level fingerprints. * Millions of users use Tor every day -- ordinary people, activists, censored people, militaries and law enforcement. That variety is part of what makes it safe to use for all of them. [Story about Dutch cop anonymity system if we want it.] Follow-up question: The core Tor part? Why is Tor different from a standard proxy or VPN? * Distributed trust -- privacy by design, not privacy by promise. * Relays are run by community, 100gbit of traffic on average [Story about anonymizer if we want it] * Transparency for Tor is key: design docs, specs, source code, but also global engagement as real human beings. (It's not a contradiction for privacy people to believe in transparency. Privacy is about choice, and we feel that choosing to be transparent is the best way to establish and grow trust with our communities.) * Ok, so what are hidden services? Most people use Tor to reach websites and other services safely. Onion services (aka hidden services) are special addresses inside Tor that flip that around: people can reach *you* safely. - better security built-in - can be faster since not competing with exit traffic - reduced vulnerability surface area - mobility * We measured what fraction of Tor traffic has to do with onion services: 3%. - Something like 7000 onion service websites up at a given time https://blog.torproject.org/some-statistics-about-onions - Compare to 2.5M-or-more users *each day* (That's not nothing, but it is tiny. If you find somebody trying to scare you with huge numbers and pictures of icebergs, make sure you understand their business model before buying their product or believing their claims.) * Some examples of interesting onion services? [Pause while we get distracted by other panelists] "Securedrop" is a tool for people to communicate securely with journalists -- the New York Times, the Guardian, the Washington Post, Toronto Globe and Mail, the AP, etc all run onion sites. (Compare to the FBI's tipline, where they pay Cloudflare to mitm it.) Ricochet Onionshare * The biggest website that has an onion service? Facebook. In April of last year they posted that 1 million people accessed Facebook over Tor in that month. That's .1% of their user base! * Onion services protect different metadata than https, and it's about giving the users choice. onion services features: - stronger security, built-in: - encryption - authentication, so no dependency on the crappy CA model - authorization, so untrusted people can't even reach the webserver - can be faster since not competing with exit traffic - reduced vulnerability surface area - mobility Surprising (to this audience) users of onion services: Facebook mobile Debian updates IoT operators Activist blogger platform example Govt and law enforcement ------- Child exploitation sites/users are bad for Tor! They're bad for society in general, but they're bad for Tor in particular. We don't want them as users. See also the discussion at the end of https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html What are onion services "most" used for? It depends how you count: Internet Watch Foundation annual report has hidden services listed as "<1%" of the problem: https://www.iwf.org.uk/report/2015-annual-report Terbium Labs "dark web" report concludes the majority of onion service content is legal: https://terbiumlabs.com/darkwebstudy.html I hear bad people use google drive and dropbox for better bandwidth. But all that said, I don't want to say there is no problem. * What are some ways of screwing up your security while using Tor? Opsec mistakes; metadata fingerprinting; browser exploits; traffic analysis. NSA/GCHQ quote about Tor: King of low-latency anonymity systems UN HR report endorsing Tor. ---- Contradictions for the audience to think about: - If Tor works, you don't hear about it. So it's easy to overlook or undercount the "good" users. - Sometimes investigators have to choose between being able to discover victims vs being able to bust people. - If there is some approach that is able to compromise bad people, the same approach can compromise good people. - Often, the bad guys work harder on their security than the good guys. - If we make Tor stronger, we make it stronger for all. - There are many ways to be bad on the Internet, and fewer ways to be safe. Central to Tor is the topic of power imbalances: those who have power are less in need of Tor's protections than the most vulnerable populations. Matt Blaze's great quote about politicians who ask for crypto backdoors: "You can put a man on the moon, so surely you can put a man on the sun!" ---- Problems with "govt hacking" as a solution to "bad people": - 1) Secrecy: we as society need to have an informed discussion, and if governments won't tell us what they do, how can society make a good decision? - NSA's goals, the existence of other countries makes this even harder. - 2) The Feds lose their zero-days, and that hurts everybody. Cf "Shadow brokers". - 3) When mass surveillance becomes the cheapest and easiest option for fighting any crime... "Well sure, maybe you trust the people in power now... but what if the people in power change?" I bet US govt people are especially sensitive to this argument this year. In many ways this is the same as the Apple encryption discussion, and the "https everywhere" discussion.

2 1

New meetbot plan: #tor-meeting and nowhere else
by Roger Dingledine 28 Sep '17

28 Sep '17

Background on meetbot: it is the irc bot that we use to help coordinate our various Tor team irc meetings, and record results for posterity and transparency. See e.g. http://meetbot.debian.net/tor-dev/2017/ http://meetbot.debian.net/tor-project/2017/ So far we've had an ad hoc schedule and location for irc meetings, spread around both #tor-project and #tor-dev. After an incident with our meetbot where we accidentally left it logging #tor-dev all weekend, we've decided to take a more defensive approach: we will hold the meetbot-mediated sessions in a new channel, called #tor-meeting. So, if you want to use meetbot -- and feel free to do so -- you should move your meeting to #tor-meeting. It might be wise to tell the folks at the previous location that you're doing it elsewhere, so people can join and watch / participate if they want. One downside could be that the meetings won't have as many random bystanders watching them, so maybe fewer people will get pulled in. But we can resolve that, maybe even more successfully, with better report-backs. I think the upside of making it clearer whether there is something logging, and publishing the logs to the internet, is worth trying this new approach. --Roger

1 0

Network team meeting notes, 25 Sep
by Nick Mathewson 26 Sep '17

26 Sep '17

Hi! Our meeting notes for yesterday are below. We had a problem with meetbot, and don't have logs for this week; with luck we'll have that straightened out by next week. Network team meeting, 25 September 2017 Last week's notes: how did we do? https://lists.torproject.org/pipermail/tor-project/2017-September/001447.ht… After this meeting, please: * Check everything assigned to you in 0.3.1 and 0.3.2. Should it be? Should it be deferred? * Check new and needs-info stuff in 0.3.1 and 0.3.2. Anything there that you should/could be handling? * Mark essential 0.3.2.2-alpha stuff with "0.3.2.2-alpha-must". teor: * Last week (or two): * Fixed a nasty bug in Experimental PrivCount that ignored most connection events * Added intro and rend failure reasons to Experimental PrivCount * Fixed a bug in Tor's HS stats noise, but we're missing a function (#23414) * anyone want to write a working round_int64_to_next_multiple_of? * Found a bunch of little bugs in Tor connections and HS v3, fixed some of them * Fixed some tor-spec bugs, reviewed others * Did some thinking about the longclaw move (we'll be fine) #23592 * Fell down the single onion service v3 IPv6 hole, trying to dig out again #23493 * This week: * Count the number of simultaneous connections per IP in Experimental PrivCount * Complete the HSDir events for Experimental PrivCount * Get ready to travel to the dev meeting * I'll be on leave next week, until the hackfest / dev meeting Nick: * Last week: - 5 releases on monday - Worked on a bunch of spec-related fixes. - Removed many tickets from 032 -- look for "032-deferred" or "032-unreached" items in Unspecified - Reviewed and merged a whole bunch of fixes - Tried to help diagnose a bunch of bugs and continue to triage things. - Worked on small/persistent/annoying bugs - Integrated scan-build to run nightly as part of my tor-auto stuff. - Automated lintchanges as part of "make check" * This week: - Sleep more - Help ahf and isis with release, targetting early next week (Monday?) - Continue fixing bugs - Write more proposals for 033 and beyond - Encourage people to defer, fix, fix, defer, etc. - Time permitting, look forward to sponsor8 stuff. - Montreal prep Mike: - Still sick and feverish.. Seeing doctor today... [asn: sounds like a lovecraft diary! get well soon!!!] dgoulet: * Last week: - Bug hunting on KIST and HSv3. Analyzing logs and trying to figure out what happened. - Addressing tickets in 032 related to scheduler and hidden service. - Review tickets in the 032 milestone - Some ticket triage happened as well. * This week: - Pretty much the same as above, I plan to continue addressing 032 tickets especially the hidden service v3 ones. - Work out with teor and asn the single onion service v3 IPv6 fix (#23493) komlo (offline): - Final round of review for protover-rust from isis- if all goes well, I will be submitting a patch early next week. - Preparing for the Rust hackfest in Montreal- will update the schedule based on asn's feedback this week. pastly: * last week: - help dgoulet fix KIST bugs * this week: - keep fixing KIST bugs as they appear catalyst: Last week (2017-W38): - Opened some tickets about streamlining release engineering - Fixed some clock skew reporting issues - Wrote some commentary about bootstrap progress reporting details in #22266 - Found #23623 (get_voting_schedule getting called 10k times in 1 second) - Lots of troubleshooting about possible bridge bypass (#20532) - Reviewed a bunch of things This week (2017-W39): - Montreal travel prep - More analysis of #20532 - More work on improving bootstrap progress and error reporting ahf: Last week: Sponsor 4: - Reviewed: #23568. Sponsor 8: - Had some problems with Android Oreo and some of the debugging scripts I used. - Refactored some of the Doze handling in Orbot and added some logging for myself to be able to debug some timing more easily on host. Misc: - Got through the Rust book and started toying around with a small program. - The test hub ircd for ng onion got a small makeover after we reached some limits. - Wrote a description of a chanserv feature we might like to see for OFTC. This week: Sponsor 4: - Fix #23551. Sponsor 8: - Finish some loose ends: help with the survey where I can + get content on the "bandwidth test" HS. - Start upstreaming some of the code for tor that I'm using to debug things with. Misc: - Prepare to roll a release for next week (with Isis + Nick) - should we talk about this during the week? - Go over the interview with BestVPN Q/A with Steph. - Look at tickets for 0.3.1 and 0.3.2 in trac that needs to be closed/pushed forward. - More Rust. asn Last week: - prop224 is currently in a controllable state. Most code has been merged, and all open tickets are non-critical things (don't impact security or reachability in a major way). We are now entering a deeper testing and bugfixing stage. - Made a wiki page for prop224: https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions and established a small testing hub on a friendly IRC network. We currently have about 15 testers but we need more! Check out: https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions#Howtoconnec… - More testing, bugfixing and test writing for prop224. Worked on #23621, #23603, #23159, #23641. Also see https://lists.torproject.org/pipermail/tor-dev/2017-September/012451.html - More debugging for some elusive discnnects on prop224 clients/services: #23543 Are we seeing too many client disconnects with prop224 or is it normal relay on a 6 hop circuit? We see lots and lots truncate cells with normal reasons (channel closed, or ended). - Managed a few hackerone bugs. - Triaged a few prop224 tickets that were on 0.3.2. - Did some preparation for the PhD. This week: - Need to figure out what to do with the open IPv6 + prop224 bugs (i.e. #23493). Delay until Montreal for discussion, or handle the first part now? - More testing and dogfooding of prop224. We should have a Tor Browser with 0.3.2.1-alpha soon so more testing will happen :) - Work on the various open prop224 tickets: #23621, #23603, etc. - Prepare for Montreal meeting. - Do reviews as needed. isis: last week: - finished farfetchd CAPTCHA server #15967 - ristretto standardisation meeting (also for vxeddsa and ristretto-based sigs) - took a day off to do political organisation work - started the moat backend #22871 - scheduling meeting sessions for montréal - this week: - ask for a server to deploy farfetchd? not sure if it should be a separate VM but it could be - more scheduling for meeting session - releasing 0.3.2.2-alpha isabela Last week: - finished time allocation update with brad (will check with nick on sending the relevant changes to network team) - started coordinating with Alison on contacts for tests/measurements we need to do for sponsor8 - send invoices reports related to sponsor8 - missed meeting cuz I was on bus (traveling) This week: - finishing survey for apps developers (sponsor8) - finish text for download measurement test - finish obtain contacts for download tests - finish error paths and msgs for progress bar (i know catalyst is looking for this) - wondering how moat api is doing (question for isis) - trying to figure out who can call in for PT community meeting organized by internews

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project September 2017