|
Grex > Coop11 > #49: Reasons to not allow verified non-members net access | |
|
| Author |
Message |
| 10 new of 57 responses total. |
srw
|
|
response 48 of 57:
| 
Dec 6 20:24 UTC 1998 |
My thoughts mirror scg's resp:39 fairly closely, but I will put them in
my own words.
There was a long gap of time between when the member vote took place
regarding which services should be open-access and the subsequent
implementation of that policy. During that interval, as I recall (only
vaguely after this much time) there was a big shift in usage. Most
notably, gopher services on the net were substantially replaced with
http services. Although this was gradual, the substantial conversion
from gopher to http took a surprisingly short amount of time. Note:
there still are gopher servers out there, but very few.
When the policy was implemeted I do remember a discussion about the
question of whether we should implement a modified version of the kernel
blocks, including http along with gopher among the open-access services,
since it had largely replaced gopher by the time of implementation.
I am confident it was discussed at a board meeting.
My interpretation is that the staff implemented what it thought was
the intent (if not the letter) of the member vote by transferring http
to the open-access side. As I recall from my memory of the many
discussions regarding this vote, the intent was primarily to open some
things up (as opposed to restrict opening things). I definitely played a
role in this staff decision, but I would *never* implement what the
voters did not want me to. Probably the disparity between the member
vote and the actual code in the kernel blocks was never reconciled by
having another vote, although it should have been.
The system has worked this way for along time now. I think it would be a
huge mistake to block outgoing http access to free accounts. If we were
to vote now on this one access issue, I would support keeping it open.
|
aruba
|
|
response 49 of 57:
|
Dec 6 22:59 UTC 1998 |
I certainly don't want to change the de facto policy either, but I think
we should make it official, so I'll propose it at the next board meeting
(unless someone beats me to it.
|
remmers
|
|
response 50 of 57:
|
Dec 7 00:45 UTC 1998 |
I fired up Grex's mighty online search engine (otherwise known as
"grep") and managed to track down the online discussion on opening
up http. It's in Coop 7, Item 93 (item:coop7,93). The reasoning
presented there for doing so was essentially as Steve recollects
it in resp:48.
The feeling seems to have been that board ratification would be
sufficent, and there was mention of bringing the issue to a board
meeting, but that apparently never happened. There's nothing on
it in the agenda item for that month's board meeting (item:coop7,102)
or the minutes (item:coop7,107). So that step evidently just got
forgotten, until now.
(I do recommend reading the agenda item -- Coop 7, item 102 -- for
its entertainment value. It goes on for 93 responses, most of them
having to do with the concept and propriety of the board having
pre-meeting dinners. Amazing stuff. I'd totally forgotten the
discussion ever took place.)
|
rtg
|
|
response 51 of 57:
|
Dec 11 04:40 UTC 1998 |
As I read this whole discussion, I find myself boiling it down to a single
question: What is the maximum level of service we can provide with the
limited resources we have available?
In the light of this, and the general feeling that our internet connection
bandwidth is the single most limiting factor, I ask why we allow ANY
protocols to pass twice over that link? It seems ridiculous to me for
anybody to be using telnet to come into grex, and then expect to go back
out the same link with http or ftp or whatever.
We are here to serve as a community bulletin board, and as an educational
resource. To me, this means that we provide our local services such as
bbs, party, and the tools necessary to write and compile simple programs
so that people can get an idea of how these magic boxes work. As a
service to our geographical community, we provide dialups, email, lynx,
and possibly telnet access to other systems.
I have made the assumption that if a user has the capability to run a
telnet client to access our locally-provided services, then they also have
the capability to run lynx or ftp locally, so it's a waste of our cpu and
especially bandwidth to run them here.
There are lots of people who share internet access with family members, or
have their only internet access at work, so I see us providing a real
service to allow our 'remote' users to receive e-mail here. (aside: What
is the total cumulative data flow for a POP3 session downloading n
messages, vs a telnet session running pine, paging through the same
messages slowly? Would POP3 allow us to serve more users more
efficiently?)
The other protocols they can run themselves, so why do we allow them to
telnet in, then surf from here?
I would support a proposal to broaden the access we allow to dialin
local users, whether they are paying members or not, and severely restrict
the use of any outgoing protocols by remote telnet users, whether they are
paying members or not.
I guess I'm making the assumption that if someone comes here to do
something they could just as easily do at home, then they must be up to no
good, and they're trying to hide behind us.
|
mary
|
|
response 52 of 57:
|
Dec 11 11:23 UTC 1998 |
Good response.
|
davel
|
|
response 53 of 57:
|
Dec 11 12:17 UTC 1998 |
As to why someone might reasonably telnet in & then access the web, consider
me. If I am telnetted in to Grex, it's from a shell account at work. From
that system (and in fact from anywhere) I do not have an ISP account providing
web access. Coming in from work I'm most likely (not always, but usually)
on to get some kind of information for my job. I may find something that has
a URL in it. I can run lynx as well from work, but not while I'm telnetted
in to Grex. (In principle I can suspend the telnet session, but in practice,
when I'm telnetted to Grex in particular, that usually means my connection
will be hung when I get back to it, for some reason.)
|
steve
|
|
response 54 of 57:
|
Dec 11 13:01 UTC 1998 |
There certanly are legimiate reasons to do that, yes. I don't think
we can make blanket statements about the validity of this kind of thing
which of course only makes it harder, trying to come up with policies to
restrict it.
|
sironi
|
|
response 55 of 57:
|
Dec 14 08:05 UTC 1998 |
From Italy I reach better (more speed) north-american sites with lynx on
Grex than using lynx on my own machine.
luca_
|
rtg
|
|
response 56 of 57:
|
Dec 16 06:08 UTC 1998 |
I hear you luca, and just read essentially the same comment from spiff in
another item. Thanks for your input.
|
janc
|
|
response 57 of 57:
|
Dec 16 06:13 UTC 1998 |
I think I'd be willing to support opening telnet and ftp to non-members
coming in on the dial-ins, but I'm not willing to reduce any of the
access now given to people coming in over telnet. I don't see a need
for any reductions in services now.
|