|
|
The following is a page to help with GSoC / SoP / Outreachy coordination.
|
|
|
|
|
|
# GOOGLE SUMMER OF CODE'S PROJECTS FOR 2023
|
|
|
|
|
|
The following 4 projects are the ones we have in 2023 for students from Google Summer of Code. You can[ read about how to contact us and apply](https://gitlab.torproject.org/tpo/team/-/wikis/How-To-Apply-to-Google-Summer-of-Code).
|
|
|
|
|
|
## 1. Relay to relay connectivity in the Tor network
|
|
|
|
|
|
- Mentor: juga, GeKo
|
|
|
- Hours required: 175 hours
|
|
|
- Skills required: Rust
|
|
|
- Expected outcome: A tool scanning the Tor network for partitions is ready to be deployed
|
|
|
- Difficulty: medium
|
|
|
|
|
|
### Problem
|
|
|
|
|
|
In an ideal world, any Tor relay would be able to reach any other Tor relay when trying to build paths through the network, as partitioning in the Tor network is bad for Tor's anonymity guarantees. While we might be lucky and there are no partitions in the network right now (which is very unlikely), we currently have no means to monitor that property of our network and detect if that changes in the future.
|
|
|
|
|
|
### Proposal
|
|
|
|
|
|
This project would involve the implementation of a relay to relay connectivity checking tool written in Rust to make use of our arti Tor client (which is written in Rust, too).
|
|
|
|
|
|
There have been many attempts in the past to write such a tool. However, none of them succeeded in producing one that we can use for keeping track of relay connectivity on a regular basis, which is an important network health goal. There are resources below pointing to past attempts and issues encountered which should be considered when designing the relay to relay connectivity checker in this project. Particular focus should be placed on a sound scanning strategy taking an additional load onto the network into account and how to store the results so we can use them in follow-up work for further visualization, e.g. on a dashboard, making the partitions in the network visible over time.
|
|
|
|
|
|
*Resources:*
|
|
|
|
|
|
For arti:
|
|
|
- https://gitlab.torproject.org/tpo/core/arti
|
|
|
|
|
|
For general information about past work on relay to relay connectivity scanning:
|
|
|
- https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/1
|
|
|
- https://gitlab.torproject.org/tpo/core/tor/-/issues/19068
|
|
|
- https://gitlab.torproject.org/tpo/network-health/metrics/ideas/-/issues/25775
|
|
|
- https://gitlab.torproject.org/tpo/network-health/team/-/issues/16
|
|
|
- https://lists.torproject.org/pipermail/tor-project/2017-October/001492.html
|
|
|
- https://lists.torproject.org/pipermail/network-health/2021-March/000668.html
|
|
|
- https://github.com/teor2345/onion-graph
|
|
|
- https://bitbucket.org/ra_/tor-relay-connectivity.git
|
|
|
- https://github.com/david415/tor_partition_scanner
|
|
|
- https://github.com/sachaservan/ShorTor
|
|
|
|
|
|
## 2. Rust/Arti API exploration to build examples/tools/utilities
|
|
|
|
|
|
- Mentors: Nick & Ian
|
|
|
- Hours required: 175 hours
|
|
|
- Skills required: Knowledge of Rust, ideally with experience in async programming
|
|
|
- Expected outcome: One or more example projects using Arti. Constructive discussions leading to changes to, or recommendations for, Arti's APIs and documentation.
|
|
|
- Difficulty: Medium
|
|
|
|
|
|
### Proposal
|
|
|
|
|
|
We're looking for a student with ideas for nice simple Tor-based projects that they would like to build in Rust, using Arti, our Rust tor implementation. The purpose would be to help create example code for others and to evaluate and improve our APIs and documentation. You can program most anything Tor-based Rust tool or library that you would like; a collection of small example programs is better than one big one. We'd work
|
|
|
with you to help choose which of your ideas to begin with.
|
|
|
|
|
|
Up to this point, the Arti APIs have had limited use by external contributors so you would be an early adopter and be able to influence the APIs' evolution.
|
|
|
|
|
|
|
|
|
## 3. Snowflake landing page revamp
|
|
|
|
|
|
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|
|
|
|
|
|
### Update 12 March 2023
|
|
|
|
|
|
- We received an overwhelming amount of emails. Please be mindful of our team's time and bandwidth as we respond to emails.
|
|
|
- Do not send a wireframe in your email. We're following a user-centered design process and as such we need to make sure that whatever new design we come up with builds on the usability research we're conducting. For now, ideas on how to complement the usability research, ideas for other technical implementations are welcome.
|
|
|
- This email does not constitute a GSoC proposal, this is just to start an initial conversation and receive feedback for your main proposal!
|
|
|
|
|
|
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|
|
|
|
|
|
- Mentors: raya and donuts (IRC).
|
|
|
- Hours required: to be determined.
|
|
|
- Skills required: Lektor, HTML/CSS, Bootstrap.
|
|
|
- Other good skills to have: understanding of UX/UI, understanding of user-centered design processes, Web design.
|
|
|
- Expected outcome: a redeveloped landing page explaining Snowflake that's well integrated with other Tor Web products and builds off of user research.
|
|
|
- Difficulty: low.
|
|
|
|
|
|
## Problem
|
|
|
Snowflake is helping many people around the world bypass the blocking of Tor, particularly in highly censored environments. Since September 2022 Snowflake has grown exponentially in popularity; we observed a staggering growth in the number of volunteer proxies.
|
|
|
|
|
|
The main source of information on Snowflake – addressed to a general public – is the following landing page: https://snowflake.torproject.org/.
|
|
|
|
|
|
Currently, The Tor Project user research team is reviewing the landing page's usability in terms of content and navigation; see the related ticket here: https://gitlab.torproject.org/tpo/ux/research/-/issues/103.
|
|
|
|
|
|
Based on the findings of the above research, we will work to design and develop n improved landing page. The landing page must be well integrated with Tor's Web products and ecosystem (i.e. it must apply Tor's brand guidelines for Web – which are currently under review – and be developed using technologies used by Tor).
|
|
|
|
|
|
## Process:
|
|
|
This is how we think the process will go after GSoC contributors are selected for this project:
|
|
|
|
|
|
- The Tor Project completes the usability research on the landing page and Tor designers start working on fresh UIs for the website (please see this ticket for more information on the ongoing usability research: https://gitlab.torproject.org/tpo/ux/research/-/issues/103).
|
|
|
- GSoC contributor(s) are invited to take part in the above process of translating research findings into interfaces, this could take the form of giving feedback on wireframes and brainstorming options (this is optional however it would be good for potential contributors to demonstrate an understanding of user-centered design processes).
|
|
|
- GSoC contributor(s) work together with project mentors to translate wireframes into code in order to develop the website, ensuring that the website complies with Tor's brand guidelines and is integrated with Tor's Web ecosystem.
|
|
|
|
|
|
## Responsibilities:
|
|
|
|
|
|
**Main responsibility:**
|
|
|
- To lead on the development of the landing page.
|
|
|
|
|
|
**Other responsibilites:**
|
|
|
- Support with translating user research findings into user interfaces and experiences.
|
|
|
- Support with design improvements and wireframes.
|
|
|
|
|
|
## Related tickets on GitLab important to read – but do not spam our GitLab tickets :(
|
|
|
Please check the below tickets out and read through the conversations that happened on them – you're not required at all to respond on the tickets just read through them – not all are directly relevant to our problem but they will help set the scene:
|
|
|
- Update Landing Page (snowflake.torproject.org): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40125 (closed)
|
|
|
- Usability Testing - Snowflake landing page: https://gitlab.torproject.org/tpo/ux/research/-/issues/103
|
|
|
- Collect feedback on landing page content (snowflake.torproject.org): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40209
|
|
|
- Improve guide for running standalone Snowflake proxy: https://gitlab.torproject.org/tpo/web/community/-/issues/301
|
|
|
|
|
|
## For GSoC contributors
|
|
|
|
|
|
- Read through the above carefully.
|
|
|
- Please, do not submit any merge requests or comment on GitLab tickets. We only need an email now.
|
|
|
- Send an email to raya (at) torproject.org with the subject line `Snowflake landing page revamp for GSoC 2023` detailing:
|
|
|
- Why you're interested in this GSoC project.
|
|
|
- Why you're interested in contributing to The Tor Project more broadly.
|
|
|
- Demonstrate skillset for the project.
|
|
|
- Some ideas you might have for the project.
|
|
|
- How you believe you can become an active contributor to The Tor Project post-GSoC.
|
|
|
|
|
|
## 4. The Tor network status API
|
|
|
|
|
|
- Mentor: hiro, GeKo
|
|
|
- Hours required: 175 hours
|
|
|
- Skills required: Rust, RESTful architectures
|
|
|
- Expected outcome: An API providing network and node status information
|
|
|
- Difficulty: medium
|
|
|
|
|
|
### Problem
|
|
|
|
|
|
We are in the process of building a service to store and index documents produced by network nodes into a postgresql database and a timeseries database (VictoriaMetrics).
|
|
|
We want to design a RESTful API to query the two databases and provide metrics about the current status of the network and its nodes.
|
|
|
|
|
|
### Proposal
|
|
|
|
|
|
This project will involve the design of a web-based API to provide status information and metrics about the Tor network and its individual nodes.
|
|
|
Onionoo is our current web-based protocol to learn about running Tor relays and bridges, we want to design a RESTful service extending and/or redesigning the onionoo protocol, using our new data pipeline [1].
|
|
|
The focus should be placed on designing the API and its requests and response formats. The proposed framework is actix [2] a web framework for Rust.
|
|
|
|
|
|
*Resources*
|
|
|
|
|
|
- https://gitlab.torproject.org/tpo/network-health/team/-/wikis/metrics/collector/pipeline#proposed-architecture
|
|
|
- https://docs.rs/actix-web/latest/actix_web/
|
|
|
|
|
|
---
|
|
|
|
|
|
---
|
|
|
|
|
|
---
|
|
|
|
|
|
---
|
|
|
|
|
|
---
|
|
|
[Previous Years](gsoc-previous-years) |
|
|
\ No newline at end of file |
|
|
The following is a page to hold all the Google Summer of Code's projects for 2025. You can find [projects](gsoc-previous-years) we had in previous years in [this page](gsoc-previous-years).
|
|
|
|
|
|
# GOOGLE SUMMER OF CODE'S PROJECTS FOR 2025
|
|
|
|