tor-project

tor-project@lists.torproject.org

16 participants
2324 discussions

Job Announcement - Software Developer
by Erin Wyatt 12 May '22

12 May '22

Hello, everyone! We are looking for two new Software Developers (same job, two positions): https://www.torproject.org/about/jobs/software-engineer-applications-team-2/ <https://www.torproject.org/about/jobs/software-engineer-applications-team-2/> Please refer anyone you think might be interested and help us spread the word. Thank you! Erin Wyatt Director of People Operations (she/her) ewyatt(a)torproject.org <mailto:ewyatt@torproject.org> PGP: 35E7 2A9F 6655 45F9 2CB6 6624 BA0C 9400 F80F 91CE https://www.torproject.org <https://www.torproject.org/> http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/ <http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/> ------------------------------------ >8 # Internet Freedom Nonprofit Seeks Software Engineer for Applications Team The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies, is seeking a Software Engineer to work on the Applications team. Our Applications Team’s main project is the Tor Browser but we have plans to develop other apps in the near future. We are looking for a full-time developer to join our team to help us with both Tor Browser development and future application development. Regardless of whether you have all of the required experience, please apply! If you feel that you meet several of the qualifications, or could meet them with a little support, we would love to hear from you. The team coordinates both synchronously and asynchronously via IRC, email, bug trackers, and some voice meetings. A personal commitment to free and open source software, good communication and documentation skills, and passion for contributing to the greater good are all essential. This is a full-time, remote position. Salary for this position is $100k USD and there is voluntary opt-in salary transparency for employees and contractors. ## The Job: • Evaluate and audit recent changes in Firefox, and understand how that affects Tor Browser users • Support maintaining Tor Browser on top of recent versions of Firefox • Improve Tor Browser’s security, privacy, and anonymity properties • Collaborate with Mozilla and directly improve Firefox • Simplify and improve Tor Browser's current protections • Support the continuous integration testing framework and tests • Improve Tor Browser's web compatibility Our main codebases are a combination of multiple components that make Tor Browser (https://gitlab.torproject.org/tpo/applications/team/-/wikis/Development-Inf…). For a more detailed understanding of the full breadth and depth of the work you'd be doing, have a look at The Design and Implementation of the Tor Browser, especially The Design Requirements section at https://spec.torproject.org/torbrowser-design#DesignRequirements. ## Preferred Qualifications: • Be comfortable working remotely with a geographically distributed team. • Experience interacting with users and other developers online, including experience being confronted with differing ideas and opinions, while maintaining a high level of professionalism. • Strong ability to become familiar with, modify, and maintain legacy codebases. • Experience updating and maintaining software build systems. • Distributed version control systems, including Git. • Experience developing and debugging software in a Linux environment. • Familiarity with: JavaScript, HTML, CSS; C++ and Rust; Kotlin and Java. • Experience developing and debugging software for the Android platform. • Familiarity and/or experience with writing add-ons and/or patches for Mozilla Firefox or other web browsers. • Familiarity with web technologies and how the web works, especially the same-origin model and web tracking. • Familiarity with browser fingerprinting defenses. • Familiarity with Firefox's internal architecture, including its use of multiple processes and sandboxing. Again, this is a wish list, and we do not expect any candidate to have experience in all these areas. If you you meet at least several of the qualifications, or could meet them with a little support, please apply! ## How to Apply To apply, submit a cover letter, your CV/resume, and a link to a code sample or some non-trivial software project you have significantly contributed to. In your cover letter, please include the reason you want to work at the Tor Project and where you heard about this job. IMPORTANT: Please email application materials in PDF format to job-dev at torproject dot org with "Applications Developer" in the subject line. ## About The Tor Project The Tor Project's workforce is smart, committed, and hard working. We currently have a paid and contract staff of around 40 developers and operational support people, plus many thousands of volunteers who contribute to our work. The Tor Project is funded in part by government research and development grants, and in part by individual, foundation, and corporate donations. Tor is for everyone, and we are actively working to build a team that represents people from all over the world - people from diverse ethnic, national, and cultural backgrounds; people from all walks of life. We encourage people subject to systemic bias to apply, including people of color, indigenous people, LGBTQIA+ people, women, and any other person who is part of a group that is underrepresented in tech. We have long-standing community guidelines and cultural norms. Our community is committed to creating an inclusive and welcoming environment. Please read more here: • The Tor Project Code of Conduct: https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t… <https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t…> • The Tor Project Social Contract: https://gitweb.torproject.org/community/policies.git/tree/social_contract.t… <https://gitweb.torproject.org/community/policies.git/tree/social_contract.t…> • The Tor Project Statement of Values: https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu… <https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu…> The Tor Project has a competitive benefits package, including a generous PTO policy, 16 paid holidays per year (including the week between Christmas and New Year's, when the office is closed), and flexible work schedule. Insurance benefits vary by employment status and country of residence. The Tor Project, Inc., is an equal opportunity, affirmative action employer.

