- tor-project - lists.torproject.org

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

17 Jan '18

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

5 9

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

17 Jan '18

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

2 2

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

16 Jan '18

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

1 0

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

16 Jan '18

Hi! We had our second Tor Browser meeting in 2018. Here is the meeting transcript: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-15-19.00.log… And the notes from the pad are: Monday, January 15, 2018 Discussion: -What about Taler (https://taler.net/en/ ) integration into Tor Browser? -Who wants to be the PoC for Pari's helpdesk reports (following it, amending it with tickets we already track, making sure it is correct from a browser side etc.)? (Richard volunteered) -I want to establish some feedback mechanism within the team by doing a 1to1 with each team member, say at least once a year. I plan to start this round end of June 2018 mcs and brade: Last week: - Worked on Moat integration loose ends (#23136). - incorporated activity spinner image from Antonela (#24696). - added support for multiple bridges returned by BridgeDB. - reviewed dcf's patch for #24642 (cannot use TOR_PT_EXIT_ON_STDIN_CLOSE) - Attended the UX + Tor Browser meeting on IRC. - Read the Android Torbutton and Tor Launcher proposals. - Investigated the Tor Launcher aspects of #24826 (compressed consensus diffs stall Tor Browser launch). - Worked on #24421 (Temporarily allow all this page and New Identity). - Helped with triage of new tickets. Planned for this week: - After a test server is deployed by the Network Team, test and put Moat integration code out for review. - Comment on Matt's Android Tor Launcher proposal. - Do more debugging for #24421 (Temporarily allow all this page and New Identity). - Work on about:tbupdate issues (#21850 and #24578; avoid using a query string), Georg: Last week: -fought my backlog -ticket review (and partially merge): #24702, #23911, #23892, #24842, #21245, #22343, and #18691 -made a bit progress on our mingw-w64/clang-based toolchain (#21777) -wrote a patch for #23916 -worked on the Tor Browser design doc update (#21256) -worked on the proposal for the toolbar redesign and better understanding of security features -started to think about our android reproducible builds and updates for Tor Browser on Mobile This week: -release preparations for 7.5 and 8.0a1 -more reviews -finish design doc update (#21256); aimed for Friday this week -further work on the proposal for the toolbar redesign and better understanding of security features -think about some improvements to our release signing scripts arthuredelstein Last week: - Worked on rebasing tor-browser.git to mozilla-central. I am about 2/3 of the way through. Once all patches are rebased, I will set up on a nightly automatic rebase script. - Made a list of patches we should try to upstream for ESR60. I will send the list to tbb-dev and update bugzilla where needed. - Attended the Mozilla/Tor UX video meeting and a second meeting with Mozilla uplift team on fingerprinting patch triage. - Checked in https://bugzilla.mozilla.org/show_bug.cgi?id=1384309 This week: - I will continue to work on the rebase, and also push forward any upstreaming patches that look feasible. - Try to move forward on https://trac.torproject.org/24309 (tor circuit door hanger) - If there is time, I also want to look at https://trac.torproject.org/14952 (HTTP2 audit/patching) boklm: Last Week: - Worked some patches for: - #24842 (debug builds are missing libasan.so.2 and libubsan.so.0) - #18691 (switch Windows builds from precise to jessie) - #24879 (enable fetching of new commits by default for nightly builds) This Week: - follow the fpcentral setup - make our testsuite run on nightly builds - look again at some improvements to our release signing scripts (#24331) - review #23916 (Create a new MAR signing key for Tor Browser) - help with building of the new releases igt0: Last Week: - PoC Tor Button for Mobile(basically, I moved the code to the tor-browser.git and started to integrate with the Firefox build system). - Updates in the Tor Button proposal - Reading about how tor-android( https://github.com/n8fr8/tor-android) works This Week: - Finish the PoC - Review sysrqb proposal - Updates to the tor button proposal pospeselr: Last Week: - investigated more avenues regarding #15559 (Range requests used by pdfjs are not isolated to URL bar domain); conclusion I've come to is there no nice surgical fix here - pdf.js seems to require the nsISystemPrincipal for range-based requests to work properly - the JS Context the range-requests run in are missing the original principal and first-party domain information needed to be put on the correct circuit - looks like the best that can be done is to just disable range-based requests, but at the cost of pdf performance - will no longer be able to read pdfs as they load, the whole thing has to be downloaded This Week: - it's easy enough to disable range-request, so will have a patch up for this later today - will find some other (hopefully simpler) fingerprinting bug to work on Georg

1 0

Network team meeting moved to Tuesday
by Alexander Færøy 15 Jan '18

15 Jan '18

Hello, The weekly network team meeting at 18:00 UTC in #tor-meeting on OFTC have been postponed to tomorrow (Tuesday the 16/1) due to the US holiday Martin Luther King Jr. Day! The meeting tomorrow will take place at the usual time at 18:00 UTC :-) Cheers, Alex. -- Alexander Færøy

1 0

'How to Run a Relay' Brochure/Flier
by Tom Ritter 12 Jan '18

12 Jan '18

I think we should make one. It'll be useful at Defcon, HOPE, and a bunch of other places. I'm hoping Alison/the community team thinks this is a good idea and can assist me in making sure it dovetails with the rest of their efforts in https://trac.torproject.org/projects/tor/ticket/24497 What I probably _can't_ do is graphically design it in a way that meshes well with any other materials we have. I talked with Steph in December, she may be interested in this? I've started a pad to start this process and cover what I think should be contained: https://storm.torproject.org/shared/kOwybHn5VZdMRDm1L-kQg6P-DMC3G2w0Zn5XLQ1… We have to fit everything on front-and-back on a standard 8.5x11" sheet so we'll have to make some tough decisions about what we include and what we don't, but this is a start. -tom

3 2

Re: [tor-project] User queries and issues for Nov-Dec'17
by Parinishtha Yadav 12 Jan '18

12 Jan '18

On 12/01/18 3:23 PM, Georg Koppen wrote: > Parinishtha Yadav: >> >> On 08/01/18 5:32 PM, Georg Koppen wrote: >>> Parinishtha Yadav: >>>> Hello people of Tor >>>> >>>> Wish you all a very happy new year! As an Outreachy intern with Tor, I >>>> spent the last month gathering data and user queries from different >>>> platforms on the internet (IRC, mail handles, Tor blog comments, >>>> stackexchange, tor subreddit, RT, etc.). The aim was to have all these >>>> queries in one place, in a sorted and organised manner. Some of the >>>> queries identified will be added to the support portal by the community >>>> team. >>>> >>>> I have created a spreadsheet on storm, with the following read only link >>>> - https://storm.torproject.org/shared/RV8v026JvwzZ_82ZMRO_4GHAxUtqUhW8Abu6xaQ… >>>> <https://storm.torproject.org/shared/RV8v026JvwzZ_82ZMRO_4GHAxUtqUhW8Abu6xaQ…> (the >>>> first sheet has bugs/errors and the second one contains doubts/queries). >>>> You can find the legend for colors used on the top right of the sheet. >>>> In case anyone feels this will be relevant to their work in any way, or >>>> is looking to pick some bugs to fix or areas to work on, you are welcome >>>> to refer to this spreadsheet. >>>> >>>> This is my first time sending this spreadsheet out, and I plan to keep >>>> doing so around the same date every month. So in case there are any >>>> suggestions that come to mind, don't hesitate to shoot me a mail and I >>>> will do my best to take them into account and make this as helpful as >>>> possible. >>> Thanks for collecting the information and putting it into that >>> spreadsheet. Really appreciated. I wonder about the workflow in case >>> changes to the spreadsheet are necessary. E.g. if one opens a bug on >>> Trac after reading a report and now wants to update the spreadsheet with >>> the bug number. Or if one wants to add already existing bug numbers. >>> >>> Sending a mail to the tor-project list for those small changes seems too >>> noisy to me. Should we just send an email to you and you'll update the >>> spreadsheet accordingly? Or could we just make it editable (if we are >>> worried about that in general then only for a bunch of folks) to make >>> that process more efficient? >>> >>> And how do we developer interact with you ideally in case we have >>> follow-up questions about some of the spreadsheet items? Are you on IRC >>> in one of the tor channels? Or should we write you an email? Or... >>> >>> Georg >>> >>> Hey Georg >>> >>> As for the workflow, I agree that there is no need to send out a mail >>> on tor-project with small issues. There are two strategies we can >>> follow simultaneously: >>> 1. I can give edit rights to a small group of people. This is for >>> people who regularly work on this stuff and they then may not email or >>> contact me every time, but can make the necessary updates on their >>> own. Please let me know who all to share access with. I am attaching >>> my public key and signature along. > Thanks. I'll talk to the team next Monday in our meeting (1900UTC in > #tor-meeting) figuring out how we want to handle it. Let's go with > access rights from there. I will try to join in on that meeting. In case there's anything that pops up then.. > >>> 2. People can mail me personally with the information they want >>> updated on the spreadsheet and I will take care of it. This method can >>> be used by people who will be sending out this information >>> occasionally and do not have edit rights. > Let's start with some observations: > > 1) Regarding row 30: I wonder whether Malwarebytes is responsible for > that we have https://trac.torproject.org/projects/tor/ticket/24709 where > another weird issue got resolved once this tool got disabled. I wonder > if that could help with row 26 and row 25 as well. > > 2) I think row 3 and row 18 can got together (maybe just mentioning the > two different error codes in column D. > > 3) row 21 and 40 is #24136. I wonder whether we should have just one row > for both. > > 4) re row 45: Did anybody contact the Tails people about that? Might be > worth it. At least to know whether they are aware of this issue and have > a ticket number for us for the spreadsheet. I have added #24709 as a "possible issue" for 30, 26 and 25. Have combined 3 and 18 as suggested. Also added #24136 as the ticket for 21 and 40. (Didn't combine them yet since they were listed under different operating systems, but have mentioned in both rows that the same issue exists on the other operating system) > >>> As for developer interactions, I am available on IRC on #tor-project >>> and #tor-meeting with the username pari. Let me know if you want me to >>> be active on any other channels too. (like #tor-dev) >>> And of course, writing me a mail is always another option you can >>> exercise. I usually reply within an hour. > That's perfectly fine, no worries. And welcome! > > One thing I am wondering is how the update to the spreadsheet is > working. I am especially interested in easily finding out changes over > time. How is that planned? I discussed this with Alison in our meeting on Wednesday, and for now, we have decided that I should go ahead and create a new sheet on the same spreadsheet, called 'January bugs' and 'January doubts'. That will keep track of any new issues that are coming up this month, while I will keep updating items on the older sheet as they are fixed,etc. Having just one link to the spreadsheet for several months will make it easier to keep track of things. Maybe after a few months, I can create a whole new fresh spreadsheet as this one will have way too many sheets. During the first week of every month, I will send out a mail that calls out issues and changes over the previous month, and also outlines the areas that users have been reporting for the particular month. For eg: my mail for first week of February will list the issues that have been coming up over January, and also mention issues that were fixed from the Dec spreadsheet. Let me know what you think of this! Cheers, Pari > Georg >

1 0

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

12 Jan '18

Notes for January 11 2018 meeting: Alison: 1) I'm excited to be serving on the FSF Award Committee again! 2) Amogh is going to give a Tor talk at nullcon in Goa, India next month. Helping him prepare. 3) Connected with the people in India who run Privacy Month 4) Connected to some privacy activists in Uganda 5) Preparing for a talk at the University of Washington next week. 6) LFI applications are starting to trickle in! Deadline is February 1. I continue building the curriculum and schedule. 7) Work continues on the relay ops wiki/#24497. 8) Added more content to the support portal articles. Phoul is working on the translation plan. The UX team will then get them added to the portal, which is now being built. 9) Pari sent out her user issues/bugs spreadsheet, and it's already getting a lot of use! 10) Phoul isn't making any progress with Transifex about the webml issues. He's going to follow up with me and the UX team about next steps. 11) Phoul is submitting our GSoC org application! 12) on Friday I'll go on Deutschlandradio to talk about LFP 13) Shari, gunner, Jon and I started planning the Rome meeting. Can we talk about having an "Around the Tor World" plenary? 14) Our Tor talk was accepted to LibrePlanet! I followed up with the people who agreed to present. 15) Connected with Kevin Gallagher who worked on this paper: https://www.usenix.org/system/files/conference/soups2017/soups2017-gallaghe…. He's working on a CS PhD at NYU and his thesis is about Tor. Roger: 1) Finished PETS reviews. 2) teor and I have been talking to the OVH abuse people about the current network overload, and at their suggestion I filed an official abuse ticket on Monday morning. On Tuesday they passed my "please contact us" request on to the overloaders. Here's hoping. 3) Been helping dgoulet with a technical mitigation for the overload. 4) Wrote up draft statement-of-work and budget for upcoming censorship circumvention project. Isa/Georg/Nick/Shari, hoping for feedback. 4a) We're going to want to hire one or more Snowflake devs soon. 4b) Accounting-wise, this one is cost-reimbursement, and so are SIDA and DRL and NSF, so we're going to need to get more serious about efficient time allocations. 5) I'm going to Seattle in late January for an internal-Tor coordination meeting, and to NYC in mid Feb for a conference talk and for an NYU Tor pep rally. 6) At the 34c3 relay operator meetup, we talked a lot about scheduling more in-person relay operator meetups in 2018 so we don't feel forced into going to 35c3 just for that. Alison, can you send me your notes from our Montreal conversation about the _relay coordinator_ job description? A funding proposal seems wise too. [Alison: yes, I will send you this.] Georg: 1) Fought my backlog 2) Preparations for Tor Browser 7.5 (due on January 23) 3) Coordination with the UX team about all the projects we plan to work on in Q1/Q2 2018 4) Alison: are we good with Tor folks being at Rightscon? Do we have the right people planning to come? [Alison: the proposal we ended up submitting is a panel on ethical user testing/design with Simply Secure and a few other orgs. The Tor person who is going to be on the panel is Sukhbir, who is working on the Sponsor 9 user testing. I don't know which other Tor people are planning to go.][Georg: okay, sounds good] Mike: 1) Mostly heads down working on guard stuff for 0.3.3 Nick: 1) 0.3.2 is stable; 0.3.3 alpha should be out later this month; new stable releases for other series soon. 2) Still somewhat in disarray from the winter break. Arturo: 1) Published a blog post on the situation in Iran: https://ooni.torproject.org/post/2018-iran-protests/ 2) Established partnership with the Digital Society of Zimbabwe (https://twitter.com/OpenObservatory/status/950317331493867521) 3) Started implementing the revamped OONI Explorer 4) Dealt with various infrastructure hurdles that are now, mostly, resolved or going to be resolved 5) Measurement Kit windows support is moving forward pretty well 6) Releasing today/tomorrow a new version of OONI Probe mobile with support for the Instant Messaging tests 7) Added some stuff to the Tor trac page for the Rome meeting: https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome. Let me know if you would like to know anything in particular about Rome :) Karsten: 1) Playing Whac-A-Mole with Onionoo tickets on Trac. 2) Reviewing/revising patches to sanitize and parse torproject.org web logs. 3) Updated format of the News page on Tor Metrics, and added support for displaying ongoing events. https://metrics.torproject.org/news.html isabela: 1) closing sponsor4 work (january is the last month) 2) working on sponsor9 work plan 3) trying to keep everything else moving while i am doing the above ^^ - organized meetings this week for: 3.1) user testing in India - Antonela and Sukhbir are organizing an event in Mumbai, where they will give talks about tor and do user testing with the audience 3.2) sync with Tor Browser and UX team - 2018 will be the year of user experience revolution at Tor Browser! :) lots going on here, so we did a sync to get everyone in the same page, more here: https://storm.torproject.org/shared/s2-cU-9VsopW7SryzRzNPyQg35TB-sdcBlTFfHD… 3.3) sync with comms and community on support.torprpoject - we will probably launch this in early Feb! tasks lists and updates can be found here: https://pad.riseup.net/p/support-tpo 4) reviewing roadmaps for ux, services and network team - I also plan on organizing another big sync with all teams on roadmaps/dependencies in February as a kickoff for preparing to do new roadmaps in Rome (March).

1 0

Community Team December update
by Alison Macrina 11 Jan '18

11 Jan '18

Hello Tor World, Here's an update from the Community Team for December! December 2017 Community Team report Meeting notes December 2017 ================================================================== https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam#Curre… December was a short, but still productive month! Support ================================================================== We finalized the copy that will go into the support portal and started thinking about who should be responsible for maintaining and updating this information. We also continue to answer user questions from frontdesk@. Our Outreachy intern Pari did a lot of work on the user issues spreadsheet (and now in January it's released!). Relay operators guide ================================================================== We got a lot of work done on the relay operators guide (#24497 and here https://trac.torproject.org/projects/tor/wiki/TorRelayGuide) Tor talks ================================================================== We helped organize a Tor talk at nullcon in Goa, India for 2018. Library Freedom Institute ================================================================== LFI applications opened (libraryfreedomproject.org/lfi) and the blog post went up https://blog.torproject.org/new-program-turns-librarians-privacy-advocates. Community governance ================================================================== We finalized the draft text for the code of conduct proposal (which is now in the discussion phase on tor-internal@). Alison attended the Mozilla All-Hands meeting and met the amazing Diversity and Inclusion team. Got lots of feedback on Tor community stuff and looked at Mozilla's community participation materials. ================================================================== -- Alison Macrina Community Team Lead The Tor Project

1 0

December 2017 Report for the Tor Browser Team
by Georg Koppen 10 Jan '18

10 Jan '18

Hello! Here comes the Tor Browser status report for December 2017. In that month the team made three releases, Tor Browser 7.0.11[1], 7.5a9[2], and 7.5a10[3]. The first two releases were mainly concerned with including new Tor versions (0.3.1.9 and 0.3.2.6-alpha respectively) and fixing Firefox security bugs. Tor Browser 7.5a10 tested various fixes for inclusion in the upcoming Tor Browser 7.5. Most notably we sorted out why "Print to File" on Linux was broken[4][5], updated the security slider copy to get it more in line with what is shipped with Orfox on Android[6], and made sure CSS line-height does not reveal the user platform[7]. Non-release work focused on making progress on our remaining Sponsor 4 deliverables: getting Moat[8] and FPCentral[9] deployed. Alas, we did not finish those items in December but we plan to do so this month. Moreover, we coordinated with the UX and the network team to get several usability improvements into Tor Browser, starting from a better circuit display[10] over redirecting users to .onion websites[11] to communicating the security state of .onions better[12]. On the mobile side we worked on including all the Orfox changes into our tor-browser.git repository.[13] That way we can easily build all flavors of Tor Browser from a single repository. Additionally, work got started to make Torbutton and Tor Launcher compatible with mobile requirements. The full list of tickets closed by the Tor Browser team in December is accessible using the `TorBrowserTeam201712` keyword in our bug tracker.[14] In January we plan to get Tor Browser 7.5 out, containing lots of improvements worked on in the past weeks and months. We'll continue working with the UX team on making progress on the above mentioned projects and plan to write a proposal for streamlining the security controls visible on the Tor Browser toolbar. We plan to finally get FPCentral and Moat deployed and on our mobile side of things we hope to have all Orfox patches merged and work will be under way to adapt Torbutton and Tor Launcher to mobile requirements. A first proposal for Torbutton got already posted on the tbb-dev mailing list.[15] All tickets on our radar for this month can be seen with the `TorBrowserTeam201801` keyword in our bug tracker.[16] Georg [1] https://blog.torproject.org/tor-browser-7011-released [2] https://blog.torproject.org/tor-browser-75a9-released [3] https://blog.torproject.org/tor-browser-75a10-released [4] https://bugs.torproject.org/23970 [5] https://bugs.torproject.org/23016 [6] https://bugs.torproject.org/21847 [7] https://bugs.torproject.org/23104 [8] https://bugs.torproject.org/24689 [9] https://bugs.torproject.org/6119 [10] https://bugs.torproject.org/24309 [11] See: https://lists.torproject.org/pipermail/tor-dev/2017-December/012660.html and follow-up emails [12] https://bugs.torproject.org/23247 [13] https://bugs.torproject.org/19675 [14] https://trac.torproject.org/projects/tor/query?status=closed&keywords=~TorB… [15] https://lists.torproject.org/pipermail/tbb-dev/2018-January/000723.html [16] https://trac.torproject.org/projects/tor/query?status=accepted&status=assig…

1 0