The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-03T22:38:17Zhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/32Manual bridge support2023-10-03T22:38:17Zmicahmicah@torproject.orgManual bridge supportWhen a user cannot connect to Tor due to censorship, the built-in bridges don’t work *and* requesting a bridge does not work. The user then should be able to find alternative bridge lines and configure them manually. If the user has a br...When a user cannot connect to Tor due to censorship, the built-in bridges don’t work *and* requesting a bridge does not work. The user then should be able to find alternative bridge lines and configure them manually. If the user has a bridge line in text format, they should be able to enter the text string in the Tor app manually.VPN pre-alpha 03cybertacybertahttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/30Built-in bridge support2023-10-03T22:38:17Zmicahmicah@torproject.orgBuilt-in bridge supportWhen a user cannot connect to Tor due to censorship and they've chosen to manually configure their connection, they should be able to select from a list of bridges to use for connecting to Tor and circumvent censorshipWhen a user cannot connect to Tor due to censorship and they've chosen to manually configure their connection, they should be able to select from a list of bridges to use for connecting to Tor and circumvent censorshipVPN pre-alpha 03cybertacybertahttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/29Manual circumvention connection2023-09-18T14:20:40Zmicahmicah@torproject.orgManual circumvention connectionIn the cases where the user is experiencing the connection difficulties, due to censorship, but does not want to provide their location, they should be able to manually configure their Tor connection settings to avoid providing their loc...In the cases where the user is experiencing the connection difficulties, due to censorship, but does not want to provide their location, they should be able to manually configure their Tor connection settings to avoid providing their location.VPN pre-alpha 03https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/64Error handling UX reminder2024-01-18T16:23:38ZetaError handling UX reminderI need to write up something in tpo/applications/vpn about how to handle connection failures (with logs); this is a reminder ticket to do that :pI need to write up something in tpo/applications/vpn about how to handle connection failures (with logs); this is a reminder ticket to do that :pVPN pre-alpha 05etaetahttps://gitlab.torproject.org/tpo/web/team/-/issues/48make a post-mortem forllowing the YEC 2023 launch2024-02-08T18:44:14Zanarcatmake a post-mortem forllowing the YEC 2023 launchjust a ticket to keep track of issues we find during the YEC 2023 launch today
- [ ] https://gitlab.torproject.org/tpo/web/blog/-/merge_requests/228 was merged without review, and prior to when @lavamind and @mattlav were around to hand...just a ticket to keep track of issues we find during the YEC 2023 launch today
- [ ] https://gitlab.torproject.org/tpo/web/blog/-/merge_requests/228 was merged without review, and prior to when @lavamind and @mattlav were around to handle the actual launch
- [ ] tor browser start announcing the launch before the time as well
- [ ] TPA (@anarcat) postponed the launch from "midnight UTC" to "morning America/Eastern" without proper coordination
- [ ] translation strings were sent to @emmapeel too late
- [ ] the donate website is under documented, a total mess, and hard to test
- [ ] specifically, it was believed it was not possible to test the donation workflow in staging
This is not to lay blame on anyone, nor to divert us from the YEC. Those are issues we can look at much later.
ideas for future improvements:
- organize the timeline on GitLab milestones and issues (or at least Nextcloud) instead of a private Google Docs, and keep tickets up to date with progress
- have a point person responsible for technical coordination that's available for the week before launch, during launch, and after launch
- ensure testing is performed long before launch
- ensure translations are ready before launch
- ensure donate.tpo is up to date before sending announcements
- document deployment workflows properly
- communicate clearly, to all stakeholders, when a blocker occurs
/cc @lavamind @mattlav @gabaYear End Campaign 2023anarcatanarcathttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/141Wrong colors connect button2024-03-19T10:57:10ZkwadronautWrong colors connect buttonFirst start through the quick settings, the connect word on the button doesn't have the right colors.
![image](/uploads/b06015a3539cc114ea316f066b2bf33a/image.png)![Screen_recording_20240202_120508](/uploads/99eef0ba1a5313a40cfbae023ae3...First start through the quick settings, the connect word on the button doesn't have the right colors.
![image](/uploads/b06015a3539cc114ea316f066b2bf33a/image.png)![Screen_recording_20240202_120508](/uploads/99eef0ba1a5313a40cfbae023ae3d4ac/Screen_recording_20240202_120508.mp4)VPN pre-alpha 06cybertacybertahttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/72Upstream the PT work2024-03-27T17:23:17ZetaUpstream the PT workThe PT stuff currently relies on horrid non-upstreamed arti hacks. This should be fixed.The PT stuff currently relies on horrid non-upstreamed arti hacks. This should be fixed.VPN pre-alpha 06https://gitlab.torproject.org/tpo/applications/vpn/-/issues/91Appearance Screen2024-03-13T13:43:06ZcybertaAppearance ScreenAs part of the app settings the user can choose between different app background designs and app icons.
Within this issue, we'll implement the background design selection and the basic app icon selection UI. The logic to switch the app ...As part of the app settings the user can choose between different app background designs and app icons.
Within this issue, we'll implement the background design selection and the basic app icon selection UI. The logic to switch the app icons and the integration of alternative app icon images will be implemented in a separate issue.VPN pre-alpha 06cybertacybertahttps://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.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41054Improve color contrast of purple elements in connection settings in dark theme2022-11-08T14:01:23ZdonutsImprove color contrast of purple elements in connection settings in dark themeThe purple check in the connection status strip in `about:preferences#connection` could do with higher contrast in dark theme:
- [connection-status](/uploads/841682da9722abc61e7f83c3f35a9e6b/connection-status.png)
The same also applies...The purple check in the connection status strip in `about:preferences#connection` could do with higher contrast in dark theme:
- [connection-status](/uploads/841682da9722abc61e7f83c3f35a9e6b/connection-status.png)
The same also applies to the "Connected" pill present on bridge cards, which uses two tones of purple:
- [connected-pill](/uploads/b56e147826f343f285ccc01203d55dcf/connected-pill.png)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/web/community/-/issues/273[Snowflake] Update the standalone instructions2022-08-18T15:17:12ZGus[Snowflake] Update the standalone instructionsFrom https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40125
If I may I'd point out that the NAT behaviour tool page linked at https://community.torproject.org/relay/setup/snowflake/standalone/ ne...From https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40125
If I may I'd point out that the NAT behaviour tool page linked at https://community.torproject.org/relay/setup/snowflake/standalone/ needs updating as well. Currently the syntax uses 'go get' which is deprecated in favour of 'go install'. I only had success with "go install github.com/pion/stun/cmd/stun-nat-behaviour@latest".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/65S96 dynamic IP obfs4 bridge performance insufficiency2023-04-10T17:37:21ZshelikhooS96 dynamic IP obfs4 bridge performance insufficiencyThis issue describes a potential usability issue with S96 dynamic IP address obfs4 bridges. The network connectivity between these bridges hosted at OVH and Tor's China vantage has an insufficient performance level to get Tor bootstrap c...This issue describes a potential usability issue with S96 dynamic IP address obfs4 bridges. The network connectivity between these bridges hosted at OVH and Tor's China vantage has an insufficient performance level to get Tor bootstrap consistently.
Tor like any network application assumes a certain level of network performance to operate [correctly](https://gitlab.torproject.org/tpo/core/tor/-/issues/16844). However, the dynamic IP obfs4 bridge currently set up have a download speed of 5-20 KByte/s during some time of the day. This speed makes its end-user experience inconsistent, and sometimes stop working(This is observed by both @cohosh and me when the bridge is unable to finish bootstrap and progress stuck at 50%).
Additional diagnose(see [below](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/65#note_2796296)) show ping to Sr2CobaltPluto bridge provided by @irl have a packet loss of 8%. For an ordinary TCP stack, this packet loss level will almost always result in a slow transfer speed.
The root cause of this issue is the TCP stack used is not designed to sufficiently compensate for packet loss; network link to OVH instance is throttled(intentional or not) with 1. transit via congested [AS4134](https://bgp.he.net/AS4134) CHINANET backbone network (as presumably a deprioritized traffic), 2. traffic between instance located Europe and vantage point took a detour at the US(see traceroute in the link above).
~~This issue is marked as confidential to prevent the IP address of our vantage point become public.~~
(traceroute info removed to make this ticket public.)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoo