Secure Wiki

It's simply fascinating how people can babble on about a secure system without knowing the least little thing about security.

The very first thing you need to do to discuss a secure system is to understand what security is.

A system is secure if an agent can:

perform every operation to which they have legitimate access
perform no operation to which they have no such access

The second thing to do is to understand the essence of the system you're attempting to create a secure design for. Once that's done, you have to exhaustively list all meaningfully distinct operations possible in the system. Only then can you apply the PrincipleOfLeastPrivilege, and only then can you design an appropriate CapabilitySecurityModel for the system. So let's do that.

What exactly is a wiki? A wiki is a massively interlinked text-based medium where known and anonymous users interact. The key terms here are: interlinked, text, users, known, anonymous. A bit of thought reveals that the fundamental objects of a wiki are: users (homepages), links, link targets (pages), text quanta (paragraphs). Only a bit more thought is necessary to realize that the following operations are all possible and that they are all meaningfully distinct from each other:

reading a page
creating a page, naming a page, deleting a page
creating a homepage, deleting a homepage
creating a paragraph, deleting a paragraph, reordering paragraphs, merging paragraphs, editing a paragraph
signing a paragraph, unsigning a paragraph

Knowing the objects in the system, we can see that links are capabilities and pages are the resources they grant permissions for. Knowing the operations in the system, we can see the permissions on the capabilities that would make it run.

....

A SecureWiki is a wiki that can be edited only by authorized users. The problem with this is that you are restricting the set of possible authors for that wiki, which in turn reduces the motivation for readers to even bother reading that wiki.

But, if a way could be found to MergeDifferentWikis, then a WikiReader could read different wikis at once. WikiSpaceIsTwoDimensional. -- PhilipDorrell

JohnDoveIsaacs, a famous and favorite professor of mine, had this quote on a nearby blackboard: It is amazing what one can accomplish if one does not care who gets the credit. (see DoNotWorryAboutTheCredit) With this attitude, the necessity of a SecureWiki is brought into question. -- ChrisGarrod

Why not create levels of Wiki access? E.g. Anyone can add a new entry to the bottom of a Wiki page, but only "editors" can edit the page and delete content. You can become an editor by simply identifying yourself via an email address (you get emailed a password which is associated with your email address and enables the editing function) or editors can be appointed or screened by the person running the server.

Just for information, the ComSwiki in use at the Swiki WikiFarm (See WikiEngineReviewSwikiFarm?) provides "append areas", which are text editing windows that anyone can enter text in, without the password, even if the page is password protected.

Another possibility: If users have to "sign up" before even adding data to the end of the page, they could be allowed to edit only their own contributions and comment on or "rate" entries from other users. In this way, fuzzy issues or new, untested ideas can collect a consensus over time. -- JamesNewton

Or perhaps journal all changes to the site and provide means to "reverse time" to any particular point in the past. Then allow users to "branch off" from the point before some major change that they find objectional. Then perhaps an interface for determining the most popular Wiki branches would be valuable. -- tinara

See also FishBowlMode? ala OrgPatterns, http://usemod.com/cgi-bin/mb.pl?SoftSecurity (for the other way). Actually, what you really want is a http://usemod.com/cgi-bin/mb.pl?WebLog (or maybe a http://usemod.com/cgi-bin/mb.pl?WikiLog). I question whether you really want a wiki or you just want to give everyone you trust access to the public_html directory.

: It is not necessarily the case that people would be less motivated to read a SecureWiki. It depends on who's writing on it. Suppose only HugoAward-winning sci-fi authors could write on it, and suppose they did so regularly. Millions might tune in.

: Yes. This type of forum already exists. Its called a web site.

: You're missing a crucial point here. Let's say you have a group of people who collaborate on something, and they all have their own competence to bring to the project - say, an open source software package - and they're spread across the globe and not very interested in having to learn to use a complex "content management system" just to each add their own little value to the documentation effort, which many of them view as a necessary evil (for once, let's be optimistic and assume they agree it's really necessary :-). Now, I'd think it'd be pretty ideal to create the documentation using a wiki (or wiki-like technology, with or without the DoggoneSinisterCaps? etc etc ;^) to develop an ever-changing web site, instead of a frozen piece of read-only text which will grow obsolete as soon as you change something in the code base.
: Now, of course, if the site is about something a little bit more sensitive - security software, perhaps - you'd really really like to be able to avoid the embarrassment that a teenager with write access and too much time on his hands could cause your site. It's not like the fascist administrator would like to restrict your access as much as possible - in fact, the functionality I'm looking for is more along the lines of, once you have your authorization, and we have your email address, you're encouraged to change everything; but not before we have your email address!
: It's not all that different from how mailing lists have evolved as more and more people have grown annoyed by the pranks which were practically invited by a model in which anyone who wanted to could post to any list. (Witness the sad state of Usenet, also.) It was predicted that the stricter model would make mailing lists less interesting, but that has hardly happened - if anything, strictly moderated lists tend to have the highest quality of submissions (obviously at the cost of high barrier to entry) but from there, it's not a white-to-black transition to unmoderated babble/spam lists, but a very wide gray zone.

Do people around here find that when they add "security" to some piece of software, it's nearly impossible to avoid doing a BigDesignUpFront? I seem to find the need to spec out an explicit security model, and before you know it, I'm trapped in a BigDesignUpFront. --

Depends on what type of security you want. Sometimes you can add security as you need it, especially with soft security. Hard security often begins with principled impoverishment - give out as little as possible. Then, you open up little holes here and there as necessary. Of course, this makes the system nearly useless, but security is fun. Gah. -- SunirShah

I think that wiki is strong as far as people are involved in an ongoing discussion about something of value for them. What happens later is a matter of archiving, but if the people interested in those archives ("who said what? when? why?) are probably not the same that those who started the discussion, then who cares?

Without the WikiDeleteFeature?, Wiki will not be interesting anymore. Instead of changing this mechanism which has already proven useful, perhaps we should tackle how one might establish a UserRankingOfPages?, which in turn might act as a EfficiencyBrowsingFilter?.

This might be useful for mixed use databases such as contact lists where some contacts have full information available to all users, but have some special information such as home phone numbers available for emergency use available only to a restricted set. More standard wiki usage would make use of hyperlinks to restricted data kept some other way, but it might make sense to keep this data in the wiki so that all relevant data gets archived together and any of the special set can edit the secure information.

How about combining a journaled edits (each being a transaction) with a rating system like SlashDot? Thus, you could easily choose to view the level of "quality" you want to see. Not even sure if it's feasible to implement, but this would seem to incorporate all the goals. --YugoNakai?

Many wikis provide history of pages. But few users ever bother to read them, I suspect. One option would be to have a wiki exist in two dimensions, each version of a page having a canonical entry by authorized users, and a freeform entry by community (unauthenticated) users.

Also, regarding the above thing about ranking nodes, that's not really ideal, since the whole point of a wiki is to have a single page for a given topic. If each user had his own page, and viewers had to browse between them, nothing would ever get done. --Dan

CategoryWiki CategorySecurity CategoryCollaboration