Linus Nordberg and I wrote a short paper that was presented at FOCI
2023. The topic is how to use all the available CPU capacity of a server
running a Tor relay.
This is how the Snowflake bridges are set up. It might also be useful
for anyone running a relay that is bottleneck on the CPU. If you have
ever run multiple relays on one IP address for better scaling (if you
are one of the relay operators affected by the recent
AuthDirMaxServersPerAddr change), you might want to experiment with this
…
[View More]setup. The difference is that all the instances of Tor have the same
relay fingerprint, so they operate like one big relay instead of many
small relays.
https://www.bamsoftware.com/papers/pt-bridge-hiperf/
> The pluggable transports model in Tor separates the concerns of
> anonymity and circumvention by running circumvention code in a
> separate process, which exchanges information with the main Tor
> process over local interprocess communication. This model leads to
> problems with scaling, especially for transports, like meek and
> Snowflake, whose blocking resistance does not rely on there being
> numerous, independently administered bridges, but which rather forward
> all traffic to one or a few centralized bridges. We identify what
> bottlenecks arise as a bridge scales from 500 to 10,000 simultaneous
> users, and then from 10,000 to 50,000, and show ways of overcoming
> them, based on our experience running a Snowflake bridge. The key idea
> is running multiple Tor processes in parallel on the bridge host, with
> externally synchronized identity keys.
[View Less]
Hi folks!
EFF has launched their advocacy campaign for getting more Tor relays
running at universities:
https://toruniversity.eff.org/https://www.eff.org/deeplinks/2023/08/announcing-tor-university-challengehttps://www.eff.org/press/releases/eff-launches-tor-university-challenge
We're focusing on universities in particular, not just to get more
capacity for the Tor network, but also to strengthen the connections
between the Tor network and academia. Universities are great locations for
…
[View More]Tor relays for education (Tor is part of every cybersecurity curriculum
these days), for community (growing connections between students and
research groups), and for research (helping the Tor network stay strong
so people can use it for research):
https://toruniversity.eff.org/administrators/https://blog.torproject.org/tor-heart-pets-and-privacy-research-community/
Having more relays at universities is especially useful because it can
help others to see that running a relay is a normal and straightforward
thing to do.
So: if you are at a university, or you know somebody who is and want to
help them, please consider setting up relays there. It can be anything
from an exit relay (the most useful to Tor users, but the most work in
terms of local advocacy and relationship-building), to a non-exit relay
(still very useful to Tor users, because we need more network diversity),
to a non-NATed Snowflake bridge (currently used most by people in Iran
to get around their censorship and reach the Tor network).
We started the campaign with thirteen institutions that are already
running relays and/or other public infrastructure pieces:
Technical University Berlin (Germany)
Boston University (US)
University of Cambridge (England)
Carnegie Melon University (US)
University College London (England)
Georgetown University (US)
Johannes Kepler Universität Linz (Austria)
Karlstad University (Sweden)
KU Leuven (Belgium)
University of Michigan (US)
University of Minnesota (US)
Massachusetts Institute of Technology (US)
University of Waterloo (Canada)
Hopefully this list will make you impressed / excited / jealous and you
will want to get your university onto it. :)
Later steps in the campaign will be to understand which universities
have IT departments that understand and value Tor, and which ones try
to block you from using Tor on their network or block Tor users from
reaching their webservers. We are also imagining to do an OONI workshop
to help people do "how well does Tor work on this network" tests.
Here is the internal coordination/roadmap ticket if you want to follow
along in detail:
https://gitlab.torproject.org/tpo/community/relays/-/issues/67
Thanks!
--Roger
[View Less]
Hello everyone!
As indicated in our bug tracker a while ago[1] we have some strong
incentives to redo our ContactInfo field. I've collected all the
different use cases and combined them in a single proposal, discussing
some potential concerns and future work we could get built upon it. The
work is tracked on Gitlab as well[2] feel free to provide feedback there
or here on the list as a follow-up to this announcement. For your
convenience the proposal text is included below (if you like …
[View More]reading the
.md file on Gitlab, see my personal repository for the latest draft[3]).
"""
```
Filename: 100-contactinfo-mandatory-email-address.md
Title: Restricting ContactInfo to Mandatory Email Address
Author: Georg Koppen
Created: 2023-10-21
Status: Open
```
## Overview
This document proposes to change the ContactInfo field from a free text
field to one that is only allowing an email address. Additionally,
providing such an email address will be required after this proposal is
implemented. This is a normative document.
## Motivation
Being able to reach out to and contact relay operators (bridge operators
are included in that group) is important for our day-to-day work at Tor.
While this has been brought up in the past as helpful in our fight
against malicious relays, it goes well beyond that use case and is
affecting general network health work, community-building efforts and
quickly deploying anti-censorship related security fixes among other
things.
Tor is providing a `torrc` configuration option, `ContactInfo`, which is
supposed to contain an email address (potentially obfuscated) under
which the relay operator may be reached. However, in practise this does
not work very well for two reasons:
1. `ContactInfo` is a free-form field which allows the operator to
include not just email addresses but essentially any kind of text
they want. This results in a lot of overhead when trying to contact
all operators and failures to do so because not everything added to
`ContactInfo` is a way to actually contact operators or undoing
`ContactInfo` obfuscation turns out to be too hard.
2. `ContactInfo` can be empty as it is not required for all operators
and in cases where it is supposed to be required (e.g. for operators
running more than one relay) the requirement is not enforced.
Over the years different teams at Tor developed different workarounds to
the issues mentioned above without addressing them directly. The goal of
this proposal is to make those workarounds obsolete.
## Fixing ContactInfo
As briefly mentioned in the [Overview section](#overview) the idea of
this proposal is deceptively simple: `ContactInfo` will be turned into a
field allowing just an email address, under which the operator can be
reached. Moreover, providing such an address will be a requirement for
all operators regardless whether they run one relay or many of them, or
bridges.
Why will we require an email address and not, say, a domain set up
somewhere or an account on our forum instead? Firstly, a lot of those
other potential options require a valid email address themselves in the
first place and would therefore just raise the costs for relay
operators. Secondly, email still scales way better than other
alternatives allowing us to reach more people in less time. And,
thirdly, email addresses are required anyway in other network related
infrastructure parts, e.g. the RIPE database for IP address space
allocation comes to mind or abuse contacts for dealing with potentially
malicious Tor traffic/Tor users.
Even though this proposal will not lay out the envisioned changes at a
technical level (for that to happen we'll need a corresponding
[tor-spec] proposal later on) there are a number of details to consider
mainly stemming from the status quo existing for years and the
accumulated usage patterns of the `ContactInfo` field "in the wild".
The remainder of this proposal will be devoted to explain those details
and address potential concerns related to them.
## Implementation
The C-Tor codebase is in maintenance mode and not accepting any new
features anymore (with a very narrow set of exceptions). We therefore
plan to have this change included solely in the upcoming Arti relay
work. Note: while we'll be using `ContactInfo` throughout this proposal
it does no mean that the respective configuration option for Arti relay
will be the same. It could just be [`contact`] or something else. The
important point is that this proposal applies to whatever is providing
the argument for the "contact" keyword in the server descriptor then.
Requiring a syntactically correct email address in an Arti relay
configuration option is necessary but not sufficient for our purposes.
Otherwise `ContactInfo` values like `nobody(a)example.com`, which is used
by some relays and bridges in the Tor network at the time of writing
this proposal, would be acceptable. However, in that case there would
be no way to get into contact with respective relay operators. We intend
to solve that problem by deploying an email verification service: relays
without a verified `ContactInfo` value won't be allowed on the network.
## Concerns
There are some concerns related to this proposal which we should discuss
and address where needed. The following sections will outline them and
explain why (and how) we think they are non-issues or can be mitigated.
### Backward compatibility and breakage of external tooling
What do we do with `ContactInfo` strings that are not email addresses
already? The main goal should be to make the transitioning process to
the new `ContactInfo` string as smooth and easy for relay operators as
possible. The good news is that we plan to have a transitioning tool for
the overall change of C-Tor relays to Arti relays anyway and having the
`ContactInfo` change be part of that should help. Running an awareness
campaign and providing up-to-date documentation to reach operators that
need to fix (or even set up) their `ContactInfo` manually should further
minimize the risk of losing relays in the network and volunteers running
them to begin with.
However, even if it were possible to extract an email address from the
C-Tor relay configuration of any C-Tor relay or bridge without manual
intervention by the operator there is another problem to consider: there
is often additional information available in current `ContactInfo`
strings, which sometimes external tools got built upon. One well-known
example for that is [`OrNetStats`] which aims at displaying statistics
related to relays and bridges in the Tor network. One important piece
of it is grouping the displayed information around so-called
Authenticated Relay Operator IDs (AROIs) were possible, which got
developed in the [ContactInfo Information Sharing Specification] \(CIISS)
and is making use of overloading the `ContactInfo` field with additional
information besides an email address. While we can't avoid breaking
tools when evolving the `ContactInfo` semantics we can provide ways for
those tools to get adapted to the new reality. For that we propose to
create an additional configuration option that includes the non-email
address information in the `ContactInfo` field and is made public in
extra-info descriptors. Even though we believe validated email addresses
as proposed in this proposal together with the planned
[happy families proposal] and [proposal 347] provide similar benefits as
the AROI mechanism, and hence make it superfluous, if someone would
still like to center their relays statistics around AROIs they could do
so by extracting the necessary information from extra-info descriptors
after this proposal got implemented.
### Spam
Exposing an email address without obfuscation in the `ContactInfo` field
is a potential spam risk which is why some operators have resorted to
obfuscating it, often in very creative ways. However, we do think that
those efforts are not effective if we want to retain a way of being able
to reach operators by email. Moreover, our own and others' experience
of running relays and providing an unobfuscated email address as
`ContactInfo` shows that spam right now is actually not an issue. That
might change in the future, though, which is why we strongly recommend
to use a dedicated and long-term email address in the `ContactInfo`
field. The long-term part is particularly important, as this proposal
turns that email address into a validated relay operator ID, which is
valuable for building trust over the longer run.
## Impact on relay operators and the growth of trust in the Tor network
As can be seen in the previous sections, the proposed changes in this
document can come with a cost for relay operators. However, we do not
expect them to have a lasting impact on our relay operator community and
the health of the network as those changes are mainly accompanied by a
one-time transition cost that puts a burden on our current relay
operators. And that one-time cost we try to keep as low as possible.
Additionally, we might lose or alienate some of our current and
potential new operators, as they might not want to provide any
(verifiable) email address at all as a requirement for running relays,
but rather prefer participation anonymously. However, in order to fight
malicious relays we need to strengthen our community and get to build
connections and contacts with each other, which is hard if there is no
way to get into contact to begin with. As outlined at the begin of this
document, a lack of contact information makes other day-to-day work at
Tor hard or impossible as well. Thus, overall we believe providing a
working email address when running relays is a small cost compared to
the improvements of the health of our network and the safety of our
users.
There is another benefit which comes with this proposal: the validated
email address can essentially work as a relay operator ID (similar to
the above mentioned AROI). While we do deal with single relays or
families of them when we are trying to determine whether they pose a
danger to our users, what we are ultimately aiming at is the operator
behind them. Having something like a relay operator ID does help with
that part. But there is more: it allows us to think better about trust
on the Tor network and how we might be able to implement ideas like
"operator X is only allowed to run Y% of the Tor network" or "unknown
operators are only allowed to run Z% of Tor's network capacity", to name
just two. There are a number of proposals both [trust][torspec 103]
[related][relay-search 40001] and [not trust-related][team 220] that
would benefit from having relay operator IDs available.
## Acknowledgements
Big thanks go to @gus and @ahf for discussions and feedback around this
proposal idea, which improved this document considerably.
[tor-spec]: https://gitlab.torproject.org/tpo/core/torspec
[`contact`]:
https://gitlab.torproject.org/tpo/core/arti/-/issues/870#note_2906252
[`OrNetStats`]: https://nusenu.github.io/OrNetStats/
[ContactInfo Information Sharing Specification]:
https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/
[happy families proposal]:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/82ba302230911cafd8683…
[proposal 347]:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/523404500320ba9700fe5…
[torspec 103]: https://gitlab.torproject.org/tpo/core/torspec/-/issues/103
[relay-search 40001]:
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss…
[team 220]:
https://gitlab.torproject.org/tpo/network-health/team/-/issues/220
"""
Thanks,
Georg
[1] https://gitlab.torproject.org/tpo/core/arti/-/issues/870
[2] https://gitlab.torproject.org/tpo/community/relays/-/issues/71
[3]
https://gitlab.torproject.org/gk/policies/-/blob/prop100/100-contactinfo-ma…
[View Less]
I provided some high speed Tor nodes (non-exits and guards) but I quit
in this year to make some space for my other projects. I would continue
collaborating by keep Tor nodes online if I receive some donation. Is it
just me, because I received $0 for running those Tor relays.
So my proposal is this:
1. make a donate-torrelay-owner.tpo website
2. let Tor relay owners link their
PayPal/Striple/BitCoin/OpenCollective/AmazonPay/GooglePay/Whatever
account
3. the Tor project and other good folks …
[View More]put money into the large bottle
(donate-torrelay-owner website)
4. the donation then split by the participants & send to each accounts
monthly
By doing this, you are creating sustainable mechanism to keep Tor nodes
running and other people who have access to their servers may join. More
Tor nodes will be added to the network & owners get paid at least.
Win-win.
Please do this!
[View Less]
On 10/31/2023 03:09 PM tor(a)nullvoid.me wrote ..
> My only concern with your solution is anyone can pretend to be the owner of a relay.
- What do you have to say to a relay owner that cannot be said publicly?
- What do you have to say that needs a reply?
In the rare cases where you would have a valid answer for the above questions, the actual email address in the ContactInfo is good enough, and - assuming there are none - you could ask to include a temporary code in the …
[View More]ContactInfo for authentification when someone contacts you on your request.
The point is if you have to contact all relay operators, you don't need to look for their email addresses in ContactInfo. All you need is to post the message publicly, easily accessible by each relay owner (a personalized RSS feed comes to mind).
[View Less]
I've been thinking long and hard about this problem and I'm not sure if an email address - validated or not - is the best way to achieve the initial goals.
What are the goals of having this validated email address?
1- Inform the operator;
2- Make sure the operator will read the info;
3- Identify the operator.
I'll keep #1 for last as this is the only truly needed goal from my point of view.
Identifying the operator ID to make further decisions on how to share the traffic may be kind of …
[View More]useless. There are either _good_ operators and you have no real reason to divert traffic from these relays or there are _bad_ operators and they will try to hide that fact by creating multiple identities. Your validated IDs are still useless to you as identifying _bad_relay operators.
About validating an email address to make sure the operator will read the info, it is still not a guarantee that it will happen in the future. If an operator does not want to - or cannot - read his/her emails, you cannot do anything about it. Except maybe revalidating the email address regularly which is, first, annoying and, second, what are going to do if a _good_ relay operator doesn't revalidate his/her email address? Shut down all of his/her relays? You might shoot yourself in the foot going with such an attitude.
So there is no real point in validating an email. It will just turn out to be more red tape to go through.
About point #1, you want to inform the relay operator. Do you need a two-way communication method for that?
* How about putting the message to the operator on the _metrics.torproject.org_ relay page?
* Would there be any reason for the messages not to be public?
* If, somehow, a response - or an exchange - may be needed, why not put a general contact email address for answers, comments, etc. with, for example, the message ID as the subject? If the message is really personal, the message can be as simple as "Contact us at torproject(a)example.org ASAP."
* Why not put an RSS feed to be able to fetch those messages automatically and regularly?
* That way, you can also contact multiple operators based on their country, platform, etc. with the same message as well.
This would be something similar to _weather.torproject.org_ but much simpler and without a need for any kind of registration.
Are you sure all operators will follow, read, and act upon your messages? Not less than by sending an email. Much better than NOT having a valid email address at all. A _bad_ operator will be a _bad_ operator no matter what.
[View Less]
Hello,
The next Tor relay operator meetup will happen this Saturday, October 21 @ 19 UTC.
Where: BBB - https://tor.meet.coop/gus-og0-x74-dzn
No need for a registration or anything else, just use the room-link
above. We will open the room 10 minutes before so you can test your mic
setup.
Note: BBB requires a browser that supports webRTC such as Firefox, Safari,
or Chromium/Chrome.
Agenda
------
https://gitlab.torproject.org/tpo/community/relays/-/issues/77
[Expected meeting duration: …
[View More]60 to 90 minutes]
- Announcements:
- WebTunnel PT is available on Tor Browser 13
- (Update) Tor on Universities
- Meta-proposal for new relay operator policies:
https://gitlab.torproject.org/tpo/community/policies/-/blob/master/001-comm…
- [Discussion] ContactInfo proposal
Everyone is free to bring up additional questions or topics at the
meeting itself.
Please share with your friends, social media and other mailing lists!
cheers,
Gus
--
The Tor Project
Community Team Lead
[View Less]
Hello everyone!
As you might have noticed, Tor Browser 13 got released last week[1]
which ships for the first time a Tor 0.4.8.x version (0.4.8.7) to our
stable Tor Browser users. One of the main features in the 0.4.8.x series
is Conflux, which allows traffic-splitting to improve Tor performance.[2]
Given that we assume Tor Browser users are a large fraction of our
overall Tor users and 0.4.8.7 deployed by Tor Browser results in
pre-built Conflux circuits, there is a chance that exit …
[View More]nodes on 0.4.7.x
might see less traffic over time. An easy way to avoid or fix that
problem is an upgrade to the 0.4.8.x series.
Georg
[1] https://blog.torproject.org/new-release-tor-browser-130/
[2]
https://gitlab.torproject.org/tpo/core/torspec/-/blob/288c5134ddb737e321cf3…
[View Less]
Hi all,
I’ve been running my first relay for a few weeks now. The VPS provider I chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 TB” and AccountingStart to