tor-project

tor-project@lists.torproject.org

9 participants
2404 discussions

PieroV's Monthly Status Report, December 2024
by Pier Angelo Vendrame 02 Jan '25

02 Jan '25

Hi everyone! Here is my status report for December 2024. This month, I finally had time for some overdue tasks that took me a long time. I started with the review of our patch set, particularly the Android part. We had some residues from the Tor integration migration and the last ESR rebase [0]. Also, some patches grew too much over time, so I split them. The resulting changes [1] were not a lot, but they were enough for a merge request. We will have to come back to this in the future. Then, I could work on fingerprinting. I finalized the patch to switch from the font "whitelist" to custom font visibility rules, matching Firefox [2]. After that, I started uplifting some of our letterboxing patches. The first ones were merged two years ago, and we want to have them in Firefox by ESR140. Also, regarding fingerprinting, I checked whether a leak of system accent color was possible [3], and set a preference as a defense in depth. During the month, I also helped to formalize the process for the rebases across all the RR versions [4][5] and attended some meetings about planning and grant proposals. Best, Pier [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43024 [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43322 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43366 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43298 [5] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests…

1 0

cve's monthly status report
by Clara Engler 02 Jan '25

02 Jan '25

Hello tor-project@, the following contains a summary of the work I have done in December 2024: * Release preparations for Arti 1.3.1 with gabi@, arti!2648, arti!2649 * Implement `--turn-secret-file` option in onionmasq, fixes onionmasq#127 * Fix clippy warnings introduced with Rust 1.83.0, onionmasq!335 * Add exclusion feature to Arti's fixup-features program, arti!2652, fixes arti#1766 * Updated several dependencies in onionmasq * Escape the coturn PID variable properly in the test suite, onionmasq!341 * Explicitly set interface in the HTTP integration test, onionmasq!340 * Hide the dangerous pcap feature behind a compile-time opt-in, fixes onionmasq#131, onionmasq!339 * Run coverage with `--all-features` enabled, onionmasq!338 * Add unit tests for config module, onionmasq!337 * Use an official Arti version in onionmasq, onionmasq!343 * Refactor device polling, onionmasq!342 * Update Arti's license year range to 2024, arti!2658 * Support for resolving local addresses in exit nodes for testing * This thing required a careful studying of the ctor source code on why it does not take `/etc/hosts` into account, despite several places in the code implying this behavior. In the end, it lead to the creation of a big ctor ticket, namely tor!40999 * Begin working on testing the DNS isolation cookie feature in onionmasq, which requires a working resolve of local addresses * Redesign the integration test suite, onionmasq!353 * Remove redundant `isolation.sh`, onionmasq!352 * IPv6 support in the integration test suite for UDP, onionmasq!351 * 38C3 related activities * Socializing with several colleagues and contributors * Watching the talk given by Gus and Hiro * Participation at the relay operator meetup on day 3 * Participation at the all-things Tor related meetup on day 4 * Freelancer bureaucracy related to the end of the year Thank You Clara

1 0

getting ready for TPA holidays
by Antoine Beaupré 20 Dec '24

20 Dec '24

Hi, So it's the most wonderful time of the year and everything... This means that we're actually coming pretty close to the holidays! TL;DR: everything will be fine, but if you need something from us before the holidays, ask now! TPA is, as usual, going to ensure some minimal rotation during the TPI holidays (December 21st to January 5th, inclusively), so we should be able to deal with emergencies. We'll have someone checking alerts and mail on a daily basis, basically. "How to report issues" doesn't change, see: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support If you're curious, you can see who's on rotation in the "TPA rotations" calendar I have just shared with TPI (an oversight). That said. If you think you might need something urgently before the holidays, it's getting *really* late to tell us now, as we're pretty much trying to wrap up everything to quiet down our infra before the holidays. So if you need anything from TPA, the time to ask for this is pretty much right now, we'll be glad to consider your request! And as the ~3 weeks pass before the holidays, we'll be less and less happy to deal with urgent "oh I just need this blog post" or "can I get a little VM cluster setup now?" right before the holidays. :) (If you need a coordinated release right before the holidays, that's fine too, but let's plan it no!) Thank you for your attention, and happy holidays! a. -- Antoine Beaupré torproject.org system administration

1 1

Tor Browser Meeting rescheduling
by Morgan 19 Dec '24

19 Dec '24

Hello everyone! Daylight savings has migrated the weekly Tor Browser meeting to an unreasonable hour for some of us, so lets move it back an hour to 1600 UTC in #tor-meeting2 in 2025. best, -morgan

1 1

Anti-censorship team meeting notes, 2024-12-19
by meskio 19 Dec '24

19 Dec '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-12-19-16.00.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday,January 9 16:00 UTC Facilitator: onyinyang ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * Azure CDN from Edgio (azureedge.net) is due to be shut down as early as 2025-01-15: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * We stopped using snowflake-broker.azureedge.net in 2021: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… * But it still receives traffic somehow: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… * onionwrapper still uses snowflake-broker.azureedge.net: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * (also, anything still using snowflake-broker.azureedge.net is using the old broker not working right now, see discussion below) * No meetings during the next two weeks. Next meeting: January 9th == Discussion == * Azure CDN from Edgio shutdown * Might make our meek builtin bridge stop working, requiring a change or removal as a default option * cohosh will follow up with micah * added a CDN77 meek bridge to the builtin bridges * going to change azure to ampcache, or sqs for China * https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_reque… * alternative domain names for CDN77 domain front * we are using phpmyadmin.net as domian front for snowflake, meek and moat * should we diversify? * https://forum.torproject.org/t/tor-and-hetzner-block-in-russia/16134/3 * tiktok domains? * in China there is a domestic version called douyin, tiktok itself may not be accessible? * shelikhoo will add support for testing domainfronts in vantage points to see what works where * snowflake-broker.azureedge.net (Edgio) became broken after being changed to point to snowflake-broker.torproject.net (the newly set up broker), because of some TLS certificate verification error between the CDN server and the broker origin. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * The suspicion is that the Edgio CDN server is, for some reason, sending a incorrect SNI ("snowflake-broker.bamsoftware.com"; i.e., the old broker, which is how it was initially set up), even though all visible configuration options have been changed to say "snowflake-broker.torproject.net" instead. * Sample SNIs reaching the broker to see if snowflake-broker.bamsoftware.com is among them? * tshark -i eth0 -f 'dst port 443' -Y 'ssl.handshake.extension.type == "server_name"' -T fields -e tls.handshake.extensions_server_name * If so, then we could point the DNS record for snowflake-broker.bamsoftware.com at the new broker, and let the new broker generate certificates for that name, for as long as the Edgio CDN still holds out. * dcf will run the tshark command and report in #40427 * covert-dtls in snowflake client and standalone proxy -- is there a plan for volunteer testing before merging? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * the recent partial blocking in Russia has ended, so asking for user testing there won't reveal whether the changed fingerprint makes a difference * but it still could be valuable to have users run with the patch as a kind of integration and interoperability test * need to test both standalone proxy and client * meskio can try running the patch on a standalone proxy * (but there's no way to get per-country statistics) * covert-dtls should be tested in both modes: randomize and mimic * theodorsm will produce instructions on how to compile and test the client with the help of cohosh * and nina will translate to post it in ntc.party == Actions == == Interesting links == * https://dl.acm.org/doi/10.1145/3589334.3645656 * Discovering and Measuring CDNs Prone to Domain Fronting (2024, open access) * https://ieeexplore.ieee.org/document/10190674 * Assessing and Exploiting Domain Name Misinformation (2023, not open access) == Reading group == * We will discuss "Discovering and Measuring CDNs Prone to Domain Fronting" on January 16th * https://dl.acm.org/doi/10.1145/3589334.3645656 * 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): 2024-12-19 Last week: - gitlab reviews and todos - more work on snowflake broker metrics improvements - handled meek builtin bridge update and azure edge shutdown This week: - afk for a few weeks dcf: 2024-12-19 Last week: - worked on making the Edgio CDN snowflake-broker.azureedge.net point to the new broker, but ran into problems with TLS certificate verification https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… - opened an issue for an error in the Snowflake Broker Survival Guide: the documented way to read the broker logs doesn't work https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - opened an issue to clean up the way multiple server names are handled on the snowflake broker https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - archived snowflake-webextension 0.9.0 and 0.9.2 https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… https://archive.org/details/snowflake-webextension-0.9.0 https://archive.org/details/snowflake-webextension-0.9.2 - answered questions from a student interested in experimenting with media streams in snowflake Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2024-12-19 Last week: - grant writting world - catching up with things from and after SplinterCon Next week: - winter break Shelikhoo: 2024-12-19 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Analysis Iran vantage point result Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Analysis Iran vantage point result onyinyang: 2024-12-19 Last week(s): - Deployed test distributor - endpoints are available @ lox-test.torproject.org - Updated lox protocols to return duplicate responses for an already seen request Next week: - Break - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096): - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-12-19 Last weeks: - WIP MR: Add covert-dtls to proxy and client - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Fix merge conflicts in MR. - Write instructions on how to configure covert-dtls with snowflake client - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake MR Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Felicia's Montly Status Report, December 2024
by Priscila 19 Dec '24

19 Dec '24

Hi everyone, I’m sending my report for December earlier since the holiday break is right at the corner. So, this month I continued working on making the need of a Moat call during connect assist more clear for users [1]. This issue is currently on review, so there’s a possibility I need to adjust something more next month. Besides that, I’ve also been working on improving the UX of the “Request bridges”flow [2], which is related to the following issues: [3] Remove the CAPTCHA from the “Request bridges” flow and [4] improve the confirmation step of the “Add new bridges” dialog. These issues are on review as well, so they’ll probably be completed next month. Lastly, I provided assistance to devs in an issue related to bootstrapping and Settings when the Tor daemon isn’t ready yet [5]. This issue branched out into 2, being the other one focused on reviewing the error prompt shown when Tor exists [6]. That’s all for now. Happy holidays! Best, Priscila (aka Felicia) - UX Team - [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42605 [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42692 [5] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41921 [6] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43186

1 0

Rhatto's Monthly Status Report, December 2024
by rhatto 18 Dec '24

18 Dec '24

Hi all :) This is my monthly status report for December 2024 with the main relevant activities I have done, was involved or are related to my work during the period. I'm sending this in advance due to the holiday break. Focus for this month was Ansible role development. ## Ansible Roles * Onionprobe Ansible role: * Released versions 0.0.2 to 0.0.6: https://gitlab.torproject.org/tpo/onion-services/ansible/onionprobe-role * Onionspray Ansible Role: * We adopted Yassine Zouggari's role, which is now hosted at https://gitlab.torproject.org/tpo/onion-services/ansible/onionspray-role * The next release is being planned: https://gitlab.torproject.org/tpo/onion-services/ansible/onionspray-role/-/… * Auxiliar roles: * Released a very simple Docker Ansible role: https://gitlab.torproject.org/tpo/onion-services/ansible/docker-role * A role for basic system setup is also available: https://gitlab.torproject.org/tpo/onion-services/ansible/basic-role * These can be useful, but there's no guarantees that they'll be maintained in the long run, as they mostly contain auxiliary system tasks. ## Other releases * Onion Launchpad 1.0.2 (a landing page for onionsites): https://onionservices.torproject.org/apps/web/onion-launchpad/changelog/#v1… * Onionbalance 0.2.3 (load balancer for Onion Services): https://forum.torproject.org/t/onionbalance-release-0-2-3/16287 * Onionspray 1.6.2 (application to serve regular websites as onionsites): https://forum.torproject.org/t/onionspray-release-1-6-2/16014 * Onionprobe 1.2.2 (an Onion Services monitoring tool): https://forum.torproject.org/t/onionprobe-release-1-2-1/16015 ## Support Did the ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. -- Silvio Rhatto pronouns he/him

1 0

TPA-RFC-74: GitLab CI retention policy
by Jérôme Charaoui 16 Dec '24

16 Dec '24

Summary: a proposal to limit the retention of GitLab CI data to 1 year # Background As more and more Tor projects moved to GitLab and embraced its continuous integration features, managing the ensuing storage requirements has been a challenge. We regularly deal with near filesystem saturation incidents on the GitLab server, especially involving CI artifact storage, such as tpo/tpa/team#41402 and recently, tpo/tpa/team#41861 Previously, [TPA-RFC-14][] was implemented to reduce the default artifact retention period from 30 to 14 days. This, and CI optimization of individual projects has provided relief, but the long-term issue has not been definitively addressed since the retention period doesn't apply to some artifacts such as job logs, which are kept indefinitely by default. [TPA-RFC-14]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/tpa-rfc-14-gitlab-artifa… # Proposal Implement a daily GitLab maintenance task to delete CI pipelines older than 1 year in *all* projects hosted on our instance. This will: * Purge old CI pipeline and job records for the GitLab database * Delete associated CI job artifacts, even those "kept" either: * When [manually prevented from expiring][] ("Keep" button on CI job pages) * When they're the [latest successful pipeline artifact][] * Delete old CI job log artifacts [manually prevented from expiring]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts#with-an-expiry [latest successful pipeline artifact]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts.md#keep-artifacts-… ## Goals This is expected to significantly reduce the growth rate of CI-related storage usage, and of the GitLab service in general. ## Affected users All users of GitLab CI will be impacted by this change. But more specifically, some projects have "kept" artifacts, which were manually set not to expire. We'll ensure the concerned users and projects will be notified of this proposal. GitLab's documentation has the [instructions to extract this list of non-expiring artifacts](https://docs.gitlab.com/ee/administration/cicd/job_artifacts_tro…. ## Timeline Barring the need to further discussion, this will be implemented on Monday, December 9th. ## Costs estimates ### Hardware This is expected to reduce future requirements in terms of storage hardware. ### Staff This will reduce the amount of TPA labor needed to deal with filesystem saturation incidents. # Alternatives considered A "CI housekeeping" script is already in place, which scrubs job logs daily in a hard-coded list of key projects such as c-tor packaging, which runs an elaborate CI pipeline on a daily basis, and triage-bot, which runs it CI pipeline on a schedule, every 15 minutes. Although it has helped up until now, this approach is not able to deal with the increasing use of personal fork projects which are used for development. It's possible to define a different retention policy based on a project's namespace. For example, projects under the `tpo` namespace could have a longer retention period, while others (personal projects) could have a shorter one. This isn't part of the proposal currently as it could violate the principle of least surprise. # References * Discussion ticket: tpo/tpa/team#41874 * [Make It Ephemeral: Software Should Decay and Lose Data](https://lucumr.pocoo.org/2024/10/30/make-it-ephemeral/)

1 1

Anti-censorship team meeting notes, 2024-12-12
by Shelikhoo 12 Dec '24

12 Dec '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-12-12-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, December 19 16:00 UTC Facilitator: meskio ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: shelikhoo == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * Azure CDN from Edgio (azureedge.net) is due to be shut down as early as 2025-01-15: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * We stopped using snowflake-broker.azureedge.net in 2021: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… * But it still receives traffic somehow: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… * onionwrapper still uses snowflake-broker.azureedge.net: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * (also, anything still using snowflake-broker.azureedge.net is using the old broker, see discussion below) * == Discussion == * Creating container mirror for anti-cenosorship projects to deal with docker hub restriction * https://gitlab.torproject.org/tpo/tpa/team/-/issues/41914#note_3138851 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * we'll create a repo in gitlab that mirrors the needed images by it's CI * WIP MR: Add covert-dtls to proxy and client * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * is a big change, shelikhoo did review it but more eyes are needed * cohosh will look into it * Reasonable PollInterval for Orbot? https://github.com/tladesignz/IPtProxy/pull/58 * standalone proxy does 5seconds poll interval * orbot was doing the same but being mobile it might be better to be slower * 120sec sounds like a good number seeing that there are already a lot of proxies new 2024-12-12 * snowflake-broker.azureedge.net is pointing to snowflake-broker.bamsoftware.com as the origin, which still points to the old Debian 10 broker (#40349). * dcf will update the Azure configuration to use snowflake-broker.torproject.net as the broker instead * dcf will delete the snowflake-broker.bamsoftware.com DNS record * Ok to turn off the old snowflake broker now? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * Yes, okay to shut it down. shelikhoo suggests turning it off but not deleting the instance for a week or so, in order to see what might still be using it. * > what was that censorship alerts mailing list? * https://lists.torproject.org/mailman3/postorius/lists/anti-censorship-alert… ? no, not that one * On Identifying Anomalies in Tor Usage with Applications in Detecting Internet Censorship * https://arxiv.org/abs/1507.05819 * https://censorbib.nymity.ch/#Wright2018a * "infolabe-anomalies", though the mailing list archives may be offline now? * GeKo: we have been in contact with the "On Identifying Anomalies" team recently, related to https://gitlab.torproject.org/tpo/network-health/team/-/issues/94 "Set up a detection and notification system of anomalies in Tor and bridge usage". * The issue on the anti-censorship-team is https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… "Add prometheus alerts to indicate potential censorship events". cohosh will contact GeKo about it. * 2009: "An anomaly-based censorship-detection system for Tor" https://research.torproject.org/techreports/detector-2011-09-09.pdf * which is what powers the censorship events at e.g. https://metrics.torproject.org/userstats-relay-country.html?start=2024-09-1… and https://metrics.torproject.org/userstats-censorship-events.html * Azure CDN from Edgio shutdown * Might make our meek builtin bridge stop working, requiring a change or removal as a default option * cohosh will follow up with micah == Actions == == Interesting links == * == Reading group == * We will discuss "" on * * Questions to ask and goals to have: * What aspects of the paper are questionable? * Are there immediate actions we can take based on this work? * Are there long-term actions we can take based on this work? * Is there future work that we want to call out in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. cecylia (cohosh): 2024-12-10 Last week: - wrote a STUN torrc check tool - https://gitlab.torproject.org/cohosh/stun-torrc-check - continued exploring options for metrics - gitlab reviews and todos This week: - work on snowflake broker metrics improvements - write a script to easily test STUN servers in snowflake's torrc - finish snowflake dependency upgrades that were causing problems - take a look at snowflake web and webext translations and best practices - make changes to Lox encrypted bridge table - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/147 Needs help with: - what was that censorship alerts mailing list? dcf: 2024-12-12 Last week: - made a graph of snowflake users in Russia in November 2024 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - snowflake azure cdn bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - commented on unreliable snowflake data channel rev2 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2024-12-05 Last week: - rdsys stopped accepting new bridges (rdsys#249) - deploy onionsproutsbot distributing TorBrowser for win7 (onionsproutsbot#64) - support webtunnel bridge operators - prepare splintercon presentations - more grant writting life - review BridgeDB deprecation blogpost Next week: - AFK at splintercon Shelikhoo: 2024-12-12 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Work on finishing snowflake container release(and fix the comments) - Incorrectly flattened container image with "pull" command https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Seperate Docker Hub mirroring to a Seperate Stagehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports… Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Analysis Iran vantage point result onyinyang: 2024-12-12 Last week(s): - Fixed up Troll-patrol MR - Worked on deploying test distributor - need to enable service on the test server Next week: - update lox protocols to return duplicate responses for an already seen request - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: in particular: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/69 - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096): - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-12-05 Last weeks: - Adjusting to post-student life - WIP MR: Add covert-dtls to proxy and client - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Test Snowflake fork with covert-dtls - Condensing thesis into paper (on hold) Help with: - Test covert-dtls in Snowflake Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0

Tor Project + SEEKCommons Fellowship Opportunity Now Available for 2025!
by gus 10 Dec '24

10 Dec '24

Hello, I'm writing to let you know that applications are now open for the second SEEKCommons Fellowship[1] cohort. The SEEKCommons Fellowship program is funded by NSF and run by partners at University of Notre Dame, University of California Davis, University of Michigan, University of Virginia, and The HDF Group. The goal of the fellowship is to bring graduate students, post-doctoral researchers, and professionals from community-based organizations with new perspectives to socio-environmental research with open technologies. Application deadline is Dec. 15, 2024. The fellowship is designed to: - Encourage new translational and integrative work involving socio-environmental action research with Open Science practices; - Provide a space for Fellows and Network members to collaborate on common research issues, challenges, and solutions. Fellows may be: - Graduate students working with open technologies on socio-environmental issues; - Post-docs with existing community projects in Science and Technology Studies, Open Science, and/or Socio-environmental research; and/or - Community practitioners who are interested in integrating common technologies into their environmental justice work. The SEEKCommons website contains all the necessary fellowship information, including the application link. https://seekcommons.org/fellowship-application.html Partnership SEEKCommons + Tor Project ===================================== This year SEEKCommons is reserving one fellowship to sustainability studies of community networks in partnership with the Tor Project! We welcome Fellowship applications on the sustainability of the Tor network with a focus on energy consumption and relay metadata (such as ASN, uptime, and platform). The goal of the partnership between SEEKCommons and Tor is to study the environmental impact of community networks and promote the use of renewable energy in decentralized infrastructures. We would like to support applications that address one (or more) of these questions: - What Free and Open Source technologies can be used to promote a more sustainable and distributed Tor infrastructure? - How can the energy consumption of the Tor network be measured and optimized to reduce its environmental impact? - How can the "Tor Snowflake" decentralized proxy model be used to improve the sustainability of the network? - How can we use metadata from relays (e.g., ASN / uptime / platform) to assess the environmental impact of the network? - What open hardware and renewable energy sources could be used/reused in the Tor network? More information: https://seekcommons.org/partnership-tor.html If you have any questions, please don't hesitate to reach out. Thank you so much! Warmly, Gus [1] https://seekcommons.org/about.html -- The Tor Project Community Team Lead

1 1

← Newer
1
...
4
5
6
7
8
9
10
...
241
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project