Knol est un projet d'encyclopédie en ligne qui a été lancé par la firme américaine Google en 2007.
L'idée centrale de Knol, par opposition avec Wikipédia, est de mettre en avant les auteurs. Tous les articles sont signés et une présentation de l'auteur est disponible sur le site. La modification du texte est, par défaut, réservée au contributeur original et les différents articles sont notés par les lecteurs.
Le but affiché officiellement par Google est de satisfaire le besoin de reconnaissance des auteurs, ce qui allait inciter ces derniers à contribuer en masse à Knol. En plus les contributeurs peuvent recevoir une rémunération en faisant apparaître des liens sponsorisés sur les pages de leurs articles.
Enfin la signature des articles pouvait être envisagée comme étant un filtre privilégiant la qualité par rapport aux contributions anonymes de Wikipédia.
Dans la réalité les choses sont bien entendu moins roses. Tout d'abord Google redirige des millions de connexions vers Wikipédia mais ne peut pas gagner d'argent avec ce trafic puisque l'encyclopédie libre ne contient pas de publicité.
Les internautes on vite compris que, par opposition à Wikipédia, une page Knol rapporte de l'argent à Google car elle contient des liens AdSense. La motivation de la firme américaine était donc vraisemblablement moins « pure » que ce qui était affiché.
Ensuite le filtre de qualité que représente, soit-disant, la signature des articles, est en réalité une vaste plaisanterie. Google ne vérifie pas l'identité de l'auteur et on peut donc publier sur Knol sous une fausse identité. La présentation de l'auteur (expertise, diplôme, profession, etc) peut également être complètement bidonnée.
Le fait d'interdire toute modification par défaut ne permet plus de corriger les erreurs ou les élucubrations de l'auteur. Comme Knol n'a pas de comité de filtrage éditorial, on y trouve quantité d'articles simplement faux ou sans aucun sens. Comparez par exemple l'article Wikipédia consacré au paradoxe bien connu de « L'oeuf et la poule » avec sa contrepartie absurde chez Knol.
David Monniaux à parfaitement résumé ces inconvénients de knol lors de plusieurs posts sur son blog (1 - 2).
Du fait de ces défauts, et aussi du succès de Wikipédia, Knol n'a jamais vraiment réussi à percer. Google vient donc d'en tirer les conséquences et a annoncé la fermeture du projet.
Bien entendu il faut sauver la face et la firme de Mountain View a donc décidé de travailler avec deux petites entreprises (Solvitor et Crowd Favorite) pour mettre en place un dérivé de Wordpress qui accueillera les articles de Knol:
We launched Knol in 2007 to help improve web content by enabling experts to collaborate on in-depth articles. In order to continue this work, we’ve been working with Solvitor and Crowd Favorite to create Annotum, an open-source scholarly authoring and publishing platform based on WordPress. Knol will work as usual until April 30, 2012, and you can download your knols to a file and/or migrate them to WordPress.com. From May 1 through October 1, 2012, knols will no longer be viewable, but can be downloaded and exported. After that time, Knol content will no longer be accessible.
Pour résumer: A partir d'avril 2012 on ne pourra plus voir les articles de Knol. A partir d'octobre 2012 la prise de courant sera complètement retirée.
Alors qu'est-ce qui reste en face de Wikipédia dans le domaine des encyclopédies ouvertes aux contributions ?
Une alternative plausible pourrait être le projet Citizendium, créé par Larry Sanger, un des fondateurs de Wikipédia.
Mais Citizendium, lancé en septembre 2006 en ayant pour but de faire valider les textes par des experts, a seulement réussi à valider 156 articles depuis sa fondation. Cette encyclopédie n'a reçu que 81 éditions en tout et pour tout dans la journée du 23 novembre 2011 (page de statistiques).
Il est clair que ce mode de fonctionnement qui exige une validation ne fonctionne pas et que le projet est en état de mort clinique.
Il semble bien que Wikipédia, malgré tous ses défauts régulièrement pointés pas les médias traditionnels, a réussi à faire le vide autour d'elle.
Créé pour être « Le projet d'encyclopédie librement distribuable que chacun peut améliorer », Wikipédia a su tenir ses promesses. La participation est ouverte à tout le monde et ces contributions collectives améliorent le contenu qui est placé sous une licence libre.
Pour que cette inestimable ressource puisse continuer à vivre il faut donc soutenir Wikipédia !
# 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Il y'a quelque temps, je songeais aux outils nécessaire pour créer une société digne de 1984. Wikipedia en ferait partie. Actuellement une telle majorité de personnes utilisent Wikipedia comme source de "vérité" qu'un "simple" proxy réécrivant les articles à la volée suffirait à créer une vérité intemporelle (X est en guerre avec Y et a toujours été en guerre).
Bien entendu le problème n'est pas Wikipedia mais le fait qu'on ne puisse identifier si un article est réellement l'original où s'il a été modifié durant le transport.
En tous cas, ça serait un projet marrant que de créer "wiki1984" où l'on retrouve le même contenu que Wikipedia, mais rendu intemporel. Et je suis certain qu'il soit possible de vendre ça à nos démocraties (et, naturellement, aux dictatures restantes).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par mr_spoke . Évalué à 6.
Wikipédia est accessible en HTTPS.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Le SSL garantit rien. Les Root CA sont pourris (les dernières attaquent sont là pour le montrer), ne respectent pas les règles (des "localhost" (ou pour des IP privée, ou autre) en certificat EV ou des clés de 512 bits ça existe https://www.eff.org/files/ccc2010.pdf), le protocole est mal fichu (comment tu gères les révoquations http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (ou poses-toi la question "Comment je sais si un certificat est valide ou pas ?" et essaie d'y répondre)), les implémentations foireuses (de moins en moins, c'est vrai), ... Et combien de pays ont un Root CA ? De tête je peux te citer la Suisse, la France, l'Allemagne et les États-Unis. Il devrait en avoir certainement plus, regarde la liste de ton navigateur.
Voilà, voilà ... SSL c'est pour brûler du temps processeur et faire croire "qu'on" se soucie de la sécurité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Juke (site web personnel) . Évalué à 0.
Le jeudi 24 novembre 2011 à 12:54 +0100, Etienne Bagnoud a écrit :
> Et combien de pays ont un Root CA ?
rien ne t'empeche de le retirer non ?
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Oui, il faut retirer tous les CA. Mais après tu ne sais plus si le certificat Wikipedia est le bon, donc n'importe lequel est correct.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu attaques gratuitement SSL parce que des tiers de confiance ne sont plus de confiance. Il n'y a pas de rapport.
Il faut "juste" un tiers de confiance commun entre le site et toi, et ton "problème" est réglé. Il y a de quoi faire aussi pour les révocations.
Si toi et le site n'avaient pas de tiers de confiance commun, ben oui, ça ne marche pas. A toi de te mettre d'accord avec le site que tu veux visiter, c'est tout. Pour le moment, Wikipedia fait confiance à Equifax, tu vires tous les autres certificats qu'Equifax et basta (et si tu n'as pas confiance en Equifax, ben charge à toi de te mettre d'accord avec Wikipedia pour trouver un tiers commun, ou pas de tiers si tu veux et a un autre moyen de valider le certificat).
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Pour un protocole dont la sécurité est basée sur les tiers de confiance, je trouve qu'il y'a un rapport assez flagrant.
Dans le reste de ton message tu omets beaucoup de détails sur SSL. Comment je sais que le CA d'Equifax dans mon navigateur est le vrai d'Equifax vraiment ? Je vais regarder sur le site d'Equifax s'il donne l'empreinte SHA-1 du certificat, ok. Quel protocole sécurisé je vais utiliser pour m'assurer que l'empreinte SHA-1 n'a pas été modifié, ainsi que le CA que je télécharge depuis le site d'Equifax, durant le transport ? HTTPS, le problème : je n'ai aucun tier de confiance, j'ai quoi ?
Ok, continuons, par quelle méthode Wikipedia a obtenu son certificat ? Non parce que, d'expérience, c'est par SMTP/IMAP que j'ai obtenu des certificats de sécurités auprès d'un CA. Comment Equifax a vérifié l'identité de Wikipedia ? D'expérience, SMTP/IMAP de document facilement falsifiable (une carte d'identité scannée en n/b ça passe tranquille).
Et Equifax, c'est qui d'abord ? Quel gouvernement, société ou peut-être quel gamin de douze ans ? Leurs serveurs, ils ont quoi comme portes dérobées, les clés sont-elles en sécurités ? Leurs outils de gestion de certificat, quel code est utilisé ? Sont-ils sécurisés ? Qui les a écrit ? La mafia, un gouvernement, un gamin de douze ans ?
Bref, il y'a une quantité énorme de question que le protocole SSL ne solutionne pas, pratiquement tous les CA ont été compromis ou on fait des erreurs à la "vas-y que je te fasse un certificat EV 512 bits de localhost expirant dans 10 ans" ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 0.
Tu sais vraiment ce qu'est un tiers de confiance? Tu as la charge d'avoir le certificat du tiers de confiance (chez moi, c'est installé avec l'OS, oui je lui fait confiance).
Oui, il y a toujours un problème de tiers de confiance. Mais sinon, c'est quoi ta solution? GPG? Même problème pour récupérer la confiance.
Vire ton fournisseur. Perso, c'est par accès SSL (dont j'ai confiance).
Tu sais ce qu'est un tiers de confiance? Tu ne fais pas confiance à ton tiers --> Négocie avec Wikipedia, qui lui dit "je t'emmerde si t'es pas content, va voir ailleurs". Si lui pense aussi qu'il y a un problème, encore une fois, vous vous mettez d'accord sur le tiers.
Ton tiers de confiance commun.
SSL, c'est horrible. Sauf qu'il n'y a pas mieux (non, GPG ne résoud pas le problème non plus)
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Personne ne sait, c'est le début du problème. Rien empêche, ton tiers de confiance, de générer une paire de clé pour chaque clé publique signée et de distribuer cette pair de clés auprès de tous ses clients qui auraient souscrit à l'abonnement "surveillance automatique d'Internet". Comme on ne sait pas qui fait quoi et qui est qui, on sait pas ce qui est signé chez qui par le tiers de confiance.
Et ? Parce qu'il y'a piège ici :)
Un tiers de confiance, c'est une entité en qui on a confiance de la véracité des informations fournies. Donc dans ce cas il s'agit du tiers de confiance de Wikipedia, pas du mien. Et Wikipedia n'est pas plus un tiers de confiance que le monsieur qui m'envoit des courriers électroniques me proposant de gagner plein d'argent si je l'aide ou que la fille qui passe une nuit dans mon lit et que je ne reverrais plus jamais (d'ailleurs j'ai certainement donné un faux nom).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à -2.
Je t'invite à ouvrir un dictionnaire. Tu peux commencer par l'explication de Wikipedia.
C'est cool, tu as la solution parfaite au problème. Bizarrement, personne n'y croit.
C'est grave quand même... Tu n'arrives même pas à lire. Il faut que je mette commun comment? en police 500?
Il s'agit de votre tiers de confiance commun. Tu refuses le tiers? Ok, donc charge à toi de te mettre d'accord avec Wikipedia pour votre transfert, car tu refuses le tiers proposé. Je te rassure : Wikipedia dira : tu fais chier, j'en propose un, si tu n'es pas content je vais pas m'emmerder avec un gus chieurs comme toi, mon tiers de confiance étant accepté par tout le monde même sous Linux.
Tu mélanges tout (par exemple les mails sans tiers de confiance), tu refuses de faire confiance aux tiers, ben, c'est ton problème. Ca n'enlève pas que SSL marche, et bien. Mais SSL repose sur des tiers, ben oui, c'est la vie, personne n'a envie d'aller dans le datacenter de Wikipedia pour récupérer la clé publique.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Normal, ce n'est pas une solution. Je te donnais un cas où ta fameuse (et fumeuse) autorité de confiance (je tiens à dire que ce terme n'apparaît pas une seule fois dans la norme X.509 ni dans les RFC) fournissait un moyen automatique d'usurper "l'identité" de n'importe quel site Web. Et le fait que tu n'aies aucunement clarifier ta position sur mon piège m'amène à cette conclusion : tu n'as jamais lu la série de documents X.500 (je sais c'est chiant a lire, mais c'est un peu essentiel pour comprendre SSL).
Bon alors l'autorité de certification, d'après X.509, c'est "an authority trusted by one or more users to create and assign certificates" (une autorité ayant la confiance de un ou plusieurs utilisateurs pour créer et assigner des certificats) (c'est repris dans la RFC 1422). X.509 définit aussi le terme confiance et ce qui devient intéressant : "[...] the entity shall be certain that it can trust the autherity to create only valid and reliable certificates." ([...] l'entité doit être certaine qu'elle puisse faire confiance en l'autorité pour produire uniquement des certificats valides et fiables).
Section 6.1 de X.509 indique clairement qu'une signature d'un CA sur une clé publique certifie la relation entre le sujet du certificat et le certificat. Un problème : aucune garantie n'est donnée par les CA à l'heure actuelle.
Ensuite la RFC 5280 inique clairement :
Est-ce que ça a été appliqué dans les derniers cas, genre Comodo ? Non.
Et la liste de problème est encore longue, je te laisse aller voir la page wikipedia sur le sujet X.509 ;) moi j'en ai un peu marre là.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par CHP . Évalué à 2.
Donc c'est l'implémentation de SSL qui est mauvaise, pas SSL en lui meme (en gros, ca marcherait si les CA faisaient leur boulot comme indiqué dans la norme)
Meme remarque
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est le point de départ de cette discussion (les CA font n'importe quoi, les implémentations aussi, ...), mais avec la sécurité, on peut pas jouer, soit c'est sécurisé, soit ça l'est pas; un truc genre "ouais c'est presque bon, mais bon on a pas mieux" : c'est pas sécurisé. Donc SSL ne garantit rien. Ta page Wikipedia en HTTPS peut, actuellement, de tellement d'autres personnes que Wikipedia, autant faire un geste pour la planète et aller en HTTP (calcul en moins, énergie consommée en moins).
Mais il y'a d'autres problèmes avec SSL parce qu'il est dérivé de X.509 et toutes les parties X.500 ont été gardées mais ne sont pas utilisables dans un annuaire LDAP, de plus il y'a trop de truc laissé à l'interprétation de l'implémentation.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 1.
Forcément, si les autres sont tous des mauvais, par définition il n'y a aucun système qui pourra te convenir, car dans tous les cas il y a aura toujours un autre dans le coin.
a partir de là, c'est bien joli de cracher sur Commodo et compagnie, mais par définition, tu ne peux pas avoir un truc que tu ne critiqueras pas.
Donc, je me répète : l'attaque est gratuite. SSL n'est pas la solution parfaite méga géniale, on sait, mais c'est la "moins pire".
[^] # Re: 1984 et Wikipedia
Posté par patrick_g (site web personnel) . Évalué à 3.
Un pdf excellent de Stéphane Bortzmeyer : http://www.bortzmeyer.org/files/jres2011-dane-article.pdf
[^] # Re: 1984 et Wikipedia
Posté par Alex . Évalué à 2.
Je ne vois pas trop la différence (enfin si, ça à tout de même l'air plus sur que dnssec)
La solution proposé passe par dnssec, donc elle implique également une confiance dans celui qui te fournira le certificat du racine. Evidemment l'aspect hyper centralisé fait que tu peux même apprendre le fingerprint par coeur, mais ça sera loin d'être le cas de tous.
De plus dnssec est encore peu testé, on a le temps d'y trouver des failles.
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 1.
J'aurai plus confiance dans celui qui fournit le DNS, que les dizaines de tiers bizarres actuellement.
Mais bon, j'ai pas tout suivi, donc je peux me tromper.
[^] # Re: 1984 et Wikipedia
Posté par Alex . Évalué à 2.
J'ai lu une doc de travers (même pas la rfc), mais il me semblait qu'il y avait quelques limites tout de même:
en fait tu n'as qu'une rootca, mais toujours une multitude de ca. De plus il me semble que la norme n'impose pas une séparation obligatoire de la zsk et de la ksk, ce qui implique que l'on aura un certain nombre de clés "exposés" (disons aussi exposé que la clé d'un serveur web). Tu es évidemment moins exposé (un dns n'étant responsable que de sa zone et indirectement de ses zones filles, et pas d'une multitude de sites comme avec ssl).
D'autres craintes que j'avais: les zsk ont une durée de vie très courte (quelques jours il me semble), je me demande si on ne verra pas un de ces 4 un cuak lors des renouvellements de clés.
J'avais aussi constaté dans la doc que j'avais lu que nulle part il n'était mentionné de procédure pour révoquer une clé, si c’est le cas on risque d’avoir des problèmes avec les clés dont l’invalidité n’est pas encore connue.
Bon je me trompe peut être complètement, mais tu m'as trouvé mon sujet d'occupation pour demain: me lire les rfc, et voir si je ne trouve pas 2/3 témoignages de déploiement.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Non, dans les conditions actuelles la moins pire est celle utilisée par le protocole SSH, la seule et unique raison de la survie de SSL c'est qu'il s'agit d'une machine à fric énorme : tu paies des prix de fou pour rien vu que personne dans le circuit peut offrir la moindre garantie.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 2.
Comment je fais avec SSH pour savoir que le serveur est le bon la première fois que je me connecte à ce serveur?
La réponse m’intéresse, parce que je n'ai pas la réponse, et du coup je m'interdis de me connecter à un serveur la première fois et qu'on me demande de valider la signature les yeux fermés, à partir d'un réseau public (bien qu'on s'en foute de moi, c'est pour le principe)
Mais bien sûr... J'ai plutôt l'impression que tu n'as pas bien compris à quel besoin SSL répond, vu ce que tu proposes comme "mieux".
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Bon je fais vite : actuellement avec SSL tu ne sais jamais à qui tu te connectes puisque personne ne peut (dans le sens avoir la capacité) te certifier que le serveur en question est bien le bon que tu veux. En cas de pépin, comme on a vu avec des affaires à la DigiNotar ou Comodo, il peut se passer presque un mois avant que tout le monde soit au courant (dans le sens la diffusion des clés soit faite).
Avec un protocole comme SSH, tu as la 1er connexion qui pose problème (et ça il y'a des solutions proposées existantes genre avec l'enregistrement DNS ou en passant par des réseaux de confiance, mais bref, j'ai dis que je faisais vite). Une fois la première connexion effectuée, tu as une garantie que le serveur est toujours le même, en cas de problèmes la révocations des clés se fait à la connexion du client (donc pas de temps mort, tu te connectes, tu sais que la clé a changé) et il n'y a pas 1 et 1 seul point central à compromettre pour que la sécurité globale s'effondre (avec SSL, un seul CA compromis et la sécurité s'effondre).
Je crois, non, je suis certain que tu n'as rien compris à X.509 et SSL. Et je sais quand utiliser X.509, sinon je ne l'utiliserais pas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 1.
Et oh miracle, c'est ça le besoin. Aller sur un site qu'on ne connait pas, comment on fait la première fois? Ta solution, ben elle ne répond pas au besoin. Ben oui, dans la vraie vie, les gens ils vont d'un site à l'autre, ils découvrent. Saloperie de besoin, vraiment, faut changer le besoin si la solution ne convient pas au besoin.
Lequel? DNSSEC, c'est à peine déployé. Donc aucune sécurité.
Comme tu fais confiance à personne, c'est dur non? Le réseau de confiance, je l'ai. Et entre Wikipedia et moi, j'ai un lien de confiance (qui s'appelle Equifax). Toi, c'est de la théorie.
Fait vite, parce que ça ne marche pas.
Alors la j'éclate de rire. la clé est révoquée, mais... Quand tu te connectes, tu te connecte sur le mauvais serveur, qui a la clé volée mais qui n'est pas l'objectif et hop... T'es mot, MITM qui se passer pour le serveur légitime. Rejoue. La seule chose que fait SSH, c'est te protéger d'un MITM, alors que SSL te permet de révoquer des certificats. Avec ton SSH, on est juste mort à la moindre perte de clé privée qu'on ne connait pas. C'est un truc qui marche quand tu contrôles le client et le serveur (quand tu sais que ton serveur s'est fait troué, tu changes côté client, client que tu connais et accède par un autre moyen).
Et si je change la clé privée sur le serveur, légitimement, je fais comment pour avertir les millions de clients que c'est légitime?
Tout ce que tu racontes, c'est juste inutile pour le cas de l'accès à Wikipedia (x clients, x étant grand). Mais bien sûr, toi tu as la solution ultime, et tu es le pauvre que personne n'écoute. Ou alors c'est que ta solution meilleure, elle n'est pas meilleure (et qu'elle ne répond pas du tout au besoin).
D'ailleurs c'est bizarre, des gens ont trouvé utile de mettre X.509 (le truc pourri pour toi) sur des clients et serveurs sshd (alors que le truc bien pour toi existait avant), mais personne n'a trouvé utile de mettre SSH sur des navigateurs et serveurs webs. Comment dire... Ah oui : tu ne proposes rien de mieux que la techno sur laquelle tu craches.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
J'ai oublié un truc, SSL, c'est l'enregistrement DNS qui permet l'identification du serveur ? Je crois bien que oui ... je crois bien que tu en arrives à démonter toi même SSL :) Tu comprends, petit à petit ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Antoine . Évalué à 2.
Heu comment ça ? Le serveur t'envoie un certificat correspondant, certes, à un ou plusieurs noms de domaines (le sujet et les éventuels subjectAltName), mais c'est par rapport au nom d'hôte que tu désires contacter que tu vérifies, pas par rapport à un hypothétique enregistrement DNS.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 0.
Oui il contrôle que le nom taper dans la bar du navigateur soit identique à celui du certificat. Un DNS menteur pourrait être utiliser exactement comme dans le cas cité par Zenitram.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Antoine . Évalué à 2.
Non... Encore une fois, qu'est-ce qu'un DNS menteur a à voir avec SSL ?
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à -2.
RFC 2818 dit :
Le nom est effectivement connu de la personne et sa résolution vers une adresse est faite par le DNS (principalement). Dans le cas, précité par Zenitram, où la clé privé du serveur a été volée et que l'attaquant utilise un DNS menteur pour faire atterrir example.com sur son serveur au lieu du bon, tu es cuit la même chose. Mais dans ce cas, il faut 2 attaques : une pour obtenir la clé privée (SSL ou SSH) et une autre pour faire mentir le DNS, donc on arrive sur le serveur de l'attaquant ayant volé la clé.
Et si tu as pris la discussion en cours (donc pas lu le sujet de départ), non SSL n'a rien à faire, fondamentalement, avec le DNS.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 4.
Non, parce que le certificat a été révoqué par le tiers de confiance (celui dans lequel tu n'as pas confiance, rappelle-toi, mais la, ben il est vachement utile) donc le certificat est bien plus protégé et toujours valide. C'est le but du jeu de SSL, entre autre, que ne permet pas ta super solution à base de SSH (qui elle, se fait planter en beauté dans ce scénario).
Les cas problématiques ont été quand le tiers ET le DNS étaient troués (de manière volontaire ou non pour le tiers, mais la il faut "juste" nettoyer les tiers pas de confiance plutôt que de critiquer SSL)
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Il n'est pas impossible de diffuser les certificats SSH corrompus, le cas Debian le démontre bien. Tu me diras qu'il faut une mise à jour et non pas l'utilisation des CRL, mais justement les derniers cas pour SSL montre bien que les CRL ou OCSP ne sont d'aucune aide, les certificats corrompus sont passé par des mise à jour. C'est un cas où il y'a encore du travail, peu importe le protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Antoine . Évalué à 3.
Bah on pourrait greffer le même système sur SSL : le navigateur enregistre le certificat (ou son empreinte) lors de la 1ère connexion, et s'il change lors d'une connexion ultérieure, une boîte de dialogue ou d'erreur est affichée.
Ce serait même assez trivial.
[^] # Re: 1984 et Wikipedia
Posté par Zenitram (site web personnel) . Évalué à 0.
Comme par exemple Certificate patrol?
This add-on reveals when certificates are updated, so you can ensure it was a legitimate change
Le monsieur raconte n'importe quoi, les défauts qu'il critique et dit que SSH est mieux, ben SSL le permet (ça existe même déjà, sauf que c'est chiant car les certificat, ça change et les utilisateurs normaux ne veulent pas une boite "attention ça a changé"), le problème est la première connexion, mais il dit que ce n'est pas le problème. On rigole bien, sauf pour la sécurité.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Non tu racontes n'importe quoi et à chaque question que j'ai posé tu as changé de sujet et surtout, tu ne prends pas la peine de lire les documents que j'ai proposé.
Enfin je te laisses avec ton SSL super-sécurisé et, même si je comprend rien, je retourne à mon travail.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Thomas Douillard . Évalué à 3.
Reste à savoir jusqu'ou tu es prêt à aller pour avoir parfaitement confiance dans le contenu de wikipedia ... je te propose d'aller physiquement dans un data center périodiquement, de faire un dump sur un disque dur que tu as préalablement vérifié pour ne contenir aucun firmware visant à corrompre spécifiquement le contenu de wikipedia pour te duper, et de ne consulter QUE ce dump.
Et de répéter l'opération chaque fois que tu veux une mise à jour.
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
C'est ce que je dis. On ne peut pas avoir confiance en Wikipedia uniquement, il faut vérifier l'information. Mais ce que j'ai remarqué : les gens font confiances à Wikipedia sans chercher plus loin, donc si je voudrais monter une société à la 1984, Wikipedia serait un outil très intéressant et intégrer dans la falsification de la vérité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Oui mais non, parce que là ce que tu dis c'est que les gens font confiance à une certaine source et qu'en compromettant le canal de cette source on pourrait manipuler ces gens. C'est valable pour toutes sources.
Je trouve qu'au contraire wikipedia met en exergue ce problème des sources multiples, là où avant le pékin moyen aurait lu un journal et écouter les commentaires au bar du coin sans ce poser ces questions des sources (multiples ou non).
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est pour ça que j'utilise le pronom "un" au lieu de "le" ... j'ai maintenu que ça serait "un outil" ou "aux outils [...] Wikipedia en ferait partie".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par passant·e . Évalué à 0.
Intéressant. enfin, même si le contenu de wikipédia devenait intemporel on a encore l'avantage - au contraire de 1984 - d'avoir des alternatives. ça me fait penser à la mode de l'insécurité qui avait pas mal réduit les alternatives.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: 1984 et Wikipedia
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
Oui enfin sauf que dans 1984, ce qui permet de changer les versions historiques des faits en permanence, c'est la centralisation poussée à l'extrême (et le fait que les anciennes versions deviennent illégales).
Wikipédia a un historique, et chacun peut copier la base et vérifier qu'elle n'a pas été modifiée entre temps; et comme pointé dans un autre commentaire, le transfert peut être sécurisé. Bref le modèle de 1984 est inapplicable à Wikipédia.
Bref, et au contraire justement, Wikipédia a un modèle qui permet d'éviter, ou au moins de limiter les modifications historiques, ou les zones d'ombres que l'on observe parfois dans les encyclopédies classiques ou les manuels scolaires.
Et en plus Wikipédia cite ses sources la plupart du temps (et si elles manquent c'est indiqué).
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est ce que je pointais et ce que le journal pointait :
Une centralisation de fait.
https://linuxfr.org/users/patrick_g/journaux/la-mort-de-knol-est-annonc%C3%A9e#comment-1293747
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par B16F4RV4RD1N . Évalué à 1.
sauf quand ils décident de supprimer un article, en ce cas l'historique n'est plus visible non plus.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: 1984 et Wikipedia
Posté par Tangi Colin . Évalué à 3.
le gros problème avec wikipédia n'est pas l'outil en lui même la manière donc la plupart des gens l'utilisent. Beaucoup trop de personne ne regarde pas les sources (pourtant bien mis en valeur à la fin de l'article), ni l'historique. Y a un gros travail d'éducation à faire.
[^] # Re: 1984 et Wikipedia
Posté par Julien Gilbert . Évalué à 5.
Dans ce cas le problème n'est pas wikipedia, mais aussi et surtout la confiance dans les résultats de google, la non remise en cause des informations trouvés sur tout site qui semble "de confiance", etc. La question de l'éducation est en effet essentielle.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: 1984 et Wikipedia
Posté par krouik . Évalué à 7.
[^] # Re: 1984 et Wikipedia
Posté par psychoslave__ (site web personnel) . Évalué à 3.
N'y a-t-il pas de multiples problèmes plutôt, il semble qu'on pourrait distinguer au moins ceux-ci :
Le premier pourrait trouver une réponse dans le domaine de la cryptographie. Les articles pourraient être signé numériquement par wikipedia, par exemple. Évidemment, ça vient avec toutes les limitations de la cryptographie :
- tiers de confiance et homme du milieu, dans le cas symétrique ;
- l'utilisateur ne comprends toute façon rien à tous ces trucs clic toujours oui, ce qui est pire avec l'asymétrique et une infrastructure à clef public.
Le second point n'a pas vraiment de solution à ma connaissance. Il y a bien quelques pistes du coté de la théorie des jeux mais cela paraît assez limité quand à la confiance concernant des enjeux géopolitiques.
Du coté psychologique, l'être humain à semble-t-il un mal fou à se dépêtré de son point de vu initial. Par exemple la flogistique à été défendu avec vigueur par des physiciens tout à fait respectable, et qui happé par l'élégance qu'ils voyaient en ce modèle, eurent du mal à admettre autre chose (voir ne l'admire jamais).
Ce qui nous amène à la vérifiabilité de l'information. Qu'est-ce qui fait qu'une théorie est fiable ? On peut vérifier en expérimentant et en comparant les résultats obtenus avec ceux prévus par la théorie. La tendance humaine serait plutôt de tenter de gueuler plus fort la théorie préféré de la personne, et de faire taire les autres.
Mais il y a des cas où l'on ne peut pas expérimenter. On ne va pas reconstruire un LHC dans notre salon pour vérifier que ces physiciens ne pipote pas, c'est sûr. Mais de manière général, expérimenter demande du temps et des moyens matériels et on ne peut pas tout vérifier.
Évidemment dans le cas de l'histoire, c'est encore plus problématique. Dans le cas de la physique si une théorie est complétement pipoté, elle permettra pas de fabriquer quoi que ce soit, d'où moins d'investissement. Tandis que pipoter l'histoire pour manipuler le peuple, cela peut attirer des investisseurs.
Il est effectivement difficile (est-ce même possible ?) de dire qu'est-ce qui, dans nos cours d'histoire, relève de la propagande pure et simple, et qu'est-ce qui relève du travail de l'historien animé uniquement par le désir d'exposer le plus objectivement possible les données dont nous disposons sur l'histoire de l'humanité.
[^] # Re: 1984 et Wikipedia
Posté par B16F4RV4RD1N . Évalué à 1.
wikipedia est un service centralisé, à la neutralité discutable, dont la résolution des conflits dépend du bon vouloir de quelques admins.
En soit, la position de wikipedia dans son créneau n'est pas beaucoup moins critiquable que celle de facebook ou de google.
Pas de pubs sur wikipedia ? Et pourtant on voit de grosses bannières appelant à la contribution financière.
Je pense que la meilleure chose qui pourrait arriver pour les internautes, ce serait un ou des fork de wikipedia : une saine concurrence ne serait pas néfaste...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Apache?
Posté par etenil . Évalué à 2.
Étonnant que Google n'essayent pas de refiler ça à la fondation Apache...
[^] # Re: Apache?
Posté par TImaniac (site web personnel) . Évalué à 4.
La fondation Apache est un cimetière logiciel, pas un cimetière à contenu :)
[^] # Re: Apache?
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
J'étais tenté de faire le (classique) jeu de mot sur les entreprises qui tournent l'apache, mais je me contenterai de me cacher derrière une prétérition.
[^] # Re: Apache?
Posté par imr . Évalué à 4.
C'est triste ton avis sur les Chapeaux Rouges.
# Citizendium
Posté par Jiel (site web personnel) . Évalué à 7.
Si on compare avec Wikipédia, c'est peu. Mais dans l'absolu, c'est déjà pas mal, 81 éditions par jour !
[^] # Re: Citizendium
Posté par patrick_g (site web personnel) . Évalué à 4.
Si tu regardes les auteurs de ces 81 contributions, il doit y avoir moins de 10 auteurs différents...et en plus on compte les discussions internes (Talk) dans ces 81 changements !
# rrr
Posté par Stibb . Évalué à 3.
je rapprocherais plus wikipedia de la base de connaissance globale décrite dans Fondation d'Asimov, ou serait stoqué un maximum de connaissance à un instant donné. Même si encore trop vulgarisateur, s'en est devenu néanmoins un point d'entrée pour bon nombre de personne : étudiant, ingénieur, journaliste, etc.
Ensuite, son mode de fonctionnement n'empechant pas les erreurs, il faut constament rappeler aux gens de croiser les données avec d'autres sources d'information !
[^] # Re: rrr
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Si tu connais un mode de fonctionnement qui empêche systématiquement toutes les erreur, n'hésites pas à nous la fournir. :)
# Oui, mais Encarta...
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
Encarta disparu en 2009 (à cause de Wikipedia diront certaines mauvaises langues, mais c'est juste parce que "le marché a évolué" http://www.20minutes.fr/high-tech/316249-High-Tech-L-encyclopedie-Encarta-c-est-bientot-fini.php )
Pourtant c'était bien cette encyclopédie qui avait de gros parti-pris, des articles très peu détaillés voire inexistants sur tout sujet un peu complexe ou tendu, au moins on ne se prenait pas la tête, une vision très occidentale^Wneutre sur le monde, l'histoire, la géographie. Un prof voulant montrer à ses élèves "Encarta, c'est Nul, voyez..." ne pouvait pas le modifier, donc son contenu était sûr et garanti.
Et puis on ne perdait pas du temps comme sur Wikipedia à cliquer sur des tas de liens qui mènent à d'autres liens pour se rendre compte à la fin de la journée qu'on connaît tous les personnages des Marvel sans avoir lu un seul Strange.
# Google Wave
Posté par oao . Évalué à 2.
L'arrêt des services de Google Wave a été annoncé pour la même date. Dommage, ce service était génial pour du travail en groupe, et je n'ai pas trouvé d'équivalents.
Quelqu'un a-t'il tenté de le mettre en oeuvre sur un serveur perso, avec les sources de la fondation Apache ? Les widgets sont-ils présents ?
# Merci
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 2.
Merci pour le lien vers la poule ou l'œuf par Google Knol, j'ai bien ri.
Ce qui est dommage c'est qu'on va perdre plein de contenu quand ils vont fermer ! Par exemple je pense particulièrement :
- The Albanian Origin of Napoleon Bonaparte
- Découvrez les attractions et monuments historiques de Strasbourg en voiture de location
- Nicolas Sarkozy Horoscope
- … pleins d'autres que je n'ai pas le temps de lister.
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Merci
Posté par Zenitram (site web personnel) . Évalué à 3.
Pardon???
tu vas perdre du contenu uniquement si tu as envie de le perdre, sinon, merci la licence CC-BY, tu peux le copier tranquille chez toi, le rediffuser etc... Le libre, c'est bon, mangez-en (tout le monde peut reprendre Knol la où il est, tout peut être sauvé, si c'est jugé utile à une personne au moins sur terre, par contre faut le faire soit-même, vu qu'archive.org se voit interdire d'archiver, pff)
[^] # Re: Merci
Posté par Juke (site web personnel) . Évalué à 3.
Le jeudi 24 novembre 2011 à 18:26 +0100, Zenitram a écrit :
> archive.org se voit interdire d'archiver
Pourquoi ?
[^] # Re: Merci
Posté par Zenitram (site web personnel) . Évalué à 3.
Page cannot be crawled or displayed due to robots.txt.
[^] # Re: Merci
Posté par Juke (site web personnel) . Évalué à 3.
Le jeudi 24 novembre 2011 à 18:46 +0100, Zenitram a écrit :
> [Page cannot be crawled or displayed due to robots.txt.][1]
Effectivement.
y'a une certaine incoherence entre la licence choisie et la mise en
place de ces restrictions.
[^] # Re: Merci
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 1.
C'est vrai mais il faudrait que je copie tous les articles marrants avant la fermeture et je n'ai pas les moyens de stockage pour l'instant (et le choix des articles est difficile).
À me plonger un peu plus dans knol je pense qu'on pourrait en faire des livres ésotériques (on prend quelques articles sur des œuvres d'art ou des monuments, on met un très gentil qui combat des très méchant et le tour est joué !).
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Merci
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Ou http://knol.google.com/k/mansour-mansour/le-champ-magn%C3%A9tique-terrestre/3l9he1x4zp9uf/31#
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Merci
Posté par patrick_g (site web personnel) . Évalué à 3.
Effectivement il est collector celui-là !
[^] # Re: Merci
Posté par Thomas Douillard . Évalué à 2. Dernière modification le 28 novembre 2011 à 13:53.
En même temps en prenant le pire de knol on lui rend pas forcément hommage, on peut y trouver des articles meilleurs que ceux de wikipedia parfois (j'avais fait la comparaison il y a quelques temps mais j'ai pas gardé les articles).
Et vu que le processus de "sélection" des info se fait différemment, tout le monde peut y pondre des articles très mauvais, tu peux y trouver des articles très mauvais.
Par contre il y a un moyen qui a fait ses preuves de faire ressortir les articles intéressants, les notes des utilisateurs. Un knol stack overflow like serait à mon avis une bonne idée à condition de fédérer une communauté.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.