Wiki Access Restricted

Symptomatic

   Type the code word, 567, here [567    ] then press save to finish editing.
   Type the code word here [    ] then press save to finish editing.

Mechanism

The wiki post logic checks for a valid code word before continuing. At times, the code word is presented as part of the message. This may be scrambled in some form that makes it harder for a computer program to read the code word. At other times, the code word is a secret that is distributed only to people that we trust.

The code words and scrambling methods can change rapidly during periods of programmatic attack. If they have not changed recently, that is a sign that things have been quiet.

The choice of which code words are valid and whether they will be reported depends on server configuration and requesting ip address range. A team of volunteers deploy various configurations depending on the degree to which they are able to monitor the site for abuse. Internet address ranges from which abuse is common are more likely to be restricted at any given time.

Rationale

The code word mechanism makes the site essentially read-only for some users at some times. This was judged a superior solution to denying all access including read-access to large ranges of ip addresses (see WikiAccessDenied). It has the advantage of having several parameters that can be adjusted in proportion to the amount of abuse overload present at any given time.

History

This machinery was deployed in 2005 after a two week period of severe server abuse. The site sustained continued attacks for the following week. Since then, both denies and restrictions have been slowly lifted while a team of volunteers (called stewards) watch the rate and source of ongoing abuse.

Recourse

If you see a code word, type it.

If you don't see a code word, try again in a few hours.

If you haven't seen a code word for a number of weeks you can assume you live in a "bad neighborhood". If this creates some sort of hardship for you with respect to this site, try writing me an email. Include your numeric IP address and a description of the hardship. It will help your case if you point to contributions you have made to the site under better circumstances.

Finally, you can try back in a few months. It is likely that our most persistent pests will have tired by then or we will have devised schemes to deal with them that do not inconvenience you.

-- WardCunningham

I am assembling a group of stewards who have both a financial and emotional stake in the continued health of this site. With their assistance I will decide how this site moves forward. -- Ward

Can you say who the stewards are, and what is being planned? -- ScottJohnson

People who would like to be involved should email me. -- Ward

WikiVandalismSolutions would be a good place to sort out the good solutions from the bad solutions. More eyes will be able to spot more vulnerabilities.... There seems to be a lot less vandalism in the last few days. Plus, we should hold our ground - otherwise the terr^H^H^H^Hvandals have already won. :) -- MichaelSparks

According to the theory the vandals will never win. -- HelmutLeitner

Someone may find in the process of editing that the code word is present, but on pressing the "save" button, discover a refused edit because the code word has been withdrawn. What mechanism causes this? -- drn

You could see this behaviour if a steward restricted an ip range that included your ip address while you were editing. This is only done in response to abuse. The inconvenience to you is considered undesirable, but preferable to the abuse. -- WardCunningham

It will be noticed that some can edit; in fact, certain people seem always to be able to edit. One would hope that those who can initiate the withdrawal of the code word do not use it to limit edits of responsible people (for reasons unknown) and instead reserve its use to that of eliminating "pests". -- drn

Yes, restriction as described on this page is a blunt instrument that injures many innocent authors. Finer-grained ip restrictions fail because there are so many ways to circumvent them. -- WardCunningham

I originally wanted to make this comment on August 3rd, but haven't had a chance until now. Although I had totally given up for a few weeks. ("Our phone system is down? Impossible! No-one has called me to complain about that!") I tried from several places in Massachusetts - maybe the entirety of the state is now a "bad neighbourhood".

Nah, I routinely post from Massachusetts. I'm not sure what the problem is, but my comcast account is NOT blocked. -- TomStambaugh

Maintaining the illusion that access to this wiki is "open to all" does more harm than good. This site must recognize the persistent identity of WikiZens across different machines and IP addresses. Not just machines, but actual human beings need to be identified and authenticated in order to have trusted communication and collaboration. -- JohnReynoldsTheStudent

Strong identity trades one set of problems for another. Still, this is probably the way in which wiki in general will evolve. -- WardCunningham

Why? It sounds like an irrational trade to me. Why is it difficult to allow editing from particular ip addresses? It can't be fear of commercial spamming, since spammers can easily adopt a totally new ip address, and will probably have abandoned old ones. In particular, some people have complained of being allowed to edit only intermittently - if true, that makes no sense at all.

I am fairly new to WikiDom, but it is my understanding that Ward hit upon a heuristic method of combating spam, and other abuse, by (intermittently) blocking large ranges of ip addresses. Blocking narrower ranges of ip addresses did not seem to work. This rough-and-ready heuristic results in some (perhaps many) innocent authors and contributors to the wiki being (perhaps arbitrarily and irrationally) shut out for significant periods of time. Ward justifies this trade-off inasmuch as he claims that nothing better than this heuristic is available. Alternative edit codes (to permit access from otherwise restricted ip addresses) are supposedly available to (some) blocked authors; but the means by which these secret keys are distributed is intentionally left somewhat mysterious. Please feel free to email me (in confidence) on this subject as you deem appropriate. -- JohnReynoldsTheStudent

Some of that is guesswork. Obviously, blocking a narrow range would work if technically possible. Ward mentioned only one alternate key, but it seems it's never been used.

It is indeed a sad state of affairs that an "open wiki" is no longer viable, that script bots and spam kings, along with the ease of constructing an HTTP POST request have ruined it for all. I like the feature of anonymous posting as someone may be struck with wishing to respond, but not want to volunteer to be an active "member" of a website, so in my own blog, I have created a two tier method that accommodates both modes:

1. A CAPTCHA test for anonymous posters. Yes, they're not 100% foolproof and at times, they can be difficult to decipher, which is a shame. And it violates accessibility rules. But I reason that it's OK because it's not the only way to compose a comment (or post).

2. Create an account which requires an email confirmation return. Then, posting can be performed by anybody "logged in" to the site.

Whether or not these would satisfy the requirements of this wiki (or any other wiki), I don't know, but it has served well on sites that I have managed. Enabling anonymous feedback without requiring someone to register an account.

-- NaumTrifanoff

These all are based on assumptions that one who can be identified will choose to behave when "logging in". It is not a problem of software as much as of the community. See ChangeTheCommunity.

I am curious, was it personality-driven EditWars or spammers that triggered the big lockdown?

Three days restriction sounds more like the second, which would be time enough to adjust the wiki software trigger mechanisms to adjust to any new technique not handled at the time of the new spamming. I did notice in the days prior to the restriction that some spamming was deleted by gnomes. It certainly was not the first, as these seem always present as one can determine via NewRecentChanges.

Only the first needed to be secretive. Power corrupts.

--- I would prefer to see something with a better user experience especially for handicapped users. For example, I'm disabled. I use speech recognition. when I encounter code words or other Captcha tests, I usually just walk away because it isn't worth the physical pain. my personal preference is some form of proof of work system where the puzzle solved in background while a user is modifying the wiki page. When the submit button is hit, the puzzle solution is sent along with it. If the puzzle isn't complete or is inadequate, the submission is rejected. Otherwise, it's taken as good.

as with all other solutions, there are problems with this one with regards to stability of Java implementations, speed, and ability to perform operations in background. But as long as you can push puzzle solutions into background, it's typically a much better solution from the users perspective and all the others and it sucks up spammer resources far better than any other technique to date.

See MoreAboutWikiAccess