Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-04-04T14:14:51Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/10Use the obfs4 transport2023-04-04T14:14:51ZCecylia BocovichUse the obfs4 transportRight now conjure is working with the min transport. This issue is to add an option to use obfs4.Right now conjure is working with the min transport. This issue is to add an option to use obfs4.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/9Add decoy registration option2022-09-28T18:15:47ZCecylia BocovichAdd decoy registration optionRight now, the conjure PT uses the bidirectional registration API. The original tapdance decoy routing method could be less easily blocked in some places.Right now, the conjure PT uses the bidirectional registration API. The original tapdance decoy routing method could be less easily blocked in some places.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/8Pass assets as arguments2022-09-28T18:15:31ZCecylia BocovichPass assets as argumentsThe conjure client requires an assets/ directory that contains information such as available phantom subnets and the station public key. This might not be necessary when using the bidirectional API, as an updating `ClientConf` can be sen...The conjure client requires an assets/ directory that contains information such as available phantom subnets and the station public key. This might not be necessary when using the bidirectional API, as an updating `ClientConf` can be sent from the station to the client along with the registration. It is necessary when using the decoy routing registraton method.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/7Save phantom registrations for later use2023-04-04T14:15:20ZCecylia BocovichSave phantom registrations for later useExisting phantom registrations can be used in future conjure sessions. This is where the Conjure registration process differs from a Snowflake rendezvous: phantoms are always online and the obfs4, min transport methods use static ports f...Existing phantom registrations can be used in future conjure sessions. This is where the Conjure registration process differs from a Snowflake rendezvous: phantoms are always online and the obfs4, min transport methods use static ports for the connection. Right now the client gets a new phantom IP for every connection. We should look into making these registrations persist to cut down on networking costs.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40150Test Snowflake Client against different types of proxies2022-10-19T00:02:22ZshelikhooTest Snowflake Client against different types of proxiesDuring the discussion about the Russian ISP's block of snowflake based on supported_groups, @arma discussed the possibility of testing the snowflake client against different kinds of proxies to get more detailed info about connectivity.
...During the discussion about the Russian ISP's block of snowflake based on supported_groups, @arma discussed the possibility of testing the snowflake client against different kinds of proxies to get more detailed info about connectivity.
IRC:
```
[5:46:07 pm] <+arma2> shelikhoo: based on the dtls discussion above, it sure seems valuable to me to have a 'matrix of snowflake variants' regression test
[5:46:16 pm] <+arma2> where we try each client (mainly just snowflake-client) against each proxy type
[5:46:29 pm] <+arma2> and maybe do it periodically on our own, or before each release, or from censored places, etc
[5:46:58 pm] <+arma2> because right now we don't even know which combinations are *supposed* to work
[5:47:25 pm] <+arma2> (i mean, 'all of them' are supposed to work, but, you know what i mean :)
[5:48:50 pm] <+shelikhoo> yes, I think we will need to have a few brokers to handle each type of proxy
[5:49:29 pm] <+shelikhoo> and somewhere to run a browser...
[5:49:35 pm] <+arma2> maybe. or a way for the broker to know which proxy each volunteer is using, and a way to request a specific one
[5:50:03 pm] <+shelikhoo> yes. that would require more advanced matching logic
[5:50:07 pm] <+arma2> but yes, maybe a 'regression broker' which is a different broker you use just for this test
[5:50:18 pm] <+arma2> lots of options
[5:50:24 pm] <+arma2> the destination seems worthwhile though, however we get there
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40149Connection Result Feedback2022-06-22T18:55:40ZshelikhooConnection Result FeedbackCurrently, the broker does not receive feedback from the client about whether the Snowflake connection is successful. This means we do not receive feedback from real-world connection attempts. In the last team sync meeting, @arma and I d...Currently, the broker does not receive feedback from the client about whether the Snowflake connection is successful. This means we do not receive feedback from real-world connection attempts. In the last team sync meeting, @arma and I discussed receiving more automated feedback from clients. and one of the ways it could work is by receiving connection feedback info from clients.
IRC:
```
[5:51:16 pm] <+shelikhoo> yes. and better if the broker can track if the connection between proxy and client is actually successful or not
[5:51:29 pm] <+shelikhoo> so that we don't need run separate test
[5:51:42 pm] <+shelikhoo> just observe the real world data from users
[5:52:28 pm] <+arma2> hm! yes, now i want that too :)
```https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/6Setting up alerts for bridge status2023-05-17T17:01:57ZshelikhooSetting up alerts for bridge statusCurrently, the dynamic bridge reincarnation manager may stop working from time to time. We should consider setting up an alert system to be notified whenever something goes wrong.
Tasks:
- [ ] detect anomaly
- [ ] send emailCurrently, the dynamic bridge reincarnation manager may stop working from time to time. We should consider setting up an alert system to be notified whenever something goes wrong.
Tasks:
- [ ] detect anomaly
- [ ] send emailhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40031[Uzbekistan] Number of meek users goes to zero, 2022-05-122023-01-26T13:54:32ZDavid Fifielddcf@torproject.org[Uzbekistan] Number of meek users goes to zero, 2022-05-12It looks like the number of meek users in Uzbekistan suddenly dropped from about 150 to 0 on 2022-05-12. Other transports and relay users appear to be unaffected.
https://metrics.torproject.org/userstats-relay-country.html?start=2021-12...It looks like the number of meek users in Uzbekistan suddenly dropped from about 150 to 0 on 2022-05-12. Other transports and relay users appear to be unaffected.
https://metrics.torproject.org/userstats-relay-country.html?start=2021-12-01&end=2022-06-01&country=uz
![userstats-relay-country-uz-2021-12-01-2022-06-01-off](/uploads/78652074b7398a1658055377dcdbc245/userstats-relay-country-uz-2021-12-01-2022-06-01-off.png)
https://metrics.torproject.org/userstats-bridge-combined.html?start=2021-12-01&end=2022-06-01&country=uz
![userstats-bridge-combined-uz-2021-12-01-2022-06-01](/uploads/2990c2c7a6fa90f09ca6e1f83c51af67/userstats-bridge-combined-uz-2021-12-01-2022-06-01.png)https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/114gettor on AWS S32024-02-27T18:23:26Zmeskiomeskio@torproject.orggettor on AWS S3Do we want to provide AWS S3 links to download TB in gettor?
Thanks to @shelikhoo we have have generic S3 support in the new gettor implementation. AFAIK with AWS we can have links that are generic, so the censor will need to block all ...Do we want to provide AWS S3 links to download TB in gettor?
Thanks to @shelikhoo we have have generic S3 support in the new gettor implementation. AFAIK with AWS we can have links that are generic, so the censor will need to block all S3 if they want to block our downloads.
But this might produce some costs to run it. I'll try to make an estimate with their calculator: https://calculator.aws/ (doesn't seem to work on tor...)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40147Move snowflake-broker to a systemd based setup2023-04-10T19:39:01ZshelikhooMove snowflake-broker to a systemd based setupCurrently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.fr...Currently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.freedesktop.org/software/systemd/man/systemd.service.html#RuntimeMaxSec=) restart.
Edit: remove incorrect info. Thanks @dcf .https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/82Discussion about the possibility of adding PT support to V2Ray to serve the r...2022-06-30T00:00:49ZshelikhooDiscussion about the possibility of adding PT support to V2Ray to serve the role of HTTPT# Adding Tor PT Support to V2Ray itself
The first option is to add PT support directly to V2Ray. In this way, the PT related code will be maintained directly by V2Fly. If a new protocol is added, it can be used as a PT automatically.
It...# Adding Tor PT Support to V2Ray itself
The first option is to add PT support directly to V2Ray. In this way, the PT related code will be maintained directly by V2Fly. If a new protocol is added, it can be used as a PT automatically.
It would be more difficult to add generalized PT support to V2Ray than add a Tor Specific PT support to HTTPT. However, if we can do that correctly, a significant amount of protocols(including future ones) can be supported at no additional cost.
## Teaching PT protocol to V2Ray
Currently, V2Ray does not understands PT protocol. As per the V2Ray convention, the support for PT will be split into components and be made reusable.
In order to add Tor PT protocol support, following Tor specific code will need to be supported in addition to general-purpose PT client support.
* ExtOR protocol
* Socks5-Tor protocol
* PT IPC(environment variable to option mapping)
## Design interactions between Tor and V2Ray
Tor can only transfer 256 characters of information in client connection. However, a V2Ray full configuration file is about 2K - 50 KB long, so there is no way of transferring all the information necessary in the connection parameter itself. So we would need to transfer only the info needed.
Here are some of the candidates:
* Outbound name (Cannot customize connection detail)
* Config file name + Outbound name (Requires external file)
* Outbound Config JSON Content (complex config may be longer than 256 characters)
* Connection specification link(flat option to option config) (requires active maintenance to keep link and settings in sync)
If we just modify HTTPT to work with Tor, it can simply use a Connection specification link, like all other PTs.
## Additional Optional Features lacking
* uTLS support is not currently in V2Ray
# Adding Tor PT Support as a separate program
We can create a separate program that reuses V2Ray's code to create a PT like https://github.com/shadowsocks/v2ray-plugin.
It is easier to add Tor PT support if that part of the code does not need to be subject to ordinary quality control and architecture of V2Ray.
It is worth noting that in this case, this program will require active maintenance. And this program will not be super beneficial parties other Tor communities, so the maintenance cost will not be shared by others.
## Conflict of Interest
@shelikhoo volunteer as the organization representative of Project V(V2Fly) and maintainer of V2Ray outside day job.2022-06-23https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/113Long term project: feedback loop to dynamically adjust bridge pool sizes (ins...2022-12-01T08:24:29ZRoger DingledineLong term project: feedback loop to dynamically adjust bridge pool sizes (inspired by proximax)Now that we have bridgestrap working, and we are ramping up our in-country deployments for assessing which bridges are getting blocked, we're back in position to reach another long-wanted milestone for the bridge distribution system. The...Now that we have bridgestrap working, and we are ramping up our in-country deployments for assessing which bridges are getting blocked, we're back in position to reach another long-wanted milestone for the bridge distribution system. The proximax-inspired bridge distribution "meta-strategy" is simple to explain: keep track of which bridge distribution strategies are effective, and automatically send new bridges toward the strategies that are succeeding.
As described in the "five ways to test bridge reachability" blog post:
"We can define the *efficiency* of a bridge address in terms of how many people use it and how long before it gets blocked. So a bridge that gets blocked very quickly scores a low efficiency, a bridge that doesn't get blocked but doesn't see much use scores a medium efficiency, and a popular bridge that doesn't get blocked scores high. We can characterize the efficiency of a distribution channel as a function of the efficiency of the bridges it distributes. The key insight is that we then adapt how many new bridges we give to each distribution channel based on its efficiency. So channels that are working well automatically get more addresses to give out, and channels that aren't working well automatically end up with fewer addresses."
Many more details in that blog post (https://blog.torproject.org/research-problem-five-ways-test-bridge-reachability/) and in the original research paper (https://www.freehaven.net/anonbib/#proximax11).
In terms of roadmap, here are possible steps.
Phase one, getting the building blocks in place:
* [ ] Pick a utility function for how to assess a given bridge. Start with something simple and then iterate. For example, "current number of users times number of days we've been giving it out and it's been unblocked." A later more complex function might be "for each country where it has users, add up the (# of users in that country times the number of days it's been reachable from that country)." A third iteration might be to assign a per-country weight multiplier based on how much blocking the country is experiencing, how much we want to prioritize that country, etc. Another idea is to look at bandwidth use (more is better) in addition to simple user count.
* [ ] Work with the metrics team to make decisions about the data architecture. Calculating bridge scores involves looking at historical info about bridges, and bridge usage, and bridge reachability. Maybe this is all better done inside onionoo -- and then the rest of the metrics pipeline like relay-search is in a better position to use it too.
* [ ] Pick a composite utility function for how to assess a given distribution stategy given scores for each bridge in its pool. Again start simple, for example "add up the utility scores for each bridge in that pool."
* [ ] Take a step back: Examine the scores we have, and see if it matches our intuition. Retune the utility functions. Put up some ongoing graphs on the metrics pages. The per-strategy summary scores are already useful at this point, to let us and others see which strategies are being effective.
Phase two, automating the feedback loop:
* [ ] Research: based on the above experience, invent utility functions which are both effective and more robust to gaming. In particular, consider how to handle attacks where colluding bridges report inflated user counts, to make a given distribution strategy look better than it really is. And make sure our utility functions converge, rather than e.g. letting one strategy's score grow so it gets more bridges so it grows more and pretty soon it's at infinity.
* [ ] Research: decide how to adjust the allocations for a new bridge: given the existing pool sizes, and the current composite utility functions, which pool should a new bridge be given to? I bet complex systems control theory has some suggestions here.
* [ ] Monitor it all to make sure it continues behaving as we expect.
In particular, one of the key features of this approach is that we can easily add new *external* bridge distribution mechanisms, such as this week's new "Salmon lite" from the Russian hackathon: we give them a "seed" pool of initial bridges, and then their approach sinks or swims on its own without any need for manual evaluation or centralized adjustments at the rdsys level.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/112detect if a bridge is blocked in a certain country by its reported usage2024-02-22T21:57:07Zmeskiomeskio@torproject.orgdetect if a bridge is blocked in a certain country by its reported usageWe know how many IPs from each country the bridge has seeing (extra-infos bridge-ips) as well as the requests for nework statuses (dirreq-*). We can monitor those for each bridge and if they drop in a certain country we can consider this...We know how many IPs from each country the bridge has seeing (extra-infos bridge-ips) as well as the requests for nework statuses (dirreq-*). We can monitor those for each bridge and if they drop in a certain country we can consider this bridge being blocked there.https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/9Timestamp in logfile doesn't use system timezone2022-05-24T18:19:45ZLordOfTheSnowTimestamp in logfile doesn't use system timezoneI am running a Snowflake docker container. The host has it's timezone set to CEST (= UTC+2).
However the output in the logfile is always in UTC, even when setting the container's TZ explicitly to CEST (Europe/Berlin) too. Moreover there...I am running a Snowflake docker container. The host has it's timezone set to CEST (= UTC+2).
However the output in the logfile is always in UTC, even when setting the container's TZ explicitly to CEST (Europe/Berlin) too. Moreover there is not output of the logfile's TZ so it's not immediately clear what the real time of the output was.
`2022/05/18 14:03:18 In the last 1h0m0s, there are 5 connections. Traffic Relayed ↑ 121 MB, ↓ 121 MB.`
It would make things easier if the container uses the host's TZ or at least the one set in the container by an environment variable.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/5Write documentation on how it is working2023-04-11T18:29:41ZGabagaba@torproject.orgWrite documentation on how it is workingAdd documentation on how it is working, the design, architecture and anything we need for it to be running (including survival guide).
- [ ] bridge survival guide
- [ ] point of contact for conjure station
- [ ] brief summary of archite...Add documentation on how it is working, the design, architecture and anything we need for it to be running (including survival guide).
- [ ] bridge survival guide
- [ ] point of contact for conjure station
- [ ] brief summary of architectureCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/80is moat distributing bridges marked as blocked in russia?2024-03-07T18:10:20Zmeskiomeskio@torproject.orgis moat distributing bridges marked as blocked in russia?Someone has reported that moat/bridgedb is distributing bridges marked as blocked in russia (e.g. https://metrics.torproject.org/rs.html#details/1807BF9A521468998385F179DDBF928D2482A62C).Someone has reported that moat/bridgedb is distributing bridges marked as blocked in russia (e.g. https://metrics.torproject.org/rs.html#details/1807BF9A521468998385F179DDBF928D2482A62C).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/team/-/issues/79Help operators to test their bridges in China2023-10-11T12:18:22ZGusHelp operators to test their bridges in ChinaI saw some engagement with the new metrics "blocklist" info. I think having that info displayed for other countries like China would be good for the bridge operator community, as many of them don't know that their bridges are blocked.
A...I saw some engagement with the new metrics "blocklist" info. I think having that info displayed for other countries like China would be good for the bridge operator community, as many of them don't know that their bridges are blocked.
As this would require some integration in rdsys/metrics/probetest and more work for the AC team, we could start small. @meskio and @shelikhoo suggested of writing a short howto to be published in the Support portal to help operators to test manually their bridge if it's blocked in China.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40137Automated LoadBalanced Tor Snowflake Server Deployment System2022-10-12T18:46:02ZshelikhooAutomated LoadBalanced Tor Snowflake Server Deployment SystemWe are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things t...We are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things to make it easier for other organizations to run the Snowflake server.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/109bridge DB changes BridgeDistribution method for an already established relay2024-03-04T15:19:21Ztoralfbridge DB changes BridgeDistribution method for an already established relayI removed yesterday the line
```
BridgeDistribution email
```
from torrc of https://metrics.torproject.org/rs.html#details/8311FFDEFB310BD65393D0B21EB8D0F0A867BB9E:
```
root@uhu:~# ls -l /etc/tor/torrc
-rw-r--r-- 1 root root 462 Apr 28 ...I removed yesterday the line
```
BridgeDistribution email
```
from torrc of https://metrics.torproject.org/rs.html#details/8311FFDEFB310BD65393D0B21EB8D0F0A867BB9E:
```
root@uhu:~# ls -l /etc/tor/torrc
-rw-r--r-- 1 root root 462 Apr 28 17:28 /etc/tor/torrc
```
and realized now that the "Bridge distribution mechanism" changed to "settings".meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40132Discussion: libp2p expansion.2022-05-06T00:48:32ZcheakoDiscussion: libp2p expansion.I've always wanted to spin up my own p2p networks. Perhaps you don't agree that anyone should be able to share in one network with islands for each client program. I believe tor is mutually beneficial to this goal. I've studied arti a...I've always wanted to spin up my own p2p networks. Perhaps you don't agree that anyone should be able to share in one network with islands for each client program. I believe tor is mutually beneficial to this goal. I've studied arti and am sad that it doesn't yet support the full for protocol. It looks like there just may be enough there to leach off of tor bridges. That's not the kind of good-natured application I'm interested in.
The libp2p supporters seem uninterested in anything other than a software as a service model. They are uninterested in any p2p network that could stand on its own.
I've looked at snowflake and see that it doesn't currently meet my needs, but it's close.
The kind of application I would build is for playing cards/chess, message boards and sharing doom demo files/high scores. Users would try and be connected all the time, but some would connect for a few hours every day.
The problem tor solves is nat traversal. It would be nice if bootstrapping was also available. At the start of each network there is only one or two nodes. libp2p solves this problem with a "global" DHT, with each program supporting this DHT even if there is only one client connecting there will be nodes running a completely different program but they will serve out the DHT with data from a host that may be offline ATM.
I believe snowflake could be improved in two main ways. 1. Is for the broker to be generic enough for any application to use it. 2. Is for client to proxy connections to be build on top of libp2p.
I envision a future where libp2p clients expand tor DHT and network in exchange for being a rally point for beginner p2p networks.