September 2023 - tor-project - lists.torproject.org

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

12 May '25

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

4 3

Retirement of Gitolite and GitWeb started, please migrate by end of year
by Antoine Beaupré 27 Mar '24

27 Mar '24

Hi, Gitolite (`git.torproject.org` and `git-rw.torproject.org`) and GitWeb (<https://gitweb.torproject.org>) will be fully retired within 9 to 12 months (by the end of Q2 2024). TPA will implement redirections on the web interfaces to maintain limited backwards compatibility for the old URLs. Start migrating your repositories now by following the [migration procedure][], and please complete the migration by the end of year 2023. See the full discussion in [TPA-RFC-36][]. [migration procedure]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git#how-to-migrate… [TPA-RFC-36]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitoli… A. -- Antoine Beaupré torproject.org system administration

1 2

Online Tor's Hackweek from Nov 6th to Nov 10th 2023
by rhatto 12 Oct '23

12 Oct '23

Hi! The Tor Project and Tor community is going to be gathering online from November 6th to November 9th this year for a 4 days hackweek. ## About This is a call for projects for whoever wants to participate, put together a team and hack through one working week with us. In the context of this hackweek, a project is anything related to Tor documentation that you can work with other people in 4 days. It could be improving the documentation for a project, a tutorial or could also be a cartoon, a screencast or anything that do not necessary requires coding skills. You will work on this project during 4 days with other people in your team. This is an opportunity to discuss how documentation is working or not in your projects, as well as thinking, proposing, researching and testing solutions. Documentation is very important for any free software project as it is the way for people to start understanding the work we are doing, the way they can use our tools and start contributing with it. In the next All-Hands following the Hackweek we are going to have a demo in a Big Blue Button's room where your team will present the work you did through the hackweek. ## Timeline This will be the timeline for the hackweek this year: * Until Monday, November 6th: * Send hackweek project proposals to this issue queue: https://gitlab.torproject.org/tpo/community/hackweek/-/issues (please use the "Proposal" issue template for the ticket Description). * Before hackweek begins, start looking for other people to join your team. * In order to join a proposal you liked, subscribe yourself to it's ticket. * Wednesday, November 1st - 16:00 UTC: All-Hands session prior to the Hackweek were people/teams will present their project proposals for other people to join their team if they want to. * Monday, November 6th: Hackweek begins. People start working on whatever they want related to documentation. By this time, you should have a few members of your team already identified. Hack hack hack hack... in whatever way you organize yourself. We will have the room #tor in irc.oftc.net to discuss general hackweek things. * Thursday, November 9th: Hackweek ends. * Wednesday, November 15th - 16:00 UTC: Each team presents the work they did in the All-Hands session happening after the Hackweek. ## Projects The updated list of projects will be available at https://gitlab.torproject.org/tpo/community/hackweek/-/issues. Each project can have one pad (you can use https://pad.riseup.net) and also use it's ticket to add all information that people need to add themselves to that project. ## References For best practices on documentation, we recommend the following material: * Diátaxis, "The Grand Unified Theory of Documentation": https://diataxis.fr/ * How to pick up a project with an audit: https://bluesock.org/~willkg/blog/dev/auditing_projects.html cheers, -- Silvio Rhatto pronouns he/him

2 1

shadow update 2023-09-27
by Jim Newsome 30 Sep '23

30 Sep '23

Mirrored from <https://github.com/shadow/shadow/discussions/3187>: This is part of a series of periodic updates of development in Shadow. This work is sponsored by the [NSF](https://shadow.github.io/docs/guide/nsf_sponsorship.html). Previous update: [2023-06](https://github.com/shadow/shadow/discussions/3061). We've merged [74 non-dependabot pull requests](https://github.com/shadow/shadow/pulls?q=is%3Apr+merged%3A2023-06… and closed [8 issues](https://github.com/shadow/shadow/issues?q=closed%3A2023-06-30..2023… since our previous update. # Latest improvements ## Spawning processes Shadow now supports running programs that spawn additional processes. Technically, this means it now supports `fork`, `vfork`, `execve`, and other related syscalls. Some uses for this: * The primary way for `tor` to work with [pluggable transports](https://blog.torproject.org/tor-heart-bridges-and-pluggable-tra… is for the `tor` process to dynamically spawn the pluggable transport process. This is currently the *only* way that pluggable transports are supported in `arti`. This now works in `shadow`. * Orchestration of multiple processes on a single host in `shadow` can now be done using e.g. `sh` or `python` scripts, instead of having to specify every process directly in `shadow`'s configuration file. * `shadow` can now run other software that spawns worker or helper processes. Another exciting application for this in `shadow` *development* is that we can now more easily run third party test suites, which typically spawn multiple test processes. For example, running `tor`'s own self-tests helps validate that `shadow` is correctly emulating the platform functionality that `tor` uses; currently [more than 99% of the tests pass](https://github.com/shadow/shadow/issues/3168)! ## New TCP stack Shadow's experimental new TCP stack is merged, and can be enabled with the experimental command-line flag `--use-new-tcp`. This new implementation is in Rust instead of C, and is developed to be very testable (e.g. in its own crate decoupled from the rest of Shadow, and with pluggable system dependencies). While some functionality is still being finished, we expect it will be much easier to maintain and to validate its correctness than the previous C implementation. Improved support for pcap file output also makes it easier to review Shadow's simulated network traffic. ## Shim stability We've occasionally run into problems due to `shadow`'s preloaded shim calling into `libc`. This is unsafe because some initialization can run before `libc` itself is fully initialized, and much of the code runs in a seccomp signal handler, running afoul of [async-signal-safety](https://man7.org/linux/man-pages/man7/signal-safety.7.…. Luckily, Rust has a rich ecosystem of code that doesn't depend on libc (`no_std` code). We've made substantial progress in migrating the shim's C code to `no_std` Rust code. ## Socket API improvements Our UDP socket implementation has been migrated from C to Rust, and along the way we've made many improvements to the socket API for UDP, TCP, and Unix sockets. We've added support for the following: * `sendmsg`, `recvmsg`, and `shutdown` syscall support for UDP sockets * `MSG_TRUNC` support for UDP and Unix sockets * `MSG_PEEK` support for UDP sockets * `SO_DOMAIN`, `SO_PROTOCOL`, and `SO_ACCEPTCONN` socket options for TCP and UDP sockets * `SIOCGSTAMP` ioctl support for TCP and UDP sockets We've also made various fixes and improvements to existing socket functionality so that Shadow more accurately follows the behaviour of Linux. ## C to Rust migration We continue to progress our migration from C to Rust. In addition to Rust progress in the shim and in the new TCP stack, other notable migrations since the last update include the shared memory allocator, epoll and timerfd descriptors and syscalls, UDP sockets, and several time-related syscalls. Our current status is 74% Rust code and 21.4% C code (much of this being C tests) according to Github statistics. # Release status We expect to release Shadow 3.1.0 some time in the next few weeks. # Project status - NSF grant is wrapping up The last three years of development on Shadow have been sponsored by an [NSF](https://shadow.github.io/docs/guide/nsf_sponsorship.html) grant. That grant ends at the end of this month (September 2023). This isn't the end of development on Shadow — Rob Jansen (@robgjansen) at the U.S. Naval Research Laboratory continues to head the project. Over the course of this project, The Tor Project has incorporated Shadow into its own research and testing workflows, and is likely to continue contributing as well. We look forward to continue improving and maintaining Shadow, but at a slower pace of development since we no longer expect contributions from programmers singularly dedicated to Shadow development. Jim Newsome (@sporksmith) is continuing to be a Tor Project employee but shifting focus to other Tor projects; Steven Engler (@stevenengler) is open to opportunities. Happy simulating! The Shadow team

1 0

Anti-censorship team meeting notes, 2023-09-28
by onyinyang 29 Sep '23

29 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-28-15.57.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, Oct 05 16:00 UTC Facilitator: meskio Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: onyinyang == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 150 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == == Discussion == - Update on snowflake domain fronting issues: - problem with cdn.sstatic.net affected more than just snowflake, also moat, conjure (no deployment change required) - fixed in new tor browser update but some users relying on snowflake/moat bridges will be unable to update - relying on a the same new front may be detrimental to improve connection issues for some users, perhaps a pool of randomly selected domains would improve the situation: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… == Actions == == Interesting links == == Reading group == * We will discuss "" on * * 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. cecylia (cohosh): 2023-09-28 Last week: - rdsys merge request !157 - wrote a feature for snowflake that allows multiple domain fronts - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - wrote a forum post for the domain fronting issue with moat - https://forum.torproject.org/t/temporary-fix-for-moat-and-connection-assist… - looked into orbot use of circumvention settings api - https://github.com/guardianproject/orbot/issues/983 This week: - finish deploying lox distributor - follow up on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-21 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - noticed a problem with the fastly domain front and coordinated with cohosh to analyze it https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Before EOY 2023: - move snowflake-02 to new VM Help with: meskio: 2023-09-21 Last week: - make fake descriptors for rdsys (rdsys#171) - document rdsys development process (rdsys#131) - use the right content-type in moat (rdsys#175) - add token authentication to onbasca requests (rdsys#174) Next week: - add a DB for bridges to rdsys (rdsys#56) Shelikhoo: 2023-09-28 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - Write Tor Spec for Armored URL - Remove Go 1.20 CI for Snowflake: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Consolidated Snowflake Update dependencies:https://gitlab.torproject.org/tpo/anti-censorship/pluggable-tr… - Merge request reviews Next Week/TODO: - Write Tor Spec for Armored URL(continue) - Merge request reviews onyinyang: 2023-09-28 Last week(s): - Still need to merge the updated dependencies and make MR to upstream ZK lib: - found bug in the zkp crate and will push a change to this to the upstream branch - reach out to dalek-cryptography maintainers to give them a heads up and get a sense of the plan for zkp lib - we may end up maintaining the zkp lib - Finished changes to rdsys API at the /resources endpoint to meet the needs of Lox - Working on required changes to lox-distributor This week: - Hopefully,finish up with the dependencies issue - Finish up changes to Lox distributor - continue with metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Anti-censorship team meeting notes, 2023-09-21
by Shelikhoo 22 Sep '23

22 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-21-15.57.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, Sep 28 16:00 UTC Facilitator: onyinyang Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: Shelikhoo == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 150 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == == Discussion == * deprecation of CAPTCHA moat * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/173 * captchas seem to be easy for censors to solve, and hard for some users to solve * prefer the circumvention settings API instead, it's not great but it seems to work better (distributes different subsets of bridges each day, you cannot enumerate them all in one day) * meskio has been ontifying downstream users about the planned deprecation * ggus: since we are planning to turn this off, before we do, could we experiment with different/harder captchas and see if bridges continue being blocked. (The hypothesis being that the captcha API is the primary way that they discover bridges.) * A proposal to phase out captchas in bridgedb from 2021: https://lists.torproject.org/pipermail/tor-dev/2021-July/014602.html * Replies suggested doing an experiment with captcha removal for 50% of bridges, that way they don't all get burned if it doesn't work * https://lists.torproject.org/pipermail/tor-dev/2021-July/014603.html * https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html * agreement on removing the in-house captcha * meskio will create an issue to explore captcha experiments * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176 * snowflake domain front resolving to a mix of fastly and cloudflare since 2023-09-20 * https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… * https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42120 * options for remediation: * change the domain front to one that still always resolves to fastly * not a lot of good options, also we don't have good knowledge of which are already censored https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * locally pin the IP address of the front domain we are using now * or resolve a different (fastly) name, but keep using the same front that we use now * creates an inconsistency between DNS and TLS * we can change the front domain for circumvention settings users, which does not require waiting for a TB/orbot/etc. release * change the domain to foursquare.com * guardian project / orbot? meskio says orbot is already using circumvention settings. But circumvention settings might be ignored for built-in bridges. * dcf will make a forum post and contact guardian project * community team will try to get testing of fourquare.com in the next week * meskio will make the change in Tor Browser and circumvention settings * Remove Go 1.20 support? kcp library seems to crash compiler: * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * # github.com/xtaci/kcp-go/v5 * /go/pkg/mod/github.com/xtaci/kcp-go/v5@v5.6.3/timedsched.go:19:6: internal compiler error: panic: interface conversion: interface is nil, not ir.Node * Please file a bug report including a short program that triggers the error. * https://go.dev/issue/new * note: module requires Go 1.21 * https://github.com/xtaci/kcp-go/blob/v5.6.3/timedsched.go#L19 * Go compiler issue: https://github.com/golang/go/issues/61074 * Has to do with new compiler builtin "clear" in go1.21 https://tip.golang.org/doc/go1.21#language * ...which kcp-go started using 10 days ago https://github.com/xtaci/kcp-go/commit/691fc2febef3dd927dca7815b207fb4dad19… * shelikhoo will go ahead and remove go1.20 support == Actions == == Interesting links == * https://www.bamsoftware.com/papers/fep-flaws/#sec:obfs4 * writeup of Elligator distinguishers that have affected obfs4proxy == Reading group == * We will discuss "" on * * 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. cecylia (cohosh): 2023-09-21 Last week: - dealt with dependency updates for snowflake and lox - discussed rdsys resource endpoints - opened an issue to create a lox user on rdsys-frontend-01 - https://gitlab.torproject.org/tpo/tpa/team/-/issues/41330 - wrote some next steps for conjure work - https://gitlab.torproject.org/tpo/operations/proposals/-/issues/51 This week: - finish deploying lox distributor - follow up on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-21 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - noticed a problem with the fastly domain front and coordinated with cohosh to analyze it https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Before EOY 2023: - move snowflake-02 to new VM Help with: meskio: 2023-09-21 Last week: - make fake descriptors for rdsys (rdsys#171) - document rdsys development process (rdsys#131) - use the right content-type in moat (rdsys#175) - add token authentication to onbasca requests (rdsys#174) Next week: - add a DB for bridges to rdsys (rdsys#56) Shelikhoo: 2023-09-21 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) (Done pass the client IP to tor for country usage stadistics, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) - Release new version of snowflake(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-trans… - Update CI targets to test Android from Golang 1.21 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Merge request reviews Next Week/TODO: - Write Tor Spec for Armored URL - Merge request reviews onyinyang: 2023-09-21 Last week(s): - Continued updating dependencies, including: - found issues with zkp library and am working on determining how to best handle those going forward, fixes are required to keep other dalek-cryptography libraries up to date: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/51 - additionally, there is a bug in the zkp crate that is noted in the blockage migration protocol so we might try to fix it: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/blob/main/crates… - Attempted changes to rdsys API at the /resources endpoint to meet the needs of Lox - Started on adding metrics This week: - Hopefully sort out the dependencies issue - Finish up changes to the API - continue with metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less?

1 0

Job Opportunity - Project Manager
by Erin Wyatt 19 Sep '23

19 Sep '23

Hi everyone! We have a new job opening for a Project Manager! https://www.torproject.org/about/jobs/project-manager/ <https://www.torproject.org/about/jobs/project-manager/> If you are or know someone who would be a good fit and wants to join our team, please apply/share. Have a great week and thanks for helping us spread the word! :) Cheers, 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/>

1 0

Anti-censorship team meeting notes, 2023-09-14
by onyinyang 15 Sep '23

15 Sep '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-14-15.58.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Sep 21 16:00 UTC Facilitator: Shelikhoo Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: onyinyang == 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 the Tor Project and Tor community. == 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 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == == Discussion == == Actions == == Interesting links == * == Reading group == * We will discuss "" on * * 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. cecylia (cohosh): 2023-09-14 Last week: - posted shadow + PT guide on the forum - https://forum.torproject.org/t/experimenting-with-tor-pluggable-transports-… - followed up on a report that snowflake is being blocked in russia - https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… - https://ntc.party/t/ooni-shows-blocking-on-snowflake-in-select-isps-in-russ… - opened issue with OONI for adding probe-engine version filter to MAT - https://github.com/ooni/probe/issues/2533 - filed an upstream issue with conjure on not relying on the replace directive - https://github.com/refraction-networking/conjure/issues/226 - updated gotapdance library version in Conjure PT to fix a stall issue - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - worked on deploying lox distributor - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/167 This week: - finish deploying lox distributor - map out next steps for conjure work - followup on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-09-13 Last week: - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… Next week: - revise encapsulation.ReadData redesign to return an error in the case of a short buffer https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2023-09-07 Last week: - vacation :) - coordinate with TPA to get a VM for a rdsys staging server - review lyrebird merge requests Next week: - deploy the rdsys staging server Shelikhoo: 2023-09-07 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - logcollector alert system - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) - Merge request reviews Next Week/TODO: - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) (Continue) - Release new version of snowflake - Merge request reviews onyinyang: 2023-09-14 Last week(s): - Continued updating dependencies, including: - aes-gcm: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/35 - base64: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/36 - found issues with zkp library and am working on determining how to best handle those going forward, fixes are required to keep other dalek-cryptography libraries up to date: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/51 - Started on adding metrics This week: - Update rdsys API at the /resources endpoint to meet the needs of Lox - Continue with adding metrics (long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by pt, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Tor at the Global Gathering Feira
by isabela fernandes 14 Sep '23

14 Sep '23

Hello community! Many Tor people will be at the Feira, we are looking forward to hanging out with y'all soon! We will be hosting conversation circles at our Onion table :) right in front of our booth. Here is the schedule: Friday Sept 15: - 14:00-15:00 -> *How to contribute to the Tor project* -> Our welcoming circle! Come meet Tor people and learn more about the project and how you can contribute to it. - 17:00-18:00 -> *Shaping the Tor advocates program* -> We are starting to organize a “Tor advocates program” and we want to host a circle for people who train others on Tor to learn about this idea and give us feedback on it. Saturday Sept 16: - 15:30-16:30 -> *Sharing between anti-censorship tools builders* -> We would like to invite other people working on building anti-censorship tools for a circle to share and build collaboration. - 17:00-18:00 ->* Experience of censored users* -> Members of our Anti-Censorship team will be hosting a circle for users to come and share their experience using our circumvention tools so we can learn what is working and how to improve what is not working. Sunday Sep 17: - 14:00-15:00 ->* Sharing lesson on usability research / user needs* -> We made big changes at Tor to have the user as the center of everything we do. In 2017 we started to implement usability research as the key director for our decisions on development and organization strategy. We would like to share about what we learned during this process and how it has been beneficial to us. - 17:00-18:00 -> *NoScript conversation* -> NoScript is a critical piece of privacy online that every user interacts with. At this circle the creator of NoScript will be sharing information about the project’s status and future plans. We would like to invite you to join the conversation to share your feedback or ask questions about NoScript and its integration in the Tor Browser. Looking forward to seeing you! cheers, isabela

1 0

Canceling the Network Team Monday meetings on IRC
by Alexander Færøy 11 Sep '23

11 Sep '23

Hello list! After the end of Sponsor 61, the Network Team Monday meetings on IRC returned to being a simple checklist meeting that is done in roughly 10 to 15 min. in average with zero external participants. I can do the checklist items directly with people over IRC without forcing a context switch for everybody by getting them into a meeting every week. The team have for a long time wanted to cut down on meetings and the BBB format where we have focused working groups works much better after the team started having multiple projects going on in parallel instead of "just" maintaining C Tor. The team continues to be readily available both via GitLab, the tor-dev@ mailing list, and via #tor-dev on IRC. All the best, Alex -- Alexander Færøy

1 0