[Home]WikiAccessLevels

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Meta-note: the links to MbTest? point to empty pages (Feb 9 2004). Is the content archived somewhere, or has it moved onto Meatball? -- EarleMartin
Speaking of AccessLevels, I'm also interested in any comments on the MbTest:AccessLevelIdea. The main idea is to classify users by the following AccessLevels

Level 0: Unknown. This user could be an attacker, a new visitor, a well-known user writing from a friend's computer, or just about anyone. This level is temporary for almost any editors.

At level 0 the user may be limited in many ways like not creating new pages, editing rate (no more than 10 different pages/hour), or not editing "core" pages like the home page, RecentChanges, TextFormattingRules, etc. Reading would be mostly unlimited, although a few things like "expensive" search operations may be unavailable.

Level 1: New or minimal user. This user has passed an extremely minimal test of any one of the following:

Level 1 would give the user most (if not all) the abilities of traditional wikis. A few limits might be retained like a edit-rate limit (maybe some high number like 100 pages/hour), or limits on editing "core" pages.

Level 2: Full member or regular user. To reach this level a user must be (publically?) accepted by at least one other user at level 2. (If this is abused, requirements could be strengthened. Users who repeatedly accept abusers might lose their own status.) My recommended guideline is that for level 2 a user should make at least three "good" or one "excellent" contribution(s). An email-only method might also be allowed, but it should require some contribution (like detailed feedback) in the email.

Level 2 would remove essentially all limits (except basic SurgeProtector-style limits). Some additional "expensive" operations might also be given to this level. (For instance, a level-2 user might be able to define a list of full-text searches that are executed every night with the results immediately available.)

Level 3: Administration. Requirements to be decided by the leader(s) of the community.

Level 3 would probably be the most controversial, and might not be needed in small communities. (The site admin could easily be the only "admin" for a small group.) In my view, it is important that "admins" get no extra "fun" privledges beyond regular members. The extra access would be mostly (completely?) "negative" actions like blocking users, immediate deletion of pages, or even drastic actions like "undo all edits from user# 1387 over the past 12 hours" (likely followed by a listing of such edits and an "are you sure: type YES" kind of prompt). All admin actions should be reviewable by the full community. If there are enough qualified people, admins should probably serve for a limited period (maybe as short as 3 to 6 months) and then pass on the role to other people. Eventually I'd like admins to take over practically all traditional "site admin" roles.

I tend to think of levels 0 and 1 as a kind of "speed bump" for new users. Qualifying for level-2 will probably take less than an hour for most users. (Slow typists like me might take two hours.) Casual abusers are unlikely to wait for level-1 access, and many other abusers would be unwilling to contribute enough for level-2. --CliffordAdams

CategoryWikiTechnology

It is difficult to assess the merit of this breakdown without having any place to test it. However, I can discuss access levels for wikis in general. Objections first.

WikiWay Objection. Part of the wiki philosophy is universality, which includes universal editing, universal reading, universal responsibility, and universal accesss. It is gauche for a wiki to require log ins and then put further walls up even. Indeed, it is a bit hypocritical to wall people out before and then give them almost full reign after.

Barrier to Entry Objection. For a person to be willing to join an (online) community, she must perceive the barrier to entry to be low enough and her will to overcome it must be high enough. Not only will you discourage casual spammers, but you will also discourage casual readers from making edits. Casual readers can and do make useful edits on occasion as they read the whole site (not just RecentChanges). I would even assert this is how wikis usually acquire new users. A couple test edits to get the idea, then a couple more, then the WikiAddiction?...

Indeed, wikis are totally bizarre to most people. I doubt many would bother joining if they had an additional wall to climb. It would be not worth the effort just to learn something they may not like.

Perception of Mistrust Objection. The first thing you say to a user is that we mistrust you. You also imply that the community mistrusts people. This makes it much harder to build bonds between people as the wall of mistrust is a very steep climb to cross. Consider that a wiki which requires AccessLevels would be high traffic, with many new users joining. If they all begin with the feeling that they are mistrusted and that the mistrust is pervasive in the community, then they will all mistrust each other. Not persuant to BarnRaising.

