response 21 of 85:

Dec 3 03:12 UTC 2010

Looks like /usr/noton/nu doesn't exist so that's why I got that error.
But if the new one is easier to get in place and it works, that might be
better (and more maintainable).

response 23 of 85:

Dec 3 15:23 UTC 2010

Here's what I see we need to do, in order of priority:

  1. Get the web newuser working.  If that means getting it working
     as it did when it was last working, with all the questions and
     technical stuff, so be it.  Not having it working at all is more of
     a harm to us than a complicated new user process.

  2. Simplify the web newuser.  From what I've seen we should be able to
     do this if we have a working web newuser and just use some default
     values or no values for options, for the things we're no longer
     asking (in the data submitted from the web page).  If this is not
     the case, speak up.

     The "how" (or "how much") to simplify is one of those consensus
     questions we get from time to time.  Let's give the Board and Staff
     and the rest of the users some time to weigh in.  Perhaps they see
     other issues with any simplification proposal.  If we hear nothing
     in a reasonable amount of time (e.g. 1 week), I'll assume no one
     has an objection.  Then let's simplify it and see how it works out.

Let me know if you see issues with this process (such as it's more work
to re-do the web newuser or web page to simplify it than it is to just
take the time to simplify all of it now).  We can adjust accordingly.

(I've also e-mailed staff and board with a summary of what we're talking
about in this item).

response 25 of 85:

Dec 3 16:21 UTC 2010

I understand your point of view, Dan.  Maybe it's time to not try so
hard for a consensus or the involvement of others and just get things
done.  From what I've seen, generally, the people who care have little
or no interest in actually making things happen, so I'm tempted to just
say "do it this way" and let the chips fall where they may.

response 27 of 85:

Dec 3 18:25 UTC 2010

resp:25 Thanks, Kent.  Don't get me wrong, consensus is good, but it's 
also this community's achillies heel.

resp:26 Quick!  Someone upload slynne's post to wikileaks!

response 29 of 85:

Dec 4 21:04 UTC 2010

Re resp:20 - "Actually, I think the short term solution is to get the
new one written.  The code that's there now is, well, complicated and 
confusing and very, very old."

I quite agree.  Web newuser is around 2400 lines of C source code, and
the TTY-based newuser around 5700, code that nobody currently active on
Grex had anything to do with writing.  Wading through that to fix
problems, when a new TTY newuser is already in place and a new web
newuser shouldn't be far behind, strikes me as not worth the effort.

response 31 of 85:

Dec 5 01:05 UTC 2010

resp:29 Agreed.

resp:30 The new newuser needs some cleanup, but overall, I think it's a lot
less crufty than the old newuser.

response 33 of 85:

Dec 9 18:04 UTC 2010

What's not a good idea about mailing the password?  This isn't the
Pentagon or anything. We've talked about an an offsite e-mail address
being more or less required, as in automatically send the user an
e-mail and they can respond and be validated.  It also gives us contact
information if there are other issues (including forgotten password).

I suppose we could require the password be changed when they first
log in.  Or at least, suggest strongly that they do so in the e-mail
we send.

response 35 of 85:

Dec 10 04:35 UTC 2010

Okay, then, sounds like we're in good shape.

response 37 of 85:

Dec 10 12:38 UTC 2010

I'm going to address your post point by point.  I'm also going to take
the time to fix your spelling errors.

> first of all .... about emailing passwords... when a newuser comes here
> she/he/it creates a passwd.

That's not true anymore; the user isn't even prompted for a password.
Further, there's nothing that says that they *have* to give a password
to newuser.

> wtf is wrong with that? nothing.

Actually, it became a vector for abuse.  I have caught specific people
making *thousands* of accounts with scripts.  This way, at least we can
track that back to an email address.

Second, by generating the passord and emailing it to the user, at least we
have some sort of useful contact information: if the user logged in at all,
we know we've got an email address for them.

Lots of sites do this: ask for an email address and email an auto-generated
password to the user.  It works just fine all over the Internet.

> second, the validation is a time delay, even if it is 30 secs.

What validation are you referring to?  The automated validation of the
email address that newuser does?  I'd say that in the worst case that
might take half a second.

Or are you talking about how long it takes for the user to get the email
so they can login for the first time?  It takes a few seconds.  The upsides
are worth it.

> third.  the eamil to the newuser may not be read (or it might go into
> some spam folder) and be unknown for months. (rt stuff is experience as
> is ... my email).

It strikes me that if a user is interested in getting an account on Grex,
they won't mind getting an email with their password.  Evidence of this is
all over the net; it's more common than not for users to get passwords
emailed to them than otherwise.  If they wait for months, well, that's on
them and they weren't likely to be very interested anyway.

What's the difference between a user logging in once automatically at the
end of creating their account and never logging again, and never logging in
because they didn't bother to read the email that we told them they were
going to get?
   
> i have  validated .. well tried to validate ... reaped logins .. which
> prompted me ... a while ago ... to ask about the reap  procedure.  what
> i had to send was "well create your login id AGAIN .. and i will validate"

I don't know what this has to do with newuser emailing passwords, except
perhaps an extension of the above paragraph about the user not reading his
or her email for months.  Newuser is pretty explicit about telling the
user, multiple times, that it's going to send them email.  If they choose
to ignore that email, then they're just as likely to login to resh, see
they can't run BNC or upload udp.pl and disappear after one login.

The policies and criteria by which we decide to reap accounts have not
changed for years.  If it takes the porters months to do validation, then
that's a real problem.
   
> fourth .. a password sitting around for a while is STUPID (imnsho)
> which is also different from the new user's original choice .. w t f ?

What do you mean, "is also different from the new user's original choice"?
Do you mean a password that they enter, or a password that they have in
mind when they create an account on Grex?  If the former, they don't enter
a password.  If the latter, I claim this is actually *easier* on them
since they don't have to sit there and think of one.

To be clear, here's the basic process for getting an account on Grex:

1. Login as newuser and enter your basic information:
   a. "Real" name.
   b. Email address.
   c. desired login name.
   d. Currently, a few other questions: address, phone number, interests, etc.
   * Note that password is not on this list. *
2. Newuser generates and emails you your password.
3. User gets the password, logs in and is in resh.  Resh sees they've
   got a special file in their home directory (I believe I named it,
   ".needspwchange", but I can't remember) and prompts them to change
   their password.

That's it.  Suppose we go on through the validation process.

4. User goes through the validation process:
   a. send email to porters@grex.org with the request,
   b. get an email back saying, "How'd you hear about Grex?"
   c. user gives some response (really, any response will do),
   d. a porter runs "validate user" on Grex, thus changing their
      primary group to "people" and changing their shell to
      /usr/local/bin/newly-validated (this will move to /cyberspace/bin
      soon, though; the path is unimportant).
5. User logs in again (note that they changed their password the first
   time they logged into resh; it doesn't change at all during the validation
   process).  Newly-validated chgrp's their files to the "people" group
   and invokes /usr/local/bin/pickashell (again, this needs to move to
   /cyberspace/bin, but the path doesn't matter); the user picks what shell
   they want to use and away they go.

Now the user has real access to Grex.  Supposing that they wanted the
full, unrestricted access, then go through the existing procedures, which
haven't really changed since Grex was created, to get verified: basically,
this means that they send a copy of an ID or a personal check or use
paypal, at which point someone runs "verify user" on them, which changes
their primary group to "verified" (and that's basically it; it also adds
them to "people" as a secondary group).

What I'd like to do, and what board talked about somewhere on the order
of three or four years ago, is add an automated verification system.
Basically, the user types "verify" or something on Grex, gets a URL that
they click on, they pay a couple of bucks or something through PayPal,
PayPal contacts us, we verify the payment and automagically verify them.

> there is more but the above is enough, i think.

No, I'm afraid it is not.

You are making a lot of flimsy assumptions (that the user won't
read their email, or that it will get marked as spam) and predicating
your argument on things that haven't been true for years (that the
user comes to Grex with some idea of what they want their password
to be, probably also that this is some sort of huge security risk).
It isn't 1991 anymore.

I think that what newuser is doing now is actually much better than
the old system:

a. It avoids abuse.
b. It gives us much higher quality contact information (we actually
   have an email address that we know works in case the user forgets
   his or her password).
c. It makes contacting the user simpler: we can look at newuser's
   contact logs to get a user's email address if we want to send them
   a message, instead of digging through their personal files (which
   TS does regularly in order to find email addresses for validation
   purposes).
d. It gives an air of professionalism to Grex that, I claim, will
   increase users, not drive them away.
e. It follows well-established and widely used precedent.  Indeed,
   even on Grex, when we reset someone's password, we just send
   them an email.

Does anyone else feel that emailing the password to the new user is
bad?

response 39 of 85:

Dec 10 15:09 UTC 2010

resp:38 See steps 4 and 5 in resp:37.  I really doubt the spam problem
is much of a concern, to be honest.

response 41 of 85:

Dec 10 17:21 UTC 2010

Sometimes big reforms require small changes be implemented first, veek.

response 43 of 85:

Dec 11 07:16 UTC 2010

  
i;m glad cross is redoing newuser ... miy comment was historical.
  
the futeur wiell be differnet... and if newuewr creates NO passwed for the
new logins ... doenslt that open the flooldgarttes? charlie woueild object?
  

response 45 of 85:

Dec 12 13:24 UTC 2010

I think you are moving in the right direction, cross.  I only wish I
could be more useful in the endeavour.