benoar a écrit 4244 commentaires

Bonjour, je me permets bien après la bataille quelques commentaires historiques sur la tendance actuelle à vouloir absolument stocker les mots de passe hashés, vu ton obstination à le faire je me disais qu'une petite perspective historique pourrait t'aider à comprendre.

Très historiquement, les protocoles d'authentification étaient effectivement « en clair » et on envoyait les mot de passe directement au serveur, sans préoccupation de divulgation des secrets. Ce problème a été résolu au cours des années 90 avec différentes implémentations de protocoles défi-réponse (challenge-response) comme DIGEST-MD5 (cité plus haut) pour le web, CHAP pour PPP, etc. Ils ont été améliorés par l'ajout de nonce pour éviter les rejeux. Il faut se remémorer à l'époque qu'utiliser des canaux chiffrés n'était pas encore très répandu, et la cryptographie très réglementée et limitée (par les US) : ces protocoles protégeaient l'authentification lorsqu'on utilisait un canal non-chiffré, mais pas le canal de données associé. Le développement de la cryptographie a amené dans le même genre de thème l'authentification défi-réponse par clé dans SSH par exemple, ou l'authentification client par X.509 par certificat. Ces méthodes permettent, contrairement aux précédentes, de ne même pas stocker de secret côté serveur ! Car oui, bien que protégeant le canal d'authentification, les méthodes de défi-réponse citées nécessitent de stocker le mot de passe de manière récupérable sur le serveur (ce qui n'est pas forcément directement en clair, mais pas très loin il est vrai).

Puis est venu le temps de la généralisation du chiffrement des canaux avec TLS, qui a bien sûr commencé tôt sur le web, et s'est généralisé ailleurs après (sachant qu'il existait d'autres techniques aux buts similaires avant, mais qui ont eu moins de succès, ou alors dans des niches, comme IPsec, et SSH — pour son canal chiffré par DH, pas pour l'auth, ici —). Pour différentes raisons, les techniques « anciennes » d'authentification avec communication du mot de passe ou d'autre secret partagé sans souci de la confidentialité de l'échange — puisqu'ici obtenu à travers TLS — sont redevenues populaires, car souvent plus simples à implémenter une fois que le boulot de confidentialité de la couche TLS a été effectué. Certains voient ça comme un progrès, personnellement je vois plutôt ça comme une régression : maintenant, le serveur doit être mis au courant à travers le réseau du secret du client lors de la négociation de l'authentification. Le client doit avoir un moyen de garder ce secret sur le long terme et le présenter au serveur à sa demande ; il ne peut ainsi plus déléguer par exemple le défi d'authentification à un token comme une clé USB de cryptographie, ou utiliser de la cryptographie asymétrique qui lui permettrait de garder les secrets dans un endroits sécurisé et pérenne, puisqu'il n'a pas besoin de le « ressortir » et l'envoyer sur le réseau à chaque authentification. Mais aujourd'hui la cryptographie asymétrique « à l'ancienne » a perdu, les navigateurs veulent même supprimer l'authentification client par certificat X.509.

Bref, on a mis sur le dos du client le poids de devoir garder un secret qu'il doit communiquer « en clair » (mais sur un canal chiffré), pour simplifier la vie des serveurs qui se font facilement poutrer… pour quelle raison ? Est-ce la responsabilité du client si le serveur n'est pas capable de garder des secrets comme il faut ? On avait su inventer des mécanismes évitant tout stockage « chaud » de secret et de communication de secret en ligne grâce à la cryptographie asymétrique, mais aujourd'hui des considérations de practicité utilisateurs (c'est soit-disant trop dur à gérer) et de soit-disant préoccupation relatives au traçage d'identités (LOL c'est Google qui dirige les normes sur les nouveaux token qui empêchent la reconnaissance cross-site… sachant que Google le fait lui-même autrement) ont mis fin à ces mécanismes utilisés tels qu'à l'époque.

