Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:43:53Zhttps://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/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/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/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/pluggable-transports/snowflake/-/issues/40021Break from infinite client-broker poll after call to snowflakes.End()2020-11-23T17:12:51ZCecylia BocovichBreak from infinite client-broker poll after call to snowflakes.End()This bug was originally brought to my attention in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40018#note_2715140 but it's a more general issue than just for snowflake on mobile devices.
The...This bug was originally brought to my attention in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40018#note_2715140 but it's a more general issue than just for snowflake on mobile devices.
The following for loop in [client/lib/webrtc.go](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/61beb9d996527cd8cb9e4ca650f8cbf24df1503e/client/lib/webrtc.go#L224) will poll infinitely until it receives an available snowflake:
```
// exchangeSDP sends the local SDP offer to the Broker, awaits the SDP answer,
// and returns the answer.
func exchangeSDP(broker *BrokerChannel, offer *webrtc.SessionDescription) *webrtc.SessionDescription {
// Keep trying the same offer until a valid answer arrives.
for {
// Send offer to broker (blocks).
answer, err := broker.Negotiate(offer)
if err == nil {
return answer
}
log.Printf("BrokerChannel Error: %s", err)
log.Printf("Failed to retrieve answer. Retrying in %v", ReconnectTimeout)
<-time.After(ReconnectTimeout)
}
}
```
Because of ongoing work on matching up clients with compatible proxies in snowflake#40013, we currently have almost no "unrestricted" proxies available, meaning snowflake clients behind restricted NATs have to poll for a very long time before getting a snowflake. Normally the potentially infinite polling isn't a problem as long as there are snowflakes available, but if the client makes a call to `snowflakes.End()` we *should* stop polling regardless of whether or not snowflakes are available.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5470Bridge descriptors on ponticum.torproject.org are out of date2020-06-27T13:43:29ZAaron GibsonBridge descriptors on ponticum.torproject.org are out of dateThe timestamp on the bridge descriptors indicates that it hasn't updated since Mar 7:
```
ls -lstra /srv/bridges.torproject.org/from-authority/bridge-descriptors
6392 -rw-r--r-- 1 bridgedb bridgedb 6542607 Mar 7 20:37 /srv/bridges.torp...The timestamp on the bridge descriptors indicates that it hasn't updated since Mar 7:
```
ls -lstra /srv/bridges.torproject.org/from-authority/bridge-descriptors
6392 -rw-r--r-- 1 bridgedb bridgedb 6542607 Mar 7 20:37 /srv/bridges.torproject.org/from-authority/bridge-descriptors
```
I sent Lucky Green an email and will update this ticket with the response.https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/26083Bridge detector. Fake?2021-07-09T18:29:19ZcypherpunksBridge detector. Fake?Some code for detection found. Is it real?Some code for detection found. Is it real?cypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/14064Bridge IP + ID wrapping weirdness2020-06-27T13:43:07ZTracBridge IP + ID wrapping weirdnessLink in question: https://bridges.torproject.org/bridges?transport=obfs3
When bridge's IP addresses and IDs are put on the webpage there is a weird wrapping that occurs on screen. This is a minor usability issue when somebody wants to c...Link in question: https://bridges.torproject.org/bridges?transport=obfs3
When bridge's IP addresses and IDs are put on the webpage there is a weird wrapping that occurs on screen. This is a minor usability issue when somebody wants to copy/paste the bridge information or try to read it.
Specifically this occurs when you request bridges with a pluggable transport. The easiest fix for this would be to change the padding size from 20px to 10px in div.bridge-lines in your CSS files. This won't solve the usability issue with all pluggable transport with a long name (e.g. scramblesuit)
Thank you for your consideration.
**Trac**:
**Username**: breadtkIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/190bridge-pool-assignment seems to often miss all webtunnel bridges2024-01-10T16:10:08Ztrinity-1686abridge-pool-assignment seems to often miss all webtunnel bridgesit seems most bridge-pool-assignment on collector contains no webtunnel bridges, despite such bridging existing and seemingly working.
Between `2023-12-11-00-20-28` and `2023-12-13-23-42-31`, 144 files have been generated, only 3 of whi...it seems most bridge-pool-assignment on collector contains no webtunnel bridges, despite such bridging existing and seemingly working.
Between `2023-12-11-00-20-28` and `2023-12-13-23-42-31`, 144 files have been generated, only 3 of which containing webtunnel bridges (`2023-12-11-22-50-28`, `2023-12-12-05-42-32` and `2023-12-11-22-20-28`, each containing 46 webtunnel bridges). It seems impossible that the reason is 46 bridges being alive for one period, and dead for every other, all in sync, so there is definitely some bug somewhere.
~~I haven't (yet) check further in the past to know if it was always like that, or when it started.~~
see belowmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10796Bridgedb became unresponsive2020-06-27T13:43:17ZMatthew FinkelBridgedb became unresponsiveBridgedb stopped responding to requests. The last entries in the logs were from a web request but there's no indication of an error or exception.
```
Feb 03 01:50:39 [DEBUG] Accept-Language: ['en-US']
Feb 03 01:50:39 [DEBUG] Languages: ...Bridgedb stopped responding to requests. The last entries in the logs were from a web request but there's no indication of an error or exception.
```
Feb 03 01:50:39 [DEBUG] Accept-Language: ['en-US']
Feb 03 01:50:39 [DEBUG] Languages: []
Feb 03 09:23:11 [INFO] Logger Started.
```
SIGHUP had no affect, too.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/2678bridgedb /16 filtering needs review2020-06-27T13:43:34ZKarsten Loesingbridgedb /16 filtering needs reviewSomeone should review aagbsn's filter16 branch:
https://github.com/aagbsn/bridgedb/tree/filter16Someone should review aagbsn's filter16 branch:
https://github.com/aagbsn/bridgedb/tree/filter16