There would be three classes of accounts: User Account: No Internet access. Can send and 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.150 responses total.
I would support that.
First edit: Change line 1 to read there would be
First Edit: Replace "There would be" in then first line with "There shall be"
I support this.
I support this.
May I make a suggestion? I think access to compilers and interpreters (except for the shells, of course) should be restricted to validated users. This would prevent many of the attacks that come from the inside. Are there any non-shell scripts (e.g. perl or python) that are essential for non-validated users?
I'll go a bit further and suggest there be some speed bump to people being able to POST to the conferences. Not necessarily social validation, but something that would require Grex sending mail to the user and getting a response back. This is a pretty standard expectation out there for good reason. Sad but true.
Along with my suggestion in #6, you might have to prohibit non-validated users from being able to upload precompiled programs from elsewhere, too. Or is there a way to prevent programs from running from the user's home directory that I'm not aware of?
resp: #8 You could put unvalitated users' home directories in a folder on another slice, and mount that slice noexec. Part of the "turning up" script that is run when they are validated would migrate their home directory to /home (or /users or /export/home or /a or /c or wherever we are putting users' directories).
resp: 9
I forgot a couple of things. Warn users to use ${HOME} instead of
hard-coding something like "/export/home/m/a/maus".
You could update newuser to only give the choices of party or rksh or a
menu and this would also limit the damage. Maybe part of the validation
email would require the user to pick a shell from a broader list (like
full ksh or bash or tag-c-shell) if they want.
Or send the two big, mean leather-dykes named Guido (Hi, Guido) to rough
up anyone who intentionally tries to break grexserver.
Could I have some proposed wording changes here, please?
The wording changes need to be to the above proposal. Please distinguish between policy and what staff would have to do to implement the policy. We do not need to include directions to staff on how to make it happen. Only what we want to see as a result of staff actions.
Mary, I'm with you, and think we should remove the ability to participate in conferences from User to Community User. Unicorn, could you give a suggested wording that would put "access to compilers and interpreters other than shells" into the Validated User group. Is that sufficiently precise that a staff member could implement it? How would you word "upload precompiled programs" if it needs to be a separate policy? Or is there a wording that would give staff the go-ahead to do what you and maus are suggesting?
Well, for my suggestions, the first and third sections could read as follows: User Account: No Internet access. May not compile programs or run user-written scripts except shell scripts. Can send and receive mail only to local Grex account, use Unix shell, participate in party and the conferences. Validated User Account: Full net access. Full access to the Internet, including telnet, ssh, ftp and http. May compile programs and run user-written scripts.
cmcgee, your response slipped in ahead of mine. I think that "May not compile programs" would imply that uploading precompiled programs is also forbidden. Or do you think it needs to be explicitly spelled out?
Maybe this would be clearer: User Account: No Internet access. May not compile programs or run user-installed programs or scripts except shell scripts. Can send and receive mail only to local Grex account, use Unix shell, participate in party and the conferences. Validated User Account: Full net access. Full access to the Internet, including telnet, ssh, ftp and http. May compile programs and run user-installed scripts. Changing "user-written" to "user-installed", and adding "programs" in the first case should make it clear that compiling elsewhere and uploading is also forbidden.
I endorse bringing this to a vote. (And suggest that folks consult the bylaws regarding timelines & endorsement requirements.)
I loved the origianl draft (#0) - don't like the modifications! A LOT of people use Grex to code and don't want to waste time on party and the BBS. Our offenders are a few well known pests, why force the large mjaority of shell users to suffer our community needlessly <g>. In any case noexec won't solve the problem, they'd just put the stuff in /tmp.
Well, noexec could just as easily be used on /tmp, couldn't it? And I'm interested in how you know that a lot of people use grex to code if they don't spend time in party and the BBS to tell you about it. Besides, nothing's stopping people who want to code on grex from getting validated so they can do so. It won't cost them anything, after all.
A standard practice should be to have /tmp and /var/tmp nosuid,noexec for precisely this problem. Requiring validation does not introduce an unreasonable barrier to being able to write and execute custom codes, but does provide a control to deter pests.
vivek, I'm curious about what impact you think validation would have on the users you are talking about.
This response has been erased.
This response has been erased.
Re #21: people may leave.
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?
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>).
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.
I do, but the issues remain issues.
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.
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.
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.
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].
> 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..
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.
Mike, always the voice of reason. :)
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.
Mike, I like the story. It's a scary one, for sure. Good thing nobody is talking about doing the same with Grex, eh?
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.
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.
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).
I wholeheartedly support this proposal and will definitely be voting for it.
I support this being brought to a vote.
As do I. Did I already say that?
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.
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.
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...).
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.
I think validation should be required to use any type of email including local. It is too open to abuse.
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.
As written, the proposal puts local grex email privileges in the Community User group.
Dan, would unicorn be able to set up and run the vote admin program?
As written, the proposal puts http access in the Validated Users group.
Regarding #51; I think that would be great!
#44: "Can receive mail only to local Grex account" Do you mean "from local Grex account"? "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." How will they respond if they don't have local e-mail access? Maybe we need some kind of script that allows communication with helpers without going through e-mail. Is that what you had in mind?
Regarding #54; I think the idea is that they can only receive local mail. That is, a validated user can send an unvalidated user an email, but not the opposite. As for how they will respond, I was envisioning some kind of web based form thing wrapped in a script, perhaps integrating with our existing RT database.
Yes, I'm suggesting that new accounts be able to receive mail, but not send it. I was thinking that they could receive both local and outside mail, but am willing to eliminate "outside" if I hear good reasons.
Isn't spam just about the only kind of outside mail that a new user would be likely to receive? Becoming an instant spam target doesn't strike me as the the best first impression for Grex to make on a newcomer.
Sometimes signing up for a web-based service requires that you provide a valid email address to which they can send email. I can see allowing a person to set up such an address. It is not necessarily true that the mailbox will automatically be filled with spam.
For technical reasons, it would be better if Internet mail were withheld until requested. In particular, if we *don't* do that, there's nothing preventing another seabass from creating a .forward file with everyone on grex in it, and then sending himself mail from, say, a hotmail account and having it go to everyone on the system once again.
New users could be asked to provide an email address outside grex to which some questionnaire could be sent.
No, that's exactly what I'm trying to avoid. I don't want people to have to have an email account somewhere else in order to get one here. Dan, are you saying that having in bound email only (not outbound to the internet, and not outbound to Grex) would still allow that particular exploitation?
Yes. Inbound mail from the Internet would allow that attack.
This response has been erased.
------------------ User Account: No Internet access. Can 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. ------------------- Amended to eliminate even local email from the initial user account. I am told that we can allow social validation without requiring a different email address (at least for now), so my main concern has been answered.
Complete Text, Third Version: There would be three classes of accounts: User Account: No Internet access. Can 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.
pretty good ... still the problem of user email response for validation. and promotion. is is sit feasible fo ruser to ahve local-eamial onluy? both send and receive inside grex but nothing from outside grex at all? i;'m assuiming somewher above that vailidated includes those-who-are-aleready -known. ... ?
Regarding #66; We'll rig something up for validation, but no, we can no longer afford to give totally anonymous email accounts out anymore. :-(
Regarding #65; I endorse bringing this to a vote.
No, this proposal will not allow new users to have any kind of email, inside or outside of Grex. You will have to be in the Social Validation group to get any email access at all. Staff has said that there will be a way for new users to request social validation without supplying an off-Grex email address.
I support bringing this to a vote.
I reiterate my endorsement and suggest others endorse as well.
As a user interested in the wellbeing of Grexserver and Cyberspace Communications, I support this, but as a non-member, I cannot formally endorse this. I would like to see this happen, and hope it will curb the abuse.
"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." What kind of response? Anything? Even f... you? It doesn't say that the User has to say "where or how they found out about Grex" - only that they respond (nor that they respond truthfully). (I'm also not sure what utility this has - but I have not read the whole item.)
We have deliberately left this up to the discretion of the Grex Helper.
off topic but would it help if staf mails the staff on other similar systems like sdf etc and ask how they are tackling the spam problem?
erm ... If the user does not have the ability to send even local email, how is he or she going to respond to the email asking how he or she found out about Grex? (As specified as the method for validation.)
Staff has a plan. I'm not sure what it involves, but that was a critical component in the way I wrote this. It is clear that vandals have made use of local email access, so there really is no way to remain a good net citizen and allow that. If the staff plan doesn't work, we will then have to have an off-site email address in order for the validation to occur.
Can I make what I hope is a fairly common-sense suggestion -- which is that you come up with whatever procedures, implement them in a kind of practice or test mode first (e.g. creation through a "newnewuser" account creation process..), have some people try to use them, make sure the limitations work, make sure the "promotion" procedures work, etc.. In other words, work all this out, including the procedures, using volunteers first, and only THEN change newuser to make this the new standard (assuming that this scheme is even approved in the first place.)
Sure, but we need to have the policy in place before we can do anything.
And how and when do we get to sign up those of us that want to be helpers [and get the basic 'training']? Is this going to be discussed at one of the upcoming board meetings?
Yes, I think we can certainly add an agenda item for the next board meeting to formalize the process a bit more.
McNally, unless staff can come up with a workable solution, we will have exactly what is posted in this item: A Grex where you cannot get social validation without an offsite email address. I'm really really hoping staff can make that work. But I'm not willing to leave us in suspended animation any longer waiting for that to happen. People are currently exploiting our openness to vandalize individuals, Grex, and other systems. We need to stop that.
I support bringing this to a vote
Folks, there's email, and there's Email. We can certainly create some way to send messages to someone that *look* like email, and to get a response back. Perhaps, ``cut and paste this into the grex terminal'' sorts of things that run some kind of script.
This item was originally posted on August 6, 2007. The final text was posted on September 4, 2007. By the end of September 6, 2007, 6 members had endorsed bringing the proposal to a vote. As of today, we have 56 members, so 6 members constitutes more than 10% of the membership. I've been asked to run the election. Unfortunately, I don't have enough time right now to set up the election. I will make time to set it up tomorrow, to run for 10 days. The voting booth will open at or about 00:01, Tuesday, September 11, 2007.
Thanks Joe!
If I did everything correctly, the voting should start at midnight. Both terminal and web access should work. If not, someone who knows how should give me a call, when the/a problem is discovered.
waht about CURRENT well-knowns? or is this *solely* new loginids?
The voting booth is available if you use www.cyberspace.org For some reason www.grex.org shows me the older webpage. Perhaps it's a browser cache problem. Telnetting in to vote does not work. I've informed Gelinas of the problem, and he will take care of it in the morning.
TS, no one who currently has email access will lose it because of this proposal. Logins that currently do not have email access will automatically be in the User group, and will need to go through the process to be promoted to the Community User group.
Yep, browser cache issue. Refreshing the page gave me access to the voting booth.
(Could I suggest making the voting booth link on the main page "secure" (i.e. https) to that login and password won't be sent in the clear.)
Also, the web voting form should contain the full wording of the proposal.
John, has the complete voteadmin procedure been documented? Apparently what Joe has access to isn't easily understandable.
Vote program installation and configuration is documented on the "Grexdoc" CVS server; see e.g. ~remmers/grexdoc/vote/doc. I guess conventions of a non-technical nature like "what to put on the voting form" aren't spelled out. What I always did was to put the full wording of the proposal and a link to the Coop discussion item. Those can easily be added by editing the relevant files that reside in the /var/spool/vote directory.
I know this doesn't have to do with the voting but I'm not sure which item to ask in--and this is the closest one I see about members... I read somewhere here [on one of the links or something?] that there is a grex ' handbook'. Is that still around somewhere, and if so, how can I get ahold of one? Thanks.
The voting programs were installed as per the grexdoc documentation (by me). I think the questions are about the softer side of running a poll.
FYI, I don't think the vote is properly configured (or maybe I'm just
confused):
: grex 1169; vote
*** Welcome to the Grex Voting Booth, cross! ***
Improper format in candlist
: grex 1170;
cross, that is the problem cmcgee mentioned in *89 above. It's fixed now. I've also secured the web voting booth and added the full text of the proposal, as suggested by remmers. I'll add a link to the discussion when I figure out "peek."
so would it be a one time payment of a dollar? how would this affect the users that create tons of accounts only to harass and abuse other grexers and such?
I added the link, but not by using 'peek.'
resp:100 I believe that since they would have to use something like Paypal, it would tie a real-world identity (i.e. one that can have its internet access revoked by its IAP or one that can have criminal charges leveled against it). Additionally, if a person made and activated a whole bunch of accounts with the same Paypal ID, it would raise red flags, and remedial action could be taken when the accounts are activated, rather than waiting until they start being used for abusive purposes.
Chad, there is no requirement that anyone pay anything. The paypal $1.00 option is only if you do not choose to submit the other photo ID options. Paypal accounts are tied to real people, that can be traced. If any account was used to violate our Terms of Service, all accounts tied to that person would be blocked and no new ones issued. Spamming conferences, individuals, and other denial of service attacks are sufficient to get your accounts blocked. Criminal activity would be prosecuted. All accounts tied to that person would be blocked and no new ones issued. The point of validation is to give us access to the identity of the person creating the accounts. The initial validation will also be sufficient to recognize a personality behind the facade, and will evolve to meet our needs to achieve that recognition. If we can't do that reliably, I will suggest we remove the intermediate class and only allow verified accounts. If we continue to experience our current levels of user harassment and destruction of the community, it will be our best option.
The voting program is somewhat confusing. Choose between candidates no (y/n) and yes (y/n). For instance, vote n for no and y for yes. I tried to vote 'y' twice and was scolded.
That sounds right. You are only able to cast a vote for passage (yes) or defeat (no). You can't vote yes on both.
Yes, the terminal-based version of the vote program is a bit confusing, and I'm afraid it's my fault. There are actually two separate "vote" programs, one for board elections and one for member proposals. I thought I had documented how to install and configure both, but upon looking at grexdoc, I see that I only included instructions for the board election program, so that's what's running. It's usable for voting on proposals too, but the interface is more tuned for voting on candidates in an election. Hence if you want to vote for the proposal, you have to vote "y" for Yes and "n" for No, which works but is definitely weird. I suggest we live with the strange interface for this election, and I'll update the docs so that future proposal votes get a more suitable interface. Apologies.
I'm going to support this proposal, but, upon closer inspection, I do have a concern. The wording is overly specific for a membership vote. If the board or staff should want to change what specific question is asked during the social validation, they are pretty locked in by this vote. Likewise for when accounts get reaped or even what is considered a minimum PayPal payment. Too much detail is hard coded to allow for tweaking. The board could, of course, vote to change any of the stated details, But they'd be overriding a membership vote. We've been pretty darn careful to avoid setting up that situation up until now. I'm sorry to mention this so late in the process. My fault for not reading response #66 as the final wording.
*sigh* I understand. But let's get this passed, and tweak it later. My suspicion is that it will need to be revised after we have a bit more experience with the "Community User" class and process anyway.
Regarding #107; Valid concerns. I agree with Colleen; let's get it passed, and then amended with another membership vote. I think that's probably the cleanest solution.
No, it's not clean. It's more quick and dirty. ;-)
This motion cannot be voted on because there are only five members who support
bringing it to vote. My guess is gelinas counted nharmon's response 4 ("I
support this") as an endorsement of bringing the motion to vote, but section
5.c. of the bylaws makes it very clear that for an endorsement to be
considered, it must consist of a statement to the effect that the motion
should be voted on.
Regarding #110; You're right, but it's cleaner than the board modifying a member proposal after the fact.... Regarding #111; Check out the legal definition of, ``reasonable interpretation.'' Nate, would you care to clarify your statements?
I also add that I should not be counted as endorsing bringing this motion to vote. While I support the motion and have made statements to that affect, I do not believe there is enough support among the membership to make this a worthwhile vote.
I also contest cmcgee's statements being construed as an endorsement to bring this to vote. While she she did state that the motion was ready to be voted on, that does not imply she AGREED the motion should be voted on.
Well to be clear, *I* do support bringing this motion to vote. Since it is a board initiative, I believe that, as an individual, I can support this proposal.
You didn't make an endorsement before the deadline.
you can certainly interpret my asking to bring it to a vote as an endorsement to bring it to a vote.
My preferred alternative is to finish this vote. Another option would be for the board to pass this as policy, and implement it immediately. Then we can patiently wait until such time as the membership can get its act together, and vote it up or down. While that's not a better alternative, it is one I'm willing to entertain.
No, you can't.
The bylaws are very clear:
Endorsement shall consist of a statement by the
member in the discussion item agreeing that the motion should
be voted on.
In response #45, you stated "This is ready to be voted on." This is simply
a statement that in your opinion the appropriate conditions had been met for
the motion to be voted on, but it cannot be construed as an endorsement.
I say that that's what I meant. Are you telling me I don't know what I was meant?
It's possible that's what you meant, but it doesn't meet the very clear criteria for an endorsement required by the by-laws.
David, knock it off.
Knock what off? Making sure Cyberspace, Inc. follows its own by-laws? People were told repeatedly in this very item to make sure they followed the requirements for endorsements and not many of them did. That should tell you something. I'd appreciate it if gelinas could post a list of the people he considered to be endorsing this proposal as well as the statements they made that which he considered to be their endorsements. According to a post he made, there were six such people -- only one more than the minimum required to bring a motion to vote.
You're being pedantic in arguing semantics; why?
This response has been erased.
please do.
I think the way people are trying to railroad this through, especially cmcgee's threat to do it even with the anaemic support we're receiving from the members, is a disturbing departure from the way Grex has functioned since its inception. That's the short of it, and I'll post the long of it, including better solutions to the problems Grex is facing, in another item when I have a bit more time.
When I said "I support this", I meant I supported this measure to be voted upon by the membership. I'm sorry I was not clearer.
Let's be clear here. Mark Conger first raised this issue in this conference on March 31, 2007, for inclusion in the April 1 board agenda. A through explanation of the board discussion was posted on April 2nd. We have also had more than a month of discussion since I posted the initial draft on August 6th. This seems to be a fairly traditional pacing for discussions and decisions on Grex. If anything, it may be overly slow. You, scholar, have visited this conference frequently since then. You have had numerous chances to contribute to the final shaping of this proposal. Now you get to vote on it. It may pass, it may fail. If it passes, the Board will implement it to the best of its ability. If it fails, the Board will try to solve the problems some other way. Stopping the vote will not stop the problems, nor the Board's duty to try to solve them.
Hey, guess what, the membership wants the Board to follow the by-laws.
I can see Grex is continuing with its illegal vote...
And why are you getting so excited about what you perceive to be an "illegal vote"? Are you not the one who tried in vain to convince me to forge a message in someone else's name to support the proposal, and got all upset because I refused to do it? And are you not the one who then suggested that if I was unwilling to do that, that I should go ahead and set up the vote anyway (under the assumption that because it was suggested by cmcgee that I take that responsibility, that the responsibility was mine)? And again, are you not the one who got all upset because I refused to do so? And now you're pretending to be the ethical one who insists on doing everything by the book? Why is that?
I support bringing this proposal to a vote. Sorry, I hadn't been paying attention and forgot about that requirement.
(( MOTD announcement about the election should be updated to include
the END of the voting period, which is now of more concern to
voters than the BEGINNING of the voting period. I'd do it myself
but I don't know when the end is... ))
krj, try refreshing your browser cache. gelinas fixed that on Saturday.
I see. The MOTD is not changed, but the Backtalk page is.
re. 133: it's too late for your support to be valid. re. 132: it's not too late for you to start making some sense here.
I finally got onto the machine today. I've now updated the motd. I re-counted the endorsements; I found, in addition to nharmon, support for voting from remmers, mary, cross, scholar, gelinas and slynne, all seven of whom are members.
At no point did I endorse taking this motion to vote.
Assuming the online member list is up-to-date, there are 56 members, so 6 is a sufficient number of endorsements.
If you want/need another, I endorse the vote...
"I wholeheartedly support this proposal and will definitely be voting for it" (scholar, response 41 above). "I reiterate my endorsement and suggest others endorse as well" (scholar, response 71 above).
Right. I was endorsing the proposal, NOT endorsing taking it to vote. Same with Nate (He said something like 'I support this').
It should also be noted that my interpretation is the one set out as correct by the by-laws, and that hcmsgee didn't endorse taking the proposal to vote either.
The Treasurer has certified the list of voters, and I have counted the votes. Twenty-four people, fifteen members and nine non-members, voted. The members voted 14 to 1 in favor of the proposal, so the proposal passed. The non-members voted 6 to 3 in favor of the proposal.
Party-land has a couple of returning long-time users who "we" would like to get tel and mail privileges added for. Their old accounts were reaped, so they appear as newbies under the new rules. How're the implementation details on this coming along?
As I understand it: cross finished the "add first class (new) users to the second class group" script before he left; unicorn and gelinas are each looking at how to put second class people back into first class" script. Board created the "porters" group at last board meeting; gelinas populated that group with the board members. Next board meeting we need to add any other members to the porters group, and decide how to handle inter-group communication for the porters. Then we can start adding first-class users to the second-class group. Primarily we're waiting on the completion of the script. Right now, you can send mail to help@grex.org asking staff to add specific userIDs to the 2nd group. As always, staff will be the ones to decide whether to block a user ID. Porters will only be able to move IDs between the two groups.
(I see that the group "porters" exists and has been populated as cmcgee described, but I didn't do it.)
uhhh, ok, it was unicorn then.
(Credit where it is due, Ma'am. ;)
You have several choices: