tor-project
Threads by month
- ----- 2025 -----
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
January 2025
- 14 participants
- 19 discussions
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
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
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
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
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
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
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
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
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
Hi folks,
On account of MLK Day, the UX Team meeting scheduled for 1600 UTC on Monday Jan 20th has been moved to the same time on Tuesday 21st instead.
See you then,
Duncan
1
0