- tor-project - lists.torproject.org

Anti-censorship team meeting notes, 2023-05-04
by Itchy Onion 05 May '23

05 May '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-05-04-15.59.log… And our meeting pad: ------------------------------------------------------------------------------------ - THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, May 11 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == 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 - https://gitlab.torproject.org/groups/tpo/-/milestones/24 - Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it - https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == == Discussion == - Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - after a lot of research the proposed solution is to enable datagram transport on webrtc to deal with the packet loss situation - that will convert webrtc into an unreliable channel, and snowflake will add reliablity with kcp - (NO update from shell @ Apr 20) - goptlib now lives in gitlab.torproject.org == Actions == - read the safari snowflake extension code (team) - try to reach the developer (itchyonion will write an email draft, and the team will go over it) == Interesting links == - https://guardianproject.info/2023/03/04/arti-next-gen-tor-on-mobile/ - "Support for features like advanced censorship circumvention or onion services is not exactly straight forward on mobile operating systems, because they tend to be way more locked down than traditional computers. Currently, we can successfully test pluggable transports in 'managed' mode on old versions of Android. However this technique will likely not work on the latest version of Android and never worked iOS to begin with. We have shared our findings with the Arti developer team and hope they’ll work on getting us to full Pluggable Transports support, integraing with our existing IPtProxy Library soon." - Unofficial(?) Snowflake extension for Safari in Apple App Store? - https://apps.apple.com/us/app/torproject-snowflake/id1597501940 - Previously noted at https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/0… == Reading group == - We will discuss "Lox: Protecting the Social Graph in Bridge Distribution" on 2023 May 18 - https://cypherpunks.ca/~iang/pubs/lox-popets23.pdf - 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): last updated 2023-05-04 Last week: - tor meeting This week: - catch up on emails - foci stuff - open issue about archiving snowflake prometheus metrics - go over lox notes again from meeting - lox-wasm tor browser builds Needs help with: dcf: 2023-04-20 - Last week: - - did a haproxy security upgrade on snowflake-01 and snowflake-01 bridges https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - moved goptlib from git.torproject.org to gitlab.torproject.org https://lists.torproject.org/pipermail/tor-dev/2023-April/014829.html - - analyzed the rate of client_ip reporting since the release of snowflake-webext-0.7.2 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Next week: - - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - open issue to disable /debug endpoint on snowflake broker - Help with: meskio: 2023-04-20 Last week: - - update PTs to use goptlib from gitlab.tpo - - distribute bridges in rdsys even if there fewer than requested in the hashring (rdsys#162) - - add webtunnel support to BridgeDB (rdsys#142) Next week: - - tormeeting Shelikhoo: 2023-05-04 Last Week: - - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - - Finish all the accumulated task during in person meetup AFK Next Week/TODO: - - [Research] WebTunnel planning (Continue) - - Try to find a place to host another vantage point - - logcollector alert system - - webtunnel document for proxy operator - - Snowflake Performance Analysis - onyinyang: 2023-05-04 Last week: - Tor meeting This week: - - finished up implementing metrics to check on flickering resources and ratios observed (maybe) awaiting review - Working through changes to handle `gone` resources. rdsys changes are tentatively implemented, Lox library changes are more hairy. - (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 useable 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 sacrified 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? Needs Help with: - - figuring out whether or not the metrics I added to rdsys actually collect what we want them to. I can run prometheus locally but am unsure how to match this with a realistic onbasca test that can actually show whether the metrics are useful/correct. Is there a known way to do such tests other than deploy and find out? Itchy Onion: 2023-05-04 Last week: - - Costa Rica This week: - https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/112 (Some bridges are reported offline but are online and working) - - consulted network health team to understand what "offline" means from the Metrics's POV (and discovered a small wording inconsistency in their doc) - - better understood the difference between "offline" and working (they are not mutually exclusive) - hackerncoder: 2023-04-20 last week: - (py-)ooni-exporter torsf (snowflake) - (py-)ooni-exporter web_connectivity Next week: - work on "bridgetester"? - how does Iran block bridges?

1 0

Nina’s Monthly status report for April’23
by Nina 04 May '23

04 May '23

Hi! Below is my report for April 2023. In April, I resolved 759 tickets, which is 200 more than in March: On Telegram (@TorProjectSupportBot) - 556 On RT (frontdesk@tpo) - 203 Additionally, I also resolved some tickets on WhatsApp (+447421000612) and Signal (+17787431312). The majority of the tickets I deal with are related to censorship circumvention and issues that happen around it, like using VPN and bridges simultaneously or incorrect use of the bridges. Another often issue I deal with is Tor Browser and antiviruses. During the internet shutdown in Kazakhstan, I helped with the translation of the Twitter post related to the situation [1] I also communicated with users a lot, gathering feedback on different pluggable transports and the work of our services. [1] https://twitter.com/torproject/status/1645868260624306176

1 0

Rhatto's Monthly Status Report, April 2023
by rhatto 04 May '23

04 May '23

Hi all :) This is my monthly status report for April 2023 with the main activities I have done during the period. ## 0. Research * Onion Plan session in Costa Rica: * Slides and notes: https://gitlab.torproject.org/tpo/team/-/wikis/2023-Tor-Meeting-Costa-Rica-… * Issue: https://gitlab.torproject.org/tpo/onion-services/onionplan/-/issues/7 * I'd like to thank everyone that attended the session and also those who gave valuable feedback :) * Onion Plan updates: while preparing to the session, I made a number of updates, but there's still many things in the TODO list. * Website: https://tpo.pages.torproject.net/onion-services/onionplan/ * Recent changes: https://gitlab.torproject.org/tpo/onion-services/onionplan/activity * Onion-Location: problems and fixes session in Costa Rica: * Helped with note taking and with the discussion: https://gitlab.torproject.org/tpo/team/-/wikis/2023-Tor-Meeting-Costa-Rica-… ## 1. Development * Onionprobe: 1.1.0 and 1.1.1 releases: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/blob/main/Cha… * Helped with the internal Security Policy Session at the Tor In-person meeting. ## 2. Support * For the Community Day in Costa Rica, * I helped writing the `cebollitas` project, with some small Onion Services examples currently based on Docker: https://gitlab.torproject.org/tpo/onion-services/cebollitas * We had a nice workshop about setting up Onion Services and we did a small exercise about how a very basic distributed chat system could work. It was just people writing messages on HTML files and refreshing each other Onion Service tabs on their browsers, but was enough to teach the mechanics and let people know how the technology can easily enable them to send content without having to run a centralized service. * We collected feedback about how to improve the workshop and also how deploying and developing system with Onion Services technology could be made easier. ## 3. Organization Time spent (from the total available for Tor-related work): | Category | Percentage |---------------|------------ | Research | 19 | Development | 7 | Support | 17 | Organization | 57 |---------------|------------ | Total | 100 (Despite lot's of research, development and support, the Costa Rica meeting made me track most of my time as "organization" work). -- Silvio Rhatto pronouns he/him

1 0

Job Opening: OONI Project Manager
by Maria Xynou 03 May '23

03 May '23

Hello, I'm excited to share that we're hiring! The OONI team (a non-profit fighting internet censorship) is looking for a dedicated *project manager* to help us manage our software development work. *Information about the job description, qualification requirements, and how to apply* is available here: https://ooni.org/post/2023-job-opening-ooni-project-manager/ Born in 2012, OONI builds free software (OONI Probe) that enables anyone to detect and collect evidence of internet censorship. With more than 100k installs, OONI Probe is run in more than 160 countries every month. To increase transparency of internet censorship, we publish censorship measurements as open data in near real-time. This data supports research and advocacy efforts investigating and fighting internet censorship worldwide. By joining our team, you will help manage our software development work, supporting a global community measuring internet censorship. This is a *full-time 12-month contract position* (which may be extended), starting ASAP. This is a *fully remote position*. We encourage applications from anywhere in the world! Applications are reviewed on a rolling basis. Please spread the word ( https://twitter.com/OpenObservatory/status/1653444903462895631) and help us find someone who can best serve the internet freedom community! Thank you, OONI team.

1 0

PieroV's Monthly Status Report, April 2023
by Pier Angelo Vendrame 02 May '23

02 May '23

Hi everyone! Here is my status report for April 2023. At the beginning of the month, Mullvad Browser was released 🎉️! So, I answered several technical questions about it and reviewed some of the issues we received. I also solved some quick ones. Also, I rebased both Tor Browser and Mullvad Browser to 102.10esr and created the first 12.5 alpha branch for Mullvad Browser. I was the second builder for Tor Browser 12.5a5, which made us find another DMG reproducibility problem [0]. A merge request to fix it is pending review. Another task was continuing with some Torbutton refactors. I want to move the code out of the big legacy commit and refactor it. I created a first merge request that targets the first 13.0 branch for the changes on the domain isolator/new circuit button [1]. However, I am pausing the refactor to focus again on upstreaming patches [2]. In a week, Firefox 115 is going to Nightly, and we are starting the ESR rebase for 13.0. This will give us two additional months to work on it, for a total of 5 months before 102 goes EOL. I think I will spend this month on this. Finally, last week I was at the Costa Rica in-person meeting [3]. Best, Pier [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41737 [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40789 [3] https://gitlab.torproject.org/tpo/team/-/wikis/2023-Tor-Meeting-Costa-Rica-…

1 0

Constructing a real-world dataset for studying website fingerprinting
by Jansen, Robert G CIV USN NRL (5543) Washington DC (USA) 27 Apr '23

27 Apr '23

Hello Tor friends, We are planning to construct a real-world dataset for studying Tor website fingerprinting that researchers and developers can use to evaluate potential attacks and to design informed defenses that improve Tor’s resistance to such attacks. We believe the dataset will help us make Tor safer, because it will allow us to design defenses that can be shown to protect *real* Tor traffic instead of *synthetic* traffic. This will help ground our evaluation of proposed defenses in reality and help us more confidently decide which, if any, defense is worth deploying in Tor. We have submitted detailed technical plans for constructing a dataset to the Tor Research Safety Board and after some iteration have arrived at a plan in which we believe the benefits outweigh the risks. We are now sharing an overview of our plan with the broader community to provide an opportunity for comment. More details are below. Please let us know if you have comments. Peace, love, and positivity, Rob P.S. Apologies for posting near the end of the work-week, but I wanted to get this out in case people want to talk to me about it in Costa Rica. === BACKGROUND Website fingerprinting attacks distill traffic patterns observed between a client and Tor entry into a sequence of packet directions: -1 if a packet is sent toward the destination, +1 if a packet is sent from toward the client. An attacker can collect a list of these directions and then train machine learning classifiers to associate a website domain name or url with the particular list of directions observed when visiting that website. Once it does this training, then when it observes a new list of directions it can use the trained model to predict which website corresponds to that pattern. For example, suppose [-1,-1,+1,+1] is associated with website1 and [-1,+1,-1,+1] is associated with website2. There are two steps in an attack: Step 1: In the first step the attacker itself visits website1 and website2 many times and learns: [-1,-1,+1,+1] -> website1 [-1,+1,-1,+1] -> website2 It trains a machine learning model to learn this association. Step 2: In the second step, with the trained model in hand, the attacker monitors a Tor client (maybe the attacker is the client’s ISP, or some other entity in a position to observe a client’s traffic) and when it observes the pattern: [-1,-1,+1,+1] the model will predict that the client went to website1. This example is *extremely* simplified, but I hope gives an idea how the attack works. PROBLEM Because researchers don’t know which websites Tor users are visiting, it’s hard to do a very good job creating a representative dataset that can be used to accurately evaluate attacks or defenses (i.e., to emulate steps 1 and 2). The standard technique has been to just select popular websites from top website lists (e.g., Alexa or Tranco) and then set up a Tor webpage crawler to visit the front-pages of those websites over and over and over again. Then they use that data to write papers. This approach has several problems: - Low traffic diversity: Tor users don’t only visit front-pages. For example, they may conduct a web search and then click a link that brings them directly to an internal page of a website. The patterns produced from front-page visits may be simpler and unrepresentative of the patterns that would be observed from more complicated internal pages. - Low browser diversity: It has been shown by research from Marc Juarez [0] and others that webpage crawlers used by researchers lack diversity in important aspects that cause us to overestimate the accuracy of WF attacks. For example, the browser versions, configuration choices, variation in behavior (e.g., using multiple tabs at once), and network location of the client can all significantly affect the observable traffic patterns in ways that a crawler methodology does not capture. - Data staleness: Researchers collect data over a short time-frame and then evaluate the attacks assuming this static dataset. In the real world, websites are being updated over time, and a model trained on an old version of a website may not transfer to the new version. In addition to the above problems in methodology, current research also causes incidental consequences for the Tor network: - Network overhead: machine learning is a hot topic and several research groups have crawled tens of thousands of websites over Tor many times each. While each individual page load might be insignificant compared with the normal usage of Tor, crawling does add additional load to the network and can contribute to congestion and performance bottlenecks. Researchers have been designing attacks that are shown to be extremely accurate using the above synthetic crawling methodology. But because of the above problems, we don’t properly understand the *true* threat of the attack against the Tor network. It is possible that the simplicity of the crawling approach is what makes the attacks work well, and that the attacks would not work as well if evaluated with more realistic traffic and browser diversity. PLAN So our goal is to construct a real-world dataset for studying Tor website fingerprinting that researchers and developers can use to evaluate potential attacks and to design informed defenses that improve Tor’s resistance to such attacks. This dataset would enable researchers to use a methodology that does not have any of the above limitations. We believe that such a dataset will help us make Tor safer, because it will allow us to design defenses that can be shown to protect *real* Tor traffic instead of *synthetic* traffic. This would lead to a better understanding of proposed defenses and enable us to more confidently decide which, if any, defense is worth deploying in Tor. The dataset will be constructed from a 13-week exit relay measurement that is based on the measurement process established in recent work [1]. The primary information being measured is the directionality of the first 5k cells sent on a measurement circuit, and a keyed-HMAC of the first domain name requested on the circuit. We also measure relative circuit and cell timestamps (relative to the start of measurement). The measurement data is compressed, encrypted using a public-key encryption scheme (the secret key is stored offline), and then temporarily written to persistent storage before being securely retrieved from the relay machine. We hope that this dataset can become a standard tool that website fingerprinting researchers and developers can use to (1) accelerate their study of attacks and defenses, and (2) produce evaluation and results that are more directly applicable to the Tor network. We plan to share it upon request only to other researchers who appear to come from verifiable research organizations, such as students from well-known universities. We will require researchers with whom we share the data to (1) keep the data private, and (2) direct others who want a copy of the data to us to mitigate unauthorized sharing. [0] A Critical Evaluation of Website Fingerprinting Attacks. Juarez et al., CCS 2014. https://www1.icsi.berkeley.edu/~sadia/papers/ccs-webfp-final.pdf [1] Online Website Fingerprinting: Evaluating Website Fingerprinting Attacks on Tor in the Real World. Cherubin et al., USENIX Security 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/cherubin

3 6

Anti-censorship team meeting notes, 2023-04-20
by Shelikhoo 20 Apr '23

20 Apr '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-04-20-15.58.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, May 4 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == 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 * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == - We will not have a meeting on IRC next week, next meeting will be at May 4 == Discussion == * Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * after a lot of research the proposed solution is to enable datagram transport on webrtc to deal with the packet loss situation * that will convert webrtc into an unreliable channel, and snowflake will add reliablity with kcp * (NO update from shell @ Apr 20) * goptlib now lives in gitlab.torproject.org == Actions == == Interesting links == * == Reading group == * We will discuss "Lox: Protecting the Social Graph in Bridge Distribution" on 2023 May 18 * https://cypherpunks.ca/~iang/pubs/lox-popets23.pdf * 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): last updated 2023-04-20 Last week: - Some FOCI stuff - reviewed snowflake-webext!63 - reviewed some library update MRs This week: - Tor meeting Needs help with: dcf: 2023-04-20 Last week: - did a haproxy security upgrade on snowflake-01 and snowflake-01 bridges https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - moved goptlib from git.torproject.org to gitlab.torproject.org https://lists.torproject.org/pipermail/tor-dev/2023-April/014829.html - analyzed the rate of client_ip reporting since the release of snowflake-webext-0.7.2 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2023-04-20 Last week: - update PTs to use goptlib from gitlab.tpo - distribute bridges in rdsys even if there fewer than requested in the hashring (rdsys#162) - add webtunnel support to BridgeDB (rdsys#142) Next week: - tormeeting Shelikhoo: 2023-04-20 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - [Merge Request] container image for webtunnel (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) (Done) - reviewing moving to goptlib to gitlab PRs - consider propagating 2FA everywhere, maybe, at the April Tor Meeting (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41083#note_2884138) (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41125) Next Week: - [Research] WebTunnel planning (Continue) - Try to find a place to host another vantage point - logcollector alert system - webtunnel document for proxy operator - Costa Rica Meetup!!! onyinyang: 2023-04-20 Last week: - worked on handling `gone resources` in a more appropriate way for Lox as outlined here: https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/issues… - work on implementing metrics to check on flickering resources and ratios observed - work on marking as `gone`, failing/low-bandwidth resources that are no longer distributed - worked on presentation for Lox overview and discussing more challenging problems of Lox that could benefit from AC team brainstorming: This week: - Tor meeting -If time (and functionality above is in place): - If a bridge is `gone` due to bandwidth issues or descriptors not being published, replace them with working bridges in Lox--this will have implications for syncing with rdsys but first things first :) (long term) - 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 useable 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 sacrified 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? Itchy Onion: 2023-04-13 Last week: - Vacation This week: - Experimenting with additional SDP tests after discussion on MR #141 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Learning about rdsys - Started working on #110 (treat unknown bridge distribution request as "none") hackerncoder: 2023-04-20 last week: - (py-)ooni-exporter torsf (snowflake) - (py-)ooni-exporter web_connectivity Next week: - work on "bridgetester"? - how does Iran block bridges

1 0

Anti-censorship team meeting notes, 2023-04-13
by Itchy Onion 17 Apr '23

17 Apr '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-04-13-15.58.log… And our meeting pad: Anti-censorship work meeting pad ------------------------------------------------------------------------------------ - THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, April 13 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == 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 - https://gitlab.torproject.org/groups/tpo/-/milestones/24 - Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it - https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == == Discussion == - Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - after a lot of research the proposed solution is to enable datagram transport on webrtc to deal with the packet loss situation - that will convert webrtc into an unreliable channel, and snowflake will add reliablity with kcp - (NO update from shell @ Apr 13) == Actions == == Interesting links == - == Reading group == - We will discuss "Lox: Protecting the Social Graph in Bridge Distribution" on 2023 May 18 - https://cypherpunks.ca/~iang/pubs/lox-popets23.pdf - 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): last updated 2023-04-13 Last week: - released a new version of snowflake-webext (0.7.2) - added CI and renovate bot to Conjure - debugged wireguard setup and confirmed it works - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - fixed a bug where SOCKS handles were being leaked in Conjure - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - Added a content security policy to webextension - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Opened an upstream issue in gotapdance to restore functionality lost in a version upgrade - https://github.com/refraction-networking/gotapdance/issues/113 This week: - Lox tor browser integration - conjure maintenance Needs help with: dcf: 2023-04-13 - Last week: - - posted performance measurements of a QueuePacketConn optimization and merged it https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - made a graph of snowflake proxy NAT types over time, which highlights the times when probetest was failing and there was an increase in "unknown" NAT types https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - archived snowflake-webextension-0.7.2 https://archive.org/details/snowflake-webextension-0.7.2 - Next week: - - migrate goptlib to gitlab https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/86#note_282… (for real) - - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - - open issue to disable /debug endpoint on snowflake broker - Help with: meskio: 2023-04-13 Last week: - - configure rdsys to distribute webtunnel bridges (rdsys#142) - - set up a webtunnel bridge to test - - review and merge a bunch of renovate MRs in rdsys - - brainstorm on pinning TLS certs in Tor Browser for bridges.torproject.org (tpa/team#41123) - - review bridgestrap aggressive retry for dysfunctional bridges (bridgestrap!16) - - review snowflake webextension CSP (webext!66) - - sponsor 96 report - - grant application work... Next week: - - distribute webtunnel bridges in BridgeDB Shelikhoo: 2023-04-13 Last Week: - - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - - [Merge Request] container image for webtunnel (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…) - - [Research] Fix crash on launch when unexpected input was supplyed over PT protocol https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt… - - Write S96 report - - Comment on S96 User Research Risk Assessment Next Week: - - [Research] WebTunnel planning (Continue) - - Try to find a place to host another vantage point - - container image for webtunnel - - consider propagating 2FA everywhere, maybe, at the April Tor Meeting (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41083#note_2884138) - - logcollector altert system - - webtunnel document for proxy operator - onyinyang: 2023-04-13 Last week: - worked on handling `gone resources` in a more appropriate way for Lox as outlined here: https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/issues… - implemented a more aggressive testing schedule for failing bridgestrap resources https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/merge_reque… - discovered that failed/low bandwidth resources are quietly marked to not be distributed and so don't show up as `gone` - discussed implementing metrics to check how frequently badwidth ratio causes resources to "flicker" tracked here: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/160 This week: - work on implementing metrics to check on flickering resources - work on marking as `gone`, failing/low-bandwidth resources that are no longer distributed -If time (and functionality above is in place): - - If a bridge is `gone` due to bandwidth issues or descriptors not being published, replace them with working bridges in Lox--this will have implications for syncing with rdsys but first things first :) - - (long term) - - 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 useable 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 sacrified 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? Itchy Onion: 2023-04-13 Last week: - - Vacation This week: - Experimenting with additional SDP tests after discussion on MR #141 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Learning about rdsys - Started working on #110 (treat unknown bridge distribution request as "none") - hackerncoder: 2023-03-09 last week: Next week: - getting ooni-exporter to work with torsf (snowflake) - ooni-exporter web_connectivity - work on "bridgetester"? - how does Iran block bridges

1 0

Tor Browser Meeting Cancelled this Week (2023-04-10)
by Richard Pospesel 10 Apr '23

10 Apr '23

Hi everyone, The browser meeting is cancelled this week but will be back next week (2024-04-17) at 1500 UTC in #tor-meeting in OFTC IRC. best, -Richard

1 0

Anti-censorship team meeting notes, 2023-04-06
by Shelikhoo 06 Apr '23

06 Apr '23

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-04-06-15.59.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------ THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------ Anti-censorship -------------------------------- Next meeting: Thursday, April 13 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == 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 * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel working on it * https://pad.riseup.net/p/sponsor139-meeting-pad == Announcements == == Discussion == * Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * after a lot of research the proposed solution is to enable datagram transport on webrtc to deal with the packet loss situation * that will convert webrtc into an unreliable channel, and snowflake will add reliablity with kcp * (NO update from shell @ Apr 6) == Actions == == Interesting links == * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… == Reading group == * We will discuss "Lox: Protecting the Social Graph in Bridge Distribution" on 2023 May 18 * https://cypherpunks.ca/~iang/pubs/lox-popets23.pdf * 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): last updated 2023-03-30 Last week: - enabled wasm target for rust in tor-browser-build - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… - helped debug blocking of Snowflake in TM - https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… - discussed the problem of deciding whether a bridge is blocked or not - took a look at memory issues for the Snowflake proxy - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… This week: - Lox tor browser integration - fix conjure issues found by code audit Needs help with: dcf: 2023-04-06 Last week: - wrote notes on WebRTC unreliable data channels https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - made graphs of DTLS packet losses in China https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - revised snowflake-server listen error check fix and merged it https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - documented more cdn.sstatic.net anomalies in Iran in March 2023 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_28… - wrote the March 2023 update for the snowflake-01 Open Collective https://opencollective.com/censorship-circumvention/projects/snowflake-dail… - wrote a sync.Pool performance optimization for snowflake QueuePacketConn and started bridge-side CPU and RAM measurements in advance of a test deployment https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - made a graph of snowflake users from Russia since the DTLS fingerprint fix (Hello Verify Request) in Tor Browser 12.0.3 (still awaiting an Orbot release) https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Next week: - migrate goptlib to gitlab https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/86#note_282… (for real) - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2023-04-06 Last week: - AFK time Next week: - webtunnel integration in rdsys Shelikhoo: 2023-04-06 Last Week: - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) - [Research] HTTPT Planning https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… - Comment on S96 User Research Risk Assessment - Comment on various grant proposal - Write grant report - Fix Telegram Bridge Distributor responding with a blank message https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/158 - Work on TPA-RFC-53: consider propagating 2FA everywhere, maybe at the April Tor Meeting - X~X time was mostly spent on urgent task Next Week: - [Research] WebTunnel planning (Continue) - Try to find a place to host another vantage point - container image for webtunnel - consider propagating 2FA everywhere, maybe, at the April Tor Meeting (https://gitlab.torproject.org/tpo/tpa/team/-/issues/41083#note_2884138) - logcollector altert system - webtunnel document for proxy opertator onyinyang: 2023-04-06 Last week: - Did a deep dive into rdsys to understand how it is handling `new`, `changed`, `gone` resources some results/discussion here: https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/issues… - updated Lox library, rdsys-backend-api and lox distributor to handle new and changed resources in a way that is more aligned with rdsys' behaviour - added some preliminary documentation: https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/wikis/… This week: - work on handling `gone resources` in a more appropriate way for Lox as outlined here: https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/issues… -If time: Start implementing a function in lox distributor/lox library to handle syncing of Lox bridgetable Needs help with: (medium term) Question 1: re: `gone` resources: under what circumstances should a `gone` bridge be replaced? - If a bridge is `gone` due to bandwidth issues or descriptors not being published, should they be replaced with working bridges in a Lox bucket ? Question 2: How easily can a censor manipulate the bridgepool/bridges to create a `gone` resource? - Does replacing bridges, especially at the untrusted user level, create an enumeration risk? My thought is that `gone` bridges should be replaced if they are determined to be unusable into the future (not just temporarily down) and the bucket risks becoming "unreachable" and requiring users to move to a new bucket. Maybe this should only be true for trusted users though? (long term) - 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 useable 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 sacrified 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? Itchy Onion: 2023-03-22 Last week: - Closed #40252 (NAT probetest for standalone proxy) - Closed #40265 (mac user reporting standalone proxy complaning about broker cert) - Worked on #40231 (Client sometimes send offer with no ICE candidates) This week: - Tested and created a potential broker security issue (#40266) - Stil working on #40231 -- validate SDP contains candidate at the "/client" and "/answer" endpoints broke almsost all of the unit tests hackerncoder: 2023-03-09 last week: Next week: - getting ooni-exporter to work with torsf (snowflake) - ooni-exporter web_connectivity - work on "bridgetester"? - how does Iran block bridges

1 0