OnWikisAndSecurity

MeatballWiki | RecentChanges | Random Page | Indices | Categories

[An essay written in October-November 2000, in response to recent discussions.]

One of the recurring themes on Meatball is the discussion about "hard" and "soft" security. I seem to have taken up the banner of HardSecurity, while Sunir tirelessly argues for the benefits of SoftSecurity. Recently I've found myself wondering why I'm advocating "hard" measures, when I often prefer communities where "soft" measures are adequate.

I think part of the reason is that I'm concerned about the practicality of the full mix of wiki-ideals and SoftSecurity. To me, the single most important aspect of a wiki is the ability to edit and improve other people's text. The ability for absolutely anyone to make these edits (the "freedom" aspect) is secondary to me.

In almost every other online forum the ability to edit a contribution is extremely controlled. Most forums don't even allow the original author to edit a contribution after posting, even in cases where identity is controlled through a login/password system. Some forums (like UseNet) have some ability to cancel/remove one's work, but in many cases only a tiny core of administrators can make edits to submitted work.

Wikis change these assumptions about editing, and these changes are hard for people to understand after many years of experience in controlled systems. (I'm still learning new things about collaborative editing.) Many people feel greatly inhibited about participating in a wiki for various reasons.

One of the most puzzling wiki changes is the idea that absolutely anyone can edit anything. Almost every week the C2 wiki will have a new batch of questions and test edits from people who find it hard to believe that wikis really do work. I think quite a few skeptics are dissatisfied with the simple replies given on pages like Wiki:WikiErase. Others may think "That's interesting, but I'd never use that wiki stuff on my site".

I see the "HardSecurity" approach as a way to introduce the collaborative editing idea without requiring the whole package of radical SoftSecurity freedom. Think of it as "constructive engagement" towards those who are stuck in high-security systems. I don't insist that these skeptics allow anyone to edit anything, but I encourage them to greatly enlarge the number of collaborative editors. Once they have had a taste of a wiki, even a relatively controlled wiki, I think they will be much more open to the fully-free wiki idea.

One of my intermediate goals (on the path to World Domination) is a wiki about the size of KuroShin (estimated 5,000-10,000 registered users) with the same quantity of contributions. Given the number of people willing to attack sites of that size, I don't see a pure or even mostly-SoftSecurity solution as appropriate. (I think that "community"-based security at that scale would degenerate into a mess of personal conflicts by rival groups.)

Another way to look at the situation is to see a WikiSecurityModel? as a tool that can be used for many different purposes. I would like to enable a continuous range of possibilities all the way from a MetaBaby-style anarchy (all functions allowed for all users) to a tightly-controlled site where only selected people can edit (the wiki becomes a "Content Management System").

One thing I don't like in some wikis is the "egalitarian" tendency to leave out useful functions if they can't/won't be given to everyone. For example, wikis that have a "delete this page" option seem to make it an everybody-or-nobody option. The site either trusts every possible user with an ability, or the ability is unavailable. While this equality often gives more trust to the average user, it often removes the possibility of sharing "administrative" powers (like banning by IP or mass-editing to remove spam).

One advantage of supporting more closed models is that it allows a community site to become more open or closed as its leaders/owners desire, without having to start over and recreate all the content. I hope to encourage more ways to "safely" open a mostly-closed site with features like KeptPages and a "submission" idea. (A submission would be an edit that is not publically shown until/unless it is accepted by a trusted editor.)

I'm also concerned about aiming for too many new goals at one time. Many times an attempt at a complete revolution fails, even if most of the people like most of the individual small changes. Even if only one unacceptable change is part of the new system, people will often reject the whole package rather than trying to extract some parts of value. Making minimal changes at each step also allows separate branches of development to evolve, and provides quick feedback on decisions.

The development of the "web" (HTTP, HTML, servers, and clients) largely followed such an evolutionary development. I was fortunate to witness much of the development of the early web. The first thing that excited me in the earliest days was not the hypertext or linking--it was the "dirt simple" HTTP protocol. (Anyone who has tried to implement an FTP client at the TCP level will know what I mean.) The CERN browser was very minimal, and wasn't much of an improvement from other telnet-accessible interfaces. Still, HTTP was definitely interesting.

Later I watched the early growth of NCSA Mosaic. The first time I really thought "this is nifty" was when I saw my first "inline image" mixed with a text page. After that, development seemed to take off--there seemed to be a neat new feature every month like text wrapped around images, imagemaps, text and background colors, etc. (Some of this excitement continued in the early days of pre-1.0 Netscape.)

One of the exciting things about the early web is that there was rarely a "grand plan"--people simply got together and did something neat. The attitude was often "(mostly-)running code, then rough consensus". After things settled down a bit, people would try to hammer down some kind of standard. (The emerging InterWiki consensus on using "sitename:remote-partial-URL" is somewhat similar.) The old standards of HTML and HTTP seem pretty much set in stone today--much of the new excitement has moved to XML.

Back to wikis... I'd like to compare the current "wiki" culture to the SGML-using culture back in the earliest days of the web. (Quick background: SGML is a large standard that defined essentially all of the basic ideas of HTML like markup and metainformation using tags. Much of XML is a reworking of prior SGML concepts. See [1] for more information.) SGML was very much Wiki:TheRightThing, and it had some dedicated supporters.

One reason for HTML's success was that it didn't require the huge HighRoad investment that SGML did. One could write an HTML parser or generator in hours (and many people apparently did just that ;-). HTML is a prime example of Wiki:WorseIsBetter (although it is mutating into the "Right Thing" with XML/XHTML). Likewise, I'd like to push UseModWiki in a similar direction--it should be something that doesn't require a huge amount of "what is a wiki" training or indoctrination into the "wiki way".

To me the most interesting idea from wikis is the collaborative editing aspect, especially when used to improve existing material. Many people's "wiki ideal" includes many other concepts like Wiki:DocumentMode, signature-less/egoless-authorship, Wiki:RealNamesPlease, special "wiki markup", minimal formatting-markup (ContentOverForm), the nearly-random unfiltered nature of RecentChanges, and lack of significant protection from vandals, among other ideas.

With my work I'd like to make most of these wiki ideals and goals optional. Some communities will "naturally" fit the classic wiki way, but others won't, and I don't see much benefit in pushing them toward a "pure wiki" way. My UseModWiki work is intended to be a foundation for different kinds of communities--some more "wiki" than others. [Insert inspiring conclusion here. ;-]

--CliffordAdams

P.S. None of the above will necessarily apply to Meatball itself, which should be free to stay as "wiki" as the core community likes. Also, in the long term I have my own "grand plan" of ViewPoint (based on UseModWiki), but I see it as a risky idea that will probably change greatly before (if?) it succeeds. UseModWiki is kind of like an intermediate way of holding the gains (Wiki:RatchetEffect) before going forward with the much riskier plans.

[CategoryEssay?]

Nice work, Cliff. Good points, all.

Discussion:

I think that Wiki is a new way of looking at things. Coincidentally, new ways of looking at the world are about the hardest thing for people to learn (can anyone think of an example outside programming? learning functional or OO when you've been doing procedural is the first example that comes to my mind.). On the other hand, I don't see why some people seem so incredibly opposed to hard security. This may be because it's been quite some time since I've made significant use of a computer system without full access to it (root or domain admin). I wholeheartedly agree with you that hard security will be needed to scale. However, I don't think that it will really serve as a stepping stone the way you wish. I think that, instead, people who now think it will be the end of the world may find it not so bad as they thought. A lot of time and effort have been put into figuring out how to make hard security transparent in other contexts, and I think they will apply quite well in a Wiki setting. -- ErikDeBill

: I'm not sure about the functional/OO analogies, since I never understood functional programming well, and I've mostly given up on OO style also. (The first big change from UseMod:AtisWiki to UseModWiki was an "objectectomy"--converting all the code to a pure procedural form. I haven't regretted it (yet?). Smalltalk and Ruby are rather tempting, however...)

If you just want to keep programming the same way, only with different syntax you can pick up a book and be working in a new language inside of a week. This leads to people "programming in C, using C++ syntax" and other things. Something similar happens when a person wants to go from using a word processor to using a markup language like LaTeX. You have to think about the document in a different way, and learning the change is much harder than just learning to use a different word processor. Fundamental changes to the way you look at something are hard.

Wikis are a similar change in the way we look at how people interact online. The threats of online attacks, infantile behavior, and fear of "looking bad" lead most web based interaction to be controlled and regulated. It is divided into the producers and the consumers - those who create content, and those who view it. The trusted and the suspect. Wikis, on the other hand, allow everything to change, and anyone to change it. People are very equal. It is assumed that people will contribute in GoodFaith. You can change any page on the Wiki. Without you having to pay, or jump through hoops, or know the someone who has connections. --ErikDeBill

: The hardest new wiki idea is probably that other people could alter your text. Ironically, alteration rarely happens on most wikis (beyond the occasional spelling correction)--almost all edits are appended or inserted. A related idea is moving, deleting, and rearranging text which happens much more often.

Corporate America would like us to think that the person who first articulates an idea (or their employer) owns that idea. They tell us that this "IntellectualProperty" is the most valuable thing in the modern economy. Having someone being able to change your IntellectualProperty without the fact that it was changed being obvious runs quite contrary to this world view. --ed

: One reason I think some people avoid wikis is that they seem "careless" about people's contributions. One could spend hours creating a good reply, and another person could wipe it out in seconds. (This was particularly bad on some wikis without backup copies or edit-conflict protection.) I know that this was a factor in my first visit to a wiki.

I've written too many things I'd rather have permanently deleted to worry so much about this (I'm sure that old emails I wrote to my girlfriend in High School are still archived on various BBSs and college computer systems. Ick. :-) I'm probably in a minority on that, though. --ed

: I can understand your concerns. Indeed, in High School I once read a few such letters between other people. The HS system was never really intended to be secure (BASIC was the main system programming language), and its text-editor could read any file on the entire system. One couple even used a simple substitution-encryption, which provided me with a few hours of amusing codebreaking. (I never told anyone about the interceptions.) My letters to girlfriends have always been on paper. I certainly hope they haven't saved them. (If any of them saved my "poetry" I'll have to change my name. Oh, the embarassment... :-) Later I've written a few things on UseNet that I'm quite glad predate the Deja archives.

: One of the biggest attractions of wikis is that the good stuff doesn't need to go away. In UseNet or in most discussion forums only a few topics are actively discussed, and they go away after a few days or weeks. Often one can retrieve and comment on such old discussions, but they are effectively inactive. Later someone will bring up the same topic, and people will continue to rewrite and rephrase the old points. A wiki can allow a topic to "rest" for awhile, but can then resume discussion almost where it left off. Rather than rehashing the same ideas, one can build on the work of those that went before. (This may require a more active editing/"refactoring" community than most wikis have, since new people will often try to start a new discussion without knowing that it has been covered before.)

: On the other hand, the social function of repeating well-known arguments shouldn't be ignored. How much of one's daily conversation is "really meaningful", (vs. a social ritual)? --CliffordAdams

: In a way, the stepping-stone idea is that a wiki could be an interesting "Content Management System" even if you don't open it up for editing by the wider public. One could easily create a short list of trusted people, and delegate abilities to each of them. Some abilities like submissions might be reasonable to give to everyone (since only trusted editors will see the non-accepted submissions). Once the outsiders prove themselves through submissions, they might be given more abilities and responsibilities. I hope to allow admins to give trust in small steps rather than huge leaps. --CliffordAdams

Hmmm... this would have been useful both for a corporate intranet and for keeping the work instructions archive. Instead we had some really awful LotusNotes databases which were painful to update and incredibly regimented. Damn near useless.

I agree with your perspective on security. SoftSecurity was perhaps a bad name, and tends to polarise the issues - "hard but unobtrusive" is good too.

One of Wiki's great features is its low barrier to entry, which is actually made up of lots of little features. No passwords is one. A Wiki with a password is going to feel different, but that will sometimes be unavoidable.

Another feature is the markup language, especially the LinkPattern. One of my person aims is to produce a private, single-use tool for writing text which includes hyperlinks. Wiki-like systems can be valuable even if they are not shared.

Ward's Wiki was for me the first web-based system that seemed to work. I think the freedom to seemlessly merge with other people's work is crucial there. An append-or-insert-only forum does not compete.

So there are many good ideas in Wiki-space; we shouldn't get hung up on security only. -- DaveHarris

re: Soft vs. Hard zealotry

Y'know, I really enjoy the back and forth between Cliff and I and the rest of y'all. It usually ends up forcing enough sides of the issue to be bunged out so we have a much more informed choice. Sometimes new ideas can emerge like the functional access trust metric or kept pages.

And I don't entirely disagree. It's just that people take HardSecurity as ideal for granted and that I disagree with entirely. I think hard security is a reaction to failure, not a means to success. Moreover, in the RealWorld, free societies try to keep fewer hard security measures, not more as on computer systems.

I think being forced to authenticate or identify myself everywhere I go, say even to go into a store or even a library, is deeply wrong. Yet, online that practice is taken as a given "best practice." I try to break that cycle of GroupThink by being adamant. Besides, trust makes for a healthier soul than fear.

re: Opening up closed systems.

I think that being so adamant about SoftSecurity is useful. It's so easy just to put another lock on the door, but it's much harder to come up with an elegant solution to a social problem. In one way, this is the Better is Better position and, you're right, it is quite deadly to take this position always. In another way, often the cheapest solution seems adequate so there is no impetus to improve it. However, the subtle effects are also deadly.

Since most people work on closing systems down, I'm interested in opening them up. I think it results in a better system.

Balance, always. -- SunirShah

Balance in moderation. Occasional excess works quite well in my experience. --CliffordAdams

re: Very large scale wiki

I've been thinking about this a little lately. I don't think it's possible for a wiki to scale to 5000 to 10000 as they exist right now. That would exceed humans' ability to cope with that much information. Moreover, the proportion of what are considered "off-topic" messages will rise as sub-discussions and lateral-discussions are formed.

Consider a forum to be a room in which similarly interested individuals discuss a topic of choice. As the forum grows, it becomes difficult to hear everybody's opinions. Moreover, the discussion will become specialized into a set of separate sub-issues. In that case, the best thing to do is break up the forum into smaller fora, each focused on the smaller problem. This is like the room growing so big it becomes a building with more rooms inside.

Then, the outer forum, the original discussion, changes into one of synthesis, adjudication and marshalling amongst the smaller focused discussions.

If you believe that, you may see some sort of truth in how wikis have evolved over time. New fora are splintering off of the original, WikiWiki, as the discussants wish to delve into further detail without aggravating the rest of the community. I give you the Wiki:ExtremeProgrammingMailingList and MeatballWiki itself. (I could give you another one, but I'm sworn to secrecy right now.) I suspect, though I'm not sure, that the ZWikis are the same.

So, really, it becomes another question of the RoleOfRecentChanges. RecentChanges is the limited resource here, as the (in)ability for humans to distinguish voices is the limited resource in a room.

One option might be to split the wiki into subwikis. Another option may be to replace RecentChanges with something superior. Another option would be several wikis each exchanging content or freely linking to each others content (ala InterWiki or even Wiki:InterWiki). Maybe there's another option? -- SunirShah

 * * *

Hmmm... Possible for a wiki to scale to 5,000 to 10,000 what? Readers? (In that case the C2 wiki may already be there.) People who have ever edited a page? (There about 1000 "home pages" of C2 wiki readers as of mid-2000, which sets a lower bound.) People who edit a page each day? (This would be more than SlashDot's level of participation, which gets about 2000 to 5000 comments/day.) Kilocharacters per millifortnight? (:-)

Perhaps one of the limiting problems are people who don't want communities to grow beyond the limits of their understanding or participation? I'm sure there are quite a few people on SlashDot who miss the "good old days" when you could read every comment on every article (and still sleep a few hours each day :-).

A similar scaling problem also occurs in growing businesses, when the founders realize (or don't realize) that they can't be involved in everything anymore. Beyond a certain size the top people need to start managing managers rather than trying to do everything themselves. Limiting a business isn't necessarily a bad thing--too many people have pursued growth at the cost of their other values, and lost sight of why they started their business. This happens all the time when idealists start a company that will be "different from all the rest", and are soon handed a choice between joining "the rest" and growing, or staying small and keeping the original values. (The decision to publically offer stock is often one of these hard choices.)

Limiting the growth of a community may be a different matter than limiting a business. In the US, many communities have a conflict over "urban sprawl", which is often defined as under-controlled expansion of cities and suburbs. For example, a city becomes popular and draws in lots of new residents. At first, these people may be happy living in apartments or other city-center housing, but eventually they want to "settle down" and buy a house in the suburbs. Suburbs often have better local facilities, especially for families with children. The existing suburbs may be full or unaffordable for the relative newcomers. Developers and builders will then offer to develop land adjacent to the city into new housing (for a vast profit, of course).

Once the development plans become publically known the fighting begins. Almost everyone agrees that city growth needs to be limited in at least the minimal sense of not overloading critical infrastructure like water or electricity. Other people draw the lines at different resources, like transportation or open spaces. Development often becomes a Wiki:TragedyOfTheCommons issue with many competing uses for common resources, and each individual development doesn't seem to hurt much on its own.

In physical cities the growth is controlled by the city government, which often delegates the power to a zoning or planning board. This board has the power to permit or deny uses of local land (or at least deny city services to that land, making development more difficult/expensive). The city government can also make certain kinds of expansion more or less attractive by incentives, infrastructure, and regulations.

Back to wikis... On most online sites the site admins are the entire local "government". They may solicit community input, but they are rarely bound by it. (Most wikis are the same, although the local populace is often quite effective at complaining. :-) The admins can encourage certain kinds of development by altering the infrastructure of the site. For instance, SlashDot encourages popular comments through moderation, and both SlashDot and KuroShin provide methods to remove most "spam" or clearly inappropriate material.

Wikis often replace the explicit coded limits like point-based filtering (a TechnologySolution) with informal CommunitySolutions like PeerReview (or PeerPressure). (As I once cynically put it, "Wikis replace technical limits with social constraints.") The informal basis of the "social" restraints often allows more control of expansion by limiting new contributions to those in the "spirit or character of the wiki". (In some ways, such limits are more similar to old vague zoning ordinances against "indecent" businesses (which could range from a store selling liquor on Sundays to "adult" entertainment). Today such zoning regulations are more clearly defined to avoid controversy and lawsuits.)

Perhaps the leaders of the local Meatball community (those who write really loud :-) should write some about what they are looking for in an online community. Is it OK if RecentChanges becomes 10X or 100X as big as it is now? How should disagreements over community style be handled? (For now Sunir gets to be the GodKing.) Should the "charter" of the site be relatively fixed or flexible? If a lot of newcomers want to change the charter significantly, should they be able to? How "polite" should the local people be to newcomers who don't understand the local customs (and seem resistant to learning them)? (The answers may require lengthy responses. Attach extra pages if necessary.)

If some of these things can be made explicit, then people may be less upset than if they held conflicting opinions and are disappointed later. For instance, someone who thinks Meatball should grow to SlashDot size may not be happy with informal community pressure to keep the community small, especially if that pressure occurs after they have "invested" a lot of effort to build up the site. If a "small community" is part of the original goals, they would have less reason to complain.

Of course, ViewPoint will solve all problems. Eventually. --CliffordAdams (If ViewPoint doesn't solve it, it isn't a problem.)

Well, since this page is getting rather long before we even get started, I'll give you WhatIWantForMeatball

---

Protection by Locking

Instead of WikiAccessLevels or Password Protection, I'd like optional security. If you really really want to protect your page, you can lock it. If the Administrator wants to lock StartingPoints and the major sections, let him. If newbies want to play in the SandBox or create their own Homepage, let them, too. Locks can be per account. Accounts can be shared.

Dealing with Big Wikis

Maybe this should be moved to a separate page together with any pertinent material?

I'm still not sure what the problem with big wikis is. It seems that only a RecentChangesJunkie suffers. Discuss on RoleOfRecentChanges, I guess. SubCommunities? form automatically as they focus on the interesting pages and ignore the rest.

What we did at WikInfo (and GetMeta?)

WikInfo had the same problems with WikiSpam, WikiVandalism?, and InformationSecurity. "Internet Encyclopedia", was then running poorly on MediaWiki, with no security but the ability to block IP's or accounts. After we re-emerged as WikInfo running GetWiki, we eventually decided to require accounts after some vandals came by. I've also done a lot of work to connect the dots in the background, so that the few blocks we have actually work. Since then, we've only had a couple of vandals drop by, and no spammers I can recall. We don't restrict the kind of login people use, whether real or fake name/handle, and anyone can come in and register pretty darned anonymously or flying their full name, and start posting. The content is secure.

Privacy is protected this way, for those who want it (IP's are not revealed unless blocked), and requiring logins knocks out nearly all the vandalism and spam. Look at the recent changes on WikInfo or GetMeta?, and behold that there is, at least for now (crosses fingers), no need to police the wiki to despam it, revert blankings, or ferret out sock puppets, as is daily sport on other wikis. This seems to satisfy all of the bullet points listed on InformationSecurity in regard to content, and doesn't block access from anyone (the rare protected page can be changed via discussion on the talk page, for example), unless you're blocked, of course. Besides, most editors were logging in anyway, as they had a UserName or RealName they wanted to use, so requiring logins wasn't a huge leap and maintained our WikiDemocracy?. -GetProteus