Alors aujourd'hui, on a su trouver des solutions intermédiaires différentes, qui ont certains avantages et d'autres désavantage : SCRAM-* par exemple, qui permet de faire du challenge-response d'un secret partagé sans avoir à stocker ce secret tel-quel sur le serveur. Ou les différentes formes d'authentification « fortes » par clé asymétriques comme WebAuthn, qui sont très spécifique au Web contrairement à X.509, et imposent des modèles d'identité et de confidentialité bien différents de ce qu'on avait avant (grand débat de savoir s'ils sont meilleurs ou moins bons…). Pourquoi pas, mais pour ça on a « mis à la poubelle » tout un tas de technologies qui étaient éprouvées et fiables, bien qu'ayant des désavantages (comme le stockage de secret « en clair » côté serveur) cités comme complètement rédhibitoire par certains comme toi, alors que les méthodes modernes ont d'autres désavantages qu'on cite moins. Tout ça est une histoire de compromis, et crier sur les gens quand ils stockent des secrets côté serveur comme si c'était universellement mauvais, alors que ça met un fardeau de gestion de secret supérieur sur le client, ça n'est pas très honnête ni constructif.

C'était pas une question de pénurie, mais une politique : les PI provoquent l'augmentation du nombre de routes de la DFZ et de la désaggrégation, et un des buts d'IPv6 est d'aggréger au maximum, donc ils ont (de mémoire) arrêté d'en faire, même si au début (il y a pas mal de temps quand même) c'était autorisé sans y avoir trop réfléchi histoire de faire « comme en IPv4 » (qui lui a vu l'arrêt des PI avec la pénurie). C'est resté pour les IX qui sont des cas spécifiques et limités, mais c'est tout. Encore une fois, je ne trouve pas de document pour appuyer mes dires.

À ma connaissance il n'y avait plus de PI IPv6 au RIPE depuis un bout de temps, à part pour les IX. Le document de leur politique concernant les PI https://www.ripe.net/publications/docs/ripe-738#IPv6_PI_Assignments n'a pas l'air de le préciser, c'est étrange.

Pour quelle raison celui qui signe les chèques en ferait un pour ça ?

Oui, tu pointes effectivement les bonnes raisons, et je sais bien que les coûts immédiats sont souvent énormes et dissuasifs. Les arguments que je présente sur « dé-complexifier » l'applicatif et la gestion réseau sont des arguments de long terme, et c'est très peu entendu dans ces structures intermédiaires.

Un autre problème qui vient avec l'IPv6 pour ces structures : ça les lie fortement à leur opérateur. Et souvent, elles aiment pas ça (et je les comprend).

Alors ça dépend de comment tu le fais : encore une fois, ça concerne l'applicatif, et c'est un chantier énorme. J'ai souvent recommandé de revenir à une gestion saine du DNS et augmenter son utilisation dans l'applicatif, car c'est le seul moyen de se défaire du couplage des applications avec les adresses : ce dont tu parles, c'est parce que tout le monde hardcode l'adressage et se lie à sa structure, ce qui amène des complications horribles en cas de renumérotation, effectivement. Et tous les devs et tous les frameworks aujourd'hui ont cette tare… alors qu'historiquement, l'utilisation des noms était beaucoup plus développée, et le NAT est venu casser cette dynamique car il rend compliqué l'utilisation des noms. C'est triste, mais c'est un combat nécessaire pour améliorer le réseau de manière générale.

Ensuite, tu peux également choisir de te préparer à l'utilisation d'adresses multiples, avec des préfixes d'origine différentes, ou alors d'adresses changeantes, afin de te défaire de cette dépendance. Ça doit être galère sans DNS, mais c'est une possibilité.

Le jour où tu veux changer d'opérateur, tu dois refaire tout ton plan d'adressage interne.

Alors, si tu ne te débrouilles pas trop mal, tu referas les configurations d'adressage de tes équipements, mais tu ne changeras pas la structure, vue que normalement ton nouvel opérateur t'offriras un préfixe assez grand pour faire un adressage similaire au précédent. Tu traduis juste le préfixe, quoi, même si je comprends la galère du changement de conf. Si tu décides de te baser sur les noms comme proposé plus haut, ça peut même être grandement simplifié. Et tu pourras même avoir de l'adressage multiple avec deux opérateurs upstream si tu le veux.

Et il ne faut pas croire que la transition d'opérateur est toujours rose même en IPv4 : tu as l'air de parler de professionnels maîtrisant bien leurs réseau, et j'ai déjà vu des transitions IPv4 où une partie de l'expertise est « avalée » par l'opérateur réseau pour différentes raisons (manque de compétences internes à l'entreprise, offre commerciales préférées par les dirigeants, etc) et les changements nécessaires aux équipements afin de gérer le ré-adressage sont substantielles !

À moins de n'utiliser que les adresses fd00:/8 en interne, mais du coup, ça supprime une partie des avantages de l'IPv6.

Ça dépend, tu peux aussi essayer de le faire « bien » : tu as en adressage pérenne en ULA (même pas forcément NATé upstream, uniquement pour la communication intra-entreprise), auquel tu peux ajouter des adresse de préfixes globaux de tes FAI pour les besoins d'accès (facile, laisse l'autoconf activée) ou de proposition de service (plus difficile mais réalisable). Comme d'habitude, il faut prendre le réflexe en IPv6 de penser que les technos peuvent s'ajouter, même si gérer la diversité augmenté bien sûr la complexité.

Avoir des ULA par défaut (non routées/NATées upstream) avec un ou des préfixes supplémentaires routés, c'est la configuration adoptée par défaut depuis quelques années par OpenWrt : tu vas me dire que ça n'est pas pour un contexte professionnel, mais je trouve que c'est une très bonne solution même dans ce contexte, qui peut satisfaire les exigences de stabilités comme celles d'atteignabilité globale. Encore une fois, bien sûr que ça amène un peu plus de complexité dans le réseau et la configuration des applications, mais en enlève aussi au niveau des NATs.

Bref, de mon point de vue, c'est surtout pour ces structures intermédiaires (mais nombreuses) que l'IPv6 représente un coût démesuré par rapport aux gains (à peu de choses près nuls)

Je pense que tu vises juste pour leurs appréhensions, mais je pense personnellement qu'il y a moyen de montrer que la réalité peut être plus simple en choisissant des stratégies de migration adaptées. Je suis par contre d'accord que ces stratégies que je propose ne sont pour l'instant pas souvent déployées, et très peu d'offres professionnelles sont proposées.

C'est effectivement une des raisons, et c'est un truc qui nous concerne nous développeurs car c'est parce que les applications sont tellement mal codées que le NAT64 « brut » a eu besoin d'être suppléé par du 464XLAT : dans les deux cas, ce qui circule sur le réseau de l'opérateur (avant d'arriver aux traducteurs) est de l'IPv6 « pur » (c'est le cas pour presque tout le réseau de Free aujourd'hui, je pense), et le « bénéfice » du 464XLAT c'est uniquement d'apporter un adressage local IPv4 (une re-traduction, en gros) afin de plaire aux hôtes qui ont des outils déficients en IPv6, et présenter une API ancienne aux applications qui ne sont pas capables d'utiliser des sockets correctement. En effet, l'API des sockets a été prévue pour que la transition puisse se faire en douceur, mais dans beaucoup de cas les logiciels sont implémentés à la truelle et font de la merde. Le NAT64, qui aurait pu fonctionner si des socket AF_INET6 étaient simplement directement utilisées (pour les softs IPv6-only qui comptent sur la présence de traducteurs sur le réseau) ou si les softs utilisaient correctement getaddrinfo(3), se plante au point qu'on est obligé de simuler un réseau et une API IPv4 pour faire fonctionner correctement les applis : c'est moche.

C'est le deuxième chantier qui est à mon avis encore gigantesque, après les manques des réseaux de certains opérateurs : faire que les applis et les framework arrêtent de réinventer la roue en ajoutant des couches « d'abstraction » qui collent complètement au modèle d'Internet NATé (ce qui est la cas de toutes les technos citées plus haut) et sont inadaptables à IPv6 au point où on en est obligé d'émuler IPv4 pour que ça « marche » (pour les « clients » seulement, car le 464XLAT pour les serveurs, ça n'est pas trop ça, il faudra faire autre chose).

J'arrive après la bataille, mais ce que tu me racontes s'apparente à une Software bill of materials : une liste de composants utilisés, avec diverses informations pour retrouver leur origine, leur licence, la durée de leur support, etc. Ça vient du monde de la gestion de chaîne logistique, et moi je l'ai surtout connu en électronique : chaque composant utilisé sur un schéma est listé, avec ses caractéristiques, ses fournisseurs, et le temps pendant lequel il est garantit d'être produit et disponible, donc également le stock et l'approvisionnement. Ça permet de gérer ton histoire de « péremption » un peu mieux : ça n'est pas parce que quelque-chose est « vieux » qu'il est mauvais, c'est juste qu'il faut qu'il y ait quelqu'un « derrière » pour assurer qu'il soit disponible et avec un support.

Je ne connais pas l'écosystème logiciel autour de ça, mais j'en ai de plus en plus entendu parler récemment, surtout lié aux attaques visant des éléments logiciels qu'on ne pensait même pas avoir inclus, comme tu l'évoques.

Les limitations que tu pointes sont pertinentes, même si dans l'absolu il existe des équivalents IPv6 à presque tout (et il existe de meilleures manières de faire que ce que tu cites, qui sont des conceptions « anciennes » et problématiques de voir le réseau). Mais c'est sûr que viser le dual-stack, c'est multiplier par plus que deux la complexité : la vraie bonne solution, qui est poussée par pas mal de monde aujourd'hui, est de faire de l'IPv6 uniquement et de compter sur les technologies de transition pour relier les deux mondes.

Ensuite, la complexité que tu vois sur l'adressage et le routage du réseau, c'est en définitive pour simplifier l'aval du réseau, qui est aujourd'hui un sac de nœud sans nom : regarde la gueule des technos réseau autour d'OpenStack, Docker et k8s, c'est un bordel immonde ; ou alors toutes les technos client pour « traverser » les NAT. Le problème est effectivement que comme le bordel a été « factorisé » dans ces technos et t'es livré inclus de base, on ne le « voit » plus, du coup on ne comprends pas l'intérêt d'avoir un réseau avec un plan d'adressage correct. Mais peut-être qu'un jour certains apprécieront, quand ils auront compris qu'on peut simplifier l'infra et l'applicatif avec une technologie réseau — car c'est le vrai but d'Internet à la base, de faciliter l'interopérabilité d'applications.

Bref, le dual-stack c'est compliqué, c'est sûr, et quand on réalisera qu'on pourra simplifier l'applicatif avec un réseau plus simple, l'IPv6 commencera peut-être à prendre.

numerama explique que ce qui freine IPv6 c'est pas les terminaux, mais les réseaux

Tu aurais le lien de l'article Numérama ? Pour le frein, oui effectivement ce sont surtout les réseaux aujourd'hui, même si ça s'est amélioré comme le signale l'ARCEP dans son compte-rendu cité plus bas.

c'était difficilement applicable (le lien de l'avocat)

