[tor-relays] Open call for proposals for improving the health of the Tor relay operator community and the Tor network

Mailing Lists tor-relays
1

Hello,

We accomplished a number of things in our fight against malicious relays
over the last 2 years[1]. One area we still need to focus on is
strengthening our relay operator community. We're therefore currently
collecting proposals from you or anyone else interested that could help
to impove the health of the Tor relay operator community and, thus,
provide our users a more trusted Tor network. We're accepting both new
and old proposals, and we're open to any ideas you may have.

Although there are various proposals for improving the network and the
Tor relay operator community, not all of them are being enforced at the
moment. Nevertheless, some proposals that can help on increasing trust
have been adopted by a meaningful fraction of the Tor community (e.g.
providing valid contact information).

Another great example of such proposals is the "Expectations for Relay
Operators"[2] document, where we guide relay operators to keep the Tor
community and the network safe, healthy, and sustainable.

We'd love to hear your proposal on how to make it more difficult for
attackers to run relays while keeping it easy for good contributors to
join our network. You can share your proposals on this GitLab ticket[3]
and our tor-relays mailing list. It is worth noting that at the moment
we are only trying to map these proposals to get an overview over the
various options available. We're not in the process of approving any of
them.

If you have any experience, positive or negative, with Sybil-resistance
and online abuse mitigation projects, we welcome your opinion as well.

Since in this debate we have seen previous bad actors trying to game
this process and thus lowering the effectiveness of our defenses, the
Tor team will take all measures to stop people acting in bad faith and
enforce the Tor Code of Conduct and policies.

During the Tor Relay Operator Meetup on Saturday (March 4, 2023 -
19UTC), we will be discussing some of these proposals we've collected so
far.

Thank you,
Gus

