- tor-project - lists.torproject.org

Anti-censorship meeting notes, 03 Dec, 2020
by Cecylia Bocovich 03 Dec '20

03 Dec '20

Hey everyone, Here is our meeting log: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-12-03-15.59.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday December 3rd 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 checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at Tor. == 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 30 https://gitlab.torproject.org/groups/tpo/-/milestones/4 https://gitlab.torproject.org/groups/tpo/-/milestones/7 https://gitlab.torproject.org/groups/tpo/-/milestones/5 https://gitlab.torproject.org/groups/tpo/-/milestones/6 Sponsor 28 must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10 possible tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&… Anti-censorship related tickets that we want other teams to fix: https://pad.riseup.net/p/tor-anti-censorship-tickets-keep <-- it will be moved into gitlab with TPO labels <-- do we still need this? The label is 'for anticensorship team' Public bug-reporting pad: https://pad.riseup.net/p/tor-anti-censorship-bugs-keep == Announcements == https://bridges.torproject.org/status?id=FINGERPRINT now online Tor bridges will log this URL to help operators figure out if their bridge works. Currently only works for obfs2, obfs3, obfs4, and scramblesuit; not vanilla. == Discussion == == Actions == Take a look at our monthly report and add/modify content as you see fit: https://pad.riseup.net/p/U4o0LNYPgm7SCxuF-1Sm == Interesting links == == Reading group == We will discuss "Poking a Hole in the Wall: Efficient Censorship-Resistant Internet Communications by Parasitizing on WebRTC" on Dec 3 https://dl.acm.org/doi/pdf/10.1145/3372297.3417874 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. phw: This week (2020-12-03): Made it possible to look up resource status by hashed fingerprint. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/28 Brainstormed ways to stream bridge updates to polyanthum. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/9 Deployed Prometheus metrics for bridgestrap. They are publicly accessible: https://bridges.torproject.org/bridgestrap-metrics https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/4 Wrote a patch that makes Snowflake's broker order its snowflake-ips metrics by value. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Made rdsys's supported resources configurable. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/29 Improved bridgestrap's metrics to make them more in line with what Prometheus recommends. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/10 Wrapped up bridgestrap deployment. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/5 Wrote November 2020 report. Started implementing metrics for rdsys. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/14 Next week: Reach out to a few folks to have emma run in different places. Deploy bridgestrap and rdsys, and expose bridge status page. Progress on Salmon. Help with: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/10 cecylia (cohosh): last updated 2020-12-03 Last week: - created tor-browser-build!129 - reviewed snowflake-mobile!16 - reviewed bridgestrap!3 - created snowflake#40023 and a fix snowflake!20 - created snowflake!21 for snowflake#40018 - did some work on multiplexing (snowflake#25723) - worked on avoiding double delays (snowflake#34080) - wrote probetest installation and survival guides: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… - sponsor 28 meetings This week: - continue to monitor snowflake stats - Figure out why we still have unknown proxies - follow up on progress towards a telegram bot for gettor - have broker inform proxies when to poll (snowflake#25598) - Finish work on avoiding double delays (snowflake#34080) - Continue snowflake multiplexing work (snowflake#25723) - Review snowflake!22 Needs help with: - review of snowflake!21 juggy : This week: - Got very basic "suggested readings" list up and running here : https://jugheadjones10.github.io/anti-censorship-reading/ Next week: - Keep studying BridgeDB to write architectural overview Help with: - Open issues here (https://github.com/jugheadjones10/anti-censorship-reading ) for papers/resources/readings that you think might be useful for newcomers arlolra: 2020-10-29 Last week: - Next week: - getting back up to speed - follow ups to #33365 - start on #31201 Help with: - dcf: 2020-12-03 Last week: - archived snowflake-webextension-0.5.2 - reviewed client NAT type reclassification https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed Snowflake client loop restructuring https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: Help with: Antonela: 2020-08-27 This week: - Wrapping Babatunde's research on the use of circumvention tools during internet censorship in Africa. Wrapping Personas for s30 with it. For september: - We are planning interviews with users in China to run our bridges discovery issues script in real time. We discussed to include TBA + snowflake as a task for users to run over a week or two and report back. https://gitlab.torproject.org/tpo/ux/research/-/issues/4 - I still have bridges.tpo to lektor issue open - More work on UX/UI for TB 10.0/10.5 - Review Salmon related tickets (im late with it!) agix:2020-12-03 Last week: -Gathered ideas for httpt issue #4 -Dug deeper into Go (found some nice resources) -Read this weeks paper Next week: -Find new rdsys ticket Help with: -Review of https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/5 -(Optional) Some feedback on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/http… hanneloresx: 2020-10-22 Last week: - Took break to focus on work Next week: - #32117: Look at CAPTCHA success rate for users from the US across different types of bridges Help with: - thymbahutymba: 2020-04-02 Last week: - CI/CD pipeline for multiarch docker images, which has a problem with the apt tor version even though the apt repository have been changed into the Dockerfile. Next week: Help with: HashikD: 2020-11-19 This week: - Next week: - Research on how to implement a STUN check on Android. Help with: -

1 0

OONI Monthly Report: September 2020
by Maria Xynou 27 Nov '20

27 Nov '20

Hello, Below we share OONI's September 2020 status report. Sincere apologies for the huge delay (our team has been quite swamped these past few months)! Our October 2020 report will follow soon too. # OONI Monthly Report: September 2020 Throughout September 2020, the OONI team worked on the following sprints: * Sprint 21 - Steve Z. (31st August 2020 - 13th September 2020) * Sprint 22 - Ποσειδάων (14th September 2020 - 27th September 2020) Our work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. ## Migrating OONI infrastructure to Amsterdam One of our top priorities in September 2020 was the migration of critical OONI infrastructure (hosting the OONI data processing pipeline) to servers in Amsterdam, and updating the OONI PostgreSQL metaDB to adapt it to the requirements of our new data processing pipeline. We worked towards replacing the batch OONI data processing pipeline with our new fastpath pipeline, which analyzes and publishes OONI measurements from around the world in real-time (the measurements are published as soon as the report is closed). To this end, we built a new PostgreSQL metaDB, which is powered by the latest version of PostgreSQL (11) available in debian stable, and which uses a different set of tables (based on our improved, fastpath pipeline). More specifically, our work related to migrating OONI infrastructure involved: * Implementing a fast-path based API to support OONI Explorer: https://github.com/ooni/backend/issues/442 * Refactoring the API codebase: https://github.com/ooni/api/pull/192 * Implementing some form of canning to use the current collector and/or the new API to receive measurements without relying on the batch pipeline: https://github.com/ooni/backend/issues/284 * Setting up a new database host in Amsterdam: https://github.com/ooni/backend/issues/400 * Implementing measurement_meta lookup: autoclaved, minican, fastpath host * Implementing measurement_uid * Implementing jsonl in the uploader * Updating the fastpath pipeline to support jsonl cans * Updating the fastpath pipeline to support API POST submissions * Implementing measurement upload into the API with new mini-canning * End-to-end testing of all probes * Investigating, implementing, testing Tor measurement submission * Adding software_name and software_version to the fastpath pipeline and rerunning it * Fixing the S3 bucket public permissions All of the above work is tracked through the following master ticket: https://github.com/ooni/backend/issues/437 ## Improving the OONI Probe engine ### Improved our golang probe-engine to support calling geolocate and measurement resubmission APIs To improve the interaction between our probe-engine and the OONI Probe mobile app, we designed new Go based APIs. The core design choice was to expose Go objects directly to Java/ObjC code, rather than continuing to implement a set of JSON based wrappers. This work is tracked here: https://github.com/ooni/probe-engine/issues/893 ### Improving the data quality of OONI measurements As part of our ongoing efforts to improve the data quality of OONI measurements, we worked on: * Understanding DNS based false positives: https://github.com/ooni/probe-engine/issues/770 * Categorizing bugs that affect data quality: https://github.com/ooni/probe-engine/issues/892 ### Working towards having our own ASN database for geolocating probes We made some progress towards building our own ASN database: https://github.com/ooni/probe-engine/issues/727 ## Released OONI Probe Mobile 2.6.0 In September 2020, we released OONI Probe Mobile 2.6.0 for: * Android: https://github.com/ooni/probe-android/releases/tag/v2.6.0 * iOS: https://github.com/ooni/probe-ios/releases/tag/v2.6.0 This release includes Countly (https://github.com/ooni/probe/issues/1241) and includes the following new features: * Notifications to run OONI Probe tests when censorship events emerge * Self-hosted platform for the collection of anonymized usage metrics (which can help us improve the OONI Probe apps) We also worked on the following: * Displaying the messages of push notifications within a modal in the OONI Probe Android app: https://github.com/ooni/probe/issues/1242 * Finished designing the new API used by the probe-engine * Progress on re-adding daily automatic testing: https://github.com/ooni/probe/issues/916 * Investigated (and addressed) the issues in the Android app (flagged by the Play Store) * Reviewed how we request for countly permissions: https://github.com/ooni/probe/issues/1244 * Edited the network count after the deletion of test data (bug fix): https://github.com/ooni/probe/issues/1240 * Added support for asking notification permission in the app: https://github.com/ooni/probe/issues/1210 * Replaced the links that discuss false positives: https://github.com/ooni/probe/issues/1095 * Discussed using multiple mobile deep link URL prefixes: https://github.com/ooni/probe/issues/1246 ## Improving the OONI Probe desktop app As part of our ongoing efforts to improve upon the OONI Probe desktop app, we worked on the following activities: * Investigated performance issues related to the loading time * Fixed the onboarding button alignment: https://github.com/ooni/probe/issues/1138 * Fixed app crash that occurred when viewing interrupted performance test results: https://github.com/ooni/probe/issues/1245 * Worked towards the renewal of the Windows code signing certificate for OONI Probe Desktop ## Added support to use the new migrated API in OONI Explorer As we worked towards migrating our infrastructure to servers in Amsterdam (and building a new API to accommodate the migration), we also had to make OONI Explorer rely on our new API and debug OONI Explorer/API interactions. This work involved activities that include: * Ensuring that OONI Explorer uses the refactored API: https://github.com/ooni/explorer/issues/489 * Removing tested_since from the OONI Explorer country page: https://github.com/ooni/explorer/issues/482 * Ensuring that OONI Explorer pages render minimal content when `test_keys` are missing: https://github.com/ooni/explorer/issues/416 ## Improvements to OONI Explorer As part of our ongoing improvements to OONI Explorer, we worked on restoring the anomaly flag indicators for the OONI Probe instant messaging tests in the search results: https://github.com/ooni/explorer/issues/425 This means that OONI Explorer users can now visually and easily find all anomalous measurements pertaining to the OONI Probe WhatsApp, Telegram, and Facebook Messenger tests via the OONI Explorer search page. ## URL prioritisation frontend We implemented a basic UI function (as an MVP) for the prioritized testing of URLs. This can be viewed here: https://github.com/ooni/ooni.org/issues/524#issuecomment-690707849 ## Published report on censorship events in Belarus amid protests We published a report documenting censorship events in Belarus amid anti-government protests. We prepared this report in collaboration with Human Constanta and the Digital Observers Community Belarus. Our report is available here: https://ooni.org/post/2020-belarus-internet-outages-website-censorship/ We detected the blocking of 86 websites in Belarus, which include news media, political opposition, pro-democracy, and election related websites, as well as communication and circumvention tool sites. We observed a variance in blocking both in terms of which websites were blocked across ISPs (i.e. different sites blocked on different networks), as well as in terms of censorship techniques. In some cases, when sites were hosted on HTTP, we saw that ISPs served a blockpage. But when sites were hosted on encrypted HTTPS, we observed interference during the TLS handshake (after the TCP connection and before the HTTP request), resulting in a connection reset error. As blocking appears to have been implemented during the TLS handshake, this suggests that Deep Packet Inspection (DPI) technology was likely used. It seems likely that the SNI was being used to decide whether to block or let connections go through. ## Press coverage CoinDesk wrote a story about OONI, which is available here: https://www.coindesk.com/hacker-decentralized-network-censorship This story features an interview with Arturo Filastò (OONI’s project lead), as well as interviews with OONI community members from Malaysia and Venezuela. The story also links to and discusses our Belarus report. Our report on Belarus also received press coverage from an Italian media outlet: https://ilmanifesto.it/la-bielorussia-ha-messo-il-bavaglio-al-web/ ## Preparation for Internet Shutdown Measurement Training for Advocates OONI is a lead partner on Internews’ OPTIMA Internet Shutdown Measurement Training for Advocates in Sub-Saharan Africa. Information about this training program (and its call for applications) is available here: https://internews.org/call-applications-internet-shutdown-measurements-advo… As part of our preparation for the Internet Shutdown Measurement Training for Advocates (a 6-week training program which started on 12th October 2020), we carried out the following activities: * Compiled relevant resources (reading materials and videos) for the training participants * Created homework assignments for the training participants * Reviewed applications for the training program * Reviewed the webinar videos of other mentors and shared feedback * Created a survey (in collaboration with Internews) to collect participant feedback prior to the start of the training program ### Recorded webinar on Introduction to Network Measurement OONI’s Maria recorded a 30-minute webinar which provides an introduction to network measurement for human rights defenders. An assignment was also prepared for this webinar. Internews will publish this webinar on their OPTIMA YouTube channel. ## Community use of OONI data ### Blocking of social media in Azerbaijan Azerbaijan Internet Watch published a report on the blocking of social media in Azerbaijan amid clashes with Armenia. Their report (which makes use of OONI data) is available here: https://www.az-netwatch.org/news/country-wide-internet-disruptions-reported… ### Reviewed OTF Fellow research report Over the past year we have collaborated with an OTF Information Controls Fellow who investigated internet censorship (through the use of OONI Probe and OONI data) in Myanmar. We offered OONI data analysis support (and relevant charts), and we reviewed their final report and shared feedback. ## Community activities ### Arusha Women School of Internet Governance (AruWSIG) 2020 On 10th September 2020, Maria presented OONI (“Measuring internet censorship with OONI Probe”) at the Arusha Women School of Internet Governance (AruWSIG) -- an annual event in Tanzania which partly took place online this year in light of the COVID-19 pandemic. Information about the event is available here: https://www.ksgen.or.tz/aruwsig-2020/ ### Forum on Internet Freedom in Africa 2020 (FIFAfrica) We attended the Forum on Internet Freedom in Africa 2020 (FIFAfrica) conference remotely, and viewed some sessions in order to learn more about Africa’s digital rights environment. Information about this event is available here: https://cipesa.org/fifafrica/ ### SMEX resource including OONI Probe SMEX published a post on “Website Blocking in the Arab Region: Techniques, Monitoring, and Response”, which is available here: https://smex.org/ar/%d8%ad%d8%ac%d8%a8-%d8%a7%d9%84%d9%88%d9%8a%d8%a8-%d8%a… This resource mentions and promotes OONI Probe as a tool for measuring internet censorship in the Arab region. ## Userbase In September 2020, 6,479,995 OONI Probe measurements were collected from 5,532 networks in 203 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/ ~ The OONI team. -- Maria Xynou Research & Partnerships Director Open Observatory of Network Interference (OONI) https://ooni.org/ PGP Key Fingerprint: 2DC8 AFB6 CA11 B552 1081 FBDE 2131 B3BE 70CA 417E

1 0

November 2020 Tor DEMO Day
by Antonela D 25 Nov '20

25 Nov '20

............................................ ██████ .███████ ███ ...███ .██████ .███████ ██ ██ ██ ████ .████ ██ ██ ██ ██ ..██ █████ ..██ ████ ██ ██ ...██ ███████ ██ ..██ ██ ..██ ██ ██ ██ ...██ ██ ██████ ███████ ██ . .██ ██████ ███████ ............................................ Hello, We will have DEMO day this Wednesday November 25th! When? ----- During the All Hands Meeting on Wednesday September 25th at 16 UTC Where? ------ At https://tor.meet.coop/ant-xfe-d2b-lnt How ---- - We will have 3 to 5 minutes length presentations. Agenda ---- Lessons learned from accepting remote presentations under C19 - ahf Padding Machines for Tor - Tobias Pulls Globaleaks - Giovanni Pellerano Query and control a running Tor in your CLI with carml - meejah Open Privacy/Cwtch - Sarah Jamie Lewis Trezor Suite + Tor integration - Pavol Rusnak On Tor and iOS - Benjamin with the Guardian See you there! A -- Antonela Debiasi UX Team Lead torproject.org @antonela E2330A6D1EB5A0C8

1 0

Tor's year-end campaign: live!
by Al Smith 23 Nov '20

23 Nov '20

Hello Tor world! Today we launched the annual year-end fundraising campaign on behalf of the Tor Project. This year, our theme is “Use a Mask, Use Tor: Resist the Surveillance Pandemic.” (You’ve probably seen the campaign graphics on about:tor already if you’ve upgraded to Tor Browser 10.0.1!) We chose this theme for our 2020 campaign because we wanted to use a positive message and speak to the power of community action & care. Use a mask, use Tor promotes the steps we can all take to combat the virus by using masks. Wearing a mask protects others. Wearing a mask is about caring about each other, our community. In the same way, when using Tor, you are not only protecting your identity and privacy online, but you are also helping to hide others who are using Tor. After all, anonymity loves company To put it simply, using a mask keeps yourself and your communities safe in person. Using Tor keeps yourself and your communities safe online. You can read the full justification behind the slogan, and what we plan to do in 2021 with your support, on our blog: https://blog.torproject.org/use-a-mask-use-tor Every donation made from now through the end of 2020 will count towards our year-end campaign. Be on the lookout for events, giveaways, and new merch available from now until December 31. Plus -- new swag! See https://donate.torproject.org for the new t-shirt and hoodie designs. If you’re not in the position to make a donation, you can help by sharing this message or amplifying what the Tor Project’s account does on Twitter / Mastadon / Instagram / LinkedIn / Facebook. Use a Mask, Use Tor! Thanks for your support. Al -- Al Smith (they/them) Fundraising • Communications The Tor Project

1 3

Anti-censorship meeting notes, 19 Nov 2020
by Cecylia Bocovich 19 Nov '20

19 Nov '20

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-11-19-15.58.html and the meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday November 19th 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 checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at Tor. == 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 30 https://gitlab.torproject.org/groups/tpo/-/milestones/4 https://gitlab.torproject.org/groups/tpo/-/milestones/7 https://gitlab.torproject.org/groups/tpo/-/milestones/5 https://gitlab.torproject.org/groups/tpo/-/milestones/6 Sponsor 28 must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10 possible tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&… Anti-censorship related tickets that we want other teams to fix: https://pad.riseup.net/p/tor-anti-censorship-tickets-keep <-- it will be moved into gitlab with TPO labels <-- do we still need this? The label is 'for anticensorship team' Public bug-reporting pad: https://pad.riseup.net/p/tor-anti-censorship-bugs-keep == Announcements == == Discussion == == Actions == == Interesting links == "Detection of Tor traffic using deep learning" https://146.227.160.144/bitstream/handle/2086/20415/AICCSA_2020_Final_Versi… Appears to only deal with vanilla Tor traffic. == Reading group == We will discuss "Poking a Hole in the Wall: Efficient Censorship-Resistant Internet Communications by Parasitizing on WebRTC" on Dec 3 https://dl.acm.org/doi/pdf/10.1145/3372297.3417874 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. phw: This week (2020-11-19): Made rdsys pool bridgestrap requests to minimise overhead. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/24 Added field to bridgestrap's response, informing requester when a bridge was last tested. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/6 Finally merged bridgestrap improvement that uses SETCONF to test bridges. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/3 Made rdsys display a bridge status page. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/10 Filed various sysadmin tickets to get bridgestrap deployed. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/5 Started investigating why we see more timeouts when we test more bridges. https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/7 Agreed to serve in TPC of NDSS DNS Privacy Workshop Started working on rdsys's design and architecture documentation. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/16 Merged an improvement to our Debian bridge setup guide. https://gitlab.torproject.org/arma/community-tpo/-/merge_requests/3 Next week: Reach out to a few folks to have emma run in different places. Deploy bridgestrap and rdsys, and expose bridge status page. Progress on Salmon. Help with: cecylia (cohosh): last updated 2020-11-19 Last week: - opened and created a MR for snowflake#40021 - more work on snowflake#40018 - merged and deployed snowflake-webext!9 - wrote up documentation of the NAT matching problem on the snowflake wiki: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - wrote snowflake!19 to close snowflake#40022 - Tor state of the onion - reviewed bridgestrap!2 This week: - Tor Browser patch for snowflake!19 - continue to monitor snowflake stats - write a PR to merge additional features from snowflake#40018 - follow up on progress towards a telegram bot for gettor - have broker inform proxies when to poll (snowflake#25598) - pick up snowflake multiplexing work again (snowflake#25723) - write probetest survival guide Needs help with: - review of snowflake!18 - review of snowflake!19 (i would really like to get this merged in tor browser quickly) juggy : This week: - Got very basic "suggested readings" list up and running here : https://jugheadjones10.github.io/anti-censorship-reading/ Next week: - Keep studying BridgeDB to write architectural overview Help with: - Open issues here (https://github.com/jugheadjones10/anti-censorship-reading ) for papers/resources/readings that you think might be useful for newcomers arlolra: 2020-10-29 Last week: - Next week: - getting back up to speed - follow ups to #33365 - start on #31201 Help with: - dcf: 2020-11-19 Last week: - archived snowflake-webextension-0.5.2 Next week: - review NAT type reclassification https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: Antonela: 2020-08-27 This week: - Wrapping Babatunde's research on the use of circumvention tools during internet censorship in Africa. Wrapping Personas for s30 with it. For september: - We are planning interviews with users in China to run our bridges discovery issues script in real time. We discussed to include TBA + snowflake as a task for users to run over a week or two and report back. https://gitlab.torproject.org/tpo/ux/research/-/issues/4 - I still have bridges.tpo to lektor issue open - More work on UX/UI for TB 10.0/10.5 - Review Salmon related tickets (im late with it!) agix:2020-11-19 Last week: -Reviewed rdsys documentation Next week: -(Definitely!) Finish work on rdsys ticket (tpo/anti-censorship/rdsys!4) -Gather ideas for Pluggable Transports/HTTPT/Issues/#4 Help with: - hanneloresx: 2020-10-22 Last week: - Took break to focus on work Next week: - #32117: Look at CAPTCHA success rate for users from the US across different types of bridges Help with: - thymbahutymba: 2020-04-02 Last week: - CI/CD pipeline for multiarch docker images, which has a problem with the apt tor version even though the apt repository have been changed into the Dockerfile. Next week: Help with: HashikD: 2020-11-19 This week: - Next week: - Research on how to implement a STUN check on Android. Help with: -

1 0

minutes from the sysadmin meeting
by Antoine Beaupré 19 Nov '20

19 Nov '20

# Roll call: who's there and emergencies gaba, hiro and anarcat on mumble, weasel (briefly) checked in on IRC. No emergencies. # BTCPayServer hosting https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750 We weren't receiving donations so hiro setup this service on [Lunanode][] because we were in a rush. We're still not receiving donations, but that's because of troubles with the wallet that hiro will resolve out of band. [Lunanode]: https://www.lunanode.com/ So this issue is about where we host this service: at Lunanode, or within TPA? The Lunanode server is already a virtual machine running Docker (and not a "pure container" thing) so we need to perform upgrades, create users and so on in the virtual machine. Let's host it, because we kind of already do anyways: it's just that only hiro has access for now. Let's host this in a VM in the new Ganeti cluster at Cymru. If the performance is not good enough (because the spec mentions SSD, which we do not have at Cymru: we have SAS), make some room at Hetzner by migrating some other machines to Cymru and then create the VM at Hetzner. hiro is lead on the next steps. # Tor browser build VM - review requirements https://gitlab.torproject.org/tpo/tpa/team/-/issues/34122 Brief discussion about the security implications of enabling user namespaces in a Debian server. By default this is disabled in Debian because of concerns that the possible elevated privileges ("root" inside a namespace) can be leveraged to get root *outside* of the namespace. In the [Debian bug report discussing this][], [anarcat asked][] why exactly this was still disabled and [Ben Hutchings][] responded by giving a few examples of security issues that were mitigated by this. [Ben Hutchings]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446#112 [anarcat asked]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446#107 [Debian bug report discussing this]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446 But because, in our use case, the alternative is to give root directly, it seems that enabling user namespaces is a good mitigation. Worst case our users get root access, but that's not worse than giving them root directly. So we are go on granting user namespace access. The virtual machine will be created in the new Cymru cluster, assuming disk performance is satisfactory. # TPA-RFC-7: root access policy https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-7-root Anarcat presented the proposal draft as sent to the team on November 9th. A few questions remained in the draft: 1. what is the process to allow/revoke access to the TPA team? 2. is the new permissions (to grant limited `sudo` rights to some service admins) acceptable? In other services, we use a vetting process: a sponsor that already has access should file the ticket for the person, the person doesn't request access. That is basically how it works for TPA as well. The revocation procedure was not directly discussed and still needs to be drafted. It was noted that other teams have servers outside of TPA (karsten, phw and cohosh for example) because of the current limitations, so other people might use those accesses as well. It will be worth talking with other stakeholders about this proposal to make sure it is attuned to the other teams' requirements. Think about the issue with Prometheus right now which is a good counter-example of when service admins do *not* require root on the servers ([issue 40089][]). [issue 40089]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40089 Another example is the `onionperf` servers that were setup elsewhere because they needed custom `iptables` rules. this might not require root but just `iptables` access, or at least special `iptables` rules configured by TPA. In general, the spirit of the proposal is to bring more flexibility with what changes we allow on servers to the TPA team. We want to help teams host their servers with us but that also comes with the understanding that we need the capacity (in terms of staff and hardware resources) to do so as well. This was agreed upon by the people present in the mumble meeting, so anarcat will finish the draft and propose it formally to the team later. # Roadmap review Did not have time to review [the team board][]. [the team board]: https://gitlab.torproject.org/tpo/tpa/team/-/boards anarcat ranted about people not updating their ticket and was (rightly) corrected that people *are* updating their tickets. So keep up the good work! We noted that the [top-level TPA board][] is not used for triage because it picks up too many tickets, outside of the core TPA team, that we cannot do anything about (e.g. the outreachy stuff in the GitLab lobby). [top-level TPA board]: https://gitlab.torproject.org/groups/tpo/tpa/-/boards # Other discussions ## Should we rotate triage responsibility bi-weekly or monthly? Will be discussed on IRC, email, or in a later meeting later, as we ran out of time. # Next meeting We should resume our normal schedule of doing a meeting the first Wednesday of the month, which brings us to December 2nd 2020, at 1500UTC, which is equivalent to: 07:00 US/Pacific, 10:00 US/Eastern, 16:00 Europe/Paris # Metrics of the month * hosts in Puppet: 78, LDAP: 81, Prometheus exporters: 132 * number of apache servers monitored: 28, hits per second: 199 * number of nginx servers: 2, hits per second: 2, hit ratio: 0.87 * number of self-hosted nameservers: 6, mail servers: 12 * pending upgrades: 36, reboots: 0 * average load: 0.64, memory available: 1.43 TiB/2.02 TiB, running processes: 480 * bytes sent: 243.83 MB/s, received: 138.97 MB/s * planned buster upgrades completion date: 2020-09-16 * [GitLab tickets][]: 126 issues including... * open: 1 * icebox: 84 * backlog: 32 * next: 5 * doing: 4 * (closed: 2119) Note that only two "stretch" machines remain and the "buster" upgrade is considered mostly complete: those two machines are the SVN and Trac servers which are both scheduled for retirement. [GitLab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards Upgrade prediction graph (which is becoming a "how many machines do we have graph") still lives at https://help.torproject.org/tsa/howto/upgrades/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. -- Antoine Beaupré torproject.org system administration

1 0

November 2020 Tor DEMO Day
by Antonela D 17 Nov '20

17 Nov '20

Hi Tor o/ This is happening at the end of the month! You can present any side project, main project, work in progress ideas, concepts, and anything that makes other people excited about what you are building or you are willing to build around Tor. Feel free to list yourself in the pad. https://pad.riseup.net/p/tor-monthly-hall-demos-october-november-2020-keep I hope to see you there! A ............................................ ██████ .███████ ███ ...███ .██████ .███████ ██ ██ ██ ████ .████ ██ ██ ██ ██ ..██ █████ ..██ ████ ██ ██ ...██ ███████ ██ ..██ ██ ..██ ██ ██ ██ ...██ ██ ██████ ███████ ██ . .██ ██████ ███████ ............................................ Why? ---- - We want to spice up our remote working routine and also break the silos between teams. How? ---- - We will call for presenters. - The agenda will be set before the meeting and will be shared with tor- project. - We want 5 to 8 minutes length presentations. We will handle questions at the end of all presentations. - Slides are allowed, but not mandatory. You may share your screen or a pre-recorded video if that makes you less anxious. - We like the adrenaline of the live presentations, but if they wish, presenters can share pre-recorded videos with us. They should be sent a few hours in advance and will be lined up and shared with assistants during the session. Who? ---- - Anyone who wants to share what they have been hacking on. It doesn't need to be a finished feature but a work in progress. It can be small like a Tor Browser feature or something you have been hacking around Tor not officially. - Presenters have 5 to 8 minutes. People can ask questions via text in the pad for 3 minutes. - Antonela will moderate at this time. We can rotate this role. Where? ------ During the All Hands Meeting. The room will be shared a few days before the meeting. When? ----- During the All Hands Meeting on Wednesday NOVEMBER 25TH at 16 UTC Agenda ------------------------------ d[-_-]b dj resident @mikeperry ------------------------------ - 5 min for the presentation - 3 min for questions ------------------------------ Questions will be written in text on the pad at any time during the presentation. Presenters will answer them in audio. -- Antonela Debiasi UX Team Lead torproject.org @antonela E2330A6D1EB5A0C8

1 0

Community Council activity summary, April 2020-August 2020
by Taylor Yu 13 Nov '20

13 Nov '20

Hi all, Here is a brief summary of the Community Council's activities from April 2020 through August 2020. The 2019 and 2020 Community Councils overlapped in the month of August. April 2020 The Council talked about longer term plans for the Council's role in the future. May 2020 The Council started planning for the upcoming Community Council election cycle. Some exploration of how to make the handover to the new Council go more smoothly because we won't have an in-person meeting for the foreseeable future. June 2020 The Council reviewed an existing community health concern in the light of new information, and began to draft a statement for internal communication. The Council reviewed existing practices in choosing to reject bad relays. Given the shortage of volunteers, made a one week extension for the call for volunteers for the next Community Council. More reminders in more places about Code of Conduct the Community Council, and other related documents. July 2020 The Council took action regarding a past Code of Conduct violation by a community member. The Council took action regarding an existing community health matter. The Council began the process of elections for the next year's Council. August 2020 The Council began the transition process to the 2020 Council. The Council continued to take action regarding an existing community health matter. --- end of summary --- This summary will also be posted on the Council's wiki page. This will be the last update from the 2019 Community Council. If you have any feedback about this summary format, or any other feedback to the Council, please contact us at tor-community-council(a)lists.torproject.org.

3 2

Network Team meeting moved from Monday to Tuesday next week
by Alexander Færøy 12 Nov '20

12 Nov '20

Hello folks. Because of the State of the Onion event on Monday the 16th of November, we are moving the Network Team meeting 24 hours ahead to Tuesday the 17th at 17:00 UTC on #tor-meeting on OFTC. All the best, Alex. -- Alexander Færøy

1 0

Tor Browser roadmap for the rest of 2020
by Gaba 12 Nov '20

12 Nov '20

Hi! The Tor Browser team is meeting on November 12th at 15UTC in #tor-meeting in irc.oftc.net We are going to discuss and define the roadmap for the Tor Browser until the end of the year. The pad for the meeting will be: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/TB-… cheers, gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

2 1