|
Grex > Coop > #39: Member Proposal: Create Three Classes of Grex Accounts: Users, Community Users, Validated Users |  |
|
| Author |
Message |
| 25 new of 150 responses total. |
cmcgee
|
|
response 25 of 150:
| 
Aug 9 03:56 UTC 2007 |
what is causing them to leave? Is it because they have no way to be validated
(like Paypal)? Is it because they don't want to be validated even though they
could be?
Is it because a shell account isn't enough to teach them anything?
What are they getting out of Grex that would change?
|
vivekm1234
|
|
response 26 of 150:
|
Aug 9 10:15 UTC 2007 |
Re #25: "Is it because they have no way to be validated (like Paypal)?"
No easy and quick way to validate - college students using credit cards
are more the exception than the norm out here, so they'd have to ask
parents or friends - It's not that they don't want to pay 1$. That's
just 40 Rupees or 4 Pepsi glasses or 4 ball-point pens - nothing! What
makes it messy is the credit-card/parent required bit.
"Is it because a shell account isn't enough to teach them anything?"
Shell access is a convenience the way i see it - most of them will just
download and install Windows/Linux, but what if you want to access Unix
from a college computer in the browsing center? Grex provides a easy,
uncomplicated and quick way to get to Unix without the hassle of
tackling a complicated install. Most people will have Windows and data
taking up the whole drive, so they don't need to repartition when they
use Grex.
"What are they getting out of Grex that would change?"
Right now you get perl, ruby, python, gcc, g++, expect, man, mail, vi,
bash, csh, ksh, mount Gahh! You get everything right now, a whole BSD
box with bells and whistles in less then 1 minute after you hit Grex's
telnet port. If that isn't great I don't know what is! Have you seen the
hoops the other shells make you dance through!
"what is causing them to leave?" - Once they finish their course,
project, loose interest they leave. They aren't a part of this community
- they use the box to learn and they don't want to waste their time with
trolls and clueless noobs . Look at Gina, she left because she wasn't
getting any return on her investment - i can barely scratch out a
program, Chad goes hohoho - what the heck is she going to do on party?
Same story on the BBS, given that we compete against Google.
WE DON'T HAVE PEOPLE - the only reason new people come here is because
of the shell - raising the entry bar will make things harder for sane
people to get in.
Don't complicate matters for now, 1 easy and small step at a time. Let's
first restore mail for non-troll accounts (Community User Accounts).
Then opening up web access to some of our forums (hardware, science,
unix, kitchen, music, books) would be the best possible advertisement
and should get us some users (Captcha is a must for backtalk).
Then if all else fails, we will be risking less when we ask our regular
hello.c users to validate shell (this would be our very last resort -
death rattle as i see it <g>).
|
cross
|
|
response 27 of 150:
|
Aug 9 14:49 UTC 2007 |
I really don't think we should restrict access to things like compilers and
interpreters. Honestly, I don't see that it's going to make much of a
difference.
|
pfv
|
|
response 28 of 150:
|
Aug 9 22:13 UTC 2007 |
I do, but the issues remain issues.
|
unicorn
|
|
response 29 of 150:
|
Aug 10 00:44 UTC 2007 |
Okay, maybe requiring validation is too strict, but since it *is* how
much of the abuses are coming about, I think it shouldn't be automatic
for new users. Being able to use compilers and interpreters is a
privilege, and those who are abusing the privilege need to have it
revoked. Automatically giving that privilege to new users prevents
that. Treat it like access to e-mail. There has to be some way
to ensure that the people who have access to those things are not
likely to abuse it, and maybe one of the things that needs to be
checked is where they're connecting from. If it's a Tor host,
they shouldn't be given access.
|
cross
|
|
response 30 of 150:
|
Aug 10 01:55 UTC 2007 |
The shell is an interpreter; should we cut off access to that, as well?
I would submit that most of the abuses (a) don't affect the vast majority of
grex users (who never use the conferences or party, etc), and (b) are due to
known issues with software that we have installed, poor or outdated defaults,
etc.
Cutting off access to compilers and interpreters because of a few bad eggs
is like moving your house into a secure vault because a fly got through a
hole in your screendoor. Ie, it is not an appropriate response given the
level of threat.
|
vivekm1234
|
|
response 31 of 150:
|
Aug 10 04:12 UTC 2007 |
Re #29: Great points. I agree that anonymous-hosts should be given a
restricted-shell, but it's going to be hard to implement? We'll need to
modify login to change the shell every time it's a anonymous-host? What
if he uses loopback/su/login?
Right now i feel we should push #0 through without delaying that! We can
always discuss the modifications, get some working code and then push
that through as a separate proposal at a later date - if required.
|
denise
|
|
response 32 of 150:
|
Aug 14 01:14 UTC 2007 |
I'm not up on the various shells and such, though I realize that's all
of what apparently many users only access. So to what extent they can
or can't provide problems to grex, I haven't a clue. But it there ARE
ways to use them easily to cause problems, then I agree that there
should be different access levels.
The stuff that I do notice, of course, are the people that abuse the
conferences, party, emailing, that sort of thing. So I agree with Mary
in her response that we should do some kind of validation before
newusers are allowed to post. Of course, by being able to READ the
conferences, they may be [more?] interested in becoming validated [or
maybe not].
|
mcnally
|
|
response 33 of 150:
|
Aug 14 05:37 UTC 2007 |
> I'm not up on the various shells and such, though I realize that's all
> of what apparently many users only access. So to what extent they can
> or can't provide problems to grex, I haven't a clue. But it there ARE
> ways to use them easily to cause problems, then I agree that there
> should be different access levels.
(This response isn't really directed at Denise, she's just the latest
to echo a sentiment that I am strongly opposed to..)
So here's the thing.. I hear people talking about "we must do this"
or "we need to do that" to protect the system, and I hope that before
anything rash gets decided we can step back and take a look at the
problem dispassionately. That's not always easy when someone keeps
poking at your tender spots, or dancing around going "hey! look at me!"
but it's kind of important to try.
I'm going to tell you a little parable I made up, which I will call
"The Parable of the Vandal." So without further ado..
--
The Parable of the Vandal
Once upon a time there was a happy family who were friendly and
hospitable to everyone who came to visit them. The doors of their
house were never locked, and they were known far and wide for their
hospitality. Strangers from faraway would come and stay whenever
they were in the area and the family derived great joy from meeting
new people and making new friends.
But one day, a bad man came along. "I don't like these happy,
friendly people," he said. "I'm going to teach them a lesson."
And the bad man took a rock and threw it through the window of
the house, where it broke a vase which was a family heirloom..
When the family saw what had happened, they were saddened. The mother
said to her son, "Well, I suppose it was inevitable that this would
happen eventually. Junior, go help your father put these shutters on
the windows so this can't happen again."
The next day, while the family were out shopping, the bad man came
back and pried off the shutters with a crowbar, broke another window,
and threw a rock, breaking a small delicate bowl that had been a gift
from one of their guests.
When the family came home, they said, "Shutters were not enough.
We must put boards over the windows and cover them with iron
bars. Then nobody will be able to throw things through the windows.
This was true, but then the house was dark and they no longer got
to enjoy their view.
On the next day, while the family was in the back yard, the vandal
walked right in the open front door and dumped a bag of garbage on
the living room rug, then walked out the way he had come.
"We can no longer leave the door open," said the family. So they
bought locks and bolts and closed the door tightly.
Unable to enter the house, the next day the bad man slashed the tires
on the family's car.
So they spent their savings and built a garage to lock the car in.
After the garage was built, the bad man came back and spray painted
a rude word on their front door.
So Father got a second job and worked hard to earn money to build a
tall fence around the house. And when the fence was finished the
family bought a vicious guard dog and set it loose to patrol the yard.
The dog even bit Mother once when she tried to stop it from barking
at Junior. But at least the bad man couldn't get in any more.
Unfortunately neither could anyone else. The house was surrounded by
a tall fence, guarded by a vicious dog, the door was locked and bolted,
and the windows were boarded over and covered with iron bars. Even if
visitors *had* been able to get in, who wants to visit a prison?
Plus, the family no longer had the time and money to entertain guests,
nor did they trust strangers any longer.
And they all lived unhappily ever after, even the vandal, who,
after all, was a miserable person to begin with..
|
mcnally
|
|
response 34 of 150:
|
Aug 14 05:41 UTC 2007 |
So what's the point of my parable? If it's not obvious, I guess
I didn't do a very good job, but what I'm hoping people will take
away from the story is that (a) the vandal will attack any target
of opportunity. Unless you lock things down so as to be hopelessly
restricted and unattractive to pretty much everybody there will
practically always be something the vandal can do to annoy you;
(b) it's much easier (less expensive in terms of resources and
time spent) for the vandal to attack than it is for you to defend.
(c) in the end, destroying the things that attract people to the
system is a poor strategy.
|
nharmon
|
|
response 35 of 150:
|
Aug 14 12:28 UTC 2007 |
Mike, always the voice of reason. :)
|
cyklone
|
|
response 36 of 150:
|
Aug 14 12:51 UTC 2007 |
I thought the parable was very nice, though I thought it would work equally
well as the Parable of the Terrorist and the Lost American Freedoms.
|
mary
|
|
response 37 of 150:
|
Aug 14 14:21 UTC 2007 |
Mike, I like the story. It's a scary one, for sure. Good thing nobody is
talking about doing the same with Grex, eh?
|
cross
|
|
response 38 of 150:
|
Aug 14 14:55 UTC 2007 |
Well, bit in a way, they are. And *talking* about it isn't necessarily a bad
thing, of course, but *doing* some of it would be. For instance, I really
think it would be bad to block access to compilers and interpreters, for
exactly the reasons Mike points out: too much effort for too little gain, and
at the end of the day, for what purpose? Sure, we *could* turn off the
execute bit on any filesystem that the average Joe can write to, but then what
about people's personal "bin" directories? It's just not worth it.
|
unicorn
|
|
response 39 of 150:
|
Aug 17 22:53 UTC 2007 |
Well, I withdraw the suggestion, then. If you feel we can deal with
the abuses without that, I respect your judgement. I would really like
to leave those things enabled, but then I would really like to be able
to leave my house and car unlocked without having to worry about people
stealing my stuff, too. I was just reacting to the recent abuses, some
of which I know were done with user compiled programs, and at least
one of the perpretrators has been talking openly about doing much more
of the same in the not-so-distant future.
By the way, the reason I felt that interpreters like perl and python
could be treated different from shells was because shells have generally
been less powerful, relying much more on external programs to do a lot
of their work, but thinking about it, that probably isn't so true,
anymore, considering that David Korn has stated that he wants ksh
to be as powerful as perl, and even zsh, which I use, has many more
capabilities than I am even aware of, not having had the time to read
the man pages and other dowumentation for it in their entirety, yet.
|
cmcgee
|
|
response 40 of 150:
|
Aug 20 21:46 UTC 2007 |
Ok, I'm about to submit a revised wording on this. We've had two+ weeks
of comment.
(I was waiting to make sure the upgrade was stable).
|
scholar
|
|
response 41 of 150:
|
Aug 24 06:53 UTC 2007 |
I wholeheartedly support this proposal and will definitely be voting for it.
|
mary
|
|
response 42 of 150:
|
Aug 24 12:47 UTC 2007 |
I support this being brought to a vote.
|
cross
|
|
response 43 of 150:
|
Aug 24 14:14 UTC 2007 |
As do I. Did I already say that?
|
cmcgee
|
|
response 44 of 150:
|
Sep 1 22:21 UTC 2007 |
Ok, here's my amended version. I have removed "send local email" from
the User Account, based on the current conversations in Agora and Garage
conferences.
I considered, but decided against, moving conference participation into
the Community User category.
--------------------------------------
There would be three classes of accounts:
User Account: No Internet access. Can receive mail only to
local Grex account, use Unix shell, participate in party and the
conferences.
Community User Account: Full E-Mail. Users can send and receive email
from or to any address.
Validated User Account: Full net access. Full access to the Internet,
including telnet, ssh, ftp and http.
All new user accounts would be created in the User class.
Promotion from the User class to Community Users class would be by
responding to a email sent by a Grex Helper which asked the user to
identify where or how they found out about Grex.
Promotion from Community Users to Validated Users would require the same
validation that is currently required for membership, either a photocopy
of a government or school issued ID that contains the person's photo, or
by a $1.00 payment through Paypal.
Once an account was Validated, it would not need to be revalidated.
Validated User accounts that had not been active for more than a year
could be reaped at the end of that time. Becoming a member would be
sufficient, but not necessary for becoming a Validated User.
|
cmcgee
|
|
response 45 of 150:
|
Sep 1 22:22 UTC 2007 |
I don't know if we have a vote admin at the present. I believe gelinas
ran the last election.
Could we hear from someone who can set up and run that program, please?
This is ready to be voted on.
|
cross
|
|
response 46 of 150:
|
Sep 1 22:56 UTC 2007 |
Regarding #44; I thought that http access was community? Perhaps I was
mistaken. I think we might want to consider doing that with users creating
web pages as well, to cut down on phishing and the like (then we could also
support images...).
|
remmers
|
|
response 47 of 150:
|
Sep 1 23:04 UTC 2007 |
Re #45: I don't recall that the board appointed a voteadm. It should.
In addition to setting up the voting software, the voteadm should check
that a proposal meets the requirements stated in Article 5 of the
bylaws. At a cursory glance, this one seems to, if 10% of the members
have endorsed bringing it to a vote.
|
keesan
|
|
response 48 of 150:
|
Sep 2 00:13 UTC 2007 |
I think validation should be required to use any type of email including
local. It is too open to abuse.
|
cross
|
|
response 49 of 150:
|
Sep 2 00:35 UTC 2007 |
I agree in principle, but let's be clear about the definition of validation.
We have proposed two types:
a) Social validation, wherein a user makes a request, is asked a question by
a volunteer, and is thus `validated.'
b) Formal verification, wherein a user presents a copy of a government-issued
photo ID or similar some well-defined equivalent to the treasurer or some
other such person.
I'd say we need (a) for email access, (b) would be overkill. (b) is used
for complete outbound network access, on the other hand.
|