[tor-relays] Tor Relay Meetup #Fosdem Notes

[gus]

Hello,

Last Saturday, a group of 30 - 40 operators joined the Tor Relay
Operator meetup.

Thank you all for joining the event!

Our next online meetup will happen on March 5th, 2000 UTC.

Gus

## Fosdem Meetup Notes

* Bridges campaign update:

"When we started the campaign on November 17, 2021, the Tor network had
approximately 1,200 running bridges. The Tor network now has 2470
running bridges, i.e., the number of Tor bridges has almost doubled!"
https://blog.torproject.org/wrapping-up-bridges-campaign/

* Gamification project update:
  - Survey Insights for Tor Relay Operators:
https://gitlab.torproject.org/tpo/community/relays/-/issues/31

* EOL 0.3.5 removal:

"Tor 0.3.5.x is unsupported beginning tomorrow, 02/01/2022. We should
contact the relay operators still on it where possible to get them
upgraded and then after a couple of weeks (4 maybe) remove the remaining
relays from the network (see: #56 (closed) for previous work in that
area)."

https://gitlab.torproject.org/tpo/network-health/team/-/issues/171

* New texas relay operator group? are there others? CCCS?

"We are just a small provider trying to help out the community. We
believe that privacy is a fundamental right for everyone. We hope to
make the internet a better place by deploying privacy based tools for
everyone to use.Checkout stormycloud.org for additional information."

* torservers.net reanimation continues. New website (feedback welcome)
is online: https://torservers.net/
Thanks Leibi, qbi and others for the work!

### Q&A session

  * Who runs Tor relays today? Do we need more transparency? (no mic)
     * Yes, we need more transparency. Gus describes a proposed "community mapping" exercise where we learn who has links / connections to other relays.

  * Best providers for exit nodes?
      * For exits, I can recommend terrahost.no They are based in Norway, have unmetered offers and allow exits with a reduced policy in their Terms of Service
      * See: https://community.torproject.org/relay/community-resources/good-bad-isps/
      * Would recommend avoiding hetzner, ovh, frantech, buyvm, there are too many relays there already.

  * Are there any plans for AS-aware tor circuit creation? (Kristian - lokodlare)

Not currently -- the AS-aware Tor designs (like Raptor and following)
are cool but have a bunch of big open questions and unresolved potential
vulnerabilities too. So, a great research area, but comes with too many
security tradeoffs currently. For a cool recent attack paper in the
area, check out: https://www.freehaven.net/anonbib/#tempest-pets2018

  * Are there plans on improving tor prometheus metrics? (more metrics: uptime, bandwidth, ...)

It turns out the DNS metrics we had were buggy and not so useful. So
there is some work to improve the accuracy / usefulness of the current
metrics.
https://gitlab.torproject.org/tpo/network-health/team/-/issues/175

  * is C tor dead in terms of new features like this? (all dev capacity goes into rust only?)

C tor is going to be deprecated over time, but the Arti roadmap involves
not getting to relays for years, so there will be an interim period
where we're wishing we could deprecate the C-Tor relay side yet there is
no Arti relay side replacement yet.

  * will arti implement the control spec (compatibility with stem)

no, at least not as it currently is. arti wants to be a library you can link in

  * Is the GeoIP location implementation for relays based on ASNs or
actual country-based IP blocks. One relay operator's server is located
in Japan but the AS seems to be American so the location is listed as
the US.

We switched from Maxmind GeoIP to IPFire in the past year.

  * Are there instructions for how people can report bugs to IPFire?

Yes, look at https://forum.torproject.net/t/tor-relay-search-showing-location-of-some-relays-incorrectly/1331
We had an example where a relay operator requested a change from IPFire, and it seems to have gone surprisingly smoothly and easily.

  * MCH:
There will be a real in-person hacker con this summer, MCH
https://mch2022.org/, with at least one Tor relay operator known
attending and at least one Tor developer known attending.

  * Is running a Snowflake proxy as useful as a (obfs4) bridge?

If you have a static IP address, maybe the obfs4 bridge is smarter?
Since the Snowflake model involves having many transient proxies.

  * Are there timelines for IPv6 only Tor or Bridge families?

tor 0.4.8.x will get MyFamily support for bridges according to Nick (C tor)
https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families.md

  * Would it be a good idea to run a web-server on the same computer as a tor bridge?

Because it would introduce collateral damage? Maybe yes in theory, but
in practice these days no. Russia and China block bridges by IP address
in a quite automated way and they don't seem to care what else is on
that computer. Mostly these censors find bridges not by looking at
network traffic, but by pretending to be users showing up to
bridges.torproject.org. So the censors who try to build blocklists
aren't even looking much at the addresses they block.

  * will arti implement the control spec (compatibility with stem)
    * Answer: I think I've heard that it probably won't, or at least not entirely

  * Is it bad to have too many exit relays in one country? And how many is too many?

    * Norway and the US and DE seems to be quite saturated already with exit relays:

    NO - 37, 481 MiB/s Tor metrics numbers
    US - 536, 4898 MiB/s
    DE - 329, 8206 MiB/s

    See: https://metrics.torproject.org/rs.html#aggregate/cc https://nusenu.github.io/OrNetStats/

  * Getting fast relays in Japan is challenging because of how we measure bandwidth weights. Is sbws moving forward? How about a newer bwauth design to make use of better geo-relay-distribution? 

  * Will rust tor solve the multiple CPU core issue (no more multiple tor instances required on a multi core machine)?

Answer: Hopefully yes, arti is multithreaded, but not as fast as C tor yet

  * Is stem unmaintained? Yes.
  * Damian no longer working on stem?

I believe that Damian is no longer actively developing stem, but
that he is maintaining it, in the sense that if you submit a patch he
might take it, or if you submit a security issue he'll probably look at
it.

 * How far away are we from rust tor support relays? will that also be called arti or is arti just the tor client functionality?
 * How far away are we from a first tor browser alpha using arti?

Arti roadmap says it should be "ready for production use" in september 2022, but that's without anti-censorship stuff and onion service support.

 * Russia has blocked Tor relays? Tor is now pretty essential for Russians. Is speed important there? Lower latency is really useful when you're using Tor.

Compare Russia to China -- China grows its internal network capacity,
but not its external network capacity, and over time it becomes more fun
to use Chinese services in China, and less fun to use external services
in China. Will Russia go that route? We'll see. Hopefully not for a
while.

 * How to get more Tor advocacy in each of our local areas? 
Seems like you read about bad people using the internet but not enough about why Tor is important.
 
 * Who runs bw authorities? How could we get one in asia?

They are the services that pick weights for relays in the consensus, so
they are trusted in a similar way to how directory authorities are
trusted. So, right now they're run either *by* the dir auth operators,
or there's a 1:1 trust relationship from dir auth operator to bwauth
operator. Putting a bwauth in Asia would probably just measure all the
relays as slow. And part of that is because of our sub-optimal
congestion control design in Tor right now, which Mike is working on. It
seems wise to wait until Mike has his fix in place, and then we can
understand how much of the "geographic diversity is slow" problemwe've
fixed, and how much of it remains.

* SysAdmin 101 workshop

Gman discusses a proposed idea on teaching relay operators about how to
sysadmin properly, how to make decisions about bare metal vs VM, how to
get time synchronization working right, all of the things that relay
operators need better intuition about. General consensus is yes this is
a good idea and could benefit a lot of people. Gman requests suggestions
for most important material and topics.

https://gitlab.torproject.org/tpo/community/relays/-/issues/36
 
 * What about raising the fast relay flag threshold?

The reasoning being that if you remove the really slow relays from the
network, then even though there are fewer relays, average circuit
performance gets better? This is actually just one of dozens of ideas we
have for improving performance, and the plan is to use Mike's framework
for doing a proper experiment for each idea, and measuring whether it
actually helps: I think gitlab link is
https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues 

There is a great wiki page too, listing e.g. what network characteristics to measure. Start here:
https://gitlab.torproject.org/legacy/trac/-/wikis/org/roadmaps/CoreTor/PerformanceMetrics
and here:
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor61/PerformanceExperiments

Idea for an agenda topic for next time: Mike's network-wide performance
experiments, how to do experiments safely and productively on the live
Tor network.


-- 
The Tor Project
Community Team Lead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20220207/02dc912b/attachment-0001.sig>