Anti-censorship issues
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues
2021-02-03T14:30:29Z
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/21
Collapse Salmon's social graph into root nodes to preserve privacy
2021-02-03T14:30:29Z
Philipp Winter
phw@torproject.org
Collapse Salmon's social graph into root nodes to preserve privacy
We may be able to build a more privacy-preserving version of Salmon which does not store a social graph on the server.
Quoting [Cecylia's explanation](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/1#note_2707688):
> E...
We may be able to build a more privacy-preserving version of Salmon which does not store a social graph on the server.
Quoting [Cecylia's explanation](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/1#note_2707688):
> Each social group in Salmon is uniquely identified by the root of the invitation tree (the person who was not invited, but joined the system on their own and then invited others). One way to avoid storing social graph data is to only store the bridges known to a social group along with the root user's identifier on the server. A user's social group root identifier will then be included in the tokens stored on the client side, so when a client requests more bridges, they present their social group's identifier. The server then only assigns them bridges known to that group already if possible. Otherwise, if a new bridge is discovered by a member of the group, that bridge is appended to the list of bridges associated with the root identifier at the server.
Let's use this ticket to build a prototype.
Sponsor 30 - Objective 2.3
Cecylia Bocovich
Cecylia Bocovich
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/22
Make the HTTPS distributor's Web interface look like torproject.org
2023-06-08T14:50:36Z
Philipp Winter
phw@torproject.org
Make the HTTPS distributor's Web interface look like torproject.org
We originally wanted to do this for [BridgeDB](tpo/anti-censorship/bridgedb#34322) but we're in the process of retiring the project, so our time is better spent doing this for our reimplementation of the HTTPS distributor.
So far, we do...
We originally wanted to do this for [BridgeDB](tpo/anti-censorship/bridgedb#34322) but we're in the process of retiring the project, so our time is better spent doing this for our reimplementation of the HTTPS distributor.
So far, we don't have a UI for the HTTPS distributor. Perhaps we can start with BridgeDB's UI and simplify it?
Copying @antonela.
Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet
donuts
donuts
https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/4
Make bridgestrap export metrics
2020-11-24T17:03:13Z
Philipp Winter
phw@torproject.org
Make bridgestrap export metrics
If we end up using statsd/graphite to keep track of rdsys metrics, it's trivial to add bridgestrap metrics too. All we have to do is to use the [statsd-client library](https://gitlab.torproject.org/tpo/anti-censorship/statsd-client) and ...
If we end up using statsd/graphite to keep track of rdsys metrics, it's trivial to add bridgestrap metrics too. All we have to do is to use the [statsd-client library](https://gitlab.torproject.org/tpo/anti-censorship/statsd-client) and log whatever we want to add to statsd's time series. Things that come to mind:
* Number of failed/successful tests.
* Execution time of Tor tests.
* Execution time of Web/API requests.
* Number of cache hits/misses.
Adding metrics is very easy, e.g.:
```go
metrics.Inc("bridgestrap.tor.num_dysfunctional_bridges", 1)
```
This line increments the counter for bridgestrap/tor/num_dysfunctional_bridges.
Sponsor 30 - Objective 2.3
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40018
Snowflake uses network continuously on mobile devices
2021-03-20T16:53:00Z
Cecylia Bocovich
Snowflake uses network continuously on mobile devices
Guardian project is working on getting Snowflake working on mobile devices and are having trouble getting Snowflake to stop using the network on command. They've put together [a patch](https://github.com/tladesignz/IPtProxy/blob/feature/...
Guardian project is working on getting Snowflake working on mobile devices and are having trouble getting Snowflake to stop using the network on command. They've put together [a patch](https://github.com/tladesignz/IPtProxy/blob/feature/stop_snowflake/snowflake.patch) file to expose the functions they want. Even after calling stop here, Snowflake continues to poll the broker for proxies indefinitely. See attached log file: [snowflake-go-ios-closing.txt](/uploads/1895eb6575581884d6c61972e45a532d/snowflake-go-ios-closing.txt)
Cecylia Bocovich
Cecylia Bocovich
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/23
Refactor rdsys's domain logic
2021-01-27T18:28:20Z
Philipp Winter
phw@torproject.org
Refactor rdsys's domain logic
[Over here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/3#note_2710432), I asked @cohosh to start reviewing rdsys's domain logic. Let's continue in this ticket, so we can close the big "reimplement BridgeDB" ticket.
[Over here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/3#note_2710432), I asked @cohosh to start reviewing rdsys's domain logic. Let's continue in this ticket, so we can close the big "reimplement BridgeDB" ticket.
Sponsor 30 - Objective 2.3
Cecylia Bocovich
Cecylia Bocovich
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40019
Hello, stun.l.google.com:19302 STUN server is still in the original torrc-def...
2021-02-16T21:58:25Z
amiableclarity2011
Hello, stun.l.google.com:19302 STUN server is still in the original torrc-defaults file of tor-browser-linux64-10.5a2 stun.l.google.com has already been blocked by China's firewall
Hello, stun.l.google.com:19302 STUN server is still in the original torrc-defaults file of tor-browser-linux64-10.5a2 stun.l.google.com has already been blocked by China's firewall. Should I replace stun.l.google.com:19302 with stun.e...
Hello, stun.l.google.com:19302 STUN server is still in the original torrc-defaults file of tor-browser-linux64-10.5a2 stun.l.google.com has already been blocked by China's firewall. Should I replace stun.l.google.com:19302 with stun.ekiga.net in the original torrc-defaults file? What's the port number of STUN server stun.ekiga.net? Thank you very much for your help. I really appreciate it.
https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/issues/3
Add new default bridge and change name of existing one
2020-11-04T19:15:18Z
Philipp Winter
phw@torproject.org
Add new default bridge and change name of existing one
Louis-Philippe VĂ©ronneau generously set up a new default bridge for us.
Louis-Philippe VĂ©ronneau generously set up a new default bridge for us.
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40020
Snowflake server died and had to be restarted
2021-05-20T19:46:07Z
Cecylia Bocovich
Snowflake server died and had to be restarted
I checked the logs, and the only clue I have to this mystery are from /var/log/syslog:
```
Nov 8 00:53:15 snowflake kernel: [19782731.564416] tor invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_
adj=0
No...
I checked the logs, and the only clue I have to this mystery are from /var/log/syslog:
```
Nov 8 00:53:15 snowflake kernel: [19782731.564416] tor invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_
adj=0
Nov 8 00:53:15 snowflake kernel: [19782731.564494] CPU: 0 PID: 10912 Comm: tor Not tainted 5.4.20 #8
Nov 8 00:53:15 snowflake kernel: [19782731.564536] Call Trace:
Nov 8 00:53:15 snowflake kernel: [19782731.564571] dump_stack+0x66/0x8b
Nov 8 00:53:15 snowflake kernel: [19782731.564603] dump_header+0x42/0x200
Nov 8 00:53:15 snowflake kernel: [19782731.564635] oom_kill_process+0xe9/0x110
Nov 8 00:53:15 snowflake kernel: [19782731.564668] out_of_memory+0xfa/0x4a0
Nov 8 00:53:15 snowflake kernel: [19782731.564701] __alloc_pages_slowpath+0x91c/0xca0
Nov 8 00:53:15 snowflake kernel: [19782731.564740] __alloc_pages_nodemask+0x249/0x280
Nov 8 00:53:15 snowflake kernel: [19782731.564777] pagecache_get_page+0xbb/0x220
Nov 8 00:53:15 snowflake kernel: [19782731.564810] filemap_fault+0x56e/0x860
Nov 8 00:53:15 snowflake kernel: [19782731.564842] ? page_add_file_rmap+0x135/0x170
Nov 8 00:53:15 snowflake kernel: [19782731.564892] ? alloc_set_pte+0x17c/0x5e0
Nov 8 00:53:15 snowflake kernel: [19782731.564929] ? xas_load+0x9/0x80
Nov 8 00:53:15 snowflake kernel: [19782731.564974] ? xas_find+0x192/0x1d0
Nov 8 00:53:15 snowflake kernel: [19782731.565005] ? filemap_map_pages+0x16f/0x360
Nov 8 00:53:15 snowflake kernel: [19782731.565062] __xfs_filemap_fault.constprop.24+0x37/0xc0 [xfs]
Nov 8 00:53:15 snowflake kernel: [19782731.565104] __do_fault+0x4a/0x8e
Nov 8 00:53:15 snowflake kernel: [19782731.565135] __handle_mm_fault+0xbc2/0x1110
Nov 8 00:53:15 snowflake kernel: [19782731.565169] handle_mm_fault+0xe7/0x1d0
Nov 8 00:53:15 snowflake kernel: [19782731.566305] __do_page_fault+0x1f5/0x4c0
Nov 8 00:53:15 snowflake kernel: [19782731.567444] page_fault+0x34/0x40
Nov 8 00:53:15 snowflake kernel: [19782731.568571] RIP: 0033:0x55b72cdd7bd0
Nov 8 00:53:15 snowflake kernel: [19782731.569707] Code: Bad RIP value.
Nov 8 00:53:15 snowflake kernel: [19782731.570796] RSP: 002b:00007ffc9a8864e8 EFLAGS: 00010246
Nov 8 00:53:15 snowflake kernel: [19782731.571875] RAX: 0000000000000004 RBX: 000055b7343027c0 RCX: 0000000000000000
Nov 8 00:53:15 snowflake kernel: [19782731.573130] RDX: 0000000000000001 RSI: 000000005fa7417a RDI: 000055b7343027c0
Nov 8 00:53:15 snowflake kernel: [19782731.574265] RBP: 0000000000000000 R08: 000000005fa7417a R09: 000000005fa805c8
Nov 8 00:53:15 snowflake kernel: [19782731.575437] R10: 0000000000000006 R11: 0000000000000000 R12: 0000000000000218
Nov 8 00:53:15 snowflake kernel: [19782731.576585] R13: 000000005fa7417a R14: 0000000000000000 R15: 000055b7343027c0
Nov 8 00:53:15 snowflake kernel: [19782731.577918] Mem-Info:
Nov 8 00:53:15 snowflake kernel: [19782731.579136] active_anon:366133 inactive_anon:16451 isolated_anon:0
Nov 8 00:53:15 snowflake kernel: [19782731.579136] active_file:16 inactive_file:37 isolated_file:0
Nov 8 00:53:15 snowflake kernel: [19782731.579136] unevictable:0 dirty:0 writeback:0 unstable:0
Nov 8 00:53:15 snowflake kernel: [19782731.579136] slab_reclaimable:1604 slab_unreclaimable:10856
Nov 8 00:53:15 snowflake kernel: [19782731.579136] mapped:485 shmem:18773 pagetables:1112 bounce:0
Nov 8 00:53:15 snowflake kernel: [19782731.579136] free:13180 free_pcp:534 free_cma:0
```
This machine should only run proxies and the bridge, it's possible there's a memory leak somewhere.
https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/issues/4
Monitor snowflake-server on our bridge
2020-11-09T19:10:40Z
Philipp Winter
phw@torproject.org
Monitor snowflake-server on our bridge
The other day, snowflake-server crashed: tpo/anti-censorship/pluggable-transports/snowflake#40020
I noticed because my browser's Snowflake told me that it couldn't connect to the bridge but we should also monitor snowflake-server.
The other day, snowflake-server crashed: tpo/anti-censorship/pluggable-transports/snowflake#40020
I noticed because my browser's Snowflake told me that it couldn't connect to the bridge but we should also monitor snowflake-server.
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/5
Deploy bridgestrap on polyanthum
2020-12-14T19:05:17Z
Philipp Winter
phw@torproject.org
Deploy bridgestrap on polyanthum
It's time to deploy a prototype of bridgestrap on polyanthum. Here's what we have to do:
* [x] Create a separate user account for privilege separation. I filed an issue to have the user account "bridgestrap" created: tpo/tpa/team#40081
...
It's time to deploy a prototype of bridgestrap on polyanthum. Here's what we have to do:
* [x] Create a separate user account for privilege separation. I filed an issue to have the user account "bridgestrap" created: tpo/tpa/team#40081
* [x] Deploy the bridgestrap binary and create a systemd script that starts it on boot.
* [x] Create a monitoring target in our monit configuration (see tpo/tpa/team#40080).
* [x] Create a bridgestrap survival guide
* [x] Consider logrotate for bridgestrap's log file.
* [x] tpo/tpa/team#40094
Sponsor 30 - Objective 2.3
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/24
Pool bridgestrap test requests for increased efficiency
2020-11-12T17:56:10Z
Philipp Winter
phw@torproject.org
Pool bridgestrap test requests for increased efficiency
Rdsys creates one connection to bridgestrap for each bridge it wants tested. This is inefficient and we should instead use a testing pool which accumulates bridges until rdsys 1) has N pending bridges to test or 2) T seconds have passed,...
Rdsys creates one connection to bridgestrap for each bridge it wants tested. This is inefficient and we should instead use a testing pool which accumulates bridges until rdsys 1) has N pending bridges to test or 2) T seconds have passed, whichever comes first.
Sponsor 30 - Objective 2.3
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/6
Add field to test result that reveals when a bridge was last tested
2021-01-12T23:16:49Z
Philipp Winter
phw@torproject.org
Add field to test result that reveals when a bridge was last tested
Our per-bridge test result informs the caller if a bridge works and if not, what the error was. We should add a field that tells the caller when a bridge was last tested.
Our per-bridge test result informs the caller if a bridge works and if not, what the error was. We should add a field that tells the caller when a bridge was last tested.
Sponsor 30 - Objective 2.3
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40021
Break from infinite client-broker poll after call to snowflakes.End()
2020-11-23T17:12:51Z
Cecylia Bocovich
Break 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/bridgestrap/-/issues/7
Why does bridgestrap's success rate decrease when we test more bridges?
2022-05-20T17:48:31Z
Philipp Winter
phw@torproject.org
Why does bridgestrap's success rate decrease when we test more bridges?
It appears that as we test more bridges at once, we're seeing more timeouts; or in other words: tor sees more `NEWDESC` events if we give it fewer bridges via `SETCONF`. Here's the setup I used:
1. The results are based on Debian's Tor ...
It appears that as we test more bridges at once, we're seeing more timeouts; or in other words: tor sees more `NEWDESC` events if we give it fewer bridges via `SETCONF`. Here's the setup I used:
1. The results are based on Debian's Tor 0.3.5.10.
2. Here's Tor's config file:
UseBridges 1
ControlPort unix:/tmp/tor-datadir-909036443/control-socket
SocksPort auto
SafeLogging 0
Log info file /tmp/tor-datadir-909036443/tor.log
DataDirectory /tmp/tor-datadir-909036443
ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec /usr/bin/obfs4proxy
Bridge obfs4 192.95.36.142:443 CDF2E852BF539B82BD10E27E9115A31734E378C2 cert=qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ iat-mode=1
Bridge obfs4 193.11.166.194:27015 2D82C2E354D531A68469ADF7F878FA6060C6BACA cert=4TLQPJrTSaDffMK7Nbao6LC7G9OW/NHkUwIdjLSS3KYf0Nv4/nQiiI8dY2TcsQx01NniOg iat-mode=0
Bridge obfs4 37.218.245.14:38224 D9A82D2F9C2F65A18407B1D2B764F130847F8B5D cert=bjRaMrr1BRiAW8IE9U5z27fQaYgOhX1UCmOpg2pFpoMvo6ZgQMzLsaTzzQNTlm7hNcb+Sg iat-mode=0
2. I used `SETCONF` to configure *N* bridges at a time and gave tor a maximum of 60 seconds to receive the respective `NEWDESC` events. If we didn't get a `NEWDESC` event in time, we label a bridge as "timed out." Once we hit the 60 second timeout, bridgestrap immediately `SETCONF`s the next batch of bridges.
For *N*=25, 721 (56.68%) out of 1,272 bridges were reachable (I tested a fairly old cached-extrainfo file). For *N*=100, 542 (42.61%) out of 1,272 bridges were reachable. When increasing the timeout to 120 seconds, the results for *N*=100 improve and we're seeing 673 (52.91%) out of 1,272 functional.
Note that we don't have ground truth about bridge reachability. I don't think the data has many (or any) false positives but it's likely to have false negatives.
~~I'm attaching the bridgestrap logs for *N*=25/60s, *N*=100/60s, and *N*=100/120s.~~ @arma, you want to pay attention to the log lines that begin with `C:` and `S:`. These are control port interactions. `C:` should be limited to bridgestrap doing a `SETCONF` and `S:` is limited to `SETEVENTS`, `ORCONN`, and `NEWDESC`.
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/25
Add parser for bridge descriptors
2021-09-02T14:21:08Z
Philipp Winter
phw@torproject.org
Add parser for bridge descriptors
Rdsys currently only parses extrainfo documents and therefore only knows about pluggable transports. We need to add a parser for bridge descriptors, giving rdsys the ability to also learn about vanilla bridges.
Rdsys currently only parses extrainfo documents and therefore only knows about pluggable transports. We need to add a parser for bridge descriptors, giving rdsys the ability to also learn about vanilla bridges.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40022
Redefine restricted NAT designation to include only symmetric NATs
2020-11-20T16:09:53Z
Cecylia Bocovich
Redefine restricted NAT designation to include only symmetric NATs
See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching for an overview of NAT types and compatibility.
Right now we classify a client NAT as "restricted" if it is symmetrically NAT'd (i...
See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching for an overview of NAT types and compatibility.
Right now we classify a client NAT as "restricted" if it is symmetrically NAT'd (i.e., has an (AO,X) or (AP,X) NAT mapping and filtering behaviour) and also if it has an aggressive filter (AI, AP).
As mentioned as a footnote on the NAT matching wiki page, most (AI,AP) clients will actually work with most (> 80% of) restricted proxies. It's also the case, judging by recent snowflake CollecTor stats, that the majority of clients are (AI,AP). Right now these clients are drawing from the **very small** unrestricted proxies bucket and depleting this resource. I'd like to reclassify these clients as unrestricted so they can pull from the restricted proxy pool. Getting a failed proxy ~20% of the time shouldn't be an issue, especially with the future plans to multiplex in #25723.
This also means that "restricted" is defined differently for clients vs. proxies. (AI,AP) is a restricted proxy, but an unrestricted client.
To do this, I'd like to make the following changes:
- [ ] Have standalone proxies do the probe test instead of using the RFC 5780 method to determine NAT behaviour
- [ ] Redefine (AI,AP) to be an unrestricted NAT type
Cecylia Bocovich
Cecylia Bocovich
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/26
Make type parameter of resource status optional
2020-11-19T23:56:30Z
Philipp Winter
phw@torproject.org
Make type parameter of resource status optional
To learn a bridge's status, one must fetch:
https://bridges.torproject.org/status?id=FINGERPRINT&type=TYPE
We should make the `type` parameter optional. If only the fingerprint is given, the page should list all of the bridge's plu...
To learn a bridge's status, one must fetch:
https://bridges.torproject.org/status?id=FINGERPRINT&type=TYPE
We should make the `type` parameter optional. If only the fingerprint is given, the page should list all of the bridge's pluggable transports.
Sponsor 30 - Objective 2.3
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/8
Make cache timeout configurable
2020-11-20T01:59:55Z
Philipp Winter
phw@torproject.org
Make cache timeout configurable
Bridgestrap currently caches resources one week. We should 1) make this timeout configurable and 2) reduce it to one or two days.
Bridgestrap currently caches resources one week. We should 1) make this timeout configurable and 2) reduce it to one or two days.
Sponsor 30 - Objective 2.3
Philipp Winter
phw@torproject.org
Philipp Winter
phw@torproject.org
https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/27
Take into account bridge-distribution-request field
2021-10-01T18:35:53Z
Philipp Winter
phw@torproject.org
Take into account bridge-distribution-request field
Rdsys currently only considers lines that start with "transport" in cached-extrainfo. We have to make its parser quite a bit smarter, and also take into account the bridge-distribution-request field, which asks BridgeDB/rdsys to assign a...
Rdsys currently only considers lines that start with "transport" in cached-extrainfo. We have to make its parser quite a bit smarter, and also take into account the bridge-distribution-request field, which asks BridgeDB/rdsys to assign a given bridge to a specific distributor.
Sponsor 30 - Objective 2.3
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/19
Make sure browser proxies are terminating connections properly
2023-02-04T09:41:52Z
Cecylia Bocovich
Make sure browser proxies are terminating connections properly
We had a user in #tor mention that their snowflake icon is staying green for hours. If this really is a multi-hour browsing session, that's fine. But if it's due to a closed connection that keeps the snowflake out of commission then we s...
We had a user in #tor mention that their snowflake icon is staying green for hours. If this really is a multi-hour browsing session, that's fine. But if it's due to a closed connection that keeps the snowflake out of commission then we should look into it.