1 0

minutes from the TPA meeting
by Antoine Beaupré 10 May '22

10 May '22

It's that time of the month again! We met, and here are our minutes. TL;DR: we'll upgrade to Mailman 3, not self-hosted Discourse, Icinga vs Prometheus still up in the air, request templates coming. # Roll call: who's there and emergencies materculae is doing OOM errors: see [tpo/tpa/team#40750][]. anarcat is looking into it, no other emergencies [tpo/tpa/team#40750]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40750 present: anarcat, gaba, kez, lavamind # product deployment workflow question Gaba created an issue to provide feedback from the community team in [tpo/tpa/team#40746][]: > Something that came up from one of the project's retrospective this > month is about having a space in TPI for testing new tools. We need > space where we can **quickly** test things if needed. It could be a > policy of getting the service/tool/testing automatically destroyed > after a specific amount of time. [tpo/tpa/team#40746]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40746 Prior art: out of the [Brussels meeting][], came many tasks about server lifecycle, see in particular [tpo/tpa/team#29398][] (a template for requesting resources) and [tpo/tpa/team#29379][] (automatically shutdown). [Brussels meeting]: https://gitlab.torproject.org/legacy/trac/-/wikis/org/meetings/2019Brussels… [tpo/tpa/team#29398]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29398 [tpo/tpa/team#29379]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29379 We acknowledge that it was hard to communicate with TPA during the cdr.link testing. The [cdr.link issue][] actually took 9 days to complete between open and close. But once requirements were clarified and we agreed on deployment, it took less than 24 hours to actually setup the machine. [cdr.link issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40578 In general, our turnaround time for new VMs is currently one business day. That's actually part of our OKRs for this quarter, but so far it's typically how long it takes to provision a VM. It can take longer, especially when we are requested odd services we do not understand or that overlap with existing services. We're looking at at setting up templates to improve communication when setting up new resources, inspired from the [service cookbooks][] idea. The idea behind this mechanism is that the template helps answering common question we have when people ask for services, but it's also a good way to identify friction points. For example, if we get a *lot* of requests for VMs and those take a long time, then we can focus on automating that service. At first the template serves as an input for a manual operation, but eventually it could be a way to automate the creation and destruction of resources as well. Issue [tpo/tpa/team#29398][] was put back in the backlog to start working on this. One of the problems is that, to have issue templates, we need a Git repository in the project and, right now, the tpo/tpa/team project deliberately doesn't have one so that it "looks" like a wiki. But maybe we can just bite that bullet and move the wiki-replica in there. [service cookbooks]: https://lethain.com/service-cookbooks/ vs wiki # bullseye upgrade: phase 3 A quick update on the phase 2 progress ([tpo/tpa/team#40692][]): slower than phase 1, because those servers are more complicated. We had to had to deprecate python 2 (see [TPA-RFC-27][]), so far network health and TPA affected. Both were able to quickly port their scripts to Python 3 so far. Also had difficulties with the PostgreSQL upgrade (see above materculae issue). [TPA-RFC-27]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [tpo/tpa/team#40692]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692 Let's talk about the difficult problems left in [TPA-RFC-20][]: bullseye upgrades. [TPA-RFC-20]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse… Extract from the RFC, discuss each individually: > * `alberti`: `userdir-ldap` is, in general, risky and needs special > attention, but should be moderately safe to upgrade, see ticket > [tpo/tpa/team#40693][] Tricky server, to be very careful around, but no controversy around it. > * `eugeni`: messy server, with lots of moving parts > (e.g. Schleuder, Mailman), Mailman 2 EOL, needs to decide whether > to migrate to Mailman 3 or replace with Discourse (and > self-host), see [tpo/tpa/team#40471][], followup in > [tpo/tpa/team#40694][], Schleuder discussion in > [tpo/tpa/team#40564][] [tpo/tpa/team#40564]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40564 One of the ideas behind the Discourse setup was that we would eventually mirror many lists to Discourse. If we want to use Discourse, we need to start adding a Discourse category for *each* mailing list. The [Mailman 3 upgrade procedure][], that said, is not that complicated: each list is migrated by hand, but the migration is pretty transparent for users. But if we switch to Discourse, it would be a major change: people would need to register, all archive links would break, etc. [Mailman 3 upgrade procedure]: https://docs.mailman3.org/en/latest/migration.html We don't hear a lot of enthusiasm around migrating from Mailman to Discourse at this point. We will therefore upgrade from Mailman 2 to Mailman 3, instead of migrating everything to Discourse. As an aside, anarcat would rather avoid self-hosting Discourse unless it allows us to replace another service, as Discourse is a complex piece of software that would take a lot of work to maintain (just like Mailman 3). There are currently no plans to self-host discourse inside TPA. There was at least one vote for removing schleuder. It seems people are having both problems using and managing it, but it's possible that finding new maintainers for the service could help. > * `pauli`: Puppet packages are severely out of date in Debian, and > Puppet 5 is EOL (with Puppet 6 soon to be). doesn't necessarily > block the upgrade, but we should deal with this problem sooner > than later, see [tpo/tpa/team#33588][], followup in > [tpo/tpa/team#40696][] Lavamind made a new puppet agent 7 package that should eventually land in Debian experimental. He will look into the Puppet server and Puppet DB packages with the Clojure team this weekend, has a good feeling that we should be able to use Puppet 7 in Debian bookworm. We need to decide what to do with the current server WRT bullseye. Options: 1. use upstream puppet 7 packages in bullseye, for bookworm move back to Debian packages 2. use our in-house Puppet 7 packages before upgrading to bookworm 3. stick with Puppet 5 for bullseye, upgrade the server to bookworm and puppet server 7 when we need to (say after the summer), follow puppet agent to 7 as we jump in the bookworm freeze Lavamind will see if it's possible to use Puppet agent 7 in bullseye, which would make it possible to upgrade only the server to bookworm and keep the fleet upgraded to bookworm progressively (option 3, above, favorite for now). > * `hetzner-hel1-01`: Nagios AKA Icinga 1 is end-of-life and needs to > be migrated to Icinga 2, which involves fixing our git hooks to > generate Icinga 2 configuration (unlikely), or rebuilding a Icinga > 2 server, or replacing with Prometheus (see > [tpo/tpa/team#29864][]), followup in [tpo/tpa/team#40695][] Anarcat proposed to not upgrade Icinga and instead replace it with Prometheus and Alert Manager. We had a debate here: on the one hand, lavamind believes that Alert manager doesn't have all the bells and whistles that Icinga 2 provides. Icinga2 has alert history, a nice and intuitive dashboard where you ack alerts and see everything, while alert manager is just a dispatcher and doesn't actually come with a UI. Anarcat, however, feels that upgrading to Icinga2 will be a lot of work. We'll need to hook up all the services in Puppet. This is already all done in Prometheus: the node exporter is deployed on all machines, and there are service specific exporters deployed for many services: apache, bind, postgresql (partially) are all monitored. Plus, service admins have widely adopted the second Prometheus server and are actually already using for alerting. We have a service duplication here, so we need to make a decision on which service we are going to retire: either Alert Manager or Icinga2. The discussion is to be continued. > [tpo/tpa/team#29864]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/29864 > [tpo/tpa/team#33588]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33588 > [tpo/tpa/team#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471 > [tpo/tpa/team#40693]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40693 > [tpo/tpa/team#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694 > [tpo/tpa/team#40695]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40695 > [tpo/tpa/team#40696]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40696 Other major upgrade tasks remaining, informative, to be done progressively in may: * upgrades, batch 2: tpo/tpa/team#40692 (probably done by this point?) * gnt-fsn upgrade: tpo/tpa/team#40689 (involves an upgrade to backports, then bullseye) * sunet site move: tpo/tpa/team#40684 (involves rebuilding 3 machines) # Dashboard review Skipped for lack of time. * https://gitlab.torproject.org/tpo/tpa/team/-/boards/117 * https://gitlab.torproject.org/groups/tpo/web/-/boards * https://gitlab.torproject.org/groups/tpo/tpa/-/boards # Holidays planning Skipped for lack of time, followup by email. # Other discussions We need to review the dashboards at the next checkin, possibly discuss the Icinga vs Prometheus proposal again. # Next meeting Next meeting should be on Monday June 6th. # Metrics of the month * hosts in Puppet: 93, LDAP: 93, Prometheus exporters: 154 * number of Apache servers monitored: 27, hits per second: 295 * number of self-hosted nameservers: 6, mail servers: 8 * pending upgrades: 0, reboots: 0 * average load: 0.64, memory available: 4.67 TiB/5.83 TiB, running processes: 718 * disk free/total: 34.14 TiB/88.48 TiB * bytes sent: 400.82 MB/s, received: 266.83 MB/s * planned bullseye upgrades completion date: 2022-12-05 * [GitLab tickets][]: 178 tickets including... * open: 0 * icebox: 153 * backlog: 10 * next: 4 * doing: 6 * needs information: 2 * needs review: 3 * (closed: 2732) [Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards Upgrade prediction graph lives at https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. # Number of the month 4 issues. We have somehow managed to bring the number of tickets in the icebox from 157 to 153, that's a 4 issues gain! It's the first time since we're tracking those numbers that we managed to get that number to go down *at all*, so this is really motivating. We also closed a whopping 53 tickets since the last report, not quite a record, but certainly on the high range. Also: we managed to bring back the estimated bullseye upgrades completion date back *two years*, into a more reasonable date. This year, even! We still hope to complete most upgrades by this summer, so hopefully that number will keep going down as we continue the upgrades. Another fun fact: we now have more Debian bullseye (54) than buster (39) machines. -- Antoine Beaupré torproject.org system administration

1 0

No UX team meeting today, May 10th
by nah＠riseup.net 10 May '22

10 May '22

Hello everyone, Most of the team is not available today, so we are going to cancel this meeting. See you all next week! Nah User Researcher The Tor Project

1 0

TPA-RFC-27: Python 2 end of life
by Antoine Beaupré 09 May '22

09 May '22

Summary: Python 2 is officially unsupported by TPA. Major breakage to unfixed code is expected after the Debian bullseye upgrade completes (May-July 2022), and definite breakage will occur when Python 2 support is completely dropped in Debian bookworm (some time in 2023). # Background [Python 2.7.18][] was released on April 20th 2020. It was the last Python 2 release that will ever happen, and Python 2 is now unsupported, end of life, [dead][]. [Python 2.7.18]: https://www.python.org/downloads/release/python-2718/ [dead]: https://www.enricozini.org/blog/2020/python/python-2-is-dead/ ## Status of Python 2 in Debian It was originally thought that the Debian 11 "bullseye" [release][] (on August 14th 2021) would not support Python 2 at all, but it was actually released with *some* Python 2 support. [release]: https://www.debian.org/News/2021/20210814 However, an analysis from anarcat about the [Python 2 modules shipped in bullseye][] shows that a large number of Python 2 modules were actually removed from Debian 11. Out of the 2699 "python 2" packages in Debian buster (packages starting with `python2?-`, excluding `-doc` and `-dbg`), 2616 were removed. Therefore, only 90 such packages remain in Debian bullseye, a 97% reduction. [Python 2 modules shipped in bullseye]: https://people.debian.org/~anarcat/python2-in-debian/ As a consequence, odds are that your Python 2 code will just stop working after the bullseye upgrade, if it uses one of the [modules missing from bullseye][]. Which, really, means if it uses anything outside the standard library that is not vendored with your code (e.g. in a "virtualenv"), because the odds of that module being one of the few 90 modules are pretty low. [modules missing from bullseye]: https://people.debian.org/~anarcat/python2-in-debian/python2-removed-bullse… The next Debian stable release (12, code name "bookworm") doesn't yet have a clear plan to remove Python 2, but it's likely to shrink the list of Python 2 modules even further. It is currently down to 79 packages. Bookworm also does not currently ship the magic [python-is-python2][] package, which ensures the existence of `/usr/bin/python`. This means any script with such a header will start breaking in Debian bookworm: #!/usr/bin/python [python-is-python2]: https://packages.debian.org/bullseye/python-is-python2 # Status of Python 2 in TPA We currently are in the middle of a the [Debian 11 bullseye upgrade][], so we have both Debian 10 and Debian 11 machines, which means we have actually Python 2.7.16 and 3.7.3 (buster) and Python 2.7.18 and 3.9.2 (bullseye) currently deployed. In any case, we have two "reasonable" versions of Python 2 (2.7+) and Python 3 (3.5+) available everywhere, it should be fairly easy to target Python 3 for ports, without having to concern ourselves with Python 2 support any longer. [Debian 11 bullseye upgrade]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5 We do not currently knowingly deploy any Python 2 module in the above list, although it's possible some packages are manually installed on some host. The TPA code base still has a lot of Python 2 code, particularly on the LDAP server, but there's a lot of Python 2 code floating around the infrastructure. We haven't performed an audit of the code and are fixing issues as they come up as part of the Python 2 upgrade procedure. Other services have not been examined. So far, most services actually run under Python 3, or have been found to be already ported and just needing a redeployment (see [tpo/network-health/metrics/exit-scanner#40004][] for an example). [tpo/network-health/metrics/exit-scanner#40004]: https://gitlab.torproject.org/tpo/network-health/metrics/exit-scanner/-/iss… # Proposal After the Debian 11 "bullseye" upgrade, TPA will *not* support Python 2 modules that were removed from Debian. Any program using such a module will need to be ported to Python 3, as the packages shipping those modules will be removed as part of the upgrade procedure. The `/usr/bin/python` binary will remain, for now, as the 2.7.18 executable. After the Debian 12 "bookworm" upgrade, Python 2 will be completely removed from servers. Any program using Python 2 will likely stop working completely as the `/usr/bin/python` command will be removed. The `/usr/bin/python` command *may* eventually be replaced by the Python 3 interpreter, but that will not be before the bookworm upgrade procedure begins, and only if the lack of a `python` binary is too problematic for users. ## Timeline Debian 11 bullseye upgrades should complete by July 1st 2022, but most upgrades should complete by the second week of May 2022, that is next week, starting on May 9th 2022 and continuing during the week. A grace period *may* be given to certain projects that cannot immediately port their code to Python 3, by keeping Python 2 modules from Debian buster installed, even after the bullseye upgrade. Those modules will *definitely* be removed by July 1st 2022, however. Debian 12 bookworm upgrades are currently scheduled to begin some time in 2023 and should be completed before July 2024. An actual schedule will be proposed in a future announcement. When this change will be deployed, Python 2 will be gone from TPA servers. ## Affected users This affects any service admin who deploys Python code on TPA infrastructure. # Alternatives considered We have considered just ignoring this problem, and in fact that was the approach with the [original Debian 11 bullseye upgrade proposal][]. Although it didn't state it explicitly, it didn't have any plan for the Python 2 upgrade. And indeed, the issue about the [Python end of life][] was postponed to the [Debian 12 bookworm upgrade milestone][], because it was believed Python 2 would just keep working in Debian 11. Unfortunately, the [second batch of upgrades][] showed the situation was much more severe than we expected, and required a more radical approach. [second batch of upgrades]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692 [Python end of life]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [original Debian 11 bullseye upgrade proposal]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-20-bullse… Another alternative to porting your code to Python 3 is actually to use the PyPy interpreter, which still supports Python 2 (and is actually still struggling with its Python 3 port). However, we strongly discourage this approach, and `pypy` is not currently installed on any TPA server. GitLab CI users may be able to ignore this issue by using containers that do ship Python 2. Note that we *may*, in the future, implement controls on the container images deployed from GitLab CI to avoid using old, unsupported software in this way, exactly for this kind of situation. But for now there are no such controls. We strongly discourage the use of outdated software, including containers, inside your tool chain, in general. # Costs Staff. There is no estimate on the volume of Python 2 code left to upgrade. A study of this should probably be performed at some point, but so far we have assumed this wasn't a problem, so we are dealing with this on a case-by-case basis. # Approval TPA. # Deadline This proposal will welcome comments until Tuesday May 10th, at which point it will be considered adopted and the Debian bullseye upgrades will resume. We acknowledge this is an extremely short deadline (~5 days), but we have actually planned those Debian bullseye upgrade for a while, and somehow expected there wouldn't be much Python 2 code lying around. We hope that the exception for Python 2 modules (until July 1st) will be sufficient mitigation for us to continue with the bullseye upgrades in a timely manner. # Status This proposal is currently in the `proposed` state. # References * [Discussions about this proposal][], comments welcome here! * [Debian 11 bullseye upgrade milestone][] * [Debian 12 bookworm upgrade milestone][] [Discussions about this proposal]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33949 [Debian 11 bullseye upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/5 [Debian 12 bookworm upgrade milestone]: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/6 -- Antoine Beaupré torproject.org system administration

1 1

Cecylia's Monthly Status Report, April 2022
by Cecylia Bocovich 06 May '22

06 May '22

Hi everyone, This is my status report for contract work in April 2022. 1. Onboarding itchyonion onto sponsor 28 deliverables: * RACE v2.1.0 was released in early April. We did a few pair programming sessions to walk through the update and release project for our Snowflake plugin deliverable for this sponsor. https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/56 * Discussed Snowflake patches necessary for integration with the RACE API in preparation for an update to the snowflake libraries used in the Snowflake plugin. * Was available to answer general questions about s28 workflow and scrimmage events. 2. Conjure pluggable transport for Tor * Continued work on getting a conjure station up and running in a development environment. This task has been complex and time consuming due to a lack of documented non-proprietary development workflows. I've experimented with virtual machine networks, but some of these experiments were dead ends due to the need for specific NIC drivers. Work on this continues... Thanks! Cecylia

1 0

Joydeep's Monthly Status Report for April 2022
by Joydeep Sen Gupta 06 May '22

06 May '22

Hello everyone! This is my monthly report for the month of April. With two Tor Browser releases in the past month (11.0.10 and 11.5a9), we received a few reports of two Tor Browser for Android bugs, namely, "Tor Browser crashing on launch" [1] and "Bug in rendering webpages" [2], I worked with the users to gather feedback for the bug reports and have been collaborating with the UX team to discuss the same during the weekly team meetings. Other frequently asked questions involved questions about setting up and using Snowflake [3], resisting censorship with Tor, random websites blocking Tor connections and about how to change the search engine from the default DuckDuckGo on Tor Browser. Last month, we saw a total of 23 unique requests for unlisted obfs4 bridges (mostly from China). These requests are generally accompanied with troubleshooting with the user. As part of my ongoing work with improving the moderation workflow on the Tor Forum, I have been looking for ways to improve the moderation queue [4] and efficient use of the 'tags' on the forum [5]. I made some progress in both of those tasks. Documenting some our workflow with the Request Tracker for user support, I authored a Community wiki article [6] on tips, best practices and efficient use of RT. That pretty much sums up the highlights from last month and following are some quick stats and highlights from our official support channels. ## Frontdesk Timeline : 01 Apr - 30 Apr 2022 Tickets: new: 13 open: 1 resolved: 383 Breakdown of number of RT tickets received with respect to operating system: (Note: This includes tickets where the user mentioned the operating system or it was evident from the issue they were running into and/or enclosed screenshots.) Windows - 15 macOS - 5 GNU/Linux - 5 Android- 15 Breakdown of most frequent tickets (at least 3 RT tickets): 1. 133 RT Tickets - How to use Tor Bridges in Russia. [7] 2. 23 RT Tickets - Private Bridge requests. This is not related to the .ru censorship but requests from Tor users in China, Iran, etc. [8] 3. 4 RT Tickets - How to circumvent geo-based restrictions with Tor? 4. 4 RT Tickets - Tor Browser Android 11.0.8 crashes on launch [1] 5. 3 RT Tickets - How to change the default SE and add a new search engine to Tor Browser? [9] 6. 3 RT Tickets - Bug in rendering webpages (on Tor Browser for Android on Samsung S22) [2] 7. 3 RT Tickets - Questions about the Snowflake proxy [3] ## Tor Forum Most popular topics in the Support category (in terms of no. of views): 1. "Bridge Blocklist RU". [10] 2. "Administrator (on windows) vs root (on GNU/Linux) and Tor Browser". [11] 3. "“Secure Connection Not Available” on https sites" [12] 4. "Is the (tor) RPM repository no longer maintained?" [13] 5. "(Setup a ) Tor node on live USB" [14] Thanks, -- Joydeep [1]: https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40212 [2]: https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40216 [3]: https://support.torproject.org/censorship/what-is-snowflake/ [4]: https://gitlab.torproject.org/tpo/community/support/-/issues/40060 [5]: https://gitlab.torproject.org/tpo/community/support/-/issues/40063 [6]: https://gitlab.torproject.org/tpo/community/team/-/wikis/Frontdesk:-Tips-fo… [7]: https://forum.torproject.net/t/tor-blocked-in-russia-how-to-circumvent-cens… [8]: https://support.torproject.org/censorship/connecting-from-china/ [9]: https://forum.torproject.net/t/custom-search-engine-in-tor-browser/2574 [10]: https://forum.torproject.net/t/bridge-blocklist-ru/2989 [11]: https://forum.torproject.net/t/administrator-vs-root-and-tor-browser/2954 [12]: https://forum.torproject.net/t/secure-connection-not-available-on-https-sit… [13]: https://forum.torproject.net/t/is-the-rpm-repository-no-longer-maintained/2… [14]: https://forum.torproject.net/t/tor-node-on-live-usb/2888

1 0

Community Team meeting notes - May 2nd 2022
by gus 06 May '22

06 May '22

Hi, Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-02-13.59.log… And our meeting pad: ## Tor Community Team meeting pad Next meeting: Monday, May 9, 2022 - 1400 UTC Weekly meetings, every Monday at 14:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) ## Goal of this meeting Weekly check-in about the status of Community Team work at Tor. ## Links to Useful documents * Previous meetings: https://forum.torproject.net/tag/community-team * Monthly l10n hangout: * https://community.torproject.org/localization/hangouts/ * Known issues with Tor Browser: * https://tb-manual.torproject.org/known-issues/ and Tor Browser for Android: https://tb-manual.torproject.org/mobile-tor/#known-issues ## Discussion - Relay operator sysadmin 101 workshop: - (draft) form: https://nc.torproject.net/apps/forms/cDLPxryHJcP5kMeW - invitation: - (gus) oniondao folks - (gman999) bsd folks + RPI students - OONI+Tor training in Latam with Derechos Digitales: - Maria will run an OONI workshop with DD - We will have a training day to talk about Tor & anticensorship - Gus will share the survey pad with Raya - Ticket: https://gitlab.torproject.org/tpo/community/training/-/issues/47 - Collecting Tor Browser alpha feedback from our support channels (RT and cdr.link): - Create a pad to collect user feedback from RT and cdr.link and track down TB alpha bugs - Create a template on RT to tag tickets - Add how to report a bug or give feedback in cdr.link text module (in Russian): https://gitlab.torproject.org/tpo/community/support/-/issues/40079 - Training page revamp discussion: https://gitlab.torproject.org/tpo/web/community/-/issues/265 ## Updates Joydeep: Last week: - 1:1 with Gus - Testing Tor Browser 11.5a9 wrt. https://gitlab.torproject.org/tpo/web/manual/-/issues/119 - Reviewed user trust levels on the forum with Gus (https://gitlab.torproject.org/tpo/community/support/-/issues/40078) - Investigating some issues on our Telegram support channel / cdr.link with Nina (https://gitlab.torproject.org/tpo/community/support/-/issues/40078) - user support work forum, RT, cdr.link - working with users to gather feedback on this fenix bug : https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40216 This week: - Testing Tor Browser alpha and prepare the documentation changes - S125 retrospective meeting Gus: Last week: - Worked on relay operator workshop form - Organized the Tor Latam meetup - S96 meeting - S9 meeting - Websites work: https://gitlab.torproject.org/tpo/web/support/-/merge_requests/108 - Meeting with Derechos Digitales - Alix Dunn course - Met opensearch community manager - team 1:1s - Got more private bridges for frontdesk/cdr.link This week: - S125 retrospective meeting - S30 meeting - Team 1:1s - Alix Dunn course - Network Health work with dgoulet and geko - Organize the East Africa Meetup (05/26 @ 1300 UTC) with raya - Promote the Relay Operator meetup (05/21 @ 1900 UTC) - Publish the Tor news (newsletter.torproject.org) rhatto: Last week: - S123 - Continue the Onionprobe testbed setup: https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/59 - S123 - Continue to work on new deployments - S123 - Created Onionmine: https://gitlab.torproject.org/tpo/onion-services/onionmine/ This week: - S123 - Continue the Onionprobe testbed setup: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/merge_request… - S123 - Work on new deployments - 1:1 with Gus Nina: Last week: - Tor users' support on cdr.link (Telegram) and RT (email). - 1:1 with Gus - Checked Telegram support channel issues This week: - User support. - Final meeting s125 - alpha-version testing raya: Last week: - Met with s123 stakeholders, discussed infrastructure requirements for s123 landing pages - April narrative report for s123: https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/75 - Some touch-ups on training page proposal: - https://gitlab.torproject.org/tpo/web/community/-/issues/265 - Started presentation on onion services for general audience (will help with s123, conference proposal, and general use within community work) - 1:1 with Gus - Gathered a list of entities who could be interested in a Tor Global South meetup This week: - Finalize s123 narrative report and send to grants - First draft of onion services presentation complete Help with: - Something you need help with. emmapeel: Last week: - support sponsors 123 and 125 - translation maintenance, updates, translators feedback This week: - support sponsors 123 and 125 - translation documentation - training page revamp Help with: - https://gitlab.torproject.org/tpo/web/tpo/-/issues/290 to publish Khmer translation -- The Tor Project Community Team Lead

