January 2025 - tor-project - lists.torproject.org

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

11 May '25

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

4 3

TPA-RFC-71: Emergency email deployments, phase B
by Antoine Beaupré 26 Mar '25

26 Mar '25

Hi, So TPA has adopted this proposal, internally, to make yet another set of emergency changes to our mail system, to respond to critical issues affecting delivery and sustainability of our infrastructure. I encourage you to read the "Affected users" section and "Timeline" below. In particular, we will be experimenting with "sender rewriting" soon, which will involve mangling emails we forward around to try and fix deliverability on those. The schleuder mailing list will also move servers. Maintenance windows for those changes will be communicated separately. Thank you for your attention! PS: and no, we didn't submit this for adoption to everyone, because it was felt it was mostly technical changes that didn't warrant outside approval, let me know if that doesn't make sense, of course. -- Antoine Beaupré torproject.org system administration --- title: TPA-RFC-71: Emergency email deployments, phase B costs: staff approval: TPA affected users: all torproject.org email users deadline: 5 days, 2024-10-01 status: draft discussion: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778 --- Summary: deploy a new sender-rewriting mail forwarder ASAP, migrate mailing lists off the legacy server to a new machine, migrate the remaining Schleuder list to the Tails server, upgrade `eugeni`. Table of contents: - Background - Proposal - Actual changes - Mailman 3 upgrade - New sender-rewriting mail exchanger - Schleuder migration - Upgrade legacy mail server - Goals - Must have - Nice to have - Non-Goals - Scope - Affected users - Personas - Timeline - Optimistic timeline - Worst case scenario - Alternatives considered - References - History - Personas descriptions - Ariel, the fundraiser - Blipblop, the bot - Gary, the support guy - John, the contractor - Mallory, the director - Nancy, the fancy sysadmin - Orpheus, the developer # Background In [#41773][], we had yet another report of issues with mail delivery, particularly with email forwards, that are plaguing Gmail-backed aliases like grants@ and travel@. [#41773]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41773 This is becoming critical. It has been impeding people's capacity of using their email at work for a while, but it's been more acute since google's recent changes in email validation (see [#41399][]) as now hosts that have adopted the SPF/DKIM rules are bouncing. [#41399]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41399 On top of that, we're way behind on our buster upgrade schedule. We still have to upgrade our primary mail server, `eugeni`. The plan for that ([TPA-RFC-45][], [#41009][]) was to basically re-architecture everything. That won't happen fast enough for the LTS retirement which we have crossed two months ago (in July 2024) already. [TPA-RFC-45]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-45-mail-a… [#41009]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41009 So, in essence, our main mail server is unsupported now, and we need to fix this as soon as possible Finally, we also have problems with certain servers (e.g. `state.gov`) that seem to dislike our bespoke certificate authority (CA) which makes *receiving* mails difficult for us. # Proposal So those are the main problems to fix: - Email forwarding is broken - Email reception is unreliable over TLS for some servers - Mail server is out of date and hard to upgrade (mostly because of Mailman) ## Actual changes The proposed solution is: - **Mailman 3 upgrade** ([#40471][]) - **New sender-rewriting mail exchanger** ([#40987][]) - **Schleuder migration** - **Upgrade legacy mail server** ([#40694][]) [#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471 [#40987]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40987 [#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694 ### Mailman 3 upgrade Build a new mailing list server to host the upgraded Mailman 3 service. Move old lists over and convert them while retaining the old archives available for posterity. This includes lots of URL changes and user-visible disruption, little can be done to work around that necessary change. We'll do our best to come up with redirections and rewrite rules, but ultimately this is a disruptive change. This involves yet another authentication system being rolled out, as Mailman 3 has its own user database, just like Mailman 2. At least it's one user per site, instead of per list, so it's a slight improvement. This is issue [#40471][]. ### New sender-rewriting mail exchanger This step is carried over from [TPA-RFC-45][], mostly unchanged. [Sender Rewriting Scheme]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme [postsrsd]: https://github.com/roehling/postsrsd [postforward]: https://github.com/zoni/postforward Configure a new "mail exchanger" (MX) server with TLS certificates signed by our normal public CA (Let's Encrypt). This replaces that part of `eugeni`, will hopefully resolve issues with `state.gov` and others ([#41073][], [#41287][], [#40202][], [#33413][]). [#33413]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33413 [#40202]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40202 [#41287]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41287 [#41073]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41073 This would handle forwarding mail to other services (e.g. mailing lists) but also end-users. To work around reputation problems with forwards ([#40632][], [#41524][], [#41773][]), deploy a [Sender Rewriting Scheme][] (SRS) with [postsrsd][] (packaged in Debian, but [not in the best shape][]) and [postforward][] (not packaged in Debian, but zero-dependency Golang program). It's possible deploying [ARC][] headers with [OpenARC][], Fastmail's [authentication milter][] (which [apparently works better][]), or [rspamd's arc module][] might be sufficient as well, to be tested. [OpenARC]: https://tracker.debian.org/pkg/openarc [not in the best shape]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017361 Having it on a separate mail exchanger will make it easier to swap in and out of the infrastructure if problems would occur. The mail exchangers should also sign outgoing mail with DKIM, and *may* start doing better validation of incoming mail. [authentication milter]: https://github.com/fastmail/authentication_milter [apparently works better]: https://old.reddit.com/r/postfix/comments/17bbhd2/about_arc/k5iluvn/ [rspamd's arc module]: https://rspamd.com/doc/modules/arc.html [#41524]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41524 [#40632]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40632 [ARC]: http://arc-spec.org/ ### Schleuder migration Migrate the remaining mailing list left (the Community Council) to the Tails Shleuder server, retiring our Schleuder server entirely. This requires configuring the Tails server to accept mail for `(a)torproject.org`. Note that this may require changing the addresses of the existing Tails list to `(a)torproject.org` if Schleuder doesn't support virtual hosting (which is likely). ### Upgrade legacy mail server Once Mailman has been safely moved aside and is shown to be working correctly, upgrade Eugeni using the normal procedures. This should be a less disruptive upgrade, but is still risky because it's such an old box with lots of legacy. One key idea of this proposal is to keep the legacy mail server, `eugeni`, in place. It will continue handling the "MTA" (Mail Transfer Agent) work, which is to relay mail for other hosts, as a legacy system. The full eugeni replacement is seen as too complicated and unnecessary at this stage. The legacy server will be isolated from the rewriting forwarder so that outgoing mail is mostly unaffected by the forwarding changes. ## Goals This is not an exhaustive solution to all our email problems, [TPA-RFC-45][] is that longer-term project. ### Must have - Up to date, supported infrastructure. - Functional legacy email forwarding. ### Nice to have - Improve email forward deliverability to Gmail. ### Non-Goals - **Clean email forwarding**: email forwards *may* be mangled and rewritten to appear as coming from `(a)torproject.org` instead of the original address. This will be figured out at the implementation stage. - **Mailbox storage**: out of scope, see [TPA-RFC-45][]. It is hoped, however, that we *eventually* are able to provide such a service, as the sender-rewriting stuff might be too disruptive in the long run. - **Technical debt**: we keep the legacy mail server, `eugeni`. - **Improved monitoring**: we won't have a better view in how well we can deliver email. - **High availability**: the new servers will not add additional "single point of failures", but will not improve our availability situation (issue [#40604][]) [#40604]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40604 ## Scope This proposal affects the all inbound and outbound email services hosted under `torproject.org`. Services hosted under `torproject.net` are *not* affected. It also does *not* address directly phishing and scamming attacks ([#40596][]), but it is hoped the new mail exchanger will provide a place where it is easier to make such improvements in the future. [#40596]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40596 ## Affected users This affects all users which interact with `torproject.org` and its subdomains over email. It particularly affects all "tor-internal" users, users with LDAP accounts, or forwards under `(a)torproject.org`, as their mails will get rewritten on the way out. ### Personas Here we collect a few "personas" and try to see how the changes will affect them, largely derived from [TPA-RFC-45][], but without the alpha/beta/prod test groups. For *all* users, a common impact is that emails will be rewritten by the sender rewriting system. As mentioned above, the impact of this still remains to be clarified, but at least the hidden `Return-Path` header will be changed for bounces to go to our servers. Actual personas are in the Reference section, see [Personas descriptions][]. | Persona | Task | Impact | |---------|-------------|--------------------------------------------------------------------------| | Ariel | Fundraising | Improved incoming delivery | | Blipbot | Bot | No change | | Gary | Support | Improved incoming delivery, new moderator account on mailing list server | | John | Contractor | Improved incoming delivery | | Mallory | Director | Same as Ariel | | Nancy | Sysadmin | No change in delivery, new moderator account on mailing list server | | Orpheus | Developer | No change in delivery | [Personas descriptions]: #personas-descriptions ## Timeline ### Optimistic timeline - Late September (W39): issue raised again, proposal drafted (now) - October: - W40: proposal approved, installing new rewriting server - W41: rewriting server deployment, new mailman 3 server - W42: mailman 3 mailing list conversion tests, users required for testing - W43: mailman 2 retirement, mailman 3 in production - W44: Schleuder mailing list migration - November: - W45: `eugeni` upgrade ### Worst case scenario - Late September (W39): issue raised again, proposal drafted (now) - October: - W40: proposal approved, installing new rewriting server - W41-44: difficult rewriting server deployment - November: - W44-W48: difficult mailman 3 mailing list conversion and testing - December: - W49: Schleuder mailing list migration vetoed, Schleuder stays on `eugeni` - W50-W51: `eugeni` upgrade postponed to 2025 - January 2025: - W3: `eugeni` upgrade # Alternatives considered We decided to not just run the sender-rewriting on the legacy mail server because too many things are tangled up in that server. It is just too risky. We have also decided to not upgrade Mailman in place for the same reason: it's seen as too risky as well, because we'd first need to upgrade the Debian base system and if that fails, rolling back is too hard. # References - [discussion issue][] [discussion issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778 ## History This is the the *fifth* proposal about our email services, here are the previous ones: * [TPA-RFC-15: Email services][] (rejected, replaced with TPA-RFC-31) * [TPA-RFC-31: outsource email services][] (rejected, in favor of TPA-RFC-44 and following) * [TPA-RFC-44: Email emergency recovery, phase A][] (standard, and mostly implemented except the sender-rewriting) * [TPA-RFC-45: Mail architecture][] (still draft) [TPA-RFC-15: Email services]: policy/tpa-rfc-15-email-services [TPA-RFC-31: outsource email services]: policy/tpa-rfc-31-outsource-email [TPA-RFC-44: Email emergency recovery, phase A]: policy/tpa-rfc-44-email-emergency-recovery [TPA-RFC-45: Mail architecture]: policy/tpa-rfc-45-mail-architecture ## Personas descriptions ### Ariel, the fundraiser Ariel does a lot of mailing. From talking to fundraisers through their normal inbox to doing mass newsletters to thousands of people on CiviCRM, they get a lot done and make sure we have bread on the table at the end of the month. They're awesome and we want to make them happy. Email is absolutely mission critical for them. Sometimes email gets lost and that's a major problem. They frequently tell partners their personal Gmail account address to work around those problems. Sometimes they send individual emails through CiviCRM because it doesn't work through Gmail! Their email forwards to Google Mail and they now have an LDAP account to do email delivery. ### Blipblop, the bot Blipblop is not a real human being, it's a program that receives mails and acts on them. It can send you a list of bridges (bridgedb), or a copy of the Tor program (gettor), when requested. It has a brother bot called Nagios/Icinga who also sends unsolicited mail when things fail. There are also bots that sends email when commits get pushed to some secret git repositories. ### Gary, the support guy Gary is the ticket overlord. He eats tickets for breakfast, then files 10 more before coffee. A hundred tickets is just a normal day at the office. Tickets come in through email, RT, Discourse, Telegram, Snapchat and soon, TikTok dances. Email is absolutely mission critical, but some days he wishes there could be slightly less of it. He deals with a lot of spam, and surely something could be done about that. His mail forwards to Riseup and he reads his mail over Thunderbird and sometimes webmail. Some time after TPA-RFC_44, Gary managed to finally get an OpenPGP key setup and TPA made him a LDAP account so he can use the submission server. He has already abandoned the Riseup webmail for TPO-related email, since it cannot relay mail through the submission server. ### John, the contractor John is a freelance contractor that's really into privacy. He runs his own relays with some cools hacks on Amazon, automatically deployed with Terraform. He typically run his own infra in the cloud, but for email he just got tired of fighting and moved his stuff to Microsoft's Office 365 and Outlook. Email is important, but not absolutely mission critical. The submission server doesn't currently work because Outlook doesn't allow you to add just an SMTP server. John does have an LDAP account, however. ### Mallory, the director Mallory also does a lot of mailing. She's on about a dozen aliases and mailing lists from accounting to HR and other unfathomable things. She also deals with funders, job applicants, contractors, volunteers, and staff. Email is absolutely mission critical for her. She often fails to contact funders and critical partners because `state.gov` blocks our email -- or we block theirs! Sometimes, she gets told through LinkedIn that a job application failed, because mail bounced at Gmail. She has an LDAP account and it forwards to Gmail. She uses Apple Mail to read their mail. ### Nancy, the fancy sysadmin Nancy has all the elite skills in the world. She can configure a Postfix server with her left hand while her right hand writes the Puppet manifest for the Dovecot authentication backend. She browses her mail through a UUCP over SSH tunnel using mutt. She runs her own mail server in her basement since 1996. Email is a pain in the back and she kind of hates it, but she still believes entitled to run their own mail server. Her email is, of course, hosted on her own mail server, and she has an LDAP account. She has already reconfigured her Postfix server to relay mail through the submission servers. ### Orpheus, the developer Orpheus doesn't particular like or dislike email, but sometimes has to use it to talk to people instead of compilers. They sometimes have to talk to funders (`#grantlyfe`), external researchers, teammates or other teams, and that often happens over email. Sometimes email is used to get important things like ticket updates from GitLab or security disclosures from third parties. They have an LDAP account and it forwards to their self-hosted mail server on a OVH virtual machine. They have already reconfigured their mail server to relay mail over SSH through the jump host, to the surprise of the TPA team. Email is not mission critical, and it's kind of nice when it goes down because they can get in the zone, but it should really be working eventually. -- Antoine Beaupré torproject.org system administration -- tpa-team mailing list tpa-team(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tpa-team

2 10

sajolida's report, September 2024
by sajolida 27 Feb '25

27 Feb '25

Hi, September was again more busy than average to respect the timeline of Project 101 (Tor VPN) and Tails releases. Tor VPN ======= - I analyzed the usability test of Tor VPN 0.6.2 that I did in August. https://gitlab.torproject.org/tpo/ux/research/-/issues/69 In short, the usability of Tor VPN 0.6.2 is decent when people don't need to use a bridge, but very bad when Tor is blocked. None of the participant managed to use a bridge on their own. The main issues are unclear system status and confusing network model. Quotes: “Tor is like a bridge.“ — P5 “I'm looking for bridges that make it like if I were in Switzerland.“ — P4 “It should say: You are being blocked! With Tor you can bypass this censorship using a bridge.“ — P6 Summary of findings: https://gitlab.torproject.org/-/project/92/uploads/1fba8220a110622d852bf448… List of all issues: https://nc.torproject.net/s/fXbRYw76pTXJZym Video clips: https://nc.torproject.net/f/645757 - I created GitLab issues to document the most severe issues: Improve feedback while "Connecting" https://gitlab.torproject.org/tpo/applications/vpn/-/issues/181 Clarify connection status on all screens https://gitlab.torproject.org/tpo/applications/vpn/-/issues/182 Allow changing exit location from Configure menu https://gitlab.torproject.org/tpo/applications/vpn/-/issues/185 Improve discoverability of the list of countries https://gitlab.torproject.org/tpo/applications/vpn/-/issues/186 Clarify what can be tapped in the Bridges screen https://gitlab.torproject.org/tpo/applications/vpn/-/issues/187 Remove the need to press Enter when entering a bridge line https://gitlab.torproject.org/tpo/applications/vpn/-/issues/188 Clarify which bridge is being used (eg. after Bridge Bot) https://gitlab.torproject.org/tpo/applications/vpn/-/issues/189 Improve discoverability of the circuit view https://gitlab.torproject.org/tpo/applications/vpn/-/issues/190 Allow configuring only a single bridge https://gitlab.torproject.org/tpo/applications/vpn/-/issues/193 Rethink how the different relays are named https://gitlab.torproject.org/tpo/applications/vpn/-/issues/194 Clarify just enough about the network model https://gitlab.torproject.org/tpo/applications/vpn/-/issues/195 Don't allow changing exit location unless already connected https://gitlab.torproject.org/tpo/applications/vpn/-/issues/196 Report loss of connectivity to the Tor network https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/110 - I started brainstorming solutions to all of these issues with Duncan and the rest of the UX team. Tails ===== I wrote some documentation to help users with recent issues: - Shim SBAT verification error (#20471) https://tails.net/news/version_6.7/#sbat - Provide fsck from Welcome Screen when the file system of the Persistent Storage is corrupted (#15451) https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1586 This one was a LOT of work to figure out which data forensics path we should recommend to users and document the main ones step-by-step. -- sajolida

1 5

Anti-censorship team meeting notes, 2025-01-30
by Shelikhoo 30 Jan '25

30 Jan '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-01-30-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday,Feb 02 16:00 UTC Facilitator: meskio ^^^(See Facilitator Queue at tail) 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * snowflake-broker.azureedge.net is still working, a week after the announced shutdown date.(It still work at Jan 30) curl -s -i https://snowflake-broker.azureedge.net/amp/client/ == Discussion == == Actions == == Interesting links == * "Identifying VPN Servers through Graph-Represented Behaviors" * https://dl.acm.org/doi/10.1145/3589334.3645552 * https://dl.acm.org/doi/pdf/10.1145/3589334.3645552 * https://github.com/chenxuStep/VPNChecker == 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): 2025-01-30 Last week: - debugged problem with tor conjure PT getting invalid addresses - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - reviewed conjure merge requests - made more improvements to phantombox, the conjure test environment This week: - support conjure work - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 - maybe do some lox work dcf: 2025-01-23 Last week: - tracked status of snowflake-broker.azureedge.net after announced date of Edgio shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - helped debug reported "AMP cache rendezvous doesn't work in China" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - 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: 2024-01-30 Last week: - investigate issues on TorBrowser in Iran (tor-browser#43454) - config repositories in irc tor bot - grant writting and review Next week: - containarize rdsys Shelikhoo: 2024-01-30 Last Week: - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews Next Week/TODO: - Merge request reviews - [Test] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2025-01-30 Last week(s): - Got conjure up and running locally! (Thanks cohosh!) - uTLS implemented for conjure - moved uTLS library to ptutil - started work on ampcache Next week: - continue on alternative registration methods (ampcache, sqs) - Add decoy registration option As time allows: - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - 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? theodorsm: 2025-01-30 Last weeks: - Testing Tor Build with covert-dtls (troubleshooting becoming DTLS client with ICE and different NAT/host types). Next weeks: - Update covert-dtls to handle new DTLS extensions in recent browsers - Write instructions on how to configure covert-dtls with snowflake client - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0

Anti-censorship team meeting notes, 2025-01-23
by onyinyang 23 Jan '25

23 Jan '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-01-23-16.04.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday,January 30 16:00 UTC Facilitator: shelikhoo ^^^(See Facilitator Queue at tail) 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * BridgeStatus's Snowflake bridge test output will change after deployment of * Use gitlab circumvention setting for snowflake bridge line update * https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… * Be sure to check if any automated script is still working correctly * snowflake-broker.azureedge.net is still working, a week after the announced shutdown date. curl -s -i https://snowflake-broker.azureedge.net/amp/client/ == Discussion == == Actions == == Interesting links == == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2025-01-23 Last week: - worked on some phantombox (conjure test environment) improvements - https://gitlab.torproject.org/cohosh/phantombox/-/issues/2 - fixups to switching to local storage for snowflake badges - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - some reviews and gitlab todos This week: - asn mapping geoip feature dcf: 2025-01-23 Last week: - tracked status of snowflake-broker.azureedge.net after announced date of Edgio shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - helped debug reported "AMP cache rendezvous doesn't work in China" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - 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: 2024-01-23 Last week: - debug a segfault in country based metrics to the snowflake proxy (snowflake!482) - debug why metrics.torproject.org doesn't display distributor metrics (rdsys#235) - keep up with snowflake debian dependencies (snowflake#40410) - deploy onionsproutsbot (onionsproutsbot#66) - investigate why we distribute non working bridges (rdsys#254) - simple refactor fixes on rdsys bridge tests (rdsys!454) - review and update P146 report - triage the long queue of open issues (there are still some snowflake ones missing) Next week: - snowflake debian package Shelikhoo: 2024-01-23 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Automate bridgeline update for snowflake(https://gitlab.torproject.org/tpo/anti-censorship/connectivity-me… ) - Use assume reachable for webtunnel bridges to avoid exporting OR port(https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measure… - Update readme to include migration notice (https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/… ) - Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - [Deployment] Automate bridgeline update for snowflake onyinyang: 2025-01-23 Last week(s): - Get conjure up and running (at least locally) - WIP Conjure stuff for Project 173 Next week: - Continue on getting conjure up and running (at least locally) - implement utls for conjure - start implementation of alternative registration methods As time allows: - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - 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? theodorsm: 2025-01-22 (AFK for meeting 01-23) Last weeks: - Testing Tor Build with covert-dtls Next weeks: - Update covert-dtls to handle new DTLS extensions in recent browsers - Write instructions on how to configure covert-dtls with snowflake client - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Haidi December24 Report
by haidis＠riseup.net 22 Jan '25

22 Jan '25

Hi! Below is my December’24 report! I have many onboarding sessions with colleagues from different teams. Some sessions for contract process, configuring Tor needed application and setup the user’s name and passwords, training some applications. I have become familiar with the projects, documents and internal policies of Tor Project. In December, I resolved 7 tickets: * On Telegram (@TorProjectSupportBot) - 7; * On RT (frontdesk@tpo) - 0; Translated censorship-circumvention text module and article to Persian[1] [1] https://gitlab.torproject.org/tpo/community/support/-/issues/40177 This is the pad link for my report : https://pad.riseup.net/p/Haidi-Report-December2024-keep Best, Haidi

1 0

OONI Monthly Report: December 2024
by Maria Xynou 16 Jan '25

16 Jan '25

Hello, This email shares OONI's monthly report for December 2024. *# OONI Monthly Report: December 2024* Throughout December 2024, the OONI team’s work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. *## Published new research report on independent media censorship in Russia* On 9th December 2024, in collaboration with RKS Global (https://rks.global/) we co-published a new research report on the systematic suppression of independent media in Russia. Our report is available in both: * English: https://ooni.org/post/2024-russia-report/ * Russian: https://ooni.org/ru/post/2024-russia-report/ RKS Global published a summary of the findings (along with recommendations) in both: * English: https://rks.global/en/research/chronicles/ * Russian: https://rks.global/research/chronicles/ Our findings are based on OONI data analysis and interviews with 15 independent Russian news media organizations. Our analysis of OONI data from Russia shows pervasive levels of news media censorship. We automatically confirmed the blocking of 279 news media domains -- including foreign and numerous independent Russian news media websites. Most blocks are implemented by means of TLS interference. As we observe the same pattern of TLS level interference in the vast majority of measurements collected from numerous networks during the same date range, OONI data suggests that these news media blocks are likely centrally managed by Roskomnadzor through the use of TSPU. Through interviews, independent Russian media organizations shared the following main challenges: * Financial and security challenges * Reduced ability to cover events in Russia * Partial loss of Russian audiences * Growing self-censorship * Closure of media organizations Despite the challenges, independent Russian media organizations remain resilient. The increased threats strengthened solidarity and cooperation among media outlets, and they have demonstrated a high level of adaptation to circumvent blocks and reach their audiences. Yet, international support is needed to strengthen the fight for press freedom in Russia. Our report received the following coverage: https://therecord.media/russia-doubles-blocking-access-independent-media-si… https://roskomsvoboda.org/ru/post/russia-censorship-pressure-independent-me… Our report was also shared widely on Telegram channels by Russian communities: https://t.me/roskomsvoboda/13149 https://t.me/ru_tech_talk/624 https://t.me/cybersarik/1428 https://t.me/airfield1972/3746 https://t.me/chertamedia/6974 https://t.me/zatelecom/29370 *## Presenting thematic censorship findings on OONI Explorer* Notably, we have completed the core development work for the new OONI Explorer thematic censorship findings pages and we have started internal testing and polishing of the pages in preparation for the upcoming launch. Based on internal testing of the new pages, we discussed and reviewed the initial feedback, and created additional mockups to improve the UX for several sections (“Reports” and “Findings”) of these new pages. We also worked towards implementing several other improvements based on feedback that emerged from internal testing in preparation for the launch. *## Automating censorship detection and characterization based on OONI measurements* In December 2024, we made steady progress on getting the new pipeline deployed into production. As part of this, we decided to switch from temporal to airflow for orchestration. Eventually, airflow will also be useful for replacing the scheduling of all other periodic tasks (which currently are done through systemd timers). We added support for deploying airflow here: https://github.com/ooni/devops/pull/132 *## Activities supported by OTF FOSS### OONI Explorer* We fixed a bug that was impacting the search feature on the OONI Explorer country pages, preventing users from searching in languages other than English: https://github.com/ooni/explorer/issues/975 *### OONI Probe Engine* In the days leading up to the 2nd Open Measurement Gathering in Atlanta, we held an OONI developer meeting to brainstorm and discuss efforts around simplifying the OONI Probe measurement engine. The goals of this work are: * Simplify or eliminate the forks of go/crypto and go/http * Make it possible to not have to release engine versions so often by externalize the geoIP dependencies outside of the engine * Expose an API that’s more “useful” to mobile developers * Merge OONI Run v2 with richer testing input related work * Solve the integration of rust libraries (such as arti) * Reduce the overall OONI Probe engine codebase * Reduce the number of ways we write OONI Probe experiments As part of this, we outlined the work necessary to separate pieces of the engine that are related to speaking to our backend services from those that are related to running experiments. *### OONI Probe Mobile* We shipped OONI Probe Android 4.0.2 which fixed a bug that involved performance tests being included in autoruns ( https://github.com/ooni/probe/issues/2831) As part of our ongoing work on our multi-platform project that aims to refactor the OONI Probe mobile applications, we fixed a bug where the app would get “stuck” after a manual upload ( https://github.com/ooni/probe-multiplatform/issues/334) and we made some small UX tweaks to ensure consistency between the current and future versions of the OONI probe applications ( https://github.com/ooni/probe-multiplatform/issues/323, https://github.com/ooni/probe-multiplatform/issues/321) Here is a list of all issues closed in December 2024: https://github.com/ooni/probe-multiplatform/issues?q=is%3Aissue+is%3Aclosed… *### OONI Backend Maintenance & DevOps* We handled an issue related to incorrect handling of X-Forwarded-For headers in the api.ooni.org endpoint ( https://github.com/ooni/backend/issues/901) This was causing issues to users that were using particular browser extensions when attempting to access certain pages on OONI Explorer. *## Hiring process for a backend developer* We completed the hiring process for a backend developer ( https://ooni.org/post/2024-job-opening-ooni-backend-developer/) and we made offers to 2 backend developers. *## Launched News Media Scan app with Deutsche Welle on iOS* In collaboration with Deutsche Welle (DW), we developed an OONI Probe-based app (“News Media Scan”) designed to measure the blocking of news media websites. Similarly to OONI Probe, News Media Scan app test results are published by OONI as open data in real-time. We previously launched the Android version of the News Media Scan app in October 2023 (https://play.google.com/store/apps/details?id=com.dw.ooniprobe ). In December 2024, we launched the News Media Scan app on iOS: https://apps.apple.com/us/app/news-media-scan/id6738992797 This is our first multi-platform application in production. *## Test list updates* We updated the Global test list to include targets related to measuring the DNSSEC root key rollover (https://github.com/citizenlab/test-lists/pull/1883) and we reviewed and merged several pull requests contributed by community members ( https://github.com/citizenlab/test-lists/pulls?q=is%3Apr+is%3Aclosed+) *## Research and data analysis for upcoming research reports* We worked on the data analysis required for an upcoming research report on internet censorship in Bangladesh: https://github.com/ooni/backend/issues/848 We also coordinated with our partner, Miaan Group, who contributed more websites to the Iranian and Global test lists: https://github.com/citizenlab/test-lists/pull/1884 *## Community use of OONI data### Internet shutdown tracking system developed by ISOC Pulse Research Fellow* An ISOC Pulse Research Fellow has developed a new Internet shutdown tracking system that retrieves data from several sources, including OONI, IODA, Cloudflare Radar, and the Google Transparency Report. Learn more here: https://pulse.internetsociety.org/blog/developing-a-holistic-approach-to-me… *## Community-led presentations### Presentation on web censorship in France* On 4th December 2024, community members Etienne Maynier and taziden presented their research on internet censorship in France, through which they presented results from their analysis of OONI data. Information about this presentation is available here: https://censxres.fr/blog/pr%C3%A9sentation-sur-la-censure-le-4-d%C3%A9cembr… *## Community activities### SplinterCon Berlin 2024* Between 9th to 11th December 2024, OONI’s Elizaveta traveled to Berlin, Germany, to attend SplinterCon (https://splintercon.net/berlin/) As part of her participation, Elizaveta presented OONI’s latest report on media censorship in Russia (https://ooni.org/post/2024-russia-report/) and participated in multiple discussions about censorship in the region. *### 2nd Open Measurement Gathering* Between 10th-12th December 2024, OONI’s Arturo, Mehul, Jessie, and Maria attended the 2nd Open Measurement Gathering (OMG) at Georgia Tech in Atlanta, USA (https://x.com/OpenObservatory/status/1869829395701215334) This event brought together internet measurement projects (OONI, IODA, Censored Planet, M-Lab) to exchange skills and knowledge. We also had the opportunity to have guest participants from Sinar Project ( https://sinarproject.org/) Access Now (https://www.accessnow.org/) and internet measurement expert, Jim Cowie. As part of our participation, we: * Presented OONI highlights from 2024 and OONI plans for 2025 * Shared OONI data workflows based on case studies from Cuba * Presented OONI’s methodology for measuring throttling * Presented OONI’s latest data processing pipeline (OONI Pipeline v5) to collect feedback from internet measurement experts * Facilitated a session comparing the pipelines of different internet measurement projects * Facilitated a session on anomaly detection and shared OONI’s work on building a Social Media Censorship Alert System * Facilitated a session on GeoIP/AS database consolidation and discussion of next steps * Shared OONI’s partnership experience and lessons learned during a session on “partner structures” In the days leading up to the Open Measurement Gathering, we had a team “hackathon” on work related to the OONI backend and measurement engine, which helped with improving our related roadmaps and plans. On 13th December 2024, following the Open Measurement Gathering, we worked out of Georgia Tech to brainstorm on and discuss some of our upcoming projects. *## Measurement coverage* In December 2024, 47,018,051 OONI Probe measurements were collected from 2,742 networks in 169 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

OONI Monthly Report: November 2024
by Maria Xynou 16 Jan '25

16 Jan '25

Hello, This email shares OONI's monthly report for November 2024. *# OONI Monthly Report: November 2024* Throughout November 2024, the OONI team’s work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. *## Report on the temporary blocking of social media in Mauritius* In November 2024, we published a new report on the blocking of social media in Mauritius ahead of the country’s 2024 general election. This report was published on the OONI Explorer Censorship Findings platform: https://explorer.ooni.org/findings/73729350400 As part of this short report, we documented the blocking of Facebook, Instagram, TikTok, YouTube, Twitter/X, and Linkedin in Mauritius on 1st November 2024 based on OONI data. As the blocks were lifted the next day (2nd November 2024), we updated the report to include OONI data on the unblocking of social media platforms in Mauritius. *## Expanding measurement methodologies* As part of our ongoing efforts to expand and improve upon our measurement methodologies, we: * Made improvements to our DNS measurement capabilities by simplifying the DNSCheck list to focus on key provider endpoints ( https://github.com/ooni/probe-cli/pull/1656) * Enhanced our ECH testing capabilities by switching to cloudflare-ech.com as the target and adding support for additional handshake configurations ( https://github.com/ooni/probe-cli/pull/1658) *## Automating censorship detection and characterization based on OONI measurements* In November 2024, we made significant progress on the OONI Pipeline v5, preparing a new release candidate (https://github.com/ooni/data/pull/99) and working on its production deployment ( https://github.com/ooni/devops/pull/112) As part of this work, we added support for parsing ECH-related fields from TLS handshakes and OONI Run link IDs (https://github.com/ooni/data/pull/100) We also improved our infrastructure and documentation by consolidating our data-related hosts to streamline our research infrastructure ( https://github.com/ooni/devops/issues/109) *## Activities supported by OTF FOSS### OONI Probe Engine* In November 2024, we shipped OONI Probe 3.24.0: https://github.com/ooni/probe/issues/2813 The release includes: * Changes to enable the ECH Check experiment and reduce DNS Check experiment inputs * Changes to enable system resolver for the DNS Check experiment * Some improvements in the OpenVPN experiment * Bug fixes for oonimkall and the Psiphon tunnel *### OONI Probe Mobile* We continued to make significant progress on our multi-platform project that aims to refactor the OONI Probe mobile applications. While our focus was on testing and QA specifically for the News Media Scap application, the majority of bugs found and fixed also benefit the OONI Probe applications because they share 80-90% of the code. Some highlights include: * We fixed a crash and addressed some performance issues: https://github.com/ooni/probe-multiplatform/issues/261 * We improved the loading state of the measurement detail views: https://github.com/ooni/probe-multiplatform/issues/276 * We improved the robustness of retrying failed uploads: https://github.com/ooni/probe-multiplatform/issues/265 Here is a list of all issues closed in November 2024: https://github.com/ooni/probe-multiplatform/issues?q=is%3Aissue+is%3Aclosed… *### OONI Run* Following the launch of OONI Run v2 in October 2024 ( https://ooni.org/post/2024-launch-ooni-run-v2/) we prioritized monitoring the performance of the recently released application throughout November 2024 to ensure there were no notable measurement drops or other issues. We also responded to questions and feedback from the community. *### OONI Explorer and general frontend* As part of our efforts to advance the OONI Probe multi-platform project, we created and improved dedicated mobile views of OONI Explorer measurement detail pages that can be consumed by the new mobile applications. Using mobile views for the measurement details view helped us to improve our development speed for this particular feature. This work is documented through the following tickets: https://github.com/ooni/explorer/issues/962 https://github.com/ooni/explorer/issues/960 https://github.com/ooni/explorer/issues/961 As part of our efforts to consolidate frontend deployment patterns, we ensured that ooni.org was deployable on Vercel: https://github.com/ooni/ooni.org/issues/1630 *### OONI Backend Maintenance & DevOps* In addition to the typical long-running background tasks to maintain our backend infrastructure, we: * Helped the mobile team investigate an issue that was happening with the new multi- platform applications: https://github.com/ooni/probe-multiplatform/issues/257 * Investigated and addressed an issue with our fallback DNS settings that was impacting the measurement API endpoints and resulted in errors on OONI Explorer: https://github.com/ooni/sysadmin/pull/521 * Monitored and responded to an incident where a bad actor was spoofing our IP address, likely in an attempt to have one of our servers taken down. This was perpetrated by the same people who were attempting something similar with Tor: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41840 * Added API documentation for OONI Run and the OONI Findings API: https://github.com/ooni/docs/pull/7 * Added a nginx-based reverse proxy to improve our backend service architecture: https://github.com/ooni/backend/pull/894 *## Hiring process for a backend developer* As part of our ongoing search to hire another backend developer for OONI ( https://ooni.org/post/2024-job-opening-ooni-backend-developer/) we continued to review incoming applications, follow up with candidates, and interview shortlisted candidates. *## OONI partner workshop series* In support of our global network of partners (https://ooni.org/partners) we facilitated an online workshop series with the goal of sharing skills and knowledge for censorship measurement research. In November 2024, we facilitated 2 workshops for our partners. Specifically, OONI’s Elizaveta facilitated the following workshops for our partners: * OONI Run v2: Features of the new release (7th November 2024) * Using the Test Lists Editor (20th November 2024) *## Published PDFs for Kazakhstan research report* Thanks to the design provided by Ura Design, we published PDFs for the English and Russian versions of our recent research report on internet censorship in Kazakhstan. The PDFs of the research report are available in: * English: https://ooni.org/documents/OONI-Report-Kazakhstan-2024-English.pdf * Russian: https://ooni.org/documents/OONI-Report-Kazakhstan-2024-Russian.pdf *## Miaan Group podcast* In early November 2024, OONI’s Maria provided an interview to our partner, Miaan Group (https://ooni.org/partners/miaan/) for their podcast. As part of this podcast, Maria shared information about OONI tools with Iranian communities. *## Collaboration with agency to boost OONI’s social media presence* We continued to collaborate with Latte (https://www.lattecreative.com/en/) an agency in Rome which supports organizations (including many nonprofit organizations, such as Amnesty International and Greenpeace) on improving their communication, branding, advocacy, and fundraising efforts. We collaborated with Latte on using Google ads to promote OONI’s work, as well as on creating a digital strategy to improve OONI’s communication and social media presence. *## Rapid response### Blocking of Telegram in Kenya during KCSE 2024 exams* On 7th November 2024, Kenya blocked access to Telegram amid the KCSE 2024 exams. We responded by sharing relevant OONI data through social media channels: https://x.com/OpenObservatory/status/1855021971672907842 We also shared OONI data on the blocking of Telegram in Kenya with the #KeepItOn advocacy community. It’s worth noting that Kenya also blocked access to Telegram last year, during the KCSE 2023 exams, which we documented in the following report: https://explorer.ooni.org/findings/228466228201 *## Community use of OONI data### Launch of a project on website censorship in France* On 15th November 2024, community members Etienne Maynier and taziden launched a new project which documents website censorship in France through legal and technical analysis. The technical analysis of their research project makes use of OONI data to document website blocks in France, and they share an OONI Run v2 link to encourage further testing. Learn more here: https://censxres.fr/ *### ISOC Pulse report on social media blocks in Mauritius* Internet Society (ISOC) published a report documenting the social media blocks in Mauritius ahead of the country’s 2024 elections. As part of this report, they cite OONI data, include an OONI Explorer chart illustrating the blocks, and encourage readers in Mauritius to contribute more measurements through the use of OONI Probe. Their report is available here: https://pulse.internetsociety.org/shutdowns/mauritius-orders-blocking-of-so… *### ISOC Pulse report on internet outages and blocks in Mozambique* Internet Society (ISOC) published a report documenting mobile internet outages and social media blocks in Mozambique amid protests. As part of this report, they cite OONI data, include OONI Explorer charts, and provide a custom OONI Run v2 link to encourage further testing. Their report is available here: https://pulse.internetsociety.org/shutdowns/mobile-internet-suspended-in-mo… *### Human Rights Watch article on internet restrictions in Mozambique* Human Rights Watch published an article on the post-election internet restrictions in Mozambique, citing OONI data. Their article is available here: https://www.hrw.org/news/2024/11/06/mozambique-post-election-internet-restr… *## Community activities### IETF 121 Dublin* Between 2nd to 5th November 2024, OONI’s Arturo attended the IETF 121 in Dublin (https://www.ietf.org/live/ietf121-plenary/) As part of his participation, Arturo attended an event organized by the Public Interest Working Group. He engaged in conversations around standards and how work can be done to orient them more in the public interest. During the IETF he connected with people working on Encrypted Client Hello and discussed some of the upcoming work on anonymous credentials which are being standardized as part of BBS. Finally, it was an opportunity to meet and engage industry players who are working on topics that have an impact on digital rights. *### OONI training session at Internet Shutdown training for journalists, activists and election observers in Tanzania* On 5th November 2024, as part of the Internet Shutdown training – organized by our partners, Zaina Foundation ( https://ooni.org/partners/zaina-foundation/) and Access Now ( https://ooni.org/partners/access-now/) – for journalists, activists and election observers in Tanzania, OONI’s Elizaveta facilitated a training session on how to use OONI Probe and OONI Explorer to investigate internet censorship in Tanzania. *### OONI presentation for Masters students at the Hasso Plattner Institute (HPI)* On 6th November 2024, OONI’s Arturo presented OONI tools and methods to computer science Masters students at the Hasso Plattner Institute (HPI) in Berlin, Germany (https://hpi.de/en/) During this lesson, he provided an overview of methods for measuring the internet to map information controls. *### Falling Walls Science Summit 2024* On 7th November 2024, OONI’s Arturo participated as a panelist at the Falling Walls Science Summit in Berlin (https://falling-walls.com/) His panel discussed the topic of Digital Walls and how to overcome them. The fellow panelists were Peter Limbourg (General Director of DW), Patryk Pawlak (European University Institute), and Sabine Frank (Google). Following the panel, Arturo was interviewed by DW, who published the interview here: https://www.dw.com/en/how-to-circumvent-online-censorship/video-70781938 *### OONI presentation at the Berkman Klein Center for Internet and Society at Harvard University* On 19th November 2024, OONI’s Maria presented OONI tools and methods to the Berkman Klein Center community at Harvard University ( https://cyber.harvard.edu/) as part of a session on “How to investigate internet censorship with OONI tools and data”. *### State of the Onion 2024* On 20th November 2024, OONI’s Arturo presented OONI highlights from 2024 and upcoming plans for 2025 as part of the Tor Project’s annual State on the Onion Community event ( https://blog.torproject.org/event/2024-state-of-the-onion/) Watch the presentation here: https://www.youtube.com/live/EODNtLqD7f8 *### OONI Community Meeting* On 26th November 2024, we hosted the monthly OONI Community Meeting on our Slack channel (https://slack.ooni.org/) As part of this meeting, we discussed new features of the OONI Run v2 release. We also discussed how existing OONI data can be used to explore different kinds of censorship, such as geo-blocking and server-side blocking. *## Measurement coverage* In November 2024, 48,385,672 OONI Probe measurements were collected from 2,839 networks in 170 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

OONI Monthly Report: October 2024
by Maria Xynou 16 Jan '25

16 Jan '25

Hello, This email shares OONI's monthly report for October 2024. *# OONI Monthly Report: October 2024* Throughout October 2024, the OONI team’s work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. *## Launched OONI Run v2* In October 2024, we launched OONI Run v2: the next generation version of OONI Run (https://run.ooni.org/) Since 2017, OONI Run has supported community-driven efforts aimed at coordinating the testing of website blocks -- particularly during political events which triggered censorship events. With the launch of OONI Run v2, we address key community feedback (identified through an extensive usability study). We published a blog post which shares detailed information, as well as a step-by-step guide (with screenshots) for using OONI Run v2: https://ooni.org/post/2024-launch-ooni-run-v2/ OONI Run v2 (https://run.ooni.org/) is a major revamp, enabling you to dynamically coordinate censorship testing with OONI Probe users around the world. With OONI Run v2: * Create a (short!) link for the websites you want to measure for censorship * Share that link with OONI Probe users * Update your OONI Run link anytime if you want to add/change URLs (your community of testers will get updates automatically!) * Automated testing is supported (for you and your community) * Find your OONI Run v2 measurements on OONI Explorer ( https://explorer.ooni.org/) as open data in real-time (based on the OONI Run link ID) OONI Run v2 is currently only supported on Android. Please update to the latest OONI Probe Android version (4.0.0) to start using OONI Run v2: https://play.google.com/store/apps/details?id=org.openobservatory.ooniprobe With the launch of OONI Run v2, we also introduced UI improvements to OONI Probe Android: https://ooni.org/post/2024-launch-ooni-run-v2/#ui-changes-to-ooni-probe-and… We thank the OONI community for their invaluable feedback, which informed the design of OONI Run v2! *## Updated OONI Data Policy* In October 2024, we updated the OONI Data Policy to account for changes introduced with the launch of OONI Run v2. The edits to the OONI Data Policy are available through this pull request: https://github.com/ooni/ooni.org/pull/1601 The updated OONI Data Policy is available here: https://ooni.org/about/data-policy *## Published animation about the OONI Partner Gathering 2024* In May 2024, we had the opportunity to host the OONI Partner Gathering 2024: a two-day event in Kuala Lumpur, Malaysia, where we brought our partners from Asia and the Middle East together to exchange skills and knowledge on internet censorship research ( https://ooni.org/post/2024-ooni-partner-gathering-report/) In October 2024, we published a new animation about the OONI Partner Gathering, which is available here: https://ooni.org/post/2024-ooni-partner-gathering-animation/ This animation provides a glimpse into the event, highlighting the importance of community participation in censorship measurement research. We thank Robotina (https://www.robotina.it/) for collaborating with us on the creation of this animation. We also thank the Ford Foundation and Luminate for supporting the OONI Partner Gathering 2024, as well as our partners for making the event an important experience through their participation. *## Published OONI Community Interview with Chido Musodza from Localization Lab* In October 2024, we published a new OONI Community Interview with Chido Musodza, Program Associate, Community Engagement at Localization Lab ( https://www.localizationlab.org/) You can watch Chido’s interview and learn about her work here: https://ooni.org/post/2024-interview-with-chido-musodza/ Through the OONI Community Interview series, we aim to share the amazing work of our partners, highlighting the different ways through which they make use of OONI tools and data. You can find more OONI Community Interviews through our YouTube channel: https://www.youtube.com/watch?v=zrclQ2QZjVo&list=PL1sH9kYR-16nWkDJwY-NAaMbr… *## Presenting thematic censorship findings on OONI Explorer* In October 2024, we focused on developing the new thematic censorship findings pages for OONI Explorer. These pages will focus on OONI measurements pertaining to News Media ( https://github.com/ooni/explorer/issues/940) Social Media ( https://github.com/ooni/explorer/issues/939) and Circumvention Tools ( https://github.com/ooni/explorer/issues/941) and will offer users a way to explore OONI data focused on these specific themes. Notably, we completed the core development work necessary to unblock our internal testing and polishing of the pages prior to the upcoming launch. We made significant improvements to our findings API to enhance censorship event analysis. Specifically, we: * Added support for filtering by theme, domains, country codes and ASNs ( https://github.com/ooni/backend/pull/890) * Implemented support for storing and filtering findings by theme ( https://github.com/ooni/backend/issues/889) * Added the ability to filter by domain name in the findings endpoints ( https://github.com/ooni/backend/issues/881) These API improvements make it significantly easier for researchers and analysts to identify and investigate potential censorship events across different regions and themes. *## Automating censorship detection and characterization based on OONI measurements* In October 2024, we made significant progress in improving our censorship detection capabilities and data processing pipeline infrastructure. Specifically, we expanded our blocking fingerprint database by: * Adding new Indonesian fingerprints that were reported through our community channels (https://github.com/ooni/blocking-fingerprints/pull/19) * Incorporating the piracyshield blockpage fingerprint ( https://github.com/ooni/blocking-fingerprints/pull/18) These additions enhance our ability to automatically identify and categorize different types of internet censorship across various regions. We continued working towards the deployment and optimization of the OONI Pipeline v5 by: * Setting up production deployment infrastructure through ansible, improving our ability to consistently deploy and manage the pipeline ( https://github.com/ooni/devops/pull/105) * Initiating the reprocessing of all 2024 data on data.ooni.org following our schema improvements (https://github.com/ooni/data/issues/90) * Moving critical infrastructure components from ooni/sysadmin to ooni/devops, making our deployment process more streamlined and maintainable. *## Activities supported by OTF FOSS### OONI Probe Engine* In October 2024, we addressed an issue where measurements could not be run if the Psiphon proxy was used (https://github.com/ooni/probe/issues/2810) We also started working towards shipping OONI Probe 3.24.0 ( https://github.com/ooni/probe/issues/2813) *### OONI Probe Mobile#### Released OONI Probe Android 4.0.0 with support for OONI Run v2* Notably, we released OONI Probe Android 4.0.0 with support for OONI Run v2: https://github.com/ooni/probe-android/releases/tag/v4.0.0 Specifically, the OONI Probe Android 4.0.0 includes the following important changes: * Next generation of OONI Run - OONI Run v2! * Updated UI of the cards displayed on the dashboard * Test settings for individual tests on each card * Changes to the "Run" button to allow users to enable/disable specific tests, including both OONI Probe tests and installed OONI Run links Further details about the UI improvements introduced to OONI Probe Android are available here: https://ooni.org/post/2024-launch-ooni-run-v2/#ui-changes-to-ooni-probe-and… *#### Multiplatform project* We continued to make progress on our multi-platform project that aims to refactor the OONI Probe mobile app. We continued iterating on the News Media Scan iOS app by ensuring the UI matches the Android app ( https://github.com/ooni/probe-multiplatform/issues/122) We also began our internal QA for the News Media Scan app, as well as for the OONI Probe application. We worked on many details necessary to get us closer to launching the re-architected OONI Probe applications. These included: * Completing the onboarding flow: https://github.com/ooni/probe-multiplatform/issues/156 * Adding support for automated testing: https://github.com/ooni/probe-multiplatform/pull/150 * Ensuring all proper icons are used: https://github.com/ooni/probe-multiplatform/issues/161 * Ensuring the app is usable in landscape orientation: https://github.com/ooni/probe-multiplatform/issues/196 * Fixing some issues that appeared when the font was enlarged: https://github.com/ooni/probe-multiplatform/issues/132 Here is a list of all issues closed in October 2024: https://github.com/ooni/probe-multiplatform/issues?q=is%3Aissue+is%3Aclosed… *### OONI Run* Throughout October 2024, we continued with our preparations for the launch of OONI Run v2 on Android. We first released the OONI Run v2-enabled version of OONI Probe to our open testing or “beta” channel on the Google Play store (https://github.com/ooni/probe/issues/2803) We then monitored the measurement volume for a period of several weeks, and compared it to a previous beta release. This helped increase our confidence that we would not ship any bugs that could impact overall measurement volume. After this additional testing and monitoring we proceeded with the launch of OONI Run v2. *### OONI Backend Maintenance & DevOps* In addition to the regular maintenance and monitoring of our infrastructure, specific tasks that we worked on this month include the following: * We made progress on refactoring our measurements service to adhere to our current standards/patterns for development: https://github.com/ooni/backend/issues/877 * We took steps to set up a new primary test server and aimed to ensure it replicates production as close as possible: https://github.com/ooni/devops/issues/110 * We worked on reducing the sizes of our machines to be more cost effective: https://github.com/ooni/devops/pull/107 * We implemented log rotation for docker files after 100MB to prevent disk space issues: https://github.com/ooni/devops/pull/108 Overall, thanks to the various improvements to our infrastructure deployment, we were able to significantly reduce cloud costs by a factor of 2. We aim to continue these improvements as we move forward. *## Published updated backend developer job opening* As part of our ongoing search (which started in June 2024) to hire another backend developer for OONI, we updated our existing backend developer job opening and re-published it in October 2024 ( https://ooni.org/post/2024-job-opening-ooni-backend-developer/) This resulted in receiving many more strong applications from developers around the world. We therefore allocated time towards reviewing new applications, following up with candidates, and interviewing shortlisted candidates. *## OONI partner workshop series* In support of our global network of partners (https://ooni.org/partners) we initiated an online workshop series with the goal of sharing skills and knowledge for censorship measurement research. In October 2024, we facilitated 2 workshops for our partners. Specifically, OONI’s Elizaveta facilitated the following workshops for our partners: * Introduction to Internet Censorship (9th October 2024) * Network Measurement: What exactly are we measuring and how can one contribute? (17th October 2024) *## Updated our research report on internet censorship in Kazakhstan* Based on community feedback, we made some minor edits to the TLS MITM section of the research report that we previously published on internet censorship in Kazakhstan (https://ooni.org/post/2024-kazakhstan-report/) We applied these edits to both versions of our report in: * English: https://github.com/ooni/ooni.org/pull/1615 * Russian: https://github.com/ooni/ooni.org/pull/1616 *## Test list updates* In October 2024, we reviewed and merged several community contributions adding news media websites to the Hong Kong test list: https://github.com/citizenlab/test-lists/pull/1826/ https://github.com/citizenlab/test-lists/pull/1828 In preparation for Georgia’s 2024 elections, we merged several contributions to the Georgian test list to encourage the testing of news media websites covering the elections: https://github.com/citizenlab/test-lists/pull/1837 https://github.com/citizenlab/test-lists/pull/1838 https://github.com/citizenlab/test-lists/pull/1851 https://github.com/citizenlab/test-lists/pull/1849 https://github.com/citizenlab/test-lists/pull/1847 *## Rapid response### Blocking of Twitter/X in Azerbaijan* On 8th October 2024, Azerbaijan blocked access to Twitter/X. On the same day, we responded by sharing relevant OONI data through social media channels: https://x.com/OpenObservatory/status/1843812546765267382 We also shared OONI data on the blocking of Twitter/X in Azerbaijan with advocacy groups. *### Blocking of Discord in Russia and Turkiye* On 8th October 2024, both Russia and Turkiye started blocking access to Discord. On the same day, we responded by sharing relevant OONI data through social media channels: https://x.com/OpenObservatory/status/1843815747094753847 *## Community use of OONI data### iMAP 2024 reports on internet censorship in 9 Asian countries* On 22nd October 2024, our long-term partner, Sinar Project ( https://ooni.org/partners/sinar-project/) in collaboration with their Internet Monitoring Action Project (iMAP) partners, launched the iMAP 2024 State of Internet Censorship Report covering 9 countries: Cambodia, Hong Kong (China), India, Indonesia, Malaysia, Myanmar, Philippines, Thailand, and Vietnam. All of these research reports are based on the analysis of OONI data. All iMAP 2024 reports are available here: https://imap.sinarproject.org/reports/2024 Specifically, the iMAP 2024 reports document internet censorship (based on OONI data) in the following countries: * Cambodia: https://imap.sinarproject.org/reports/2024/imap-cambodia-2024-internet-cens… * Hong Kong (China): https://imap.sinarproject.org/reports/2024/imap-hong-kong-china-2024-intern… * India: https://imap.sinarproject.org/reports/2024/imap-india-2024-internet-censors… * Indonesia: https://imap.sinarproject.org/reports/2024/imap-indonesia-2024-internet-cen… * Malaysia: https://imap.sinarproject.org/reports/2024/imap-malaysia-2024-internet-cens… * Myanmar: https://imap.sinarproject.org/reports/2024/imap-myanmar-2024-internet-censo… * Philippines: https://imap.sinarproject.org/reports/2024/imap-philippines-2024-internet-c… * Thailand: https://imap.sinarproject.org/reports/2024/imap-thailand-2024-internet-cens… * Vietnam: https://imap.sinarproject.org/reports/2024/imap-vietnam-2024-internet-censo… *### Freedom on the Net 2024 reports* Freedom House published their annual Freedom on the Net report ( https://freedomhouse.org/report/freedom-net/2024/struggle-trust-online) which includes numerous country reports ( https://freedomhouse.org/countries/freedom-net/scores) This year, OONI data was cited in 35 (out of 72) Freedom on the Net 2024 reports. Specifically, OONI data is cited in the following Freedom on the Net country reports: * Azerbaijan: https://freedomhouse.org/country/azerbaijan/freedom-net/2024 * Bangladesh: https://freedomhouse.org/country/bangladesh/freedom-net/2024 * Belarus: https://freedomhouse.org/country/belarus/freedom-net/2024 * Brazil: https://freedomhouse.org/country/brazil/freedom-net/2024 * Cambodia: https://freedomhouse.org/country/cambodia/freedom-net/2024 * Cuba: https://freedomhouse.org/country/cuba/freedom-net/2024 * Egypt: https://freedomhouse.org/country/egypt/freedom-net/2024 * Ethiopia: https://freedomhouse.org/country/ethiopia/freedom-net/2024 * India: https://freedomhouse.org/country/india/freedom-net/2024 * Iran: https://freedomhouse.org/country/iran/freedom-net/2024 * Italy: https://freedomhouse.org/country/italy/freedom-net/2024 * Jordan: https://freedomhouse.org/country/jordan/freedom-net/2024 * Kenya: https://freedomhouse.org/country/kenya/freedom-net/2024 * Lebanon: https://freedomhouse.org/country/lebanon/freedom-net/2024 * Libya: https://freedomhouse.org/country/libya/freedom-net/2024 * Malaysia: https://freedomhouse.org/country/malaysia/freedom-net/2024 * Mexico: https://freedomhouse.org/country/mexico/freedom-net/2024 * Myanmar: https://freedomhouse.org/country/myanmar/freedom-net/2024 * Nigeria: https://freedomhouse.org/country/nigeria/freedom-net/2024 * Pakistan: https://freedomhouse.org/country/pakistan/freedom-net/2024 * Russia: https://freedomhouse.org/country/russia/freedom-net/2024 * Rwanda: https://freedomhouse.org/country/rwanda/freedom-net/2024 * Saudi Arabia: https://freedomhouse.org/country/saudi-arabia/freedom-net/2024 * Sri Lanka: https://freedomhouse.org/country/sri-lanka/freedom-net/2024 * Sudan: https://freedomhouse.org/country/sudan/freedom-net/2024 * Thailand: https://freedomhouse.org/country/thailand/freedom-net/2024 * Tunis: https://freedomhouse.org/country/tunisia/freedom-net/2024 * Turkey: https://freedomhouse.org/country/turkey/freedom-net/2024 * Uganda: https://freedomhouse.org/country/uganda/freedom-net/2024 * UAE: https://freedomhouse.org/country/united-arab-emirates/freedom-net/2024 * UK: https://freedomhouse.org/country/united-kingdom/freedom-net/2024 * Uzbekistan: https://freedomhouse.org/country/uzbekistan/freedom-net/2024 * Venezuela: https://freedomhouse.org/country/venezuela/freedom-net/2024 * Zambia: https://freedomhouse.org/country/zambia/freedom-net/2024 * Zimbabwe: https://freedomhouse.org/country/zimbabwe/freedom-net/2024 *### Report on internet health in Cuba* In October 2024, community members published a report on internet health in Cuba, which makes use of OONI data: https://guardianesdigitales.blogspot.com/2024/10/informe-6-sobre-la-salud-d… As part of this report, they used OONI Probe to collect measurements and they used OONI Explorer to analyze OONI data and generate charts to document blocks in Cuba. They have also published several other reports over the past year, documenting internet censorship in Cuba based on OONI data: https://guardianesdigitales.blogspot.com/2024/07/informe-5-sobre-la-salud-d… https://guardianesdigitales.blogspot.com/2024/04/informe-4-sobre-la-salud-d… https://guardianesdigitales.blogspot.com/2023/12/estudio-trimestral-sobre-l… https://guardianesdigitales.blogspot.com/2023/12/censura-y-restricciones-de… *### Karisma Foundation report on blocks in Colombia* Our partner, Karisma Foundation ( https://ooni.org/partners/karisma-foundation/) published a report on emergent blocks in Colombia based on OONI data: https://obi.karisma.org.co/2024-10-28-colombia-bloqueo-bitcoin-e-independen… Specifically, their report documents the blocking of Bitcoin and The Independent news media website in Colombia based on OONI data. *## Community-led presentations### Phnom Penh Internet Forum 2024* On 18th October 2024, the Advocacy and Policy Institute (API) presented the iMAP Cambodia 2024 Internet Censorship Report (which is based on OONI data) at the Phnom Penh Internet Forum ( https://ppifcambodia.net/ppif-home/agenda-en/) Read the iMAP Cambodia 2024 Internet Censorship Report here: https://imap.sinarproject.org/reports/2024/imap-cambodia-2024-internet-cens… The event and presentation of the censorship findings received the following press coverage: https://cambojanews.com/phnom-penh-internet-forum-calls-attention-to-digita… *## Community activities### Lightning talk at the Berkman Klein Center for Internet and Society at Harvard University* On 8th October 2024, OONI’s Maria gave a lightning talk at the Berkman Klein Center for Internet and Society (https://cyber.harvard.edu/) where she introduced other fellows to her fellowship research, which aims to explore how internet censorship changed globally over the past eight years. As part of this lightning talk, Maria also briefly introduced participants to OONI tools and data. *### Panel discussion on internet censorship policies in Indonesia* On 10th October 2024, OONI’s Mehul participated in a panel discussion (“Unraveling Government’s Content Moderation and Internet Access Restrictions Policies and Implementation Techniques”) – organized by our partner, SAFEnet (https://ooni.org/partners/safenet/) – on internet censorship policies in Indonesia. As part of his participation, Mehul introduced participants to OONI tools and methods and he shared some censorship findings from OONI measurements collected from Indonesia. *### OONI training session for SHOOA* On 10th October 2024, OONI’s Elizaveta hosted an OONI training session for SHOAA (https://shoaa.org/) a digital rights organization from Algeria. During this session, participants learned how to use OONI Probe, OONI Run, the OONI Test Lists Editor and OONI Explorer to document and investigate internet censorship. *### OONI training of trainers (ToT) for civil society activists in Senegal* On 11th October 2024, OONI’s Elizaveta facilitated a full-day, hybrid, training of trainers (ToT) for civil society activists from Senegal. This training of trainers event was organized by our Senegalese partners, Computech Institute (https://ooni.org/partners/computech/) and Jonction. As part of the training, Elizaveta covered all OONI tools (OONI Probe, OONI Run, Test Lists Editor, OONI Explorer) and prepared 10 civil society activists to run similar training sessions in their regions in Senegal. *### Presentation of research report at the Internet Governance Forum (IGF) 2024 Kazakhstan* On 16th October 2024, OONI’s Elizaveta presented the findings from our new research report on internet censorship in Kazakhstan ( https://ooni.org/post/2024-kazakhstan-report/) at the Internet Governance Forum (IGF) 2024 Kazakhstan (https://igf.kz/en/main/#agenda) The presentation of the report at the event received the following press coverage: https://bes.media/news/mitm-ataki-i-tsenzura-raskriti-metodi-pravitelstvenn… *### M-Lab Community Call on large scale internet measurements* On 17th October 2024, OONI’s Maria participated as a panelist in M-Lab’s community call discussion on challenges and lessons learned from large scale internet measurements. Watch the full Community Call discussion on M-Lab’s YouTube channel: https://www.youtube.com/watch?v=Sq-v5GfYInQ *### Panel at Decrypting Digital Authoritarianism conference* On 29th October 2024, OONI’s Arturo participated in the conference "Decrypting Digital Authoritarianism" at the European University Institute, which focused on examining how internet usage can impact democracy and human rights. Arturo was a speaker in the roundtable discussion "Strategies and counterstrategies of digital authoritarianism in practice," alongside representatives from Freedom House, Deutsche Welle, Meta, Project Liberty – Sciences Po, and the Freedom Online Coalition ( https://x.com/EUI_Schuman/status/1851192966615896490) The session, chaired by Patryk Pawlak, explored various approaches to identifying and countering digital authoritarian practices. Throughout the conference, Arturo engaged in discussions with other participants about documenting and responding to digital authoritarianism globally. *### OONI Run v2 demo for Localization Lab community* On 30th October 2024, OONI’s Elizaveta provided a live demo of using our new OONI Run v2 tool (https://run.ooni.org/) for the Localization Lab community (https://www.localizationlab.org/) The goal of this session was to introduce the Localization Lab’s translator community (who localize OONI tools) to OONI Run v2, address their questions, and collect their feedback. *### OONI Community Meeting* On 29th October 2024, we hosted the monthly OONI Community Meeting on our Slack channel (https://slack.ooni.org/) We dedicated this meeting to the discussion of the recently launched OONI Run v2 tool (https://ooni.org/post/2024-launch-ooni-run-v2/) Community members asked many questions, shared feedback and feature requests, as documented in our community meeting pad: https://pad.riseup.net/p/ooni-community-meeting-keep *## Measurement coverage* In October 2024, 56,985,335 OONI Probe measurements were collected from 2,964 networks in 176 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

Anti-censorship team meeting notes, 2025-01-16
by Shelikhoo 16 Jan '25

16 Jan '25

Hey everyone! Here are our meeting logs: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday,January 23 16:00 UTC Facilitator: meskio ^^^(See Facilitator Queue at tail) 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * SQS rendezvous exceeded free tier limit * https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * Edgio Azure CDN was supposed to have shut down 8 hours ago, snowflake-broker.azureedge.net is still running for the moment * https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… == Discussion == * Should we proceed with "Dockerfile: run proxy as non-root user" (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) * Unreliable WebRTC mode really is faster! https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * Status of Tor Browser build with Snowflake with covert-dtls? * Thanks for the reminder. == Actions == == Interesting links == == Reading group == * We will discuss "Discovering and Measuring CDNs Prone to Domain Fronting" on January 16th * https://dl.acm.org/doi/10.1145/3589334.3645656 * https://github.com/karthikaS03/DomainFrontingDiscovery * 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): 2025-01-016 Last week: - debugged some let's encrypt cert issues on old versions of android - lyrebird#40012 - https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… - snowflake!483 - helped onyinyang set up a conjure test environment - worked a bit more on expanding the geoip library to use CAIDA AS routeviews data - looked into SQS exceeding free-tier usage limit This week: - finish catching up on reviews - asn mapping geoip feature dcf: 2025-01-16 (since 2024-12-19) Last week: - with shelikhoo, let the new snowflake broker respond to snowflake-broker.bamsoftware.com, as a workaround for the apparently unchangeable origin SNI in the Edgio CDN https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - opened an issue to shut down the snowflake-broker.azureedge.net (Edgio) CDN profile after it stops working https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - azure snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - responded to a question about ampcache rendezvous https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - opened an issue for snowflake-client SOCKS args clobbering each other when multiple bridge lines are used https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - 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: 2024-01-16 Last week: - coordinate with debian developers to package snowflake dependencies (snowflake#40410) - add country based metrics to the snowflake proxy (snowflake!482) - look into 8.8.8.8 being distributed as bridge (team#156) Next week: - snowflake debian package Shelikhoo: 2024-01-16 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Automate bridgeline update for snowflake(https://gitlab.torproject.org/tpo/anti-censorship/connectivity-me… ) Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2025-01-16 Last week(s): - Get conjure up and running (at least locally) - WIP Conjure stuff for Project 173 Next week: - Continue on getting conjure up and running (at least locally) - implement utls for conjure - start implementation of alternative registration methods As time allows: - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - 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? theodorsm: 2024-01-16 Last weeks: Next weeks: - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Write instructions on how to configure covert-dtls with snowflake client - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake MR Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0