Servers and the "Named" flag (was Re: time needed to register a serve)

[Roger Dingledine <arma@xxxxxxx>]

On Tue, Sep 18, 2007 at 03:06:53AM -0500, Scott Bennett wrote:
>      Does anyone have a sense of the current processing delay in registering
> a server?  I ask only because I sent off the registration information to
> tor-ops@xxxxxxxxxxxxx last Thursday evening, 13 Sept., and my server is still
> showing up in the status documents without the "Named" flag in them.
>      It's not a big deal; I'm just curious.  Processing of flight instructor
> certificate renewals is now said to take more than six months, and the
> certificates have to be renewed every 24 months.  (Your tax dollars at work,
> of course. :-)

Alas, we've pretty much stopped assigning the Named flag to servers.
This is because it's a time-sink to manually go through and make sure
the server is actually acting correctly, go put the keys in the right
place, etc. There have been some proposals to make it easier, e.g.
https://tor.eff.org/svn/trunk/doc/spec/proposals/113-fast-authority-interface.txt
and at some point we should do one of them. See also the discussion
under http://archives.seul.org/or/dev/Apr-2007/msg00040.html
I'm a fan of solution #2 in the above url: there's no reason why a human
needs to be in the loop, and if we don't know the operator on the other
end, the "Named" flag doesn't mean what it meant in 2003 when we created
it anyway.

Once upon a time (2003 era), you needed to be manually approved or you
wouldn't be able to join the network. The primary reason was that we
needed to verify that your server was reachable, working, etc. Then
we got more than a dozen servers, including servers run by people we
didn't know, and we automated the process of testing reachability at the
directory authorities. Then we started to allow unnamed servers to join
the network and play pretty much the same role.

The only main difference at this point is from the client perspective:
if you manually specify a non-named server in your torrc or using the
foo.exit syntax, your Tor will complain to you (well, to your logs)
and suggest a hex digest that you should use instead.

Now, there is an argument for letting people remember nicknames rather
than hex digests. But I would eventually like to see some sort of
graphical "server picking" interface that most users would use, and it
would be smart enough to know the hex digest of the picked server. If,
that is, we need any sort of server picking to be happening at all --
most users I hear from who need to specify a specific server rather than
just let Tor pick for them seem to be doing it to get around crude access
controls on websites or other services, and I'm not sure that's an arms
race I want to get into.

There are other problems that need to be solved from a usability angle.
For example, if the nickname Alice picks is already registered, then when
she tries to sign up her server, it will print a mysterious message in her
logs ("there are logs? what's a log?") and her server won't be useful. We
need to make that simpler somehow, and the simplest approach for now
(by default) is to not have many Named servers. My preferred solution
would be to add an "Unnamed" flag that servers get when they're using a
nickname that is already registered -- the server will continue to be a
fine server, but it will be invisible from the perspective of referring
to servers by nickname.

And lastly, one of the crucial reasons for maintaining contact with server
operators is so they feel appreciated, and so we have an opportunity
to answer their questions, address their concerns and problems, etc.
Maintaining communication with the server community helps it to grow
and be stable. We are doing a poor job at that currently. A few years
ago I realized that I could choose between answering a whole lot
more mail (and having the number of good Tor servers keep going up)
and getting more development work done on Tor. Since Tor is nowhere
close to done, the latter was the clear choice -- as long as there
is *some* sort of Tor network, that's good enough for testing the new
scalability/anonymity/performance features and bugfixes.

Peter Palfrader then stepped up to answer mail for a while, but he
soon found it to be a flood too. My fix at the time was to modify
https://tor.eff.org/docs/tor-doc-server#email to make it clearer that we
may not ever answer the mails. Maybe I should make the statement even
stronger, or just erase 'step four' entirely, until somebody sorts out
proposal 113 and implements and deploys a good solution.

I don't think getting a pile of volunteers to answer the mails is the
right answer -- we should instead a) work to take out the artificial
bottleneck (help appreciated! :), and b) figure out better ways to build
server operator community that don't involve as much manual attention
from me (help appreciated! :).

Thanks,
--Roger