1 0

Rhatto's Monthly Status Report, April 2022
by rhatto 05 May '22

05 May '22

Hi all :) This is my monthly status report for April 2022. Main activities during the period: 0. Onionprobe (an onion sites monitoring tool): * Uploaded to PyPI! https://pypi.org/project/onionprobe/ * Released Onionprobe version 0.3.0: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/blob/main/Cha… https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/tags/0.3.0 * Added Debian packaging support! https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/4 * Adapted for an instance monitoring the health of The Tor Project's onion sites: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40717 2. Onionmine: created this small set of scripts to help automating the generation of Onion Service vanity keys: https://gitlab.torproject.org/tpo/onion-services/onionmine/ 3. Many other activities related to Sponsor 123 such as meetings, development and support :) -- Silvio Rhatto pronouns he/him

1 0

Anti-censorship team meeting notes, 2022-05-05
by meskio 05 May '22

05 May '22

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-05-15.58.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday May 12th 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at Tor. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from sponsors we are working on: * All needs review tickets: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Sponsor 28 * must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10 * possible tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&… * Sponsor 96 * https://gitlab.torproject.org/groups/tpo/-/milestones/24 == Announcements == * the bridges telegram bot is now in rdsys == Discussion == * Distributed Snowflake Server Support * there is a merge request now: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * review is wellcome, there are mayor changes * RKS hackathon * RKS is organizing a hackathon: demhack.ru and asked TPO to be part of it * we are proposing whatsapp gettor+bridgesbot * they think it might be to small, we can extend it * another idea is to do it in iMessage * we'll discuss it in a ticket * due to monday == Actions == * == Interesting links == * == Reading group == * We will discuss "Understanding the Impact of Encrypted DNS on Internet Censorship, ACM WWW 2021" on May 19th, 2022 * https://shhaos.github.io/papers/www21-DoE.pdf * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. anadahz: 2022-01-27 Last week: - Increase timeout check cycles for default-bridge-felix-1 and default-bridge-felix-2 as they have been generating too many alerts: https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/mer… cecylia (cohosh): last updated 2022-04-14 Last week: - moved tor-specific snowflake code out of client library (snowflake#40124) - merge request: snowflake!85 - bump version of webrtc dependency (snowflake#40127) - merge request: snowflake!86 - commented on snowflake web workflow (snowflake#40125) - opened issue to bump version of snowflake and webrtc in tor browser (tor-browser-build#40474) - work on conjure test environment setup This week: - continue work on conjure PT - continue snowflake maintenance tasks Needs help with: dcf: 2022-05-01 (will be absent 2022-05-05) Last week: - opened an issue for confusing client NAT check log messages https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - filed an OONI issue to get access to stunreachability measurements, in order to get more insignt into torsf (snowflake) failures https://github.com/ooni/backend/issues/590 Next week: - look at STATUS VERSION proposal https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63 - set up access control on the snowflake-02 bridge https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: arlolra: 2022-04-07 Last week: - Merged the rest of snowflake !81 Next week: - Get to snowflake-webext #10 Evergreen: - Figure out where in pion/webrtc ALPN should be configured and used - Maybe add Chacha20Poly1305 to pion/dtls https://github.com/pion/dtls#planned-features https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: - maxb: 2021-09-23 Last week: - Worked on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… re: utls for broker negotiation - Had conversation with someone about upstream utls http round tripper https://github.com/refraction-networking/utls/pull/74 - Too busy with work :/ Next week: - _Really_ want to get a PR for utls round tripper meskio: 2022-05-05 Last week: - deploy telegram in rdsys (rdsys#111) - advance on the onionsproutsbot deployment (team#78) - add onionsproutsbot to transifex (l10n#40070) - add the location to circumvention settings (rdsys#108) - API for dynamic bridges in telegram (rdsys#98) - review bridedb.tpo/info fixes (bridgedb!39) Next week: - bridges sharing the same IP should use the same distributor (rdsys#106) - finish and deploy the changes into circumvention settings API (rdsys#108) Shelikhoo: 2022-05-05 Last Week: >>> - [Merge Request] Add Distributed Snowflake Server Support (snowflake!87) <<< - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Merge Request Review] Telegram distributor hands both new and old bridges to old accounts(snowflake!37) - [Merge Request Review] Don't mix up old and new telegram accounts(snowflake!38) - [Merge Request Review] Remove smallerRichard default bridge - [Research & Coding] WebSocket + CDN Based Probe Control Connection Forwarder (shelikhoo/LogCollectorAncillary#3) - [Coding & Deployment] Include frontdisk testing targets in probe tests (shelikhoo/LogCollectorAncillary#4) - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Discussion] Opening 8443 port on probetelemetry-01@ for V2Ray Websocket Connection Inbound Next Week: - [Coding] Distributed Snowflake Bridges (continue) - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Research] Implement metrics to measure snowflake churn(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transport… Itchy Onion: 2022-05-05 Last week: - go over snowflake code (in preparation for the next Georgetown meeting and also help with snowflake rebasing) This week: - prepare Georgetown meeting (read more docs and code) - starting to look at new RACE version (2.1.1) HackerNCoder: 2021-12-16 This week: Last/done: Setup web mirror on tor.encryptionin.space Next: Get (new VPs with) new IP and setup new web mirror on new domain -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Nina's Monthly Status Report, April 2022
by nina13＠riseup.net 05 May '22

05 May '22

Hi, that's my monthly report for April 2022 Summary: Telegram tickets answered and solved - 554 Tickets received by email (frontdesk) answered and solved - 189 Total: 743 This month I took part in the Samsung S22 bug investigation[1] and spotted some issues with cdr.link[2]. Fortunately, minor ones. In April, we managed to get some feedback on censorship in Turkmenistan[3] and test some ways to circumvent it. Private bridges worked best. This month @ggus, @championquizzer, and I had a Ticket triage and backlog session for frontdesk tickets. I put some effort into educating as many users as possible about our bot https://t.me/@getbridgesbot so that they could get bridges anytime and immediately. That makes their experience using Tor Browser better and gives us more space to communicate with alpha-testers. [1] https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40216 [2] https://gitlab.torproject.org/tpo/community/support/-/issues/40078 [3] https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… and https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project