The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-27T18:12:37Zhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/15Sponsor 96 - Objective 3: Update a diverse set of proven open source circumve...2024-02-27T18:12:37ZGabagaba@torproject.orgSponsor 96 - Objective 3: Update a diverse set of proven open source circumvention applications so they are compatible with new bridges and censorship resistance/detection techniques.The Tor Project and its partners in this project have developed a set of applications that are proven to be useful for human rights defenders and their organizations, journalists, whistleblowers, and activists living under censorship and...The Tor Project and its partners in this project have developed a set of applications that are proven to be useful for human rights defenders and their organizations, journalists, whistleblowers, and activists living under censorship and surveillance in China and other places around the world. The goal of this objective is to enhance these applications with our new bridges and censorship resistance/detection techniques. We will also execute a push to bring these apps to the mobile experience, as China, Hong Kong, and Tibet are mobile-first cultures
We have focused on mobile so heavily because most of our target users use mobile devices because they are less expensive and easier to acquire than desktops. Mobile devices are not only phones--this also includes all devices that run on Android, like tablets and televisions, and our project is designed to run across platforms whenever possible. We acknowledge that there can be challenges to focusing on mobile devices, because the censors are also focusing on phones. In some regions law enforcement requires certain apps be installed on every phone. When we build our tools, we are considering this threat environment and thinking about how to get around this kind of detection. All of this work will benefit desktop circumvention as well.
- O3.1: Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android).
- O3.2: Integrate Snowflake into Tor Browser stable.
- O3.3: Improve automatic censorship detection in OnionShare desktop.
- O3.4: Integrate Tor into CalyxOS.
- O3.5: Integrate Tor+Snowflake/obfs4 capabilities into mobile applications.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/20goptlib doesn't allow optimistic SOCKS data2022-03-01T17:19:09ZDavid Fifielddcf@torproject.orggoptlib doesn't allow optimistic SOCKS datagoptlib [wraps its socket](https://gitweb.torproject.org/pluggable-transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n203) in a [bufio.ReadWriter](https://golang.org/pkg/bufio/#ReadWriter) while processing ...goptlib [wraps its socket](https://gitweb.torproject.org/pluggable-transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n203) in a [bufio.ReadWriter](https://golang.org/pkg/bufio/#ReadWriter) while processing the SOCKS handshake. Before returning the socket back to the application, [it makes sure](https://gitweb.torproject.org/pluggable-transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n437) there is no unread data sitting in the buffer (which would otherwise be lost).
In legacy/trac#24432, we're trying to have Tor Browser use meek-client as a proxy directly, not going through Tor. The problem (comment:19:ticket:24432) is that Tor Browser has a special optimistic data SOCKS patch that causes it to send data exactly where goptlib checks to make sure there isn't any.
A mild rewrite of goptlib's SOCKS code could eliminate the internal buffer and enable Tor Browser's optimistic data.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40019Now that we have a docker-based probe test, figure out how to keep bridges up...2024-02-27T19:03:51ZCecylia BocovichNow that we have a docker-based probe test, figure out how to keep bridges up to dateWe've got our docker-based tests and are starting to collect measurements from different vantage points. We've been baking obfs4 bridges into the docker image, but how do we keep this image up to date? My current plan has been to check t...We've got our docker-based tests and are starting to collect measurements from different vantage points. We've been baking obfs4 bridges into the docker image, but how do we keep this image up to date? My current plan has been to check the probes from the Canada vantage point every week and replace a bridge if probes from Canada fail for more than 2-3 days in a row. Is there a way to do this more dynamically? Do we run our own bridges?https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/16Sponsor 96 - Objective 4: Surge by deploying region-specific and varied outre...2023-12-20T05:45:10ZGabagaba@torproject.orgSponsor 96 - Objective 4: Surge by deploying region-specific and varied outreach, and distribution localized efforts.- O4.1: Localize all UI modified in this project.
- O4.2 Create and publish user documentation.
- O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps.
- O4.4: Build region-specific outreach, distribution, and use...- O4.1: Localize all UI modified in this project.
- O4.2 Create and publish user documentation.
- O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps.
- O4.4: Build region-specific outreach, distribution, and user support.
- O4.5: Conduct end-user feedback collection and usability research.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2023-12-21https://gitlab.torproject.org/tpo/web/tpo/-/issues/215Please post job description to website - "Software Developer, Rust"2021-07-21T15:48:33ZErin WyattPlease post job description to website - "Software Developer, Rust"# Internet Freedom Nonprofit Seeks Rust Developers
July 20, 2021
The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human rights and freedoms by creating and deploying free and open source anonymity and privacy technol...# Internet Freedom Nonprofit Seeks Rust Developers
July 20, 2021
The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies, is seeking two experienced Rust developers to be a part of the Network Team.
These developers will be an integral part of a small team that develops and maintains the networking software at the core of the Tor network, keeping it secure and improving it for the future. (Over the past 15 years, we've been developing the Tor implementation in C; but the time has finally come to migrate to Rust.)
The team coordinates both synchronously and asynchronously via IRC, email, bug trackers, and some voice meetings. A personal commitment to free and open source software, good communication and documentation skills, and passion for contributing to the greater good are all essential.
This is a full-time, remote position. Salary for this position is $90k - $110k USD, depending on experience, and there is voluntary opt-in salary transparency for employees and contractors.
## The Job:
### Summary
In this role, you will:
- Help design, develop, and improve (Arti) [https://blog.torproject.org/announcing-arti], our Rust implementation of the Tor protocol.
- Help other team members improve their Rust skills.
- Collaborate with other Tor teams to integrate Arti in their workflows.
- Contribute to other free, open-source Rust projects as needed, especially to ones that Arti depends on.
### Required Technical Skills and Experience
- Familiarity with the Rust programming language, and with system design in Rust.
- Strong remote work and time management skills.
- Good communication and documentation skills.
- Enthusiasm for teaching and learning within a distributed team.
### Preferred Qualifications
(These are good to have, but not required!)
- Experience with async/await programming in Rust.
- Experience with portable, cross-platform coding. (We work on Unix, OSX, Windows, iOS, and Android, and we're aiming to expand to WASM.)
- Experience with developing large software projects, keeping them maintainable and flexible over time.
- Experience with API design and documentation.
- Familiarity with privacy, network programming, distributed systems, security, and cryptography.
- Familiarity with FOSS software engineering practices.
- Familiarity with C (for reading old tor code).
- Experience with reading and writing technical specifications.
Academic degrees are great, but not required if you have the right experience! If you feel that you meet several of these requirements or could meet them with a little support, we would love to hear from you.
## How to Apply
To apply, submit a cover letter, your CV/resume (including three professional references), and a link to a code sample or some non-trivial software project you have significantly contributed to. In your cover letter, please include the reason you want to work at the Tor Project.
IMPORTANT: Please email application materials in PDF format to job-network at torproject dot org with "Network Developer" in the subject line.
## About The Tor Project
The Tor Project's workforce is smart, committed, and hard working. We currently have a paid and contract staff of around 28 developers and operational support people, plus many thousands of volunteers who contribute to our work. The Tor Project is funded in part by government research and development grants, and in part by individual, foundation, and corporate donations.
Tor is for everyone, and we are actively working to build a team that represents people from all over the world - people from diverse ethnic, national, and cultural backgrounds; people from all walks of life. We encourage people subject to systemic bias to apply, including people of color, indigenous people, LGBTQIA+ people, women, and any other person who is part of a group that is underrepresented in tech.
The Tor Project has a competitive benefits package, including a generous PTO policy, 16 paid holidays per year (including the week between Christmas and New Year's, when the office is closed), and flexible work schedule. Insurance benefits vary by employment status and country of residence.
The Tor Project, Inc. is an equal opportunity, affirmative action employer.GusGushttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40062Snowflake should self-diagnose where it fails in the connection process, and ...2022-04-08T10:56:52ZRoger DingledineSnowflake should self-diagnose where it fails in the connection process, and inform TorWe have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps succe...We have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps successfully on the VPS we're trying it from, but clearly that's not the end of the story. For example, I bet the mobile carriers have different constraints.
I was first thinking to suggest some standalone Snowflake debugging tool that would try a bunch of things and see how they go and summarize it for the user.
But then I realized: Snowflake itself should do this, because it *does* try things, and it learns how they go, and our users already have it. So all that remains is (a) figuring out which conclusions are worth escalating to the user, possibly including some refactoring inside Snowflake to do the steps in a way where we're confident in our results, and then (b) deciding what the right pathway is for escalating the information.
For 'b', we should be careful to avoid getting bogged down picking between options, since there are plenty of approaches that will do adequately. Maybe the PT log command is useful here, and (if I understand it correctly) in that case the way users can see the output is by preferences->tor->view logs.
And then I imagine the bulk of the work will be in step 'a'.
To get us started: what is the taxonomy of ways that Snowflake can fail to make its connection? And for each of those ways, is there an obvious point where Snowflake can self-assess that it has failed?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/64Create a circumvention map json2022-02-25T16:58:38Zmeskiomeskio@torproject.orgCreate a circumvention map jsonOn a fast look into OONI and the [state-of-censorship.json](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json) this is what I can come up with:
```json
{
"by": {
"setti...On a fast look into OONI and the [state-of-censorship.json](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json) this is what I can come up with:
```json
{
"by": {
"settings": [
{"bridges": {"type": "obfs4", "source": "builtin"}},
{"bridges": {"type": "vanilla", "source": "bridgedb"}},
{"bridges": {"type": "obfs4", "source": "bridgedb"}},
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"cn": {
"settings": [
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"tm": {
"settings": [
{"bridges": {"type": "obfs4", "source": "bridgedb"}},
{"bridges": {"type": "snowflake", "source": "builtin"}}
]
},
"ru": {
"settings": [
{"bridges": {"type": "snowflake", "source": "builtin"}},
{"bridges": {"type": "obfs4", "source": "bridgedb"}}
]
}
}
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40707Test all combinations of bridges, PTs, proxies to make sure success/failure i...2022-04-04T17:19:52ZRoger DingledineTest all combinations of bridges, PTs, proxies to make sure success/failure is properly reportedWe have a variety of different ways that you can configure your Tor client at startup:
* with no bridges, with one bridge, with two bridges, with many bridges
* if bridges, bridges with various PTs like obfs4 and snowflake
* with or with...We have a variety of different ways that you can configure your Tor client at startup:
* with no bridges, with one bridge, with two bridges, with many bridges
* if bridges, bridges with various PTs like obfs4 and snowflake
* with or without a proxy setting
* combinations of the above, like setting both bridges *and* a proxy
In all of these possible settings, if things work, Tor is supposed to send Tor Browser a controller event indicating success, so Tor Browser can know that things worked and let the user browse.
And if things *don't* work, Tor is supposed to escalate that failure to Tor Browser also, so Tor Browser can know things aren't working and tell the user, try another config, or whatever it wants to do.
We suspect there are some bugs in Tor where it doesn't reliably report failures in some combinations -- causing Tor Browser to just sit there with its bootstrapping progress bar forever.
As a first step in the saga, we have this ticket, which is: we should work through the matrix of config combinations, and test them for the success case and for the failure case, and see how Tor actually behaves.
Then once we have some surprises, we can open tickets for the surprises and try to get them fixed (likely in core Tor, because we want Tor to behave correctly for all controllers, rather than teach Tor Browser to do workarounds).richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/40043Test all combinations of bridges, PTs, proxies to make sure success/failure i...2023-11-06T22:10:35ZRoger DingledineTest all combinations of bridges, PTs, proxies to make sure success/failure is properly reportedWe have a variety of different ways that you can configure your Tor client at startup:
* with no bridges, with one bridge, with two bridges, with many bridges
* if bridges, bridges with various PTs like obfs4 and snowflake
* with or with...We have a variety of different ways that you can configure your Tor client at startup:
* with no bridges, with one bridge, with two bridges, with many bridges
* if bridges, bridges with various PTs like obfs4 and snowflake
* with or without a proxy setting
* combinations of the above, like setting both bridges *and* a proxy
In all of these possible settings, if things work, Tor is supposed to send Tor Browser a controller event indicating success, so Tor Browser can know that things worked and let the user browse.
And if things *don't* work, Tor is supposed to escalate that failure to Tor Browser also, so Tor Browser can know things aren't working and tell the user, try another config, or whatever it wants to do.
We suspect there are some bugs in Tor where it doesn't reliably report failures in some combinations -- causing Tor Browser to just sit there with its bootstrapping progress bar forever.
As a first step in the saga, we have this ticket, which is: we should work through the matrix of config combinations, and test them for the success case and for the failure case, and see how Tor actually behaves.
Then once we have some surprises, we can open tickets for the surprises and try to get them fixed (likely in core Tor, because we want Tor to behave correctly for all controllers, rather than teach Tor Browser to do workarounds).https://gitlab.torproject.org/tpo/ux/design/-/issues/26Update our browser design files, icon library and source new style guides2021-10-01T19:47:25ZdonutsUpdate our browser design files, icon library and source new style guidesAs of [Firefox 89](https://www.mozilla.org/en-US/firefox/89.0/releasenotes/), our internal design files, main reference guide for Photon ([design.firefox.com/photon](https://design.firefox.com/photon/)) and Firefox's icon library ([desig...As of [Firefox 89](https://www.mozilla.org/en-US/firefox/89.0/releasenotes/), our internal design files, main reference guide for Photon ([design.firefox.com/photon](https://design.firefox.com/photon/)) and Firefox's icon library ([design.firefox.com/icons](https://design.firefox.com/icons)) are obsolete.
In order to support the transition onto the Firefox 91 ESR as best we can, the UX team will need access to:
- Updated design files/libraries for Figma (preferred, but not essential) or Sketch
- An updated pattern library/style guide or other reference material (if not included in the above)
- The new icon suite in vector format
It would also be great (although not critical) if we could discuss some way to stay in sync with any changes to the above too.donutsdonutshttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40010O1.4.2: Run a public campaign to encourage new individual operators to establ...2022-07-20T20:56:47ZGabagaba@torproject.orgO1.4.2: Run a public campaign to encourage new individual operators to establish bridges.This campaign will target individuals and nonprofits who are part of the Internet freedom community, like free software advocates, relay associations, technical collectives, and hosting companies. In a previous DRL project titled Empower...This campaign will target individuals and nonprofits who are part of the Internet freedom community, like free software advocates, relay associations, technical collectives, and hosting companies. In a previous DRL project titled Empowering Communities in the Global South to Bypass Censorship, we ran a bridge campaign and added approximately 100 obfs4 bridges to the network, and we know this strategy is effective in growing the capacity of bridge bandwidth resources.
- [ ] [November 2021's campaign](https://gitlab.torproject.org/tpo/community/relays/-/issues/24)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/ux/research/-/issues/44Add a persona who rejects modern web technology2023-08-08T18:55:19ZMatthew FinkelAdd a persona who rejects modern web technologyI would like to capture the persona that wishes for the web as it existed in 1999. They don't want any of the new, dynamic features available in other web browsers and they only want HTML rendering without being tracked. They reject the ...I would like to capture the persona that wishes for the web as it existed in 1999. They don't want any of the new, dynamic features available in other web browsers and they only want HTML rendering without being tracked. They reject the assumption of other browsers that "more is better" and they want a browser that is less complicated and only does what they want.https://gitlab.torproject.org/tpo/core/arti/-/issues/153Conditional compilation of tor-checkable2021-10-06T17:47:35Zdaniel.eadesConditional compilation of tor-checkableI was reading the design decisions behind the tor-checkable library, in particular that many of the exposed methods are useful for testing, but not in production.
I wonder if it's worth exploring using conditional compilation to toggle t...I was reading the design decisions behind the tor-checkable library, in particular that many of the exposed methods are useful for testing, but not in production.
I wonder if it's worth exploring using conditional compilation to toggle the presence or visibility of these methods. For example you could these items behind a
```rust
#[cfg(test)] pub use ...
```
The methods exposed in production builds would defer to the conditionally visible methods under the hoodhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40347Add SPF and/or DKIM and/or others for lists.torproject.org2022-12-10T03:21:38ZRoger DingledineAdd SPF and/or DKIM and/or others for lists.torproject.orgIt occurred to me yesterday that while we will have a tough time promising the internet that all @torproject.org emails will come from eugeni, it is easy to promise that all the @lists.torproject.org emails will come from eugeni -- becau...It occurred to me yesterday that while we will have a tough time promising the internet that all @torproject.org emails will come from eugeni, it is easy to promise that all the @lists.torproject.org emails will come from eugeni -- because I think that's already the case and we have no plans to change it.
I believe @lavamind already (yesterday) enabled an spf line for the lists.tpo domain. How's that going?
We could go farther and enable dkim or dmarc or whatever else we pick as well (assuming they can each be applied to subdomains of a domain that itself does not yet have them enforced).improve mail serviceshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40561Refactor about:torconnect implementation2021-07-22T17:47:41ZMatthew FinkelRefactor about:torconnect implementationTurns out, the first time wasn't the best design. Let's re-do it more smartly.Turns out, the first time wasn't the best design. Let's re-do it more smartly.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40294Individual-resistance: HTTPS by default2022-03-15T17:17:46ZGabagaba@torproject.orgIndividual-resistance: HTTPS by defaultAs part of the Collaborative ResistancE to Web Surveillance (CREWS)'s project with UCL we are going to build a prototype to understand of effectiveness of enhanced eavesdropping protection in Tor Browser.
Modern web browsers, including...As part of the Collaborative ResistancE to Web Surveillance (CREWS)'s project with UCL we are going to build a prototype to understand of effectiveness of enhanced eavesdropping protection in Tor Browser.
Modern web browsers, including Tor Browser, will indicate that unencrypted web traffic is insecure, but not block unencrypted traffic, because some websites do not support encryption. Therefore malicious intermediaries can perform “SSL-stripping attacks”, forcing the browser to downgrade to unencrypted traffic. For this project we will **evaluate how to require encryption to be enabled unless the user explicitly permits downgrading**. We will explore approaches to clearly describe the risks of sharing web browsing data with intermediaries (legibility) and giving the user controls of whether to proceed nevertheless (agency).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40563Rebase 11.0 patches on 91.0b52021-07-29T08:18:10ZMatthew FinkelRebase 11.0 patches on 91.0b54fc4d759365dc2ffe2774b32c4621db890062e7f4fc4d759365dc2ffe2774b32c4621db890062e7fhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40436circuit_resume_edge_reading_helper checks wrong package window2021-11-22T19:45:48ZMike Perrycircuit_resume_edge_reading_helper checks wrong package windowIn order to decide the maximum it can package on a circuit, circuit_resume_edge_reading_helper() checks only the circuits package window, which is not used if layer_hint is non-NULL.
The consequences of this are unclear. It seems that b...In order to decide the maximum it can package on a circuit, circuit_resume_edge_reading_helper() checks only the circuits package window, which is not used if layer_hint is non-NULL.
The consequences of this are unclear. It seems that because the max to package is set to the cell highwater size and queue length if it is too large, this should not have much effect in practice. But we should do the correct check here, in any case.
Found while hooking up congestion control code. Fix will be part of that branch, because I actually fixed it while refactoring the choice of which package window to use into a function.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/web/tpo/-/issues/216Add new green onion members - Defcon and Blockchair2021-07-22T23:45:58ZGusAdd new green onion members - Defcon and Blockchairhttps://twitter.com/torproject/status/1414993025579749376https://twitter.com/torproject/status/1414993025579749376GusGushttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40564[meta] Evaluate if Tor Browser is meeting the needs of our users2022-01-31T16:54:17ZMatthew Finkel[meta] Evaluate if Tor Browser is meeting the needs of our usersTor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important ...Tor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important for the [people](https://community.torproject.org/user-research/persona/) we are trying to protect.
We should be able to justify our general design requirements through the needs of our users, instead of defining the strictest-possible private browser design and then applying that to all of the use cases. Indeed, this should influence tor-browser-spec#25021.
cc @duncan @nahTor Browser: 11.0 Issues with previous release