![[Home]](http://meatballwiki.org/meatball.gif)
PublicallyEditableInterMap
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesPublically-editable InterMap index -- a suggestion for InterMap (rejected)
see also InterMapPublic
Publicize the InterMap index so that end users can maintain it. Instead of reading intermap.txt (or whatever), it would pull the page InterMapIndex? which would have the handy format:
- This is very unlikely to occur. Probably the biggest problem is that it opens InterWiki links to full-HTML exploits using a remote server. For instance, consider someone relinking "Wiki:" to a site containing malicious HTML/ActiveX/Java-VM-bug exploits. By the time the user realized the link wasn't going where they expected, their system could be destroyed.
- I am planning to make it much easier for the administrator(s) to maintain the InterWiki index, however. (If a site chooses to open administration to everyone, that would be their choice.) All users should be able to easily submit new entries and changes for review.
ZWiki implements this through their ZWiki:RemoteWikiURL schema. Instead of having a central list, the link forms are maintained on the separate pages describing the foreign pages. Perhaps the niftiest hack was the inclusion of ZWiki:FatBrain. -- SunirShah
See also Tavi:InterWiki and Tavi:SisterWiki for WikkiTikkiTavi's implementation of a user-editable intermap.
I don't understand the security objection. I don't think the mere syntax of an inter-wiki link, as opposed to a normal URL, should be taken as saying something about the security of the remote site.
Here's a fuller explanation:
Suppose an attacker creates a website which contains a single script. The script ignores any arguments or parameters, and returns "bad" HTML code. This "bad" HTML code might take advantage of holes in ActiveX, Java, Javascript, or other parts of the browser. Depending on what browser/OS the user has, and which features they have enabled, the consequences could be drastic.
Normally, this isn't much of a problem. One trusts ordinary sites not to link to such places. On most sites publically editable content (which could link to bad sites) is separated from the main site content, so it is clear who is responsible.
On a wiki, however, anyone can edit (almost) any text on the site, including older trusted text. People learn to deal with the problems of trust in a wiki, and should be skeptical of strange claims on a page. For instance, if the CliffordAdams page claims that Cliff has always hated Perl (and that FORTRAN is the One True Scripting Language), then someone else has probably been having some fun.
One can enjoy the strange insecurities of a wiki, and even laugh at weird edits made by third parties. The fun stops when editors can cause immediate serious damage, especially if the victims didn't think they were at risk.
On some wikis (which allow arbitrary HTML), a single malicious person could damage several systems (before they are blocked from editing). On other wikis which allow arbitrarily-named remote links, "CliffordAdams" or "RecentChanges" could be a link to a bad/damaging site. On wikis which allow InterWiki editing, "MeatBall:RecentChanges" could be bad. Finally, on most sites (including here), "http://www.some.bad.site.example/mystuff" could be a bad link, but at least one knows where one is going.
Users could check every link before clicking on it, but I doubt many people would bother. If a site allows editable InterWiki links, then attackers can redirect a large number of popular links with minimal effort. (One possible outcome is that authors might avoid using InterWiki links and write out full URLs.)
One thing I like about restricted-link wikis is their "transparency". If the page shows "RecentChanges", or any other WikiName link, one knows that one is visiting a local page. InterWiki links like "Wiki:RecentChanges" will continue to point to Ward's wiki, and not to some other site. Users can still click on raw URLs, but the destination is obvious. One can then easily avoid non-trusted sites. --CliffordAdams
A solution
We could use a FileReplacement scheme as outlined on that page. -- SunirShah
- March 28, 2002. The first time InterMapTxt was replaced. There were some bugs, but I've fixed them.
I've been feeling that the InterMapTxt project has been too accepting of new entries. Many entries nowadays don't even have links on MeatballWiki, which seems odd as it is our intermap. I think this is because people have been turning it into a giant telephone directory of all wikis that have crossed out path. I don't think this will work for either us nor them, so I have a new solution.
First, encouraging the frequent alteration of the InterMapTxt prevents its adoption via FileReplacement. I expected that changes to the intermap would be few and far between, as traditionally Cliff and I were adding wikis very infrequently. Indeed, an entry would only be accepted after some vetting on InterMapSuggestions. Nowadays, no vetting is required, as the changes can be made directly by those who proposed them.
This lack of vetting has had two immediate effects. One, there are no more bruised egos for having their pet wikis rejected by our arbitrary opinions. This has created a lack of conflict by EnlargeSpace. On the other hand, entries lacking any direct value to MeatballWiki have been added aplenty, now overwhelming the list. Overwhelming the list, I think, reduces our desire to PeerReview the intermap. At least it reduces mine because I'm fairly sure I won't be interested enough in wikis being added to go visit them to see if it is worth adding them. The lack of peer review actually creates dangerous opportunities to subvert the system, adding security attacks or links to embarassing material.
If we let this continue, we could become known as the canonical list of InterWiki sites. I don't think this is a good road to travel. Having Meatball mandate to other communities what they should do, what intermap they should contain, is not a position without difficulty. Also, if we become the effective DNS of wikis by canonicalizing the InterWiki monikers, we will end up having to resolve more name conflicts, a very distracting business. If you don't think this will happen, we already have the conflict between the two IAWikis: information architecture and information anarchy. I think it's best to let each wiki decide for itself what its intermap should be. I also think it's good to encourage other wikis to publish their intermaps so they can be exchanged as desired. And even if MeatballWiki does not become a canonical list of InterWiki sites, I think it's valuable to keep our list meaningful to ourselves instead of buried in a hundred sites we cannot track.
This is what Cliff and I propose. MeatballWiki reduces the current InterMapTxt to what we link to, as BayleShanks suggested. UseModWiki's default distribution will be reduced to the absolute minimum number of entries (even UseMod will likely be excluded). For those who want to acquire a more complete intermap.txt, we will give them a link somewhere on MeatballWiki which will link to various lists maintained by whomever wishes to list them, including our own.
This will solve most of the problems I see, but it will not solve the overarching problem of allowing individuals to publish their wikis to the world. I do not wish to deny them this basic celebration of their projects. Indeed, I think something like the OneBigWiki would be a great place to create some sort of complete telephone directory of all wikis. In the meantime, I would like to see Meatball acquire control of the dmoz.org directory for wikis and makethat serve the role the current InterMapTxt plays for the whole wiki community. I think this will solve not only this problem, but it will have a number of secondary benefits that are worth exploring. Mind you, Wiki:WikiClones serves this purpose as well, but it's not actively maintained and scrubbed for dead links, nor is it as public as dmoz.org. -- SunirShah, with CliffordAdams hovering nearby
After pruning the current InterMapTxt and coming to a consensus on that, we should agree not to edit InterMapTxt more than once every few weeks so that the FileReplacement has time to update. In fact, on InterMapSuggestions, we could maintain a "queue" of pending changes to InterMapTxt that we'll make after the next time InterMapTxt updates.
It might be nice if there were some indicator on InterMapTxt that told us when the last time that FileReplacement activated, and when the next time will currently be.
Also, in the long term, I don't think FileReplacement is sustainable; eventually we may have to introduce another mechanism, such as "seconded" changes, to prevent visitors from changing InterMapTxt without realizing the FileReplacement consequences. This may not be a danger for awhile, though. -- BayleShanks
- Be careful, though. Right now we reap the benefits of DelayAction and PeerReview. Voting, I think, compromises wiki nature too much. Plus, exceptions like "seconding" invite mischief (c.f. LimitTemptation); you might as well AvoidIllusion and just promote the changes immediately. Also remember that on the scale of the WikiNow, a link that doesn't work for a month is not such a big deal. Sometimes we get some benefit from delaying that instant gratification.
- Granted, I don't stay up nights worrying that someone will hack the intermap. ;-) Still, skipping out on parts of SoftSecurity at least sets a dangerous precedent. -- anon.
yeah, I agree that voting is not the goal here. Good point about LimitTemptation, too; but I think seconding may still be of value here, although it is not necessary yet. The intent is not to defend against malicious users at all, but just to defend against visitors who don't know the details of FileReplacement. I meant seconding AND the current FileReplacement system, so we'd still get DelayAction. How about this first, instead, though: when someone edits a FileReplacement page, after they click Save, they get a big "are you SURE?" page warning them about how they may be disrupting FileReplacement, etc, telling them where the discussion/queue page is associated with the FileReplacement page, and asking them not to continue unless they think they know what they are doing; they have to click on a certain link on that page for the Save to be successful. The text of the are you SURE? page could be a standard community-edited wiki page. -- BayleShanks
"Are you SURE" type dialogues are not a HumaneInterface. -- AlexSchroeder
Proposal: Based on experience with MultiUserDungeons? - independent, single-server games, usually derived from one of a handful of code bases. These games were very successfully networked in the mid to late 1990s. Each server had a "hosts" file, listing all of the other games it knew about. Inter-mud communication consist of channel based chat, which was broadcast to every listed host using UDP, or point to point messages, also UDP, for exchanging files, email, remote who information, and so on. Each game trying to keep its "hosts" file up to date proved completely impossible - games came, went, and moved far too quickly. Tracking changes would be a full time job for each person at each site. This was the first step of evolution. The second was a few games did do a good job of keeping their lists up, so everyone just used thier lists. The third and ultimate was for each game to distribute their list on request, and software which automatically recursed through the list: every new game it encountered would be queried for its host list, and so forth. Non working entries were easily detected, and names were taken on a first-come-first-serve basis: if you use a fairly reliable game as your root node, there was very little chance of someone poisoning the distributed database. This would only require each server to have a _non_ PublicallyEditableInterMap, but instead a private one, that was published in a standard format. Each Wiki would list other Wikis that it trusted. In fact, the Wiki at http://wiki.slowass.net has a trust metric computation engine, inspired by AdvoGato, built in, that could be used to compute confidence intervals based on max flow graph - who links to where, and how many links there are to there. This fits with the principles of simplicity and autonomy, and allows each host to reference as much or as little of the WikiWikiWeb as desired. If you have some interest in this, please sign the guest log at http://wiki.slowass.net/?GuestLog - I've implemented most of my proposals already on my Wiki fork, and I'll do it again. I'd like to trade ideas, but I'm not going to keep an eye on here - sorry. Too busy coding, not talking. My Wiki fork is already linking to pages if they exist on the C2 Wiki, and it automatically links back to pages that link to pages there, both implemented in ActiveWikiPages.
If your goal is to have each wiki to be well-connected, that's the way to go. However, my feeling is that it's nice to have a relatively circumscribed "neighborhood" -- like a rolodex of people that you've actually met, rather than a white pages of everyone in your metropolitan area. Then again, maybe InterWiki is not the place to do the neighborhood thing, I dunno. -- BayleShanks
There are two conflicting intentions, and you've listed them. If, on one hand, you to cross reference your Wiki with another one that is relavent to the topic or you have some social relationship with, a PublicallyEditableInterMap is not the solution. If you want to do something like MoinMoin does and just people easy ways to refer to arbitrary Wikis but aren't cross referencing automatically, knowing about lots and lots of Wikis is a good thing. There is of course a middle ground which could be described as similar what forms on a Gnutella network: cross reference to those immediately around those, and those immediately around them, with a limited level of recursion, favoring those who are most strongly interconnected - I'm a big fan of the TrustMetric idea. Having an InterMap of virtually all known Wikis and only cross referencing your pages to those Wikis that people use MoinMoin style prefixes to manually cross reference to. A threshold could be manually set. This is obviously way too complex to be a standard, especially a Wiki one, but it does illustrate that both ideas are useful, and that a middle ground can be reached on each Wiki. The key thing is not that Wikis succumb to any sort of automatically, just that they allow it to happen. Under this proposal, the only thing required is a published InterMap - PublicallyEditableInterMap or not. WardsWiki does this, and that is enough to enable TinyWiki to cross references its pages to there - both Wikis share essentially the same topic though TinyWiki is run with an iron fist and has a very specific agenda to match. WardsWiki would almost certainly not want to cross reference its pages to TinyWiki. I'm mirroring this discussion so far at http://wiki.slowass.net/?InterWiki - where it really belongs. TinyWiki also demonstrates another automated cross referencing concept - automatically linking back to anyone that links to you.
I appreciate the attempt to explain the problem described on PublicallyEditableInterMapForSnapshot, I have wondered about it a bit. I must admit, I am still puzzled how the "damage" could happen. Technologically blahh, MarkDilley
At Sunir's urging for more detail, I'll do what I can: - why is a publically editable inter map any less safe then a txt file? I do not understand the security and destruction risks involved in having this list be publically edited. Can some bot use it to easily overwrite sites? I am curious about this because of the OneBigWiki project. Besides Sunir's assertion that it is just not neccessary. Is it "dangerous"?
[CategoryMeatballWikiSuggestion] [CategoryWikiTechnology] [CategoryUncommonWikiTechnology]