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

[Robert W Capps II]

Interesting, while the server config page clearly says the email may  
not be answered, it does not indicate that the email will most likely  
never be ACTIONED.

If it is the intention to not register names for servers, then that  
should be clearly stated in the Server configuration guide.  It  
sounds like it's time to delete Step Four: 'Let us know about your  
server', since for all intents and purposes, the feature has been  
abandoned.

I for one would like to see some protection given to the names  
assigned to long-term stable routers . . . but that may just be a  
personal preference of mine, I like to know which server ops take the  
time to actually register their servers :)

Robert


On Sep 23, 2007, at 1:37 PM, Roger Dingledine wrote:

> 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 at freehaven.net 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
>