tor-project

tor-project@lists.torproject.org

16 participants
2324 discussions

cohosh's monthly status report, October 2023
by Cecylia Bocovich 05 Nov '23

05 Nov '23

Hi! This is my status report for contract work done in October 2023. # Reputation-based bridge distribution - Deployed the lox distributor in production - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/167 - Updated the rdsys survival guide with information on how to deploy new frontend services - https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… - Met with the UX team to discuss Lox UX - Reviewed the addition of prometheus metrics to the lox distributor - Continued Tor Browser integration with Lox client - Had to rebase and work around the new Firefox CSP - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/34 # Snowflake - Worked with OONI to update domain front used for Snowflake tests - https://github.com/ooni/probe-cli/pull/1337 - Looked into the blocking of foursquare.com and other potential fronts - Changed proxy stats and metrics to report throughput during the last hour - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Reviewed Snowflake outbound proxy support - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Found and fixed a regression in the Snowflake client caused by supporting multiple domain fronts - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 0

OONI Monthly Report: October 2023
by Maria Xynou 03 Nov '23

03 Nov '23

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.

1 0

Nina’s Monthly Status Report: October 2023
by Nina 02 Nov '23

02 Nov '23

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

1 0

Anti-censorship team meeting notes, 2023-11-02 [FIXED]
by Shelikhoo 02 Nov '23

02 Nov '23

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?

1 0

Anti-censorship team meeting notes, 2023-11-02
by Shelikhoo 02 Nov '23

02 Nov '23

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?

1 0

Anti-censorship team meeting notes, 2023-10-05
by meskio 02 Nov '23

02 Nov '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-28-15.57.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Oct 12 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?s… * 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_na… == Announcements == == Discussion == - Update on snowflake domain fronting issues: - https://github.com/guardianproject/orbot/releases/tag/17.1.0-RC-1-tor.0.4.7… - "Fix snowflake Fastly and Moat Activity front" https://github.com/guardianproject/orbot/commit/594c49edc0ee7c702852aac2c14… - at this point, this release is apparently only available by sideloading an APK https://lists.mayfirst.org/pipermail/guardian-dev/2023-October/005712.html - problem with cdn.sstatic.net affected more than just snowflake, also moat, conjure (no deployment change required) - fixed in new tor browser update, but some users relying on snowflake/moat bridges will be unable to update - foursquare.com seems to not work in Iran? Do we need to update this for Moat so that users can access circumvention settings? - https://lists.mayfirst.org/pipermail/guardian-dev/2023-October/005712.html "I am getting reports though that the new front domain chosen may not be reachable in Iran" - https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measu… - https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/00… "On snowflake-01, not all countries were equally affected. Russia and China had bigger relative decreases than Iran did." - relying on a the same new front may be detrimental to improve connection issues for some users, perhaps a pool of randomly selected domains would improve the situation: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - we are thinking about caching the most recently working front domain, so that the selection is only random the first time, and it doesn't hurt so much if a broken/blocked domain gets in the list - we have asked OONI about github.githubassets.com, they said it was throttled in Iran 1.5 years ago - currently, if the circumvention API ("smart connect"?) returns a snowflake bridge, Orbot uses its own built-in snowflake settings rather than the ones returned by the API https://github.com/guardianproject/orbot/issues/983 - short term: what, if anything, to do about Moat? - switch to githubassets for next release - test in alpha first? - cdn.sstatic.net no longer resolving to a mix of fastly and cloudflare in ooni tests, just cloudflare now - snowflake-02 not getting as much use as before - why? - https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… - until yesterday, 2023-10-04 ~12:00, it suddenly popped up - https://share.riseup.net/#2ycoKPORT4HuqeHMnnMJOw - about 4 hours after a reboot of snowflake-01, related? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - future of PTs, plugins vs. different processes over the network - https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/130 - Remove proxy churn measurement - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - (Network Health) 'Running' flag for counting bridges and network size https://gitlab.torproject.org/tpo/network-health/team/-/issues/318 == Actions == == Interesting links == * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… == 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): 2023-10-05 Last week: - opened PR to update domain front for OONI snowflake tests - https://github.com/ooni/probe-cli/pull/1337 - met with ooni to discuss tor ooni tests - more work on deploying the lox distributor - updated MR to randomly select front domain from a list - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - looked into blocking of foursquare.com and alternative fronts This week: - deploy lox distributor - follow up on conjure reliability issues - visualize and write up some snowflake shadow simulation results Needs help with: dcf: 2023-10-05 Last week: - posted a note in the forum about the fastly domain front issue https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-bro… - wrote an email speculating about possible reasons why snowflake-01 and snowflake-02 were unequally affected: https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/… 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-05 Last week: - fix lyrebird dependencies (lyrebird!14) - add authentication token to onbasca-rdsys communication (rdsys#174) - release and deploy a new version of rdsys Next week: - test the whatsapp bot (rdsys#147) Shelikhoo: 2023-10-05 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled) - Write Tor Spec for Armored URL (continue) - Merge request reviews - Finally write a script to automatically merge bot MR: https://gist.githubusercontent.com/xiaokangwang/eecf2c7c9a6bc57a8bf5fe3b7a2… Next Week/TODO: - Write Tor Spec for Armored URL (continue) - Merge request reviews onyinyang: 2023-10-05 Last week(s): - Finished changes to rdsys API at the /resources endpoint to meet the needs of Lox - Finished up required changes to lox-distributor - Still need to merge the updated dependencies and make MR to upstream ZK lib: - fixed bug (? hopefully this can be reviewed) in the zkp crate - will make MRs to both dalek-cryptography and zkcrypto and maintain a new fork This week: - Finish up with the dependencies issue - Continue with metrics - Time permitting, start work on telegram distributor bot for Lox (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? -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

2 2

Rhatto's Monthly Status Report, October 2023
by rhatto 01 Nov '23

01 Nov '23

Hi all :) This is my monthly status report for October 2023 with the main relevant activities I have done during the period. ## 0. Research ### Onion Plan * Renamed section "Roadmaps" to "Scenarios", since The Onion Plan is not an authoritative instance for defining roadmaps. Instead, it merely produces research studies and scenarios: https://tpo.pages.torproject.net/onion-services/onionplan * Started to work again on Onion Discovery, trying to draft a plan for it. More info about discovery is available at https://tpo.pages.torproject.net/onion-services/onionplan/proposals/usabili… https://tpo.pages.torproject.net/onion-services/onionplan/scenarios/discove… * Other minor improvements. ### Tor Browser Quality Assurance for Onion Services * Did a presentation during the Applications Team meetup: https://gitlab.torproject.org/tpo/applications/team/-/wikis/Goteburg-2023-M… * Ongoing QA activities. ## 1. Development ### Onionbalance * Basic maintenance, including contact info update, fixing the GitHub mirror, adding GitLab CI and other improvements to avoid bit rotting: https://gitlab.torproject.org/tpo/onion-services/onionbalance/activity ### Onion MkDocs * General enhancements: https://gitlab.torproject.org/rhatto/onion-mkdocs/activity ## 2. Support ### Maintenance * Ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. ## 3. Organization Time spent (from the total available for Tor-related work): | Category | Percentage |---------------|------------ | Research | 44 | Development | 6 | Support | 13 | Organization | 37 |---------------|------------ | Total | 100 -- Silvio Rhatto pronouns he/him

1 0

PieroV's Monthly Status Report, October 2023
by Pier Angelo Vendrame 01 Nov '23

01 Nov '23

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

1 0

Online Tor's Hackweek - Nov 6th to Nov 19th, 2023
by Tyler Corn 31 Oct '23

31 Oct '23

Hi everyone 🙂 More friendly reminders about Hackweek (happening Nov 6th - 9th): (1) Like Pavel mentioned, don't forget to add your Hackweek project proposal to the issue queue in Gitlab this week (see Rhatto's Aug. 30 email below); (2) If you don't have a Hackweek documentation project proposal, you can join someone else's proposed project; (3) Next week's All Hands Meeting (November 1st) - (after the Finance Update) each Hackweek project proposer will have about 5 minutes to present their submitted project and everyone will have a chance to ask questions; and (4) Project proposers - be thinking about where your group will be meeting (BBB room?) during Hackweek (on Nov. 6th) and what time folks will start working on the projects. Thanks everyone! Best, Tyler On 8/30/2023 11:13 AM, rhatto wrote: Hi! The Tor Project and Tor community is going to be gathering online from November 6th to November 9th this year for a 4 days hackweek. ## About This is a call for projects for whoever wants to participate, put together a team and hack through one working week with us. In the context of this hackweek, a project is anything related to Tor documentation that you can work with other people in 4 days. It could be improving the documentation for a project, a tutorial or could also be a cartoon, a screencast or anything that do not necessary requires coding skills. You will work on this project during 4 days with other people in your team. This is an opportunity to discuss how documentation is working or not in your projects, as well as thinking, proposing, researching and testing solutions. Documentation is very important for any free software project as it is the way for people to start understanding the work we are doing, the way they can use our tools and start contributing with it. In the next All-Hands following the Hackweek we are going to have a demo in a Big Blue Button's room where your team will present the work you did through the hackweek. ## Timeline This will be the timeline for the hackweek this year: * Until Monday, November 6th: * Send hackweek project proposals to this issue queue: https://gitlab.torproject.org/tpo/community/hackweek/-/issues (please use the "Proposal" issue template for the ticket Description). * Before hackweek begins, start looking for other people to join your team. * In order to join a proposal you liked, subscribe yourself to it's ticket. * Wednesday, November 1st - 16:00 UTC: All-Hands session prior to the Hackweek were people/teams will present their project proposals for other people to join their team if they want to. * Monday, November 6th: Hackweek begins. People start working on whatever they want related to documentation. By this time, you should have a few members of your team already identified. Hack hack hack hack... in whatever way you organize yourself. We will have the room #tor in irc.oftc.net to discuss general hackweek things. * Thursday, November 9th: Hackweek ends. * Wednesday, November 15th - 16:00 UTC: Each team presents the work they did in the All-Hands session happening after the Hackweek. ## Projects The updated list of projects will be available at https://gitlab.torproject.org/tpo/community/hackweek/-/issues. Each project can have one pad (you can usehttps://pad.riseup.net) and also use it's ticket to add all information that people need to add themselves to that project. ## References For best practices on documentation, we recommend the following material: * Diátaxis, "The Grand Unified Theory of Documentation": https://diataxis.fr/ * How to pick up a project with an audit: https://bluesock.org/~willkg/blog/dev/auditing_projects.html cheers, -- Silvio Rhatto pronouns he/him

1 1

Tor Browser Meeting Cancelled 2023-10-30
by richard 27 Oct '23

27 Oct '23

Hey Everyone, I think we've met enough for one week, so let's cancel our meeting next week and think about things that are not browser related. The next meeting will be the following week, 2023-11-06 at 1500 UTC in OFTC IRC per usual. best, -richard

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project