Pour des raisons un peu moisies dans l'absolu, même si ça se comprend légalement : la France transcrit une directive de manière plus contraignante (l'obligation d'IPv6 n'est pas mentionné au niveau européen), absence d'un calendrier précis de transition, et l'obligation serait « disproportionnée ». Ils parlent de la disproportion de s'adapter au marché français seul, sans parler du fait que l'obligation pour le Brésil est déjà en place depuis plusieurs années, par exemple (avec ses propres limitations, certes).

l'arcep contraint tout opérateur souhaitant proposer de la 5G a passer en IPv6.

Tu as des sources là-dessus ? Je ne suis pas du tout un spécialiste 5G, mais des trucs que j'ai glané, la 5G est basiquement très orientée IPv6, voire promouvant l'IPv6-seul. Ça n'est pas pour rien que Huawei est le leader dans les RFC proposant de passer à « l'IPv4-as-a-Service », c'est-à-dire faire des réseaux uniquement IPv6, avec IPv4 « en option » pour ceux qui ont vraiment besoin de l'ancien monde… (basiquement c'est juste des méthodes de découverte de ponts NAT64 ou autre techno de transition).

Je navigue également sans JS, et pourtant je ne vois quasiment jamais de tels blocages… Tu as d'autres exemples que leboncoin ? (qui a effectivement un blocage si on n'accepte pas les cookies, et c'est pas pareil en fonction des navigateurs)

Perso c'était même pas une veille, je suis tombé par hasard dessus, en partant de la fiche Wikipédia de Pannier-Runacher (oui, je creuse loin…).

Je ne pense pas que le but soit de freiner la compatibilité IPv6, mais juste d'éviter de se prendre des procès pour non-conformité. Bon, c'est vrai que du coup, sans punition les opérateurs/fabricants peuvent plus facilement traîner des pieds…

Beaucoup d'articles dans cette loi suppriment des obligations pour les entreprises qui existaient pour faire les choses « bien », ça n'est pas pour qu'elles le fassent forcément moins (mmhh) mais pour qu'on n'ait pas de recours pour les emmerder si elles ne le font pas.

La dérégulation, quoi : le « marché » s'en charge, pas « besoin » de loi pour ça.

Merci à tous pour vos suggestions, bien que je n'ai rien découvert de nouveau et que trouver le juste milieu entre emmerdement et laisser-faire est toujours difficile. Je n'ai pas répondu à quiconque, désolé, mais je trouve les réactions intéressantes.

Je suppose qu'un nouveau tour de Google en CSS cache les résultats

Aujourd'hui j'ai pris quelques minutes pour regarder encore une fois précisément ce qui avait changé dans la page pour donner cette « page blanche », et en fait c'est tout simple : au sein de la balise noscript (qui contient le meta refresh évoqué dans ce journal), il y a une balise style contenant table,div,span,p{display:none}, c'est tout. Ça doit pouvoir se bloquer à coup de règle de filtrage CSS, mais j'étais justement en train d'abandonner Adblock Plus pour une autre extension qui ne permet pas le filtrage CSS…

Bon, tentons quand même : google.com##noscript>style, ça matche bien, mais la page reste blanche. Je suppose qu'ABP peut bloquer ainsi des éléments HTML désignés par un sélecteur CSS, mais ne bloque pas l'interprétation d'un bloc CSS désigné par un sélecteur CSS… ou un truc du genre.

Bref, les ingés de Google ont bien joué avec celle-ci, mais je trouvais quand-même cela assez hallucinant que les utilisateurs d'un trick si « bête » et sûrement marginaux soient visés, en 2021, par de tels changements.

J'aime bien les trackpoints également, mais j'ai un problème en particulier qui m'a un peu refroidi, moi qui ai l'habitude d'utiliser des vieilles machines : j'ai l'impression qu'avec l'âge, l'étalonnage se perd un peu (même si est refait automatiquement au démarrage, je sais) et l'arrêt de l'appui dessus n'entraîne pas l'arrêt immédiat du signal, ce qui fait que le pointeur a une sorte d'inertie très désagréable qui le rend très imprécis.

Pour l'expliquer autrement, on envoie le pointeur dans une direction, avec la dextérité acquise on vise bien sur l'objet visé du premier coup, mais au moment de lâcher le trackpoint, le pointeur se met à dériver légèrement dans la direction qu'on lui avait indiquée. Ça ne le fait pas sur des trackpoints neufs, mais sur des machines de plus de cinq ans d'âge, je l'ai vu plusieurs fois. C'est je pense plutôt une sorte de problème physique dû à l'usure.

Ça plus les problèmes de tendinite évoqués plus haut, que je n'avais pas étant jeune mais qui arrivent avec l'âge, m'ont fait abandonner l'utilisation des trackpoints, qui sont pourtant pour moi la meilleure manière d'utiliser le pointeur pour un utilisateur avancé du clavier, pour toutes les raisons évoquées plus haut.

Retraduire n'importe quel autre bouquin, peut-être. Mais retraduire celui qui dénonçait la manipulation de la langue… c'est fort de café !

P.S. : au passage, un article du fondateur d'Agone était paru en papier pour une plus grande audience dans le Diplo, quelques mois après ce post de blog : https://www.monde-diplomatique.fr/2019/07/DISCEPOLO/60049

Pour la même raison que les SMS ne sont plus autorisés, il faut que la vérification dépende aussi de la transaction.

Alors c'est marrant et intéressant, le boîtier que m'a fournit le Crédit Coop fait une sorte de challenge/response, où ça n'est pas simplement un OTP généré par la carte de crédit. On rentre un code donné par l'établissement de vérification de la transaction lors du paiement, et on renvoie un code retour (après avoir tapé son code de carte bancaire). C'était utilisé au début pour les transactions les plus sensibles (je ne me souviens plus desquelles, mais je me souviens l'avoir utilisé), cependant ça a été abandonné il y a quelques années pour une raison que je ne connais pas ; je suppose que la fusion avec le SI tout moisi de la Caisse d'Épargne a joué pour le nivellement par le bas… Et que c'était également peut-être « trop compliqué » pour certains utilisateurs… Il existe également sur le boîtier une troisième fonction « signature » que je n'ai jamais vue utilisée.

Ça pourrait à mon avis tout à fait remplir le critère de « lien dynamique » entre la transaction et le code renvoyé pour le boîtier.

et même quelques anciens téléphones dont le support a été intégré au noyau

T'as des exemples stp ? Ça m'intéresse et je n'en avais jamais entendu parler. Merci.

Merci pour ton retour, c'est très intéressant. Perso ça fait 10 ans je prends mes notes (réunion, comptes-rendus divers, idées, journaux linuxfr, …) en reStructuredText, voire Sphinx pour les projets les plus développés, et c'est vrai que c'est vraiment confort une fois que tu connais bien. Je connais très peu de gens qui font de même, d'où l'importance de ton retour pour moi !

J'utilise également rst2s5 pour les présentations, même si c'est assez basique. J'avais également un projet de Wiki versionné basé sur Sphinx, qui est en standby depuis un bout de temps. Tiens, je l'avais déjà publié dans un coin, même : http://dolka.fr/code/gitollion.git

J'aime le côté progressif également, j'avance comme toi « tranquillement », et le fait que le standard soit ancien et stable, même si les quelques minimes différences entre reST et Sphinx font un peu tâche (mais bon, par rapport à Markdown c'est le paradis).

Je serais intéressé pour voir tes directives perso aussi, si le code est publié.

Les bases de connaissance mieux intégrées en reST, c'est drôle, j'avais déjà réfléchi dessus, sans aboutir. Par contre, les interfaces graphiques, très peu pour moi, c'est à mon avis la manipulation du texte brut qui fait la force de ces systèmes. Ou alors à la limite un éditeur pour le Web avec édition d'élément HTML graphiquement, comme le fait Wikipédia, avec une conversion HTML <-> reST qui serait idéalement idempotente…

Bref, j'ai l'impression d'être dans le même mode que toi de réflexion et extension à long terme, basé sur des choses simples et standard… c'est agréable de voir qu'on n'est pas seul !

D'accord avec ta constatation sur l'accélération de l'information, et sa dégradation. Après, je pense toujours que tu sous-estimes l'effet des moteurs de recherche dessus, car ils ont changé quelque-chose de beaucoup plus fondamental.

et si demain ils décident d'effacer des archives comment t'en rendre compte?

Nan mais arrête d'imaginer des situations quasi-inimaginables pour justifier l'utilité des moteurs de recherche ! En plus dans ce cas précis, tu ne t'en rendras pas non plus compte avec, tu auras juste une source qui a disparu et que tu as oubliée, vu que tu ne fais en général même plus attention aux sources quand tu te fies beaucoup au moteur (ça n'est pas pour rien que Google extrait les infos structurées pour les afficher sur sa page).

Un moteur de recherche est un outil, il faut apprendre à l'utiliser, connaître ses limites et savoir comment les gérer.

Bon, toujours les même arguments, et moi toujours les même réponses, on tourne un peu en boucle.

Merci en tous cas pour la discussion.

Si j'essayais de résumer ton commentaire, tu dis en gros (corrige moi si je me trompe) que les moteurs de recherche servent à palier la désinformation sur l'actualité, puisque la majorité des sujets que tu évoques concernent l'information sur l'actualité. Je te ferais noter que la désinformation était auparavant contrée par des publications indépendantes, et tu fais remarquer qu'elles ont quasiment disparu : effectivement. Mais justement, le fait d'avoir tout disponible « sur Internet », par un moteur de recherche, n'est-il pas (en partie) responsable de la disparition de ces publications ? Pourquoi quasiment plus personne ne paye de journalistes directement aujourd'hui ? « T'as qu'à chercher sur Internet », sous-entendu « gratuitement ».

Je ne suis pas sûr que voir les moteurs de recherche en sauveurs est la bonne réalité : la causalité du problème démocratique que tu évoques n'est pas si simple, et les soit-disant sauveurs d'aujourd'hui sont peut-être les fauteurs de trouble d'hier (et d'aujourd'hui). Je ne pense pas qu'on trouvait « moins » l'information avant, elle mettait certes plus de temps à éclore, mais ça marchait plutôt bien je trouve. Tu noteras que les nouveaux propriétaires des grandes publications sont des acteurs qui ont des intérêt… dans les nouvelles technologies, et qui s'accommodent bien du monopole de Google. Croire que Google aide à mieux s'informer est un mirage selon moi.

Je céderais juste sur la remarque pertinente de la facilité de chercher de l'information ancienne avec ces moteurs : c'est effectivement un usage très intéressant et difficilement atteignable « à l'ancienne », même si c'est justement également une spécialité du Diplo d'offrir un grand moteur de recherche sur leurs archives (oui, tu as dû noter que j'aime bien ce journal).

Alors je dirais que ton problème c'est que tu n'as pas abordé l'auto-hébergement de la bonne manière : selon moi il faut toujours prévoir de la disponibilité (je ne vais pas appeler ça « haute » disponibilité, ça serait mentir) avec des tiers. L'e-mail et le DNS ont justement été conçus dès le début pour ça, autant en profiter !

Et donc pour l'e-mail, toujours prévoir un MX secondaire qui te garde tes mails au chaud ailleurs pendant que le premier est hors-ligne ou en galère. Ça résout ton 1 (partiellement, il peut toujours arriver que le primaire soit on-line mais renvoie une erreur pour une autre raison), ton 4 (tu peux même avoir une autre secondaire chez toi, aussi, et le passer en primaire en cas de besoin ; oui, pour ça il te faudra plusieurs IP, mais IPv6 sais faire, et les gros fournisseurs aussi), et ton 5. Perso, j'ai tenu un déménagement (que tu évoques dans les commentaires) off-line de 15 jours sans problème (j'avais même la délégation DNS sur cette ligne, et avec des zones correctement en cache les NS secondaires ont répondu pendant mon absence sans problème, tout comme le MX secondaire).

Pour le reverse en 2, il faut effectivement être chez un FAI correct, et ça n'est pas facile à trouver, mais ça se fait. Et ça résout potentiellement ton 6 si ça n'est pas un des gros qui classe bêtement tout le monde en « résidentiel ».

Quant au 3, SPF, le problème est dans la question : SPF veut combattre le spam, certes, mais tue le principe décentralisé (et non-authentifié, d'où le problème du spam) de l'e-mail. Donc oui, si tu t'y conformes, tu vas forcément tomber dans ce genre de problème un jour. Il faut donc accepter le spam…

Bon, je ne vais pas dire que ça n'est pas du bouleau de gérer tout ça, mais comme ont dit certains autres, c'est du boulot au début, mais une fois bien fait la maintenance est relativement légère.

Merci en tous cas de tes retours, c'est toujours intéressants de lever les problèmes, car tout n'est pas tout blanc dans l'auto-hébergement, c'est sûr.

Avec ta solution il m'est impossible de sortir de ma bulle, aussi grande soit elle, je serai toujours limité par ma connaissance de sites/annuaire de moi ou de mes connaissance;

Je pense que c'est faux, et qu'on pourrait très bien s'en sortir comme ça. Et surtout que les bulles seraient beaucoup moins captivantes sans un oracle universel.

Non il est important que tout un chacun ait accès aux mêmes informations afin de pouvoir les débattre si tu cloisonnes les informations bulles par bulles tu réduit d'autant la capacité de se rendre compte que les informations sont fausses ou dépassées;

Je suis désolé, mais l'effet « bulle » que tu décris est beaucoup plus présent aujourd'hui avec des monopoles de recherche ou de réseau qu'avant. « Sortir de sa bulle » était moins nécessaires avant, et je trouve que la démocratie s'en portait mieux.

L'avantage avec ta solution c'est que l'effet streisand n'existe pas;

Effectivement, l'effet serait beaucoup plus diminué.

l’inconvénient, c'est qu'étouffer des histoire embarrassante est beaucoup plus facile, la propagation de l'information étant complètement atrophiée.

Peut-être pour certaines, mais je suis convaincu qu'il y a d'autres histoires aujourd'hui qui sont beaucoup mieux cachées par le monopole de la recherche. Le fait même que Google soit le bras-droit des US pour la domination non seulement culturelle mais aussi cognitive du monde (oui, j'ai mis mon chapeau d'alu).

alors qu'en fait c'est juste un coup d'état comme un autre qui a tenter de diaboliser le précédent président

Et tu cites un journal (qui a certes collaboré à ce mensonge précédemment) pour rétablir la vérité : ça n'est pas ton moteur de recherche qui l'a permis pour un large public, seulement pour les quelques initiés qui se sont intéressés au problème. En France une enquête est parue dans le Diplo le mois dernier (ou celui d'avant), et ce journal avait déjà émis des critiques de l'histoire officielle au moment de l'élection. Encore une fois, un journal rédigé par des humains, qui a une influence pas par son classement algorithmique (qui n'est pas très bon) mais par la confiance que les gens ont en lui.

Avec ta solution il est tellement plus simple contrôler l’information ou de mentir aux gens qui n'auront aucun moyen de le savoir.

Je n'en suis pas du tout convaincu. La fable du « avant Internet on pouvait mentir sans vergogne, plus maintenant » n'est pas si vraie que ça.

Ne t'en déplaise google, n'est pas l'unique source d'entré du monde, il en existe d'autres.

Là, ici se trouve l'incompréhension : je m'en fous qu'il y ait une concurrence des « points d'entrée du monde », le problème est de croire qu'il peut exister un point d'entrée sans que ça ne pose de problème. Je suis d'accord qu'un certain nombre de gens — la majorité — équivaut Internet avec « point d'entrée unique », mais c'est quelque-chose qui est dangereux pour la démocratie pour moi. C'est bien là que je vois le problème, au cas où on ne se soit pas encore bien compris.

J'ai connu le web d'avant google, j'ai utilisé altavista, lycos, yahoo… j'ai utilisé les web-ring, et je ne veux pas y revenir.

Je suis de la même époque et ai eu la même expérience, et aujourd'hui je pense l'inverse de toi : Internet était raisonnable au début, mais plus aujourd'hui.

le gars de gauche n’aura accès qu'a des site de gauche, et des informations qui vont avec, pareil pour le gars de droite, ou le conspirationniste

Heu, tu es en train de décrire exactement ce qui se passe aujourd'hui avec les bulles algorithmiques… Un point d'entrée unique ne résout pas ça ! Rien ne le résoudra parce que pour moi ça n'est pas un problème à résoudre par la technique ; au contraire, plus tu tenteras de le résoudre par la technique, plus la polarisation avancera.

si le site de bricolage que j'utilise préconises des manip dangereuse, je n'ai aucun moyen de le savoir, si le site de programmation que je suis me fait coder des vulnérabilité de la taille de la tour Eiffel, je l'ignorerai; si la norme que j'ai trouvé sur un site donné par le copain d'un collègue, se trouve dépassé, je suis dans les choux; de même si l'annuaire est mal maintenu; quand ton moteur de recherche te file des résultats, les mauvais sont généralement poussés vers le bas.

Oui, et alors ? Il existe des vérités universelles qu'aucun consensus ne peut faire sortir à long terme, il faut forcément une entité technique magique qui va te la dire ? Oui c'est un monde différent que je propose, celui « d'avant », car la croyance en l'oracle universel est pour moi un danger de cette « nouvelle » vision que tout le monde adopte sans se rendre compte du changement anthropologique que cela implique : que la raison humaine individuelle n'a plus de valeur, qu'il faut faire confiance « à la machine », sans se poser de questions sur sa construction. C'est pourtant la base du logiciel libre que d'essayer de comprendre et maîtriser les machines !

Surtout que le travers de google, aujourd'hui visible de par sa taille et son audience large, sera imperceptible les annuaires de liens ou sites à l'audience plus limité.

Donc pour toi c'est plus important d'avoir une vérité universelle quitte à ce qu'elle soit despotique, plutôt que des faits plus ou moins faux dont la responsabilité est disséminée dans le monde ? C'est une certaine vision, je dénonce juste ce changement fondamental vers lequel on glisse tout doucement sans se rendre compte de rien.

Essaye d'être un peu plus précis pour ne pas te faire moinsser, parce que ce que tu dis n'est pas faux (comme ckiller) : il n'y a rien d'équivalent sans changer un peu d'interface utilisateur et sans changer de formats d'échange niveau qualité — à moins de faire appel à quelques petits artisans du libre qui seront bien sûr plus chers que la solutions MS — pour le grand public en libre.

Oui, compter sur des bénévoles pour faire une plateforme pérenne, avec une politique de gestion et de conservation des données respectueuse et fiable à long terme, hébergées pas trop loin, avec des gens pour faire le support derrière quand il faut, c'est effectivement impossible.

Après avoir édicté ça, on peut commencer le débat sur quels sont les moyens qu'on met, les compromis qu'on fait, c'est quoi la vision à long terme pour pérenniser les solutions alternatives à MS, etc.

Tout usage se prête naturellement au monopole.

Je ne suis pas d'accord, et je pense qu'on ne peut pas se comprendre.

quels sont les arguments qui permettent de dire que ce sera toujours un échec ? Tu base se savoir sur quelque chose de solide ou juste sur la volonté de détruire google ?

J'ai essayé de te les montrer, mais apparemment je n'arrive pas à me faire comprendre. Il n'existe pas un « marché de l'oracle omniscient », pour résumer encore une fois.

Si on avait yahoo, bing, google, baidu et yandex qui avaient chacun 20% requêtes de recherche, tu ne pourrais pas dire les moteurs de recherche c'est nécessairement mal.

Personne ne fera jamais le poids face à Google. Monter un serveur mail, par contre, c'est à la portée de beaucoup plus de monde.

Mais bon, je n'ai pas de nouveaux arguments alors je vais m'arrêter là. Merci pour la réflexion en tous cas.

Ce sont d'énorme obstacle. Si tu ne change pas régulièrement d'adresses c'est très difficile de retrouver partout où tu l'a utilisé, le faire changer partout où c'est possible, maintenir une redirection pendant un certains temps.

Ça c'est parce que donner son e-mail a été amené comme habitude forcée, car dans plein de cas où on la donne ça ne serait pas nécessaire dans l'absolu : pour ce qui est vente en ligne, rien n'oblige à avoir un compte à part si on veut te tracer (pour éviter de rentrer ses informations personnelles plusieurs fois, il y a eu plusieurs tentatives de standardisation de stockage côté client et standardisation des champs — genre avec XForms — qui ont échoué… parce que ça rapportait moins que d'exploiter les données personnelles) ; pour les comptes de communication (chat, réseau social ou autre) on a éclaté l'écosystème ce qui oblige à en faire beaucoup trop de comptes, alors qu'une approche fédérée avec standardisation éviterait cet écueil ; j'essaye d'imaginer quels sont les autres faux besoins, mais je n'en vois pas pour l'instant.

Bref, l'utilisation de l'e-mail comme identifiant soit-disant indispensable est très galvaudé, normalement on aurait juste à le mettre à jour auprès de nos contacts qu'on connaît, et un nombre limité d'institutions — comme on faisait avant quand on changeait d'adresse physique… — et ça irait très bien.

(j'avoue que j'imagine ces problématiques sur le moment, n'ayant pas anticipé tes réponses — merci de m'y faire réfléchir)

Tu tente d'exprimer après coup ce qui a posé problème pour l'interdire, alors que le monopole est la cause racine, c'est une question qui est étudié depuis des décénies et on peut arriver à les empêcher.

Alors comme avec fearan au-dessus, je pense que tu as mal compris (ou j'ai mal expliqué) mon point de vue : certaines choses se prêtent naturellement au monopole, et ne peuvent qu'y mener. Je pense que c'est le cas avec la « recherche » au sens d'outil utilisé par l'humanité pour répondre à toute question généraliste. Il ne peut pas exister de « concurrence » de l'oracle universel.

Genre les monopoles ?

Les monopoles sont un problème dans des contextes où la concurrence peut avoir lieu, et oui c'est une bonne idée de les combattre. Mais dans le domaine dont on parle, ça n'a pas vraiment de sens.

Je ne dis pas que l'autoritarisme est impossible, mais qu'il est très faibles, limité dans le temps et l'espace là où les méthode décrites par Huxley fonctionne sur la quasi totalité do globe depuis des dizaines d'années.

Oui effectivement, en y réfléchissant, en tous cas en ce qui concerne la France, tu as raison.

Je vais prendre bien soin d'ignorer ostenssiblement ce passage.

Si c'est parce que c'est hors-sujet, je peux comprendre, je m'éloigne pas mal. Si c'est pour une autre raison, je serais curieux de savoir ?

C'est ce que tu affirme, mais ça n'est pas établi.

Peut-être faudrait-il que j'étoffe mon argumentaire, mais j'y réfléchis et j'ai débattu depuis plusieurs années (pas en grand comité, certes), et je n'ai jamais vu de contre-argument réellement pertinent.

Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ?

Le but ça n'est pas d'interdire les tentatives de choses plus « éthiques », c'est de dire que de toutes façons, elles sont vouées à l'échec. Le but c'est d'interdire Google ou tout autre qui pourra le remplacer (mais je pense qu'au niveau où ils sont, c'est in-rattrapable ; cf. déjà l'analyse d'Assange d'il y a 10 ans déjà).

Après je suis toujours septiques de la recherche de toujours tout le temps vouloir du fédéré/acentré/décentralisé. Ça cache systématiquement d'énormes biais.

Moi aussi je trouve qu'un certain nombre d'initiatives se font sans réflexion sur le fond du problème. Je ne sais pas trop quels biais tu évoques, mais oui parfois c'est fait « par réflexe », sans penser aux inconvénients différents que ça va amener. Mais globalement, tout de même, les projets fédérés sont quand même souvent ceux qui respectent le plus les libertés fondamentales. Internet est fédéré. L'e-mail également. Ça n'est pas pour rien.