[1] Malicious relays and the health of the Tor network | The Tor Project
[2]
Expectations for Relay Operators · Wiki · The Tor Project / Community / Team · GitLab
[3] Collect proposals towards a more trusted relay operator community (#55) · Issues · The Tor Project / Community / Relays · GitLab

···

--
The Tor Project
Community Team Lead

1 Like
2

I've got some practical experience with how things are (not) handled
by the Tor Project in this space which discourages involvement.
The past has also shown that proposals in this area are not
handled as tor proposals in the sense of [1].

We're not in the process of approving any of them.

a few questions:

- Can you describe the process these proposals will undergo after they got collected?
- Who "approves" / rejects them?
- Will it be a public and transparent process?
- Who will be involved in the process?
- How are relay operators included and to what extend?

- Will "approved" proposals be enforced?
- How will they get enforced? New tor release or directory authority vote?
- Will directory authorities be formally required to enforce "approved" proposals?

how to make it more difficult for attackers to run relays while keeping it easy for good contributors to join our network.

Will there be a longer problem statement and a
description of your threat model?

adopted by a meaningful fraction of the Tor community (e.g.
providing valid contact information).

Can you elaborate on how you define "valid" in this context?

kind regards,
nusenu

[1]

https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

···

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3

I've got some practical experience with how things are (not) handled
by the Tor Project in this space which discourages involvement.
The past has also shown that proposals in this area are not
handled as tor proposals in the sense of [1].

I believe some proposals about relay operators were not handled as
people had different opinions about the Tor Community governance and its
process. But, as I said in my previous email, after 2 years of Network Health
team work, we have seen how much important is to build a trusted and
healthy Tor Community.

> We're not in the process of approving any of them.

a few questions:

- Can you describe the process these proposals will undergo after they got collected?
- Who "approves" / rejects them?
- Will it be a public and transparent process?
- Who will be involved in the process?
- How are relay operators included and to what extend?

- Will "approved" proposals be enforced?
- How will they get enforced? New tor release or directory authority vote?
- Will directory authorities be formally required to enforce "approved" proposals?

Great questions.

- Yes, it will be a public and transparent process;
- Yes, it's a community-driven process;

As part of Tor's culture, we try to discuss proposals exhaustively until
we reach a consensus. But, that said, there is a lack of formal process.
Our goal is to build this governance process.

As part of the Tor Community, relay operators must be included, and
that's why we're bootstrapping this process with this open call and
inviting everyone to discuss this topic at the tor relay operators
meetups. Are you joining us today?

> how to make it more difficult for attackers to run relays while keeping
> it easy for good contributors to join our network.

Will there be a longer problem statement and a
description of your threat model?

> adopted by a meaningful fraction of the Tor community (e.g.
> providing valid contact information).

Can you elaborate on how you define "valid" in this context?

From the Expectations for relay operators:

"Be sure to set your ContactInfo to a working email address in case we
need to reach you."

cheers,
Gus

[1] Write "expectations for relay operators" document (#18) · Issues · The Tor Project / Community / Relays · GitLab

···

On Fri, Mar 03, 2023 at 11:26:07PM +0100, nusenu wrote:

kind regards,
nusenu

[1]
Tor design proposals: how we make changes to our protocol | The Tor Project
001-process.txt\proposals - torspec - Tor's protocol specifications

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

--
The Tor Project
Community Team Lead

4

nusenu:

I've got some practical experience with how things are (not) handled
by the Tor Project in this space which discourages involvement.

That's unfortunate. What has been the problem with past proposal-handling? And how should it have been done differently?

The past has also shown that proposals in this area are not
handled as tor proposals in the sense of [1].

That is correct. Proposals in this space are not necessarily related to Tor proposals that aim to specify behavior at the Tor protocol level. There might be some, though, that could lead to changes in Tor which then would merit a respective proposal in the sense you linked to. However, that would be a follow-up task so that the network team gets a specification which they could then implement.

I've been explaining that at the relay operator meetup last Saturday, but "proposal" here is meant to be used in a broad sense: some text detailing an idea or recipe for improving the health of the operator community, providing our users a safer Tor network that way. We look for all sorts of inputs here: ideas that might be enforceable at some point or could lead to technical changes at the protocol level or aimed at strengthening non-technical aspects of our operator community or...

I hope this clarifies things a bit.

[snip]

Georg

5

gus:

I've got some practical experience with how things are (not) handled
by the Tor Project in this space which discourages involvement.
The past has also shown that proposals in this area are not
handled as tor proposals in the sense of [1].

I believe some proposals about relay operators were not handled as
people had different opinions about the Tor Community governance and its
process.

I actually had something else in mind (see geko's reply) but
if you say that people had no clear understanding or different opinions about
community governance than it might also be a good time to start clarifying it.

The point "clarify and describe the different involved roles" as mentioned on Saturday's relay meetup
is a good start in this specific context and I agree that it will be useful.

We're not in the process of approving any of them.

a few questions:

- Can you describe the process these proposals will undergo after they got collected?
- Who "approves" / rejects them?
- Will it be a public and transparent process?
- Who will be involved in the process?
- How are relay operators included and to what extend?

- Will "approved" proposals be enforced?
- How will they get enforced? New tor release or directory authority vote?
- Will directory authorities be formally required to enforce "approved" proposals?

Great questions.

- Yes, it will be a public and transparent process;

When geko highlighted the sponsor in the meeting something along the lines of
"sitting down with our sponsor and defining criterias" (if you haven't been at the meeting don't take this too serious)
it made me wonder: If this is a public and transparent process, who is financing this work? (dubbed S112)

Our goal is to build this governance process.

Do you have a timeline for building and defining the governance process
which probably should be the first thing to do
so people can make up their minds on whether they like
the process and want to be involved or not?

adopted by a meaningful fraction of the Tor community (e.g.
providing valid contact information).

Can you elaborate on how you define "valid" in this context?

From the Expectations for relay operators:

"Be sure to set your ContactInfo to a working email address in case we
need to reach you."

Since that document says nothing about verifying that string
"hopefully valid" is in my opinion a more accurate description for it
than "valid", no?

kind regards,
nusenu

···

On Fri, Mar 03, 2023 at 11:26:07PM +0100, nusenu wrote:

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays