Hello everyone!
With three stable Tor Browser releases (two for desktop, one for
Android), much of my work focussed on user support around these
releases. Prior to the release of Tor Browser 13, I worked to review and
update our user-facing documentation on Tor Browser User Manual[0].
I also handled some tickets from users reaching out for support and
questions about Tor in light of the launch of the year-end campaign[1].
The questions range from, "where can I download Tor Browser from?", "I
can't reach xyz.com", "this particular onion service isn't
working","apart from donating, can I contribute with
ideas/suggestions?", etc.
In October, we closed many tickets that were already resolved, but they
were in the 'open' queue. We also had some private bridge "country code"
requests that ended up being basic troubleshooting problem. And finally,
many tickets were created by a few users trying to get new bridges. So
each ticket that we closed was marked as 'resolved' hence showing up in
the numbers although counted just once in the breakdown.
Following is a thorough breakdown of tickets our user support team
handled in October:
# Frontdesk (email support channel)
* 965(↑) RT tickets created
* 1280(↑) RT tickets resolved
Tickets by numbers:
1. 204(↓) RT tickets: private bridge requests from Chinese speaking users.
2. 174(↓) RT tickets: circumventing censorship in Russian speaking countries.
3. 27 RT tickets: user support and common Tor questions in aftermath of launch of YEC.
4. 9(↑) RT tickets: circumventing censorship with Tor in Farsi.
5. 8(↑) RT tickets: help with installing and troubleshooting Tor Browser on Linux.
6. 4 RT tickets: All saved passwords lost after updating to Tor Browser 13.0.[2]
7. 3 RT tickets: Tor Browser 13 (lyrebird) not working with Windows 7.[3]
8. 3 RT tickets: Questions about internships and volunteering with Tor.[4]
9. 1 RT ticket: Tor Browser empties clipboard while shutting down.[5]
10. 1 RT ticket: Tor Browser detected as malware on Windows.[6]
# Telegram, WhatsApp and Signal Support channel
* 681(↑) tickets resolved
Breakdown:
* 633(↑) tickets on Telegram
* 34(↑) tickets on WhatsApp
* 14(↑) tickets on Signal
Tickets by numbers:
1. 370(↑) tickets: circumventing censorship in Russian speaking
countries.
2. 37(↑) tickets: circumventing censorship with Tor in Farsi.
3. 30(↑) tickets: private bridge requests from Chinese speaking users.
4. 3(↓) tickets: Tor Browser detected as malware on Windows
# Highlights from the Tor Forum
1. Call for testers: Webtunnel, a new way to bypass censorship with Tor
Browser.[7]
2. PSA: Updated Tor User Support office hours (2023)[8]
3. Tor Browser no longer flagged by Windows Defender[6]
Thanks!
e.
Note: (↑), (↓) and (-) are indicative if the number of tickets we
received for these topics have been increasing, decreasing or have been
the same from the previous month respectively.
[0]: https://gitlab.torproject.org/tpo/web/manual/-/issues/150
[1]: https://blog.torproject.org/2023-fundraiser-make-a-donation-to-Tor/
[2]: https://forum.torproject.org/t/saved-passwords-gone-after-upgrade-to-tor-br…
[3]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42179
[4]: https://community.torproject.org/
[5]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42154
[6]: https://forum.torproject.org/t/torbrowser-12-5-6-no-longer-flagged-by-windo…
[7]: https://forum.torproject.org/t/call-for-testers-webtunnel-a-new-way-to-bypa…
[8]: https://forum.torproject.org/t/psa-updated-tor-user-support-office-hours-20…
Hello,
This email shares OONI's monthly report for October 2023.
*# OONI Monthly Report: October 2023*
Throughout October 2023, the OONI team worked on the following sprints:
* Sprint 101 (1st - 8th October 2023)
* Sprint 102 (9th-22nd October 2023)
* Sprint 103 (24th-31st October 2023)
Our work can be tracked through the various OONI GitHub repositories:
https://github.com/ooni
Highlights are shared in this report below.
*## Launch of News Media Scan app*
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 (https://ooni.org/data/).
On 5th October 2023, Deutsche Welle and OONI launched the News Media Scan
app for Android, which is available in the Google Play Store:
https://play.google.com/store/apps/details?id=com.dw.ooniprobe&pli=1
Deutsche Welle published a press statement, announcing the launch:
https://corporate.dw.com/en/news-media-scan-by-dw-deutsche-welle-and-ooni-l…
The app also received press coverage by turi2:
https://www.turi2.de/aktuell/dw-und-ooni-bringen-app-zur-erkennung-von-inte…
We are excited about this launch, as we expect that it will help boost news
media censorship measurement worldwide, supporting efforts to defend press
freedom around the world.
*## New partnership*
We are excited to have established a new partnership with Digitally Right (
https://digitallyright.org/), a digital rights organization in Bangladesh.
We aim to collaborate on the study of internet censorship in Bangladesh.
We also published a page to feature our new research collaboration
(established in September 2023) with the GLITCH Research Interest Group at
the Oxford Internet Institute, a department of the University of Oxford.
This page is available here: https://ooni.org/partners/glitch/
*## Published OONI Community Interview with Siti Nurliza*
On 16th October 2023, we published an interview with Siti Nurliza: a
talented data analyst and technologist with Sinar Project, one of our most
dedicated and long-term partners who have led OONI censorship measurement
efforts in Southeast Asia for more than 6 years!
Siti’s interview (which we published on the OONI YouTube channel) can be
viewed here: https://www.youtube.com/watch?v=DOTjOR7zA2Y
This interview is part of our “OONI Community Interviews” series, through
which we highlight the important work of OONI community members.
We also published a blog post to share the interview and information about
Sinar Project and their work:
https://ooni.org/post/2023-interview-with-siti-nurliza/
*## OONI Probe user guides available in Vietnamese*
As of October 2023, the OONI Probe user guides are available in Vietnamese!
The Vietnamese user guides can be found below:
* OONI Probe Mobile: https://ooni.org/vi/support/ooni-probe-mobile
* OONI Probe Desktop: https://ooni.org/vi/support/ooni-probe-desktop
We thank Nathan Tran for the translation!
*## OONI Explorer available in Arabic, Burmese and Portuguese*
In October 2023, we released OONI Explorer in Arabic, Burmese, and
Portuguese.
* Arabic: https://explorer.ooni.org/ar
* Burmese: https://explorer.ooni.org/my
* Portuguese: https://explorer.ooni.org/pt-BR
We thank the Localization Lab community for these translations!
*## OONI Outreach Kit available in Russian*
We are excited to share that the OONI Outreach Kit is now available in
Russian!
The Russian version of the OONI Outreach Kit can be found here:
https://ooni.org/ru/support/ooni-outreach-kit/
*## OONI Probe Mobile*
In October 2023, we released OONI Probe Mobile 3.8.4 for both Android (
https://github.com/ooni/probe-android/releases/tag/v3.8.4) and iOS (
https://github.com/ooni/probe-ios/releases/tag/v3.8.4), which includes a
series of improvements.
Notably, OONI Probe 3.8.4 includes support for Vietnamese and Burmese.
*## OONI Run*
As part of our work on creating the next generation version of OONI Run
(“OONI Run v2”), we continued to iterate on the user interface designs for
the web and mobile applications.
We started updating the OONI Run UI on OONI Probe Mobile from v1 to v2, (
https://github.com/ooni/probe-android/pull/626). This included updating the
test overview view, implementing new components (
https://github.com/ooni/probe-android/pull/629), updating the dashboard
view (https://github.com/ooni/probe-android/pull/631), and updating the
choose websites view (https://github.com/ooni/probe-android/pull/630).
*## OONI Probe CLI*
In October 2023, we released OONI Probe CLI 3.19.0:
https://github.com/ooni/probe-cli/releases/tag/v3.19.0
Below are some highlights from this release:
1) We improved support for measuring throttling by integrating code that
takes periodic download speed snapshots while fetching websites in Web
Connectivity LTE (the currently-experimental next-generation Web
Connectivity implementation). This data collection process will further
enrich the measurements we collect and allow spotting throttling across the
whole web page download, as opposed to limiting the analysis to spotting
throttling during the TLS handshake and the beginning of the download
(which is what 3.18 was capable of doing).
2) We introduced the concept of OONI Probe Bridges. A bridge is an IP
address that we can use to communicate with the OONI backend and for which
we are confident that we can use any Server Name Indication during the TLS
handshake without errors. We believe this functionality will improve the
reliability under some censorship conditions.
3) We improved measurement scrubbing to remove any string that looks like
an IP address or a TCP/UDP endpoint from the HTTP response bodies and
headers. We are still scrubbing known IP addresses (e.g., the one used by
OONI Probe) from the whole measurement. By adding this extra scrubbing
step, we further increase OONI Probe’s safety.
4) We started using the netemx integration testing framework in the
codebase. This framework combines GVisor (https://gvisor.dev/), an emulated
internet topology, and deep packet inspection, to allow us to write complex
and realistic censorship scenarios. We migrated many of the most important
nettests to use this framework for testing. Going forward, this capability
will allow us to replace the implementation of experiments knowing that key
properties related to detecting censorship continue to hold.
5) We added support to the OONI Probe Engine for fetching OONI Run v2
descriptors, which is a precondition for implementing OONI Run v2 in mobile
applications.
6) Taking advantage of `netemx`, we migrated all the tests run by `go test
-short ./...` to use netemx rather than the host network. This means that,
from this release onwards, one does not need to have access to an
uncensored network to develop OONI Probe. In fact, all the key unit and
integration tests only rely on GVisor and on the emulated network topology
described above, meaning that no traffic is actually sent to or received
from actual network interface cards.
7) We fixed the bootstrap of OONI Probe in a case where the timeouts
configuration conflicted with the bootstrap being successful. While version
3.19 only includes a hotfix, we plan on refactoring this part of OONI Probe
and fixing some fundamental issues we identified (
https://github.com/ooni/probe/issues/2545).
8) We fixed a data quality issue in Web Connectivity v0.4 where Android’s
getaddrinfo resolver conflicted with the analysis logic in the presence of
NXDOMAIN-based censorship. Android has a getaddrinfo implementation that
always returns EAI_NODATA when there is any error. This happens because
getaddrinfo is actually a proxy for a DNS lookup service and there is no
support for passing errors along. The OONI Probe engine did already
identify this specific error condition as android_dns_cache_no_data. What
changed in version 3.19 is that we say that there is a measurement anomaly
if this error appears and the test helper, instead, says that the domain
for the website we’re measuring successfully resolves to IP addresses.
*## Expanding OONI’s testing model to support richer testing input*
After months of research on richer input, we were able to draft a plan that
describes exactly how we are going to implement it and for which
experiments. You can read the whole plan here:
https://github.com/ooni/ooni.org/issues/1295
Below are some highlights:
1) We will implement richer input by enriching the existing
`/api/v1/check-in` response (i.e., the response from the check-in API used
to deliver measurement targets to OONI Probe).
2) The check-in API client in the OONI Probe Engine will cache specific
bits of the check-in response using the disk or memory. Some information
will be cached on disk with a pretty long expiry time. Other information is
cached for a short timeframe or kept in memory.
3) We will modify how we run experiments by moving around a pure-data
structure that contains the experiment name, the experiment options, and
the experiment inputs. (The whole point of richer input is indeed to move
options around and honor them when running experiments.)
4) We will need to refactor how ooniprobe, the miniooni research client,
and the mobile apps execute experiments by replacing code that create
instances of “Experiment” with code that moves around this pure data
structure and defers the actual instantiation and execution of the
experiment deep inside of the OONI Engine.
5) The ooniprobe, miniooni, and mobile apps codebase will prepare pure-data
structures and submit them to the engine for execution. In the common case
of running experiments like we currently do, ooniprobe, miniooni, and the
mobile apps will not fill any option. Instead, the engine would do that
based on the cached check-in content.
In October 2023, we also started writing code to implement this plan, but
the bulk of the work is going to happen in subsequent weeks and months.
Obviously, the plan is tentative and possibly poised to change as we learn
more and flesh out the implementation.
*## Creating a throttling measurement methodology*
As mentioned above when discussing OONI Probe CLI 3.19.0 release notes,
there is better support for detecting throttling only in Web Connectivity
LTE. As you may remember from previous reports, Web Connectivity LTE is
currently experimental and only enabled for a small subset of our users.
This situation begs the question of how to bring these extra throttling
improvements to all experiments. For example, it would be nice if the OONI
Probe Telegram test measures throttling when testing web.telegram.org.
To make this possible, we need to switch the underlying engine used by
other experiments from the old `legacy/netx` to the new `mesurexlite`
engine. The reason why we need to do this change is that the `measurexlite`
engine uses a different methodology for collecting OONI measurements called
tracing. This methodology is more flexible than the one used by the
`legacy/netx` engine, called wrapping, and enables us to collect more data
– including data relevant for throttling – in a more flexible way.
Currently, Web Connectivity LTE is the only experiment using
`measurexlite`. But switching the engine requires rewriting large swaths of
code. Thus, we spent time polishing the `netemx` testing framework and
rewriting unit and integration testing code to use it. This work occurred
in previous reporting periods and was released in version 3.19. Hence, now
we start being well positioned to initiate the migration to the
`measurexlite` engine.
However, `measurexlite` is a low-level engine and writing code for it
directly has proven to be difficult. For writing Web Connectivity LTE, in
fact, we used a code generator. However, we were not completely satisfied
with this approach and we introduced `dslx`, which allows composing
measurement primitives in an easy way and which is based on `measurexlite`.
Therefore, the plan is now to rewrite existing experiments using `dslx`.
To make this possible, in October 2023 we applied fixes that allow writing
more compact and expressive code, based on our several-months-long
experience in using `dslx`. (To make sure `dslx` was up to the task, we
used it extensively when experimenting with richer input; this means that
we already know about some pain points.)
More specifically, below are the changes we applied to `dslx`:
1. https://github.com/ooni/probe/issues/2580
2. https://github.com/ooni/probe/issues/2582
3. https://github.com/ooni/probe/issues/2611
4. https://github.com/ooni/probe/issues/2612
5. https://github.com/ooni/probe/issues/2613
6. https://github.com/ooni/probe/issues/2614
7. https://github.com/ooni/probe/issues/2615
8. https://github.com/ooni/probe/issues/2617
9. https://github.com/ooni/probe/issues/2618
With these changes implemented, we’re now well positioned to move forward
with measuring throttling.
*## Creating a Social Media Censorship Alert System*
We made progress on the research side of the Social Media Censorship Alert
System by polishing a design document and updating the relevant pull
request (https://github.com/ooni/backend/pull/651) based on feedback. We
also started to reach out to members of the research community to collect
input on how we might improve upon the design of the alert system.
*## Creating a Censorship Incident Reporting Platform*
We continued working towards launching the Censorship Incident Reporting
Platform. Our focus was on testing, making improvements and UI tweaks (
https://github.com/ooni/explorer/pull/878) to ensure that everything works
smoothly. We also updated our component library as needed (
https://github.com/ooni/design-system/). On the backend side, we added
support for displaying the author's email address in the admin UI of the
incident reporting platform (https://github.com/ooni/backend/pull/732).
We wrote most of the censorship reports for the platform, and we started
publishing them as part of our internal testing process. As part of this
testing and publication process, we documented feedback for improvements (
https://github.com/ooni/explorer/issues/879). All of the reports (along
with the platform itself) will be accessible from the OONI Explorer menu
navigation bar when the platform is publicly launched.
*## OONI backend*
In order to improve the effectiveness in circumventing the blocking of the
traffic between probes and the API, we deployed a second ooni bridge using
a different provider than Hetzner: Greenhost.
We fixed a previously identified bug in the probe registration API entry
point affecting the authentication JWT. The bug did not impact the
live/production API because it uses Orchestrate for this (
https://github.com/ooni/backend/issues/731,
https://github.com/ooni/backend/pull/727).
Based on a request from a user, we investigated the generation of test
lists in Georgia and created a monitoring script and a dashboard. This is
an initial stepping stone to better understand how frequently the URLs in
test lists are "reordered" by the prioritization algorithm.
We detected a client scraping the aggregation API. The increase in load did
not impact the performance of the API to the point of disrupting the
service, however it increased the CPU load enough to be clearly noticeable
on performance dashboards. We improved an existing Jupyter notebook to
extract the heaviest queries.
We also investigated using traffic quotas in ClickHouse but encountered a
bug in the current version of the database that required postponing the
implementation. After noticing high database load due to the measurement
uploader tool and the database backup tool we investigated how to lower the
query priorities to decrease the impact.
We performed initial end-to-end tests for a custom STUN server using probe
VPSs as vantage points. The STUN server is meant to be used for
circumvention and potentially to measure latency between the probe and the
server.
We continued carrying out security updates in the OS on our servers (
https://github.com/ooni/backend/issues/740). We updated the monitoring host
to Debian Bookworm. As part of this Grafana and ClickHouse have been
upgraded to newer and more performant versions. We also worked on improving
the existing documentation for the backend infrastructure.
*## Automating censorship detection and characterization based on OONI
measurements*
We continued to make progress on automating censorship detection and
characterization based on OONI measurements. Specifically, we worked on
improving the performance of the observation generation for older buckets,
which are currently affected by a bug that makes them not be compressed.
As part of this work, we implemented a different parallelization strategy
which allows us to reprocess a bucket of measurements in a day in around 5
minutes (whereas previously it was in the range of 30-40 minutes).
We also added support for storing statistics in the database about how long
it took to process a given batch of measurements, allowing us to more
accurately assess how we are doing on the performance front. This work is
documented here: https://github.com/ooni/data/pull/37
*## Scoping upcoming research reports*
Throughout October 2023, we worked towards scoping some of our upcoming
research reports. This involved analyzing OONI data to identify interesting
censorship cases, writing internal documents with relevant research
questions, plans, and timelines, and coordinating with relevant research
partners.
*## Created surveys for upcoming OONI training in the DRC*
In preparation for a week-long OONI training that we will be facilitating
in Kinshasa (DRC) in November 2023, we created two surveys for the
participants. The first survey will be shared with the participants at the
start of the training, while the second survey will be shared at the end.
The goal of these surveys is to evaluate how effective the training will
be, and to collect relevant participant feedback. We shared these surveys
with the training organizers for French translation.
*## Created the agenda for the OONI Team Meeting 2023*
Between 8th-10th November 2023, we will host our annual OONI Team Meeting
in Nairobi, Kenya. This 3-day meeting will provide our team the opportunity
to discuss roadmaps, strategic priorities, and projects in person.
In preparation for our annual OONI Team Meeting, we solicited team feedback
for the agenda. Based on team feedback and session proposals, we worked on
creating and finalizing the detailed agenda for our 3-day team meeting.
We also coordinated on other relevant logistics pertaining to travel to
Nairobi for our upcoming meeting.
*## Test Lists updates*
In October 2023, we reviewed test list updates contributed by community
members.
These include:
* Extensive update of the Kazakhstan test list by our partner, Internet
Freedom Kazakhstan: https://github.com/citizenlab/test-lists/pull/1459
* Update of the Global test list by a community member:
https://github.com/citizenlab/test-lists/pull/1452
*## Rapid response*
*## Azerbaijan unblocked access to TikTok*
On 31st October 2023, Azerbaijan unblocked access to TikTok! Azerbaijan had
previously been blocking access to TikTok since 19th September 2023 (during
the military offensive in Nagorno-Karabakh). We shared OONI data and
reported on the unblocking of TikTok in Azerbaijan on X:
https://twitter.com/OpenObservatory/status/1719742224940859674
*## Community use of OONI data### iMAP 2023 Internet Censorship Reports*
On 13th October 2023, the iMAP project (https://imap.sinarproject.org/)
published 10 new research reports on internet censorship in the following
Asian countries: Malaysia, Myanmar, Thailand, Vietnam, Cambodia, Hong Kong
(China), India, Indonesia, Timor-Leste, and the Philippines. These reports
are based on the analysis of OONI data collected from these 10 countries.
The iMAP 2023 Internet Censorship Reports are available here:
https://imap.sinarproject.org/reports/2023
Specifically, they include the following reports:
1) Cambodia: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-cambodia-2023-internet-cens…
2) Hong Kong (China): 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-hong-kong-2023-internet-cen…
3) India: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-indonesia-2023-internet-cen…
4) Indonesia: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-indonesia-2023-internet-cen…
5) Malaysia: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-malaysia-2023-internet-cens…
6) Myanmar: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-myanmar-2023-internet-censo…
7) Philippines: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-philippines-2023-internet-c…
8) Thailand: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-thailand-2023-internet-cens…
9) Timor-Leste: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-timor-leste-2023-internet-c…
10) Vietnam: 2023 Internet Censorship Report:
https://imap.sinarproject.org/reports/2023/imap-vietnam-2023-internet-censo…
The launch and presentation of these reports was live-streamed here:
https://www.youtube.com/watch?v=YkFQxzvJrMs
*### Freedom on the Net 2023 reports*
Freedom House published their annual Freedom on the Net report (
https://freedomhouse.org/report/freedom-net/2023/repressive-power-artificia…),
which includes numerous country reports (
https://freedomhouse.org/countries/freedom-net/scores).
OONI data is cited in the following 38 (out of 70 in total)
country-specific Freedom on the Net 2023 country reports:
* Azerbaijan: https://freedomhouse.org/country/azerbaijan/freedom-net/2023
* Belarus: https://freedomhouse.org/country/belarus/freedom-net/2023
* Brazil: https://freedomhouse.org/country/brazil/freedom-net/2023
* Cambodia: https://freedomhouse.org/country/cambodia/freedom-net/2023
* Colombia: https://freedomhouse.org/country/colombia/freedom-net/2023
* Cuba: https://freedomhouse.org/country/cuba/freedom-net/2023
* Egypt: https://freedomhouse.org/country/egypt/freedom-net/2023
* Ethiopia: https://freedomhouse.org/country/ethiopia/freedom-net/2023
* India: https://freedomhouse.org/country/india/freedom-net/2023
* Indonesia: https://freedomhouse.org/country/indonesia/freedom-net/2023
* Iran: https://freedomhouse.org/country/iran/freedom-net/2023
* Iraq: https://freedomhouse.org/country/iraq/freedom-net/2023
* Italy: https://freedomhouse.org/country/italy/freedom-net/2023
* Jordan: https://freedomhouse.org/country/jordan/freedom-net/2023
* Kazakhstan: https://freedomhouse.org/country/kazakhstan/freedom-net/2023
* Kenya: https://freedomhouse.org/country/kenya/freedom-net/2023
* Lebanon: https://freedomhouse.org/country/lebanon/freedom-net/2023
* Libya: https://freedomhouse.org/country/libya/freedom-net/2023
* Malaysia: https://freedomhouse.org/country/malaysia/freedom-net/2023
* Myanmar: https://freedomhouse.org/country/myanmar/freedom-net/2023
* Nigeria: https://freedomhouse.org/country/nigeria/freedom-net/2023
* Pakistan: https://freedomhouse.org/country/pakistan/freedom-net/2023
* Philippines: https://freedomhouse.org/country/philippines/freedom-net/2023
* Russia: https://freedomhouse.org/country/russia/freedom-net/2023
* Rwanda: https://freedomhouse.org/country/rwanda/freedom-net/2023
* Saudi Arabia:
https://freedomhouse.org/country/saudi-arabia/freedom-net/2023
* Sri Lanka: https://freedomhouse.org/country/sri-lanka/freedom-net/2023
* Sudan: https://freedomhouse.org/country/sudan/freedom-net/2023
* Thailand: https://freedomhouse.org/country/thailand/freedom-net/2023
* Tunis: https://freedomhouse.org/country/tunis/freedom-net/2023
* Turkey: https://freedomhouse.org/country/turkey/freedom-net/2023
* Uganda: https://freedomhouse.org/country/uganda/freedom-net/2023
* UAE:
https://freedomhouse.org/country/united-arab-emirates/freedom-net/2023
* UK: https://freedomhouse.org/country/united-kingdom/freedom-net/2023
* Uzbekistan: https://freedomhouse.org/country/uzbekistan/freedom-net/2023
* Venezuela: https://freedomhouse.org/country/venezuela/freedom-net/2023
* Zambia: https://freedomhouse.org/country/zambia/freedom-net/2023
* Zimbabwe: https://freedomhouse.org/country/zimbabwe/freedom-net/2023
*## Community activities### OONI training in Thailand for participants from
South Asia*
Between 2nd-4th October 2023, OONI’s Maria co-facilitated a 3-day training
programme in Thailand in collaboration with IODA’s Amanda. This was an
OPTIMA training programme for human rights defenders from South Asia,
designed to share skills and knowledge around measuring internet shutdowns.
As part of this training programme, Maria facilitated the following OONI
workshops:
* Introduction to OONI
* Using OONI Probe and OONI Run for measuring internet censorship
* Updating test lists to improve website censorship testing
* Using OONI Explorer to investigate internet censorship based on real-time
open data
The above workshops included a combination of presentations, live demos,
and hands-on exercises (through which participants made use of the tools
based on real-world scenarios).
In addition to the above, Maria collaborated with Amanda on presenting a
case study (“Internet censorship in Myanmar”) that combines both OONI and
IODA data for investigating internet shutdowns (involving both outages and
blocks). Maria and Amanda also collaborated on facilitating a day-long
workshop through which participants worked on group projects aimed at
investigating internet censorship based on both OONI and IODA data. At the
end of this workshop, participants presented their projects.
*### OONI training in Tbilisi for media managers from Turkey*
On 5th October 2023, OONI’s Elizaveta facilitated a workshop on OONI tools
as part of the training organized by Internews for Turkish media managers.
As part of this workshop, managers learned how to use OONI Run to
coordinate measurement campaigns, how to collect evidence on the blocking
of media tools, and how to use OONI Explorer to investigate the blocking of
news media websites in Turkey.
*### Hackathon at Internet Measurement Conference (IMC) 2023*
On 23rd October 2023, OONI collaborated with ISOC, Censored Planet, and
M-Lab on co-hosting an internet measurement hackathon right before the
Internet Measurement Conference (IMC) 2023. Information about the hackathon
is available here: https://ooni.org/post/2023-imc-hackathon/
As part of the hackathon 3 teams worked on projects which made use of OONI
data. The teams which made use of OONI data worked on the following:
* Using OONI data to investigate IPv6 connectivity, where they used OONI
data to investigate differences and evolution in IPv6 connectivity
worldwide and disaggregated by network type.
* Data triangulation, where they extracted signals for internet shutdowns
by comparing multiple different datasets, including OONI.
* ARIMA based anomaly detection, where they developed a statistical anomaly
detection model to identify anomalous signals in various datasets,
including OONI.
All in all, it was great to see how much was accomplished in such a short
period of time and we hope that these researchers will have learned more
about OONI data and continue to make use of it in the future.
In addition to hosting the hackathon, OONI’s Arturo also attended IMC 2023 (
https://conferences.sigcomm.org/imc/2023/).
*### OONI Community Meeting*
On 31st October 2023, we hosted the monthly OONI Community Meeting on our
Slack channel (https://slack.ooni.org/), during which we discussed the
following topics:
1) Updates from OONI and the OONI community
2) Community feedback for the naming of OONI’s upcoming new “Censorship
Incident Reporting Platform”
3) Community feedback related to re-designing the OONI website
4) Community feedback on OONI’s educational resources: Which are most
useful, and which are missing/needed?
5) IODA updates on internet outages in Gaza
*## Measurement coverage*
In October 2023, 63,123,792 OONI Probe measurements were collected from
3,112 networks in 171 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! It is time for my October-2023 report!
In October, I resolved 1059 tickets (WOW!):
* -Telegram (@TorProjectSupportBot) - 505
* -RT (frontdesk@tpo) - 526
* -WhatsApp (+447421000612) - 20
* -Signal (+17787431312) - 8
This month the majority of usersneeded help with:
1. Russian speaking users to obtainbridges and using them correctly
2. Tor Browser getting flag by Windows defender and other antivirus
3. How to use new WebTunnel bridges and where to get them
4. How to use snowflakeon different Tor powered apps
At the beginning of October, there was an issue with Windows Defender
flaggingTor Browser as a virus[1], whichled to a giant wave of Tor users
asking us how to fix their Tor Browser.
With @ebanam,we had a quarterly user support template review and
updatedseveral templates to reflect changes in the latest Tor Browser
version.
This month, because of the activists' detention in Kazakhstan in an
attempt to prevent unrest on Republic Day (25 October)[2], some users
reached us to express their concerns and get instructions on how to use
the Tor Browser in case of the internet shutdown.Tor Comms team
re-published instructions for users in Kazakhstan on how to download Tor
powered apps.
Other bugs: Tor users reportedanissue with TelegramGetTor Bot
<https://t.me/gettor_bot> that wasn't distributing Tor Browser
Windowsversion.I also submitteda bug with Tor Browser not working for
the users with Windows 7 [3].
[1]
https://forum.torproject.org/t/torbrowser-12-5-6-no-longer-flagged-by-windo…
[2] https://en.wikipedia.org/wiki/Republic_Day_(Kazakhstan)
[3]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42179
Hey everyone!
[FIXED]: In the last email, next meeting date was not appropriately
updated. Sorry for the inconvenience.
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-11-02-15.57.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Anti-censorship
--------------------------------
Next meeting: Thursday, Nov 09 16:00 UTC
Facilitator: onyinyang
Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
(channel is logged while meetings are in progress)
This week's Facilitator: shelikhoo
== Goal of this meeting ==
Weekly check-in about the status of anti-censorship work at Tor.
Coordinate collaboration between people/teams on anti-censorship at the
Tor Project and Tor community.
== Links to Useful documents ==
* Our anti-censorship roadmap:
*
Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards
* The anti-censorship team's wiki page:
*https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home
* Past meeting notes can be found at:
* https://lists.torproject.org/pipermail/tor-project/
* Tickets that need reviews: from sponsors, we are working on:
* All needs review tickets:
*https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
* Sponsor 96 <-- meskio, shell, onyinyang, cohosh
*https://gitlab.torproject.org/groups/tpo/-/milestones/24
* Sponsor 150 <-- meskio working on it
*https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_name%5B%5D=Sponsor%20150
== Announcements ==
== Discussion ==
* Fastly to block domain fronting in February 2024
https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/00…
* azure is closing domain front support next month
* there are some alternatives to domain fronting we could use
(ampcache or tapdance), but it might be trickier to integrate with moat
* cohosh will investigate if cnd77, netlify or akamai are
alternatives we could use
* let's stress tests ampcache using it in one of our default
bridges
* we can add metrics to the broker to know if the clients come
from ampcache or domain front
* don't reject unrestricted client if there are no restricted
proxies
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* we'll merge it, it should not affect our deployment
(New: Nov 2)
* Maybe move to use a private pad?
== Actions ==
== Interesting links ==
* webtunnel testers call out:
*
https://forum.torproject.org/t/call-for-testers-webtunnel-a-new-way-to-bypa…
* blog post of the sponsor 30 code audit
*
https://blog.torproject.org/security-audit-report-tor-browser-ooni/
* New paper PTPerf: On the Performance Evaluation of Tor
Pluggable Transports: https://dl.acm.org/doi/10.1145/3618257.3624817
== Reading group ==
* We will discuss "On Precisely Detecting Censorship
Circumvention in Real-World Networks" on November 9
*
https://www.robgjansen.com/publications/precisedetect-ndss2024.html
* 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): 2023-11-02
Last week:
- continued lox integration with tor browser
-
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/34
- Changed how proxy stats logging works
-
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- Reviewed addition of prometheus metrics to lox
-
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/63
This week:
- lox tor browser UX integration
- follow up on conjure reliability issues
- visualize and write up some snowflake shadow simulation results
Needs help with:
dcf: 2023-11-02
Last week:
- snowflake CDN bookkeeping
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co…
Next week:
- revise encapsulation.ReadData redesign to return an error in
the case of a short buffer
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- open issue to have snowflake-client log whenever KCPInErrors
is nonzero
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- parent:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- open issue to disable /debug endpoint on snowflake broker
Before EOY 2023:
- move snowflake-02 to new VM
Help with:
meskio: 2023-10-26
Last week:
- test the whatsapp bot (rdsys#147)
- investiage a failure on telegram bot, was on applications
side (onionsproutsbot#54)
- some lox merge request reviews (lox!62 !68)
Next week:
- set up staging server for rdsys (rdsys#170)
Shelikhoo: 2023-11-02
Last Week:
- Work on snowflake performance
improvement(WIP):https://gitlab.torproject.org/shelikhoo/snowflake/-/tree/d…
- Restart broker without proxy churn measurements
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- Merge request reviews
Next Week/TODO:
- Write Tor Spec for Armored URL (continue)
- Merge request reviews
onyinyang: 2023-11-02
Last week(s):
- Finished up metrics
- Added functionality to handle blocked bridges in a single
location for MVP
- Started work on telegram distributor bot for Lox
This week:
- Continue work on Lox telegram bot
- Hackweek: Docs for Lox
https://gitlab.torproject.org/tpo/community/hackweek/-/issues/20
- Fix flakey test if time
(long term things were discussed at the
meeting!):https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep
- brainstorming grouping strategies for Lox
buckets (of bridges) and gathering context on how types of bridges are
distributed/use in practice
Question: What makes a bridge usable for a
given user, and how can we encode that to best ensure we're getting the
most appropriate resources to people?
1. Are there some obvious grouping
strategies that we can already consider?
e.g., by PT, by bandwidth (lower
bandwidth bridges sacrificed to open-invitation buckets?), by locale (to
be matched with a requesting user's geoip or something?)
2. Does it make sense to group 3
bridges/bucket, so trusted users have access to 3 bridges (and untrusted
users have access to 1)? More? Less?
Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-11-02-15.57.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Anti-censorship
--------------------------------
Next meeting: Thursday, Nov 2 16:00 UTC
Facilitator: shelikhoo
Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
(channel is logged while meetings are in progress)
This week's Facilitator: meskio
== Goal of this meeting ==
Weekly check-in about the status of anti-censorship work at Tor.
Coordinate collaboration between people/teams on anti-censorship at the
Tor Project and Tor community.
== Links to Useful documents ==
* Our anti-censorship roadmap:
*
Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards
* The anti-censorship team's wiki page:
*https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home
* Past meeting notes can be found at:
* https://lists.torproject.org/pipermail/tor-project/
* Tickets that need reviews: from sponsors, we are working on:
* All needs review tickets:
*https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
* Sponsor 96 <-- meskio, shell, onyinyang, cohosh
*https://gitlab.torproject.org/groups/tpo/-/milestones/24
* Sponsor 150 <-- meskio working on it
*https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_name%5B%5D=Sponsor%20150
== Announcements ==
== Discussion ==
* Fastly to block domain fronting in February 2024
https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/00…
* azure is closing domain front support next month
* there are some alternatives to domain fronting we could use
(ampcache or tapdance), but it might be trickier to integrate with moat
* cohosh will investigate if cnd77, netlify or akamai are
alternatives we could use
* let's stress tests ampcache using it in one of our default
bridges
* we can add metrics to the broker to know if the clients come
from ampcache or domain front
* don't reject unrestricted client if there are no restricted
proxies
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* we'll merge it, it should not affect our deployment
(New: Nov 2)
* Maybe move to use a private pad?
== Actions ==
== Interesting links ==
* webtunnel testers call out:
*
https://forum.torproject.org/t/call-for-testers-webtunnel-a-new-way-to-bypa…
* blog post of the sponsor 30 code audit
*
https://blog.torproject.org/security-audit-report-tor-browser-ooni/
* New paper PTPerf: On the Performance Evaluation of Tor
Pluggable Transports: https://dl.acm.org/doi/10.1145/3618257.3624817
== Reading group ==
* We will discuss "On Precisely Detecting Censorship
Circumvention in Real-World Networks" on November 9
*
https://www.robgjansen.com/publications/precisedetect-ndss2024.html
* 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): 2023-11-02
Last week:
- continued lox integration with tor browser
-
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/34
- Changed how proxy stats logging works
-
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- Reviewed addition of prometheus metrics to lox
-
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/63
This week:
- lox tor browser UX integration
- follow up on conjure reliability issues
- visualize and write up some snowflake shadow simulation results
Needs help with:
dcf: 2023-11-02
Last week:
- snowflake CDN bookkeeping
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co…
Next week:
- revise encapsulation.ReadData redesign to return an error in
the case of a short buffer
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- open issue to have snowflake-client log whenever KCPInErrors
is nonzero
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- parent:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- open issue to disable /debug endpoint on snowflake broker
Before EOY 2023:
- move snowflake-02 to new VM
Help with:
meskio: 2023-10-26
Last week:
- test the whatsapp bot (rdsys#147)
- investiage a failure on telegram bot, was on applications
side (onionsproutsbot#54)
- some lox merge request reviews (lox!62 !68)
Next week:
- set up staging server for rdsys (rdsys#170)
Shelikhoo: 2023-11-02
Last Week:
- Work on snowflake performance
improvement(WIP):https://gitlab.torproject.org/shelikhoo/snowflake/-/tree/d…
- Restart broker without proxy churn measurements
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- Merge request reviews
Next Week/TODO:
- Write Tor Spec for Armored URL (continue)
- Merge request reviews
onyinyang: 2023-11-02
Last week(s):
- Finished up metrics
- Added functionality to handle blocked bridges in a single
location for MVP
- Started work on telegram distributor bot for Lox
This week:
- Continue work on Lox telegram bot
- Hackweek: Docs for Lox
https://gitlab.torproject.org/tpo/community/hackweek/-/issues/20
- Fix flakey test if time
(long term things were discussed at the
meeting!):https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep
- brainstorming grouping strategies for Lox
buckets (of bridges) and gathering context on how types of bridges are
distributed/use in practice
Question: What makes a bridge usable for a
given user, and how can we encode that to best ensure we're getting the
most appropriate resources to people?
1. Are there some obvious grouping
strategies that we can already consider?
e.g., by PT, by bandwidth (lower
bandwidth bridges sacrificed to open-invitation buckets?), by locale (to
be matched with a requesting user's geoip or something?)
2. Does it make sense to group 3
bridges/bucket, so trusted users have access to 3 bridges (and untrusted
users have access to 1)? More? Less?
Hi everyone!
Here is my status report for October 2023.
We have finally released Tor Browser 13.0. I prepared that release, and
writing its changelog took me a surprising amount of time. The changes
it contains are numerous; we hope you enjoy them!
It's also the first release not to have Torbutton as a backend, and I've
written a blog post about that [0].
In addition to that, in the first half of the month, I've been doing
last-minute fixes, such as some preferences that we missed [1], a way to
allow using Tor Browser with Tor set as a proxy but without connecting
to the control port [2], fixed a build problem of Android that happened
only with the release channel [3], and a few more.
Speaking of Android, I also helped to find a way to improve its building
time when we run our reproducible builds [4].
Then, I worked a little to make the DLL blocklist file obey the portable
mode [5]. We haven't merged my proposed MR because it relied on Win32
APIs, but we might use std::filesystem instead to work around certain
limitations. I haven't done that in the first place because Firefox used
to disable it in libc++, but it has been enabled in Firefox 116, and we
might do the same to our 115 ESR and revisit the patch.
Last week, we were at the Mullvad offices for a team meeting. It was a
very productive week, and we've taken a lot of notes. We've already
published a first draft [6], but we might have to go back to it and do
some more formatting and add any missing information.
Finally, I've started hacking on Android because we want to bring the
connection assist there as well.
My dream is to unify our code base and handle both desktop and Android.
It helps feature parity, it reduces the maintenance time, and in case of
bugs, we can fix them on all our platforms at once.
I'm not sure we'll do it for the front end eventually (there have been
some discussions about that [7]), but even doing it only for the back
end would be a great help.
I've already managed to hook up a Tor daemon to the TorProvider I worked
on last Summer and also to plumb the creation of a lyrebird instance for
the domain fronting proxy. So, I'd expect it to be feasible, even though
it'll take a while to create a polished patch.
I plan to keep working on Android a little bit. I've done the first
exploration because I implemented the desktop part, so I know very well,
but I might pass it to someone else.
Then, I might go back to Mullvad Browser packaging changes.
Best,
Pier
[0] https://blog.torproject.org/torbutton-retired/
[1]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41496
[2]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42160
[3]
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4…
[4] https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40062
[5]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42163
[6]
https://gitlab.torproject.org/tpo/applications/team/-/wikis/Goteburg-2023-M…
[7]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41188