Skip to content

Add WebTunnel support for users-added bridges

Estimation

Use this spreadsheet to break down this feature into smaller tasks so we can better estimate the size of this work. Add the complexity, uncertainty levels and who will be responsible for the tasks.

Please take into account tany technical research that will be required, in case elements of this feature's implementation are currently unknown.

Job story

  • When the Tor network is blocked and other circumvention methods are not effective,
  • I want to add the WebTunnel bridge(s) I already use for Tor Browser to Tor VPN,
  • So Tor VPN will successfully connect to the Tor network.

Problem

Users in countries where Tor is blocked rely on bridges to connect to the Tor network. In countries like Russia and Mainland China, WebTunnel is currently the most practical option due to widespread enumeration of bridge lines and the blocking of other Pluggable Transports. As such, Russian and Chinese users are being distributed WebTunnel bridges manually by the User Support Team and automatically through Rdsys (for example, via Tor Browser's Connection Assist feature).

Subsequently, users from Russia and Mainland China are attempting to input their WebTunnel bridges into Tor VPN, however Tor VPN does not support WebTunnel at this point in time (see #323). This means that prior to the addition of bridge line validation in Beta 3, the "Add bridges" dialog would appear to accept these bridges – only to fail to connect to the network.

This is resulting in us receiving negative reviews from users based in Russia and mainland China on Google Play, and our other user support channels too.

Solution

We have recently shipped improvements to the "Add bridges" dialog that should mitigate this issue, including:

  1. Indicating which PTs are currently supported in the "Add bridges" dialog: #332 (closed)
  2. Deploying basic error handling for bridge lines: https://gitlab.torproject.org/tpo/applications/vpn/-/issues/313

In addition to the above, we should extend support for user-added bridges to include WebTunnel. This will involve:

  • Adding an additional chip to the user interface after obfs4 and Snowflake that reads WebTunnel.
  • Extending bridge line parsing in onionmasq so that both onionmask and the UI recognize WebTunnel parameters correctly.
  • Ensuring that iptproxy starts correctly with WebTunnel parameters.

As part of this scope of work, we will not be exploring:

  • Adding WebTunnel as a built-in bridge option at this time.
  • Extending the level of integration of Tor VPN's bridge bot with the circumvention API (e.g. through deeper integration with the API's country settings)

We may implement one or both of these features in the future, however this will require a greater level of planning, and will likely be part of a future funded project for Tor VPN.

Value

  1. Users in countries experiencing extreme internet censorship (where both the Tor network and many of our existing circumvention options are currently blocked, such as Russia and Mainland China) will be able to connect to the network, test Tor VPN, and participate to the Beta program.
  2. Tor VPN will gradually gain a reputation as a working circumvention tool in these countries, and the volume of negative reviews and user support requests mentioning WebTunnel should decrease.
  3. Through their participation, we will expand our feedback pool to users experiencing extreme censorship – which more closely aligns to Tor VPN's intended audience.

Acceptance criteria

  • Correctly formatted WebTunnel bridges pass error handing in the "Add bridges" dialog.
  • Tor VPN connects to the Tor network via the specified WebTunnel bridge when the following conditions are met:
    • One or more WebTunnel bridges have been added in the "Add bridges" dialog.
    • "Your bridges" is set to "Manual selection"
    • "Use a bridge" is toggled on.
  • WebTunnel is listed as a supported PT in the "Add bridges" modal.
Edited by donuts