12 entreprises cotées en bourse ont décidé de comment on pourrait utiliser des caractères accentués dans les noms de domaines. Enfin presque…
Au commencement était la RFC 3492 et son algorithme "Bootstring" qui permet de dire que bcher-kva.ch c'est en fait bücher.ch (le -kva transmet à la fois le caractère à placer et son emplacement dans la chaîne qui précède)(exemple tiré de Punycode). Mais l'ICANN avait besoin d'un préfixe pour dire "attention ce nom de domaine contient des caractères Unicode". Ils ont donc choisi xn-- pour que xn--caf-dma.com devienne café.com.
Mais pourquoi xn !?
- Il fallait un préfixe parmi ceux réservés à l'usage privé (ISO 3166-1) pour ne pas risquer de collision avec le code d'un pays. Soit
AA
QM à QZ
XA à XZ
ZZ
- Ils ont exclu les préfixes qui se trouvaient déjà dans des zones DNS genre
qm--machin.com(pourquoi un tel enregistrement a pu se trouver dans une zone, je n'en ai aucune idée…). Ainsi que ceux contenant des lettres qui ressemblent à des chiffres (XI,XS, …) ou ceux contenant des lettres qui ressemblent à d'autres lettres comme le U et le V. Donc il restait 18 possibilités :
XB XC XD XE XF XG XH XJ XK XM XN XP XQ XR XT XW XX XY
Et c'est là que l'histoire devient cocasse, l'ICANN a 18 choix possibles et équivalents, il faut trouver le moyen d'en prendre un seul sans être accusé plus tard d'avoir choisi de manière à ce que quelqu'un de chez eux puisse anticiper et réserver des domaines intéressants avant tout le monde. Donc ils ont trouvé une méthode élégante mais baroque : faire reposer le choix sur le volume d'échange de 12 actions cotées au NYSE et au NASDAQ le 10 février 2003.
The twelve stocks and their trading volumes (in 100s) were:
(NYSE) IMS Hlth RX 22157
(NYSE) IL Tool ITW 11795
(NYSE) IntRectifr IRF 5742
(NYSE) IBM IBM 78719
(NYSE) IntPaper IP 16609
(NYSE) Interpublic IPG 34961
(NASDAQ) Inamed IMDC 1567
(NASDAQ) Informatica INFA 4357
(NASDAQ) Inktomi INKT 6085
(NASDAQ) i2 Tch ITWO 37777
(NASDAQ) IDEC Pharm IDPH 18754
(NASDAQ) Intel INTC 524545
On concatène ces nombres, on calcule le hash MD5 puis on fait modulo 18 (le nombre de choix). Le reste de la division a donné 10, on ajoute 1 parce que les choix étaient numérotés de 1 à 18 => on sélectionne le n°11 ! Et voilà pourquoi il y a xn-- dans les noms de domaines internationalisés. Bon la méthode n'est pas si compliqué mais je trouve cocasse qu'ils soient allés jusque-là. Ils auraient dit « on a choisi xk-- parce que c'est joli », je ne crois pas que la face du monde s'en fut retrouvée changée… Et selon mes dernières vérifications, les noms de domaines internationaux n'ont pas vraiment acquis une grande valeur. Généralement on essaye de les éviter et si on en parle ce n'est pas en bien.
[HS] LinuxFR c'est dangereux pour la productivité. C'est ce commentaire de Benoît qui m'a lancé dans des recherches sur les encodages, la Base64 puis le Quoted-Printable jusqu'à arriver au Punycode. Et après 60 bonnes minutes quand j'ai lu « L'IANA a choisi d'utiliser le volume d'échange de douze actions la journée du 10 février 2003 : six actions du NASDAQ et six actions du NYSE.» je me suis dit qu'il y avait matière à creuser encore jusqu'à retrouver les échanges d'origine. Bref, travailleurs tenez-vous éloignés de ce lieu de perdition.
# Affichage dans le navigateur
Posté par impromptux (site web personnel) . Évalué à 4 (+3/-0).
Je remarque que Firefox affiche "xn--caf-dma.com" quand je tape "café.com", pour des raisons de sécurité j'imagine. L'extension Alerte sur les sites GenAI en profite pour m'avertir de la présence d'un caractère spécial dans le nom de domaine.
Ce comentaire est sous license CC0: faites en ce que vous voulez tant que vous ne m'atribuez pas de fausses paroles.
[^] # Re: Affichage dans le navigateur
Posté par tcit (site web personnel, Mastodon) . Évalué à 6 (+5/-0).
Tu as dû changer la valeur de
network.IDN_show_punycodedans tonabout:config.[^] # Re: Affichage dans le navigateur
Posté par impromptux (site web personnel) . Évalué à 3 (+2/-0).
C'est probablement lié au fait que j'utilise LibreWolf et non Firefox. Quoi qu'il en soit c'est une bonne chose je pense.
Ce comentaire est sous license CC0: faites en ce que vous voulez tant que vous ne m'atribuez pas de fausses paroles.
[^] # Re: Affichage dans le navigateur
Posté par damiend . Évalué à 2 (+1/-0). Dernière modification le 25 septembre 2026 à 16:32.
Si on veut préserver la "beauté" de l'affichage, à mon avis c'est le rôle de l'orga qui gère le TLD (avec peut-être les conseils de l'ICANN) de bien choisir les caractères autorisés pour qu'il n'y ait pas de confusion possible. Par exemple, le .com américain devrait accepter 'é' car la langue anglaise a des mots importés du français avec cet accent, mais pas le 'е' cyrillique.
Mais il me semble que c'est le cas maintenant ? Peut-être pas pour tous les TLD.
À noter que certains langages ont une fonction anti-spoofing native (SpoofChecker), qui pourrait être utilisée pour les pseudos d'ailleurs.
# Crossover
Posté par thoasm . Évalué à 4 (+1/-0).
La question aurait aussi pu être soulevée dans la discut' de ce lien. Manifestement les LLMs ne sont pas vraiment capables d'utiliser correctement ces informations folle !
(non ce n'est pas une pub éhontée, ce lien est de l'histoire ancienne, ce n'est pas moi qui l'ait posté et il est pertinent
)
[^] # Re: Crossover
Posté par Colin Pitrat (site web personnel) . Évalué à 2 (+0/-0).
Merci, j'ajoute ce site dans mes flux RSS!
# C’est pas bête
Posté par sobriquet . Évalué à 6 (+4/-0).
Je trouve la démarche intéressante et la réponse pertinente : Comment choisir un nombre au hasard, et manière à pouvoir prouver qu'il a été choisi au hasard ? Réponse : utiliser un flux de données suffisamment aléatoire, et accessible publiquement, à une date déterminée à l'avance. Le choix d'une activité boursière est insolite, mais répond bien à ces contraintes.
Si je devais faire une autre proposition aujourd'hui, je ne suis pas sûr de savoir faire mieux. J'utiliserais peut-être le md5 du 60 mot du 4e article du Monde de la semaine prochaine, mais si c'est une décision à enjeu, ce choix n'exonèrerait pas totalement de toute accusation de délit d'initié.
[^] # Re: C’est pas bête
Posté par mahikeulbody . Évalué à 3 (+1/-0).
[^] # Re: C’est pas bête
Posté par Faya . Évalué à 10 (+9/-0). Dernière modification le 24 septembre 2026 à 21:04.
Non ils ont bien choisi une date future (10 février). Regarde https://www.psg.com/lists/idn/idn.2003/msg00021.html les échanges datent du 30 janvier. Et la RFC qui propose cette méthode date de 3 ans avant.
[^] # Re: C’est pas bête
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Puisqu'on parle d'utiliser le cours de la bourse pour générer des nombres aléatoires, c'est l'occasion de faire de la pub pour le geohashing, un loisir qui consiste à se rendre à un point dont les coordonnées GPS sont calculées selon une méthode similaire.
Je n'ai encore croisé personne dans mes expéditions (assez irrégulières je dois l'admettre).
[^] # Re: C’est pas bête
Posté par _seb_ . Évalué à 1 (+0/-0).
Je ne suis pas certain que les variations de la Bourse soient réellement aussi aléatoires, du moins à court terme.
Il me semble qu'il existe des mécanismes plus largement reconnus pour garantir l'imprévisibilité, comme ceux utilisés par exemple dans les loteries nationales.
Pour le besoin évoqué, c'est peut-être davantage une question de principe : faire un choix didactique.
[^] # Re: C’est pas bête
Posté par arnaudus . Évalué à 3 (+0/-0).
Les variations de la bourse ne sont pas aléatoires, mais si ton hash est équiprobable, ça n'est pas important. Un caractère de différence dans l'entrée va te donner des hashs aussi différents que deux entrées aléatoires.
Ce genre d'algorithme ne doit par contre jamais être utilisé pour des applications sérieuses, puisque les données d'entrée sont en théorie manipulables.
[^] # Re: C’est pas bête
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+11/-0).
Il y a bien sûr une RFC qui explique bien tout.
La propriété qui est considérée comme importante est que les nombres aléatoires retenus soient vérifiables par le public.
L'idée est donc d'annoncer à l'avance comment le tirage au sort sera fait, quelle source pseudo-aléatoire publique sera utilisée, et comment elle sera traitée pour obtenir les résultats. Ainsi, tout le monde peut indépendament se procurer le résultat de la source aléatoire, exécuter l'algorithme, et s'assurer qu'il obtient bien le résultat annoncé.
La section 3.3 explique comment mesurer l'entropie des sources et faire en sorte que le résultat soit suffisament aléatoire.
La RFC mentionne d'autres sources possibles, incluant les numéros gagnants du loto:
Le fait que la source utilisée est imparfaite est bien pris en compte, mais, compte tenu des enjeux, elle est jugée acceptable. En gros: si vous pouvez manipuler le cours de la bourse (ou les numéros du loto) avec une telle précision, vous n'avez probablement aucun intérêt à utiliser vos capacités pour fausser les décisions de l'IETF, il y a des choses plus faciles et plus profitables à faire.
On peut noter que avant la mise en place de cet algorithme, la méthode de tirage au sort utilisée était de mettre des bouts de papier dans un réceptacle, puis de sélectionner une personne pour choisir les élus.
La RFC a été mise à jour par la suite (postérieur à son utilisation pour le choix du préfixe 'xn'), et elle donne d'autres raisons de ne pas utiliser les indices boursiers:
La section 5 ("Real world problems") revient un peu plus en détail sur le sujet. Elle se conclut en recommendant de choisir plutôt les numéros du loto, dont le tirage est moins susceptible d'être annulé, les résultats sont dans une forme bien définie et qui ne change que très rarement. On ne peut décidément pas faire confiance au monde de la finance pour quoi que ce soit, même pas pour produire des nombres aléatoires de façon fiable!
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.