Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-11-02T11:44:51Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/27IPv6 only on bridges web site2023-11-02T11:44:51ZJacobo NájeraIPv6 only on bridges web siteOn the site of the bridge, they only appear with IPv6 even when the bridges are only configured for IPv4
https://bridges.torproject.org/bridges/?transport=webtunnel
Thanks, JacoboOn the site of the bridge, they only appear with IPv6 even when the bridges are only configured for IPv4
https://bridges.torproject.org/bridges/?transport=webtunnel
Thanks, Jacobohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/6Implement integration tests2023-11-02T11:08:42ZPhilipp Winterphw@torproject.orgImplement integration testsLet's figure out a way to implement integration tests for rdsys. Here's a simple suggestion for a simple shell script:
1. Write a simple cached-extrainfo file to disk.
2. Start the backend.
3. Start the HTTPS distributor.
4. Use curl to ...Let's figure out a way to implement integration tests for rdsys. Here's a simple suggestion for a simple shell script:
1. Write a simple cached-extrainfo file to disk.
2. Start the backend.
3. Start the HTTPS distributor.
4. Use curl to fetch bridges from the HTTPS distributor.
5. Make sure that the bridges are the same as those in the cached-extrainfo file.
There are probably smarter ways to accomplish this. Let's make sure that our integration tests are lightweight and can be run as part of a continuous integration test infrastructure.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/censorship-analysis/-/issues/40039Add ShadowSocks plugable transport2023-11-02T08:07:01ZcypherpunksAdd ShadowSocks plugable transportIt is stronger crypto, has PFS and combat-proven in China. See
https://mullvad.net/en/help/intro-shadowsocks/
https://github.com/shadowsocks/shadowsocks-rust
I have succesfully done my experiment and speed is better than meek.
Tor --S...It is stronger crypto, has PFS and combat-proven in China. See
https://mullvad.net/en/help/intro-shadowsocks/
https://github.com/shadowsocks/shadowsocks-rust
I have succesfully done my experiment and speed is better than meek.
Tor --SOCKS--> SS local --/censor/--> SS server --> internethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/86snowflake on local network2023-11-01T10:30:11Zcypherpunkssnowflake on local networkI don't know much about network so please help me on that.
I am running a web server on iOS, and I tried to put iframe embedding on my web server's html page.
It's only on the local network, which means I can access the webpage through...I don't know much about network so please help me on that.
I am running a web server on iOS, and I tried to put iframe embedding on my web server's html page.
It's only on the local network, which means I can access the webpage through same Wi-Fi, will the snowflake effective on that case?
and I find snowflake is very slow, may I ask how many deployed server can bring the snowflake to the speed of regular website browsing, I hope I can help with that.
Thanks!https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/29Add metrics for open Invite distribution2023-10-31T21:21:02ZonyinyangAdd metrics for open Invite distributionFuther to #28 we should add metrics to measure how quickly we get to k number of users as well as how quickly we get to the maximum buckets distributed (#28) each day so we can better tweak our distribution process.Futher to #28 we should add metrics to measure how quickly we get to k number of users as well as how quickly we get to the maximum buckets distributed (#28) each day so we can better tweak our distribution process.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40302Proxy hourly stats did not actually happen during that hour2023-10-30T16:44:18ZRoger DingledineProxy hourly stats did not actually happen during that hourMy snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relaye...My snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relayed ↓ 561833 KB, ↑ 97282 KB.
2023/10/27 11:53:58 In the last 1h0m0s, there were 63 connections. Traffic Relayed ↓ 124717270 KB, ↑ 6237157 KB.
2023/10/27 12:53:58 In the last 1h0m0s, there were 48 connections. Traffic Relayed ↓ 745608 KB, ↑ 97699 KB.
```
That "125 gigabytes" entry translates to... almost 35 megabytes per second of traffic, on average during the hour? Probably by only a few or even one user? This did not happen during that hour.
Looking at proxy/lib/pt_event_logger.go:
```
case event.EventOnProxyConnectionOver:
e := e.(event.EventOnProxyConnectionOver)
p.inboundSum += e.InboundTraffic
p.outboundSum += e.OutboundTraffic
p.connectionCount += 1
```
I.e. what is happening here is that the stats for the entire connection are counted during the hour that it closed.
See the forum for somebody else reporting this same issue (forum post noticed courtesy MarkC on irc): https://forum.torproject.org/t/impossible-metric-for-snowflake-proxy/9941/1
We should either (a) make the hourly "In the last 1h0m0s," be accurate, in the sense that they actually tell me what happened in the last 1h0m0s, or (b) change the log message so it's clearer it is telling me how many connections finished during that hour along with total transfer on those recently-closed connections.
I'd prefer solution 'a', since it is what I thought I was getting out of these log entries, and I was using it to e.g. try to judge what timezones my snowflake is popular.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40079Privacy preserving stats in Snowflake standalone proxy2023-10-30T16:42:52ZGusPrivacy preserving stats in Snowflake standalone proxyWhile running a Snowflake standalone proxy, I can see user stats in the logs:
```
2021/11/10 04:27:22 Traffic throughput (up|down): 10 KB|8 KB -- (40 OnMessages, 31 Sends, over 80 seconds) ...While running a Snowflake standalone proxy, I can see user stats in the logs:
```
2021/11/10 04:27:22 Traffic throughput (up|down): 10 KB|8 KB -- (40 OnMessages, 31 Sends, over 80 seconds)
2021/11/10 04:27:22 datachannelHandler ends
2021/11/10 04:31:16 OnClose channel
2021/11/10 04:31:16 Traffic throughput (up|down): 333 KB|308 KB -- (950 OnMessages, 1184 Sends, over 2179 seconds)
2021/11/10 04:31:16 datachannelHandler ends
2021/11/10 04:33:11 sdp offer successfully received.
2021/11/10 04:33:11 Generating answer...
2021/11/10 04:33:15 OnDataChannel
2021/11/10 04:33:15 Connection successful.
2021/11/10 04:33:15 OnOpen channel
2021/11/10 04:33:15 connected to relay
2021/11/10 04:38:14 OnClose channel
2021/11/10 04:38:14 Traffic throughput (up|down): 227 KB|16 KB -- (141 OnMessages, 250 Sends, over 299 seconds)
2021/11/10 04:38:14 datachannelHandler ends
2021/11/10 04:39:15 sdp offer successfully received.
2021/11/10 04:39:15 Generating answer...
```
It would be nice to have privacy preserving stats, so instead of information per user, we could have aggregated stats like bridge's heartbeat, for example:
```
Nov 11 02:02:59.000 [notice] Heartbeat: Tor's uptime is 10 days 12:00 hours, with 27 circuits open. I've sent 70 GB and received 70 GB. I've received 6251 connections on IPv4 and 711 on IPv6. I've made 78879 connections with IPv4 and 17757 with IPv6.
Nov 11 02:02:59.000 [notice] While bootstrapping, fetched this many bytes: 1601628 (microdescriptor fetch)
Nov 11 02:02:59.000 [notice] While not bootstrapping, fetched this many bytes: 152599774 (server descriptor fetch); 15050 (server descriptor upload); 17615482 (consensus network-status fetch); 1604564 (microdescriptor fetch)
Nov 11 02:02:59.000 [notice] Heartbeat: In the last 6 hours, I have seen 50 unique clients.
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40301Non-fronted connections to the broker no longer work since 9fdfb3d1b53e911342...2023-10-30T16:27:44ZCecylia BocovichNon-fronted connections to the broker no longer work since 9fdfb3d1b53e9113422a7a2816b2a9af4450b4acThe changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a889...The changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a88927e42fb2e3864f706d3e3c72fd0dca3/client/lib/rendezvous_http.go#L49 is never false, causing a connection to a blank URL to happen if no front is provided:
```
2023/10/26 14:46:44 Negotiating via HTTP rendezvous...
2023/10/26 14:46:44 Target URL: snowflake-broker.torproject.net
2023/10/26 14:46:44 Front URL:
2023/10/26 14:46:44 WebRTC: closing DataChannel
2023/10/26 14:46:44 WebRTC: closing PeerConnection
2023/10/26 14:46:44 WebRTC: Closing
2023/10/26 14:46:44 WebRTC: dial tcp :443: connect: connection refused Retrying...
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/147integrate whatsapp library into rdsys2023-10-26T16:50:27ZGabagaba@torproject.orgintegrate whatsapp library into rdsysmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector/-/issues/2Connection Speed Info Collection2023-10-25T15:47:43ZshelikhooConnection Speed Info CollectionCurrently we are not collecting connection speed info, which is required for performance evaluation. We should collect this info.Currently we are not collecting connection speed info, which is required for performance evaluation. We should collect this info.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/70Centralized Probe Log Collection Ascension Request2023-10-25T15:47:20ZshelikhooCentralized Probe Log Collection Ascension Request
This is a special merge request to transfer [Centralized Probe Log Collection](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/54) toolkit, which is currently an individual project, into an Anti-censorship Team Project.
...
This is a special merge request to transfer [Centralized Probe Log Collection](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/54) toolkit, which is currently an individual project, into an Anti-censorship Team Project.
Here is a list of codes that would be transferred:
- [x] [LogCollector](https://gitlab.torproject.org/shelikhoo/logCollector)
- [x] [LogCollector support for probetest](https://gitlab.torproject.org/shelikhoo/probetest/-/commits/dev-logcollector)
- [x] [Scripts & Configuration for managing and processing LogCollector](https://gitlab.torproject.org/shelikhoo/LogCollectorAncillary)
Here is the list of Resources that would be transferred/migrated:
- [x] VPS that hosts LogCollector(TPA managed)
- [ ] Private CA that manage mutual authentication of LogCollector client and server(need a shared shell environment for Anti-censorship team, maybe TPA? Or we can commit changes to a private git, thus remove the need for shell environment.)
- [ ] ~~A domain name for the LogCollector server(maybe Anti-censorship team? We don't want this domain name to have any discoverable relationship with Tor.)~~
- [x] Git repo to publish the result(Anti-censorship team managed)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/20Documentation about server file2023-10-25T15:46:06ZJacobo NájeraDocumentation about server fileI am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
`...I am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
```
Where is server file? whe i tried it:
ssh: connect to host ip port 22: Connection timed out
lost connection
Thanks, Jacoboshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/21panic: assignment to entry in nil map2023-10-25T15:45:08Zcomputerscotpanic: assignment to entry in nil map```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [d...```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [debug] read_to_chunk(): Read 313 bytes. 313 on inbuf.
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "panic: assignment to entry in nil map"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: panic: assignment to entry in nil map
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: ""
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "goroutine 1 [running]:"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: goroutine 1 [running]:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: " /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "main.main()"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: main.main()
```shelikhooshelikhoohttps://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/pluggable-transports/snowflake/-/issues/40069Snowflake needs outbound proxy support2023-10-25T15:40:24ZtlaSnowflake needs outbound proxy supportFor continued iOS support, we will need to run Snowflake behind a proxy, since with its Go runtime it's way to big to run in a [Network Extension](https://developer.apple.com/documentation/networkextension/packet_tunnel_provider), which ...For continued iOS support, we will need to run Snowflake behind a proxy, since with its Go runtime it's way to big to run in a [Network Extension](https://developer.apple.com/documentation/networkextension/packet_tunnel_provider), which has a hard 15 MByte RAM usage limit.
Currently, Snowflake doesn't seem to support that scenario.
Please point me to the code, if it actually has, so I can understand how to leverage it.
If not, I suggest having a look at Obfs4proxy for reference on how this could be implemented:
https://gitlab.com/yawning/obfs4/-/blob/master/obfs4proxy/obfs4proxy.go#L67-158
Thank you!shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/95Investigate Distributed Snowflake Rollout Issue on proxy2023-10-25T15:24:07ZshelikhooInvestigate Distributed Snowflake Rollout Issue on proxyCurrently, we are encountering a slow rollout in distributed snowflake. We should investigate why.Currently, we are encountering a slow rollout in distributed snowflake. We should investigate why.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://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/pluggable-transports/webtunnel/-/issues/28WebTunnel does not connect2023-10-24T16:35:16ZdinosmWebTunnel does not connectI cannot connect to Tor via WebTunnel. I am using Tor Alpha. My connection log is below.
```
2023-10-24 09:50:15.658 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing...I cannot connect to Tor via WebTunnel. I am using Tor Alpha. My connection log is below.
```
2023-10-24 09:50:15.658 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:22.472 [NOTICE] Renaming old configuration file to "D:\Utils\Tor Browser\Alpha\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
2023-10-24 09:50:36.887 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:36.887 [NOTICE] Switching to guard context "bridges" (was using "default")
2023-10-24 09:50:37.181 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2023-10-24 09:50:37.181 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
2023-10-24 09:50:37.599 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2023-10-24 09:50:37.611 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2023-10-24 09:50:38.348 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2023-10-24 09:50:38.466 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2023-10-24 09:50:38.591 [WARN] Tried connecting to router at [2001:db8:c84d:9331:7c61:633b:6bdb:b352]:443 ID=<none> RSA_ID=945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE, but RSA + ed25519 identity keys were not as expected: wanted 945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE + no ed25519 key but got 719C8B27643CD9283DE52C45112EA61CD45B0D80 + wllgI7D+012eycMYn2wWtIbg+oKDwJgiN5YWjjL5X6o.
2023-10-24 09:50:38.591 [WARN] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 945C8C659224ADD3C8AB99BDA5CB6178B6F55AFE at 2001:db8:c84d:9331:7c61:633b:6bdb:b352:443)
2023-10-24 09:50:38.599 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
2023-10-24 09:50:38.599 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-10-24 09:50:38.968 [WARN] Managed proxy "N/A" process terminated with status code 0
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/17improve descriptor arguments published2023-10-24T08:17:20Zmeskiomeskio@torproject.orgimprove descriptor arguments publishedThis is the extra-info line I see for the bridge documented in the README:
```
transport webtunnel 127.0.0.1:11000 domainname=n97jlbvjwy3iotetc0axrtu3mm7gq1gajqv7-80-78-24-44.sslip.io,path=939e42a2-8f3f-4645-9d7b-8b9be28b157e,port=443,pu...This is the extra-info line I see for the bridge documented in the README:
```
transport webtunnel 127.0.0.1:11000 domainname=n97jlbvjwy3iotetc0axrtu3mm7gq1gajqv7-80-78-24-44.sslip.io,path=939e42a2-8f3f-4645-9d7b-8b9be28b157e,port=443,publicVersion=0.0.1
```
Currently webtunnel is publishing the localhost IP and port where is listening for connections from the http proxy, we might want to publish a different IP address and port there as they will be used to build the bridgeline. The README uses 192.0.3.2:1, but AFAIK we can't use the same IP-port combination for several bridges as tor will consider is the same bridge and ignore the others. We could generate a random IP address from a private range, but maybe is better to put there the public IP address of the domain we are using as front. Any ideas?
I see in the extra-info line `domainname` and `path`, where AFAIK the client expects `url`. I think this is not coming from the code itself, but from `ServerTransportOptions` in torrc. Isn't it? Maybe we can improve the README to document how that is configured to include the `url` option (and fix our public tunnel).
I have some doubts about `publicVersion`, I think is weird to keep that in the bridgeline. rdsys could strip it out, but is pretty hacky. I would love to see https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 solving that problem instead andSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/19Deploy the lox distributor in a staging environment2023-10-23T18:42:33ZCecylia BocovichDeploy the lox distributor in a staging environmentIt would be helpful to have the lox distributor deployed so that we can more easily test the client and work on the UX, as well as give the server side some stress testing before it goes into production.
Related: https://gitlab.torproje...It would be helpful to have the lox distributor deployed so that we can more easily test the client and work on the UX, as well as give the server side some stress testing before it goes into production.
Related: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/93Cecylia BocovichCecylia Bocovich