tor-project July 2020

tor-project@lists.torproject.org

15 participants
31 discussions

Tor's Bug Smash Fund: Fundraising Campaign
by Al Smith 17 Sep '20

17 Sep '20

Hello Tor! Today, the Tor Project is launching our second annual Bug Smash Fund,[1] a month-long fundraising campaign (7/31 - 8/31). The goal of the Bug Smash Fund campaign is to raise unrestricted funds that we allocate to finding and fixing bugs / doing maintenance / and addressing issues that aren’t flashy or exciting for most funders, but totally necessary for the health of Tor and all of the third party apps that rely on Tor to provide privacy, security, and anonymity to their users. Unrestricted funding, like what we’re raising for the Bug Smash Fund, is key for the Tor Project to improve our agility and stop relying on the slow, piecemeal process of grant funding in order to accomplish our goals and respond to emergent issues. Last year during our first Bug Smash Fund campaign, we raised $86,081 that we used to close 74 tickets.[2] In 2019, we were able to allocate all of the donations we raised in-person at DEF CON to the Bug Smash Fund. That was about $40,000. As we all know, this year is different, and it will be a big stretch to meet or exceed the amount we raised last year without this event. So your help to amplify this campaign could really help make this campaign a success. How to help: -- Tweet about the Bug Smash Fund using the #TorBugSmash and a link to our launch blog post. Here are some suggested posts.[3] -- Quote tweet @torproject posts about the Bug Smash Fund with your own take about why unrestricted funds are so important for the health of Tor. -- Forward this email to those who might be able to amplify the campaign. Activities in August to support the Bug Smash Fund campaign: -- Hosting a second PrivChat event featuring stories about smashing bugs in software development on (date tbd) -- Sharing regularly on social media and engaging our friends to amplify the campaign -- Sending two emails to previous donors who have not made a donation in the last 90 days -- Promoting a new cryptocurrency campaign on Blockchair: https://blockchair.com/donut/tor-project If you have any questions about or ideas for the Bug Smash Fund campaign, please email me or Isabela or grants(a)torproject.org, we would be happy to talk about it. Happy Friday, Al [1] https://blog.torproject.org/tor-bug-smash-fund-2020 [2] https://blog.torproject.org/tor-bug-smash-fund-2019-final-update [3] https://pad.riseup.net/p/OiWVPFGPw7I9vnX7MnN2 -- Al Smith (they/them) Fundraising • Communications The Tor Project

1 2

User Experience Team monthly on August 4th
by Antonela Debiasi 31 Jul '20

31 Jul '20

Hi! We will be having the User Experience team meeting on August 4th in #tor-meeting on OFTC.[*] The folks at Guardian project will join us this time to share the experience of designing Tor Browser for iOS. Also, we will have some space for an open floor so feel free to list yourself in the pad. https://pad.riseup.net/p/1D8sK8Zy74b_0qclC97I-ux-team-monthly-2020-keep Remember, the User Experience team meetings are willing to cultivate an open space for discussions around ethical user research, user interface design, and user experience, meanwhile building privacy-enhancing products. I hope to see you around! Peace and love, A [*] https://gitlab.torproject.org/tpo/ux/team/-/wikis/home -- Antonela Debiasi UX Team Lead torproject.org @antonela E2330A6D1EB5A0C8

1 0

Anti-censorship meeting notes, 30 July 2020
by Cecylia Bocovich 30 Jul '20

30 Jul '20

Here is the meeting log: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-07-30-15.59.html And the meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday July 30th 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 == Announcements == Please add your work to our July team report: https://pad.riseup.net/p/0JgLG-qpdbqTMZW4Kjma == Discussion == == Actions == == Interesting links == FOCI'20 program is out (but papers are not yet available): https://www.usenix.org/conference/foci20/workshop-program *.ampproject.org was blocked in Iran for a few days: https://twitter.com/KhosroKalbasi/status/1288185192490979336 IETF tls mailing list: "Possible blocking of Encrypted SNI extension in China" https://mailarchive.ietf.org/arch/msg/tls/YzT5LjLJ_6WWhdnU2wVsKNKR6_I/ == Reading group == We will discuss "Emotional and Practical Considerations Towards the Adoption and Abandonment of VPNs as a Privacy-Enhancing Technology" on July 23rd https://petsymposium.org/2020/files/papers/issue1/popets-2020-0006.pdf https://www.youtube.com/watch?v=jksejehBQII 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-07-30): Spent most of my time working on BridgeDB reimplementation. https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32900 Reviewed tpo/anti-censorship/pluggable-transports/snowflake#40002. Reviewed Gus's training slides. Reviewed S30 report. Next week: Wrap up tpo/anti-censorship/wolpertinger#34259. Help with: cecylia (cohosh): last updated 2020-07-30 Last week: - sponsor 28 evaluation bullshit, still - updated tor-browser-build#40016 with work on snowflake#30579 - reviewed snowflake-mobile!12 - opened snowflake#40005 - responded to some of nick's core tor anti-censorship ticket triage questions This week: - take a look at #25595 - NAT discovery at proxies (snowflake-webext#13) - continue with GetTor + BridgeDB refactor - look at snowflake#40004 Needs help with: - review of tor-browser-build#40016 (tbb-team) 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 paper/resource/reading arlolra: 2020-06-11 Last week: - Next week: - follow ups to #33365 - start on #31201 Help with: - dcf: 2020-07-30 Last week: - reviewed random selection of STUN servers (snowflake!40031) - filed ticket to add licenses of kcp-go and smux (tor-browser-build#40031) Next week: - find out what went wrong with trying to give cohosh CDN access (snowflake#30510) - set up an etherpad for public bug reporting and link it from https://snowflake.torproject.org/#bugs (snowflake#34435) - add licenses of kcp-go and smux (tor-browser-build#40031) Help with: Antonela: 2020-07-23 Last week: - (S28) Snowflake Android App UI https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - (S30) Making bridges.tpo looks like tpo.org https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34322 - (S30) Planning activities for the user group in HK (happening next week): - Run emma https://gitlab.torproject.org/tpo/ux/research/-/blob/master/scripts%20and%2… - Discovery issues with Bridges flow - working on the script https://gitlab.torproject.org/tpo/ux/research/-/issues/4 This week: - (S28) Review Snowflake Android App UI - (S30) Working on making bridges.tpo work with lektor - (S30) Sent Get Bridges User Research to the group in HK. Will meet them on Friday. Final script: https://gitlab.torproject.org/tpo/ux/research/-/issues/4 agix:2020-07-23 Last week: -on vacay till 08-03 Next week: - Help with: - hanneloresx: 2020-07-30 Last week: took a break to focus on emergency at my job Next week: - Work on #32117 - Work on #33727 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-07-16 Last week: - Made designs for Snowflake mobile: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - #6 Showing users stat about how many clients they served in the past 24 Next week: - Work on ticket #11 Help with: -

1 0

Damian's Status Report - July 2020
by Damian Johnson 30 Jul '20

30 Jul '20

Hi all. Throughout these last couple months Illia and I migrated Stem to asyncio! You can read about it at... https://blog.atagar.com/july2020/ Cheers! -Damian

1 0

Network meeting, July 27th
by Gaba 27 Jul '20

27 Jul '20

Hi! Network meetings are happening every Monday at 1700UTC on #tor-meeting in irc.oftc.net. Everyone is welcome to participate in them! Meeting Log: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-07-27-16.59.log… Contents of the meeting pad: == Network meeting pad! == Next meeting is at Monday 3rd August 1700 UTC on #tor-meeting on OFTC. July Schedule: * Monday 27 July 17:00 UTC August Schedule * Monday 3rd August 17:00 UTC * Monday 10th August 17:00 UTC * Monday 17th August 17:00 UTC * Monday 24rd August 17:00 UTC Welcome to our meeting! We meet each month at: Mondays at 1700 UTC On #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see anything you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! After each week's meetings, the contents of this pad will be sent to tor-project @ lists.torproject.org. After that is done, the pad can be used for the next week. == Previous notes == (Search the tor-project mailing list archive for older notes.) 20 July: https://lists.torproject.org/pipermail/tor-project/2020-July/002934.html == Stuff to do every week == Let's check and update our roadmap: What's done, and what's coming up? Any change? Board: https://gitlab.torproject.org/groups/tpo/core/-/boards S28 & S30 - Continue after October - Ahf - maybe dgoulet can do some of this after August S55 - Nickm & dgoulet, ends 15 August Non sponsor stuff 044 fixes and releases DoS defenses = Dgoulet + Asn Library Size reduction = Ahf + Dgoulet sbws = Ahf + Juga Check reviewer assignments! How reviews from last week worked? Any blocker? Here are the outstanding reviews: Merge requests in Core NOT already marked for backport: https://gitlab.torproject.org/groups/tpo/core/-/merge_requests?scope=all&ut… Let's check out 0.4.4 release status and open tickets! Tickets in 0.4.4.x with no owner. https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&sta… nickm: https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&sta… dgoulet: https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&sta… ahf: https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&sta… asn: https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&sta… Core Tor Releases: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… == Reminders == * Remember to "/me status: foo" at least once daily. * Remember that our current code reviews should be done by end-of-week. * Make sure you are in touch with everybody with whom you are doing work for the next releases. * Check other's people call for help in their entries. Volunteers need help. Please help them when you are around. Maybe we should have times of day when different people are responders, and expectations of who helps. ------------------------------- ---- 27 July 2020 ------------------------------- == Announcements [please date] == == Discussion [please date] == issues in https://gitlab.torproject.org/tpo/core/team/-/issues === Active Proposed Policies === * Pull Request Guidelines (stalled) === Design proposals under discussion === 315: require more fields in directory documents (still waiting [6/1]) 316: flashflow (asn and nickm are reviewing, should schedule discussion with pastly. [5/18]) 317: dns (under discussion on ML [5/18]) 318: limit protovers (waiting for more commment; needs discussion [6/1]) 319: wide everything (nick replied on ml; waiting for more discussion [6/1]) 320: tap out again - Do we have a consensus to replace this with a "deprecate v2 onion services" proposal? If so, who writes it? [6/1] protover rethinking (teor's email to tor-dev) (nick needs to reply [5/18]) 321: happy families (need feedback [6/1]) 322: dirport linkspec (need feedback [6/1]) == Recommended links == == Updates == Name: Week of XYZ (planned): - What you planned for last week. Week of XYZ (actual): - What you did last week. Week of ABC (planned): - What you're planning to do this week. Help with: - Something you may need help with. PLEASE DO NOT BULK-DELETE THE OLD ENTRIES! Leave the "Planned" parts! Leave the parts for last week and this week! (feel free to delete your own stuff that's more than 1-2 weeks old) Nick: Week of 20 July (planned): - Catch up on emails - Still keep an eye on openssl bug status - Chutney attack! - Try to wrap up all s55 work with dgoulet - Try to make 044 progress as needed/possible - Work on checklists more. Week of 20 July (acutal): - emails - Lots of review and merge - Tried to wrap up s55 stuff with dgoulet - chutney debugging adventures - triaged first 500 tickets in core/tor Week of 27 July (planned): - Proposal triage - Final S55 stuff - Plan 045 on Thursday meeting - Release 0.4.4.3-alpha (any blockers?) - 044 work? ahf: Week of 20/6 (planned): - Fenix - Help with merges Week of 20/6 (actually): - Fenix: - Gitlab CI work - Continued work on fenix#40001 - Looked at Nick's CI script for Tor Week of 27/6 (planned) - Last week before going on vacation. - Fenix continued. - Do reviews for GeKo on sbws. - Make the Lobby usable for more people. asn: Back from AFK jnewsome: Week of July 6 (planned): - Get code-coverage PR cleaned up and merged - Implement phantom memory-marshalling optimization "for real" and merge Week of July 6 (actual): - Got code-coverage tracking merged into shadow - Reworked CI to move logic from GH proprietary config to shell scripts, and added scripts to run it locally via Docker - More work on memory-marshalling mmap optimization: wrote an IntervalMap in Rust to track mmap state Week of July 13 (planned): - Memory-marshalling mmap optimization Week of July 13 (actual): - Finished up and merged IntervalMap https://github.com/shadow/shadow/pull/886 - Started making Shadow C code callable from Shadow Rust code (bindgen + wrappers) https://github.com/shadow/shadow/pull/887 - Prototyped some different approaches of modelling Shadow's object graph in Rust https://github.com/sporksmith/dev-journal/blob/master/rust-ownership/Shadow… Week of July 20 (planned): - Write MemoryManger in Rust to implement mmap-based memory access in Shadow/Phantom - OoO next week - have fun! pastly: Week of 18 May (planned): - Finish bones of external FlashFlow repo (python?) to control tor clients that perform FF measurements - Finish bones of little-t tor changes s.t. measurement can be performed - Discuss FlashFlow with network team devs as they have questions c: Week of July 6 (actual): - fix up chutney #40002 Week of July 13 (actual): - #40002 merged in Week of July 20 (planned): - tor #21524 and other IPv6-tagged issues Week of July 20 (actual): - obsolete #21524 for #40066 - started on #40066 Week of July 27 (planned): - finish #40666 - revisit https://gitlab.torproject.org/tpo/core/chutney/-/issues/33604 (IFS for shell scripts) dgoulet: Week of 13/07 (actual): - s55, s55 and s55 (IPv6). :) Week of 20/07 (planned); - s55 - New list of fallback dirs -- she/her are my pronouns GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Sponsor 38 update (Shadow simulator)
by Jim Newsome 24 Jul '20

