The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-15T19:08:08Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/985Construct NetDir with geoip support2023-11-15T19:08:08ZJanosch GräfConstruct NetDir with geoip supportI wanted to get the country codes from `Relay`, but noticed that they're never set. `tor-netdir` has a `geoip` feature that gives `PartialNetDir` a `new_with_geoip` method. This method is never called currently.
Changes needed to use `P...I wanted to get the country codes from `Relay`, but noticed that they're never set. `tor-netdir` has a `geoip` feature that gives `PartialNetDir` a `new_with_geoip` method. This method is never called currently.
Changes needed to use `PartialNetDir::new_with_geoip`:
- add `geoip` feature to `arti_client`. This is not strictly needed, but is how I imagine one enables geoip support in general.
- add `geoip` feature and optional dependency on `tor-geoip` to `tor-dirmgr`.
- add `geoip_db: Arc<GeoipDb>` to `DirMgr`.
- in `DirMgr::from_config`: get `GeoipDb::from_embedded` and put it into `DirMgr`. We could also pass in the `GeoipDb` from further up the graph. I'm not sure about this.
- add `geoip_db` field to `GetConsensusState` and add it to the constructor.
- add `geoip_db` to `GetCertsState`
- add `geoip_db` to `GetMicrodescsState`. This is needed for `GetMicrodescsState::reset`.
- pass `geoip_db` to `GetMicrodescsState::new`
- this is the call-site of `PartialNetDir::new_with_geoip`
- adding an argument here triggers clippy's warning that the method has to many arguments.
I have working code (only clippy fails) [here](https://gitlab.torproject.org/sw1tch/arti/-/commit/b0d83949923002536cccdab729304ebbf46299a3)
So my main questions are:
1. How do we make clippy happy with the method with too many arguments. Note that 2 arguments in that signature are behind a feature flag.
2. Should we pass the `GeoipDb` to the dirmgr from further up. If so, how?
3. Should we pass `Option<Arc<GeoipDb>>` instead (so it can be disabled at runtime).Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/74Convert from `log` to `tracing`2023-02-01T12:40:13ZNick MathewsonConvert from `log` to `tracing`Arguably, libraries should be using `tracing` rather than `log` to report events. There seem to be bridges between the two.Arguably, libraries should be using `tracing` rather than `log` to report events. There seem to be bridges between the two.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/100Design a temporary application icon for the VPN pre-alpha2023-08-01T16:33:33ZdonutsDesign a temporary application icon for the VPN pre-alphaI think something based on the onion rings (i.e. keeping it generic would be good enough for now. Maybe with a sparkle?
- Resources: [Guidelines](https://developer.android.com/develop/ui/views/launch/icon_design_adaptive) | [Templates](...I think something based on the onion rings (i.e. keeping it generic would be good enough for now. Maybe with a sparkle?
- Resources: [Guidelines](https://developer.android.com/develop/ui/views/launch/icon_design_adaptive) | [Templates](https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m/VPN-pre-alpha?node-id=939%3A2070&t=xXPiif40TbrHiSJg-1) (in Figma)Sponsor 101 - Tor VPN Client for Androiddonutsdonutshttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/21Integrate IPtProxy for PT support2024-02-01T12:07:48Zmicahmicah@torproject.orgIntegrate IPtProxy for PT supportWe expect that part of TorVPN need will be onionmasq being able to call IPtProxy for PT support, ideally onionmasq would start and stop IPtProxy as necessary and probably the communication would happen over SOCKS. This integration work i...We expect that part of TorVPN need will be onionmasq being able to call IPtProxy for PT support, ideally onionmasq would start and stop IPtProxy as necessary and probably the communication would happen over SOCKS. This integration work in onionmasq will need to be done at the rust level and use the FFI to interface.Sponsor 101 - Tor VPN Client for Androidhttps://gitlab.torproject.org/tpo/ux/research/-/issues/94Track User Research for VPN2023-10-02T13:22:42ZNahTrack User Research for VPNThis is a major issue to track all User Research done for S101.
During this research, we will carry on activities to design a Tor VPN client that meet the needs of target users. We will work together with other oganizations and conduct ...This is a major issue to track all User Research done for S101.
During this research, we will carry on activities to design a Tor VPN client that meet the needs of target users. We will work together with other oganizations and conduct research on the existing VPN ecosystem. We will conduct research on Android, desktop, and iOS platforms. Our goal with this phase is to understand the features and functionalities necessary to build a minimal viable product for our target audience, and to bring this research to Objective 2.
- Product: VPN.
- Stakeholders: The Guardian Project.
- Target audience: human rights defenders, NGOs, journalists, activists.
**Methodologies:**
- Surveys (user needs)
- Interviews (job/user stories) #70
- Card sorting (safety features)
- Desk research (vpn ecosystem) #64 #63
**Outcomes:**
- Report Survey
- Report Interviews
- RecommendationsSponsor 101 - Tor VPN Client for Androiddonutsdonutshttps://gitlab.torproject.org/tpo/core/arti/-/issues/461User should be able to run an onion service in the background on iOS2022-05-18T13:09:44ZholmesworcesterUser should be able to run an onion service in the background on iOS<!--
* Use this issue template for submitting a feature.
-->
### Summary
Tor-based apps like [OnionShare](https://onionshare.org/), [Ricochet Refresh](https://www.ricochetrefresh.net/), and [Quiet](https://github.com/ZbayApp/monorepo) ...<!--
* Use this issue template for submitting a feature.
-->
### Summary
Tor-based apps like [OnionShare](https://onionshare.org/), [Ricochet Refresh](https://www.ricochetrefresh.net/), and [Quiet](https://github.com/ZbayApp/monorepo) use Tor to share data directly and privately between peers.
On desktop platforms and Android, a user can choose to leave such an app running in the background.
However, iOS restricts what apps can run in the background. There isn't an obvious way to for these apps leave an onion service running in the background on iOS.
This might be unavoidable given iOS restrictions, but if there was some way for Tor to run an onion service as a background process (I've heard that VPNs might be able to do this?) and fire a notification or wake up another app when it receives an incoming connection, that would be very helpful for developers and users of this class of application, on iOS.
### What is the expected behavior?
An onion service runs in the background on iOS and is capable of receiving an incoming request, firing a notification, and/or waking up another app to handle the incoming request.Sponsor 101 - Tor VPN Client for AndroidAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/423Design & specify handling UDP traffic from the VPN interface into Tor2022-03-29T00:51:43ZGabagaba@torproject.orgDesign & specify handling UDP traffic from the VPN interface into TorDesign & specify handling UDP traffic from the VPN interface into Tor; perform connection mapping on incoming UDP traffic into Tor circuits.Design & specify handling UDP traffic from the VPN interface into Tor; perform connection mapping on incoming UDP traffic into Tor circuits.Sponsor 101 - Tor VPN Client for Androidhttps://gitlab.torproject.org/tpo/ux/design/-/issues/35Create wireframes and document key user journeys for the Tor VPN2023-05-17T20:47:50ZdonutsCreate wireframes and document key user journeys for the Tor VPNKey screens and user flows will require illustration with low-fidelity wireframes, detailing their functions, rough hierarchy in terms of UI elements, and general user experience. Critical functionality (or anything not made immediately ...Key screens and user flows will require illustration with low-fidelity wireframes, detailing their functions, rough hierarchy in terms of UI elements, and general user experience. Critical functionality (or anything not made immediately obvious in the illustration itself) needs to be annotated for developer handoff.
Once complete, we should have a clear idea of the number of screens/templates and UI elements requiring design in order to begin development of the MVP.
This ticket relates to the following objectives:
* O1.3: Create wireframes and potential user flows for the VPN client based on research conducted in O1.1 and O1.2.Sponsor 101 - Tor VPN Client for Androiddonutsdonutshttps://gitlab.torproject.org/tpo/ux/research/-/issues/68Create technical specification for the Tor VPN2023-06-28T16:27:31ZdonutsCreate technical specification for the Tor VPNOnce the product requirements have been agreed upon in https://gitlab.torproject.org/tpo/ux/research/-/issues/66, the list of supported features will be translated into a full technical specification detailing the technical requirements,...Once the product requirements have been agreed upon in https://gitlab.torproject.org/tpo/ux/research/-/issues/66, the list of supported features will be translated into a full technical specification detailing the technical requirements, dependencies and approach required to accomplish each. The technical specification will also need to exercise a degree of foresight, and provide a foundation for the expansion of the MVP’s feature-set in future.
This activity will require multiple teams to collaborate to produce a single doc – each sharing responsibility to document their portion of the project – including: the UX team, the Applications team, the Network team and the Network Health/Metrics team.Sponsor 101 - Tor VPN Client for Androidhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/73Write a proposal to send UDP traffic over Tor2023-11-08T19:10:20ZNick MathewsonWrite a proposal to send UDP traffic over TorNote that this is not for Tor-over-UDP; it's for UDP-over-Tor.Note that this is not for Tor-over-UDP; it's for UDP-over-Tor.Sponsor 101 - Tor VPN Client for AndroidNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1277Make VanguardMgr accessible to CircMgr2024-03-19T15:07:31Zgabi-250Make VanguardMgr accessible to CircMgr`CircMgr::launch_hs_unmanaged` will need to be able to launch circuits that use vanguards, so `CircMgr` will need a handle to `VanguardMgr`.
Depends on #1275`CircMgr::launch_hs_unmanaged` will need to be able to launch circuits that use vanguards, so `CircMgr` will need a handle to `VanguardMgr`.
Depends on #1275Arti: Guard discovery researchgabi-250gabi-250https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/25pass the client IP to tor for country usage stadistics2023-09-21T15:18:26Zmeskiomeskio@torproject.orgpass the client IP to tor for country usage stadisticsThe webtunnel server should use the `X-Real-IP` or another header to get the client IP address and pass it to the tor process so it can produce country based usage statistics.The webtunnel server should use the `X-Real-IP` or another header to get the client IP address and pass it to the tor process so it can produce country based usage statistics.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/26Add a license to the project2023-08-02T14:41:50Zmeskiomeskio@torproject.orgAdd a license to the projectlox-library and lox-wasm have MIT license, but it looks like the rest of the crates don't have any license. We could make all the project be MIT license.lox-library and lox-wasm have MIT license, but it looks like the rest of the crates don't have any license. We could make all the project be MIT license.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/18Create a container image for webtunnel2023-04-19T14:33:45Zmeskiomeskio@torproject.orgCreate a container image for webtunnelWebtunnels bridge operators might want to be able to use a container to run their bridge.
We should produce some documentation on how to run the container.Webtunnels bridge operators might want to be able to use a container to run their bridge.
We should produce some documentation on how to run the container.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/web/support/-/issues/313Review and update the support article about circumventing censorship in China2023-10-31T16:10:20Zchampionquizzerchampionquizzer@torproject.orgReview and update the support article about circumventing censorship in ChinaWe should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)We should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGushttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40630Update builtin bridges from Circumvention Settings API2022-12-22T11:22:11Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/13Fix stability issue discovered in WebTunnel2023-03-10T14:14:19ZshelikhooFix stability issue discovered in WebTunnelCurrently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Currently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/11Upload Connection Parameters to rdsys for Distribution2022-12-07T15:43:23ZshelikhooUpload Connection Parameters to rdsys for DistributionCurrently, WebTunnel does not upload sufficient information to Tor process and in turn rdsys for distribution.
We need to find a way to upload these information to rdsys(including sensitive part like URL) to rdsys.Currently, WebTunnel does not upload sufficient information to Tor process and in turn rdsys for distribution.
We need to find a way to upload these information to rdsys(including sensitive part like URL) to rdsys.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/2O1.4: Increase the number of active HTTPT bridges.2023-06-27T18:40:56ZGabagaba@torproject.orgO1.4: Increase the number of active HTTPT bridges.Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 and HTTPT bridges running on unblocked IP addresses. We have tw...Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 and HTTPT bridges running on unblocked IP addresses. We have two strategies in mind for rapidly increasing these numbers:
- O1.4.1 Increase the number of dynamic bridges run by nonprofit partners. The Tor community has a close relationship with trusted relay operator nonprofits1 that run groups of relays, bridges, and exits. We will ask our relay operator nonprofit partners to set up new bridges, with the specific goal of spinning up new bridges when current ones get blocked, and taking blocked bridges offline. We will offer subsidies to trusted relay nonprofits in order to offset some of their infrastructure costs so that this effort can scale rapidly. We will monitor operation costs after scaling to develop a financial plan for long term sustainability together with these nonprofits.
- O1.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 Empowering Communities in the Global South to Bypass Censorship, we ran a bridge campaign2 and added approximately 100 obfs4 bridges to the network, and we know this strategy is effective in growing the capacity of bridge bandwidth resources.
- O1.4.3: Monitor bridge health. We will build continuous communication with bridge operators, sharing updates with them so they can update bridge configurations so they continue to work in target countries as new blocking attempts are deployed by CCP.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/87Publish a snapshot of what PTs are needed for successful Tor use in each country2022-07-20T21:15:30ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (legacy/trac#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is legacy/trac#23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.org