It seems that neither the current nor the proposed design of the Tor Launcher takes much care about the use case where Tor users use third-party censorship circumvention tools to bypass the Tor censorship. However, those third-party censorship circumvention tools are actually widely used in heavily censored area where Tor bridges and pluggable-transports are not effective.
Therefore, it would be helpful to do more research on how we can design a better Tor Launcher to guide users configure the Tor to work with those third-party censorship circumvention tools.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
Two common way a censorship circumvention tools can work with Tor:
The censorship circumvention tools, for example a VPN, will handle all the traffic generated by Tor automatically.
The other case is that the censorship circumvention tools, for example Lantern, Psiphon3 or Shadowsocks, will open a HTTP/Sock port(s) as an interface, listening the traffic coming from Tor.
In the first case, users can simply click the "connect" button on the Tor Launcher and the censorship circumvention tool will help Tor bypass the Tor censorship. However, the current instruction ask users whether they would like to "make a direct connection to the Tor network". People who use a VPN may not think they are connecting to the Tor network "directly". So the instruction seems to be a little be misleading.
In the second case, users need to configure the proxy setting on Tor launcher to use the interface provided by the third-party censorship circumvention tools. In this case, things are a little bit complex. The current instruction asks users if their connections to the Tor network are censored. If so, they will be guided to use a Tor bridge or some pluggable-transports. However, in heavily censored area, those tools may not be very effective. Therefore, it would be better to provide some instruction for users in heavily censored area on how to configure Tor to use some third-party censorship circumvention tools.
I am not a big fan of making it look like we support some third party tools we have not audited. If there is an issue with Tor's circumvention capabilities we should fix that on the Tor side. Third party applications might be easily in the position to betray the very safeguards Tor is trying to provide.
I am not a big fan of making it look like we support some third party tools we have not audited. If there is an issue with Tor's circumvention capabilities we should fix that on the Tor side. Third party applications might be easily in the position to betray the very safeguards Tor is trying to provide.
I agree with these thoughts. Because I have not heard much discussion of use of 3rd party tools, this statement surprises me: "third-party censorship circumvention tools are actually widely used in heavily censored area where Tor bridges and pluggable-transports are not effective."
I am not a big fan of making it look like we support some third party tools we have not audited. If there is an issue with Tor's circumvention capabilities we should fix that on the Tor side. Third party applications might be easily in the position to betray the very safeguards Tor is trying to provide.
I agree with you that using third party censorship circumvention tools may not be the best choice in terms of anonymity/usability/security when Tor bridges/pluggable-transports are effective.
However, sometimes Tor bridges/pluggable-transports may not be effective/available because:
an adversary is capable of filtering the connection to the Tor bridges and pluggable-transports.
the valid pluggable-transport, let's say meek for example, is not available in some downstream projects, like Tails/Whonix.
This is the case where we may need the 3rd party tools. Additionally, even if Tor bridges/pluggable-transports are effective and available for most of the time, we may still need 3rd party tools as a backup plan when a new censorship event occurs.
I do understand that we should not "make it look like we support (or encourage using) 3rd party tools", so maybe we can make a warning when that option is used? or maybe we should only provide a 3rd party tools configuration tutorial in assistant page? What do you think, gk?
Because I have not heard much discussion of use of 3rd party tools, this statement surprises me: "third-party censorship circumvention tools are actually widely used in heavily censored area where Tor bridges and pluggable-transports are not effective."
The diagram shows that there are only around 500 meek connections and only around 250 obfs4 connections per day from China on average. Considering the direct connection to the Tor network has been blocked for yeas in China, the sum of the two numbers should be seen as the total number of Tor users in China, which is approximately 750. Comparing with the number of Tor users in other countries, the user number is very likely underestimated. One possible explanation is that Tor is not popular in China at all. Another explanation is that many Tor users in China connect to the Tor network with the help of 3rd party censorship circumvention tools, whose connection will be recorded as countries other than China in Tor metric.
Additionally, what the diagram does not show is the connection quality when meek or obfs4 is used. We may ask questions like how stable the connections are? how much bandwidth a Tor user will get when using meek? If the stability or bandwidth are unbearable for users, it is possible for them to choose some 3rd party tools instead.
I am not a big fan of making it look like we support some third party tools we have not audited. If there is an issue with Tor's circumvention capabilities we should fix that on the Tor side. Third party applications might be easily in the position to betray the very safeguards Tor is trying to provide.
I have to agree with this. I think it's dangerous to do this.
Additionally, we want to keep the choices as simple as possible. Giving MORE options is not always helping the user. Rather, I would argue that it is a hindrance most of the time.
We are generally making it easier to user Tor launcher see here. The goal is to ask for consent, but then automatically connect to Tor, without having to do the work. We're also 1) reducing the amount of transports to choose from 2) not requiring people to go outside of the setup dialog to get custom bridges 3) being smarter about how we make connections.
I think the problem to solve is "make people connect easier," not "support more third party tools."