Necessary Expertise Objection. You have a chicken and egg problem. In order to contribute well, one needs some practice with the WikiSyntax and CommunityExpectations. This takes longer than an hour. People with access will still need to learn their way around. Worse, though, you have explicitly rewarded what is likely to be substandard behaviour. This changes the flavour of the wiki.

Community Failure Objection. AccessLevels can lead to a GatedCommunity. Gated communities are an indicator that the society as a whole has failed.

It's a morally righteous statement (as opposed to a valid statement) to say that a gated community is an indication that the society as a whole has failed. There are many examples of gated communities that many people would not say are failures (e.g. Quakers, Native American Tribes, Boy Scouts, Girl Scouts, the American barbership quartet association, etc.)

Insufficiency Objection. Strictly speaking, a person could just keep applying to the site, so AccessLevels would not thwart a concerted attack. They would, though, discourage prolonged attacks. However, it's not clear if that is sufficient if the people can still make edits with new accounts.

Animosity Objection. Reducing access will create fury and anger, thus inciting the behaviour that access levels intend to keep out. However, the best attacks are made by people who understand the system. Witness the attack on kuro5hin this summer as an example of this.

And now for something completely different (or is it?)...

OnlineCommunitiesAreCityStates Argument. An online community is analogous to a city state in that it is completely autonomous. Consequently, it cannot appeal to a higher power to quash the violent hordes that do in fact inhabit the online sphere. Thus, online communities of a certain attraction must put up "city walls" as a first line of defense. Usually the city walls serve mostly to corral incoming traffic to a choke point where they can be controlled, though. AccessLevels don't do this, however. They are more like a club membership. Clubs with initiation policies are bad.

PeerReview Argument. Anonymity is bad. The necessary log ins would help identify people. However, people dislike being forced to log in. Pseudonyms would become popular. Besides, PeerReview requires peers.

Delegation of Authority Argument. The real benefit of AccessLevels is the ability to hand over site administration powers to a trusted few. This delegates responsibility and makes the community more robust against attack. (Consider the case when the site admin is on vacation.)

My heart isn't in it. Access levels have never worked well for me in the past. I will say it does come close to the classic 3 or 4 level approach on BulletinBoardSystems: level 4 was the sysop, level 3 were the co-sysops, level 2 were the normal users and level 1 were users waiting to be validated (usually with the Callback door). However, there, we had phone numbers in order to uniquely identify people. Online we do not. -- SunirShah

I agree we need to distinguish between 0 and the rest; that is, I want to be able to filter out newly created IDs which may not belong to real people. There needs to be some kind of validation, and preferably one which can't be got around by an automated system. (I am open on what that validation should be - eg personal recommendation, a fee (possibly nominal, possibly not) paid by credit card, are alternatives to the "good" edit.

After that, I am not really enamoured of levels. I definitely don't get what the level 1/2 distinction is for. If we need administrators, that's fine, but I would be inclined to go for a finer-grained, "capability" approach.

I'd really like the 0 -> 1 validation to be done by a generic, non-Wiki infrastructure. Along the lines of giving your social security number, certified DNA sample or whatever, and having this built into browsers so that the login process is transparent. We just need to be sure that an ID, once expelled, cannot come back under a different name so that the PrisonersDilemma becomes iterated. -- DaveHarris

You mean validate a credit card and then place a cookie on the user's browser? No thanks. If that was required to participate, I promise you I would never do so. ...Discussion moved to UseRealNamesDiscussion... -- ErikDeBill

One of my models is a more-or-less closed community like a Chess Club, with an annual subscription and bulletin board for members. Even if the community was made more open, to justify a login it ideally would offer a lot more security than MeatballWiki. This would be a step away from plausible deniability, though.

If you insist on complete anonymity, then some kinds of security - both hard and soft - become impossible. -- DaveHarris

Agreed, but I think something short of that is quite reasonable - PlausibleDeniability. I just don't want to be in the position 10 years from now where my views have changed drastically and I have to worry about someone dredging up really old philosophical musings and confronting me with them. Think of it as the intellectual version of a politician wishing nobody knew they smoked pot or snorted coke 20 years ago. Of course, there are ways to handle things like that if they come up, but it's better not to. Unfortunately, there's no such thing as personal correspondence or talking off the record in the digital world. (This needs to change in order to promote free thought/speech, by the way.) -- ErikDeBill

When I originally wrote the MbTest:AccessLevelIdea I wasn't certain about "level 3" administration. Now I think that administration should be an entirely separate issue from initial and regular access. I might continue as the only "administrative" power on Meatball, although I may tempt Sunir with a taste of absolute power now and then. During an attack the admins might "deputize" some well-trusted users and give them certain powers, but the current admin needs are minimal. (See PeerPrivilege, PoliceForce.)

Also, AccessLevels are often simply a shortcut for quickly changing many different capability flags. My vague plans for a MbTest:SecurityModel would give each action a "level" number that is required to use it. If a user tries an action, the model will first see if the user has some specific "exception" for that action (this could either be an exceptional grant or suspension of access). If there is no "exception", the action's level is compared to the user's generic level. In this model, it's tempting to create a generic "admin" level, but I think it would be better to explicitly give each "admin" access as an exception. This will allow admins to start with small things (like banning single IPs) before moving up to larger responsibilities (like making the entire site read-only). (See FunctionalAccess.)

About the difference between levels 1 and 2, there isn't a large difference currently. I would like level-1 to be absolutely trivial to attain. Even a single decent paragraph should be plenty to gain that level, and all users should feel very free to give away level-1 access to anyone meeting that *minimal* standard. Even if the user is ignored, they will get level-1 within a few hours or days. The biggest benefit to gaining level-1 access would be continued access in case of moderate attacks. (Under moderate attacks the site might become closed to new users, or require level-0/outside edits to be submitted for approval.)

Granting level two access should involve some responsibility on the part of the people granting the access. My suggested guideline is that this level should require one very-good edit, or three "good" edits.

It will be possible to abuse this system, which is a bit more trusting than some. One could write a few good pages to be trusted, then grant level-two access to an outside gang of abusers. If attacks like that persisted, other measures might be taken.

As for logins, I don't like them either. That's why I made them essentially invisible in UseModWiki. Right now when you get a user-ID cookie (from setting your UserName or other preferences) you get a user-ID number and also a "randkey" in the cookie. The "randkey" is essentially a password set by the wiki used to authenticate the cookie. For most practical purposes, this is as secure as a login/password combination. (I may eventually allow those few who *really* care to set their own passwords.) Under the system above, I would probably also send out a cookie whenever a user edits a page (if they don't have an ID). I even have eventual plans for an optional cookie-less login system using some kind of session-IDs in the URL.

Finally, I probably care less about UsingRealNames than Sunir, as I prefer explicit (hard) security to social coercion. To me the UserName is just a bit of data attached to the real user-ID number (IP address are also useful for tracking non-cooperative users). Sunir's the high-chief-editor-king around here, however, and I'm just the shady character behind the throne...--CliffordAdams

How well will your proposed system work for someone like me? I use at least 3 different computers and 7 different browser/computer combinations. That's why I like username/password. No setting things up on each and every computer I use (a royal pain when getting all 3 browsers on a computer synched up involves a reboot). If I can easily use a username/password or some other method to get a cookie onto a given browser (after manually turning on cookies just for that purpose) it's not too bad. If I have to have 7+ uid's each with it's own preferences that have to get tweaked when I decide I like something to be changed... -- ErikDeBill (Your real problem is that you have too many computers. Send some to me. --ca ;)

I already have a login system partially implemented in the current Meatball/UseModWiki code. The user interface isn't finished (and it is likely to change), but right now you can:

At this time there isn't much worth preserving in a user-ID. I even use different IDs from different browsers. The login system will be finished before "valuable" information like access levels are implemented. --CliffordAdams

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: