You are not logged in. Login Now
 0-17   17-41   42-66   67-91   92-116   117-127     
 
Author Message
25 new of 127 responses total.
dpc
response 17 of 127: Mark Unseen   Mar 16 14:53 UTC 1999

I'm with STeve on this.
janc
response 18 of 127: Mark Unseen   Mar 16 16:14 UTC 1999

Mixed feelings.  I kind of like the concept of non-tiered access.  I
don't think the computational/bandwidth/policing burden would be bad.  I
do think there is some administrative cost.

I like the two-way snail-mail validation process as a concept. 
Something like:
  - User sends a letter to Grex, with ID, the name of his login and
    a return address.
  - We send a letter back to the return address, containing a code
    word.
  - User runs a command "enable-inet" which prompts for the code word
    (different for each user) and turns on internet access.

Problem is, who's going to read the mail and generate the codewords and
do all that.  Yick.
keesan
response 19 of 127: Mark Unseen   Mar 16 19:50 UTC 1999

How many dial-in users seriously cannot afford $6/month?  People in India
cannot afford this, but Americans who have access to a phone line (which costs
more than $6/month) and a computer not being able to come up with $6/month?

What do people need telnet for that lynx will not do?  Can you telnet from
the library computer?
scg
response 20 of 127: Mark Unseen   Mar 16 20:54 UTC 1999

I don't think this would put Grex in competition with ISPs, because the level
of what's being offered is very different.  Most ISP customers wouldn't know
what to do with a Unix shell account, or a non-graphical web browser.

At the same time, though, I'm not wild about putting a lot of Grex resources
towards doing a not very good job of providing a service that is commercially
available very cheaply in this area.  If I were really concerned about not
having different access levels for members and non-members, I'd be more
tempted to turn off telnet access for members than I would to turn on telnet
access for non-members.
steve
response 21 of 127: Mark Unseen   Mar 16 22:03 UTC 1999

  There are indeed people in the aa area who cannot afford $6/mo.  Or they
can, but might give up something like bus fare to do it.  Remember, not all
the folks around here are at the upper edges financially.

  However, in this day I simply do not see many reasons for telnetting out
for most people.  Back in the summer when Damon and Staci (my kids) were
haing around at the public library a lot, they knew how to telnet because 
of Grex but it seemed that few others did, 'till they showed others Grex.
Not even the librarians knew, and were puzzled 'till Staci showed them
what telnet was.

  These days, there is very little that telnet does that Lynx (web) access
will not do, better.  Grex (and M-Net) is in the very distinct minority in
having the telnet traffic that we do.

  I would like a flat-access model too, but there are some realities tht
get in the way of being completely true to it, so we do what we can, which
is still quite a lot.  I don't think our principals are being hurt because
of this--not when telnet is dying and the web is taking over.
mdw
response 22 of 127: Mark Unseen   Mar 17 01:10 UTC 1999

I don't think it's really accurate to say "telnet is dying and the web
is taking over", or that "there is very little that telnet does that web
access will not do better".  Telnet usage isn't growing at the same rate
as web access, but that's because most people aren't using the internet
to do programming or general purpose computing, they're using the
internet to browse information.  Telnet very definitely still has its
place: if you want to do serious programming, remote system
administration, etc., you can't really do this via your web browser.
But the # of people doing serious programming and remote system
administration is not growing nearly as rapidly as the number of
non-computer type people is.
cmcgee
response 23 of 127: Mark Unseen   Mar 17 01:19 UTC 1999

Ack yes, leave me telnet!  I use it a lot.
devnull
response 24 of 127: Mark Unseen   Mar 17 04:04 UTC 1999

What janc describes in #18 seems like exactly the right idea.  Assuming
enough staff time (which I know may be a bad assumption), it ought to
be possible to write a program which whomever is processing the snail
mail can run; they enter the login name, it perhaps displays the login
name and full name, and asks for a yes/no confirmation, and then the
program picks a random code word, records the code word in a file, and
prints it on the screen.  Person writes code word on paper, and mails it off.

At the moment, my feeling is that the only problem anyone has brought up
that I have any concern about at all is the question of whether there is
a volunteer to process this mail.
mdw
response 25 of 127: Mark Unseen   Mar 17 06:52 UTC 1999

Record keeping, validation, consistency, flexibility, policy.

One of the conditions our last ISP imposed on us is that we *not* offer
unlimited internet access to regular users.  This was one of the
conditions we agreed to in exchange for reduced rates on the internet
connection.  Our last ISP was also a commercial outfit selling shell
accounts - if we had given those away "for free" that would have
undermined his business.  Our current ISP, not being a commercial ISP,
does not have any such condition, but there is no guarantee we'll be
able to keep them forever, or, if we select a future commercial ISP,
that "giving away" shell accounts with unlimited internet access might
not become a liability.

Validating internet access imposes these responsiblities on us: we need
to keep records on who it is (so that in case there are problems, we can
hold the person responsible for their actions).  The logical person
(indeed the only real choice we have at present) is our treasurer, for
obvious reasons.  That means treasurer time that can't be spent on other
more important activities, such as deciding when to send out paper
receipts, or dealing with credit card memberships or whatever else we
decide is important.

There are still lots of policy issues to be resolved.  One of the most
important is "what does it really mean to be local?"  The first obvious
question is just how local do you mean by local?  A^2?  SE Mich?
Midwest? If you believe local people should include people who primarily
or only access grex via telnet from other places, then I don't see much
reason to be geographic-centric: grex's "virtual" community is
world-wide, and I see no reason why we should be any more picky about a
user who happens to use the seattle public library than one who happens
to use the ypsilanti public library to access grex.  The second
question, of course, is what about people who move -- do they suddenly
become ineligible?  How do we decide when they've moved away?  What if
they're just on vacation, or going to college somewhere far away but
might be back for summer vacations, or are commuting across the state to
visit their significant other every weekend? If we really mean only
people who dial up to grex (as opposed to telnetting in from the public
library), perhaps that's something login ought to notice: if person is
using a local dialup (same logic as we use for the telnet queue) and
person is in the "validated-local" login group, add them to the
"internet" group also.  Of course, that's not just login, that's also
ftpd, and sshd, which makes it an inelegant and nuisance fix, but
perhaps not much worse than the $MAIL hack we already have.
aruba
response 26 of 127: Mark Unseen   Mar 17 12:45 UTC 1999

I'm not too worried about the extra time needed to process requests for
validation.  I think that as long as we limit this to people who are a local
call from Grex, we won't be flooded with requests.

If we were just talking about telnet, then I don't see any reason to give out
telnet privileges to anyone who's telnetted into Grex; they obviously already
have the capability.  So Marcus's idea of putting people in the internet group
if they are in the validated group and are dialed in makes sense.  (But of
course it will require staff to make some software changes.)

I suspect, however, that more people will ask to be validated in order to use
ftp and irc than they will for telnet.  It's possible that people at, say,
a public library (or at work behind a firewall) might be able to telnet out
but not irc out.  It seems possible to me that we might get a horde of
requests from such people (I really don't know) if we don't limit the granting
of privileges to people who are dialed in.

There is another advantage to limiting validation to people local to Ann Arbor
- we can send the Grex brute squad after them if they do anything nasty. 
Well, actually, there is no Grex brute squad, but potential vandals might
*suspect* there is one, so will be less likely to make mischief if they know
they're physically near Grex's base of operations.
mary
response 27 of 127: Mark Unseen   Mar 17 12:48 UTC 1999

I would volunteer to be a validator.  I bet others would too.
dpc
response 28 of 127: Mark Unseen   Mar 17 15:24 UTC 1999

There is *too* a Grex brute squad.  Howcum nobody told you who was
in it, aruba?
pfv
response 29 of 127: Mark Unseen   Mar 17 15:44 UTC 1999

        "..folks in india can't afford 6/mo.."

        <snort>, yeah right.. "Software Engineers", too.
mary
response 30 of 127: Mark Unseen   Mar 17 17:21 UTC 1999

Ack, aruba's response got in and I didn't know it.
I volunteered in vain. ;-)

Opening it up to dialin users would be a nice way 
to test this out.
aruba
response 31 of 127: Mark Unseen   Mar 17 18:36 UTC 1999

Re #28:  I guess it's a secret.
I suppose we could have more than one validator, but there would have to be a
central place where validation info is stored.  I'm not sure how picking up
the mail would work, too.
prp
response 32 of 127: Mark Unseen   Mar 17 19:57 UTC 1999

GIF ?
FSF ? 
prp
response 33 of 127: Mark Unseen   Mar 17 20:13 UTC 1999

Re system load:  As I rember there are about five dial-in users and sixty-five
network-in users.  Thus if restricted to dial-in users, system load should
not be a problem. 
 
Re verification:  Given the dial-in restriction, you have effectively limited
this to locals.  As you have monthly meetings, in person verification is 
possible.  No new software required.
 
Re troublemakers:  A public file with the id's, name's and address's of 
verified users might keep it to a minimum.
remmers
response 34 of 127: Mark Unseen   Mar 17 21:59 UTC 1999

I'd object to a public file of names and addresses on right-to-privacy 
grounds.

There are well-established procedures for validating members for 
outgoing internet access. We could simply use the same procedures for 
non-member verification.
keesan
response 35 of 127: Mark Unseen   Mar 18 01:47 UTC 1999

How about giving out a few free memberships to anyone who can demonstrate that
they are unable to donate $6/month for a paid membership?  And require them
to provide the same id as all other members.  (dial ins only).

You can ftp at the library, we have done it, faster than on grex.
rcurl
response 36 of 127: Mark Unseen   Mar 18 01:52 UTC 1999

I would not support that. The minimum dues are already very low, but
still represent a committment of support. I would have no objection
to *others* donating the $6 for the penurious to become members. 
aruba
response 37 of 127: Mark Unseen   Mar 18 05:04 UTC 1999

Re #33:  Grex currently has 11 dialin lines.
fadedx
response 38 of 127: Mark Unseen   Mar 18 10:03 UTC 1999

i think your $6 a month is perfectly fair, in fact i just started this 
service about a week ago and tommorow i'm sending in my $.
aruba
response 39 of 127: Mark Unseen   Mar 18 14:28 UTC 1999

Thanks!
devnull
response 40 of 127: Mark Unseen   Mar 18 14:57 UTC 1999

Re #35: That seems like a reasonable alternative to me; I'm not sure whether
I prefer to give the poor free membership, or give everyone within the local
calling area outgoing access.  I do think the latter has the advantage that
only people who really care about grex will be able to vote, which may be
a win.
keesan
response 41 of 127: Mark Unseen   Mar 18 16:28 UTC 1999

I got the impression that only people who were both members and cared about
grex bothered to vote anyway..  What was the 'turnout'?  (I forgot).
 0-17   17-41   42-66   67-91   92-116   117-127     
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss