InterCartePubliquementEditable

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette carte a démarré sur PublicallyEditableInterMap

index InterCarte publiquement éditable -- une suggestion pour l'InterCarte (rejeté)

Publiciser l'index InterCarte de façon à ce que les utilisateurs finaux puissent le maintenir. Au lieu de lire le fichier intermap.txt (ou ce que vous voulez), cela consisterait à tirer la page InterMapIndex? qui aurait le format commode :

SobriquetEtranger?: http://exemple.com/base-url
MeatballWiki: http://meatballwiki.org/wiki/

: Il est très peu probable que cela arrive. Probablement, le plus gros problème est que cela ouvre des liens InterWiki vers des adresses complètes HTML utilisant un serveur distant. Par exemple, imaginez que quelqu'un soit en train de relier "Wiki:" à un site contenant des exploits malicieux du type HTML/ActiveX/Java-VM-bug. En passant, l'utilisateur a réalisé que le lien n'allait pas être celui qu'il attendait, son système pourrait être détruit.

: Je prévois néanmoins de faire qu'il soit beaucoup plus facile pour le(s) administrateur(s) de maintenir l'index InterWiki. (Si un site choisit d'ouvrir l'administration à tous, ce sera son choix). Tous les utilisateurs devraient pouvoir proposer facilement de nouvelles entrées et modifications pour la révision.

ZWiki implémente ceci à travers son schéma ZWiki:RemoteWikiURL. Au lieu d'avoir une liste centralisée, les formulaires de liens sont maintenus sur des pages séparées décrivant les pages étrangères. Peut-être que le hack le plus chouette était l'inclusion de ZWiki:FatBrain. -- SunirShah

Voir aussi Tavi:InterWiki et Tavi:SisterWiki pour l'implémentation de WikkiTikkiTavi d'une intercarte éditable par l'utilisateur.

Je ne comprends pas l'objection de sécurité. Je ne pense pas que la simple syntaxe d'un lien interwiki, à l'oppos d'une URL normale, doive être prise comme disant quelque chose à propos de la sécurité du site distant.

Voilà une explication plus complète :

Supposons qu'un agresseur crée un site web qui contienne un script unique. Le script ignore n'importe quels arguments ou paramètres et renvoie du code HTML "mauvais". Ce "mauvais" code HTML pourrait prendre partie des brèches dans ActiveX, Java, Javascript, ou d'autres parties du navigateur. Selon le navigateur/OS de l'utilisateur, et quelles sont les fonctionnalités autorises, les conséquences pourraient être drastiques.

Normalement, ceci n'est pas vraiment un problème. On a confiance en des sites ordinaires qui ne lient pas vers de tels endroits. Sur la plupart des sites, le contenu publiquement éditable (qui pourrait lier vers des mauvais sites) est séparé du contenu principal du site, aussi il est clair de savoir qui est responsable.

Sur un wiki, néanmoins, tout le monde peut éditer (presque) n'importe quel texte sur le site, y compris le texte de confiance plus ancien. Les personnes apprennent à gérer les problèmes de confiance dans un wiki et devraient être sceptiques à propos des plaintes étranges sur une page. Par exemple, si la page CliffordAdams prétent que Cliff a toujours détesté Perl (et que le FORTRAN est l'Unique Véritable Langage de Programmation), alors quelqu'un d'autre a dû probablement passer un bon moment.

On peut apprécier les insécurités étranges d'un wiki et même rire sur des éditions étranges produites par des parties tiers. Les arrêts amusants quand les éditeurs peuvent provoquer des dégâts sérieux immédiats, tout spécialement si les victimes ne penses pas qu'elles prenaient des risques.

Sur quelques wikis (qui autorise le HTML arbitraire), une personne seule et méchante pourrait abîmer plusieurs systèmes (avant qu'elle ne se fasse bloquer en édition). Sur d'autres wiki qui autorisent des liens distants arbirtrairement nommés, "CliffordAdams" ou "RecentChanges" pourraient être des liens vers un site mauvais/à dégâts. Sur les wikis qui permettent l'édition InterWiki, "MeatBall:RecentChanges" pourrait être mauvais. Pour conclure, sur la plupart des sites (y compris celui-ci), "http://www.quelque.mauvais.site.exemple/montruc" pourrait être un mauvais lien, mais au moins on sait où on va.

Les utilisateurs pourraient vérifier chaque lien avant de cliquer, mais je doute que beaucoup de gens s'ennuieraient à cela. Si un site permet des liens InterWiki éditables, alors les agresseurs peuvent rediriger un grand nombre de liens populaires avec un effort minimum. (Un résultat possible serait que les auteurs éviteraient d'utiliser les liens InterWiki et écrivent des URLs complètes.)

Une chose que j'aime à propos des liens restreints dans les wikis est la "transparence". Si la page affiche "RecentChanges", ou tout autre lien WikiNom, on sait qu'on visite une page locale. Les liens InterWiki comme "Wiki:RecentChanges" continueront à pointer vers le wiki de Ward, et non pas vers quelque autre site. Les utilisateurs peuvent encore cliquer sur des URLs brutes mais la destination est évidente. On peut facilement éviter les sites qui ne sont pas de confiance. --CliffordAdams

Une solution

Nous pourrions utiliser un schéma de RemplacementFichier? comme suggéré sur cette page. -- SunirShah

28 mars 2002. La première fois que l'InterCarteTxt a été remplacée. Il y avait quelques bugs, je les ai réparés.

J'ai eu le sentiment que le projet InterCarteTxt a été d'accepter de nouvelles entrées. Beaucoup d'entrées de nos jours n'ont même pas de liens sur MeatballWiki, qui semble farfelues comme l'est notre intercarte. Je pense que c'est parce que les personnes l'ont transformée en un énorme annuaire téléphonique de tous les wikis qui ont croisé notre chemin. Je ne pense pas que cela fonctionnera ni nous pour nous ni pour elles, aussi ai-je une nouvelle solution.

D'abord, encourager une retouche fréquente du fichier InterCarteTxt emêche son adoption via le RemplacementFichier?. Je m'attendais à ce que les modifications sur l'intercarte soient peu nombreuses et espacées, parce que traditionnellement Cliff et moi y ajoutions les wikis vraiment de manière très peu fréquente. Bien sûr, une entrée ne serait seulement acceptée qu'après quelque examen sur les SuggestionsInterCarte. De nos jours, aucun examen n'est requis, aussi les modifications peuvent être produites directement par tous ceux qui les proposent.

Ce manque d'examen a eu deux effets immédiats. D'une part, il n'y a plus d'égos meurtris face au fait de s'être vu rejeté un wiki pour un animal domestique par nos opinions arbitraires. Ceci a créé un manque de conflit par ElargirEspace D'un autre côté, les entrées manquant de valeur directe pour MeatballWiki se sont vues ajoutées en abondance, encombrant désormais la liste. Encombrer la liste, je pense, réduit nos désirs de RévisionParLesPairs l'intercarte. Au moins cela réduit mon intérêt parce que je suis vraiment certain que je ne serai pas intéressé suffisamment par les wikis ajoutés pour aller les visiter afin de voir s'ils veulent la peine d'être ajoutés. Le manque de révision par les pairs crée véritablement des opportunités dangereuses pour subvertir le système, et ajouter des attaques de sécurit et des liens vers des contenus gênants

Si nous laissons cela continuer, nous pourrions devenir connus comme la liste canonique des sites InterWiki. Je ne pense pas que ce soit une bonne route à suivre. Voir Meatball mandater d'autres communautés sur ce qu'elles devraient faire, quelle intercarte devrait t'elle cotnenir, n'est pas une position sans difficultés. Aussi, si nous deveons une DNS efficace des wikis en canonisant les sobriquets InterWiki, nous finirons par devoir résoudre encore plus de noms de conflits, un business très distrayant. Si vous ne pensez pas que cela arrivera, nous avons déjà le conflit entre les deux IAWikis : "information architecture" et "information anarchy". Je pense que c'est mieux de laisser chaque wiki décider par lui-même quel devrait être son intermap. Je pense aussi que c'est bien d'encourager d'autres wikis à publier leurs intercartes de façon à ce qu'elles puissent être échangées comme désiré. Et si MeatballWiki ne devient pas une liste canonique des sites InterWiki, je pense qu'il est valable de conserver notre liste aprévenant de la manière dont il pourrait déranger le RemplacementFichier?, etc, lui disant où est la pages de discussion/queue associée avec la page RemplacementFichier?, et lui demandant de ne pas continuer à moins qu'il ne pense connaître ce qu'il est en train de faire ; il doit cliquer sur un certain lien sur cette page là afin que la Sauvegarde réussisse. Le texte de la page "Etes-vous SUR ?" pourrait être une page standard éditée par la communauté-wiki. -- BayleShanks

Les types de dialogues "Etes-vous SUR" ne sont pas une InterfaceHumaine. -- AlexSchroeder

Proposition : Basée sur l'expérience des MultiUserDungeons? - jeux indépendants, sur un serveur unique, généralement dérivés d'un ensemble de bases de code. Ces jeux ont réseauté avec grand succès au milieu des années 90. Chaque serveur avait un fichier "hosts", listant tous les autres jeux qu'il connaissait. Les communications inter-mud consistaient de canaux fondés sur le chat pour échanger des fichiers, qui était de la diffusion vers chaque hôte listé en utilisant UDP, ou des messages de point à point, aussi en UDP, pour échanger des fichiers, des emails, aller vers l'information et ainsi de suite. Chaque jeu essayant de maintenir à jour son fichier "hôtes" faisait face à l'impossible - les jeux venaient, allaient et bougeaient bien trop vite. Pister les modifications serait un job à plein temps pour chaque personne sur chaque site. Ceci était le premier pas de l'évolution. Le second était que peu de jeux faisaient un bon travail pour maintenir leurs listes à jour, aussi tout le monde utilisait simplement sa liste. Le troisième et le dernier était pour chaque jeu de distribuer sa liste à la demande, et le logiciel qui allait automatiquement en récursivité dans la liste : chaque nouveau jeu qu'il rencontrait serait requêté pour sa liste d'hôtes et ainsi de suite. Les entrées qui ne fonctionnaient pas étaient facilement détectées, et les noms étaient pris sur une base du premier-venu-premier-servi : si vous utilisez un jeu de confiance comme votre noeud racine, il y avait très peu de chance d'avoir quelqu'un empoisonnant la database distribuée. Ceci obligerait seulement chaque serveur à avoir une _non_InterCartePubliquemenEditable mais au lieu d'une privée, c'était une publiée au format standard. Chaque wiki listerait d'autres wikis qui sont de confiance. En fait le wiki chez http://wiki.slowass.net a un moteur informatique de mesure de confiance, inspiré par AdvoGato, intégré, qui pourrait être utilisé pour calculer les intervalles de confiance

 sur un graphe de flux maximum - qui lie vers où et combien de liens il y a là vers là.

Ceci colle avec les principes de simplicité et d'autonomie, et permet à chaque hôte de référencer autant ou ausi peu du WikiWikiWeb que désiré. Si vous avez quelque intérêt en cela, signez svp le "guest log" sur http://wiki.slowass.net/?GuestLog - j'ai déjà implémenté la plupart de mes propositions sur ma bifurcation wiki, et je le ferai à nouveau. J'aimerais commercialiser des idées mais ne vais garder un oeil ici - désolé. Trop occupé à coder, pas à parler. Mon wiki bifurqué est déjà en train de lier vers des pages si elles existent sur le wiki C2, et il rétrolie automatiquement vers des pages qui lient vers des pages ici, à la fois implémentées dans des ActiveWikiPages.

Si votre objectif est d'avoir chaque wiki bien connecté, c'est le chemin à suivre. Néanmoins, mon sentiment est qu'il est bien d'avoir un "voisinage" relativement limité -- comme un rolodex de personnes que vous avez vraiment rencontrées, plutôt que des pages blanches de tout le monde dans votre ville. A nouveau, peut être que l'InterWiki n'est pas l'endroit pour faire cette chose de voisinage, je ne sais pas. -- BayleShanks

Il existe deux intentions conflictuelles et vous les avez listées. Si d'un côté, vous avez un référencement croisé de votre wiki avec un autre pertinent sur le sujet ou vous avez quelque relation sociale avec, une InterCartePubliquementEditable n'est pas la solution. Si vous voulez faire quelque chose comme MoinMoin le fait et donner simplement aux personnes des moyens faciles de pointer vers des wikis arbitraires mais qui ne se cross-référencent pas automatiquement, connaître des tonnes et des tonnes de wikis est une bonne chose. Il y a bien sûr un compromis similaire à ce qui se passe sur le réseau Gnutella : cross-réference vers ceux immédiatement proches, et ceux immédiatement proches à un doigt, avec un niveau limité de récursivité, favorisant ceux qui sont les plus solidement interconnectés - je suis un grand fan de l'idée de la MétriqueConfiance?. Avoir une InterCarte de virtuellement tous les wikis connus et ne cross-référençant que vos pages vers ces wikis que les gens utilisent les préfixes de style MoinMoin pour cross-référencer manuellement. Un seuil pourrait être réglé manuellement. Ceci est évidemment une manière trop complexe pour que ce devienne un standard, tout spécialement un standard wiki, mais cela illustre vraiment que les deux idées sont utiles, et qu'un compromis peut être atteint sur chaque wiki. Le point-clé n'est pas que les wikis succombent à toute sorte d'automatisme, simplement qu'ils permettent que cela se produise. Sous cette proposition, la seule chose requise est une InterCarte publiée - qu'elle soit ou non une InterCartePubliquementEditable. WardsWiki fait ça et c'est suffisant pour permettre à TinyWiki de cross-référencer ses pages vers là - les deux wikis partagent en fait la même thématique bien que TinyWiki tourne d'abord avec une main de fer et a un ordre du jour à remplir très spécifique. WardsWiki ne voudrait certainement pas cross-référencer ses pages vers TinyWiki. Je suis en train de mettre en miroir cette discussion à ce stade sur http://wiki.slowass.net/?InterWiki - où elle appartient vraiment. TinyWiki démontre aussi un autre concept automatisé de référencement croisé - rétrolier automatiquement vers quiconque qui vous lie.

J'apprécie la tentative d'expliquer le problème décrit sur PublicallyEditableInterMapForSnapshot, j'y ai réfléchi un peu. Je dois admettre, que je suis encore en train d'élucider comment les "dégâts" pourraient survenir. Technologiquement blahh - MarkDilley

Pour Sunir pressant pour plus de détails, je ferai ce que je pourrai : pourquoi est-ce qu'une intercarte publiquement éditable est moins sûre qu'un fichier txt ? Je ne comprends pas les risques de sécurité et destruction inclus par le fait d'avoir cette liste publiquement éditable. Est-ce que quelque robot peut l'utiliser pour facilement écraser des sites ? Je suis curieux d'en savoir plus à ce propos du fait du projet OneBigWiki. Aux côtés de l'assertion de Sunir que cela n'est pas seulement pas nécessaire. Est-ce "dangereux" ?

LangueFrançaise PageTranslation PublicallyEditableInterMap DossierSuggestionMeatballWiki DossierTechnologieWiki DossierTechnologieWikiNoncommune

InterCartePubliquementEditable

Une solution

Discussion