Arff les adresses d'exemple sont encore de la forme "nom@hébergeur" alors que salut@louise ou coucou@goffi serait tellement plus swag et plus "internet décentralisé" ;-)
En allant voir sur le site de Conversations et celui d'OMEMO il semble bien que le transfère de fichiers soit pris en charge, y compris en conférences (après j'ai pas testé dans tous les sens) :
Merci pour l'article ! Ses tests sont très intéressants. Cependant ils ne portent que sur l'ergonomie, pas sur la sécurité effective. Par ailleurs il est dommage que Conversations n'ait pas été testé.
On est bien d'accord que c'est Signal, Moxie Marlinspike et Open Whisper Systems qui choisissent d'utiliser Google Cloud Messaging et MapView ? Donc ils sont bien responsables des failles de sécurités de leur application qu'ils présentent comme sécurisée ?
@Régis tu n'as pas lu l'article de la FSFE. Lit-le et dis nous ce que tu en penses après.
Par exemple :
Signal est opensource :
Signal propose qu'on puisse compiler le code est vérifier que c'est le même distribué sur le Play Store
Précisément ce n'est pas le problème. Ça ne sert (presque) à rien d'auditer le code source de Signal ou de le recompiler pour vérifier sa conformité puisque le problème n'est pas dans SON code mais dans celui des services Google qu'elle utilise et sur lesquels elle repose.
Ou encore :
Le bémol c'est que nous devons leurs faire confiance pour les métas informations qui transitent par chez eux.
Oui le problème n'est pas les méta-informations qui transitent par chez eux mais les informations & les méta-informations qui transitent par Google lorsque l'on UTILISE l'application Signal.
Mais aussi :
Avec Signal ou Whatsapp il est excessivement facile de vérifier la clef soit via les numéros de sécurité soit en scannant le code QR Code.
Pour WhatsApp le code de l'application n'est pas public, donc on ne peut pas vérifier ce que fait concrètement l'application. L'application peut très bien te présenter un code tout en utilisant un autre puisque de bout en bout du transit du message tout passe par elle, sans que l'on puisse y déroger. Par ailleur elle a la possibilité d'ajouter silencieusement un appareil virtuel donc même si ta clef est bonne etc. etc. il y a une tierce personne qui a la clef et écoute la conversation. Cela renvoi au commentaire publié sur Reflets et à celui de Tanguy Ortolo publié ci-dessous.
juste un comportement par défaut choisi pour ne pas faire fuir les utilisateurs.
Non ce n'est pas "juste" un comportement par défaut, c'est bien un comportement qui pose des problèmes de sécurité.
Imaginons que What's app notifie à chaque fois qu'une clef publique change.
Ce n'est pas quelque chose qui arrive tous les 4 matins. Et en plus ce n'est pas hyper-intrusif. Notifier ne veut pas dire "valider" comme c'est le cas pour SSH. Cette notification n'est pas intrusive, or elle n'est pas activée par défault :
Pour que chaque utilisateur fasse le choix d'accepter ou de refuser le changement de clefs, il faudrait leur expliquer de quoi il s'agit.
A moins que chaque utilisateurs de la chaîne, veuillent réellement une communication confidentielle … bon courage.
Ah quoi bon clamer que c'est sûr si ce n'est pas "vraiment" sûr ? Notamment quand la menace principale, c'est à dire la NSA et le gouvernement américain, a les mains libres pour que ça ne soit pas sûr ?
Et surtout : pourquoi rejeter toute critique ?
Récemment, des représentants de gouvernements, dont le notre, reprochaient à Signal son système de chiffrement trop sûr; et ce, bruyamment.
Je ne peut m’empêcher de croire qu'il y a anguille sous
Et bien là justement des gens te permettent d'avoir des éléments crédibles pour dépasser la simple croyance. Et les révélations Snowden dont le programme PRISM devraient être suffisant pour qu'on ne fasse pas confiance à ce type de logiciel aux sources fermées proposées par des entreprises étasuniennes dont les serveurs sont sur le sol américain.
Et vu les bonnes relations entre le gouvernement français et le gouvernement américain on peut sérieusement considérer qu'ils échangent des informations. D'ailleurs Reflets avait bien annalysée comment l'échange d'information entre agence de surveillances de différents permettait à chacune d'outre passer les interdictions de surveiller les habitants de leur propre pays.
Mais justement avec la fonction de renvendeur de Gandi le client n'a pas à te "donner" (ou plutôt indiquer) son compte Gandi. C'est même l'inverse, c'est toi, en tant que fournisseur de service, qui lui "donne" (vend, en fait) un compte chez Gandi et enregistrement dans le DNS.
Du coup le client n'a jamais eu à faire la démarche pour savoir qui est "OVH", comment ouvrir un compte chez OVH, etc. etc. Ce qui simplifie énormément la démarche d'un utilisateur pour obtenir un nom de domaine, une adresse email, une adresse jabber, un hébergement web etc.
Le client n'a qu'a ouvrir 1 seul compte chez 1 seul prestataire pour avoir tout ça. Il délègue à son fournisseur de service la gestion de toute la complexité. Mais s'il souhaite quitter ce prestataire, il reste possesseur de son nom de domaine (et de ses données si les choses son bien faites) et donc il maintient toutes ses relations sociales. Aucune nouvelle adresse à donner (de conversation ou de médiatisation) à ses contact etc.
C'est le seul moyen d'aller chatouiller les GAFAM : que chaque internaute ai son nom dans le DNS.
De ce que j'ai compris (je n'ai pas essayé), la fonction revendeur permet de créer le compte client à la place du client. Ainsi il n'a pas à faire un allé retour entre OVH et ton service : il ne voit que ton service.
Par ailleurs, pour éviter de payer en plus à Gandi et rendre plus chère ton offre, je pense que devenir un bureau d'enregistrement auprès de l'Afnic n'est peut-être pas si compliqué (jamais essayé) :
Pour Movim c'est une bonne idée mais peut-être compliqué. Je pensais surtout que tu pouvais indiquer à tes clients qu'ils peuvent utiliser http://conversations.im (Android) ou http://chatsecure.org (iOS) comme ça tu n'a "que" le serveur XMPP à gérer.
Ton offre a l'air bien intéressante ! Cependant, pour des raisons que j'ai déjà expliqué ici il me semble que la base pour un service Internet est de permettre au client-usager d'utiliser son propre nom de domaine, d'avoir son nom dans le DNS.
Or sur ton site je lis :
[…] En plus d'une adresse au format @whiskers.top nous fournissons […]
Je pense qu'en tant qu'hébergeur libre, ne souhaitant pas enfermer tes utilisateurs chez toi, il est important de ne surtout PAS proposer ce format d'adresse (cf les liens ci-dessus).
À mon avis c'est aussi un énorme service rendu à tes clients que de leur éviter la configuration de leur propre DNS. Je sais que chez Gandi on peut être "revendeur" et ainsi ouvrir des comptes pour ses propres clients chez Gandi, en se mettant automatiquement en gestionnaire technique. En gros tes clients sont bien propriétaires de leurs DNS, mais tu les gères pour eux.
D'autres bureau d'enregistrement de noms de domaine proposent peut-être des services similaires ou mieux.
Par ailleurs, ce qui existe peu aujourd'hui c'est des hébergeurs pro qui proposent un hébergement XMPP à jour avec un nom de domaine personnalisé pour chaque client. Est-ce envisageable ?
Pour compléter l'information le client android Conversation.im est libre ainsi que ejabberd - le logiciel qui fait tourner le service d'hébergement. Cependant je ne crois pas que l'interface graphique d'administration soit libre.
Sinon, un admin pourrait-il modifier un peu mon texte ? j'ai commis des erreurs d'orthographe :
le titre pour ajouter un s à nom : Hébergeurs XMPP avec noms DNS personnalisés : Conversations.im & Mailbox.org
remplacer le "et" par "est de" dans : simplifier la gestion d'un nom de domaine est de proposer en premier un service
replacer "ne propose" par "proposent" dans J'en profite pour remarquer que peu de Chatons proposent une
ajouter un point et une majuscule pour avoir : une prise en charge du DNS. Peut-être que ça viendra ?
J'en parle dans mon précédent article et je te conseille de regarder la vidéo de présentation de Gns (les liens sont dans le journal au dessus).
En gros Gns a 2 niveaux :
un est unique sur Internet mais difficilement manipulable par un humain (clef publique et condensat de la clef publique)
un est non-unique mais manipulable ur internet. Du coup on vérifie qu'on s'adresse bien à la bonne personne en utilisant le premier système de noms.
Une des astuces pour simplifier ce système est que des registres fassent référence dans des sphère culturelles. Genre en France tout le monde connaitrait la clef publique de ".fr" et celle de ".icann".
Voilà comment on évite les collisions. Après rien n'est parfait.
La différence avec le GNS est que chaque intermédiaire est autonome, peut exister indépendamment de son existence dans un autre registre. Ainsi ".fr" peut exister indépendamment de ".icann" (ce qui n'est pas le cas avec le DNS) même si bien sûr ".fr" a intérêt à maintenir des bonnes relations avec ".icann" pour y exister (mais ce n'est pas obligatoire, ni nécessaire).
On peut aussi noter que le GNS aboutira à (et bénéficiera de) ce que certains registre obtiennent une plus grande notoriété que d'autres (le ".icann" sera plus (re)connus que le ".apichat").
Par exemple ces noms peuvent nommer la même entité, mais le principal référent diffère : "toto.fr.icann" et "toto.icann.fr" et "toto.icann" et ".toto". Ici Toto a enregistré son nom dans deux registre qui se connaissent mutuellement ".icann" et ".fr" mais a aussi la possibilité d'avoir une relation directe avec son public.
Du coup les collisions peuvent être moins grave : je m'en fout d'avoir "toto713" chez ".icann" puisque 90% de mon public se réfère au ".fr" chez qui je suis enregistré sous "toto"
# Appli Yunohost ?
Posté par Apichat (site web personnel) . En réponse à la dépêche Hackathon pour les vingt ans de sympa les 1ᵉʳ et 2 avril 2017. Évalué à 1. Dernière modification le 10 mars 2017 à 15:54.
Yunohost est "acteur de l'évènemnet" est-ce que ça veut dire qu'une intégration à Yunohost va voir le jour ? Ça serait vraiment, vraiment très bien !
Sachant qu'une intégration de Mailman patine depuis 1 an : https://yunohost.org/#/apps_in_progress_fr
# salut@toi
Posté par Apichat (site web personnel) . En réponse à la dépêche Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 2.
Arff les adresses d'exemple sont encore de la forme "nom@hébergeur" alors que salut@louise ou coucou@goffi serait tellement plus swag et plus "internet décentralisé" ;-)
Pour rappelle : salut@toto — salutation, règle éditoriale et nom sur Internet
Bon c'est vendredi, mais pour de vrai : merci pour ce logiciel qui s'annonce vraiment pratique !
# Merci !
Posté par Apichat (site web personnel) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées de janvier 2017. Évalué à 4.
Merci à toute l'équipe de LinuxFR ! Ce site est super et l'ambiance est sympa :-) Merci aussi aux éditions Eyrolles.
[^] # Re: partage d'images
Posté par Apichat (site web personnel) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 1. Dernière modification le 27 janvier 2017 à 14:47.
En allant voir sur le site de Conversations et celui d'OMEMO il semble bien que le transfère de fichiers soit pris en charge, y compris en conférences (après j'ai pas testé dans tous les sens) :
voir aussi : https://github.com/siacs/HttpUploadComponent
[^] # Re: ortho
Posté par Apichat (site web personnel) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 2.
Merci, est-ce possible de modifier aussi ce titre :
Avantages d'OMEMO et XMPP par rapport autres logicielsAvantages d'OMEMO et XMPP par rapport aux autres logiciels
[^] # Re: Un peu de concret
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 2.
Merci pour l'article ! Ses tests sont très intéressants. Cependant ils ne portent que sur l'ergonomie, pas sur la sécurité effective. Par ailleurs il est dommage que Conversations n'ait pas été testé.
[^] # Re: Ce n'est pas une backdoor
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 3.
@Régis tu n'as pas lu l'article de la FSFE, ni les extraits que j'ai publié dans ce journal. Lit-le et dis nous ce que tu en penses après.
https://blogs.fsfe.org/larma/2017/signal-backdoors/
[^] # Re: .
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
On est bien d'accord que c'est Signal, Moxie Marlinspike et Open Whisper Systems qui choisissent d'utiliser Google Cloud Messaging et MapView ? Donc ils sont bien responsables des failles de sécurités de leur application qu'ils présentent comme sécurisée ?
[^] # Re: D'accord
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
@Régis tu n'as pas lu l'article de la FSFE. Lit-le et dis nous ce que tu en penses après.
Par exemple :
Précisément ce n'est pas le problème. Ça ne sert (presque) à rien d'auditer le code source de Signal ou de le recompiler pour vérifier sa conformité puisque le problème n'est pas dans SON code mais dans celui des services Google qu'elle utilise et sur lesquels elle repose.
Ou encore :
Oui le problème n'est pas les méta-informations qui transitent par chez eux mais les informations & les méta-informations qui transitent par Google lorsque l'on UTILISE l'application Signal.
Mais aussi :
Pour WhatsApp le code de l'application n'est pas public, donc on ne peut pas vérifier ce que fait concrètement l'application. L'application peut très bien te présenter un code tout en utilisant un autre puisque de bout en bout du transit du message tout passe par elle, sans que l'on puisse y déroger. Par ailleur elle a la possibilité d'ajouter silencieusement un appareil virtuel donc même si ta clef est bonne etc. etc. il y a une tierce personne qui a la clef et écoute la conversation. Cela renvoi au commentaire publié sur Reflets et à celui de Tanguy Ortolo publié ci-dessous.
[^] # Re: In french please!
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
Ah le lien vers Reflets était bon, je voulais bien pointer ce commentaire que je trouve intéressant. Si vous pouvez remettre l'ancre je préfère
https://reflets.info/whatsapp-backdoor-ou-petard-mouille/#comment-618434
[^] # Re: Ce n'est pas une backdoor
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 4.
En parlant de pot de miel, voilà des anar français qui suggèrent l'utilisation de Signal pour des conversations sécurisées : https://speakerdeck.com/dunglas/petite-introduction-a-lauto-defense-numerique
C'est inquiétant.
[^] # Re: Ce n'est pas une backdoor
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 2.
Non ce n'est pas "juste" un comportement par défaut, c'est bien un comportement qui pose des problèmes de sécurité.
Ce n'est pas quelque chose qui arrive tous les 4 matins. Et en plus ce n'est pas hyper-intrusif. Notifier ne veut pas dire "valider" comme c'est le cas pour SSH. Cette notification n'est pas intrusive, or elle n'est pas activée par défault :
Oui face à ça Daniel Gultsch propose un comportement alternatif "Blind Trust Before Verification". Ce comportement est en place dans Conversations
Ah quoi bon clamer que c'est sûr si ce n'est pas "vraiment" sûr ? Notamment quand la menace principale, c'est à dire la NSA et le gouvernement américain, a les mains libres pour que ça ne soit pas sûr ?
Et surtout : pourquoi rejeter toute critique ?
Il faut bien vendre le pot de miel.
Et bien là justement des gens te permettent d'avoir des éléments crédibles pour dépasser la simple croyance. Et les révélations Snowden dont le programme PRISM devraient être suffisant pour qu'on ne fasse pas confiance à ce type de logiciel aux sources fermées proposées par des entreprises étasuniennes dont les serveurs sont sur le sol américain.
Et vu les bonnes relations entre le gouvernement français et le gouvernement américain on peut sérieusement considérer qu'ils échangent des informations. D'ailleurs Reflets avait bien annalysée comment l'échange d'information entre agence de surveillances de différents permettait à chacune d'outre passer les interdictions de surveiller les habitants de leur propre pays.
[^] # Re: In french please!
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
Oula ! Oui merci ! Si un admin peut corriger ça, c'est cool…
[^] # Re: FUD
Posté par Apichat (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 2.
Et aussi http://conversations.im
[^] # Re: Nom de domaine personnalisé
Posté par Apichat (site web personnel) . En réponse au journal Faire un peu d'argent avec le logiciel Libre, l'après Wallabag.... Évalué à 4. Dernière modification le 20 janvier 2017 à 15:24.
Peut-être n'ai-je pas compris ta réponse.
Mais justement avec la fonction de renvendeur de Gandi le client n'a pas à te "donner" (ou plutôt indiquer) son compte Gandi. C'est même l'inverse, c'est toi, en tant que fournisseur de service, qui lui "donne" (vend, en fait) un compte chez Gandi et enregistrement dans le DNS.
Du coup le client n'a jamais eu à faire la démarche pour savoir qui est "OVH", comment ouvrir un compte chez OVH, etc. etc. Ce qui simplifie énormément la démarche d'un utilisateur pour obtenir un nom de domaine, une adresse email, une adresse jabber, un hébergement web etc.
Le client n'a qu'a ouvrir 1 seul compte chez 1 seul prestataire pour avoir tout ça. Il délègue à son fournisseur de service la gestion de toute la complexité. Mais s'il souhaite quitter ce prestataire, il reste possesseur de son nom de domaine (et de ses données si les choses son bien faites) et donc il maintient toutes ses relations sociales. Aucune nouvelle adresse à donner (de conversation ou de médiatisation) à ses contact etc.
C'est le seul moyen d'aller chatouiller les GAFAM : que chaque internaute ai son nom dans le DNS.
[^] # Re: Nom de domaine personnalisé
Posté par Apichat (site web personnel) . En réponse au journal Faire un peu d'argent avec le logiciel Libre, l'après Wallabag.... Évalué à 2.
De ce que j'ai compris (je n'ai pas essayé), la fonction revendeur permet de créer le compte client à la place du client. Ainsi il n'a pas à faire un allé retour entre OVH et ton service : il ne voit que ton service.
Est-ce pareil chez OVH ?
[^] # Re: Nom de domaine personnalisé
Posté par Apichat (site web personnel) . En réponse au journal Faire un peu d'argent avec le logiciel Libre, l'après Wallabag.... Évalué à 2.
Chouette !
Par ailleurs, pour éviter de payer en plus à Gandi et rendre plus chère ton offre, je pense que devenir un bureau d'enregistrement auprès de l'Afnic n'est peut-être pas si compliqué (jamais essayé) :
https://www.afnic.fr/fr/produits-et-services/le-fr/devenir-bureau-d-enregistrement/
Pour Movim c'est une bonne idée mais peut-être compliqué. Je pensais surtout que tu pouvais indiquer à tes clients qu'ils peuvent utiliser http://conversations.im (Android) ou http://chatsecure.org (iOS) comme ça tu n'a "que" le serveur XMPP à gérer.
# Nom de domaine personnalisé
Posté par Apichat (site web personnel) . En réponse au journal Faire un peu d'argent avec le logiciel Libre, l'après Wallabag.... Évalué à 7. Dernière modification le 20 janvier 2017 à 11:40.
Salut,
Ton offre a l'air bien intéressante ! Cependant, pour des raisons que j'ai déjà expliqué ici il me semble que la base pour un service Internet est de permettre au client-usager d'utiliser son propre nom de domaine, d'avoir son nom dans le DNS.
Or sur ton site je lis :
Je pense qu'en tant qu'hébergeur libre, ne souhaitant pas enfermer tes utilisateurs chez toi, il est important de ne surtout PAS proposer ce format d'adresse (cf les liens ci-dessus).
À mon avis c'est aussi un énorme service rendu à tes clients que de leur éviter la configuration de leur propre DNS. Je sais que chez Gandi on peut être "revendeur" et ainsi ouvrir des comptes pour ses propres clients chez Gandi, en se mettant automatiquement en gestionnaire technique. En gros tes clients sont bien propriétaires de leurs DNS, mais tu les gères pour eux.
Gandi : Devenir un revendeur nom de domaine
Qu'en penses-tu ?
D'autres bureau d'enregistrement de noms de domaine proposent peut-être des services similaires ou mieux.
Par ailleurs, ce qui existe peu aujourd'hui c'est des hébergeurs pro qui proposent un hébergement XMPP à jour avec un nom de domaine personnalisé pour chaque client. Est-ce envisageable ?
[^] # Re: Logiciels libres
Posté par Apichat (site web personnel) . En réponse au journal Hébergeurs XMPP avec noms DNS personnalisés : Conversations.im & Mailbox.org. Évalué à 1.
Merci !
# Logiciels libres
Posté par Apichat (site web personnel) . En réponse au journal Hébergeurs XMPP avec noms DNS personnalisés : Conversations.im & Mailbox.org. Évalué à 1.
Pour compléter l'information le client android Conversation.im est libre ainsi que ejabberd - le logiciel qui fait tourner le service d'hébergement. Cependant je ne crois pas que l'interface graphique d'administration soit libre.
Sinon, un admin pourrait-il modifier un peu mon texte ? j'ai commis des erreurs d'orthographe :
Hébergeurs XMPP avec noms DNS personnalisés : Conversations.im & Mailbox.orgsimplifier la gestion d'un nom de domaine est de proposer en premier un serviceJ'en profite pour remarquer que peu de Chatons proposent uneune prise en charge du DNS. Peut-être que ça viendra ?[^] # Re: The State of Mobile XMPP in 2016
Posté par Apichat (site web personnel) . En réponse à la dépêche Renouveau de JabberFR. Évalué à 2.
Oui ce n'est pas encore disponible…
Non, tout ce qui est présenté dans l'article est fonctionnel avec des exemples de logiciels implémentant ces fonctionnalités.
Par exemple Conversations sur Android :
https://conversations.im/
https://play.google.com/store/apps/details?id=eu.siacs.conversations&referrer=utm_source%3Dwebsite
ChatSecure sur iOS et Android :
https://chatsecure.org/
Qui propose aussi un service d'hébergement avec toutes ces fonctionnalités disponibles :
https://account.conversations.im/
Un outil de comparaison des services d'hébergement (aussi intégrer au logiciel Conversations) :
https://gultsch.de/compliance.html
Coter serveurs les plus avancés sont eJabberd et Prosody :
https://www.ejabberd.im
https://prosody.im https://modules.prosody.im
# The State of Mobile XMPP in 2016
Posté par Apichat (site web personnel) . En réponse à la dépêche Renouveau de JabberFR. Évalué à 3.
À propos des dernières évolutions de XMPP :
The State of Mobile XMPP in 2016 par Daniel Gultsch, développeur de l'application Android https://conversations.im
[^] # Re: flatpak
Posté par Apichat (site web personnel) . En réponse au journal Lollypop continue son chemin. Évalué à 2.
Et un dépôt Debian ? Est-ce en prévision ?
[^] # Re: Quelle différence ?
Posté par Apichat (site web personnel) . En réponse au journal Mon Retour de PSESHSF : DNS & Minitel. Évalué à 1.
Ahah zut ok je vois ce que tu veux dire :-)
J'en parle dans mon précédent article et je te conseille de regarder la vidéo de présentation de Gns (les liens sont dans le journal au dessus).
En gros Gns a 2 niveaux :
un est unique sur Internet mais difficilement manipulable par un humain (clef publique et condensat de la clef publique)
un est non-unique mais manipulable ur internet. Du coup on vérifie qu'on s'adresse bien à la bonne personne en utilisant le premier système de noms.
Une des astuces pour simplifier ce système est que des registres fassent référence dans des sphère culturelles. Genre en France tout le monde connaitrait la clef publique de ".fr" et celle de ".icann".
Voilà comment on évite les collisions. Après rien n'est parfait.
[^] # Re: Quelle différence ?
Posté par Apichat (site web personnel) . En réponse au journal Mon Retour de PSESHSF : DNS & Minitel. Évalué à 6.
La différence avec le GNS est que chaque intermédiaire est autonome, peut exister indépendamment de son existence dans un autre registre. Ainsi ".fr" peut exister indépendamment de ".icann" (ce qui n'est pas le cas avec le DNS) même si bien sûr ".fr" a intérêt à maintenir des bonnes relations avec ".icann" pour y exister (mais ce n'est pas obligatoire, ni nécessaire).
On peut aussi noter que le GNS aboutira à (et bénéficiera de) ce que certains registre obtiennent une plus grande notoriété que d'autres (le ".icann" sera plus (re)connus que le ".apichat").
Par exemple ces noms peuvent nommer la même entité, mais le principal référent diffère : "toto.fr.icann" et "toto.icann.fr" et "toto.icann" et ".toto". Ici Toto a enregistré son nom dans deux registre qui se connaissent mutuellement ".icann" et ".fr" mais a aussi la possibilité d'avoir une relation directe avec son public.
Du coup les collisions peuvent être moins grave : je m'en fout d'avoir "toto713" chez ".icann" puisque 90% de mon public se réfère au ".fr" chez qui je suis enregistré sous "toto"
J'espère avoir répondu à ta question.