Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-10-17T11:55:14Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40215Bad range port format2022-10-17T11:55:14ZVortBad range port formatsnowflake proxy built from latest commit (8b1970a3) produces such error after startup:
`Bad range port format: 0xc0001d40b0`
[Spotted](https://forum.torproject.net/t/standalone-proxy-traffic-relayed-almost-zero-with-restricted-nat-ty...snowflake proxy built from latest commit (8b1970a3) produces such error after startup:
`Bad range port format: 0xc0001d40b0`
[Spotted](https://forum.torproject.net/t/standalone-proxy-traffic-relayed-almost-zero-with-restricted-nat-type/5122/17?u=vort) by forum user mjacobs-de.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/20708Baidu Anti-TBB or TBB Trojanic upgrade2020-06-27T13:43:53ZTracBaidu Anti-TBB or TBB Trojanic upgradehi there i was running TBB 6.5a3 inside windows 8.1 and i have baidu anti-virus running inside it.
then i upgraded TBB to 6.5a4 , then this is what happened:-
baidu detected that there are viruses going to be downloaded by doing this...hi there i was running TBB 6.5a3 inside windows 8.1 and i have baidu anti-virus running inside it.
then i upgraded TBB to 6.5a4 , then this is what happened:-
baidu detected that there are viruses going to be downloaded by doing this upgraded so baidu blocked them. the weird thing that the upgrade continues and TBB worked !! even tho there r some parts of it has been deleted.
here is what Baidu thought that there r trojans:-
1- '''Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe
'''
2- **Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports\meek-client-torbrowser.exe**
3- **Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports\meek-client.exe**
4- **Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports\obfs4proxy.exe**
all of these categorized under one umbrella (reason behind deletion):-
**Trojan.Crypt.Heur.gen**
what is the dangerous things that i think i found in here :-
1- which one is correct regarding false security Baidu or TBB upgrade ?
2- TBB kept working and ignoring the reality that there r some parts of it have been removed !! , which mean any edit/modify/remove in TBB installed files/parts there will be no signals to know that. (unless its obvious like my case).
i think the best thing to do , is to have an enhancement to avoid TBB files corruption, like for e.g most anti-viruses have "'''
```
Self-Defense
```
https://blog.kaspersky.com/tip-of-the-week-what-is-antivirus-self-defense/3936/'''"
good thing this is happened in TBB alpha. any further Questions , help just ask. thnx
**Trac**:
**Username**: agentchaosGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/11BandwidthRate does not work in Docker2022-03-11T18:34:19ZhufhendrBandwidthRate does not work in DockerWithout limitation, tor is able to occupy the entire outgoing bandwidth. I followed the instructions and set the .env to:
```
OR_PORT=65535
PT_PORT=65534
[...]
OBFS4_ENABLE_ADDITIONAL_VARIABLES=1
# set limit to 5 Mbit/s
#OBFS4V_Bandwidth...Without limitation, tor is able to occupy the entire outgoing bandwidth. I followed the instructions and set the .env to:
```
OR_PORT=65535
PT_PORT=65534
[...]
OBFS4_ENABLE_ADDITIONAL_VARIABLES=1
# set limit to 5 Mbit/s
#OBFS4V_BandwidthRate="3750 KBytes"
#OBFS4V_BandwidthBurst="7500 KBytes"
OBFS4V_BandwidthRate="375000 bytes"
OBFS4V_BandwidthBurst="625000 bytes"
OBFS4V_AddressDisableIPv6=1
# OBFS4V_ExitNodes=1
```
It will transfer to the container correctly:
```
docker exec -it tor /bin/bash
debian-tor@97...6:/$ cat /etc/tor/torrc
RunAsDaemon 0
SocksPort 0
BridgeRelay 1
Nickname DockerObfs4Bridge
Log notice file /var/log/tor/log
Log notice stdout
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ExtORPort auto
DataDirectory /var/lib/tor
ORPort 65535
ServerTransportListenAddr obfs4 0.0.0.0:65534
[...]
# Additional properties from processed 'OBFS4V_' environment variables
BandwidthRate 375000 bytes
AddressDisableIPv6 1
BandwidthBurst 625000 bytes
```
However, the announced speed is 52.39 KiB/s (see attachment) and this corresponds to the really low traffic on my router.
Anyway, no matter how I change the numbers in the .env, nothing happens. If I don't set any, it ramps up too. ![Snímek_obrazovky_pořízený_2022-02-18_00-46-35](/uploads/5db38891cac3fdc80ea1a4f21fce07a0/Snímek_obrazovky_pořízený_2022-02-18_00-46-35.png)https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/3Be more efficient when testing bridges2020-11-12T21:53:45ZPhilipp Winterphw@torproject.orgBe more efficient when testing bridgesThere's room to make bridgestrap more efficient when it tests bridge lines. Roger helpfully suggested the following:
* Reuse Tor's data directory. (Bridgestrap currently deletes it after a test).
* Consider running a single Tor client an...There's room to make bridgestrap more efficient when it tests bridge lines. Roger helpfully suggested the following:
* Reuse Tor's data directory. (Bridgestrap currently deletes it after a test).
* Consider running a single Tor client and use `SETCONF` to test different bridges.
* If we can fetch the bridge's descriptor, we know that 1) we can establish a handshake and 2) the bridge knows its address. If we do a full bootstrap instead, we also learn if the bridge can properly fetch and serve directory information too.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12773Be more flexible when deciding if we should render RTL2020-06-27T13:43:09ZcypherpunksBe more flexible when deciding if we should render RTLCurrently we only render RTL if the language exactly matches one of: 'ar', 'he', 'fa', 'gu_IN', 'ku'.
We should prefer to render RTL for the language, no matter which country/region is specified. Splitting on the '_' and making out deci...Currently we only render RTL if the language exactly matches one of: 'ar', 'he', 'fa', 'gu_IN', 'ku'.
We should prefer to render RTL for the language, no matter which country/region is specified. Splitting on the '_' and making out decision based on the first two characters should suffice, i think (or simply always comparing [:2] may work just as well.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/30Best practices for update webtunnel in production2024-02-23T14:58:41ZJacobo NájeraBest practices for update webtunnel in productionHi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webt...Hi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webtunnel image is unchanged. But there is a new version of Tor. But it maintains Tor 0.4.7.13 version.
I also tried with it, but it doesn't work to update Tor version:
- docker compose down --volumes
- docker compose pull
- docker compose build
- docker compose up -d
Thanks, Jacoboshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/4Better gamify the UX for snowflake extension2022-09-28T05:35:34ZCecylia BocovichBetter gamify the UX for snowflake extensionHow do we make sure that users don't uninstall the extension if it seems like it isn't being used?
Sometimes usage is low due to bugs but other times it could be due to very few clients using the system. Is there a way to reassure peopl...How do we make sure that users don't uninstall the extension if it seems like it isn't being used?
Sometimes usage is low due to bugs but other times it could be due to very few clients using the system. Is there a way to reassure people that the extension is still working or will be useful in the future?
Related comments:
- https://trac.torproject.org/projects/tor/ticket/31100#comment:6https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31109Better gamify the UX for snowflake extension2020-06-30T16:00:09ZCecylia BocovichBetter gamify the UX for snowflake extensionHow do we make sure that users don't uninstall the extension if it seems like it isn't being used?
Sometimes usage is low due to bugs but other times it could be due to very few clients using the system. Is there a way to reassure peopl...How do we make sure that users don't uninstall the extension if it seems like it isn't being used?
Sometimes usage is low due to bugs but other times it could be due to very few clients using the system. Is there a way to reassure people that the extension is still working or will be useful in the future?
Related comments:
- https://trac.torproject.org/projects/tor/ticket/31100#comment:6https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/17Better handling of rejected connections at bridge2022-11-28T19:31:30ZCecylia BocovichBetter handling of rejected connections at bridgeSince the Conjure PT bridge is just a generic haproxy server, we have an allowlist to only allow traffic from known Conjure stations. Commit https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/commit/e0cc5a96...Since the Conjure PT bridge is just a generic haproxy server, we have an allowlist to only allow traffic from known Conjure stations. Commit https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/commit/e0cc5a9660848b7e5756cdd80561fc05e3b5838a fixed this feature, but we still seem to be opening OR connections for connections that are rejected by the allowlist policy.
To conserve resources, perhaps we can check to see if the connection has been closed first, and improve logging.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/58Better Invitation Encoding2024-03-01T11:43:41ZonyinyangBetter Invitation EncodingThe Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114...The Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114,93,58,10,118,162,141,183,53,200,168,179,108,34,222,21,15,252,195,121,92,185,187,78,126,17,67,153,113,32,87,109,232,90,104,27,162,141,83,26,121,195,47,249,109,50,104,220,136,183,111,7,8,93,53,3,12}
```
This is probably not ideal for a user to paste into the browser, though maybe it is fine?
We should check with the ux team to see if they have suggestions for a better user experience and consider changing this (and the interface) to accept a more user-friendly invite.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12215better project tree structure for obfs-flash/fog2020-06-27T13:43:58ZXimin Luobetter project tree structure for obfs-flash/fogThe project tree structure is quite disorganised atm. Now is probably a good time to turn it into modules, before we write too much more code.
See obfsproxy[1] and pyptlib[2] for an example of how to structure a python project.
See webs...The project tree structure is quite disorganised atm. Now is probably a good time to turn it into modules, before we write too much more code.
See obfsproxy[1] and pyptlib[2] for an example of how to structure a python project.
See websocket[3] and goptlib[4] for an example of how to structure a go project.
[1] https://gitweb.torproject.org/pluggable-transports/obfsproxy.git
[2] https://gitweb.torproject.org/pluggable-transports/pyptlib.git
[3] https://gitweb.torproject.org/pluggable-transports/websocket.git
[4] https://gitweb.torproject.org/pluggable-transports/goptlib.githttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/4Better templating system2022-01-27T20:15:33ZKezBetter templating systemThe current templating system from !1 isn't the best. I wrote it without a solid grasp on go's scoping, so it unnecessarily loads templates from disk on every request and passes around closures to keep scope. The rendered lektor template...The current templating system from !1 isn't the best. I wrote it without a solid grasp on go's scoping, so it unnecessarily loads templates from disk on every request and passes around closures to keep scope. The rendered lektor templates also use printf-formatting which works fine for the templates as they are now, but it's pretty fragile.
A big issue with the old system was that any error in the handler functions would call `SendError`. `SendError` couldn't be use a template, because the error might actually be related to loading templates. Loading the templates at startup eliminates that issue, so now `SendError` can use a proper template instead of sending the error string wrapped in `<h1>` tags.
I'm currently rewriting the templating with html/template syntax, and I've reworked the code to only load the templates from disk once, into a global map so closures aren't needed (it looks a lot nicer too!)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29208Better timeout and retry for Snowflake2020-06-27T13:40:33ZCecylia BocovichBetter timeout and retry for SnowflakeRight now clients can't figure out why their connection has stopped, figure out how to try another snowflake more quicklyRight now clients can't figure out why their connection has stopped, figure out how to try another snowflake more quicklyhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/20785Block of some direct users in Saudi Arabia, 2016-11-202020-06-27T13:43:41ZDavid Fifielddcf@torproject.orgBlock of some direct users in Saudi Arabia, 2016-11-20On 2016-11-20, the number of direct users dropped from about 8000 to about 5500. There was a simultaneous increase in bridge users (mostly obfs4) from about 500 to over 1200.
One month later, on 2016-12-22, the number of bridge users dr...On 2016-11-20, the number of direct users dropped from about 8000 to about 5500. There was a simultaneous increase in bridge users (mostly obfs4) from about 500 to over 1200.
One month later, on 2016-12-22, the number of bridge users dropped again, almost back to where it was before.
![userstats-relay-country-sa-2016-08-28-2017-06-01-off.png](uploads/userstats-relay-country-sa-2016-08-28-2017-06-01-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-08-28&end=2017-06-01&country=sa&events=off)
![userstats-bridge-country-sa-2016-08-28-2017-06-01.png](uploads/userstats-bridge-country-sa-2016-08-28-2017-06-01.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-08-28&end=2017-06-01&country=sa)
![userstats-bridge-combined-sa-2016-08-28-2017-06-01.png](uploads/userstats-bridge-combined-sa-2016-08-28-2017-06-01.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2017-06-01&end=2016-11-26&country=sa)https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/54Blocked spare or undistributed bridges2024-02-27T11:28:28ZonyinyangBlocked spare or undistributed bridgesWhen written, Lox did not consider that spare/undistributed bridges may become blocked.
In Lox's threat model, if bridges aren't distributed, this shouldn't happen. However, since rdsys is the source of truth for whether or not bridges a...When written, Lox did not consider that spare/undistributed bridges may become blocked.
In Lox's threat model, if bridges aren't distributed, this shouldn't happen. However, since rdsys is the source of truth for whether or not bridges are blocked, it's theoretically possible that a spare or undistributed bridge may be marked as blocked in a certain region in rdsys, despite that bridge not having been distributed.
In reality though, _might_ a bridge actually be marked as blocked if it hasn't been distributed (i.e., if it only exists in a spare bucket)?
One way I'm imagining this _could_ happen is if a particular block of bridges that have a common feature are blocked. We may assume, or test these bridges for reachability, and determine that they are blocked, regardless of whether or not they have been distributed. However, I think in most situations like this we would not consider these bridges as being blocked as a result of a censor blocking a bridge they learned about through Lox. In this case, we could just call these bridges `not-working` and replace them with `working` bridges rather than marking them as blocked and allowing migrations to new buckets.
If there are additional instances where bridges that are not distributed are marked as blocked though, these bridges should be handled differently. There's no point in having marked a spare bridge as blocked since it hasn't been distributed, so it should just be removed. The Lox authority currently does not include this logic, but could if necessary. Probably Lox will have to be deployed for sometime before we can definitively say whether or not there is any reason to consider this problem.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115Blocking of cdn.sstatic.net by SNI in Iran, 2023-01-16 to 2023-01-24 and spor...2023-05-25T15:19:56ZDavid Fifielddcf@torproject.orgBlocking of cdn.sstatic.net by SNI in Iran, 2023-01-16 to 2023-01-24 and sporadically thereafterIt looks like the domain cdn.sstatic.net is blocked by SNI filtering in some ISPs in Iran since 2023-01-16.
This is affecting Snowflake user numbers because that domain is used for one of the two supported rendezvous methods
(the only su...It looks like the domain cdn.sstatic.net is blocked by SNI filtering in some ISPs in Iran since 2023-01-16.
This is affecting Snowflake user numbers because that domain is used for one of the two supported rendezvous methods
(the only supported default in Tor Browser; one of two supported defaults in Orbot).
A mitigation is to use AMP cache rendezvous, which is a menu option in Orbot but which
requires [manually entering a bridge address](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2870903)
in desktop Tor Browser.
Related links:
* [In case Snowflake rendezvous gets blocked](https://ntc.party/t/in-case-snowflake-rendezvous-gets-blocked/1857)
* [Iran: Circumventing Censorship with Tor](https://forum.torproject.net/t/iran-circumventing-censorship-with-tor/4590#use-orbot-tor-vpn-26)
The OONI chart showing anomalies since 2023-01-16:
https://explorer.ooni.org/chart/mat?probe_cc=IR&test_name=web_connectivity&domain=cdn.sstatic.net&since=2023-01-06&until=2023-01-20&axis_x=measurement_start_day
![Iran, Web connectivity test, cdn.sstatic.net](/uploads/59bc189c99092df9cecbf4074d0681a6/ooni-mat-cdn.sstatic.net-ir-20230106-20230119.png)
Some specific Web Connectivity measurements:
|date|AS|result|
|---|--:|---|
|[2023-01-17 06:35:02](https://explorer.ooni.org/measurement/20230117T063503Z_webconnectivity_IR_206065_n1_IJS8oihggpINfmvo?input=https%3A%2F%2Fcdn.sstatic.net%2FImg%2Fhome%2Fopen-source.svg)|AS206065|timeout after tls_handshake_start|
|[2023-01-17 08:15:28](https://explorer.ooni.org/measurement/20230117T081528Z_webconnectivity_IR_50810_n1_beTnkn3kw9glaFDp?input=https%3A%2F%2Fcdn.sstatic.net%2FImg%2Fhome%2Fopen-source.svg)|AS50810|timeout after tls_handshake_start|
|[2023-01-17 19:18:12](https://explorer.ooni.org/measurement/20230117T191810Z_webconnectivity_IR_16322_n1_5hiFUmFKegcIEaGs?input=https%3A%2F%2Fcdn.sstatic.net%2FImg%2Fhome%2Fopen-source.svg)|AS16322|ok|
|[2023-01-17 21:47:01](https://explorer.ooni.org/measurement/20230117T214701Z_webconnectivity_IR_31549_n1_CzoWHAgGRJ9nRpdu?input=https%3A%2F%2Fcdn.sstatic.net%2FImg%2Fhome%2Fopen-source.svg)|AS31549|ok|
The effect on the top 6 Snowflake countries, showing a change only in IR and US.
(Recall that we suspect that many of the [nominally US users are actually in IR](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40207#note_2844116), due to geolocation errors.)
![Snowflake users by country, January 2023](/uploads/a02bf1d39dffc5278a2727450ba1d797/snowflake-country.png)
<details>
<summary>Graph source code</summary>
```r
library("tidyverse")
PALETTE <- c(
"ir" = "#239f40",
"us" = "goldenrod",
"??" = "#bbbbbb",
"ru" = "#0039a6",
"cn" = "#de2910",
"de" = "#de00de"
)
x <- read_csv("userstats-bridge-combined.csv") %>%
filter(transport == "snowflake") %>%
filter(country %in% names(PALETTE)) %>%
mutate(country = factor(country, levels = names(PALETTE)))
p <- ggplot(x) +
geom_ribbon(aes(x = date, ymin = low, ymax = high, fill = country)) +
geom_line(aes(x = date, y = low, color = country), size = 0.5) +
geom_line(aes(x = date, y = high, color = country), size = 0.5) +
geom_text(aes(x = date, y = low, label = country), size = 2) +
scale_color_manual(breaks = names(PALETTE), values = PALETTE) +
scale_fill_manual(breaks = names(PALETTE), values = PALETTE) +
coord_cartesian(xlim = as.Date(c("2023-01-06", "2023-01-18")), expand = FALSE) +
guides(color = guide_legend(override.aes = list(alpha = 1.0, size = 1)), fill = "none") +
theme_minimal() +
labs(title = "Snowflake users by country, January 2023", x = NULL, y = "average simultaneous users")
ggsave("snowflake-country.png", p, width = 7, height = 4, dpi = 200)
```
</details>
OONI's Tor Snowflake test also shows an increase in anomalies starting 2023-01-16:
https://explorer.ooni.org/chart/mat?probe_cc=IR&test_name=torsf&since=2023-01-06&until=2023-01-20&axis_x=measurement_start_day
![Iran, Tor test](/uploads/b24367ab9a567018c9a9ecd9daff8394/ooni-mat-torsf-ir-20230106-20230119.png)
Specific Tor Snowflake measurements:
|date|AS|rendezvous_method|result|
|---|--:|---|---|
|[2023-01-17 23:46:57](https://explorer.ooni.org/measurement/20230117T234659Z_torsf_IR_206065_n1_4S8WFEGdb6L9GCk0)|AS206065|domain_fronting|generic_timeout_error|
|[2023-01-17 23:20:22](https://explorer.ooni.org/measurement/20230117T232021Z_torsf_IR_50810_n1_3o3coWvoHX081qRK)|AS50810|domain_fronting|generic_timeout_error|
|[2023-01-17 20:49:42](https://explorer.ooni.org/measurement/20230117T204940Z_torsf_IR_16322_n1_jEg9BYO65fRC1Smm)|AS16322|domain_fronting|ok|
|[2023-01-17 22:11:53](https://explorer.ooni.org/measurement/20230117T221153Z_torsf_IR_31549_n1_Wk2qLQOchyFAlobC)|AS31549|domain_fronting|ok|https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/20907Blocking of public relays in Belarus, 2016-12-012020-06-27T13:43:41ZDavid Fifielddcf@torproject.orgBlocking of public relays in Belarus, 2016-12-01Direct users decreased from 5,500 to 3,000 over a few days starting on November 30 or December 1. Bridge users simultaneously increased, from 250 to 2,000.
OONI blog post: [urandom.pcap: Belarus (finally) bans Tor](https://ooni.torproje...Direct users decreased from 5,500 to 3,000 over a few days starting on November 30 or December 1. Bridge users simultaneously increased, from 250 to 2,000.
OONI blog post: [urandom.pcap: Belarus (finally) bans Tor](https://ooni.torproject.org/post/belarus-fries-onion/):
> 1. Tor directory authorities are not blocked
> 2. Public onion routers have their ORPort blocked by TCP RST injection
> 3. The onion routers’ DirPort is not blocked
> 4. Plain-old non-obfuscated Tor Bridges from BridgeDB circumvent the interference
> 5. Beltelecom (or its upstream) has strange configuration of the networking gear injecting reset packets
![userstats-relay-country-by-2016-09-07-2016-12-11-off.png](uploads/userstats-relay-country-by-2016-09-07-2016-12-11-off.png) [link](https://metrics.torproject.org/userstats-relay-country.html?start=2016-09-07&end=2016-12-11&country=by&events=off)
![userstats-bridge-country-by-2016-09-07-2016-12-11.png](uploads/userstats-bridge-country-by-2016-09-07-2016-12-11.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-09-07&end=2016-12-11&country=by)
![userstats-bridge-combined-by-2016-09-07-2016-12-11.png](uploads/userstats-bridge-combined-by-2016-09-07-2016-12-11.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2016-09-07&end=2016-12-11&country=by)https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40038Blocking of Snowflake in China, 2023-05-12 to 2023-05-152023-05-22T17:13:09ZDavid Fifielddcf@torproject.orgBlocking of Snowflake in China, 2023-05-12 to 2023-05-15Reports of failures to connect with Snowflake in China since 2023-05-12
https://github.com/net4people/bbs/issues/249
> Around afternoon time on May 12 2023,tor browser's built in snowflake stops working<br>
> Connection asist doesn't w...Reports of failures to connect with Snowflake in China since 2023-05-12
https://github.com/net4people/bbs/issues/249
> Around afternoon time on May 12 2023,tor browser's built in snowflake stops working<br>
> Connection asist doesn't work neither.
>
> In Wireshark I see full package loss(TCP Spurious Transmission) to the supposely existing bridge front server(i think that what it is called) ip after initial handshake.
https://forum.torproject.net/t/snowflake-bridge-does-not-work-in-china-since-days-ago/7635
> I built the Snowflake client manually and run it, got Tor logs below, the connection hangs on 10% forever.
Bridge users graph.
https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-15&country=cn<br>
[![Bridge users by transport from China](/uploads/7e3dcbdc20254fe0df1379015e89ca54/userstats-bridge-combined-cn-2023-03-01-2023-05-15.png)](https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-15&country=cn)
A graph that shows the separate contributions of the two bridges, also with the `??` geolocation bug retroactively fixed, by redistributing `??` proportionally to the other countries. This was made from [snowflake-graphs 9de9b4ed](https://gitlab.torproject.org/dcf/snowflake-graphs/-/tree/9de9b4ed7cd7830efce45c191d0a12f63d3cc112) with the additional patch [top-countries-cn.patch.gz](/uploads/d7d96c1e98137a498579f8a12fb7a8df/top-countries-cn.patch.gz).
![Snowflake users in China](/uploads/06f657e8111b9abd9b7f49053dad4069/snowflake-userstats-bridge-combined-cn-20230513.png)
Note that there are events from the the [metrics timeline](https://gitlab.torproject.org/tpo/network-health/metrics/timeline)
that bear on these graphs:
|start date|end date|places|protocols|description|links|? |
|----------|--------|------|---------|-----------|-----|---|
|2023-04-11||cn|obfs4|Sudden drop in access to bridges from the "settings" and "moat" pools from China.|[comment](https://bugs.torproject.org/tpo/anti-censorship/censorship-analysis/40033#note_2896876) [bridge graph](https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-31&country=cn)|X|
|2023-04-11|||snowflake|Release of Snowflake WebExtension 0.7.2, with a fix for missing client country information that had been introduced in 0.6.0 on 2022-06-27. The result is better country-level attribution of Snowflake users: most who had been being assigned to `??` are now assigned to their proper geolocated country.|[archive](https://archive.org/details/snowflake-webextension-0.7.2) [comment](https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/82#note_2895133)||
|2023-04-12|||snowflake|Orbot begins a release rollout of version 17.0.0-RC-1-tor.0.4.7.11. First release of Orbot to include the snowflake-02 bridge along with the existing snowflake-01. Has a change to the Snowflake DTLS fingerprint (removes Hello Verify Request) to mitigate reported blocking in Russia.|[release](https://github.com/guardianproject/orbot/releases/tag/17.0.0-RC-1-tor.0.4.7.11) [Orbot commit adding snowflake-02](https://github.com/guardianproject/orbot/commit/c3f6ee18f17770a5904ad19c3cd24b9c8dcb3885) [IPtProxy commit upgrading Snowflake](https://github.com/tladesignz/IPtProxy/commit/5d0654a6a1439c05d3ee52b2b351b5df1ff3f6dc)||
|2023-04-19||cn|obfs4 snowflake|Changed the recommended transport in Circumvention Settings in China from obfs4 to snowflake.|[comment](https://bugs.torproject.org/tpo/anti-censorship/censorship-analysis/40033#note_2898442) [commit](https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/commit/082c227d680330cf7ff06cd9dff1d59ebc91c4cf)||
Relay users for comparison:
https://metrics.torproject.org/userstats-relay-country.html?start=2023-03-01&end=2023-05-15&country=cn<br>
[![Directly connecting users from China](/uploads/d3c30efab7906b68c67ad6fe429f7ddf/userstats-relay-country-cn-2023-03-01-2023-05-15-off.png)](https://metrics.torproject.org/userstats-relay-country.html?start=2023-03-01&end=2023-05-15&country=cn)
OONI's data on cdn.sstatic.net in China is sparse, though it perhaps shows a larger proportion of anomalies since 2023-05-12:
https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cdn.sstatic.net<br>
[![Web Connectivity Test, cdn.sstatic.net in China](/uploads/65d03af08c65170dac75a28a29f6c1c0/ooni-mat-cdn.sstatic.net-cn-20230515.png)](https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cdn.sstatic.net)
OONI has more torsf measurements. It does look like there are more anomalies since 2023-05-12, or even before.
https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=torsf<br>
![Tor Snowflake Test in China](/uploads/784152cda8c73c9256d84ad19ae8fc61/ooni-mat-torsf-cn-20230515.png)https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024Blocking of Snowflake in Turkmenistan, 2021-10-242024-02-26T15:39:12ZDavid Fifielddcf@torproject.orgBlocking of Snowflake in Turkmenistan, 2021-10-24On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-202...On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-2021-12-16.png)](https://metrics.torproject.org/userstats-bridge-combined.html?start=2021-08-01&end=2021-12-16&country=tm)
Previously discussed at:
* https://gitlab.torproject.org/tpo/community/support/-/issues/40030#note_2759213
* http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-11-04-15.59.log.html#l-55
```
16:19:56 <anadahz> Confused about the meek client metrics in Turkmenistan -- https://metrics.torproject.org/userstats-bridge-combined.png?start=2021-08-02&end=2021-11-04&country=tm
16:20:39 <anadahz> How come and there are so many meek clients in Turkmenistan?
16:20:54 <dcf1> Here is a graph with some more context
16:20:56 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-08-01&end=2021-11-05&country=tm
16:21:00 <meskio> does it look like related to snowflake going down?
16:21:13 <dcf1> however zoom out a bit to get even *more* context (esp. wrt relay users)
16:21:15 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-07-01&end=2021-11-05&country=tm
16:21:23 <cohosh> related info on tor blocking in TM: https://gitlab.torproject.org/tpo/community/support/-/issues/40030
16:22:10 <dcf1> to me it looks like OR and meek were rising simultaneously, then snowflake and OR got blocked.
16:22:33 <cohosh> wow
16:22:49 <meskio> blocked? or our failure with probetest?
16:23:45 <dcf1> but snowflake users globally did not go to zero in the same way https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-08-06&end=2021-11-04&transport=snowflake
16:24:05 <anadahz> On 2021-10-31 the amount of meek clients count were almost spike to 1,5 times than before.
16:24:05 <meskio> I see what you mean :(
16:24:09 <cohosh> yeah this looks suspiciously close to zero
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035Brainstorm and analyze heuristics to guess that a bridge might be offline or ...2024-02-22T21:57:07ZRoger DingledineBrainstorm and analyze heuristics to guess that a bridge might be offline or blockedIn the upcoming "subscription model" plan (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42), we envision several use cases. Here are the first three:
* (1) bridge moves to a new IP address
* (2) bridge goes offline
...In the upcoming "subscription model" plan (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42), we envision several use cases. Here are the first three:
* (1) bridge moves to a new IP address
* (2) bridge goes offline
* (3) bridge gets blocked
Case 1 is the easiest, since if the bridge is at a new IP address, we know this because we have a newer bridge descriptor for it. So if a client comes asking for a replacement, we just give them a new bridge line based on this new bridge descriptor.
For case 2, we want to give users a deterministic replacement -- but only if the bridge is actually offline. So we need some scanning mechanism to discover and/or verify which bridges have gone offline, and it should learn an answer quickly enough to be relevant for the subscription model style replacement.
For case 3, we also want to give users a deterministic replacement, but it has to come from the "dynamic bridge pool" subset, and also we only want to offer a replacement if we believe the bridge is actually blocked. Case 3 is also fun because we don't want to test a given bridge from in-country until we hit a threshold of suspicion that it is blocked.
This umbrella ticket aims to collect ideas for (a) what information sources we can use to decide that a given bridge is worth testing now, and (b) think about architectures for active scanning that go well with these three use cases plus the information sources from 'a'.
Potential data sources:
- Usage metrics (https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/112)
- Client reports
- Reported by tor process (https://gitlab.torproject.org/tpo/core/arti/-/issues/717)
- Reported by Tor Browser
- Measurement probes
- Indirect, external scanning (e.g., spooky scan, censored planet)
- Scans from within the censored region (e.g., OONI, our own censorship probe)
Consumers of this information:
- Subscription model for bridge distribution (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42)
- Reputation-based bridge distribution (https://gitlab.torproject.org/tpo/anti-censorship/lox/lox-overview/-/issues/5)