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
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
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
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
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/13149https://t.me/ru_tech_talk/624https://t.me/cybersarik/1428https://t.me/airfield1972/3746https://t.me/chertamedia/6974https://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.
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/962https://github.com/ooni/explorer/issues/960https://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.
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