Add support for `snowflake`. The level of support it will have is comparable to what we do for `webtunnel` (see #20267): - default bridges that use snowflake are supported - user will need to type the snowflake bridge line themselves, just like how it is for obfs4 and webtunnel ## Context [Snowflake](https://snowflake.torproject.org/) has been part of the default bridges in Tor Browser since [July 2021](https://blog.torproject.org/snowflake-in-tor-browser-stable/). Since then it became the preferred way of connecting to Tor from [Iran](https://metrics.torproject.org/userstats-bridge-combined.html?country=ir) and [China](https://metrics.torproject.org/userstats-bridge-combined.html?country=cn). [Russia](https://metrics.torproject.org/userstats-bridge-combined.html?country=ru) still uses mostly obfs4 (not the case anymore as of 2025-05, see tails/tails#20267). As of 2024-07-23, the Circumvention Settings API, that Tor Browser uses for its "connect assist" feature, and that we should use for #15331+, returns Snowflake bridges for China, among other places: https://bridges.torproject.org/moat/circumvention/map Adding support for Snowflake is slightly higher priority than WebTunnel. However, note that Snowflake is known to be slow in China: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251 More data on how Snowflake is helping against censorship around the world: https://blog.torproject.org/snowflake-daily-operations/. ## User feedback - [\[Tails-dev\] obfs4 doesn't work in Iran](https://lists.autistici.org/message/20221229.171220.b1c356e6.en.html) - [\[Tails-dev\] Please update the Snowflake Bridge and default bridge](https://lists.autistici.org/message/20240508.005944.9b54fc1d.en.html) # Implementation See tails/tails!881. ## Backend * Lyrebird is going to get Snowflake support, better use that rather than the older `snowflake-client`? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/63 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/64 * a beginning of a prototype https://gitlab.tails.boum.org/tails/tails/-/issues/5494#note_191609 did this: * add Snowflake to our `ClientTransportPlugin` config * adjust the Tor Connection backend to allow entering a Snowflake bridge * `snowflake-client` needs to resolve a few domain names; is `config/chroot_local-includes/lib/systemd/system/tor@default.service.d/50-resolv-conf-override.conf` enough? * https://gitlab.tails.boum.org/tails/tails/-/issues/5494#note_240322 * allow the `debian-tor` user to do everything on UDP * either test Snowflake with Chutney in our automated test suite, or using the real Tor network, or add to manual QA; expected challenges are similar to WebTunnel, see details on #20267+, but meskio told us it's going to be much more complicated than WebTunnel: we'll need to run a snowflake broker, server, bridge and proxy, which is more complicated than a webserver * update the design doc * anything else? ## UI https://www.figma.com/board/RnTAzBfkWKbOwdZxvk5xer/Pluggable-transports - Automatic mode * How many PT do we want to try? - Bridge configuration screen * Introduce layering in the UI to accommodate for more options - Use an accordion pattern to unfold below each radio button? * Support different types of bridges when "Use a default bridge" - Only applies to "automatic + configure bridge" - Explain the different bridges to help people choose the PT that is most likely to work (in the accordion) * Adapt "obfs4" placeholder in textarea - Have a separate textarea for each type of bridge in an accordion? * Makes explicit which PT we support * Keeps solving #19169 - Error screen * Layer email and telegram with a popup window - Fixes https://gitlab.tails.boum.org/tails/tails/-/issues/20113+ We only help people choose the best PT when choosing a default bridge. I think it's fine because: - This matters most to anticensorship scenarios and people should use the "automatic mode" for that, instead of the "hiding mode". - In the "automatic mode" people can still use a default bridge and we explain the different PTs there. - For people who chose the "hiding mode", each bridge bot returns bridges in 1 type of bridge anyway. People are going to try whatever bridge bot is the easiest. Right now: * Email Bot returns obfs4 * Web Bot returns webtunnel * Telegram Bot returns obfs4 ## Website * Update the end-user doc # Fundraising https://gitlab.torproject.org/tpo/operations/proposals/-/issues/106 ## Related UX debt As part of the same grant, it would be great to also work on other related improvements: - Add Telegram Bot in bridge screen * Requires https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/243 - UX debt related to bridges or troubleshooting, for example: * https://gitlab.tails.boum.org/tails/tails/-/issues/20398+ * https://gitlab.tails.boum.org/tails/tails/-/issues/19336+ * https://gitlab.tails.boum.org/tails/tails/-/issues/18593+ * https://gitlab.tails.boum.org/tails/tails/-/issues/18570+ * https://gitlab.tails.boum.org/tails/tails/-/issues/18548+ * https://gitlab.tails.boum.org/tails/tails/-/issues/18482+