Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2022-09-27T18:43:09Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40066O1.1: Prepare Snowflake to handle a surge of operators and users.2022-09-27T18:43:09ZGabagaba@torproject.orgO1.1: Prepare Snowflake to handle a surge of operators and users.Although we already deployed Snowflake in Tor Browser, we want to be sure that Snowflake can handle all new users from China by preparing it with:
- [x] add many additional Snowflake operators (coordinate with @ggus on campaign),
- [ ]...Although we already deployed Snowflake in Tor Browser, we want to be sure that Snowflake can handle all new users from China by preparing it with:
- [x] add many additional Snowflake operators (coordinate with @ggus on campaign),
- [ ] monitor bottlenecks & blocking events (ongoing task for @tpo/anti-censorship),
- [x] set up at least one more snowflake bridge (1. prepare snowflake to give more than 2 bridge, 2. coordinate with @ggus for when partnering to have more bridges)
- [ ] respond to blocking events and prevent users from getting Snowflakes that have been blocked (ongoing task for @tpo/anti-censorship).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/snowflake/-/issues/40062Snowflake should self-diagnose where it fails in the connection process, and ...2022-04-08T10:56:52ZRoger DingledineSnowflake should self-diagnose where it fails in the connection process, and inform TorWe have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps succe...We have periodic reports (e.g. #40044) of people in China saying that Tor Browser + Snowflake gets to 10% bootstrapped and can't get past it. We got another one on irc just now. Our own internal tests show that Snowflake bootstraps successfully on the VPS we're trying it from, but clearly that's not the end of the story. For example, I bet the mobile carriers have different constraints.
I was first thinking to suggest some standalone Snowflake debugging tool that would try a bunch of things and see how they go and summarize it for the user.
But then I realized: Snowflake itself should do this, because it *does* try things, and it learns how they go, and our users already have it. So all that remains is (a) figuring out which conclusions are worth escalating to the user, possibly including some refactoring inside Snowflake to do the steps in a way where we're confident in our results, and then (b) deciding what the right pathway is for escalating the information.
For 'b', we should be careful to avoid getting bogged down picking between options, since there are plenty of approaches that will do adequately. Maybe the PT log command is useful here, and (if I understand it correctly) in that case the way users can see the output is by preferences->tor->view logs.
And then I imagine the bulk of the work will be in step 'a'.
To get us started: what is the taxonomy of ways that Snowflake can fail to make its connection? And for each of those ways, is there an obvious point where Snowflake can self-assess that it has failed?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/snowflake/-/issues/40059Change how Snowflake handles client arguments2022-03-02T15:29:57ZCecylia BocovichChange how Snowflake handles client arguments@richard just pointed out on IRC that the way Snowflake's client-side arguments are passed to the executable make them difficult to dynamically change through Tor Browser's preferences. For Snowflake, these are specified through the `Cli...@richard just pointed out on IRC that the way Snowflake's client-side arguments are passed to the executable make them difficult to dynamically change through Tor Browser's preferences. For Snowflake, these are specified through the `ClientTransportPlugin` torrc option in the [`torrc-defaults`](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/5e61e15a2b71412538b3be5e9b62180f4d2686ce/projects/tor-browser/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix) file:
```
## obfs4proxy configuration
ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec ./TorBrowser/Tor/PluggableTransports/obfs4proxy
## snowflake configuration
ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports/snowflake-client -url https://snowflake-broker.torproject.net.global.prod.fastly.net/ -front cdn.sstatic.net -ice stun:stun.l.google.com:19302,stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
```
Bridge lines, on the other hand, are specified in a seperate torrc file. See the [built-in preferences](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/5e61e15a2b71412538b3be5e9b62180f4d2686ce/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js) for obfs4 and snowflake bridges.
Right now the only way to make changes to Snowflake client-side options (which have a huge impact on censorship) is to ship a new verison of Tor Browser or tell users to manually modify their torrc files.
@dcf also mentioned in !50 that we need to reconsider command-line options for Snowflake with the addition of new rendezvous methods. This is a related concern and we should make sure that how we chose to move forward works well with this scenario.
One option would be to instead specify command-line arguments through the pluggable transport specification PT args (as obfs4 does with the `cert` and `iat-mode` arguments). I haven't tried this, so I'm not sure it would work if two different bridge lines have the same fingerprint, but I believe it would allow us to specify multiple Snowflake configurations as separate bridges:
```
Bridge snowflake 192.0.2.3:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.l.google.com:19302
Bridge snowflake 192.0.2.3:2 2B280B23E1107BB62ABFC40DDCC8824814F80A72 ampcache=https://cdn.ampproject.org/ ice=stun:stun.l.google.com:19302
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40056O1.2: Increase the number of Snowflake proxies.2022-07-05T18:08:28ZGabagaba@torproject.orgO1.2: Increase the number of Snowflake proxies.With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thou...With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thousands.
- O1.2.1: Run a public campaign to encourage Internet users to install the Snowflake extension in Firefox or Chrome and use their web browser to act as bridges for censored people. This campaign will target individuals who care about free access to information but who may have limited capacity to operate a traditional bridge.
- O1.2.2: Scale Tor reachability through mobile Snowflakes. It’s also possible to build the Snowflake into mobile applications. We can rapidly increase the availability and diversity of bridge IP addresses that are not blocked in China by asking the millions of active Orbot users to “help censored users connect to Tor.” Through the Internews DISRUPT program, Guardian Project is designing and implementing “Orbot as Bridge” capability with the use of Snowflake, and as a result of this Activity, any Orbot user will be able to become a Snowflake bridge to Tor when they are not actively using their device. Guardian Project is also implementing as much of this capability as possible in Onion Browser for iOS.1 To do so, Guardian Project will: continue to improve Tor+Snowflake stability & performance on mobile devices and tune mobile-as-Snowflake bridge usability and performance, especially considering connections from the target regions.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2022-12-31https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40055Standalone proxy reconnects in a tight loop when server refuses connection2022-10-11T19:44:19ZDavid Fifielddcf@torproject.orgStandalone proxy reconnects in a tight loop when server refuses connectionRun the proxy and let it connect to a broker port that refuses connections. After the probetest (about 30 s), it starts trying to poll the broker in a tight loop. We should probably wait at least `pollInterval` between connection attempt...Run the proxy and let it connect to a broker port that refuses connections. After the probetest (about 30 s), it starts trying to poll the broker in a tight loop. We should probably wait at least `pollInterval` between connection attempts in case of error.
```
snowflake/proxy$ ./proxy -broker http://localhost:9999/ 2>&1 | head -n 50
2021/07/19 18:00:04 starting
2021/07/19 18:00:04 WebRTC: Created offer
2021/07/19 18:00:04 WebRTC: Set local description
2021/07/19 18:00:04 Offer: {...}
2021/07/19 18:00:35 error polling probe: http2: timeout awaiting response headers
2021/07/19 18:00:35 NAT type: unknown
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
2021/07/19 18:00:35 Error reading broker response: unexpected end of JSON input
2021/07/19 18:00:35 body:
2021/07/19 18:00:35 bad offer from broker
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
2021/07/19 18:00:35 Error reading broker response: unexpected end of JSON input
2021/07/19 18:00:35 body:
2021/07/19 18:00:35 bad offer from broker
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
...
```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/anti-censorship/pluggable-transports/snowflake/-/issues/40015Investigate high retransmission rate of Snowflake2022-03-01T19:17:35ZCecylia BocovichInvestigate high retransmission rate of SnowflakeThe recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a ...The recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a bug. It could also apply to the rest of the connection after the handshake. We should look into this.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/snowflake/-/issues/40014Make Snowflake's DTLS fingerprint more similar to popular WebRTC implementations2024-01-12T17:12:10ZCecylia BocovichMake Snowflake's DTLS fingerprint more similar to popular WebRTC implementationsSome recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush chang...Some recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush changes to the fingerprint without a more complete comparison to more WebRTC implementations popular in censored regions. But, we can get a start on figuring out how to change the fingerprint in pion and see whether we will need to submit upstream patches to provide us with this kind of agility. Something like uTLS would be great for us in the long run.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibettheodorsmtheodorsmhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34075Implement metrics to measure snowflake churn2023-07-18T18:57:33ZCecylia BocovichImplement metrics to measure snowflake churnAs discussed in the meeting this week, it would be useful to know how often snowflake proxy IP addresses actually change. We collect counts of unique IPs on any given day, but not how much variance we get in IP addresses over time.
This...As discussed in the meeting this week, it would be useful to know how often snowflake proxy IP addresses actually change. We collect counts of unique IPs on any given day, but not how much variance we get in IP addresses over time.
This relates to our ability to resist censorship, as snowflake relies in part on the claim that snowflakes are ephemeral, changing, and difficult to block exhaustively.
Let's implement some metrics to see how much snowflake IPs change.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/snowflake/-/issues/31085Make an Android extension or app for people to be a snowflake (AMO or proxy-go)2023-07-13T14:59:01ZcypherpunksMake an Android extension or app for people to be a snowflake (AMO or proxy-go)https://addons.mozilla.org/en-US/android/https://addons.mozilla.org/en-US/android/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/snowflake/-/issues/29863Add disk space monitoring for snowflake infrastructure2023-07-31T02:23:24ZCecylia BocovichAdd disk space monitoring for snowflake infrastructureWe've run out of disk space at both the snowflake bridge (legacy/trac#26661, legacy/trac#28390) and the broker (legacy/trac#29861), which has caused snowflake to stop working. We've set up rotating and compressed logs but it would be nic...We've run out of disk space at both the snowflake bridge (legacy/trac#26661, legacy/trac#28390) and the broker (legacy/trac#29861), which has caused snowflake to stop working. We've set up rotating and compressed logs but it would be nice to have some disk space monitoring to alert us if/when this happens again
Also, as discussed on IRC, we should eventually move the broker to a TPA machine.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/snowflake/-/issues/28651Prepare all pieces of the snowflake pipeline for a second snowflake bridge2023-05-15T19:25:40ZRoger DingledinePrepare all pieces of the snowflake pipeline for a second snowflake bridgeRight now there is one snowflake bridge, and its fingerprint is hard-coded in tor browser.
Eventually we will have enough load, and/or want more resiliency, that we want to set up a second snowflake bridge.
To be able to do that, I thi...Right now there is one snowflake bridge, and its fingerprint is hard-coded in tor browser.
Eventually we will have enough load, and/or want more resiliency, that we want to set up a second snowflake bridge.
To be able to do that, I think we need changes at the client, changes at the snowflake, and changes at the broker.
[Edit 2022-03: the three items I list next are no longer quite the best way to do this ticket. See the extensive and ongoing discussions below for what we currently think is the best plan.]
(A) At the snowflake side, the snowflake needs to tell the broker which bridge(s) it is willing to send traffic to. Additionally, we either want to declare that each snowflake sends to only one bridge, or we need to add a way for the client to tell the snowflake which bridge it wants to reach.
(B) At the broker side, we need it to be able to learn from snowflakes which bridge(s) they use, and we need it to be able to learn from clients which bridge they want to use, and we need it to match clients with snowflakes that will reach that bridge.
(C) At the client side, we need it to tell the broker which bridge it wants to use, and (depending on our design choice in A above) we might also need the client to be able to tell the snowflake which bridge it wants to use.
(There is an alternative approach, where we assume that every snowflake is always running the newest javascript, so it is willing to reach every bridge on our master list. Then the broker doesn't need to do anything new, and we just need to add a way for the client to tell the snowflake which bridge it wants. I don't have a good handle on how realistic this assumption is.)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/snowflake/-/issues/25598Let the broker inform proxies how often to poll2022-07-25T17:59:44ZDavid Fifielddcf@torproject.orgLet the broker inform proxies how often to pollCurrently, proxies poll the broker at a static rate of once every 5–10 seconds. If we're anticipating thousands of proxies, we don't need them to poll so frequently.
The broker could instead tell each proxy how long to wait before polli...Currently, proxies poll the broker at a static rate of once every 5–10 seconds. If we're anticipating thousands of proxies, we don't need them to poll so frequently.
The broker could instead tell each proxy how long to wait before polling again. The broker could even dynamically adjust the rate based on an estimate of supply and demand.
One way to do this would be a custom header in responses to `/proxy` requests:
```
Snowflake-Next-Poll: Thu, 22 Mar 2018 18:05:47 GMT
```
Or using a relative time offset:
```
Snowflake-Next-Poll: 600
```
There was a similar idea for flash proxy.
legacy/trac#8171::
The facilitator included a fixed `check-back-in=600` in its responses.
legacy/trac#8172::
Adjust polling interval dynamically (never implemented).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/snowflake/-/issues/19409Make a deb of snowflake (proxy and client) and get into Debian2022-03-05T21:42:54ZadrelanosMake a deb of snowflake (proxy and client) and get into Debianaka
`apt-get install snowflake`
Speaking for Whonix, this would be very useful. Perhaps for Tails as well, but I am not speaking for them.
(Similar to legacy/trac#13160.)aka
`apt-get install snowflake`
Speaking for Whonix, this would be very useful. Perhaps for Tails as well, but I am not speaking for them.
(Similar to legacy/trac#13160.)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/anti-censorship/pluggable-transports/snowflake/-/issues/40354Extract reusable parts to a shared library2024-03-26T10:41:06Zmeskiomeskio@torproject.orgExtract reusable parts to a shared library[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other p...[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other projects like rdsys.
Another useful piece for other projects is [safelog](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/common/safelog?ref_type=heads) that is already being imported by bridgestrap and conjure. Maybe we want to be able to import it without snowflake.
We could bundle both into a single library as this might make it easier to add other pieces in the future and each extra library makes it harder to package software to distros.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40353Rename Container Image Tag for containers built from main branch to nightly2024-03-25T15:21:37ZshelikhooRename Container Image Tag for containers built from main branch to nightlyThe current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly...The current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly` as [discussed](https://lists.torproject.org/pipermail/tor-project/2024-March/003787.html) in the during the weekly meeting.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40352Use unreliable and unordered WebRTC data channels2024-03-21T20:15:25ZDavid Fifielddcf@torproject.orgUse unreliable and unordered WebRTC data channels@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I ...@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I think it would make sense to also consider make protocol level change on how kcp is interacting with webrtc before considering to add forward error correction. This would be in the form of enabling unreliable mode of webrtc and make necessary change to get it to work.
Right now, kcp packets are sent in webrtc data channel in a reliable way that deliver all packets in order and retransmit any lost message repeatedly. However, kcp also retransmit its packet itself, which as a result, queue all those retransmitted packets somewhere, like in webrtc's buffer.
This means lost packets are required to be retransmitted more than once in different protocol, and retransmit & timeout get compounded. More retransmit result in more lost packets and more retransmission, which eventually lead to [connection melt down](https://openvpn.net/faq/what-is-tcp-meltdown/) <- please read.
back pressure like the one introduced in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/144 only move the problem, and block kcp's send in unexpected way, as kcp don't expect send to block as it is usually over udp.
See also: https://lists.torproject.org/pipermail/anti-censorship-team/2023-March/000286.html
(@dcf split this issue off from #40251 to separate the analysis of speed in China from the proposed remedy.)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40351broker is not publishing metrics to collector2024-03-21T15:06:48Zmeskiomeskio@torproject.orgbroker is not publishing metrics to collectorYesterday (2024-03-20) the snowflake broker didn't publish any metrics for collector. I have checked /home/snowflake-broker/metrics.log in the broker server and the last published metric is:
```
snowflake-stats-end 2024-03-19 23:21:24 (8...Yesterday (2024-03-20) the snowflake broker didn't publish any metrics for collector. I have checked /home/snowflake-broker/metrics.log in the broker server and the last published metric is:
```
snowflake-stats-end 2024-03-19 23:21:24 (86400 s)
```
Looking at grafana everything seems to be working normally.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349Upgrade snowflake broker machine from Debian 102024-03-19T16:23:25ZCecylia BocovichUpgrade snowflake broker machine from Debian 10Looks like Debian 10 will not be supported by the LTS team after this June: https://wiki.debian.org/LTSLooks like Debian 10 will not be supported by the LTS team after this June: https://wiki.debian.org/LTShttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40348Snowflake addon not found in firefox store2024-03-16T17:04:01ZSven GottwaldSnowflake addon not found in firefox storeI followed the link on [Browser Snowflake proxy](https://community.torproject.org/relay/setup/snowflake/browser/) that leads to https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/. The page says:
> **Oops! We can’t find...I followed the link on [Browser Snowflake proxy](https://community.torproject.org/relay/setup/snowflake/browser/) that leads to https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/. The page says:
> **Oops! We can’t find that page**
>
> If you’ve followed a link from another site for an extension or theme, that item is no longer available. This could be because:
> - The developer removed it. Developers commonly do this because they no longer support the extension or theme, or have replaced it.
> - Mozilla removed it. This can happen when issues are found during the review of the extension or theme, or the extension or theme has been abusing the terms and conditions for addons.mozilla.org. The developer has the opportunity to resolve the issues and make the add-on available again.
>
> Try visiting the page later, as the theme or extension may become available again. Alternatively, you may be able to find what you’re looking for in one of the available extensions or themes, or by asking for help on our community forums.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40347Deploy new SQS features and fixes2024-03-21T13:41:39ZCecylia BocovichDeploy new SQS features and fixesNow that we have country-specific metrics for client rendezvous methods (!258), and some client-side fixes (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/264, https://gitlab.torproject....Now that we have country-specific metrics for client rendezvous methods (!258), and some client-side fixes (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/264, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/264), we should make sure these changes are deployed. That involves:
- [X] releasing a new Snowflake version [v2.9.2](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/releases/v2.9.2)
- [x] deploying a new version of the broker
- [x] opening a tor-browser-build MR to update the client (https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/936)Cecylia BocovichCecylia Bocovich