|
Grex > Coop11 > #84: outgoing internet access for non-members | |
|
| Author |
Message |
| 25 new of 127 responses total. |
dpc
|
|
response 17 of 127:
|
Mar 16 14:53 UTC 1999 |
I'm with STeve on this.
|
janc
|
|
response 18 of 127:
|
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:
|
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:
|
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:
|
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:
|
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:
|
Mar 17 01:19 UTC 1999 |
Ack yes, leave me telnet! I use it a lot.
|
devnull
|
|
response 24 of 127:
|
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:
|
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:
|
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:
|
Mar 17 12:48 UTC 1999 |
I would volunteer to be a validator. I bet others would too.
|
dpc
|
|
response 28 of 127:
|
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:
|
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:
|
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:
|
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:
|
Mar 17 19:57 UTC 1999 |
GIF ?
FSF ?
|
prp
|
|
response 33 of 127:
|
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:
|
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:
|
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:
|
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:
|
Mar 18 05:04 UTC 1999 |
Re #33: Grex currently has 11 dialin lines.
|
fadedx
|
|
response 38 of 127:
|
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:
|
Mar 18 14:28 UTC 1999 |
Thanks!
|
devnull
|
|
response 40 of 127:
|
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:
|
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).
|