The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-16T14:20:15Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40885dual stack bridges only publish an IPv4 bridge line2023-11-16T14:20:15Zdzwdzdual stack bridges only publish an IPv4 bridge lineBridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919...Bridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919d3128646d85c75d08338bea4b31bffa/src/feature/client/transports.c#L1724-1732
@arma checked the extra-info descriptor of one of my (dual stack) bridges and confirmed it only used its IPv4 address in the transport line. I don't see any IPv6 users either, but that's just anecdotal evidence. I think this has the potential to add a lot of new bridge address to the pool, which would be pretty neat from an anti-censorship perspective.
Right now I'll try to patch a bridge of mine to publish two transport lines in extra-info, one per IP version, and see if that breaks anything. If it doesn't, I can submit a MR after !782 gets merged (it affects the same area of the code).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42161"Unexpectedly high use successes counts", maybe one of reasons why users pref...2023-12-15T20:22:47Zcypherpunks"Unexpectedly high use successes counts", maybe one of reasons why users prefer to snowflake-01?```
yyyy-mm-dd 01:27:10.293 [NOTICE] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (17.000000/16.000000) for guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72) (on Tor ...```
yyyy-mm-dd 01:27:10.293 [NOTICE] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (17.000000/16.000000) for guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72) (on Tor 0.4.7.15 505ec7a64720e065)
yyyy-mm-dd 01:37:30.395 [NOTICE] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (23.000000/22.000000) for guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72) (on Tor 0.4.7.15 505ec7a64720e065)
yyyy-mm-dd 02:43:42.139 [NOTICE] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (39.000000/38.000000) for guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72) (on Tor 0.4.7.15 505ec7a64720e065)
```
TBB Version: 12.5.6 (based on Mozilla Firefox 102.15.1esr) (32-bit)
All three "Bug:" output lines are about snowflake-01, no snowflake-02 at all.
I don't know how to reproduce this phenomenon but I think maybe it is important for debug why [seem users prefer to snowflake-01](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000317.html).meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/network-health/team/-/issues/318'Running' flag for counting bridges and network size2024-03-27T09:38:57ZGus'Running' flag for counting bridges and network sizeRdsys is ignoring 'running' flag[1] and some operators are stopping to expose their ORPort[2].
It means that more bridges will appear as offline in Metrics website, while they are perfect fine and being distributed.
I wonder if this wil...Rdsys is ignoring 'running' flag[1] and some operators are stopping to expose their ORPort[2].
It means that more bridges will appear as offline in Metrics website, while they are perfect fine and being distributed.
I wonder if this will affect the number of bridges that are being counted:
https://metrics.torproject.org/networksize.html
From Reproducible metrics:
>Relay flags: Parse relay flag from the "s" line. If there is no "Running" flag, skip this entry. This ensures that we only consider running bridges.
https://metrics.torproject.org/reproducible-metrics.html#running-bridges
[1] https://forum.torproject.org/t/orport-127-0-0-1-auto/8470/2 and https://lists.torproject.org/pipermail/tor-project/2023-June/003642.html
[2] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
(cc @gaba @hiro as this can impact on sponsors indicators.)HiroHirohttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/156add support for webtunnel bridges2024-02-12T12:46:44Zmeskiomeskio@torproject.orgadd support for webtunnel bridgeshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/https://gitlab.torproject.org/tpo/core/arti/-/issues/717arti-based obfs4 quick reachability monitor2024-03-27T09:38:10ZRoger Dingledinearti-based obfs4 quick reachability monitorIn the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down ...In the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down / get blocked. One goal is to notice quickly enough that we can use the reachability result in the "bridge subscription" approach (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42) where clients auto-ask for a replacement when one of their bridges goes down.
* [ ] Part one, a feature replacement for bridgestrap. That is, we need to take in a set of bridge lines to test (e.g. via an http post from rdsys, but we can do that interface however both sides like), launch connections to them, learn success or failure, and report it both in response to the request from rdsys and also write it out to a file like the ones here: https://collector.torproject.org/recent/bridgestrap/
* [ ] Part two, the new feature: we want to learn, for each bridge that we think is currently up, the moment that it goes down. The goal is that clients will start coming to rdsys asking for a replacement bridge when they think one of their bridges goes down, and we want rdsys to already have our 'ground truth' answer by the time the client makes that request. The naive approach would be to connect to each bridge every 10 seconds or something using the 'part one' approach from above. But I think the better option is to *hold open* connections to each bridge, and then notice when a connection breaks. We will still be subject to TCP issues where sometimes it takes a while to notice a broken connection, but this approach is a low-cost way to get results within a 60-ish second response time range.
Some details that make 'part two' more complicated than we might first think:
* We still need to launch new connections every so often too, to detect the case where the bridge stays up for existing connections but somehow gets firewalled for new ones. How often to launch those connections is a parameter we should explore, to find a good balance between being thorough vs limiting our overall connection volume.
* Can the obfs4proxy tool handle hundreds or thousands of client connections, or does something fail at that scale? I don't know the answer, but if we discover scaling issues, we should either debug and resolve them, or maybe we work around them and use them as motivation to switch to the "arti runs a rust obfs4 thread" model that we already want to get to eventually.
* If we simply make a connection to an obfs4 bridge and then try to hold it open, the bridge will expire and close that connection after a few minutes because it has no circuits on it. So we need to come up with a suitable trick for convincing the bridge to not expire the connection. Is making a one-hop circuit and leaving it open enough, or does it get expired after a while? How about if you put a dir stream on it? Worst case we can make a two-hop circuit, but it would be unfortunate if that's our best option: if we pick a new second hop each time, we undermine our bridge enumeration defenses (strategy 2 on https://blog.torproject.org/research-problems-ten-ways-discover-tor-bridges/), whereas if we pick one relay to use every time (e.g. Serge), everything fails if that relay goes away for a bit.
The eventual deployment vision is that (a) we run this tool in a safe uncensored location, where the goal is to get ground truth about upness; if it scales well we run one to test every bridge, or if needed we run a farm of them where each instance handles its fair share of the bridges, and then (b) we run one of these tools inside each censored area, where it does tests on demand and we only give it an address to test if our uncensored location says it's up but a threshold of clients have come to us saying it's down in their location.https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40019Calculate effectiveness score for individual bridges and then aggregate score...2023-10-02T08:41:13ZRoger DingledineCalculate effectiveness score for individual bridges and then aggregate scores for bridge strategiesThis is the metrics-side ticket for the overall project which is documented in https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/113
Specifically, from the metrics side I want the ability to loop through a bridge's past, ...This is the metrics-side ticket for the overall project which is documented in https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/113
Specifically, from the metrics side I want the ability to loop through a bridge's past, computing a daily score for it (that is, a score for each of its past days).
We'll want to experiment with what exactly goes into the score (that is, I expect we will change our minds a bunch of times over the coming years), but maybe there are some approaches here that are quite easy from the metrics perspective and we should start there. For example, how about if we compute a score for each bridge for each day, where today's score is only a function of information from today and yesterday. In terms of specific state we would track a daily number which is "how many days the bridge has been published at this address and running for most of the day and with this distribution strategy and not thought to be blocked anywhere" and then the score for the bridge would be "today's number of users times number of days since first becoming available."
Variations include
* doing per-country scores, where we only count users reported from that country, and we only consider it blocked if we think it is blocked from that country
* a simple memoryless snapshot, where we treat the "number of days available" as simply 1.
Then once we have a few versions of the per-bridge scores, the next step is to sum up the bridge scores by distribution strategy, and to average the bridge scores by distribution strategy, both for a global count and also a per-country count, to see what patterns emerge.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40074plot snowflake proxy metrics2023-09-25T17:07:41Zmeskiomeskio@torproject.orgplot snowflake proxy metricsWill be nice to have snowflake proxy metrics in the website. We could provide them by country, by nat type and by implementation.
We already have that kind of graphs in grafana, but those are not publicly visible.Will be nice to have snowflake proxy metrics in the website. We could provide them by country, by nat type and by implementation.
We already have that kind of graphs in grafana, but those are not publicly visible.https://gitlab.torproject.org/tpo/community/relays/-/issues/48Suggest alternative ways to volunteer2022-07-26T16:55:17ZWofWcawofwca@protonmail.comSuggest alternative ways to volunteerFor example, suggest setting up a conventional bridge (or a regular relay), https://community.torproject.org/relay/
It's especially useful when the extension can't work (due to censorship).For example, suggest setting up a conventional bridge (or a regular relay), https://community.torproject.org/relay/
It's especially useful when the extension can't work (due to censorship).https://gitlab.torproject.org/tpo/web/manual/-/issues/118Add dnstt pluggable transport2022-03-27T16:09:26ZGusAdd dnstt pluggable transportAs Tor Browser will have dnstt PT support (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001), we need to:
* [ ] Add dnstt to the pluggable transports table - https://tb-manual.torproject.org/cir...As Tor Browser will have dnstt PT support (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001), we need to:
* [ ] Add dnstt to the pluggable transports table - https://tb-manual.torproject.org/circumvention/
* [ ] Add dnstt when we list all PTs supported in Tor Browser - https://tb-manual.torproject.org/circumvention/
This should be done only when dnstt is shipped in Tor Browser.
Ref: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40859https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40465Add dnstt bridge strings2023-01-05T13:12:07ZPier Angelo VendrameAdd dnstt bridge stringsWe are going to support a new transport: [dnstt](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001).
Therefore, we should also add new bridge strings for this PT.We are going to support a new transport: [dnstt](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001).
Therefore, we should also add new bridge strings for this PT.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40859Add support for dnstt on TorSettings and about:preferences2023-01-05T16:17:16ZPier Angelo VendrameAdd support for dnstt on TorSettings and about:preferencesPlease add support for the new dnstt pluggable transport on Tor Browser (i.e., add all the relevant information on `TorSettings.jsm` to manage it, and on `about:preferences`, to make it selectable by users).Please add support for the new dnstt pluggable transport on Tor Browser (i.e., add all the relevant information on `TorSettings.jsm` to manage it, and on `about:preferences`, to make it selectable by users).https://gitlab.torproject.org/tpo/core/tor/-/issues/40584Feature request: do not include the Bridge line into the server descriptor f...2022-08-24T14:42:21ZtoralfFeature request: do not include the Bridge line into the server descriptor for private bridgesWhilst I like the info and the graphs at metrics.t.o, I do not want to share the secret of a private bridge with anybody.
This would allow me to replace "0" with "bridge".Whilst I like the info and the graphs at metrics.t.o, I do not want to share the secret of a private bridge with anybody.
This would allow me to replace "0" with "bridge".https://gitlab.torproject.org/tpo/core/tor/-/issues/40578Let bridge users choose to only reach their first working bridge2024-02-28T17:55:43ZRoger DingledineLet bridge users choose to only reach their first working bridgeWe have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is...We have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is loud, wasteful, and maybe even dangerous.
In Snowflake (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651) we are heading toward a world where Tor Browser users have k snowflake bridge lines, one per destination bridge, in order to scale up and improve resiliency. But the Snowflake people worry that doing more than one-ish Snowflake connection will be wasteful (since each connection involves a domain front, a stun connection, a webrtc handshake, etc) and also it will stand out on the network. So they are considering having Tor Browser choose just one Snowflake line at random for each user, which helps with the scaling but it discards all the resiliency features that we would be so close to getting.
I think the answer in both these cases is that we want an option in Tor that makes you only try to fetch bridge descriptors from the bridges you actually hope to use.
I expect the main two parts of this change will be:
* When considering launching a bridge descriptor fetch, decide if you would call this bridge one of your primary guards if it worked, and if not, don't fetch.
* As soon as any bridge fails, immediately go through and see if you need to launch any new descriptor fetches (because otherwise you could end up in a situation where your existing bridges failed and you aren't trying any new ones yet).
(I do think we want to retain the existing "try them all" behavior as an option too (maybe even the default? that's a decision we should make), first for the people who use bridges for connectivity because it gives you the best connectivity, and second because we use the "try them all" functionality in e.g. bridgestrap.)Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/web/community/-/issues/250snowflake: add debian package as installation method2022-08-03T01:37:40Ztxt.filesnowflake: add debian package as installation method<!--
* Use this issue template for suggesting new docs or updates to existing docs.
-->
### Problem to solve
<!-- Include the following detail as necessary:
-->
* On debian its a good idea to use the package manager instead of docker/a...<!--
* Use this issue template for suggesting new docs or updates to existing docs.
-->
### Problem to solve
<!-- Include the following detail as necessary:
-->
* On debian its a good idea to use the package manager instead of docker/ansible/self-compilation
* debian has a snowflake-proxy package
### Further details
<!--
* Include use cases, benefits, and/or goals for this work.
* If adding content: What audience is it intended for? (What roles and scenarios?)
-->
* https://packages.debian.org/search?keywords=snowflake%2Dproxy
### Proposal
<!-- Further specifics for how can we solve the problem. -->
Add installation via debian packages to `content/relay/setup/snowflake/standalone/contents.lr`.
### Who can address the issue
<!-- What if any special expertise is required to resolve this issue? -->
Anyperson able to write text.
### Other links/references
<!-- E.g. related Tor issues/MRs -->https://gitlab.torproject.org/tpo/web/support/-/issues/276[Tor Bridge] Introducing a seperate page for Tor Bridge2023-05-11T18:34:15ZMelroy van den Berg[Tor Bridge] Introducing a seperate page for Tor BridgeMy proposal is to add a separate page for "**Tor Bridge**", which should also be visible in the menu:
![image](/uploads/185cd4e6ed89c694ee4aab4028a0584c/image.png)
I think new users definitely do _not_ know where to look for, I won't ...My proposal is to add a separate page for "**Tor Bridge**", which should also be visible in the menu:
![image](/uploads/185cd4e6ed89c694ee4aab4028a0584c/image.png)
I think new users definitely do _not_ know where to look for, I won't think about looking at 'relay operators'. Since that name is too ambitious in my opinion anyway.
Please consider my proposal! Especially since you need more Tor Bridges on the network, why not make the documentation more clear???
Regards,
Melroy vd Berghttps://gitlab.torproject.org/tpo/network-health/analysis/-/issues/15Figure out where our bridges are in relationship to our exits2022-03-04T13:03:42ZCecylia BocovichFigure out where our bridges are in relationship to our exitsI'm triaging some core/tor tickets today and came across https://gitlab.torproject.org/tpo/core/tor/-/issues/2998. Regardless of what the current behaviour of tor is, it seems like a good idea to check up on where our bridges are and who...I'm triaging some core/tor tickets today and came across https://gitlab.torproject.org/tpo/core/tor/-/issues/2998. Regardless of what the current behaviour of tor is, it seems like a good idea to check up on where our bridges are and who owns them in relationship to our exits. A second outcome of this would be coming up with desirable behaviour or a policy on which bridges can be used with which exits so that the network team can implement it.
So, more concretely:
- How many bridges are in the same /16 of each of our exits?
- Which entities (orgs, individuals, etc) are running both bridges and exits?
- What behaviour should tor have when building circuits? (Should we care about the bridge/exit being in the same /16? owned by the same people?)
- What should our policy be on allowing people to run both bridges and exits?https://gitlab.torproject.org/tpo/network-health/team/-/issues/115Collect potential use cases for Grafana dashboard(s)2022-02-28T14:18:16ZGeorg KoppenCollect potential use cases for Grafana dashboard(s)We should start collecting use cases that are already covered by Grafana dashboards (or are about to be covered) and those which would be interesting for different stakeholders.
We can start in this ticket but I am wondering whether we ...We should start collecting use cases that are already covered by Grafana dashboards (or are about to be covered) and those which would be interesting for different stakeholders.
We can start in this ticket but I am wondering whether we should just add a page with that information in our wiki instead.
/cc @hiro @gus @cohosh @meskio @gabahttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40009Show an aggressive user count estimate alongside our conservative user count ...2023-01-27T16:23:00ZRoger DingledineShow an aggressive user count estimate alongside our conservative user count estimateOn our various user graphs on the metrics site, we show a user count that assumes many users are online all day. In countries where many Tor users go online briefly to use Tor and then disappear again (e.g. from modems, internet cafes, e...On our various user graphs on the metrics site, we show a user count that assumes many users are online all day. In countries where many Tor users go online briefly to use Tor and then disappear again (e.g. from modems, internet cafes, etc), our approach means that our user counts in those countries is an underestimate -- by as much as an order of magnitude.
We picked that approach originally because we wanted to be publishing a clearly defensible number, but also because at the time most of our users were on good internet connections (so it wasn't so clearly wrong at first).
I find myself explaining this potential inaccuracy every time I'm showing the graphs to funders. And in the anti-censorship space, I'm often talking to them about exactly the countries where people don't typically leave their Tors running 24/7 on good internet connections.
So my proposal here is to have a "high water mark" line on the user count graphs, to go with our current "low water mark" line. The reality is that the true user count lies somewhere between these two lines, and we don't know where.
Now, there are several steps remaining:
* How do we calculate our current numbers? Right now the way we get the number is to take the total number of users that we would have if every consensus fetch were made by a different user, and divide it by 10, on the somewhat random assumption that 2/3 of the requests are from repeat users. See https://gitweb.torproject.org/metrics-web.git/tree/src/main/resources/doc/users-q-and-a.txt : "We put in the assumption that the average client makes 10 such requests per day. A tor client that is connected 24/7 makes about 15 requests per day, but not all clients are connected 24/7, so we picked the number 10 for the average client. We simply divide directory requests by 10 and consider the result as the number of users. Another way of looking at it, is that we assume that each request represents a client that stays online for one tenth of a day, so 2 hours and 24 minutes."
* How should we calculate these new lines? [The simple version] We take the high water mark as this number before we divided it by 10, and take the low water mark as this number divided by 15.
* How should we calculate these new lines? [The complex version] We might be able to improve the high water mark accuracy based on e.g. looking at the number of IP addresses and deciding that if there are a small number of IP addresses, then probably there are a smaller number of users. But I would be wary of trying to get too smart at this stage -- really we want a new project to reassess whether we're counting accurately and if there's something fundamentally smarter we can do, and that's a different ticket.
* How do we communicate these new lines on our graphs? Two lines of different colors? A shaded area in between them? This is in part a @UX question (cc @duncan, @nah), and it gets even more complex when we consider the graphs that show more than one curve at once (e.g. https://metrics.torproject.org/userstats-bridge-transport.html).Metrics OKRs Q3-Q4 2022HiroHirohttps://gitlab.torproject.org/tpo/web/community/-/issues/219[Proposal] Add new "Circumvention" or "anti-censorship" section2024-03-05T19:10:46ZGus[Proposal] Add new "Circumvention" or "anti-censorship" sectionBack in 2018, when we first drafted the Community website, we didn't have the anti-censorship team.
I think we could have a dedicated section for anti-censorship team activities that volunteers could help us (beyond running bridges):
1....Back in 2018, when we first drafted the Community website, we didn't have the anti-censorship team.
I think we could have a dedicated section for anti-censorship team activities that volunteers could help us (beyond running bridges):
1. Help us to detect censorship: run emma, marco, and other censorship analyzers
2. Contribute to Metrics timeline to document internet censorship around the world
3. Other ideas?https://gitlab.torproject.org/tpo/network-health/team/-/issues/70Come up with criteria for extending our bad-relay tools to bridges2022-02-28T14:17:56ZGeorg KoppenCome up with criteria for extending our bad-relay tools to bridgesBridges are relays, too, but we don't monitor any of them for potential bad activity yet. While I think, in general, the bad relay criteria in our wiki apply to bridges, too, (where it makes sense, of course) we might want to take the di...Bridges are relays, too, but we don't monitor any of them for potential bad activity yet. While I think, in general, the bad relay criteria in our wiki apply to bridges, too, (where it makes sense, of course) we might want to take the difference to public relays into account. We should come up with a set of things to look for in this ticket and then I can file follow-up tickets in the respective projects given that we have different tools for different purposes.
/cc @meskio @cohosh @arma