At the last board meeting, there was discussion of redoing the way we grant access to different resources to our users. Right now, we have (defacto) three basic categories that people fall into: 1) No access. You're a brand new user, and we give you no access to outbound Internet or email resources. You can still create a web page, and receiving incoming email. 2) Minimal access. You're still a newish user, but you have somehow been granted minimal Internet access and possibly the ability to send outbound email. Minimal Internet access is defined as access to the web (as a client), making DNS requests, using finger, whois, and maybe talk (whether people actually *use* these last three is questionable). 3) All access. You can send (almost) anything you want to the Internet and can send outbound email. Currently restricted to members. These three categories were not necessarily planned, but rather grew up in response to changing conditions on grex and the Internet as a whole. We've never *really* formalized any of the categories, nor how one moves between them. There are some defacto rules and perhaps some old member decisions, but we haven't evaluated this in a long time. I submit that it is now time to do so; in particular, whatever decisions we've made in the past really need to be re-evaluated in light of how the electronic landscape has changed since we made those decisions (probably in the 1990s). What follows are my proposals for how we should handle this issue, as well as my rationale. This item is for discussion of this proposal and this issue as a whole. Please note, I am not a lawyer; I don't understand how this would affect, say, our common carrier status for instance, but I'm hoping that those who do will weigh in. I propose that we maintain the following three levels of access and associated methods for transitioning between levels. Note that each level is a superset of the level below it: 1) No access. This is for new users; they are given no Internet access at all and are blocked from sending and receiving Internet email, though they can send and receive as much local email as they like (for instance, they can send email to staff). This is similar to how things are presently set up. RATIONALE: The Internet has changed drastically since 1991, when Grex first set up shop (though I understand that the first connection to the net did not come for another couple of years). In particular, the Internet is far more dangerous now than it was then. We simply cannot allow access to the Internet, even minimal access, for untrusted users anymore. We have seen too many attacks originate from grex for this to be practical anymore. With respect to email, we've seen that the vast majority of users just don't read email on grex; there's no point in creating them a mailbox that quickly becomes filled with spam unless they ask for it, which brings us to the next level of access. 2) Minimal access. Again, this is similar to the way things are currently set up; we allow minimal access to some common protocols (HTTP, DNS, finger, talk, etc) and allow users to send and receive Internet email, but otherwise constrain there access. One transitions from the no access category to the minimal access category by requesting minimal access. In practice, this will involve running a program from grex's command line; that program will send a message to a team of volunteers taken from the community who, if they approve of the request, will run another program that moves the user to the minimal access category. RATIONALE: This is little different from how we do things right now, except that it combines requests for Internet email access with requests for minimal Internet access, and adds community verification (a term I heard at the last board meeting, though I do not recall who coined it; perhaps cmcgee?). The idea is that the social interaction required by actually requesting access from a human being will be enough to deter most Internet predators. As Steve has observed, most of the people who will abuse grex's services want to remain under the radar and are loathe to do something public and personal (like request Internet access). It's easier for them just to go somewhere else. Further, we tie minimal network access to email since it seems that there is little reason to separate them; in the case where we did separate them, the procedure for requesting access for one would be nearly identical to requesting access to another. It would put an undue burden on both our community volunteers and our users to separate the requests. 3) Verified access. This is full (almost) unrestricted access. (Almost in the sense that a verified user still can't, e.g., allocate a privileged port, for instance). A user transitions to this level by providing some form of identification to grex that validates their identity. This might mean either making a minimal payment via PayPal, or using some form of identification comparable to one of those used for, e.g., gaining membership. Note that all members are automatically verified, but that verification does not require membership. Once a user is verified, that users account becomes non-reapable for somewhere on the order of five years since the last time the user logged in. RATIONALE: It has always struck me as strange that the primary criterion for outbound access has been membership. We say we want to prevent the situation where members are granted special privileges over non-members, but that's basically what ends up happening. However, it seems clear that the intent is to prevent abuse, and to require some sort of verification before granted unrestricted access to the Internet; this is certainly a reasonable step to help mitigate risk. But if that's the case, then let us decouple the notion of verification from the notion of membership. Verified users get outbound Internet access, as do members, but membership is no longer the focus of verification. This will clean up a few edge cases. For instance, what happens when a user who has previously been a member lets his or her membership lapse? That user has been verified and was trusted to access the Internet, why suddenly is the user no longer permitted to access the network? They haven't been *unverified*, they're just not a member presently. We are in a situation presently where some members have decided that given the surplus of cash we have on hand at the moment, grex does not need their continued financial support right now, and have decided to let their memberships lapse. Very well. But why do we take away Internet access from them? We know who they are, we know we can count on them not to attack remote hosts. So why not let them retain outbound access? Further, suppose their account becomes inactive for a time; we went to the trouble to verify them, so lets let them ride inactivity for a little while. We may remove their outbound access until they come back and run some sort of a program to validate that, yes, it really is them logging in again, but there's no need to remove and re-validate the account after only three months. This is my proposal. What do others think?44 responses total.
I support decoupling membership from internet access.
I like it.
As do I.
I doubt that most people who want to use a browser here also want to receive email from outside grex. There are probably also people who want the email but not the other internet privileges. I set up spam filters for people from India, Mexico, and Indonesia who appear to just like using shell account email. So please decouple them.
I just checked and one person (from Poland) is using pine and six are using lynx. This suggests that there are more people using grex to browse than for email, and they probably do not all want the email.
Regarding #4; Well, just because one *can* receive Internet email doesn't mean that one *has* to. One can certainly forward it elsewhere or to /dev/null or just opt-out. And similarly, just because one *can* use a web browser or other minimal form of outgoing access doesn't mean that one has to. On the other hand, if we decouple the request process, that does place an additional burden on the volunteers (these are not necessarily staff members) to authorize the same account for multiple services. It seems like an unnecessary complication to separate the two. Sindi, what's your reasoning? It imposes no additional burden on the user to have something that he or she doesn't use....
It fills up disk space for no reason, and probably puts a bit more strain on the mail receiving software and any future antispam software. Why not just have them request internet, or mail, or both?
#7: That's what I thought he was saying -- just a user wouldn't have to file two separate requests for email and Internet access.
Regarding #8; That is what I'm saying.
Regarding allowing all users to create web pages: M-net, in the policy conference, has reports that malicious users have been using M-net to host phishing pages, and M-net's hosting provider is threatening to cut access if this happens again. Has this been an issue for Grex? Can Grex move fast if it does become an issue? (A phishing page is the page set up to collect financial information, such as bank account information or PayPal passwords, on a fraudulent basis.)
I hadn't really addressed the web page issue. It has been an issue in the past, but surprisingly infrequently. But now that you mention it, it strikes me that no access users probably should *not* have the ability to throw up a web page. However, limited access users probably should; would `community verification' be sufficient to insure no abuse (or at least `managable' abuse) from otherwise non-validated users?
I hate to pull a function before it is necessary for Grex to pull it. Here's a suggestion: If Grex is not being threatened due to phishing pages, allow no-access users to create web pages, as we do today. Obviously staff continues to swat down phishing pages as they are reported. If such a threat arises, then have the hooks in place so that web page creation can be switched to the limited-access category at a moment's notice. This might mean board pre-approving the switch in advance, at staff's judgement.
Why not add a server side include banner on the webpages?
I would volunteer to preapprove any webpages to be posted by non-members, and any changes to them made later.
Regarding #12; I'm fine with that. Regarding #14; One of the purposes of this proposal is to reduce the privileges of `members.' Membership rights should be limited to the governance of the corporation, not access privileges. I think what you meant was, `webpages posted by non-verified users.' But I think that we really don't want to get into the business of `approving' web pages or anything else.
Re #13: Couldn't JavaScript be used to override a server side banner? Re #15 re #14: I agree.
re #16 Couldn't JavaScript be used to override a server side banner? That's a good question and I'm not sure if it's been done. I'm not thinking of pop-ups but actual includes which would be at the top of every webpage.
Javascript could be used to override the server side banner. Maybe with a InnerHTML property.
So you're talking about something that would cover the HTML of the banner? I'm thinking the httpd config could include a shtml at the beginning of all userpages and it would include banner graphic and text plus the TAGS to show it is Grex, etc..
well, if there were a way to have a server side banner, that would be the best solution imho.
Javascript allows you to dynamically change the HTML.
At the very least, Grex should have some language in its terms of use that empowers staff to take web pages off-line in response to complaints about things like phishing. It should be a clearly defined system policy and without authorization under such a policy staff shouldn't remove anything -- otherwise censoring one web site and not another could be argued to be implicit approval or endorsement of the other.
Well, perhaps we need more data on the frequency of phishing attempts and the consequences we've been threatened with; I honestly am out of the loop on that right now. I agree 100% with #22, though.
I like the idea of decoupling membership from service, and I think that the tiered access system makes sense, where increased privilege is granted by increased exposure to the staff, thereby increasing personal accountability. keesan, the idea of having to have webpages vetted concerns me, and I suspect it would concern others as well. I would prefer that staff had the right to revoke before giving them the responsibility to vet a page beforehand. Requiring approval before putting up content without some reason to suspect the user in question would have a chilling effect. That said, I also think staff should have a mechanism in place to be able to yank a webpage that violates TOS. I also think it would be a good idea to have the TOS looked over, reaffirmed by staff and reposted in a prominent place when we have the next system upgrade.
From the MotD: } To see statements of grex principles and limits, run } } /usr/local/bin/grex-principles } /usr/local/bin/grex-limits Thus, you can use !grex-limits at the next available prompt. Comments, of course, are welcome. I like the idea of decoupling membership and access levels. I do not like the idea of coupling access levels and donations. Verification, and thus increased access, should NOT rely on a contribution to the corporation. I don't want to get into fees for services rendered.
Boy, those limits haven't been updated in a while, have they? They don't appear to say anything about phishing. Is that in the principles document?
Regarding #25; No, I wouldn't think that verification would be tied to contributions to the corporation; my PayPal example was just one method by which one could be verified. Mailing a photocopy of an ID to the treasurer or some other designated entity would be another method (though, I guess, then one is donating a stamp to the corporation. :-))
Part of the updating could be using terminology that others would recognize ToS. Those filenames would make me think of what the ideals are, and the limitations of the system.
While those two are a good starting point, I would recommend that they
be extended in such a way as to provide a means for enforcement.
Additionally, phrasing it as "it would be nice if" decreases
enforceability. Because the rules are fairly specific, they are harder
to enforce on the edge cases ("well, it doesn't say I can't use my
account to trick people out of their credit card information"). Lastly,
Cyberspace Communications needs to provide a means by which liability
can be transfered to the infringing party; that is, if I use Grex to do
something illegal, Cyberspace Communications needs to make sure that
they have already established legal grounds by which they can sue my
sorry tail if they get sued.
Oh, and the terms of service also need cheese.
I am a little confused why Dan says we've never formalized the internet access categories he describes in #0; the membership category was formalized a long time ago, and the distinction between the first two was formalized at the last board meeting. The content of Dan's proposal seems to be that we should allow people full internet access if they are verified but not members. This was in fact the original intent when Grex first instituted an internet access policy, but for various reasons full access has always been linked to membership. I am in favor, in principle, of allowing verified members full internet access. There are a few logistical problems we need to consider, however. 1. How long should a validation be valid? If I take out a Paypal account today, verify it, pay Grex a dollar, then move next year but don't tell Grex, the validation information from Paypal is not very valid. If I did something destructive and Grex handed over my info to law enforcement, I doubt that they could find me. Now, granted, this is a bit far-fetched; it's unlikely someone will go to the trouble to gain privileges on Grex in order to abuse them several years in the future. But it is certainly possible. If we allow verification to last 5 years, I envision us having a lot of accounts on the verified rolls which have not been logged into for a long time. 2. Someone needs to accept and record validation information. I assume that will be the treasurer (currently me). I don't expect a deluge of people requesting validation, so it will probably be fine; but I am aware that everything that gets added to the treasurer's job will make it harder to find someone to do it in the future. Also, presumably, when a verified account's verification period is up, presumably someone will need to remind (nag) that person to re-validate. I presume that will also fall to the treasurer. If it's been 5 years, it's not at all unlikely that it will be hard to find an email that works. 3. Do we accept the same forms of ID that we always have? Currently that includes school IDs and library cards. (See ~aruba/idpolicy for a description of currently acceptable IDs.) No one has used such an ID in a while, I must say; by far the most popular form of ID these days is a verified Paypal membership. I bring the topic up because if we are reducing the bar required for access, perhaps we should make up for that by requiring a little more ID. (In other words, it's possible that the necessity of sending $6 along with one's library card may have discouraged certain vandals who will not be discouraged by simply sending the library card.) People should be aware that we will probably lose a few members as a result of changing the policy, because there have lways been a (changing) handful of people who become members in order to have the internet privileges. I'd estimate there are 1-5 such members at any given time. We can afford to lose that much income.
I generally become a member in order to have the internet privileges and to vote. Although I would also become a member if Grex needed the money, but that hasn't been the case lately.
Regarding #30; (First Para): Sorry, that was ambiguous; I was trying to give a brief recap of the discussion at the board meeting, but I didn't make that clear. At the board meeting, we said that the access levels had never really been formalized, and then sorta formalized them, but also said we should take it to the membership (unless I misunderstood things). Hence the proposal. First point: My vision was that verification should take place, and then remain valid for as long as the account is active, plus a grace period aftwards. I'm okay with the grace period being as short as a year or two, five is good too, but that's a detail that will have to be formalized. Second point: I'm not sure we need to make verification a responsiblity of the treasurer. If most of it is done by Paypal, then we could write a script to do it automagically (just query PayPal as necessary, and update the user's primary group ID). I guess that other mechanisms need a bit of thought, if for no other reason than that we are constrained by who actually picks up the (physical) mail at the PO Box. Third point: Personally, I don't think that library cards are sufficient anymore. Some sort of picture ID is probably best.
Any automatic querying of Paypal would require storing Grex's Paypal password somewhere; I'm not at all crazy about that idea.
That's probably not true. Paypal's integration does NOT require you to store your paypal account information in scripts. Merchants direct buyers to their paypal store, and paypal redirects them via a special link back, or possibly makes an alternate request, either way the informatio nca be verified WITHOUT needing the grex paypal accont password *BY* the receiving script.
Re #34: Dan was talking about automatically querying Paypal from time to time to get info on recent transactions; to do that, you need the password. However, Paypal does send a confirmation notice when someone sends money to Grex. I suppose those notices could be (in theory) parsed when they come in, and people added to the appropriate groups automatically. We'd have to verify that the messages really came from Paypal, though, or someone could send such a message themselves and become falsely validated.
Hmm; I wonder if there's a way to ask them to send a signed message or something....
I think cryptographic signing, creation and management of keys, etc would be far too complicated for the majority of our users; keesan would give birth to kittens and complain loudly that it is not part of default pine, and damnit, telnetting in and using pine right on the server is the way the gods meant for humankind to do email, thankyouverymuch.
Well, only between PayPal and the script that interprets whatever comes back from PayPal, not for the end users.
Oh, have PayPal send a signed message. I thought you meant have the prospective validated member send a signed message. Pardon my confusion.
Not at all!
What has been proposed seems quite appropriate and reasonable, without any particular change. Having newusers with the ability to host pages automatically always seemed unnecessary to me. Losing that function for new accounts does not seem to be a big deal. And probably may be a good idea in the long run. No reason they could not host a locally accessible page, but otherwise I see no reason why we cannot drop hosting for --brand new users--. (note emphasis) One thing I always liked about grex was even as a newuser there was full shell access (albeit without outbound internet connectivity). I am seeing nothing here that would change that. Kudos. Also the ability to self-create accounts on the system for INSTANT access is as far as I can see without any other equivalent out there. Insofar as paying for access, I would not have any problem with any particular users paying for :: --larger disk quota --larger mailbox quota ..etc.etc. If some people pay for more space, etc. that allows purchase of larger disks, better hardware, and it can then purposefully flow down to all users on the system as everyones space and service increases in benefit. Any thoughts?
Almost forgot, I'm not for nitpicking the levels, everyone gets email at a certain level. If they dont use it fine, they can "> /dev/null" or fill up their disk space quota at their option. Everyone gets specific access at specific levels and they choose if, and when they use the access, if they ever do. thx. (I personally dont use the email, glad it's there though. I dont get ANY email, spam or otherwise, just FYI).
My only objection to adding web hosting to the list of privileges restricted to activated users is that Grex was founded on the principles of free speech, and if the verification process required a name that could be harmed. On the other hand, Grex was also designed as an online community, not as a fee-for-service model, on which grounds I would object to letting users pay for more disk space, etc. (The founding was before my time, of course, so I know whereof I speak only second-hand.)
I don't think we need to ask people to pay for more disk space, mail quota, etc. The thing about web pages is that we need to balance out the risk of an unverified user creating a phishing hole (get it? ha ha ha) versus legitimate users who want to create pseudo-anonymous web sites. I'm honestly not sure where the balance should be there.
You have several choices: