- tor-project - lists.torproject.org

Anti-censorship team meeting notes, 2023-08-10
by meskio 10 Aug '23

10 Aug '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-08-10-15.57.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Aug 17 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: 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 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == * Webtunnel documentation in the community portal: * https://community.torproject.org/relay/setup/webtunnel/ == Discussion == * HTTP CONNECT and MASQUE for the future of PTs * https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/130 * coordination with other PT teams? * https://github.com/Pluggable-Transports/Pluggable-Transports-spec * https://github.com/twisteroidambassador/ptadapter * https://community.internetfreedomfestival.org/community/channels/pluggable-… == Actions == * Next week (August 10th): follow up on Snowflake/Pion incompatibility with Android 11+ and SDK >29) when Guardian project responds and shelikhoo returns: * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * might only affect android apps that target android>11, but google will start requiring it soon (end of August 2023) * https://support.google.com/googleplay/android-developer/answer/11926878 * Issue on pion side, closed as wontfix: https://github.com/pion/transport/issues/228 * we ought to be up to date with dependencies, as renovatebot is connected to the snowflake repo * meskio will cc Guardian Project on #40278 to see if they have any insight * shelikhoo will try to reproduce and will try the available patches * no news 2023-08-03 == 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): away until 2023-08-17 Last week: This week: Needs help with: dcf: 2023-08-10 Last week: - contributed some review to STATUS TYPE=version for server pluggable transports in core tor https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/731 - reviewed STATUS TYPE=version in goptlib https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/gopt… - did more investigation of past snowflake blocking in Turkmenistan, particularly the rise an fall in users from May to August 2022 https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Next week: - merge goptlib STATUS TYPE=version https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/gopt… - 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-08-10 Last week: - review webtunnel documentation for the community portal (web/community!310) - fix snowflake release CI (snowflake!157) - create an issue to discuss HTTP CONNECT and MASQUE for the future of PTs (team#130) - lox reviews (lox-rs!22 lox-rs!20) Next week: - be AFK at CCCamp Shelikhoo: 2023-07-27 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - logcollector alert system - ongoing - Reviewing & comment on merge requests - FOCI Keynote and attendence Next Week/TODO: - logcollector alert system <- immediate todo onyinyang: 2023-08-03 Last week(s): - Implemented db - decided against polodb and went for sled instead https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/22 - not sure if reading/writing the lox-context to json should still be supported at all or just removed - Implemented and tested a basic k-invites for open entry distribution https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/20 - Thought more deeply about how best to sync Lox with rdsys given https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168 - the rdsys API is really not designed for a distributor like Lox that needs persistence. Even a lastPassed flag will only be helpful for `gone` resources if Lox stores all of the resource info from rdsys and checks it regularly. This diverges from the original intention of rdsys, in which rdsys should be the 'arbiter of truth' for the status of resources - The next step is to check the rdsys API and see if the get functionality can improve this situation. I think ideally we want a list of all resources assigned to Lox and their current statuses that can then be checked against something like the `lastPassed` flag each time Lox polls rdsys. This week: - Continue with implementing db and synchronization between Lox/rdsys (possibly reliant on some aspects of the former point) - Work on adding metrics - AFK from August 5 - 21! (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? Itchy Onion: 2023-06-08 Last week: - fixed snowflake pipeline due to outdated Debian image - continue working on rdsys#56 implementation. Still need to do the following: - finish up computing bridge distribution in Kraken - does it have to be deterministic? - does the disproportion have to be strictly followed - finish writing tests - refactor code because some functions are getting extremely long - what to do with stencil package? This week: - review MRs - continue working on rdsys#56 implementation. Still need to do the following: - fixed a problem with vanilla bridges not being added properly to the database - still working on tests - adding a migaration patch (https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/56#note_29…) -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

ebanam's monthly status report for July 2023
by ebanam 05 Aug '23

05 Aug '23

Hello everyone, Most of my work, during July, revolved around helping users in places where Tor is censored. This, in general, involved helping people use Connection Assist, use Pluggable Transports in Tor Browser and little-t-tor. I also worked to collect Tor logs and general user feedback during the ongoing webtunnel soft launch. With two Tor Browser release in this month (one stable, one alpha) some of my work went into providing post-release user support. Apart from this, I made some changes to our user-facing documentation on the Tor Browser Manual and Support Portal. Added updated instructions on installing, updating and uninstalling Tor Browser for Android from the Play Store[0] and improved the section about how to prioritize onion sites in Tor Browser (thanks to feedback from a translator)[1] and section on how to make Tor Browser work with antivirus software on the Support Portal[2]. Also helped with reviewing the support templates that we have for the webtunnel soft release. Following is a breakdown of tickets our user support team handled in July: Timeframe: 01 - 31 July 2023 # Frontdesk (email) * 648 (↑) RT tickets created * 514 (↓) RT tickets resolved Most frequent tickets by numbers: 1. 203 (↑) RT tickets: circumventing censorship in Russian speaking countries. 2. 61 (↓) RT tickets: private bridge requests from China. 3. 6 (-) RT tickets: circumventing censorship with Tor in Iran. # Telegram, WhatsApp and Signal Support channel * 959 (↑) tickets resolved Breakdown: * 932 (↑) tickets on Telegram * 20 (↑) tickets on WhatsApp * 7 (↑) tickets on Signal The most frequent tickets on cdr.link have been about: 1. 653 (↑) tickets: Circumventing censorship in Russian speaking countries. 2. 41 (↓) tickets: Circumventing censorship in Iran. 3. 10 (↓) tickets: Circumventing censorship in China. # Highlights from the Tor Forum 1. We updated the instructions on the Support Portal regarding how to make Tor Browser work with antivirus[2] owing to some user feedback on the Forum[3] 2. Update about censorship in Turkmenistan (thanks to Gus)[4] 3. "How do I connect to a WebTunnel bridge?"[5] 4. (Upcoming Event) "Tor Project sessions for the Feira at Global Gathering"[6] 5. Outgoing email outage on Forum (issue resolved. thanks to TPA!)[7] Thanks! e. Note: (↑), (↓) and (-) are indicative if the number of tickets we received for these topics have been increasing, decreasing or have been the same from the previous month respectively [0]: https://tb-manual.torproject.org/mobile-tor/ [1]: https://tb-manual.torproject.org/onion-services/ [2]: https://support.torproject.org/tbb/tbb-10/ [3]: https://forum.torproject.org/t/new-release-tor-browser-12-5/8105/4 [4]: https://forum.torproject.org/t/tor-relays-help-turkmens-to-bypass-internet-… [5]: https://forum.torproject.org/t/how-do-i-connect-to-a-webtunnel-bridge-i-wis… [6]: https://forum.torproject.org/t/tor-project-sessions-for-the-feira-at-global… [7]: https://forum.torproject.org/t/outgoing-email-outage-on-forum-resolved/8412

1 0

Anti-censorship team meeting notes, 2023-08-03
by onyinyang 04 Aug '23

04 Aug '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-07-31-15.58.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, Aug 10 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 == This week: * ptspec status version support * to be included in 0.4.8 * https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/731 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/gopt… * goptlib not blocking core tor * Webtunnel soft release and next phase: https://gitlab.torproject.org/tpo/community/team/-/issues/94 * Feedback collected * improving the docs for compiling from the source * some ppl asked apache instructions and not just nginx * didn't work in china and worked in russia * Next steps * gus will improve and move the documentation to the community portal * will talk with applications to include webtunnel in the upcoming TB 13 in september * we'll organize a call for bridges * HTTP CONNECT as an alternative to SOCKS for PT interfacing * HTTP CONNECT proxy has advantages over SOCKS4/5, one of which is abundant room to encode bridge parameters * Mentioned in an issue about bridge line length * https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/104#note_29… * dcf: server-side SOCKS (needed for client PT) has poor support in standard programming language packages, which is why goptlib and Proteus implement their own SOCKS server: * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/gopt… * https://github.com/unblockable/proteus/tree/v0.1.0/src/net/proto/socks * What about MASQUE (https://datatracker.ietf.org/wg/masque/about/) more generally (HTTP proxying but more general than just HTTP CONNECT, would leave room for e.g. datagram-based proxying)? * "The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection." == Actions == * Next week (August 10th): follow up on Snowflake/Pion incompatibility with Android 11+ and SDK >29) when Guardian project responds and shelikhoo returns: * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * might only affect android apps that target android>11, but google will start requiring it soon (end of August 2023) * https://support.google.com/googleplay/android-developer/answer/11926878 * Issue on pion side, closed as wontfix: https://github.com/pion/transport/issues/228 * we ought to be up to date with dependencies, as renovatebot is connected to the snowflake repo * meskio will cc Guardian Project on #40278 to see if they have any insight * shelikhoo will try to reproduce and will try the available patches * no news 2023-08-03 == 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): away until 2023-08-17 Last week: This week: Needs help with: dcf: 2023-08-03 Last week: - wrote forum post for proxy churn measurements https://forum.torproject.org/t/advisory-mistakenly-collected-proxy-churn-me… and made issue public https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - fixed standalone proxy DefaultRelayURL to point back at snowflake.torproject.net https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - review goptlib STATUS TYPE=version https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/gopt… - 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-08-03 Last week: - release and deploy rdsys with telegram bot translations - test tor's support for status version (tor!731) - add support for goptlib for status version (goptlib!1) - review and deploy new circumvention rules for Turkmenistan (rdsys-admin!16) - update obfs4 docker image to don't expose OrPort (team#129) - review lox merge requests (lox-rs!15 !18 !21) Next week: - organize work for BridgeDB deprecation Shelikhoo: 2023-07-27 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - logcollector alert system - ongoing - Reviewing & comment on merge requests - FOCI Keynote and attendence Next Week/TODO: - logcollector alert system <- immediate todo onyinyang: 2023-08-03 Last week(s): - Implemented db - decided against polodb and went for sled instead https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/22 - not sure if reading/writing the lox-context to json should still be supported at all or just removed - Implemented and tested a basic k-invites for open entry distribution https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/20 - Thought more deeply about how best to sync Lox with rdsys given https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168 - the rdsys API is really not designed for a distributor like Lox that needs persistence. Even a lastPassed flag will only be helpful for `gone` resources if Lox stores all of the resource info from rdsys and checks it regularly. This diverges from the original intention of rdsys, in which rdsys should be the 'arbiter of truth' for the status of resources. - The next step is to check the rdsys API and see if the get functionality can improve this situation. I think ideally we want a list of all resources assigned to Lox and their current statuses that can then be checked against something like the `lastPassed` flag each time Lox polls rdsys. This week: - Continue with implementing db and synchronization between Lox/rdsys (possibly reliant on some aspects of the former point) - Work on adding metrics - AFK from August 5 - 21! (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? Itchy Onion: 2023-06-08 Last week: - fixed snowflake pipeline due to outdated Debian image - continue working on rdsys#56 implementation. Still need to do the following: - finish up computing bridge distribution in Kraken - does it have to be deterministic? - does the disproportion have to be strictly followed - finish writing tests - refactor code because some functions are getting extremely long - what to do with stencil package? This week: - review MRs - continue working on rdsys#56 implementation. Still need to do the following: - fixed a problem with vanilla bridges not being added properly to the database - still working on tests - adding a migaration patch (https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/56#note_29…) -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

