- tor-project - lists.torproject.org

Nina's Monthly Status Report, February 2022
by nina13＠riseup.net 04 Mar '22

04 Mar '22

Hello everyone! This is my monthly status report for February, 2022. In February, I focused on testing support approaches via cdr.link on Telegram. Starting the Telegram support at the end of January 2022, we used the articles from the RT to create template answers in cdr.link. As I have immersed myself in the specifics of the work via messenger, I realized that this type of support needs another approach, and shorter templates would work better. Thus, I rewrote these templates based on platform and commons issues and added a new one on how to download Tor Browser, as Russian users often ask about it. I also added a new template article to deal with requests about onion services. I also added a similar article to RT, in Russian. For a month, I have collected experiences of support via cdr.link channel. The summary can be seen here: https://gitlab.torproject.org/tpo/community/support/-/issues/40059 This month, since censorship became harder, we started to get more requests on troubleshooting, as users want to be sure that Tor Browser works. Overall, I solved around 1670 tickets in February: Telegram (Cdr.link) - 953 RT (frontdesk) - 717 Translation I made some Russian to English and English to Russian translations for social media: https://twitter.com/torproject/status/1497241683100061704 https://twitter.com/torproject/status/1493332229346365447 Thanks, Nina

1 0

Roger's Q2 plans
by Roger Dingledine 03 Mar '22

03 Mar '22

Hi folks, I've been stretched too thin lately, and am risking further burnout by trying to continue doing too many things. So in an effort to keep myself more sustainable, I'm scaling back and focusing on a smaller set of activities. My original hope was to spend some real time thinking about reputation-based ("Salmon"-like) bridge distribution strategies, first because it is a good self-contained topic and second because we have funding for it and nobody is scheduled to work on it. But funder relationship tasks keep coming up, so my best remaining plan is to try to balance the "funder presentation" interrupts with the "get some uninterrupted time to think about Salmon" goal. I've written my priorities, framed loosely as OKRs but I admit it's more like a roadmap, on a new wiki page: https://gitlab.torproject.org/tpo/team/-/wikis/arma with the goal that it will be easier for other people to follow along with what I'm up to. For this round I am also using this list of priorities as a way to constrain my scope: I plan to drop things that aren't on this list. That is, I'm moving from "best effort, try to do all the things but actually do too many of them poorly" to "by default, do not do things that aren't on this list." My immediate next steps are to make gitlab tickets for the upcoming tasks, so my gitlab board will better reflect reality. I am going to spend the rest of this week continuing to do too many things, and this weekend I will switch gears to start the new plan. So if there is something you still need from me, it's best to remind me about it this week. Thank you for your understanding as I attempt this new experiment with trying to get back to being productive while also staying sane. :) --Roger

1 0

Anti-censorship team meeting notes, 2022-03-03
by meskio 03 Mar '22

03 Mar '22

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-03-03-15.59.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday March 10th 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 checkin 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 30 https://gitlab.torproject.org/groups/tpo/-/milestones/4 https://gitlab.torproject.org/groups/tpo/-/milestones/7 https://gitlab.torproject.org/groups/tpo/-/milestones/5 https://gitlab.torproject.org/groups/tpo/-/milestones/6 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&… == Announcements == Centralized Probe Result Collector on trial deployment Russia, Turkey, Beijing probetests are integrated BridgeDB is now using rdsys == Discussion == obfs4 fail to connect issue https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 we are coordinating with builtin bridges to update, many has already updated there is now a docker image with the new version the obfs4proxy 0.0.13 package will land in debian backports soon snowflake load and bottlenecks do we need more proxies? next steps for bridge capacity probetest is at is capacity could standalone proxies (which can make direct TCP connections) bypass snowflake-server and connect directly to the tor ExtORPort no, snowflake-server holds the turbo tunnel state we want to move into a design where there are multiple snowflake-servers and multiple bridges idea: partition snowflake-servers and bridges into non-overlapping "pools" i.e., snowflake-server A forwards to a set of bridges, snowflake-server B forwards to *its* set of bridges, and they share no bridges in common (which is a generalization of the current case, where there is 1 snowflake-server and 1 bridge) (there could be distinct brokers for different pools, but that is orthogonal) partitioning the set of bridges has this effect: when a broker/proxy wants to connect a client's traffic to a snowflake-server, for a specific bridge there is *one and only one* snowflake-server that is associated with that bridge therefore multiple connections in the same session, which use the same bridge, will also use the same snowflake-server, and therefore not lose turbo tunnel state it can work like this: the client torrc specifies the desired bridge fingerprint in its bridge line as a SOCKS param (redundantly with the fingerprint that is already there as part of the syntax) e.g. `Bridge snowflake 1111222233334444aaaabbbbccccdddd 192.0.2.3:1 url=https://snowflake.torproject.net/ front=front.example.com ice=... fingerprint=1111222233334444aaaabbbbccccdddd` the client sends the desired bridge fingerprint along with its offer to the broker the broker has a mapping of bridge fingerprints to snowflake-server WebSocket URLs. when the broker matches the client with a proxy, the broker informs the proxy of the WebSocket URL to connect to (i.e., which snowflake-server to connect to). it will always be the same snowflake-server URL for the same bridge fingerprint, because the mapping is consistent. the proxy connects to the WebSocket URL provided by the broker, and it includes the bridge fingerprint in the URL query string when it makes the connection (the same way the client IP address is communicated: e.g. `?client_ip=1.2.3.4:5678&fingerprint=1111222233334444aaaabbbbccccdddd`) the snowflake-server has its own mapping of bridge fingerprint to ExtORPort addresses. if it's an existing turbo tunnel session, it just resumes the ExtORPort TCP it already has. if it's a new session, it connects to the ExtORPort address corresponding to the bridge fingerprint. such a design alleviates the state-sharing concerns with multiple snowflake-servers. as long as a client uses a consistent bridge fingerprint during a session (which it will), it will get mapped to the same snowflake-server. arlolra is planning to write a patch for including the bridge fingerprint as a bridge line SOCKS param, and passing it to the broker, which is a necessary step for any of this then there can be multiple snowflake bridge lines in torrc, each with different bridge fingerprints. load balancing will come from the tor client's local random selection. there is a "thundering herd" concern with the way tor currently uses multiple bridge lines. tor will attempt to connect to all of them at once, and keep using only one of them. This means N broker transactions and N STUN exchanges, and possibly N-1 proxies held idle. maybe it's not such a big problem, if N is not too large an alternative would be a modification to tor where it shuffles its bridge list, and tries only one at a time another alternative is to write the torrc file dynamically: choose a random bridge line, then write torrc containing only that one randomly selected bridge line https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… need to consider backward compatibility: a client that doesn't communicate its desired fingerprint gets mapped to the existing == Actions == == Interesting links == https://archive.org/details/ptim2021 Pluggable Transports Implementers Meeting 2021 videos == Reading group == We will discuss "Throttling Twitter: an emerging censorship technique in Russia" on 10 March https://dl.acm.org/doi/pdf/10.1145/3487552.3487858 https://censorbib.nymity.ch/#Xue2021a 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-03-03 Last week: - updated version of snowflake in Tor Browser to include logged events - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… - started work on conjure PT for Tor (conjure#1) - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - reviewed and merged some small snowflake MRs - snowflake!79 - snowflake!80 - checked out shadow fixes for go programs - https://github.com/shadow/shadow/issues/1549 - helped monitor snowflake broker stats - https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0… - commented on adding more snowflake bridges (snowflake#28651) This week: - continued work on conjure PT - continue to monitor snowflake broker stats Needs help with: dcf: 2022-03-03 Last week: - posted summary of snowflake bridge outage on 2022-02-18 https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0… - tried porting extor-static-cookie to rust https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0… - tried the bridgedb+rdsys setup https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0… - inquired with OTF about funding for the snowflake bridge - posted about hardware limitations at the snowflake bridge https://lists.torproject.org/pipermail/tor-project/2022-March/003301.html - posted notes on using STATUS for PT version reporting https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2781418 - commented on space changes for STATUS VERSION https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63 Next week: Help with: agix: 2021-02-10 Last week: - Continued work on gettor-twitter Next week: - Hopefully finish the task Help with: - arlolra: 2022-03-03 Last week: - Next week: - 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… - Pass bridge fingerprint in SOCKS param to the broker 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-03-03 Last week: - deploy rdsys + bridgedb in production (rdsys#12) - update docker obfs4-bridge image with the new obfs4proxy (docker-obfs4-bridge#12) - coordinate with TPA to clean up the old email setup in BridgeDB - coordinate with metrics so the new assignments file - work on an update of the pt-spec to include the version on the STATUS message Next week: - use rdsys bridges in circumvention settings (bridgedb#40045) Shelikhoo: 2022-03-03 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Merge Request Awaiting] uTLS for broker negotiation - [Discussion] Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update (aka "Subscription") - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) Next Week: - [Coding & Deployment] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) 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 hanneloresx: 2021-3-4 Last week: - Submitted MR for bridgestrap issue #14 Next week: - Finish bridgestrap #14 - Find new issue to work on Help with: - -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

PSA: procmail removed from all torproject.org servers
by Antoine Beaupré 01 Mar '22

01 Mar '22

Hi, The venerable "procmail" package will progressively be removed from all torproject.org servers over the next 6 hours. Details on the why and the how are explained in this ticket: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40639 ... but the short version is that procmail hasn't been maintained for more than 20 years and has known security issues. If you currently use any of the following commands in any script or program, you will need to migrate to an alternative: * procmail * mailstats * lockfile * formail For procmail and mailstats, the alternative is generally to switch to a Sieve-compatible local delivery agent (LDA). I have deployed this on rude (rt.torproject.org) successfully. The other host using it was polyanthum, which has been cleaned up as well (tpo/tpa/team#40635). I am not aware of any other deployment of procmail, and I searched far and wide (for .procmailrc files, specifically). As for the other alternatives, instead of lockfile(1), use flock(1). Instead of formail(1) you can use reformail(1), from the courier `maildrop` package. If I missed anything, do let me know. Apologies for the rushed deployment. Typically, we would do this sort of change with an advanced notice and a formal proposal, but considering the severity of the security issue, I figured it was better to act quickly, at the cost of breaking things, rather than allow what is essentially a backdoor into our systems. A. -- Antoine Beaupré torproject.org system administration

1 0

PieroV's monthly status report
by Pier Angelo Vendrame 01 Mar '22

01 Mar '22

Hi everyone! Here is my status report for February 2022. This month I continued working on the Tor Browser connection preferences. I was also assigned the related changes on the about:torconnect page. All the updates are on the merge request (tor-browser!254 <https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests…>). As you can see, we are taking care of every detail 💫! And we will continue working on it also in March. Another change I worked on is the HTTPS-only mode (tor-browser#19850 <https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850>). With it, HTTPS-Everywhere will not be needed anymore. However, we want to keep .tor.onion aliases working. Therefore, recently I worked on a replacement for this extension (tor-browser#40458 <https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40458>). I will continue working on it in March. Finally, I reviewed some merge requests (the 91.6 rebases and torbutton!72 <https://gitlab.torproject.org/tpo/applications/torbutton/-/merge_requests/72> to show IPv6 addresses on circuit display) and worked a little bit on Tor Browser tests. And that is all for February 🙂. Thanks, Pier

1 0

new BridgeDB version using rdsys
by meskio 28 Feb '22

28 Feb '22

Hello, I have just deployed a new version of BridgeDB[0]. Now BridgeDB uses rdsys[0] as backend so it has changed how bridges are managed internally, but all the user facing pieces are (almost) the same. The distributors (email, https[1] and moat) hasn't changed and should work as before. If you are a bridge user you should not see any difference. The bridges you are already using should stay working and requesting new bridges should work as before. The move to rdsys implies that all the bridges might have changed their distribution mechanism. If you are bridge operator you might see your bridge having a different distributor mechanism in the coming hours, if you had configured your bridge with the "BridgeDistribution" option your distribution mechanism should not change and stay on what you configured. There are more few more distribution mechanisms now, this is the full list: * https. The web interface of bridgedb[0]. * moat. The API used by Tor Browser to request bridges directly from the settings. * email. Bridges distributed by bridges(a)torproject.org. * telegram. Bridges that will be distributed by the telegram bot @GetBridgesBot. * settings. A new API used to autoconfigure the circumvention mechanism depending on your geolocation. * reserved. Bridges reserved for experiments or future needs. People with bridges assigned to telegram and settings will not see much usage of their bridges yet, as those are projects we are working on but will be soon in use. If you notice any problems with the bridge distribution don't hesitate to open an issue[2] or contact me. [0] https://bridges.torproject.org [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Community Team meeting notes - February 14 2022
by gus 25 Feb '22

25 Feb '22

Hi, Here's our meeting log: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-02-14-14.02.html And our meeting pad: ## Tor Community Team meeting pad Next meeting: Monday, February 28, 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 checkin about the status of Community Team work at Tor. ## Links to Useful documents * Tor 0.3.5.x EOL: https://forum.torproject.net/t/tor-relays-tor-0-3-5-x-is-unsupported-please… * 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 * Tor docs mirror * Forum tags * Disabling and archiving dead mailing lists: * https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-teachers * https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-community-team * https://lists.torproject.org/cgi-bin/mailman/listinfo/global-south * Outreachy/Gamification project updates ## Updates Gus: Last week: - Finished to contact all EOL relay operators (phew!) This week: - Following up and helping some EOL relay operators. - Reviewing network health fellowship with acute. - S96 meeting: - Discuss new default bridges plan: https://gitlab.torproject.org/tpo/community/relays/-/issues/23 - S9 meeting - S30 sync meeting with Tails and The Guardian Project - Onboarding raya, our new education coordinator - S123 kick-off meeting - Run a bridge campaign: getting bridge operators contact info and sending to Erin. - Run a bridge campaign: select 10 bridge operators. Joydeep: Last week: - Tor Browser 11.0.6 support work - All articles reviewed and updated on frontdesk This week: - Tor Browser Alpha 11.5a4 testing and support work - learn more about the Discourse trust levels (part of https://gitlab.torproject.org/tpo/community/support/-/issues/40060) emmapeel: Last week: - Translation previews - Review locales for release - Define list of countries/regions for the tor browser - Some web fixes, especially about images in previews This week: - Bug translators to maintain already published translations - Think and add to gitlab the weblate integration - document new setup - Friday: hangout! Rhatto: Last week: - Onboarding tasks: https://gitlab.torproject.org/tpo/community/team/-/issues/57 - Onion Services SRE kickstart meeting: https://lists.torproject.org/pipermail/tor-project/2022-February/003288.html - Wrote minimailer: https://gitlab.torproject.org/rhatto/minimailer/ - Skeleton for the Oniongroove project: https://gitlab.torproject.org/rhatto/oniongroove This week: - Remaining onboarding tasks: https://gitlab.torproject.org/tpo/community/team/-/issues/57 - S123 kick-off meeting - Work on Oniongroove specs (hopefully) Help with: - Suggestions/advice on Onion Services deployment. Nina: Last week: - User support via RT - User suppot via Telegram - Article translation:247 "Russian: Enquiries with anything related to 'Dark Web'" This week: - User support - Translation of the article "Law enforcement requests about Onion Services" Miko: Last week: - Started working on mockups!! - Incorporated new ideas after brainstorming mockup with Gus This week: - Mockup is out (Figma link, no sign in needed) https://www.figma.com/proto/aQdKK8BdMs4NQr0ClAwy8Y/Relay-Portal-Mockup-(Cop… Next week: - Working on look and feel of the relays portal (high fidelity mockup!!) Help with: - Recruiting users for user testing low fidelity mockup -- The Tor Project Community Team Lead

1 0

Anti-censorship team meeting notes, 2022-02-24
by meskio 24 Feb '22

24 Feb '22

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-02-24-15.59.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday February 24th 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 checkin 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 30 https://gitlab.torproject.org/groups/tpo/-/milestones/4 https://gitlab.torproject.org/groups/tpo/-/milestones/7 https://gitlab.torproject.org/groups/tpo/-/milestones/5 https://gitlab.torproject.org/groups/tpo/-/milestones/6 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&… == Announcements == meskio plans to deploy rdsys+bridgedb next Monday, 2022-02-28. many bridges will change distribution mechanism == Discussion == obfs4 fail to connect issue https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 upstream maintainer recommends getting servers to upgrade our own testing shows that new client -> new server solves the problem no reply yet to the query sent to Aaron Johnson following last week's conversation obfs4proxy is on its way to Debian testing, as soon as it hits testing we should ask acute to upload it to backports, to make it easier for server operators to upgrade the package is expected to reach testing in <10 days an upgrade of all obfs4 bridges will likely take time start with the limited goal of upgrading all Tor Browser default bridges? https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Default-Brid… bridges currently don't report the version of the PTs they run, it would help track the progress of upgrading if they did report https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2770219 Past discussion on using the PT STATUS message for version reporting: https://lists.torproject.org/pipermail/tor-project/2021-October/003194.html http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-09-30-16.00.log… uTLS in Snowflake Client Broker Communication we have some concerns on the uTLS fingerprints being old and "easier" to censor psiphon devs see uTLS working right for them is a client side change, we can update it quickly we don't enable uTLS by default, but make it an option from the SOCKS interface, so we can enable it by changing the bridge line from the circumvention settings == Actions == == Interesting links == https://archive.org/details/ptim2021 Pluggable Transports Implementers Meeting 2021 videos == Reading group == We will discuss "Throttling Twitter: an emerging censorship technique in Russia" on 10 March https://dl.acm.org/doi/pdf/10.1145/3487552.3487858 https://censorbib.nymity.ch/#Xue2021a 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-02-17 Last week: - tried out snowflake experiments in shadow's preload mode - https://github.com/shadow/shadow/issues/1549 - deployed snowflake server fixes - reached out to default bridge operators - finished s28 prep and documentation - wrote some follow up code for Snowflake event channel - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… This week: - mostly afk Needs help with: dcf: 2022-02-24 Last week: - further helped debug obfs4proxy-0.0.12 connection failures https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 - investigated a snowflake bridge outage and restarted the server Next week: - post summary of 2022-02-18 snowflake bridge outage Help with: agix: 2021-02-10 Last week: - Continued work on gettor-twitter Next week: - Hopefully finish the task Help with: - arlolra: 2022-01-20 Last week: - [added 2022-01-20 by dcf] ALPN support for pion DTLS https://github.com/pion/dtls/pull/415 Next week: - 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-02-24 Last week: - validate opendkim headers in bridgedb (bridgedb!36) - review concurrency problems in rdsys (rdsys#90) - fix rdsys bridge status site, it was not reporting if they are working for non-vanilla bridges (rdsys#88) - handle bridgedb reconnections (bridgedb!34) - make easier to develop bridgedb with a fake rdsys (bridgedb#40034) - coordinate the deployment of rdsys + bridgedb Next week: - deploy rdsys + bridgedb in production (rdsys#12) - use rdsys bridges in circumvention settings (bridgedb#40045) Shelikhoo: 2022-02-24 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Merge Request Done] Add verbosity switch to suppress diagnostic output (snowflake#40079, snowflake!74) - [Merge Request] uTLS for broker negotiation - [Discussion] Implement metrics to measure snowflake churn (snowflake#34075) - [Discussion] Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update (aka "Subscription") - [Discussion] Proposal: Push Notification Based Signaling Channel - [Discussion] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) - [Discussion] HTTPT & Websocket (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http…) - [Investigate] Is there a better moat/snowflake SNI than cdn.sstatic.net? (snowflake#40068) - [Investigate] Multi-instance Load Balanced Tor - Snowflake Deployment - [Investigate] China "Anti-Fraud" Webpage Redirection Censorship (censorship-analysis#40026) - [Investigate] S96 Bridge Performance Next Week: - [Discussion] Implement metrics to measure snowflake churn (snowflake#34075) - [Discussion] Proposal: Push Notification Based Signaling Channel - [Coding] Proposal: Centralized Probe Result Collector (anti-censorship/team#54) 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 hanneloresx: 2021-3-4 Last week: - Submitted MR for bridgestrap issue #14 Next week: - Finish bridgestrap #14 - Find new issue to work on Help with: - -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Network Team - Upcoming tor.git 0.4.7.4-alpha release - February 2022
by David Goulet 23 Feb '22

23 Feb '22

Greetings, Network team will be releasing on Friday a new alpha (0.4.7.4-alpha) but this one is very special, it is the first alpha with the gigantic congestion control work in it. https://gitlab.torproject.org/tpo/core/tor/-/issues/40405 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rt… There are also couple important fixes for relay operators running alphas and so we will recommend to upgrade. With this alpha, we hope to get to a release candidate very soon and then onto the long awaited 0.4.7 stable in around 2-3 months. Upcoming versions: - 0.4.7.4-alpha @network-team: It is _now_ a good time to start reviewing changes/ files: https://gitlab.torproject.org/tpo/core/tor/-/tree/main/changes Last, we've asked the dirauth to recommend these versions few minutes ago. Cheers! David -- hn/Y6tIdc7o83Kubm4tb7kwGg3cVfoop1AQ3QAX8UkA=

1 0

DEMO DAY at the end of March? Please send us your proposal
by Gaba 22 Feb '22

22 Feb '22

Hi! We are going to have our next demo day at the end of March! Please submit your proposals to https://nc.torproject.net/apps/forms/MT5NTyWnGwDsJ4r8 Tor Demo Day - March 23rd 2022 ============================== What is a Demo Day? ------------------- An hour long session at an all hands meeting where different people present 5 minutes ideas, tools, hacking or anything that they think it may be interesting for the Tor community. How? ---- - We call for presenters a month before the demo day. - The agenda will be set before the meeting and will be shared with tor-project. - We want 5 to 8 minutes length presentations. We will handle questions at the end of all presentations. - Slides are allowed, but not mandatory. You may share your screen or a pre-recorded video if that makes you less anxious. - We like the adrenaline of the live presentations, but if they wish, presenters can share pre-recorded videos with us. They should be sent a few hours in advance and will be lined up and shared with assistants during the session. - This is a place where people should feel safe to engage, share their point of view, and participate. Read our Code of Conduct: https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t… Who? ---- - Anyone who wants to share what they have been hacking on. It doesn't need to be a finished feature but a work in progress. It can be small like a Tor Browser feature or something you have been hacking around Tor not officially. - Presenters have 5 to 8 minutes. People can ask questions via text in the pad for 3 minutes. Where? ------ The link to a room in our BBB instance will be sent a few hours before starting the demo day. When ---- Wednesday March 23rd at 1600 UTC Agenda ------------------------------ - 5 min for the presentation - 3 min for questions ------------------------------ Questions will be written in text on the pad in any time during the presentation. Presenters will answer them in audio. -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0