Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-06-28T09:21:33Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40261Standalone proxy: use standard notation of "inbound" and "outbound"2023-06-28T09:21:33ZitchyonionStandalone proxy: use standard notation of "inbound" and "outbound"Right now, the standalone proxy increment the "outbound" count when it [receives messages from SF client](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L414) and incre...Right now, the standalone proxy increment the "outbound" count when it [receives messages from SF client](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L414) and increment the "inbound" count when it [writes to the relay](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L296). It will be better to use the standard "inbound" and "outbound" notation to include everything regardless of traffic logic because:
1. proxy runners might have a limit of inbound/outbound traffic imposed by their ISP or hosting service provider, and they will be using the standard way to count
2. it's less confusing and more consistent with everything else
3. traffic logic shouldn't matter to proxy runnershttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/155Document in a bit more detail how rdsys is using onbasca2023-04-13T15:58:10ZjugaDocument in a bit more detail how rdsys is using onbascajugajugahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40257Client: add config option to filter out IP address used for ICE2023-06-21T09:14:52ZitchyonionClient: add config option to filter out IP address used for ICEFrom https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used ...From https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used to generate candidates.
In some cases, providing an IP address as candidate could also save one STUN connection. While we still use STUN servers to determinte NAT type on the client side, this could be helpful when [censors are targeting STUN servers](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024#note_2829127).
This came up as I was researching https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40256Standalone Snowflake proxy for Microsoft Windows2023-03-07T14:55:51ZRahim RollinsStandalone Snowflake proxy for Microsoft Windows> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/rel...> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/relay/setup/snowflake/standalone/) provides instructions for installing and configuring the CLI version of Snowflake proxy on Debian, Fedora, Arch Linux, FreeBSD and Ubuntu. However, most users (working on Windows) would be able to help other users bypass censorship without having to keep the browser running. Now this possibility is impossible for them. At least for such volunteers there is not even an instruction, unlike users of the operating systems listed above.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40254Nil Pointer Crash when Initializing Snowflake Proxy2023-03-07T15:49:08ZbimNil Pointer Crash when Initializing Snowflake Proxyhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this b...https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this bumping snowflake to the the latest release in Orbot via our IPtProxy wrapper library.
https://github.com/tladesignz/IPtProxy/issues/39
For now, we simply just init'd our own event dispatcher instance to sidestep the crash.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/120Telegram GetBridgesBot is giving the same bridge to different users and repea...2023-06-21T09:16:58ZGusTelegram GetBridgesBot is giving the same bridge to different users and repeating the same bridge twiceTor Telegram bot GetBridgesBot is replying with the same bridge line and it's repeating twice (xxxx:8599).
Testing with another user, it shared 4 bridges, but gave xxxx:8599 bridge twice again.Tor Telegram bot GetBridgesBot is replying with the same bridge line and it's repeating twice (xxxx:8599).
Testing with another user, it shared 4 bridges, but gave xxxx:8599 bridge twice again.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/79meta: fill the "donate" link on addons.mozilla.org2023-08-01T18:44:42ZWofWcawofwca@protonmail.commeta: fill the "donate" link on addons.mozilla.org![image](/uploads/1f3d212fb7ff1f3a2389c92ad083720e/image.png)
This will add the buttons on the extensions list and on the store page:
<details><summary>Like this</summary>
![image](/uploads/e4727d45059eb5d3b3ce8adb5ed2ff02/image.png)
...![image](/uploads/1f3d212fb7ff1f3a2389c92ad083720e/image.png)
This will add the buttons on the extensions list and on the store page:
<details><summary>Like this</summary>
![image](/uploads/e4727d45059eb5d3b3ce8adb5ed2ff02/image.png)
![image](/uploads/9f7bf215b4235e0871f29d235f7f8e4a/image.png)
</details>
Related: #77https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/24Turbotunnel for Conjure2023-06-19T16:18:32ZCecylia BocovichTurbotunnel for ConjureThe connections to phantom IPs through the conjure station(s) is less reliable than we thought originally, making something like turbotunnel a big quality of life improvement.The connections to phantom IPs through the conjure station(s) is less reliable than we thought originally, making something like turbotunnel a big quality of life improvement.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251Analysis of speed deficiency of Snowflake in China, 2023 Q12024-03-21T20:45:13ZshelikhooAnalysis of speed deficiency of Snowflake in China, 2023 Q1We are currently observing an increase of snowflake bootstrap failure. This ticket document our investigation of this incident.
As we can observe from the vantage point test [result](https://gitlab.torproject.org/tpo/anti-censorship/con...We are currently observing an increase of snowflake bootstrap failure. This ticket document our investigation of this incident.
As we can observe from the vantage point test [result](https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/blob/39c4d2a143c2ce43ffb1cbf39bf18f26d7ba49c7/recentResult_cn), the bootstrap percentage is often more than 10 and less than 100 as a result of poor connection speed.
In order to measure the packet loss rate at the vantage points a few [scripts](https://gist.github.com/xiaokangwang/14ac48ef9fc2ce8dd04f92ed9c0928de) are used to calculate the packet loss rate from packet capture file, here is the result:
```
snowflake-probe-0-eth0.pcap:TOTAL 3027, RECV 2702, LOSS RATE .107
snowflake-probe-1-eth0.pcap:TOTAL 3406, RECV 3169, LOSS RATE .069
snowflake-probe-2-eth0.pcap:TOTAL 2896, RECV 2294, LOSS RATE .207
snowflake-probe-3-eth0.pcap:TOTAL 2883, RECV 2652, LOSS RATE .080
snowflake-probe-4-eth0.pcap:TOTAL 2696, RECV 2514, LOSS RATE .067
snowflake-probe-5-eth0.pcap:TOTAL 847, RECV 669, LOSS RATE .210
snowflake-probe-6-eth0.pcap:TOTAL 1855, RECV 1692, LOSS RATE .087
snowflake-probe-7-eth0.pcap:TOTAL 76, RECV 284, LOSS RATE -2.736 (invalid, more than one dtls connection)
snowflake-probe-8-eth0.pcap:TOTAL 1577, RECV 1255, LOSS RATE .204
snowflake-probe-9-eth0.pcap:TOTAL 1449, RECV 1166, LOSS RATE .195
```
As we can see snowflake's bootstrap percentage is regularly impacted by packet loss rate. We can either make snowflake more resistant to packet loss or improve matching process to reduce packet loss.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/23Use timeouts to detect stale connections and retry2023-04-04T14:14:06ZCecylia BocovichUse timeouts to detect stale connections and retryAs described in #22, there are some cases where a successful connection to the phantom proxy is established, but the TLS handshake with the phantom proxy doesn't complete.
We could add a staleness timeout similar to snowflake to close t...As described in #22, there are some cases where a successful connection to the phantom proxy is established, but the TLS handshake with the phantom proxy doesn't complete.
We could add a staleness timeout similar to snowflake to close the connection and retry registration again.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/22Hang during startup2023-08-17T20:56:13ZVortHang during startupWhen I start conjure + Tor, nothing is happening for several minutes.
Looks like conjure encounter `i/o timeout`, but for some reason do not propagate this error to Tor.
Timeout by itself is not much of a problem, incorrect processin...When I start conjure + Tor, nothing is happening for several minutes.
Looks like conjure encounter `i/o timeout`, but for some reason do not propagate this error to Tor.
Timeout by itself is not much of a problem, incorrect processing of timeout is.
Here is what I see in Tor logs:
```text
Jan 27 11:38:53.000 [notice] Bootstrapped 0% (starting): Starting
Jan 27 11:38:53.000 [notice] Starting with guard context "bridges"
Jan 27 11:38:53.000 [notice] Delaying directory fetches: No running bridges
Jan 27 11:38:54.000 [notice] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
Jan 27 11:38:54.000 [notice] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
Jan 27 11:38:54.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Jan 27 11:43:54.000 [warn] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 143.110.214.222:80)
Jan 27 11:43:54.000 [warn] 1 connections have failed:
Jan 27 11:43:54.000 [warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Jan 27 11:50:39.000 [warn] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 2; recommendation warn; host 0000000000000000000000000000000000000000 at 143.110.214.222:80)
Jan 27 11:50:39.000 [warn] 2 connections have failed:
Jan 27 11:50:39.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Jan 27 11:51:11.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
Jan 27 11:51:11.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
Jan 27 11:51:11.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
```
Here is what I see in conjure logs:
```text
[11:38:53] Redirecting log to file
2023/01/27 08:38:53 Started SOCKS listener at 127.0.0.1:49518
2023/01/27 08:38:54 SOCKS accepted: {143.110.214.222:80 url=https://registration.refraction.network.global.prod.fastly.net/api;front=cdn.sstatic.net map[front:[cdn.sstatic.net] url:[https://registration.refraction.network.global.prod.fastly.net/api]]}
2023/01/27 08:38:54 Attempting to connect to bridge at 143.110.214.222:80
2023/01/27 08:38:54 Using the registration API at https://registration.refraction.network.global.prod.fastly.net/api
[11:38:54] [0-993fa7] Shared Secret - 993fa79ab18355764b72929c0ab200426a6820e4e3b3296d9c20c7a67668d459
[11:38:54] [0-993fa7] covert 143.110.214.222:80
[11:38:54] [0-993fa7] Representative - a78b0aca057f22e950441300511844dfd611b9d30ee42ee9e3fb96c230eae5d5
[11:38:54] [0-993fa7] registering via APIRegistrarBidirectional
2023/01/27 08:38:54 Buffering 517 bytes to send later
2023/01/27 08:38:54 Performing a Conjure registration with domain fronting...
2023/01/27 08:38:54 Conjure station URL: https://registration.refraction.network.global.prod.fastly.net/api
2023/01/27 08:38:54 Domain front: cdn.sstatic.net
[11:38:55] [0-993fa7] bidirectional API registration succeeded
[11:38:55] [0-993fa7] sleeping for 1s
[11:38:56] [0-993fa7] Attempting to Connect ...
[11:38:56] [0-993fa7] Connected to phantom 2001:48a8:687f:1::a32 using transport 1
2023/01/27 08:38:56 Successfully connected to phantom proxy!
2023/01/27 08:38:56 Connected to bridge at 143.110.214.222:80
2023/01/27 08:38:56 Flushed 517 bytes from buffer
[11:38:57] [0-993fa7] failed to dial phantom 35.6.92.87: dial tcp 35.6.92.87:443: i/o timeout
2023/01/27 08:45:39 SOCKS accepted: {143.110.214.222:80 url=https://registration.refraction.network.global.prod.fastly.net/api;front=cdn.sstatic.net map[front:[cdn.sstatic.net] url:[https://registration.refraction.network.global.prod.fastly.net/api]]}
2023/01/27 08:45:39 Attempting to connect to bridge at 143.110.214.222:80
2023/01/27 08:45:39 Using the registration API at https://registration.refraction.network.global.prod.fastly.net/api
2023/01/27 08:45:39 Buffering 517 bytes to send later
[11:45:39] [1-d395fc] Shared Secret - d395fc83724535c06a8696810887780d39dc92c55906a672a8009d4f2959e25c
[11:45:39] [1-d395fc] covert 143.110.214.222:80
[11:45:39] [1-d395fc] Representative - 3fc023e0ac6e4a8561591b150a5744bd62d379ac9291899e248e1e60bbf10775
[11:45:39] [1-d395fc] registering via APIRegistrarBidirectional
2023/01/27 08:45:39 Performing a Conjure registration with domain fronting...
2023/01/27 08:45:39 Conjure station URL: https://registration.refraction.network.global.prod.fastly.net/api
2023/01/27 08:45:39 Domain front: cdn.sstatic.net
[11:45:40] [1-d395fc] bidirectional API registration succeeded
[11:45:40] [1-d395fc] sleeping for 1s
[11:45:41] [1-d395fc] Attempting to Connect ...
[11:45:41] [1-d395fc] Connected to phantom 35.8.49.148 using transport 1
2023/01/27 08:45:41 Successfully connected to phantom proxy!
2023/01/27 08:45:41 Connected to bridge at 143.110.214.222:80
2023/01/27 08:45:41 Flushed 517 bytes from buffer
[11:45:42] [1-d395fc] failed to dial phantom 2001:48a8:7fff:2:a1ae:301b:83bf:dd9d: dial tcp [2001:48a8:7fff:2:a1ae:301b:83bf:dd9d]:443: i/o timeout
2023/01/27 08:51:20 SOCKS accepted: {143.110.214.222:80 url=https://registration.refraction.network.global.prod.fastly.net/api;front=cdn.sstatic.net map[front:[cdn.sstatic.net] url:[https://registration.refraction.network.global.prod.fastly.net/api]]}
2023/01/27 08:51:20 Attempting to connect to bridge at 143.110.214.222:80
2023/01/27 08:51:20 Using the registration API at https://registration.refraction.network.global.prod.fastly.net/api
2023/01/27 08:51:20 Buffering 517 bytes to send later
[11:51:20] [2-e1613b] Shared Secret - e1613b624c8f3e54d59282f8d4b9e443f21bb99fbb00abdc35536be48fa0515d
[11:51:20] [2-e1613b] covert 143.110.214.222:80
[11:51:20] [2-e1613b] Representative - 22d161cbd51034061570b0e680a5170a4816666ef76cdcd6e12ca134fce80689
[11:51:20] [2-e1613b] registering via APIRegistrarBidirectional
2023/01/27 08:51:20 Performing a Conjure registration with domain fronting...
2023/01/27 08:51:20 Conjure station URL: https://registration.refraction.network.global.prod.fastly.net/api
2023/01/27 08:51:20 Domain front: cdn.sstatic.net
[11:51:20] [2-e1613b] bidirectional API registration succeeded
[11:51:20] [2-e1613b] sleeping for 1s
[11:51:21] [2-e1613b] Attempting to Connect ...
[11:51:22] [2-e1613b] Connected to phantom 141.219.104.210 using transport 1
2023/01/27 08:51:22 Successfully connected to phantom proxy!
2023/01/27 08:51:22 Connected to bridge at 143.110.214.222:80
2023/01/27 08:51:22 Flushed 517 bytes from buffer
[11:51:23] [2-e1613b] failed to dial phantom 2001:48a8:7fff:2:431b:5a3b:e14e:2515: dial tcp [2001:48a8:7fff:2:431b:5a3b:e14e:2515]:443: i/o timeout
```
Version: 49f2601b4af6b6e7cecd15d662ea7ee8cee5a7e4Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250Broker side channel fallback mechanism2023-10-03T18:22:22Zmeskiomeskio@torproject.orgBroker side channel fallback mechanismCurrently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) ...Currently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) it will be useful to automatically fall back to amp cache.
This would be really nice to be encoded in the bridge line, but we are already near the limit on size for the bridge line.
The snowflake client could use the bridgeline provided side channel configuration and if that fails try to use the one provided by the flags passed to the binary on launch (by `ClientTransportPlugin`). This has the problem that those flags will not be distributed by Circumvention Settings and needs some coordination with the different tor applications to have the same defaults everywhere. We might need to think how snowflake library users will use this fallback (or if they need to implement it themselves).https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/11can we avoid using 'network: host'?2024-02-27T18:47:05Zmeskiomeskio@torproject.orgcan we avoid using 'network: host'?We could use the `-ephemeral-ports-range` and expose those ports with docker.We could use the `-ephemeral-ports-range` and expose those ports with docker.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248(More) Distributed servers2023-09-17T15:22:17ZWofWcawofwca@protonmail.com(More) Distributed serversStanding on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eli...Standing on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eliminating the need of maintaining several centralized, set-in-stone Snowflake servers (bridges), which, mind, [costs quite a bit to operate, upgrade](https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations) and optimize.
What the parties need to become capable of doing so all this can work:
* Severs (a.k.a. bridges (or relays)): set up a Tor bridge, and set up a Snowflake server coupled with it, with a dedicated port (say, `7901` see #40166)
* Proxies: set [allowed relay pattern](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/7db2568448fed6d883b33db11e3a497c69f1748f/proxy/main.go#L28) to `*:7901` (any host, at port `7901`, see #40166)
* Clients: choose a server (bridge) that is set up accordingly, set up the Snowflake client to forward connections to that server, then connect Tor to it as a bridge.
From what I see, it should be quite possible upgrade all the current bridges ([or better public relays](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2875147)) this way (maybe even by embedding a Snowflake server in the Tor relay package), or upgrade bridge distribution mechanisms with a way to filter bridges by whether they accept Snowflake connection (like it is with obfs4). At which point it should become possible to let the Tor client choose the entry node itself, not manually specify a bridge you want (ahh, just remembered that it needs to learn the addresses of the nodes first. Maybe it can connect to directory authorities through Snowflake as well).
This idea is a based on these other ideas: #40166, #40168.
A step further would be to combine the server (bridge) and the proxy on one machine, but I haven't thought about it enough (see #40165, for example).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/77Add "Donate" link to the popup2023-04-25T10:44:36ZWofWcawofwca@protonmail.comAdd "Donate" link to the popupLike this maybe
![image](/uploads/7928d63db7365ba0fb2e4abe09456ae6/image.png)Like this maybe
![image](/uploads/7928d63db7365ba0fb2e4abe09456ae6/image.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40244TLS instead of DTLS (TLS Candidates for ICE)2023-01-11T12:28:49ZWofWcawofwca@protonmail.comTLS instead of DTLS (TLS Candidates for ICE)I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe...I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe another protocol could be used. I reached out to the creator of the Pion library (the one that Snowflake uses) and he [told](https://gophers.slack.com/archives/CAK2124AG/p1671995560491059) me that [this draft](https://datatracker.ietf.org/doc/html/draft-martinsen-ice-tls-candidates-00) is probably what I want.
So, the idea: peers connect to each other with TLS, making DPI's job harder, because TLS is probably the last thing censors want to block, unlike DTLS, which offers relatively low collateral IMO.
Sean also said that it might already be implemented in libwebrtc, and that he's willing to add it to Pion.
So, I suggest to evaluate this idea and provide the Pion team the assistance we can offer, if we think that it's a good idea.https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/8Dynamic Bridges Dead on Arrival in China, 2023 Q12024-02-27T18:22:20ZshelikhooDynamic Bridges Dead on Arrival in China, 2023 Q1Since the beginning of 2023, significant amount of dynamic bridges are dead on arrival in China, which means it is inaccessible since the first probe, as seen in [this](https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measu...Since the beginning of 2023, significant amount of dynamic bridges are dead on arrival in China, which means it is inaccessible since the first probe, as seen in [this](https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/commit/bd57f51e93e0b34299e6996536b71409b6850a1e#22f475052c3dc2d8db62ff1f6a5f6aa268ecdc6d) commit.
The following observations have been made:
* The inaccessible bridges are blocked by IP.
* Adjacent IP blocked in some, but not all cases.
* Some dead on arrival IP address have an IP that served as a bridge before. (check it with `git log -S '****' --source`, gitlab search won't work)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/76Toggle "Keep running when the browser is closed" doesn't activate when clicked2023-01-10T19:11:35ZcypherpunksToggle "Keep running when the browser is closed" doesn't activate when clickedInfos about my system :
Opera browser Version : 93.0.4585.37 (Stable)
System: Windows 10 64-bit
Chromium version: 107.0.5304.122
Version of the Snowflake chrome extension : 0.7.0
The toggle on the Snowflake web extension called "Keep ru...Infos about my system :
Opera browser Version : 93.0.4585.37 (Stable)
System: Windows 10 64-bit
Chromium version: 107.0.5304.122
Version of the Snowflake chrome extension : 0.7.0
The toggle on the Snowflake web extension called "Keep running when the browser is closed" doesn't activate . I've installed the extension through the Chrome web-store (since Opera can install extensions directly from the chrome webstore). But when I click on the toggle to activate it, nothing happens, it doesn't move, it doesn't activate and stays in the default disabled state. the other toggle titled "Enabled" above it works correctly though.https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/51set up a config for the black code formatter2023-01-10T19:10:52Zn0tooseset up a config for the black code formatterhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/112Reported as offline in metrics, some bridges are online and running2024-02-29T15:22:53ZGusReported as offline in metrics, some bridges are online and runningSince last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject....Since last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject.org/rs.html#details/25A5B3BB5449EC5A0D4AE4DB657899C02C186EBE), but on the tor logs I see:
>Nov 28 12:02:57.000 [notice] Heartbeat: Since last heartbeat message, I have seen 200 unique clients.
Other messages on the logs:
```
Nov 20 12:23:29.000 [notice] Guard bauruine ($5B83DC983406651A0B4F6AE1940793CDD6A6F92E) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 198/283. Use counts are 63/63. 227 circuits completed, 0 were unusable, 30 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
Nov 20 23:04:10.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 5983/6034). That's ok. We will try to fetch missing descriptors soon.
Nov 21 03:24:31.000 [notice] Guard rixtyminutes ($01AE2DE314276C82FCCC3603A1C2F3238E6544C9) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 109/156. Use counts are 37/37. 132 circuits completed, 0 were unusable, 23 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
```
Reddit: https://www.reddit.com/r/TOR/comments/z2o7ro/bridge_metrics_showing_offline/meskiomeskio@torproject.orgmeskiomeskio@torproject.org