Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-06-07T14:52:22Zhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/1Sync Lox bridgetable with rdsys2023-06-07T14:52:22ZonyinyangSync Lox bridgetable with rdsysThis will involve creating a database for the Lox bridge table that can be restored from an unexpected shutdown and checking each resource received from rdsys against the Lox bridge table when a full update is sent (about every 30 minute...This will involve creating a database for the Lox bridge table that can be restored from an unexpected shutdown and checking each resource received from rdsys against the Lox bridge table when a full update is sent (about every 30 minutes) to ensure that the bridgepool from rdsys and the Lox bridge table do not fall out of sync.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/85Avast blocking connection to 02.snowflake.torproject.net on Chrome2023-06-27T18:50:48ZcypherpunksAvast blocking connection to 02.snowflake.torproject.net on ChromeHello, I've had the Snowflake browser extension on Google Chrome for at least a year now, maybe 2 years. I've never had any problems with it. Suddenly, starting yesterday, I've started receiving alerts from a security software I've had...Hello, I've had the Snowflake browser extension on Google Chrome for at least a year now, maybe 2 years. I've never had any problems with it. Suddenly, starting yesterday, I've started receiving alerts from a security software I've had installed for over a year now (Avast) about security threats from Tor Snowflake.
This has never happened before, so I just wanted to check if there are any new, known security vulnerabilities for Snowflake providers? I'm just curious as to why I'm suddenly receiving alerts from Avast.
This is the warning I've received twice now: "We've blocked a threat URL: Blacklist on https://
02.snowflake.torproject.net/ from being downloaded."
I've not put snowflake on a blacklist, and it always worked fine before, so either Avast recently put Snowflake on a blacklist, Snowflake is trying to download an update or something, or a malicious user (somehow, I'm not too knowledgeable about what's technically possible for users to do) is trying to download something on my computer via Snowflake.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/31Dependency Dashboard2023-06-01T14:40:43ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/golang-1.x -->[Update golang Docker tag to v1.20](!11)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
- `golang 1.18-buster`
- `golang 1.20-buster`
- `golang 1.20-buster`
</details>
</blockquote>
</details>
<details><summary>gomod</summary>
<blockquote>
<details><summary>go.mod</summary>
- `go 1.17`
- `git.torproject.org/pluggable-transports/snowflake.git/v2 v2.5.1`
- `github.com/pires/go-proxyproto v0.7.0`
- `github.com/refraction-networking/gotapdance v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib v1.4.0`
</details>
</blockquote>
</details>https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40273Automated Testing Script for Potential Domain Fronting Domains2023-10-25T15:42:23ZshelikhooAutomated Testing Script for Potential Domain Fronting DomainsIn order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to auto...In order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to automate the screening of domain name for domain fronting.
The following domain name was evaluated to be potentially useable for domain fronting. We should try to reduce solo reliance on cdn.sstatic.net with a fronting domain rotation system to reduce the chance any of them get blocked.
See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40068 , https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/123shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector/-/issues/4Implement Alert System for logcollector2023-10-25T13:11:16ZshelikhooImplement Alert System for logcollectorIn order to implement an alert system for resource monitored by logcollector, a standardized result reporting system should be used to report a subset of data to a metrics monitoring system(Prometheus), which will subsequently generate a...In order to implement an alert system for resource monitored by logcollector, a standardized result reporting system should be used to report a subset of data to a metrics monitoring system(Prometheus), which will subsequently generate alert(grafana alert managor).
This would require adding state system to log collector to keep essential data between restart as well as prometheus data exporter for some data.
## State system
A json file with all persistent states will be written to the disk every second if there is a change in the status. The file will be named `status.{start_time}.{time_after_start}.json`, where {start_time} is the system wall clock time when process started in linux time format, {time_after_start} is the number of seconds since the process started in monotonic clock second. (Current wall clock time is not used to deal with leap second or more likely ntp time adjustment).
A new file is always created for each save, and logcollecor is designed to never overwrite any state file. An external [script](https://superuser.com/questions/268344/how-do-i-delete-all-but-10-newest-files-in-linux) will be used to delete old status.
Each exporter have its own state files.
## prometheus data exporter
Log collector will expose a standard prometheus data exporter endpoint to facilitate alerts.
It will initially only expose vantage point last seen information as `vantage_point_lastseen(site=XXX)`.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/6)shelikhooshelikhoohttps://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/40272go snowflake picks 'restricted' but stun-nat-behaviour picked endpoint indepe...2023-05-16T18:32:06ZRoger Dingledinego snowflake picks 'restricted' but stun-nat-behaviour picked endpoint independentOn my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2....On my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2.6
go: downloading github.com/pion/transport/v2 v2.2.0
go: downloading golang.org/x/crypto v0.5.0
go: downloading github.com/pion/udp/v2 v2.0.1
$ cd go/bin/
$ ./stun-nat-behaviour
INFO: 2023/05/13 15:45:02 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:02 Local address: 0.0.0.0:33731
INFO: 2023/05/13 15:45:02 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:02 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:45:02 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
INFO: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT mapping behavior: inconclusive
INFO: 2023/05/13 15:45:03 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:03 Local address: 0.0.0.0:60922
INFO: 2023/05/13 15:45:03 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:03 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:45:03 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
WARNING: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT filtering behavior: inconclusive
$ ./stun-nat-behaviour -server stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:52168
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
INFO: 2023/05/13 15:46:13 Mapping Test II: Send binding request to the other address but primary port
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.71:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.71:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
WARNING: 2023/05/13 15:46:13 => NAT mapping behavior: endpoint independent
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:55735
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:14 Filtering Test II: Request to change both IP and port
INFO: 2023/05/13 15:46:14 Sending to 185.125.180.70:3478: (28 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.71:3479: (100 bytes)
WARNING: 2023/05/13 15:46:14 => NAT filtering behavior: endpoint independent
```
which sure makes me think that I successfully put my laptop in dmz mode behind my router. (As another data point, I can telnet in to services on this laptop from the outside).
But then running headless snowflake, I have
```
2023/05/13 19:57:49 snowflake-proxy 2.4.1
023/05/13 19:57:49 Proxy starting
2023/05/13 19:57:49 WebRTC: Created offer
2023/05/13 19:57:49 WebRTC: Set local description
2023/05/13 19:57:54 Offer: {"type":"offer","sdp":"v=0\r\no=- 4036211437389836707 1684007869 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 15:17:2D:41:43:C5:5D:D4:BD:B0:20:17:01:36:DB:0A:60:2B:E5:C4:A0:01:69:55:8F:77:71:17:72:F2:64:57\r\na=extmap-allow-mixed\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:TKUQqKORrkMnHIMw\r\na=ice-pwd:xLDVhUwJYEBnMGBjSgqOnluskGZjDVNg\r\na=candidate:1961522861 1 udp 2130706431 [scrubbed] 39181 typ host\r\na=candidate:1961522861 2 udp 2130706431 [scrubbed] 39181 typ host\r\na=end-of-candidates\r\n"}
2023/05/13 19:58:19 NAT Type measurement: unknown -> restricted = restricted
2023/05/13 19:58:19 NAT type: restricted
```
It sure looks like my snowflake is mistakenly calling me restricted when I'm not.
Did the newer go libs or something cause a regression where we think people like me are restricted?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40271refactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`2023-06-29T18:57:41ZWofWcawofwca@protonmail.comrefactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pio...[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pion would filter out addresses by itself, instead of us only stripping them off when sending the offer/answer (see 0fae4ee8ea487c3b4384217e193e5b9a9088e7de, 1867f89562fb25bf9a3c2172a7b6f0a198c81adb, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/19026). It _might_ also solve [the problem (if it's a problem)](https://forum.torproject.net/t/ubuntu-snowflake-standalone-proxy-tries-to-access-private-lan/7485?u=wofwca) where if a client sends local addresses in its offer, the proxy will try to connect to these local addresses.
Also while we're at it, need to check whether it can be a proper way to solve https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40011error while building main branch of obfs42023-05-25T20:28:25Zboklmerror while building main branch of obfs4While building the `main` branch (currently baf2254038d2390ac2b4ca97ca78365ae39e4d54), I have the following error:
```
# github.com/klauspost/compress/huff0
../vendor/github.com/klauspost/compress/huff0/decompress.go:774:21: cannot conve...While building the `main` branch (currently baf2254038d2390ac2b4ca97ca78365ae39e4d54), I have the following error:
```
# github.com/klauspost/compress/huff0
../vendor/github.com/klauspost/compress/huff0/decompress.go:774:21: cannot convert out (variable of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:775:24: cannot convert out[dstEvery:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:776:24: cannot convert out[dstEvery * 2:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:777:24: cannot convert out[dstEvery * 3:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1013:21: cannot convert out (variable of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1014:24: cannot convert out[dstEvery:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1015:24: cannot convert out[dstEvery * 2:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1016:24: cannot convert out[dstEvery * 3:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
```
I have not tested but I think updating the go version to 1.17 in `go.mod` might fix that.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/164some bridges are not appearing in the assignments.log2024-03-06T19:11:22Zmeskiomeskio@torproject.orgsome bridges are not appearing in the assignments.log3575906728C3ADCD4CC54915E0D1AA0855480D78 and 226450492AD08A406A9CBED4CC32DF7D362D747D appear in https://bridges.torproject.org/status?id=<fingerprint> as functional, but they are not being assigned to any distributor.3575906728C3ADCD4CC54915E0D1AA0855480D78 and 226450492AD08A406A9CBED4CC32DF7D362D747D appear in https://bridges.torproject.org/status?id=<fingerprint> as functional, but they are not being assigned to any distributor.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/52plugins are loading from the local directory2023-05-24T17:52:27Zmeskiomeskio@torproject.orgplugins are loading from the local directoryRight now onionsprouts bot expect the plugins to be in `./OnionSproutsBot/plugins`. Which works fine for development as is usually run from the git repo, but not for deployment that we might want to run it from a different folder.
I thi...Right now onionsprouts bot expect the plugins to be in `./OnionSproutsBot/plugins`. Which works fine for development as is usually run from the git repo, but not for deployment that we might want to run it from a different folder.
I think plugins should be loaded from the onionsproutsbot library folder where is installed.Sponsor 139: Rapid Response Iranmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/84Snowflake web badge need 3rd-party cookies to run, which is unskilled in toda...2023-05-16T18:24:05ZsolidsSnowflake web badge need 3rd-party cookies to run, which is unskilled in today's most browsersToday most browser set the default config to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love]...Today most browser set the default config to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love](https://relay.love) will show "Cookies are not enabled." in my browser and it's not possible to run without re-enabling 3rd-party cookies, which will allow tracking websites sneak in my privacy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40269Snowflake web badge need 3rd-party cookies to run, which is unskilled in toda...2023-04-20T16:09:34ZsolidsSnowflake web badge need 3rd-party cookies to run, which is unskilled in today's most browsersToday most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love...Today most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love](https://relay.love) will show "Cookies are not enabled." in my browser and it's not possible to run without re-enabling 3rd-party cookies, which will allow tracking websites sneak in my privacy.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/125tpo/anti-censorship/lox/lox-overview#72023-04-18T16:30:56Zonyinyangtpo/anti-censorship/lox/lox-overview#7https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/163export num of bridges per ratio into prometheus2023-05-30T07:45:07Zmeskiomeskio@torproject.orgexport num of bridges per ratio into prometheusCan we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometh...Can we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometheus doesn't handle well having too many different values for the label. We could to pack the ratios together on 0.1 steps and decide a maximum value that we just count together everything above that. I'm not sure if we'll be able to plot this nicelly in graphana or if there are better tools in prometheus for this.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/162Telegram distributor fails for new accounts with few dynamic bridges2023-08-23T18:59:04Zmeskiomeskio@torproject.orgTelegram distributor fails for new accounts with few dynamic bridgesThere is currently only one dynamic bridge. The telegram distributor is not working properly.There is currently only one dynamic bridge. The telegram distributor is not working properly.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/161Resources with failing tests (bridgestrap/onbasca) should be explicitly marke...2023-06-16T18:10:10ZonyinyangResources with failing tests (bridgestrap/onbasca) should be explicitly marked as `gone`Resources that fail bridgestrap and/or onbasca tests are not distributed according to the [functionality here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/core/backend_resources.go#L171) but as far as I can te...Resources that fail bridgestrap and/or onbasca tests are not distributed according to the [functionality here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/core/backend_resources.go#L171) but as far as I can tell are not marked as `gone` explicitly anywhere. Instead resources are determined to be `gone` when they have been pruned [based on their expiration](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L62) but this is based on when a resource's bridge descriptors expire rather than when a resource is failing for other reasons. If resources are no longer distributed, they should be marked as `gone` to ease syncing with distributors. This functionality is particularly important for systems like Lox that maintain some internal bridge distribution state.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/160Include metrics to track flickering bridges/resources by onbasca ratio2023-05-29T23:19:43ZonyinyangInclude metrics to track flickering bridges/resources by onbasca ratioWhile rdsys [collects metrics for onbasca's bandwidth ratio](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L118) and provides insight on a resource's state (`untested`, `accepted`, `rejected`), it...While rdsys [collects metrics for onbasca's bandwidth ratio](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L118) and provides insight on a resource's state (`untested`, `accepted`, `rejected`), it would be useful to have more insight into whether and how often resources "flicker", meaning how often do `accepted` or `rejected` resources change back and forth?
The first step is to figure out if this happens. Then when we have collected some metrics about it and have determined if it does indeed happen, and how often, we can expand upon the information we collect about it.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/probeobserver/-/issues/2test meek-azure connectivity2024-02-27T19:08:20Zmeskiomeskio@torproject.orgtest meek-azure connectivityshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/19Fix crash on launch when unexpected input was supplyed over PT protocol2023-10-16T15:58:12ZshelikhooFix crash on launch when unexpected input was supplyed over PT protocol```
Apr 13 14:32:06.000 [info] launch_managed_proxy(): Managed proxy at '/usr/bin/webtunnel-server' has spawned with PID '100'.
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' repo...```
Apr 13 14:32:06.000 [info] launch_managed_proxy(): Managed proxy at '/usr/bin/webtunnel-server' has spawned with PID '100'.
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: panic: assignment to entry in nil map
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error:
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: goroutine 1 [running]:
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: git.torproject.org/pluggable-transports/goptlib%2egit.Args.Add(...)
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: /go/pkg/mod/git.torproject.org/pluggable-transports/goptlib.git@v1.2.0/args.go:32
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: main.main()
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: /webtunnel/main/server/main.go:46 +0x430
```shelikhooshelikhoo