I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
Hi David,
I'm able to use snowflake on the command line, but not in Tor Browser. This seems to be due to this bug: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282
I'm a bit surprised that it took so long for the issue to be reflected in snowflake statistics, I also hadn't run across it myself until I tried to change my Tor Browser config after reading this email. Philipp and I are talking with the browser and core tor developers about a fix. I'm a little surprised we are only finding out about this now. But, it seems to not be an issue with Snowflake itself.
Cecylia
On 2021-01-18 11:30 p.m., David Fifield wrote:
I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
I'm still pretty sure that the complete drop off of snowflake users has to do with Tor Browser crashing when configured to use the default snowflake bridge.
But, I did notice some other weird behaviour. The number of unrestricted snowflake proxies dropped off at around the same time (and the number of unknown proxies rose dramatically). This should not affect most users (I have been able to bootstrap Tor fully using snowflake with the same torrc configurations options that Tor Browser uses). However, it is weird. I'm not sure yet of the cause, and it could be a coincidence that these two events coincided.
See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
On 2021-01-19 12:59 p.m., Cecylia Bocovich wrote:
Hi David,
I'm able to use snowflake on the command line, but not in Tor Browser. This seems to be due to this bug: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282
I'm a bit surprised that it took so long for the issue to be reflected in snowflake statistics, I also hadn't run across it myself until I tried to change my Tor Browser config after reading this email. Philipp and I are talking with the browser and core tor developers about a fix. I'm a little surprised we are only finding out about this now. But, it seems to not be an issue with Snowflake itself.
Cecylia
On 2021-01-18 11:30 p.m., David Fifield wrote:
I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
Not to be overly paranoid, but if a bunch of thought to be OK proxies disappear and a bunch of mystery proxies pop up around the same time, my first thought would be an attempt to insert a bunch of malicious machines in the middle.
— Sent from a small device with autoerror
On Jan 20, 2021, at 3:18 PM, Cecylia Bocovich cohosh@torproject.org wrote:
I'm still pretty sure that the complete drop off of snowflake users has to do with Tor Browser crashing when configured to use the default snowflake bridge.
But, I did notice some other weird behaviour. The number of unrestricted snowflake proxies dropped off at around the same time (and the number of unknown proxies rose dramatically). This should not affect most users (I have been able to bootstrap Tor fully using snowflake with the same torrc configurations options that Tor Browser uses). However, it is weird. I'm not sure yet of the cause, and it could be a coincidence that these two events coincided.
See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
On 2021-01-19 12:59 p.m., Cecylia Bocovich wrote: Hi David,
I'm able to use snowflake on the command line, but not in Tor Browser. This seems to be due to this bug: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282
I'm a bit surprised that it took so long for the issue to be reflected in snowflake statistics, I also hadn't run across it myself until I tried to change my Tor Browser config after reading this email. Philipp and I are talking with the browser and core tor developers about a fix. I'm a little surprised we are only finding out about this now. But, it seems to not be an issue with Snowflake itself.
Cecylia
On 2021-01-18 11:30 p.m., David Fifield wrote: I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
I find this unlikely. I should have been more clear in my wording. From what I can tell there wasn't a massive group of proxies disappearing or joining. The group of proxies is more or less the same. The only change is what type of NAT the proxies think they have.
Let me give a bit more background information. Each proxy performs a test once a day to determine what type of NAT they have (see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...). If the proxies fail to complete the check (i.e., the probe server is down), then they set their NAT type to "unknown". Given that the number of proxies with "unknown" types rose drastically, and the number of both unrestricted and restricted proxies fell, I'm guessing there is an issue with the probe server responsible for the NAT test. It might have been overloaded or ended up misconfigured.
Looking at the metrics, there doesn't seem to be a change in the geolocation of proxy IP addresses either.
Cecylia
On 2021-01-20 6:23 p.m., Eric Burger wrote:
Not to be overly paranoid, but if a bunch of thought to be OK proxies disappear and a bunch of mystery proxies pop up around the same time, my first thought would be an attempt to insert a bunch of malicious machines in the middle.
— Sent from a small device with autoerror
On Jan 20, 2021, at 3:18 PM, Cecylia Bocovich cohosh@torproject.org wrote:
I'm still pretty sure that the complete drop off of snowflake users has to do with Tor Browser crashing when configured to use the default snowflake bridge.
But, I did notice some other weird behaviour. The number of unrestricted snowflake proxies dropped off at around the same time (and the number of unknown proxies rose dramatically). This should not affect most users (I have been able to bootstrap Tor fully using snowflake with the same torrc configurations options that Tor Browser uses). However, it is weird. I'm not sure yet of the cause, and it could be a coincidence that these two events coincided.
See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
On 2021-01-19 12:59 p.m., Cecylia Bocovich wrote: Hi David,
I'm able to use snowflake on the command line, but not in Tor Browser. This seems to be due to this bug: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282
I'm a bit surprised that it took so long for the issue to be reflected in snowflake statistics, I also hadn't run across it myself until I tried to change my Tor Browser config after reading this email. Philipp and I are talking with the browser and core tor developers about a fix. I'm a little surprised we are only finding out about this now. But, it seems to not be an issue with Snowflake itself.
Cecylia
On 2021-01-18 11:30 p.m., David Fifield wrote: I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
Hi,
Which method do you recommend to keep execution ./proxy for the Snowflake on a server? Currently, I use screen to it.
Do you have plans to integrate with systemd in near future or something like that?
Thanks in advance, Jacobo
On Mon, Mar 15, 2021 at 05:00:19PM -0600, Jacobo Nájera wrote:
Which method do you recommend to keep execution ./proxy for the Snowflake on a server? Currently, I use screen to it.
We are doing it now with runit.
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guid...
The `timeout` commands there may not be necessary; they were put in there to deal with deadlocks that we experienced in the past. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
Hi
El 15/03/21 a las 17:05, David Fifield escribió:
On Mon, Mar 15, 2021 at 05:00:19PM -0600, Jacobo Nájera wrote:
Which method do you recommend to keep execution ./proxy for the Snowflake on a server? Currently, I use screen to it.
We are doing it now with runit.
I installed runit on Ubuntu and Debian via .deb packages it works well with Snowflake. But What do you recommend on Fedora? I am trying to extend fedora support on ansible role (https://github.com/nvjacobo/snowflake)
Thanks, Jacobo
On Mon, Jan 18, 2021 at 09:30:53PM -0700, David Fifield wrote:
I happened to look at the Snowflake bridge's bandwidth and user history page, and the counts are close to zero since yesterday. I haven't investigated it at all.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69...
The measured decrease in users occurred on 2021-01-17 and lasted 3–4 days. Since 2021-01-21 there has been a recovery almost to previous levels.
I had mentally attributed the drop to the tor bug that made default bridges not work in Tor Browser 10.5a7. https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282
But the timing doesn't line up. The measured decrease happened *before* the release of 10.5a7 on 2021-01-20. Tor Browser 10.5a8 was just released with a fix for tor-browser!40282, but the recovery in Snowflake user numbers happened before that. 10.5a7 2021-01-20 https://blog.torproject.org/new-release-tor-browser-105a7 10.5a8 2021-01-26 https://blog.torproject.org/new-release-tor-browser-105a8
At the team meeting today, cohosh suggested that the cause may not actually be tor-browser!40282, but rather an unexplained drop in the number of NAT-unrestricted proxies starting 2021-01-20: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-01-28-15.58.log....
16:03:24 <dcf1> I'm planning to start an email thread but I'll just mention here, Snowflake user numbers recovered even before the 10.5a8 release 16:03:31 <dcf1> https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB69... 16:03:45 <cohosh> dcf1: yeah i noticed that too 16:04:03 <cohosh> i wonder if it had something to do with the weird broker metrics we were getting 16:04:04 <dcf1> so I don't know if people found their own workarounds, or if the majority of our users are not Tor Browser users, or what 16:04:23 <cohosh> whereall of our proxies suddenly didn't know what kind of NAT they had 16:05:34 <dcf1> that might be a better explanation, since the non-working 10.5a7 was released 2021-01-20 and the decrease in users happened *before* that 16:06:14 <cohosh> i rolled out a fix that should prevent that from happening again 16:06:56 <cohosh> but it's weird that it dropped to zero 16:07:05 <cohosh> the number of clients i mean
anti-censorship-team@lists.torproject.org