Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-01-26T13:54:32Zhttps://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.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40131Unix socket support.2023-01-05T17:20:17ZcheakoUnix socket support.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/issues/2keep from-serge tar file history for some time2023-04-20T16:46:50Zmeskiomeskio@torproject.orgkeep from-serge tar file history for some timeSerge sends regularly to polyanthum a tar file with the latest descriptors. In polyanthum we [process](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/store-bridge-tarball-from-serge) the tar and [send it...Serge sends regularly to polyanthum a tar file with the latest descriptors. In polyanthum we [process](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/store-bridge-tarball-from-serge) the tar and [send it](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/sync-to-colchicifolium) with a timestamp to collector. There might be issues with the sending, will be nice to keep a copy of each uploaded tar to collector for some time so we can restore if needed.
Related to: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40026https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40128Give standalone snowflakes guidance on how best to set up their nat2023-03-31T16:56:08ZRoger DingledineGive standalone snowflakes guidance on how best to set up their natAccording to our current broker stats (https://snowflake-broker.torproject.net/debug), we have
```
current snowflakes available: 3021
standalone proxies: 2589
browser proxies: 5
webext proxies: 250
unknown proxies: 177
NAT Types avai...According to our current broker stats (https://snowflake-broker.torproject.net/debug), we have
```
current snowflakes available: 3021
standalone proxies: 2589
browser proxies: 5
webext proxies: 250
unknown proxies: 177
NAT Types available:
restricted: 2512
unrestricted: 386
unknown: 123
```
i.e. most of the snowflakes that we're giving out seem to be standalone ones as opposed to browser extension ones, and also most of the ones we have available to us are behind restricted nat.
It seems to me that the standalone ones are probably in a better position to be behind the good kind of nat (or no nat at all). But does our docker image impose the bad kind of nat on them by default? How come so many standalone proxies are behind restricted nat?
More generally: is there useful guidance we can give people, on setting themselves up with the right kind of nat, presuming they're on a VPS or otherwise on a 'real' internet connection?shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40126Visualize the Snowflake Network2023-03-31T19:00:35ZsereneVisualize the Snowflake NetworkTo further upgrade the main page, we could include a live visualization showing the strength of the Snowflake Network. (in a way which is scrubbed / anonymized of course, which the underlying metrics I believe always are.)
- It can show...To further upgrade the main page, we could include a live visualization showing the strength of the Snowflake Network. (in a way which is scrubbed / anonymized of course, which the underlying metrics I believe always are.)
- It can show how many people are currently helping, how many people are being helped.
- It would further assist in immediately making clear to new visitors what exactly Snowflake is/does, and how they can immediately be involved... whether as a volunteer proxy, as a user, as a dev, as a funder...
- It would cool.
I've not implemented this yet, but it's on my list. It would be an excellent addition to the landing page. See: #40125
I will update this ticket with a screenshot or demo soon.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/106Bridges sharing the same IP should have the same bridge distribution method2024-03-04T15:23:30ZGusBridges sharing the same IP should have the same bridge distribution methodIn the last 'Run a bridge' campaign, Meskio and arma pointed out that having bridges sharing the same IP but using different ports would increase the probability of a censor to discover and block the bridge IP. As the censors are most li...In the last 'Run a bridge' campaign, Meskio and arma pointed out that having bridges sharing the same IP but using different ports would increase the probability of a censor to discover and block the bridge IP. As the censors are most likely blocking bridges by IP and not IP:Port, bridgeDB/rdsys should attribute the same bridge distribution method for bridges with the same IP.
Example: [these new bridges](https://metrics.torproject.org/rs.html#search/sochaczewski) are sharing the same IP but were automatically attributed two different distribution methods (settings, moat).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/13author proper design/readme documents2022-09-21T22:41:17Zn0tooseauthor proper design/readme documentsit's time
- [ ] Overview of how Telegram works, its limits and past failures that formed the way the bot currently works
- [ ] Translation system/i18n, overview on working with gettextit's time
- [ ] Overview of how Telegram works, its limits and past failures that formed the way the bot currently works
- [ ] Translation system/i18n, overview on working with gettextn0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/33bridges.torproject.org retuns odd time for "Last tested: "2023-01-24T18:54:37Ztoralfbridges.torproject.org retuns odd time for "Last tested: "Yesterday I queried https://bridges.torproject.org/status?id=662D4E4DE2C883625C543DFA3C4EE466899E6C85 for the status of a new relay with nickname "hoppel" and got:
```
Last tested: 2022-04-01 01:22:29.996384489 +0000 UTC (17h20m3.267273...Yesterday I queried https://bridges.torproject.org/status?id=662D4E4DE2C883625C543DFA3C4EE466899E6C85 for the status of a new relay with nickname "hoppel" and got:
```
Last tested: 2022-04-01 01:22:29.996384489 +0000 UTC (17h20m3.267273954s ago)
```
The "time ago" looks odd b/c the public bridge was setup about just 2-3 hours ago (using ansible, accidently I run the setup few times in a row at different VPS ip addresses and forgot to not publish the bridge distributor for those tests).