Résumé

  • Un Internet-Draft individuel daté du 27 octobre examine l’usurpation des noms du support et des recruteurs dans les messages de plateformes. Il expose des choix d’ingénierie, sans définir de protocole.
  • Le texte relève deux défauts possibles : l’égalité stricte des « squelettes » Unicode rate certaines ressemblances, et des validateurs étudiés accepteraient des hôtes en conservant des caractères de format invisibles. La décision doit croiser l’expéditeur, le lien et l’intention du message.

Un faux message du support peut pousser un candidat à remettre ses identifiants ou un vendeur à quitter une place de marché pour payer ailleurs. Dans cette boîte de réception, le message passe d’un compte à l’autre à l’intérieur du produit. Le nom « Assistance » peut être saisi par un compte qui ne représente pas la plateforme. Le projet sur les expéditeurs ressemblants situe donc le contrôle au niveau du message : qui écrit, sous quel nom, avec quelle adresse et vers quel hôte le lien conduit-il ? La plateforme possède cette scène et le nom officiel affiché dans son décor.

L’auteur propose de rapprocher le domaine de l’expéditeur et les hôtes des liens d’une liste d’identités protégées. Un nom de marque dans l’adresse locale d’un domaine étranger, ou un nom d’affichage officiel associé à un compte ordinaire, ajoute un indice. La demande formulée compte aussi : fournir des identifiants, quitter l’application, obéir à une prétendue autorité de la plateforme. Aucune de ces traces ne mérite seule une sanction lourde. Le bureau d’orientation d’une université peut partager le vocabulaire d’un recruteur légitime.

Le premier défaut tient à une astuce Unicode trop étroite. UTS no 39 décrit le « squelette » des caractères confusables et la détection des écritures mêlées. Le projet montre que l’égalité exacte de deux squelettes peut manquer des imitations visuelles : certains caractères grecs ou cyrilliques ont un prototype latin qui n’est pas une lettre ASCII. Il cite le petit kappa grec et le petit « te » cyrillique. L’outil qui ne compare qu’un squelette final au nom ASCII protégé laisse passer cette famille de ressemblances. Le texte propose d’y ajouter l’examen des écritures et une distance bornée entre squelettes.

L’autre défaut se cache dans un espace qui ne se voit pas. Le projet rapporte que plusieurs validateurs de sa revue acceptaient des noms d’hôte contenant notamment U+00AD, U+200B, U+2060 ou U+FEFF et les restituaient avec ce caractère encore présent. RFC 5890 pose le cadre des noms internationalisés, RFC 5892 définit le statut des points de code, et UTS no 46 décrit le traitement de compatibilité. Le projet demande de traiter le nom selon IDNA2008 ou UTS-46 avant la comparaison à la liste autorisée, puis de rejeter les étiquettes contenant des caractères de format ou ignorables par défaut. Le tampon « valide » ne vaut rien si le programme suivant reçoit une chaîne différente de celle qu’il croit comparer.

La décision finale appartient au produit. Sa liste de noms protégés fixe ce que « Support » signifie ici. Son historique de comptes distingue un agent officiel d’un expéditeur qui lui ressemble. Son échelle de réponses sépare avertissement et blocage. Un classificateur à modèle de langage peut enrichir l’analyse, mais le projet demande de traiter le message comme une entrée hostile et de conserver les faits déterministes sur l’expéditeur devant le verdict du modèle. Datatracker classe encore le document parmi les projets individuels I-D Exists, destinés à l’Informational.

La revue de validateurs citée par le projet ne donne ni les noms et versions des bibliothèques, ni une matrice d’entrées et de sorties. Une telle matrice permettrait d’évaluer la portée actuelle de ce défaut particulier.