2 1

Nina’s Monthly Status Report, July 2023
by Nina 04 Aug '23

04 Aug '23

Hi! This is my July 2023 report! In July, I resolved 1080 tickets: On Telegram (@TorProjectSupportBot) - 786 On RT (frontdesk@tpo) - 276 Additionally, I resolved 13 tickets on WhatsApp (+447421000612) and 5 on Signal (+17787431312). Most of the tickets I deal with are related to censorship circumvention in Russian-speaking countries - bridges and troubleshooting around them. I also gathered user feedback on what worked for them and what did not prove helpful. In July, I noticed atrendinusersfrom Russian-speaking countries touselittle-t-tor on Windows by adding bridges directly in torrc, mostly obfs4 and meek.We believe they are using little-t-tor to proxy other applications in their operating systems.So I spent some time gathering best practices to share with users. This month we started testing the new, WebTunnel bridge[1], so I prepared templates for our support channels, added them, and started gathering users' feedback. This month I devoted significant time to editing support templates to keep them relevantand up-to-date. I continued working on Conjure feedback, gathering logs and discussing with users their experience with this type of pluggable transport. [1] https://gitlab.torproject.org/tpo/community/team/-/issues/94

2 1

Rhatto's Monthly Status Report, July 2023
by rhatto 01 Aug '23

01 Aug '23

Hi all :) This is my monthly status report for July 2023 with the main activities I have done during the period. ## 0. Research * Certificates: followed the recent updates on IETF ACME Working Group on the ACME for Onions (https://acmeforonions.org) Internet Draft: * The draft was approved back in June: https://mailarchive.ietf.org/arch/msg/acme/h61EvyQjFER9geA5adKa8u9T-x8/ * The proposal was presented during IETF 117: https://play.conf.meetecho.com/Playout/?session=IETF117-ACME-20230725-0030 * Quality Assurance for Tor Browser: continued research and investigation on issues with Tor Browser when accessing Onion Services. ## 1. Development * Onionprobe milestone planning: * https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/milestones/1 * https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/79 ## 2. Support * PoW defense for Onion Services: documentation preparation for the feature release: * https://gitlab.torproject.org/tpo/web/community/-/issues/312 * https://gitlab.torproject.org/tpo/community/team/-/issues/93 * The usual sponsored work with deployment, maintenance and monitoring of Onion Services. ## 3. Organization Time spent (from the total available for Tor-related work): | Category | Percentage |---------------|------------ | Research | 12 | Development | 0 | Support | 52 | Organization | 36 |---------------|------------ | Total | 100 -- Silvio Rhatto pronouns he/him

1 0

PieroV's Monthly Status Report, July 2023
by Pier Angelo Vendrame 01 Aug '23

01 Aug '23

Hi everyone! Here is my status report for July 2023. Like the previous month, in July, I worked mainly on the transition to Firefox ESR 115 and the refactors of Torbutton. For the ESR update, I kept working on our build system. We stumbled upon a couple of reproducibility problems with LLVM. One [0] was already fixed in the main branch, but I had to git bisect to find the solution and backport it to 16.0.4, the version we and Mozilla use. The other one was about the macOS binaries: they matched except for the UUID. Because this difference was limited and specific, I could quickly find the cause in the source code. This UUID is a hash, and its computation was split into as many workers as the available cores. Even though this is deterministic, it introduces a dependency of the result on the hardware used to produce it. So, I opened an issue [1], which was solved super fastly ❤️! Then, I also worked on the Android part of the build system. Between 102 and 115, Mozilla unified the repositories for Android Components and Fenix [2]. Therefore, we had to create a brand new project, and making it build successfully from start to end required a considerable time. We had reproducibility problems also on Android, more precisely on the application services part. They were already known, so I just had to update the patch for 102 to 115. I wanted to upstream these changes, but in Application Services 116, Mozilla did a big refactor on this code. So, I adapted our patch again, and it was accepted [3]. The tor-browser-build merge request for Android [4] is still under review, but we will need to merge it soon because we want to release 13.0a2 also for Android. My other big work topic of July was the refactors to Torbutton. Our objective is to extract all the code that originally composed the extension and integrate it more with the rest of the browser code. The first MR [5] moved about:tor to a patch on its own and included a modernization of its IPC mechanisms and a refactor to TorCheckService. It also removed old migration code that is not needed anymore since users are forced to pass through Tor Browser 11.5.8 if updating from older versions. Torbutton also forced the value of a few preferences depending on whether PBM was always enabled [6]. This MR removed this behavior. In another MR [7], I removed direct uses of the Tor controller. We planned to centralize all these operations in a TorProvider class built around the browser's needs. The rationale is to create a common interface with a future ArtiProvider. We expect that we will have to review everything again in the future, but we preferred starting already to get the first part of the work done. With this done, I could focus on refactoring the browser's Tor controller [8]. Other smaller tasks I worked on last month are: - a fix to make NoScript and the browser communicate again [9] - a fix to the bootstrap failing without any error [10] - make the build system extract Firefox's PDB and distribute them to users interested in debugging the browser [11]. This sure was a long month for me, but I am very happy about the results we are getting. I hope you will appreciate them too. In yesterday's weekly meeting, we decided to release alphas more often since we are still targeting the end of September for 13.0 stable. So, I would like to invite you all to please test the Tor Browser alphas. Thank you very much! Pier [0] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… [1] https://github.com/llvm/llvm-project/issues/63961 [2] https://github.com/mozilla-mobile/firefox-android [3] https://github.com/mozilla/application-services/pull/5736 [4] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… [5] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [6] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41845 [7] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [8] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [9] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41877 [10] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41907 [11] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/3…

1 0

Anti-censorship team meeting notes, 2023-07-27
by meskio 27 Jul '23

27 Jul '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-07-27-15.57.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Aug 3 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: 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 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == * onyingyang co-won PETS 2023 Best Student Paper Award https://www.petsymposium.org/2023/student-paper-award.php * shelikhoo co-won FOCI 2023 Best Practical Award https://twitter.com/royaensafi/status/1678822594332557312 == Discussion == * Does this issue need attention (Snowflake/Pion incompatibility with Android 11+ and SDK >29)? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * might only affect android apps that target android>11, but google will start requiring it soon (end of August 2023) * https://support.google.com/googleplay/android-developer/answer/11926878 * Issue on pion side, closed as wontfix: https://github.com/pion/transport/issues/228 * we ought to be up to date with dependencies, as renovatebot is connected to the snowflake repo * meskio will cc Guardian Project on #40278 to see if they have any insight * shelikhoo will try to reproduce and will try the available patches * Publish advisory for accidentally collected unhashed proxy churn measurements? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * dcf will make the issues public and write a forum post == Actions == * == Interesting links == * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… * Using Arti with Windows schannel for the sake of a different TLS fingerprint * https://ntc.party/t/26-04-23/4403/9 == 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): last updated 2023-06-29 Last weeks: - fixed certificate error in Snowflake and Conjure - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - released snowflake v2.6.0 - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - bumped version of Snowflake in Tor Browser - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… - fixed a crash in Conjure on Android - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - code lint improvements in lox - https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/12 - started deployment of lox distributor - https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/issues/19 - found and fixed a bug in the parsing of resource diffs from rdsys - https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/issues/22 This week: - tidy up and share shadow simulations guide for PTs - Lox tor browser integration - conjure maintenance Needs help with: dcf: 2023-07-27 Last week: - presented "Running a high-performance pluggable transports Tor bridge" at FOCI 2023 https://www.bamsoftware.com/talks/foci-2023-pt-bridge/ - opened a merge request to reduce memory allocations in snowflake-server https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - tried and discarded a performance optimization in ClientMap https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - tried adjusting num-turbotunnel on snowflake bridges to observe the effect on performance https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - opened issue to remove proxy churn measurements from broker https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reopened issue to delete accidentally unblinded hashed IP addresses in unpublished measurements https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - write forum post for proxy churn measurements https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - 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-07-27 Last week: - read and review lox code - integrate gettor updater metrics into prometheus - catch up after PETS... Next week: - test i18n support in rdsys (rdsys#11) Shelikhoo: 2023-07-27 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - logcollector alert system - ongoing - Reviewing & comment on merge requests - FOCI Keynote and attendence Next Week/TODO: - logcollector alert system <- immediate todo onyinyang: 2023-07-27 Last week(s): - Finished up up indexing of hashmaps for Lox bridgetable https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/15 - Presented Lox presentation for PETS (with some details about Tor integration) <see announcements 🎉> - Completed basic serialization/deserialization of Lox context https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/18 - Decided that poloDB is probably the most useful db for Lox, but still need to work out some details of how best to synchronize between rdsys/Lox with the current API (or if that needs to change) - Implemented a basic k-invites for open entry distribution https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/20 - Thinking more deeply about how best to sync Lox with rdsys given https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168 This week: - Come up with a plan to address https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168 - Implement db and synchronization between Lox/rdsys (possibly reliant on some aspects of the former point) - Work on 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? Itchy Onion: 2023-06-08 Last week: - fixed snowflake pipeline due to outdated Debian image - continue working on rdsys#56 implementation. Still need to do the following: - finish up computing bridge distribution in Kraken - does it have to be deterministic? - does the disproportion have to be strictly followed - finish writing tests - refactor code because some functions are getting extremely long - what to do with stencil package? This week: - review MRs - continue working on rdsys#56 implementation. Still need to do the following: - fixed a problem with vanilla bridges not being added properly to the database - still working on tests - adding a migaration patch (https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/56#note_29…) -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Tor's history of D/DoS attacks; strategy for mitigation
by Cory Francis Myers 26 Jul '23

26 Jul '23

I'm investigating the applicability of the IETF's DDoS Open Threat Signaling (DOTS) specifications[1] to the needs of privacy-preserving overlay networks, including VPNs but with particular interest in Tor. Specifically, now that the July 2022 D/DoS attack has finally come to a close, I'm wondering about: 1. the history, frequency, and magnitude of D/DoS attacks against the Tor network; 2. when these have taken the form of Tor traffic versus lower-level attacks on Tor nodes and HSDirs; and 3. how the new "proof of work over introduction circuits" scheme fits into Tor's overall strategy for mitigating D/DoS attacks. I've found plenty of current and historical GitLab tickets---but I'm wondering if there are more comprehensive documents or other resources I'm not aware of. --- cfm[2]. [1]: https://datatracker.ietf.org/wg/dots/documents/ [2]: I'm a maintainer of the SecureDrop project at the Freedom of the Press Foundation, but this work is supported by ARTICLE 19's Internet of Rights Fellowship.

2 5

GSoC'23 Project : eRPC(An efficient Relay Partition Checker) 3 weeks Project Report
by Rishad Baniya 23 Jul '23

23 Jul '23

Hello everyone, I hope everyone's doing well. This is a 3 week report(June 19 - July 8)for the GSoC(Google Summer of Code) Project, eRPC(An efficient Relay Partition Checker). Project Repo : https://gitlab.torproject.org/rishadbaniya/erpc Let me explain the progress of the project and the challenges. So far, the relay partition checking tool is ~50% complete, it achieves the goal of checking for partition by creating two hop circuits between all the relays present in the tor_netdir::NetDir provided by arti, it also handles the influx of relays by wrapping around the DirMgr provided by arti. You can run the application through here : https://gitlab.torproject.org/rishadbaniya/erpc#running-primary-worker and also explore it's structure through here : https://gitlab.torproject.org/rishadbaniya/erpc/-/wikis/home Let's go through an important challenges that I am trying to solve and community members involved in "arti" might help me out on this -: Segregating the errors that occurred while attempting to build a circuit: Here are list of all the errors that can occur while attempting to build a circuit : https://docs.rs/tor-circmgr/0.9.1/src/tor_circmgr/err.rs.html#18 While running the erpc application and building thousands of circuits, we found out that The most common error of all was : https://docs.rs/tor-circmgr/0.9.1/src/tor_circmgr/err.rs.html#111, which was mostly due to OS level errors. It would be great to have your feedback regarding how we should consider a relay being partitioned simply through those errors at https://gitlab.torproject.org/rishadbaniya/erpc/-/issues/18 With Regards, Rishad Baniya

1 0

OONI Monthly Report: June 2023
by Maria Xynou 12 Jul '23

12 Jul '23

Hello, This email shares OONI's monthly report for June 2023. *# OONI Monthly Report: June 2023* Throughout June 2023, the OONI team worked on the following sprints: * Sprint 93 (5th - 18th June 2023) * Sprint 94 (19th June - 2nd July 2023) Our work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. *## Launch of OONI Explorer supporting localization* We are thrilled to share that OONI Explorer (https://explorer.ooni.org/) now supports localization! OONI Explorer is an open data resource on internet censorship around the world. As of June 2023, OONI Explorer is available in 8 new languages: * Chinese: https://explorer.ooni.org/zh-cn * Farsi: https://explorer.ooni.org/fa * French: https://explorer.ooni.org/fr * German: https://explorer.ooni.org/de * Russian: https://explorer.ooni.org/ru * Spanish: https://explorer.ooni.org/es * Thai: https://explorer.ooni.org/th * Turkish: https://explorer.ooni.org/tr We thank the Localization Lab (https://www.localizationlab.org/) community for making OONI Explorer – and real-time open data on internet censorship worldwide – available in so many new languages! *## OONI Probe Mobile* We made some improvement to the code quality of OONI Probe Android by making progress on de-duplicating the code used for running background tests (https://github.com/ooni/probe-android/pull/572) and we made improvements to some of the unit tests ( https://github.com/ooni/probe-android/pull/575) We also added the ability to “select all”, “deselect all” category codes in the websites categories to test settings (https://github.com/ooni/probe-android/pull/576) *## OONI Probe user guides translated to German* Thanks to a community member (Curtis Baltimore), the OONI Probe user guides are now available in German! The German user guides are available through the following links: * OONI Probe Mobile User Guide: https://ooni.org/de/support/ooni-probe-mobile * OONI Probe Desktop User Guide: https://ooni.org/de/support/ooni-probe-desktop *## OONI Run* We have started adding support to OONI Probe Android for parsing and displaying OONI Run v2 descriptors ( https://github.com/ooni/probe-android/pull/577) We also made progress on the web editor for OONI Run v2 links (https://github.com/ooni/run/pull/131) and on the backend for adding support for storing and serving them, by deploying it to the testing infrastructure ( https://github.com/ooni/backend/pull/678) *## OONI Probe CLI* We released OONI Probe CLI v3.17.4 ( https://github.com/ooni/probe-cli/releases/tag/v3.17.4) This release updates to OpenSSL 1.1.1u (https://github.com/ooni/probe-cli/pull/1148) includes a test helper fix to correctly measure Twitter ( https://github.com/ooni/probe/issues/2488) and updates the GeoIP database to 2023-06 to address a Facebook Messenger issue ( https://github.com/ooni/probe/issues/2485) We also released OONI Probe v3.17.5 (https://github.com/ooni/probe-cli/releases/tag/v3.17.5) which updates to go1.19.10. Moreover, we upgraded the main development branch to go1.20.5 ( https://github.com/ooni/probe/issues/2478) and we released OONI Probe CLI v3.18.0-alpha (https://github.com/ooni/probe-cli/releases/tag/v3.18.0-alpha) and v3.18.0 (https://github.com/ooni/probe-cli/releases/tag/v3.18.0) In addition to the aforementioned patches that we also included in v3.17.x, the v3.18.x series releases the following major features (please, refer to the v3.18.0-alpha and v3.18.0 release notes for the complete changelog): * dslx ( https://pkg.go.dev/github.com/ooni/probe-cli/v3@v3.18.0/internal/dslx) an internal DSL for simplifying the process of writing and maintaining network experiments; * netemx ( https://pkg.go.dev/github.com/ooni/probe-cli/v3@v3.18.0/internal/netemx) support for writing integration testing using Gvisor (a TCP/IP stack in userspace that allows us to simulate censorship and throttling in a predictable environment). We started working on dslx in December 2022 and we started working on netemx in March 2023. We are excited to see these features finally landing in a stable release! While working on the v3.18.x release, we also updated the underlying ooni/netem library (https://github.com/ooni/netem) used by the netemx feature to emulate DNS spoofing (https://github.com/ooni/netem/pull/27) By releasing v3.18.0 (https://github.com/ooni/probe-cli/releases/tag/v3.18.0) which uses go1.20.5, we also addressed a community raised issue ( https://github.com/ooni/probe/issues/2478) where it was impossible to compile OONI Probe using the go1.20.x compiler series. *## Expanding OONI’s testing model to support richer testing input* We continued to work on supporting richer testing input ( https://github.com/ooni/ooni.org/issues/1291) We tagged version v0.1.0 ( https://github.com/ooni/2023-05-richer-input/releases/tag/v0.1.0) of our ooni/2023-05-richer-input prototype ( https://github.com/ooni/2023-05-richer-input) This release saves the stage of the repository at the end of May 2023. In this initial prototype, we implemented richer input as a list of flat “mini nettests” that an existing nettest (e.g., Facebook Messenger) should execute to obtain a complete measurement of all the relevant targets. While this design was adequate for an initial prototype, in June 2023 we spent additional time trying to engineer and simplify this design. In particular, we investigated whether we could reuse the DSL introduced in ooni/probe-cli v3.18.0-alpha ( https://github.com/ooni/probe-cli/releases/tag/v3.18.0-alpha) to express richer inputs in a more flexible and composable way ( https://github.com/ooni/probe/issues/2494) This culminated in releasing v0.2.0 (https://github.com/ooni/2023-05-richer-input/releases/tag/v0.2.0) of the prototype, which included a possible richer input implementation that was using a DSL instead of flat nettest targets. A DSL-based design is more flexible because we can naturally compose existing building blocks (e.g., DNS lookups, TCP connect, TLS handshake) with other blocks whose task is that of calculating a nettest’s top level keys (e.g., the `blocking` key of Web Connectivity). We introduced a complete DSL for richer input and adapted Facebook Messenger to use such a DSL ( https://github.com/ooni/2023-05-richer-input/pull/5, https://github.com/ooni/2023-05-richer-input/pull/6) *## Creating a throttling measurement methodology* Regarding measuring throttling (https://github.com/ooni/ooni.org/issues/1296) we focused on adding (to the DSL introduced in ooni/probe-cli v3.18.0-alpha (https://github.com/ooni/probe-cli/releases/tag/v3.18.0-alpha)) prototype support for collecting extra statistics during long downloads to Web Connectivity LTE (the current experimental version of Web Connectivity) and to the ooni/2023-05-richer-input ( https://github.com/ooni/2023-05-richer-input) Currently, the underlying framework that we use for these three pieces of code collects up to 64 network events during and after the TLS or the QUIC handshake. While these events naturally include the initial download of the body, we wanted to extend this model to collect download speed snapshots. To this end, we imported memoryless from m-lab/go ( https://github.com/ooni/probe-cli/pull/1163) to have support for sampling at exponentially distributed (and truncated) intervals, which provides PASTA properties (https://en.wikipedia.org/wiki/Arrival_theorem) when observing network events. We then used this functionality to implement collecting download speed snapshots ( https://github.com/ooni/probe-cli/pull/1166) and we added initial support for measuring the download speed ( https://github.com/ooni/2023-05-richer-input/pull/4) *## Creating a Social Media Censorship Alert System* In May 2023, we continued to make progress towards building a Social Media Censorship Alert System. Specifically, we added support for the reprocessing of existing measurements, and we are currently running the event detector on the backend host. As part of improvements to the overall event detector logic, we fixed a bug affecting how columns are handled in Pandas. This work is documented through the following pull request: https://github.com/ooni/backend/pull/651 *## Creating a Censorship Incident Reporting Platform* We’re excited to share that we’re building a Censorship Incident Reporting Platform! New censorship events frequently emerge worldwide on an ongoing basis, but producing an in-depth report and analysis on each event (in a timely manner) is not easily scalable. Moreover, rapid response efforts benefit from censorship findings that are easier and quicker to consume. We therefore aim to create a Censorship Incident Reporting Platform which will regularly provide short reports with summary information on emergent censorship events based on OONI data and charts. This will enable journalists and human rights defenders to more easily learn about and respond to censorship events. Over time, the platform will become an archive of known censorship incidents from around the world based on OONI network measurement data. In June 2023, we made significant progress towards creating a Censorship Incident Reporting Platform. Specifically, we developed the backend API for creating, updating and retrieving censorship incidents through OONI Explorer (https://github.com/ooni/backend/pull/678) This will allow logged in OONI Explorer users to create incidents that can then be retrieved by any user on the OONI Explorer platform, allowing us to develop views for them. The backend API feature was deployed on testing and production infrastructure, allowing us to start working on the frontend for displaying and editing the censorship incidents. On the frontend part, we started working on the editor ( https://github.com/ooni/explorer/pull/862) which supports an enriched markdown format that allows us to embed MAT charts within markdown formatted text. It also allows us to define some metadata which can be used for retrieving incidents matching a specific search criterion (e.g. all censorship incidents pertaining to a particular country). *## OONI backend* In June 2023, we implemented the extraction of test helper metadata (URL and type) in the fastpath (https://github.com/ooni/backend/pull/682) which will enable us to track which test helper was used in Web Connectivity measurements and to create dashboards to detect correlation between test helper locations and test failures. We updated the test helper rotation tool to deploy Vector and configure log forwarding on test helpers ( https://github.com/ooni/backend/pull/692) which will allow collecting logs from the test helpers centrally and storing them. We also implemented an initial form of alarming based on the test helper failure rate. We added support for GeoIP lookup for the probes ( https://github.com/ooni/backend/pull/678) and we implemented an experimental tool and dashboard to monitor the accessibility of our website (ooni.org) through Tor. We created an experimental STUN server to perform initial connectivity tests from countries that block many other protocols. *## Automating censorship detection and characterization based on OONI measurements* In June 2023, we added support for storing IP metadata related to control measurements (e.g. AS and country information) to be used as part of the DNS analysis (https://github.com/ooni/data/pull/30) We also added support for making it easier to perform migrations of the database SQL schema, allowing us to more quickly enrich the database table with more features ( https://github.com/ooni/data/pull/30/commits/7c9b6a5c68841c86e553c2d60d5fbf… ). We also added support for correctly mapping unknown_failures (caused by software bugs) to known failure strings, which allows us to consider more kinds of measurements as part of the analysis (which would have otherwise been considered as “failed”). This work is documented here: https://github.com/ooni/data/pull/29 Finally, we added support for skipping the use of the dask parallel processing engine, when no parallelism is needed, thereby increasing performance (https://github.com/ooni/data/pull/31) *## Interviewed Project Manager candidates* In June 2023, we completed the first round of interviews for the OONI Project Manager position ( https://ooni.org/post/2023-job-opening-ooni-project-manager/) Based on these interviews, we created a shortlist for the second (and final) round of interviews and coordinated with candidates. We also started the second round of interviews with shortlisted candidates. *## Blocking of social media in Senegal* Following unrest erupted over the sentencing of opposition leader Ousmane Sonko, OONI data from Senegal shows that ISPs started blocking access to several social media platforms on 1st June 2023. Specifically, OONI data shows the blocking of: * WhatsApp: https://explorer.ooni.org/chart/mat?probe_cc=SN&since=2023-05-03&until=2023… * Telegram: https://explorer.ooni.org/chart/mat?probe_cc=SN&since=2023-05-03&until=2023… * Facebook, Instagram, YouTube, Twitter: https://explorer.ooni.org/chart/mat?probe_cc=SN&since=2023-05-03&until=2023… OONI data collected from Senegal shows that access to social media and messaging platforms is blocked by means of TLS interference (i.e. TLS handshakes timing out). In response to the blocks, we shared relevant OONI data (and charts) on our social media platforms ( https://twitter.com/OpenObservatory/status/1664611174854303745) with the #KeepItOn advocacy community, and with Senegalese advocacy groups. *## Blocking of F-Droid in China* As of 22nd June 2023, OONI data collected from China shows the blocking of F-Droid by means of DNS injection, where an unrelated IP address (e.g. DropBox) is returned to the client ( https://explorer.ooni.org/m/20230622211826.539282_CN_webconnectivity_87bc82…) This technique is commonly used in China to restrict access to services, and OONI data shows that F-Droid is blocked on at least 4 networks in China. OONI data on the blocking of F-Droid in China is available here: https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-06-13&until=2023… In response to the block, we shared OONI data (and charts) in both English and Chinese on our social media platforms ( https://twitter.com/OpenObservatory/status/1673659531639894019) We also reached out to F-Droid developers to share relevant data that could potentially help with circumvention. *## Community use of OONI data### Civil society response to the social media blocks in Senegal* As soon as the social media blocks emerged in Senegal on 1st June 2023, Senegalese civil society groups ran OONI Probe and independently reported on the blocks, sharing OONI data ( https://twitter.com/aliamsi/status/1664374471849902080) Similarly, other internet freedom community members, such as Deutsche Welle’s Oliver Linow, responded to the blocks by sharing OONI data ( https://twitter.com/OliverLinow/status/1664397344111042565) *### Access Now statement in response to social media blocks in Senegal* In response to the social media blocks in Senegal, Access Now published a statement (citing OONI data): https://www.accessnow.org/press-release/keep-people-connected-senegal/ *## Community activities### RightsCon 2023* Between 5th-8th June 20213, OONI’s Elizaveta, Maria, and Arturo traveled to Costa Rica to attend RightsCon 2023 (https://www.rightscon.org/) As part of their participation, they presented OONI as part of the following 5 sessions: 1) Session: “KeepItOn in 2022: successes, opportunities, struggles, and lessons learned in the fight against election-related shutdowns” (hosted by Access Now and KICTANET), 6th June 2023, OONI speaker: Elizaveta Yachmeneva 2) Session: “Data and Action: Using data analysis for incident response and threat prevention” (hosted by the Center for Digital Resilience), 7th June 2023, OONI speaker: Arturo Filastò 3) Workshop: “Learn to investigate internet shutdowns through an Iran 2022 case study” (hosted by OONI and IODA), 7th June 2023, OONI speaker: Maria Xynou 4) Session: “Internet blocking and the consequences for human rights?” (hosted by Cloudflare), 8th June 2023, OONI speaker: Arturo Filastò 5) Lightning talk: “Investigating Internet shutdowns through open data” (hosted by OONI, IODA, M-Lab), 8th June 2023, OONI speaker: Maria Xynou We also participated in a private #KeepItOn meeting to discuss how telcos can support the fight against internet shutdowns. Overall, participating at RightsCon provided a great opportunity to reconnect with many of our partners and community members in person, and to learn from many of the sessions that we attended! *### OONI workshop for journalists and civil society in Sierra Leone* On 21st June 2023, OONI’s Elizaveta facilitated an online OONI workshop for journalists and civil society organizations in Sierra Leone as part of the hybrid Stakeholders Dialogue on Internet Shutdowns event organized by Access Now and our Sierra Leone partner, CHRDI ( https://ooni.org/partners/chrdi/) ahead of Sierra Leone’s 2023 elections. Information about the event is available through the following links: https://twitter.com/chrdiorg/status/1671661565068623877 https://twitter.com/accessnow/status/1670860527541600256 The event (along with the OONI workshop) can be watched here: https://www.youtube.com/watch?v=ho1wTgvIE-M *### OONI webinar for civil society in Sierra Leone* On 22nd June 2023, OONI’s Elizaveta presented OONI’s tools and methods to civil society groups in Sierra Leone as part of Paradigm Initiative’s “Defend, Connect, Report: Navigating Internet Censorship and Defending Digital Rights in Sierra Leone’s Election” webinar in preparation for Sierra Leone’s 2023 elections. Information about the webinar is available here: https://twitter.com/ParadigmHQ/status/1671091608840990722 *### OONI workshops at DSAConnectCon 2023* Between 28th-29th June 2023, OONI’s Maria traveled to Johannesburg, South Africa, to participate at DSAConnectCon, a 2-day community convening organized by our partner, Digital Society of Africa (DSA). Learn about DSA’s important work here: https://digitalsociety.africa/ As part of her participation, Maria co-facilitated 2 training sessions in collaboration with IODA’s Amanda. These training sessions (“Investigating Internet shutdowns through open data”) introduced participants to both OONI and IODA tools, methods, and datasets, including hands-on exercises based on real-world internet shutdown scenarios. Maria also assisted participants with localizing OONI Probe into 7 additional African languages (Zulu, Ndebele, Nyanja, Swati, Mozambican Portuguese, Tumbuka, Shona) during the Localization Lab’s ( https://www.localizationlab.org/) hands-on workshop on localizing internet freedom tools. *### OONI Community Meeting* On 27th June 2023, we hosted the monthly OONI Community Meeting on our Slack channel (https://slack.ooni.org/) during which we briefly discussed: 1) Social media blocks in Senegal. 2) F-Droid block in China. 3) Monitoring internet censorship in Sierra Leone during the country’s 2023 elections. 4) OONI Explorer being released in 8 new languages (encouraging further localization efforts). *## Measurement coverage* In June 2023, 56,948,483 OONI Probe measurements were collected from 2,897 networks in 165 countries around the world. This information can also be found through our measurement stats on OONI Explorer (see chart on “monthly coverage worldwide”): https://explorer.ooni.org/ ~ OONI team.

1 0