24 Jul '20

Sponsor 38: https://github.com/shadow/shadow/blob/master/docs/nsf-sponsorship.md Previous updates: * 2020-02-10 https://lists.torproject.org/pipermail/tor-project/2020-February/002718.html * 2020-03-19 https://lists.torproject.org/pipermail/tor-project/2020-March/002785.html * 2020-06-01 https://lists.torproject.org/pipermail/tor-project/2020-June/002859.html We've moved our NSF sponsor page from Tor's now-deprecated Trac site into our source repository on GitHub, next to our code. https://github.com/shadow/shadow/blob/master/docs/nsf-sponsorship.md. (We also have a place-holder in Tor's new GitLab instance, but it just directs readers to the GH page). We've continued to make progress on the new process-based architecture (aka Phantom) https://github.com/shadow/shadow/milestone/16. In particular: * We've migrated this work from a private repository to a new |dev| branch in the public Shadow repo: https://github.com/shadow/shadow/tree/dev. * This branch can now run Shadow's |phold| simulator performance benchmark, which we've been using to iterate on performance measurements and improvements before continuing on to add additional syscall support to run |tor|. https://github.com/shadow/shadow/issues/825 * Preliminary results were as much as 10x slower than the single-process architecture in a small-scale, ad-hoc test. These results led us to think more carefully about our design and we have begun to implement optimizations that we expect will help close this performance gap. o We've modified the |ptrace| interposition mechanism to use |PTRACE_SYSEMU| instead of |PTRACE_SYSCALL| (https://github.com/shadow/shadow/commit/bdf9fe529ed8090bb07aa5f2683b21bc550…), giving about a 20% speedup. Adding a caching layer to address lookups also gave a substantial speedup. Together these got us down to roughly 3.5x slower than the single-process approach. o We have work in progress to further improve performance by sharing memory between Shadow and its plugins (https://github.com/shadow/shadow/issues/888) and by using spin-locks for faster control-transfers (https://github.com/shadow/shadow/issues/894). * Since the |phold| benchmark essentially does nothing but send and receive UDP packets, it spends most of the benchmark crossing the new process boundaries between the Shadow process and the plugins. We think this is a worst case scenario in which to compare the new architecture to the current single-process architecture. We've added a tunable CPU-load parameter to |phold| to let us evaluate how this gets amortized, and plan on doing analysis with it soon. https://github.com/shadow/shadow/pull/897 We've integrated Rust into our build system such that Shadow code can be written in Rust, and Shadow's C and Rust code can call each-other. New code is now being being written in Rust. https://github.com/shadow/shadow/milestone/17 We've continued to improve Shadow's test suite and continuous integration. * We've added CI for all of the Linux distros we intend to support. https://github.com/shadow/shadow/milestone/19 * We've started collecting test coverage measurements https://github.com/shadow/shadow/milestone/20, and generating differential coverage reports on PRs. https://codecov.io/gh/shadow/shadow/branch/dev * We've moved core CI logic into bash scripts, and added an alternative driver script to run some or all of it in local Docker containers (vs GitHub's) for debugging. https://github.com/shadow/shadow/pull/875 * We've made progress on more-thoroughly testing the libc socket API. https://github.com/shadow/shadow/milestone/21 The Shadow team (https://github.com/shadow/shadow/blob/master/docs/nsf-sponsorship.md#people)

1 0

Anti-censorship meeting notes,23 July 2020
by Cecylia Bocovich 23 Jul '20

23 Jul '20

Here is the meeting log: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-07-23-15.58.html And the meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday July 23rd 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 == Announcements == The cost for Snowflake broker CDN service was non-zero, 0.01 USD, for the first time last month. On track for 0.02 USD in July. == Discussion == == Actions == == Interesting links == Relevant papers from Privacy Enhancing Technologies Symposium 2020. There's one on VPN usage, two on decoy routing, and one on rendezvous using cryptocurrency. https://petsymposium.org/2020/program_UTC.php Emotional and Practical Considerations towards the Adoption and Abandonment of VPNs as a Privacy-Enhancing Technology https://petsymposium.org/2020/files/papers/issue1/popets-2020-0006.pdf https://www.youtube.com/watch?v=jksejehBQII Running Refraction Networking for Real https://petsymposium.org/2020/files/papers/issue4/popets-2020-0073.pdf https://www.youtube.com/watch?v=ZDYKdy7lCRY SiegeBreaker: An SDN Based Practical Decoy Routing System https://petsymposium.org/2020/files/papers/issue3/popets-2020-0051.pdf https://www.youtube.com/watch?v=s7mHOKFtcYA MoneyMorph: Censorship Resistant Rendezvous using Permissionless Cryptocurrencies https://petsymposium.org/2020/files/papers/issue3/popets-2020-0058.pdf https://www.youtube.com/watch?v=vnc2i64rXvI == Reading group == We will discuss "Emotional and Practical Considerations Towards the Adoption and Abandonment of VPNs as a Privacy-Enhancing Technology" on July 23rd https://petsymposium.org/2020/files/papers/issue1/popets-2020-0006.pdf https://www.youtube.com/watch?v=jksejehBQII 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-07-23): Reviewed tpo/anti-censorship/bridgedb#27984. Reviewed tpo/anti-censorship/pluggable-transports/snowflake#40002. Spent a lot of time working on design of BridgeDB rewrite: https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32900#n… Next week: Wrap up tpo/anti-censorship/wolpertinger#34259. Help with: Thoughts on tpo/anti-censorship/bridgedb#32900 greatly appreciated. cecylia (cohosh): last updated 2020-07-23 Last week: - sponsor 28 evaluation bullshit, mostly - added more stun servers to client (snowflake#30579) - reviewed snowflake-mobile tickets - talked with phw about bridgedb re-write This week: - take a look at #25595 - NAT discovery at proxies (snowflake-webext#13) - snowflake sponsor 28 evaluation (monday, tuesday) - update tor-browser-build#40016 with work on snowflake#30579 - continue with GetTor + BridgeDB refactor Needs help with: - review of snowflake#30579 (snowflake!7) 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 paper/resource/reading arlolra: 2020-06-11 Last week: - Next week: - follow ups to #33365 - start on #31201 Help with: - dcf: 2020-07-23 Last week: - updated markup in the Snowflake wiki page for gitlab - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - find out what went wrong with trying to give cohosh CDN access (snowflake#30510) - set up an etherpad for public bug reporting and link it from https://snowflake.torproject.org/#bugs (snowflake#34435) Help with: Antonela: 2020-07-23 Last week: - (S28) Snowflake Android App UI https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - (S30) Making bridges.tpo looks like tpo.org https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34322 - (S30) Planning activities for the user group in HK (happening next week): - Run emma https://gitlab.torproject.org/tpo/ux/research/-/blob/master/scripts%20and%2… - Discovery issues with Bridges flow - working on the script https://gitlab.torproject.org/tpo/ux/research/-/issues/4 This week: - (S28) Review Snowflake Android App UI - (S30) Working on making bridges.tpo work with lektor - (S30) Sent Get Bridges User Research to the group in HK. Will meet them on Friday. Final script: https://gitlab.torproject.org/tpo/ux/research/-/issues/4 agix:2020-07-02 Last week: -Worked on #27984 Next week: -Work on #34318 Help with: -Review of #27984 (It's just a feedback implementation) hanneloresx: 2020-07-23 Last week: - Read existing documentation for BridgeDB. - Started investigating #32117 Next week: - Work on #32117 - Work on #33727 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-07-16 Last week: - Made designs for Snowflake mobile: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - #6 Showing users stat about how many clients they served in the past 24 Next week: - Work on ticket #11 Help with: -

1 0

Metrics meeting notes, July 23rd
by Gaba 23 Jul '20

23 Jul '20

Hi people interested in metrics meetings! Metrics Meetings are still happening every Thursday at 15UTC in #tor-meeting in irc.oftc.net Here are the pad notes for the meeting of July 23rd: **************************************************************************************** This pad is shared publicly. **************************************************************************************** Public pad URL is: https://pad.riseup.net/p/tor-metricsteam-2020.1-keep Weekly meetings, every Thursday at 15 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress). Links: Metrics Team wiki page: https://gitlab.torproject.org/tpo/metrics/team OnionPerf board: https://gitlab.torproject.org/tpo/metrics/onionperf/-/boards OnionPerf milestone: https://gitlab.torproject.org/groups/tpo/metrics/-/milestones/1 All Metrics Roadmap: https://gitlab.torproject.org/groups/tpo/metrics/-/boards Next meeting: Thursday, July 30th, 15 UTC ----------------------------------------------------- Agenda Thursday, July 23rd, 15 UTC ----------------------------------------------------- woswos project (CAPTCHA Monitor): https://dashboard.captcha.wtf/ More details: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/home Log: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-07-23-15.05.log… -- she/her are my pronouns GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

OONI Monthly Report: June 2020
by Maria Xynou 22 Jul '20

22 Jul '20

Hello, Throughout June 2020, the OONI team worked on the following sprints: * Sprint 14 - Ponyo (1st June 2020 - 7th June 2020) * Sprint 15 - Globster (8th June 2020 - 21st June 2020) * Sprint 16 - Neon (22nd June 2020 - 30th June 2020) Our work can be tracked through the various OONI GitHub repositories: https://github.com/ooni Highlights are shared in this report below. ## Released OONI Probe Mobile 2.5 We released OONI Probe Mobile 2.5! Android: https://github.com/ooni/probe-android/releases/tag/v2.5.0 iOS: https://github.com/ooni/probe-ios/releases/tag/v2.5.0 Highlights from the latest release include: 1) Circumvention tool testing: The latest release includes OONI Probe tests for measuring the blocking of Tor & Psiphon! 2) 5 new languages: Thanks to the Localization Lab community, the OONI Probe mobile app is now also available in Indonesian, Thai, Romanian, Slovak, and Icelandic (in total, the OONI Probe mobile app is now available in 20 languages!) As part of the iOS release, we also rewrote NDT to increase its reliability and measurement accuracy, and wrote the Telegram, NDT, and DASH tests in golang. ## OONI Probe desktop app In June 2020, we made two OONI Probe desktop app releases: * OONI Probe Desktop 3.0.2: https://github.com/ooni/probe-desktop/releases/tag/v3.0.2 * OONI Probe Desktop 3.0.3: https://github.com/ooni/probe-desktop/releases/tag/v3.0.3 These releases feature bug fixes and other improvements based on community feedback. ## Making the OONI Probe apps rely entirely on the golang engine As part of our ongoing efforts to make the OONI Probe apps rely entirely on the golang engine, we: * Used JCenter to fetch probe-engine on Android: https://github.com/ooni/probe/issues/1191 * Updated to the latest version of probe-cli/probe-engine: https://github.com/ooni/probe/issues/1178 * Made a series of updates: https://github.com/ooni/probe-engine/issues/689 ## Adding support for configuring push notifications Our goal is to be able to send push notifications to OONI Probe mobile app users through the use of Countly, which enables us to include links (such as OONI Run links for coordinated OONI Probe testing) in push notifications. To this end, we evaluated how to manage the collection of app usage metrics, crash reports, and privacy settings, as documented through the following ticket: https://github.com/ooni/probe/issues/1182 We also made progress on implementing countly on Android: https://github.com/ooni/probe-android/pull/341 ## Adding support in OONI Probe for availability testing of the circumvention tools Tor, obfs4proxy, and Psiphon We have completed our work related to adding support in OONI Probe for availability testing of Tor, obfs4proxy, and Psiphon. The new Tor and Psiphon tests are available through the recently launched OONI Probe desktop app (https://ooni.org/install/desktop). In June 2020, we also implemented the STUN server reachability experiment: https://github.com/ooni/probe-engine/issues/243 ## Improving censorship circumvention tool methodologies by including performance metrics We completed our (short-term) work on improving our methodologies for measuring censorship circumvention tools by measuring the performance of those tools as well. As part of our final relevant activities, we: * Recorded website accessibility performance metrics when using Psiphon: https://github.com/ooni/probe-engine/issues/404 * Improved the data format versioning: https://github.com/ooni/probe-engine/issues/423 * Allowed using an external tor binary to run ndt7, DASH, and urlgetter over it: https://github.com/ooni/probe-engine/issues/587 ## Developing OONI Probe orchestration logic that is specific to circumvention tool testing We completed our work related to developing OONI Probe orchestration logic that is specific to circumvention tool testing. As part of our final relevant activities, we: * Wrote an integration test for private Tor bridges: https://github.com/ooni/probe-engine/issues/721 * Stripped private bridge addresses: https://github.com/ooni/probe-engine/issues/643 * Included the country code in the Tor query string: https://github.com/ooni/probe-engine/issues/629 ## Making OONI Probe’s reporting logic more resilient to censorship We completed our (short-term) efforts related to making OONI Probe’s reporting logic more resilient to censorship. As part of our final relevant activities, we: * Discussed requirements for detecting the blocking of OONI services in the pipeline: https://github.com/ooni/backend/issues/417 * Created new domain names: https://github.com/ooni/backend/issues/424 * Implemented a prototype of Probe Services blocking detection: https://github.com/ooni/backend/issues/428 * Implemented failover between available OONI data centers: https://github.com/ooni/probe-engine/issues/621 * Used best available OONI data center for orchestration and other services: https://github.com/ooni/probe-engine/issues/651 We did an analysis (https://github.com/ooni/probe/issues/886), using the fact that we added support for probes to failover to cloudfront collectors, and we did not notice any probes failing over using this method. We have not identified any cases of blocking of OONI infrastructure. That said, we will continue to do more investigations and eventually automate the process. ## Improving URL testing ### Implementing beta quality backend logic for prioritising URLs As part of our work on implementing beta quality backend logic for the prioritization of URLs, we worked on refactoring and improving our URL prioritization backend (and on creating an internal Grafana dashboard). See: https://github.com/ooni/pipeline/pull/321 Moreover, we started adding an haproxy server in front of the URL prioritisation backend so that we are able to start using it in production for a percentage of the probes out there. See: https://github.com/ooni/sysadmin/pull/446. ### Implementing beta quality frontend to support management of the URL priorities In order to implement a beta quality frontend to support the management of URL priorities, we started off by reviewing the relevant priorities. As part of this process, we documented the next steps in the following tickets: https://github.com/ooni/backend/issues/429 https://github.com/ooni/ooni.org/issues/524 ## Analyzing data to extract website metrics As part of our ongoing data analysis work to extract website metrics, we published an aggregation API endpoint and started working on creating a page to try out the new aggregation API. The goal of this page is to query the API for different kinds of data and to render charts based on that data. Eventually, these charts will be integrated in the country pages of OONI Explorer. See: https://github.com/ooni/explorer/issues/463 Our initial experiment for trying out the new aggregation API is available here: https://codesandbox.io/s/nivobar-extra-layers-pbgg4?file=/src/index.js ## Presenting website measurements to account users We are working towards enabling community members to have access to advanced and database-heavy views of website-centric measurements (through accounts that we will create). To this end, we started off by discussing and deciding what it means to have an account within the context of the various OONI platforms: https://github.com/ooni/ooni.org/issues/434 As part of this research, we wrote an internal document outlining our plans for implementing accounts and authentication to OONI services. We also documented the use cases (user stories) for these accounts, feedback and community requests pertaining to accounts (as communicated to us through a pull in a previous community meeting, as well as through other long-term interactions with community members), as well as implementation details and requirements. We also worked on creating mock-ups for website-centric views: https://github.com/ooni/explorer/issues/472 ## Improving our server infrastructure As part of our ongoing work to improve our server infrastructure, we improved the performance of the counters table (https://github.com/ooni/backend/issues/411) and we made improvements to the monitoring of our infrastructure (https://github.com/ooni/backend/issues/427). ## Testing and quality assurance We made progress on improving the quality of our software through better testing and quality assurance procedures. We performed data analysis based on specific measurements (https://github.com/ooni/probe-engine/issues/662) and implemented changes (described below in detail) to simplify subsequent data analysis attempts. We also further evaluated the code for selecting the closest OONI probe service API among the available data centers (HK, MIA, AMS), and extended this functionality to OONI orchestration. Specifically, we: * Performed experiments and data analysis based on measurements performed in India (which resulted in a blog post): https://github.com/ooni/probe-engine/issues/662 * Simplified OONI data analysis by ensuring that the resolver is added to the measurement: https://github.com/ooni/probe-engine/issues/642 * Simplified OONI data analysis by setting the DNS cache to null when empty: https://github.com/ooni/probe-engine/issues/658 * Improved urlgetter measurements: https://github.com/ooni/probe-engine/issues/656 * Used best data center providing the probe service API for orchestration and other services: https://github.com/ooni/probe-engine/issues/651 * Wrote an integration test for private Tor bridges: https://github.com/ooni/probe-engine/issues/721 Throughout June 2020, we focused quite a bit on improving the data quality of OONI measurements. ## Published report on the blocking of DNS over TLS in Iran In June 2020, we published a research report, titled "DNS over TLS blocked in Iran", which is available here: https://ooni.org/post/2020-iran-dot/ We investigated whether DoT works in Iran by gathering a list of 31 well-known DoT endpoints and running experiments from four distinct Iranian mobile and fixed-line Internet Service Providers (ISPs): MCI, TCI, Irancell, and Shatel. We discovered that: * 57% of the endpoints are blocked on a least one ISP; * the blocking is not implemented uniformly across ISPs; * most blocking happens by interfering with the TLS handshake; * in some cases TLS handshake blocking seems to depend on the SNI, while in other cases it seems to depend strictly on the TCP endpoint being used; * forcing TLSv1.3 does not change the rate of successful TLS handshakes compared to letting the server choose a TLS version between v1.0 and v1.3. In our report, we share details from our experiments and findings. This research is part of our ongoing efforts to expand and improve upon our measurement methodologies. ## Published report on TLS blocking in India In collaboration with India’s Centre for Internet and Society (CIS), we co-published a research report investigating TLS blocking in India. This report is available here: https://ooni.org/post/2020-tls-blocking-india/ This investigation sought to understand whether there were cases of TLS blocking that were not only caused by the value of the Server Name Indication (SNI) field in the ClientHello TLS message, but also by the destination IP address. This was part of our efforts to expand our SNI blocking methodology (discussed here: https://ooni.org/post/2020-iran-sni-blocking/). To this end, we wrote and ran a series of experiments (that will eventually be integrated into the OONI Probe measurement engine) to measure the blocking of four domains (facebook.com, google.com, collegehumor.com, and pornhub.com) on three popular Indian ISPs: ACT Fibernet (fixed line), Bharti Airtel, and Reliance Jio (mobile). We recorded SNI-based blocking on both Bharti Airtel and Reliance Jio. We also discovered that Reliance Jio blocks TLS traffic not just based on the SNI value, but also on the web server involved with the TLS handshake. We also noticed that ACT Fibernet’s DNS resolver directs users towards servers owned by ACT Fibernet itself. Such servers caused the TLS handshake to fail, but the root cause of censorship was the DNS. We also found that one of the tested endpoints (for collegehumor.com:443) does not allow establishing a TCP connection from several vantage points and control measurements. Yet, in Reliance Jio, we saw cases where the connections to such endpoints completed successfully and a timeout occurred during the TLS handshake. This is likely caused by some kind of proxy that terminates the TCP connection and performs the TLS handshake. ## Expanding OONI Probe measurement methodologies Our aforementioned research reports on DNS over TLS blocking in Iran (https://ooni.org/post/2020-iran-dot/) and TLS blocking in India (https://ooni.org/post/2020-tls-blocking-india/) document our ongoing efforts to expand our measurement methodologies. The experiments that we design and run as part of these research efforts will eventually be integrated into OONI Probe and shipped as part of our apps. Some of our efforts on expanding our measurement methodologies are also documented through the following tickets: https://github.com/ooni/probe-engine/issues/624 https://github.com/ooni/probe-engine/issues/576 https://github.com/ooni/probe-engine/issues/659 ## Published report of OTF Information Controls Fellow Over the last year, OONI has had the opportunity to serve as the host organization of OTF Information Controls Fellow, Chinmayi S K (https://www.opentech.fund/about/people/chinmayi-sk/). In June 2020, we published Chinmayi's research report, titled "Those Unspoken Thoughts: A study of censorship and media freedom in Manipur, India". Summary of report: https://ooni.org/post/2020-those-unspoken-thoughts-otf-fellow-report/ Full length report: https://ooni.org/documents/those-unspoken-thoughts-otf-fellow.pdf As part of her fellowship, Chinmayi researched internet censorship in Manipur, India, and its effect on the womxn in the region. To investigate internet censorship, Chinmayi ran OONI Probe in various regions of India and analyzed relevant OONI measurements. To explore the impact of internet censorship on womxn in the region and to investigate restrictions to media freedom, she circulated a survey and carried out interviews. Throughout her fellowship, OONI provided research, editing, and data analysis support. When we published Chinmayi’s report in June 2020, we also assisted with relevant outreach activities. ## Published statement in support of the OTF Following the firing of OTF’s leadership, we published a statement in support of the OTF, explaining why the OTF is essential for internet freedom. Our statement is available here: https://ooni.org/post/2020-06-19-save-internet-freedom-support-the-open-tec… ## Collaboration with Azerbaijan Internet Watch ### Published guest blog post to encourage more OONI Probe testing in Azerbaijan To encourage more OONI Probe testing in Azerbaijan, we published a guest blog post (in Azerbaijani) written by Arzu Geybullayeva of Azerbaijan Internet Watch (with whom we partner). This blog post is available here: https://ooni.org/post/2020-azerbaijan-ooni-probe-testing/ The post provides step-by-step instructions for OONI Probe testing, particularly with regards to the testing of media websites and circumvention tools, which present signs of blocking based on OONI data analysis. ### Data analysis As part of our partnership with Azerbaijan Internet Watch, we analyzed all OONI measurements collected from Azerbaijan between 1st January 2020 to 30th June 2020 (https://github.com/ooni/ooni.org/issues/543), based on which we produced relevant charts and wrote a report. ## Collaboration with Netalitica Netalitica researchers continued to do great work in reviewing and updating the Citizen Lab test lists (https://github.com/citizenlab/test-lists). In June 2020, we reviewed URLs shared by Netalitica researchers and added them to the Turkish test list: https://github.com/citizenlab/test-lists/pull/642 We also made updates to the Azerbaijan (https://github.com/citizenlab/test-lists/pull/640) and Hong Kong (https://github.com/citizenlab/test-lists/pull/641) test lists, based on URLs shared by community members. ## Press coverage RESET interviewed the OONI team and published an article about OONI. This article was published in: * German: https://reset.org/blog/ooni-software-spuert-menschenrechtsverletzungen-im-i… * English: https://en.reset.org/blog/ooni-free-software-designed-detect-human-rights-v… DARK Reading also published an article that mentions OONI Probe, following an interview with OONI’s Arturo. This article is published here: https://www.darkreading.com/cloud/no-internet-access-amid-protests-heres-ho… ## Community use of OONI data ### Psiphon Data Engine (PDE) Over the last year, we have collaborated with Psiphon on integrating OONI measurements into a new platform, called Psiphon Data Engine (PDE). This platform displays OONI and M-Lab measurements, along with Psiphon metrics, through an interactive dashboard. In June 2020, Psiphon launched the PDE, which is available here: https://psix.ca/ ### Report on the blocking of Blogger in Lebanon Through the use of OONI Probe and OONI data, SMEX examined the blocking of Blogger in Lebanon. They published a report based on their findings, which is available here: https://smex.org/ar/%d8%ad%d8%ac%d8%a8-%d8%a8%d9%84%d9%88%d8%ba%d8%b1-%d9%8… ### Report on potentially blocked media in Belarus In June 2020, Human Constanta published a report examining several cases of network interference in Belarus. As part of their study, they also used OONI Probe to examine the blocking of several media websites. Their report (which includes OONI findings) is available here: https://humanconstanta.by/chto-proisxodilo-s-internetom-v-belarusi-19-iyuny… ### 2019 Annual Report on Digital Rights in Venezuela Our Venezuelan partners, IPYS Venezuela, published their 2019 annual report on digital rights in Venezuela, which is available here: https://ipysvenezuela.org/2020/05/17/desconexion-y-censura-reporte-anual-de… This report discusses censorship findings that they discovered through the use of OONI Probe and OONI data. ### Blocking of YouTube in Venezuela Through the use of OONI Probe and OONI data, our local partners in Venezuela reported the blocking of YouTube: https://twitter.com/ipysvenezuela/status/1271196383463247872 ## Community activities ### Internet Measurement Village 2020 Throughout June 2020, we organized and hosted the first Internet Measurement Village (IMV) 2020. Information about the event is available through our relevant blog post: https://ooni.org/post/2020-internet-measurement-village/ The IMV is an online community event -- dedicated to discussions around internet measurement -- that took place throughout June 2020, starting on 10th June 2020 and ending on 3rd July 2020. During this 4-week period, we hosted one session almost every day (on weekdays), all of which were live-streamed on the OONI YouTube channel: https://www.youtube.com/c/OONIorg In total, we hosted 18 live-streamed sessions, covering a wide range of internet measurement projects, as well as local censorship measurement projects, advocacy efforts against internet shutdowns, and censorship circumvention tool projects. To encourage participation, we hosted a live chat on several platforms (YouTube chat, Slack, IRC) and, on average, each presenter received around 10 questions from the viewers. All questions discussed during each session are available through this pad: https://pad.riseup.net/p/imv2020-keep Apart from hosting 18 live-streamed sessions, we also worked on promoting each session through the creation of relevant social media assets, as well as through outreach on multiple mailing lists and on all our social media platforms (Twitter, Mastodon, Facebook, Instagram). The Internet Measurement Village 2020 also featured an online social event, the IMV2020 Distance Disco, hosted by Sandy Ordonez on the following platform: https://distancedisco.nl/ At the end of the Internet Measurement Village 2020, we shared a survey to collect community feedback and learn how we can host better events in the future. Our survey is available here: https://ooni.typeform.com/to/cPVT4ILB As all the live-streamed sessions of the IMV will continue to live on the OONI YouTube channel, we hope that these recordings will serve as a valuable resource on internet measurement for the internet freedom community. ### OONI presentation at the Internet Measurement Village 2020 On 10th June 2020, as part of the Internet Measurement Village 2020 (that we organized and hosted throughout June 2020), we live-streamed a presentation about OONI. The video recording of our presentation is available here: https://www.youtube.com/watch?v=SES8PAeQvvs ### Online discussion of findings of OTF Information Controls Fellow research report Over the last year, OONI has served as the host organization for OTF Information Controls Fellow, Chinmayi SK, whose research report was published on the OONI website in mid-June 2020 (see: https://ooni.org/post/2020-those-unspoken-thoughts-otf-fellow-report/). On 25th June 2020, we hosted a session on the OONI Slack channel (https://slack.ooni.org/) -- bridged with IRC -- to provide Chinmayi an opportunity to present and discuss her findings with the community. As part of this session, Chinmayi discussed her research findings in depth, and received several questions from participants. ## Userbase In June 2020, 7,657,872 OONI Probe measurements were collected from 5,942 networks in 208 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

[INFORMATION REQUEST] Onion Service Web Site Deployments
by Matthew Finkel 21 Jul '20

21 Jul '20

(tl;dr: We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that connections with all onion services are secure. Do you send HTTP (unencrypted/unauthenticated) traffic between the onion service and a remote web server?) Hello everyone, Recently we received a question and concern regarding how Tor Browser interacts with web sites over HTTP. Over the last few years, Tor Browser has increasingly trusted HTTP connections with a .onion address (HTTP+.onion) due to the inherent security properties of onion services. The security assumptions Tor Browser makes about these connections is based on another critical assumption: connections between the onion service and the destination web server are "secure" [0]. This assumption is correct when an onion service is run beside the web server and connections between the two components are over localhost/loopback/etc. However, onion services can connect to a remote web server instead, and when the connection between those hosts/components is not secure then Tor Browser's security assumption about the overall connection is wrong. Let's call this latter configuration an "onion tunnel" (for lack of a better term right now). We are now aware some web sites are deploying onion tunnels where the connection between the onion service and the web server is not secure. As a result, we are considering reverting [1] a change of behavior in Tor Browser where "secure cookies" may leak in plaintext under some circumstances in an onion tunnel deployment. Tor Browser treats connections with onion services as secure in other ways, as well. We'd like more information about how onion services are deployed, and whether we should re-think about the current assumption that all .onion connections are secure. Do you know of deployments where HTTP (unencrypted/unauthenticated) traffic is sent between the onion service and a remote web server? (Please email me privately if you feel more confortable with that.) Thanks, Matt [0] In this context, let's say "secure" means a connection that provides unidirectional authenticity, and bidirectional integrity and confidentiality. TLS is the typical example, but onion services provide these properties, too. [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40033

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project July 2020