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

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

2 Likes

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

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] https://gitlab.torproject.org/tpo/community/relays/-/issues/18

ยทยทยท

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
https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

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

--
The Tor Project
Community Team Lead

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

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

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)

If you're not familiar with project management practices at the Tor
Project, it's important to note that Sponsor+code is simply a numerical
code assigned by the operations/grants team to a particular funded
project. It is not a cypherpunk "scramble box" as some may mistakenly
assume.

The sponsor name, DRL (Department of State Bureau of Democracy, Human
Rights, and Labor - US Gov), can be found in the linked milestone that was
previously shared, during the meetup, and is also publicly listed in our
GitLab instance.

Milestone:

S112 activity tracked with the label "S112" in our GitLab:

You can find all the current Tor Project sponsors, projects and
reports here:
- Project wiki page: sponsors 2023 ยท Wiki ยท The Tor Project / Organization ยท GitLab
- Current Sponsors: Tor Project | Sponsors
- Fiscal year reports: Tor Project | Reports

For those interested on learning more about S112 work, the Network
Health team meet every Monday at 16 UTC, on #tor-meeting (irc.oftc.net),
and we've been adding the relevant topics on the relay operator meetup
agenda.

> 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?

Sure, here is the timeline: October 2022 - January 2024

- We called for proposals from the community (March 3 2023)
- Work on proposals (TPO) (like meta proposal about the process and
   governance and different stake holders) (March/April)
- Proposal evaluation (May/July)
- Events and offline discussions with community (August/September)
- Approving proposals after feedback from the community and figuring out
   the details of enforcement/adhering to them (September-December)
- Proposals go live (January 2024)

> > > 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

hm, for the scope of that document (Expectation for relay operators), I
don't think we need to describe a verification process of "working
email". For other proposals, it could be important to define the
process, though.

But you can suggest a better phrase here:

Gus

ยทยทยท

On Mon, Mar 06, 2023 at 07:49:47PM +0100, nusenu wrote:

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

--
The Tor Project
Community Team Lead

The sponsor name, DRL (Department of State Bureau of Democracy, Human
Rights, and Labor - US Gov), can be found in the linked milestone

I found it after sending the question but thanks for elaborating.

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;

[...]

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?

Sure, here is the timeline: October 2022 - January 2024

  - We called for proposals from the community (March 3 2023)
  - Work on proposals (TPO) (like meta proposal about the process and
    governance and different stake holders) (March/April)
  - Proposal evaluation (May/July)
  - Events and offline discussions with community (August/September)
  - Approving proposals after feedback from the community and figuring out
    the details of enforcement/adhering to them (September-December)
  - Proposals go live (January 2024)

Based on your answer I got the impression that my question was
slightly misunderstood since you outlined the timeline from the proposals
to the "proposals go live" but my question was specifically about
the definition of the governance process.
According to the order outlined people are expected to submit
proposals before the governance process (the second item in your list looks like it) is defined,
shouldn't it be the other way around?

I think an effort could be made to to answer some more fundamental questions,
like the one I sent previously, found under "a few questions".

I found it surprising to see some of my previous
proposals linked on the slides of the meeting - because tor core people (arma, geko, more?)
have practically rejected them in the past already.

kind regards,
nusenu

ยทยทยท

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

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?

I would actually like to hear the torproject's "self-assessment" on this
before I send my opinion on it.

kind regards,
nusenu

ยทยทยท

--
https://nusenu.github.io

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

1 Like

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?

I would actually like to hear the torproject's "self-assessment" on this
before I send my opinion on it.

Well, I don't know how we should do that as you are likely the only person that knows what you mean by "how things are (not) handled by the Tor Project in this space". I don't even know the timeframe you have in mind to do any kind of digging for some potential problems you could have meant.

So, again, I (and others) would be happy to hear about the problems you had in mind when writing your email and ideally what we should have done differently, but without knowing at least the problems I don't know how we are supposed to say anything about them as I mentioned above.

Georg

ยทยทยท

kind regards,
nusenu

I agree: it would be nice to hear about the current (informal) process, flawed as it may be, and the Tor Project's self-assessment of a sample of past suggestions, how they were handled, and recommendations for improvement.

ยทยทยท

On Sun, 2 Apr 2023, nusenu wrote:

I would actually like to hear the torproject's "self-assessment" on this
before I send my opinion on it.

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

toroperlist@jrobin.ephemeron.org:

I would actually like to hear the torproject's "self-assessment" on this
before I send my opinion on it.

I agree: it would be nice to hear about the current (informal) process, flawed as it may be, and the Tor Project's self-assessment of a sample of past suggestions, how they were handled, and recommendations for improvement.

Well, *that* is a good idea, which we certainly can do. Thanks for bringing it up.

I've filed a ticket to track that work for those of you who are interested.[1]

Thanks,
Georg

[1] Get an overview of how we dealt with past suggestions for network-health/community improvements (#66) ยท Issues ยท The Tor Project / Community / Relays ยท GitLab

ยทยทยท

On Sun, 2 Apr 2023, nusenu wrote:

gus:

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)

If you're not familiar with project management practices at the Tor
Project, it's important to note that Sponsor+code is simply a numerical
code assigned by the operations/grants team to a particular funded
project. It is not a cypherpunk "scramble box" as some may mistakenly
assume.

The sponsor name, DRL (Department of State Bureau of Democracy, Human
Rights, and Labor - US Gov), can be found in the linked milestone that was
previously shared, during the meetup, and is also publicly listed in our
GitLab instance.

Milestone:
Sponsor 112 : Combating Malicious Relays ยท The Tor Project ยท GitLab

S112 activity tracked with the label "S112" in our GitLab:
Issues ยท The Tor Project ยท GitLab

You can find all the current Tor Project sponsors, projects and
reports here:
  - Project wiki page: sponsors 2023 ยท Wiki ยท The Tor Project / Organization ยท GitLab
  - Current Sponsors: Tor Project | Sponsors
  - Fiscal year reports: Tor Project | Reports

For those interested on learning more about S112 work, the Network
Health team meet every Monday at 16 UTC, on #tor-meeting (irc.oftc.net),
and we've been adding the relevant topics on the relay operator meetup
agenda.

To add to what Gus said: we have from time to time face-to-face meetings[1] and we publish meeting notes for those as well. So watch that space, too. :slight_smile:

In our latest face-to-face meeting two weeks ago we had a session about network health proposals and I just finished uploading the notes[2] for those of you who are interested. Two highlights included there are

- our current draft of proposal evaluation criteria
- some proposal ideas we as the Tor Project should pursue, which are all tracked in our shiny new policies project[3]. I expect more to come in this area... :slight_smile:

Georg

[1] Meetings ยท Wiki ยท The Tor Project / Organization ยท GitLab
[2] Wiki ยท The Tor Project / Organization ยท GitLab
[3] The Tor Project / Community / Policies ยท GitLab

ยทยทยท

On Mon, Mar 06, 2023 at 07:49:47PM +0100, nusenu wrote:

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