Résumé

  • La Public Suffix List recense des frontières administratives que la syntaxe DNS ne permet pas de déduire, afin que les logiciels distinguent un suffixe commeco.ukdu domaine enregistrable situé immédiatement en dessous.
  • Le langage de règles utilise des correspondances exactes, des caractères génériques et des exceptions. Le logiciel canonise un nom d’hôte, recherche les règles correspondantes, applique une exception si elle existe ou la règle comportant le plus de labels, puis considère normalement le suffixe public accompagné d’un label supplémentaire comme le domaine enregistrable.
  • La liste comporte des sections ICANN et PRIVATE distinctes. La première reflète les espaces de noms adossés à des registres; la seconde permet aux propriétaires de domaines de décrire les frontières de plateformes sur lesquelles des clients indépendants reçoivent des sous-domaines.
  • L’inscription dans la PSL ne constitue pas une certification de sécurité, de confiance ou de propriété. Les responsables examinent les preuves et fusionnent une ligne en amont, tandis que les navigateurs, bibliothèques, systèmes de certificats et services décident quand mettre leurs données à jour et comment les utiliser.
  • La procédure de soumission du 6 mai 2026 impose de conserver sans modification le modèle automatisé de demande d’intégration et rejette explicitement toute réécriture par GPT, ce qui reflète à la fois la nécessité d’attestations engageant leurs auteurs et les capacités limitées d’un projet bénévole.

Le cookie qui aurait pu traverser co.uk

Un navigateur qui autoriserait un titulaire situé sousco.ukà définir des cookies pour l’ensemble deco.ukréunirait des sites sans lien dans une même frontière de sécurité. La PSL existe parce que le nombre de points ne permet pas de savoir où cette frontière doit se trouver.

La Public Suffix List existe parce que la politique d’enregistrement des domaines ne peut pas être déduite de manière fiable des points figurant dans un nom d’hôte. Certains registres autorisent les enregistrements directs sous un domaine de premier niveau, d’autres sous des labels de deuxième niveau ou plus profonds, comme co.uk ou pvt.k12.ma.us, et des plateformes privées peuvent attribuer des sous-domaines à des parties qui ne se font pas mutuellement confiance. Les navigateurs ont besoin d’une carte de règles externe pour savoir si deux noms d’hôte appartiennent au même titulaire ou à des inconnus.

La liste décrit des frontières de politique connues; elle ne constitue pas la source faisant autorité pour déterminer si un nom DNS existe actuellement.

Le problème de sécurité initial concernait la portée des cookies. Sans connaissance des frontières des registres, un site situé sous co.uk pourrait tenter de définir un cookie pour co.uk et l’exposer à des titulaires sans lien. La PSL permet aux logiciels de refuser les cookies aux frontières des suffixes publics tout en autorisant un titulaire à partager des cookies au sein de son propre domaine. Les règles relatives aux cookies sont mises en œuvre par les agents utilisateurs et les normes; la PSL elle-même ne les exécute ni ne les fait respecter.

La liste est un langage de règles compact, et non un catalogue à plat. Les entrées peuvent être des règles exactes, des caractères génériques placés à gauche ou des exceptions. Les implémentations canonisent les noms, recherchent les règles correspondantes, donnent la priorité à une exception ou, à défaut, choisissent la règle comportant le plus de labels, puis déterminent le suffixe public et le domaine enregistrable. Quelques formes de règles suffisent à représenter des structures d’enregistrement irrégulières sans énumérer tous les noms d’hôte possibles.

Les bibliothèques peuvent traiter incorrectement Unicode, les points finaux, les suffixes inconnus, les frontières de section ou les données obsolètes.

Le domaine enregistrable se trouve normalement un label au-dessus du suffixe public. Pourwww.example.co.uk, co.uk est le suffixe public et example.co.uk le domaine enregistrable, souvent appelé eTLD+1. Les navigateurs et services utilisent cette frontière pour regrouper par site les cookies, l’historique, les autorisations, les limites de débit et d’autres états. Les notions de « site », d’« origine », d’« hôte » et de « domaine enregistrable » sont liées, mais ne sont pas interchangeables en matière de sécurité.

Les sections ICANN et PRIVATE représentent des sources d’autorité différentes. Les modifications de la section ICANN doivent provenir d’un registre, de l’ICANN ou de l’IANA, ou s’appuyer sur des preuves officielles; celles de la section PRIVATE doivent être demandées par un propriétaire de domaine autorisé qui attribue des sous-domaines à des parties ne se faisant pas mutuellement confiance. Cette séparation permet aux utilisateurs de décider si les frontières des plateformes privées doivent compter pour un cas d’usage donné.

L’inscription dans PRIVATE exprime la politique opérationnelle du détenteur du domaine et n’apporte absolument aucune garantie générale de sécurité ou de confiance.

La maintenance est une fonction bénévole d’examen aux conséquences importantes. Les demandeurs utilisent un modèle public de demande d’intégration, fournissent des attestations et des preuves, réussissent les tests et répondent aux responsables, qui évaluent le format, l’autorité, les conséquences et le risque de retour en arrière. Une seule ligne fusionnée peut toucher des millions de clients après sa propagation en aval. Le projet dispose de peu de ressources, n’offre aucun service client et ne garantit ni date d’inscription ni délai d’examen. Son influence dépasse largement les cookies des navigateurs. La liste sert aux restrictions dedocument.domain, au regroupement des sites, à la présentation des URL, au contrôle des certificats génériques, au regroupement des limites de débit, à la lutte contre le pistage, ainsi qu’aux bibliothèques, robots d’exploration et politiques réseau. Un fichier de frontières de domaines est devenu une infrastructure d’identité partagée entre des produits sans autre lien. Les responsables ne prescrivent pas tous ces usages et ne contrôlent pas si un dérivé traite différemment les entrées ICANN et PRIVATE.

La distribution crée une chaîne d’approvisionnement longue et en partie invisible. La copie canonique est produite quotidiennement à partir de GitHub, mais les navigateurs, systèmes d’exploitation, bibliothèques, services cloud et applications peuvent intégrer des instantanés ou prétraiter les données selon des calendriers différents. Une fusion ne signifie pas un déploiement effectif, et une annulation peut nécessiter un nouveau cycle complet de propagation. Le projet PSL ne gouverne ni les œuvres dérivées, ni leur cadence de mise à jour, ni leur interprétation propre à chaque produit.

La liste ne doit pas remplacer le DNS ni servir à contourner la politique d’un produit tiers. Les recommandations du projet avertissent que des copies statiques de la PSL peuvent mal classer des domaines valides ou retirés et que les fournisseurs ne doivent pas envoyer leurs clients demander une entrée PSL uniquement pour contourner des limites de sous-domaines, de débit ou des protections contre le pistage. Ces avertissements protègent à la fois la sécurité des utilisateurs et les capacités des bénévoles.

Un logiciel peut toujours employer la PSL comme heuristique, mais il doit assumer les conséquences de son actualisation, de ses solutions de repli et de sa politique.

La conclusion centrale de cette recherche est que la PSL condense de la gouvernance dans des données. Une ligne indique où commence l’enregistrement ou le contrôle indépendant, mais la décision vient des registres, propriétaires de domaines, bénévoles et responsables des implémentations en aval plutôt que d’une autorité mondiale unique. Sa légitimité tient à la transparence des preuves, à une syntaxe de règles contrainte et à une réutilisation étendue entre fournisseurs. Ce modèle distribué fragmente aussi la responsabilité lorsqu’une modification perturbe les cookies, les certificats ou le regroupement des services.

Un registre ou un propriétaire de domaine autorisé identifie une frontière d’enregistrement -> le demandeur ouvre sur GitHub une demande d’intégration fondée sur le modèle, avec preuves et attestations -> les contrôles automatiques et les tests vérifient la syntaxe, l’ordre et le comportement attendu -> les responsables bénévoles examinent l’autorité, l’impact et le choix de section -> la modification est fusionnée dans public_suffix_list.dat -> la copie canonique de publicsuffix.org est actualisée quotidiennement -> les navigateurs, bibliothèques et services ingèrent ou transforment la liste selon leurs propres calendriers

-> chaque utilisateur applique sa propre politique concernant les cookies, les certificats, le regroupement des sites, les limites de débit ou la sécurité.

Solidité des preuves par domaine. Identité canonique et finalité: très forte; le site officiel et le dépôt définissent le projet et ses exemples. Format des règles et algorithme de correspondance: très forte; un algorithme formel public et des tests sont disponibles. Modèle de soumission et d’autorité: forte; les directives et exigences actuelles du modèle sont publiques.

Fichier de données canonique actuel: preuves très fortes; il peut être téléchargé directement avec les métadonnées de version et de commit. Utilisation par les navigateurs et les normes: forte; des documents officiels relatifs aux navigateurs, aux normes du Web et aux certificats citent cette frontière. Déploiement et fraîcheur en aval: modérés; il n’existe ni inventaire complet ni calendrier commun de mise à jour. Gouvernance et effectifs: modérés; le processus bénévole est visible, mais il n’existe pas de liste actuelle exhaustive ni d’audit de la charge de travail.

Impact économique: limité; aucun compte autonome ni mesure de valeur vérifiable n’est disponible. La Public Suffix List est une carte, tenue par des bénévoles, de frontières administratives que le DNS n’encode pas. Elle protège les utilisateurs en permettant aux navigateurs de distinguer des titulaires sans lien, mais son influence dépasse ses ressources formelles: une ligne en amont peut orienter les cookies, certificats et politiques de service dans un écosystème en aval que ses responsables ne contrôlent pas.

La Public Suffix List constitue une infrastructure parce qu’elle fournit une frontière avant qu’un navigateur ou un service décide qui peut partager un état. Le fichier ne transporte pas de trafic, mais il peut déterminer si un cookie, un certificat ou une limite de débit s’applique à un seul site ou à plusieurs sites sans lien. Sa taille masque sa portée. De nombreux utilisateurs en aval compilent les données dans des binaires ou des bibliothèques; la plupart des utilisateurs finaux ignorent donc qu’une ligne examinée par des bénévoles a influencé la décision de leur navigateur. La liste révèle aussi une asymétrie de gouvernance: des entreprises peuvent faire dépendre des fonctions de grande valeur de l’inscription dans la PSL tout en laissant le projet bénévole externe subir la pression des clients qui en résulte. Fournisseurs de navigateurs: ils utilisent les frontières pour les cookies, le regroupement des sites,document.domainet l’interface; chaque fournisseur contrôle son analyseur, son actualisation et sa politique produit.

Registres de TLD: ils fournissent et maintiennent les règles de frontières d’enregistrement; leur politique peut changer avant la mise à jour de la liste. Opérateurs de plateformes privées: ils demandent des entrées PRIVATE pour des locataires ne se faisant pas mutuellement confiance; l’inscription peut modifier les cookies et certificats de tous leurs clients. Autorités de certification: elles utilisent les données de frontière pour les certificats génériques et les limites de débit; le choix exact des sections et de la fraîcheur varie.

Développeurs Web: ils dépendent indirectement du comportement des cookies et des sites; ils peuvent ignorer quel instantané PSL utilise un client. Responsables de bibliothèques: ils empaquettent les algorithmes de recherche et les données pour les applications; les forks et instantanés statiques peuvent diverger de la version canonique. Fournisseurs cloud et SaaS: ils utilisent des entrées ou s’y réfèrent pour leurs politiques de comptes et de sous-domaines; ils doivent assister directement leurs clients au lieu de transférer leur politique aux bénévoles de la PSL.

Équipes de sécurité et de confidentialité: elles utilisent les domaines enregistrables dans leurs logiques d’isolation, de pistage et de filtrage; eTLD+1 n’est pas une frontière complète de confiance ou d’origine. Responsables bénévoles: ils examinent les preuves, la syntaxe et les conséquences; leurs capacités sont limitées et aucun engagement de service n’est proposé. Internautes: ils bénéficient d’une protection contre le partage d’état entre titulaires; ils ne peuvent pas facilement voir ou choisir la version utilisée par chaque produit.

Ce que le sujet ne possède ni ne contrôle: la PSL ne contrôle pas la zone racine du DNS et ne décide pas si un nom de domaine existe. Elle n’enregistre pas les domaines et ne vérifie pas la propriété juridique au-delà des contrôles d’autorité lors des soumissions. Elle ne prescrit pas exactement la manière dont les navigateurs, autorités de certification ou services utilisent chaque entrée. Elle ne peut obliger un produit en aval à se mettre à jour, à revenir en arrière ou à inclure la section PRIVATE.

Une entrée n’établit ni la sécurité, ni la fiabilité, ni la légitimité commerciale. Le projet n’accorde aucune exemption aux limites de débit ou aux politiques de compte d’une autre entreprise. Il ne fournit ni service client ni délai d’examen garanti. L’hébergement associé à Mozilla ne transforme pas chaque décision en aval en décision de Mozilla. L’importance de la PSL vient du fait qu’elle représente la moins mauvaise réponse commune à une question à laquelle le DNS ne répond pas: où commence le contrôle administratif indépendant?

Son risque opérationnel vient de ce que de nombreux produits ont transformé cette réponse en politique sans donner aux responsables bénévoles un contrôle, des ressources ou une visibilité équivalents.

La liste doit être traitée comme une donnée de frontière, et non comme une autorité DNS. Une ligne peut indiquer à un utilisateur où un domaine administratif est susceptible de se terminer; elle ne peut prouver que le nom se résout, que l’opérateur est digne de confiance ou que deux labels appartiennent à des personnes morales différentes.

Pourquoi le DNS ne peut révéler une frontière d’enregistrement

Le DNS enregistre la délégation et la résolution des noms, non la règle commerciale ou administrative selon laquelle les utilisateurs obtiennent des noms. La politique d’enregistrement varie selon les registres, organismes publics et plateformes privées; les logiciels ont donc besoin de preuves extérieures à l’arborescence DNS.

Nom canonique: Public Suffix List. Abréviation courante: PSL. Type de sujet: jeu de données d’infrastructure inter-fournisseurs et projet communautaire bénévole. Fichier canonique: public_suffix_list.dat. Point de téléchargement canonique: publicsuffix.org/list/public_suffix_list.dat. Licence: Mozilla Public License 2.0. Description des responsables: bénévoles de Mozilla travaillant avec les soumissions des registres et propriétaires de domaines. Version canonique observée: 2026-07-25_14-20-03_UTC. Contexte daté: téléchargement du 6 août 2026; ces éléments évoluent. Commit canonique observé: e1b8015c3b2f0f4f8c18659c2480fc1a22c07b20.

Contexte daté: téléchargement du 6 août 2026; ces éléments évoluent. Procédure d’actualisation du fichier canonique: la copie de publicsuffix.org est mise à jour quotidiennement à partir de GitHub. Fréquence de téléchargement recommandée: au maximum une fois par jour. Fréquence habituelle des modifications en amont: quelques fois par semaine, selon la page du projet. Règle exacte de base: un suffixe public par ligne qui n’est pas un commentaire. Contexte daté: format actuel.

Syntaxe des caractères génériques: astérisque uniquement dans le label le plus à gauche. Contexte daté: format actuel. Syntaxe des exceptions: la règle commence par! et prévaut sur une correspondance générique ou générale. Contexte daté: format actuel. Canonisation: comparaison des noms d’hôte en minuscules et en Punycode. Contexte daté: algorithme actuel. Règle par défaut en l’absence de correspondance: *. Contexte daté: algorithme formel actuel; les cas d’usage peuvent traiter les suffixes inconnus différemment. Règle prépondérante: l’exception si elle existe, sinon la règle correspondante comportant le plus de labels.

Contexte daté: algorithme formel actuel. Domaine enregistrable: suffixe public plus un label supplémentaire. Contexte daté: algorithme formel actuel. Divisions principales: sections ICANN et PRIVATE. Autorité de soumission: représentant autorisé du titulaire du domaine. Preuves pour une soumission ICANN: autorité du registre, de l’ICANN ou de l’IANA, ou documents officiels justificatifs.

Statut de confiance: l’inscription dans la PSL ne constitue pas un indicateur de sécurité ou de confiance. Usage historique principal: frontière d’héritage des cookies. Autres usages dans les navigateurs: restrictions dedocument.domain, regroupement de l’historique et des cookies, mise en évidence des URL et fonctions liées aux sites. Usage dans les systèmes de certificats: analyse des domaines contrôlés par les registres et des frontières des certificats génériques; la politique exacte varie selon l’utilisateur. Règle de 2026 pour les demandes d’intégration: modèle automatisé obligatoire; ne pas le coller dans un GPT, le modifier ou le résumer. Contexte daté: 6 mai 2026. Contrôle en aval: les responsables ne contrôlent ni la date de mise à jour ni l’usage des dérivés. Engagement de service: aucun n’est publié. Service client: le projet indique qu’il n’existe aucune ressource de service client PSL. Inventaire complet des utilisateurs en aval: non publié. Revenus ou valorisation autonomes: sans objet ou non publiés.

Avant la PSL, la logique des cookies des navigateurs considérait souvent comme frontières de registre uniquement les labels de premier niveau sans point. Elle échouait pour des structures comme co.uk, où les enregistrements indépendants se font un niveau plus bas. Années 2000: Mozilla a développé un service de données sur les TLD effectifs ou suffixes publics afin de représenter les politiques d’enregistrement irrégulières, créant une solution maintenable en remplacement d’une inférence purement algorithmique impossible.

2007: le droit d’auteur et l’identité du projet Publicsuffix.org datent de cette période, établissant une ressource publique inter-fournisseurs au-delà de l’arborescence source d’un seul navigateur. 2008-2010: les tickets Mozilla et les mises à jour de navigateurs ont régulièrement actualisé les données des TLD effectifs, montrant que la liste était une donnée de politique vivante plutôt qu’une norme statique. Années 2010: Chromium, Opera, Qt, des bibliothèques de robots d’exploration et d’autres logiciels ont adopté les données ou les concepts de la PSL, transformant le jeu de données en infrastructure inter-fournisseurs.

2013-2014: un point de distribution canonique sur publicsuffix.org a été établi et des recommandations de fréquence d’actualisation ont été publiées. Cela a réduit les liens directs vers l’infrastructure source des navigateurs et créé une URL prise en charge. Années 2010: l’usage de la section PRIVATE s’est développé pour les plateformes déléguant des sous-domaines à des utilisateurs ne se faisant pas mutuellement confiance, étendant le modèle de frontière au-delà des registres DNS formels. 2018: les recommandations de soumission ont insisté sur les tests, l’autorité et le suivi, rendant l’examen public des modifications plus reproductible.

2021: les recommandations de sécurité ont documenté la relation avec l’ICANN, l’IANA et les responsabilités des administrateurs de TLD, précisant qu’il existe plusieurs ressources différentes qualifiées de « suffixes publics ». 8 février 2022: la documentation du format et de la spécification a été regroupée dans le wiki GitHub, simplifiant la maintenance publique du langage de règles. 2023: des avis du dépôt ont rappelé que le projet bénévole ne pouvait prendre en charge les demandes de service client dirigées par des fournisseurs, rendant explicites les limites de ressources et la diffusion par des tiers.

26 juillet 2024: les responsables ont lancé des prises de contact manuelles à très faible volume afin de vérifier si certaines entrées demeuraient nécessaires, introduisant un mécanisme prudent d’examen des entrées obsolètes. 28 octobre 2024: les recommandations sur la diffusion par des tiers et la sécurité ont été actualisées, rejetant explicitement l’usage des entrées PRIVATE comme signaux de confiance ou solutions de contournement du service client.

1er avril 2025: la documentation du format a précisé la canonisation, les règles prépondérantes et la sémantique des sections, renforçant les indications données aux responsables d’implémentation sur le comportement exact de correspondance. 27 mai 2025: un avis du dépôt a demandé aux utilisateurs de Cloudflare de ne pas solliciter d’ajout à la PSL uniquement pour contourner des limites de sous-domaines, protégeant les capacités bénévoles et décourageant les contournements dangereux de politiques.

6 mai 2026: le modèle automatisé de demande d’intégration est devenu obligatoire pour les ajouts, avec interdiction explicite de le coller dans des systèmes GPT ou de le réécrire par leur intermédiaire, afin de préserver les attestations, la transparence et la cohérence de l’examen bénévole.

25 juillet 2026: la version du fichier canonique intégrait le commit e1b8015c3b2f0f4f8c18659c2480fc1a22c07b20, dernière version observée à la date limite de la recherche. 6 août 2026: le dépôt, la distribution canonique et la procédure de soumission demeuraient actifs, ce qui confirme leur fonctionnement actuel. La frontière des cookies que les points ne pouvaient révéler: un navigateur peut analyser les labels, mais il ne peut déduire de la syntaxe DNS si les utilisateurs s’enregistrent directement sous uk, co.uk ou un label plus profond du secteur public. La politique des registres varie selon l’espace de noms.

Sans frontière de politique, des titulaires sans lien peuvent être traités comme un seul domaine de cookies, ce qui compromet l’isolation. La PSL consigne la politique soumise par des parties faisant autorité; elle ne rend pas à elle seule cette politique vraie dans le DNS. Le TLD effectif comme infrastructure de navigateur.

Mozilla a mis en œuvre un service de TLD effectifs et maintenu une liste dans le code source du navigateur avant que le jeu de données ne devienne une ressource inter-fournisseurs distincte. Cette implémentation a montré qu’un petit fichier de données pouvait combler une faille de sécurité que le seul texte des normes ne pouvait résoudre. La terminologie historique des navigateurs ne doit pas laisser croire que chaque suffixe public est réellement un TLD. Les plateformes privées créent des frontières analogues à celles des registres.

Les plateformes cloud et applicatives peuvent permettre à des clients indépendants de créer des sites sous un même domaine enregistré à titre privé, par exemple des locataires distincts sous un suffixe d’hébergement. Considérer l’ensemble du domaine du propriétaire de la plateforme comme un seul site peut réunir les cookies et l’état d’identité de clients ne se faisant pas mutuellement confiance. L’inscription est une expression volontaire de politique et ne certifie ni la plateforme ni ses locataires. Une liste, de nombreux utilisateurs.

Les moteurs de navigateurs, bibliothèques, systèmes de certificats, robots d’exploration et services ont adopté la liste pour prendre des décisions différentes. La réutilisation inter-fournisseurs a rendu l’exactitude en amont et la rétrocompatibilité plus importantes que dans une implémentation propre à un navigateur. Le projet ne peut garantir que tous les utilisateurs emploient la même section, le même algorithme, la même solution de repli ou la même cadence d’actualisation.

Gouvernance bénévole sous pression des produits: lorsque des entreprises ont commencé à renvoyer leurs clients vers la PSL pour résoudre des limites de débit, des problèmes d’analyse et des restrictions de sous-domaines, les responsables ont reçu des demandes étrangères à la finalité du jeu de données. Les règles de soumission défendent désormais à la fois le sens sécuritaire de la liste et le temps limité des examinateurs. Une procédure stricte peut frustrer les demandeurs légitimes; une procédure faible peut provoquer des perturbations mondiales. Première phase: données de TLD effectifs propres au navigateur.

Mozilla maintenait des données de frontière de registre dans le développement du navigateur afin d’empêcher les cookies trop larges et de permettre le regroupement des domaines.

La liste a commencé comme une infrastructure d’implémentation destinée à résoudre un problème concret de sécurité du Web. L’historique des sources des navigateurs est dispersé entre d’anciens tickets et dépôts plutôt que réuni dans des archives institutionnelles complètes. Deuxième phase: ressource publique inter-fournisseurs. Publicsuffix.org et une liste canonique ont rendu les données accessibles au-delà d’un navigateur. Le projet est devenu une dépendance commune utilisable par plusieurs moteurs et bibliothèques. Des données communes n’ont pas créé une implémentation ou un calendrier de publication unique et obligatoire.

Troisième phase: maturation des sections ICANN et PRIVATE. Les règles ont distingué les espaces de noms adossés à des registres des domaines privés dont les propriétaires délèguent des sous-domaines à des utilisateurs indépendants. Le modèle a ainsi représenté la politique formelle de délégation et les frontières administratives des plateformes. Il est légitime que certains usages traitent différemment les deux sections. Quatrième phase: dépôt, tests et algorithme formel.

L’examen sur GitHub, l’intégration continue, les recommandations de format et un algorithme documenté de règle prépondérante ont amélioré la reproductibilité. La maintenance est devenue un processus transparent d’ingénierie des données plutôt qu’une correction informelle de navigateur. Les tests valident la syntaxe et certaines propriétés sémantiques, pas toutes les conséquences dans chaque produit en aval. Cinquième phase: diffusion en aval et pression d’assistance. Des produits tiers ont de plus en plus fait dépendre de l’inscription dans la PSL les limites de débit, le pistage, les certificats et le fonctionnement des comptes clients.

Le jeu de données a acquis un pouvoir de politique dépassant largement sa finalité initiale liée aux cookies. Les responsables n’ont ni choisi ni contrôlé nombre de ces dépendances. Sixième phase: attestations renforcées en 2026. Le projet a imposé un modèle structuré et automatisé de demande d’intégration et interdit que ses attestations soient modifiées ou résumées par des outils GPT. L’intégrité du processus est devenue une défense explicite contre les soumissions générées, dépourvues de contexte ou détournées par des fournisseurs.

Un modèle plus rigoureux améliore les preuves, mais ne peut garantir ni la compatibilité en aval ni le délai de réponse des bénévoles.

Des TLD effectifs de Mozilla à une liste inter-fournisseurs

La liste a commencé comme une infrastructure de TLD effectifs de Mozilla avant de devenir une ressource inter-fournisseurs partagée. Cette transition a transformé un détail d’implémentation de navigateur en données amont dont dépendent de nombreux produits indépendants.

La Public Suffix List compte des responsables de projet plutôt qu’une équipe dirigeante classique. L’autorité s’exerce au moyen des droits sur le dépôt, de l’examen des preuves, de recommandations documentées et de normes communautaires, tandis que les registres et propriétaires de domaines fournissent les faits de politique sous-jacents. Le dépôt public montre les contributeurs et examinateurs, mais aucune structure juridique actuelle complète, aucun effectif salarié ni aucun conseil formel élu n’a été identifié. Il est plus sûr de parler de l’infrastructure de Mozilla et d’une maintenance bénévole que d’inventer une organisation autonome.

Direction actuelle ou historiquement pertinente. Bénévoles de Mozilla: maintenance et examen du projet; la description provient du site officiel et la liste des bénévoles ainsi que leur activité évoluent. Responsables du dépôt: ils fusionnent, rejettent ou demandent des modifications; leur autorité est attestée par les droits GitHub et l’examen public.

Registres de TLD: sources faisant autorité pour la politique de la section ICANN; ils définissent la politique d’enregistrement sans contrôler toute la gouvernance de la PSL. ICANN et IANA: sources documentaires faisant autorité sur la zone racine et les registres; elles n’exploitent pas la PSL inter-fournisseurs. Titulaires de domaines privés: demandeurs faisant autorité pour les frontières PRIVATE; ils doivent comprendre les conséquences et les attester.

Responsables des implémentations de navigateurs et de bibliothèques: propriétaires des analyseurs et politiques en aval; la consommation des données ne leur confère aucune autorité sur le projet. Infrastructure de la Mozilla Foundation: contexte historique et d’hébergement; elle ne fait pas de la liste un produit réservé à Mozilla. Contributeurs publics: ils soumettent des corrections, tests et documents; la contribution est ouverte, mais l’autorité de fusion reste limitée. Structure organisationnelle ou contributive.

Les registres et propriétaires de domaines autorisés définissent la politique réelle d’enregistrement ou de location -> les demandeurs fournissent preuves et attestations -> l’examen public sur GitHub et les tests automatisés valident le format et l’autorité -> les responsables bénévoles fusionnent la règle canonique -> publicsuffix.org publie une copie quotidienne -> les équipes des navigateurs, autorités de certification, bibliothèques et services choisissent les sections, transforment les données et fixent leur cadence d’actualisation -> le comportement des cookies, certificats et sites pour l’utilisateur final résulte de

ces implémentations en aval.

La gouvernance du projet est plus étroite que son influence. Les responsables décident si les preuves justifient une ligne, mais pas de tout le comportement que les navigateurs, autorités de certification ou services cloud associent à cette ligne. La responsabilité doit donc être retracée à travers les acteurs en amont et en aval.

Le statut bénévole n’est pas un simple détail d’effectif. Il façonne la politique: les responsables refusent le transfert des demandes de service client et imposent des attestations structurées parce que chaque demande de faible qualité consomme une capacité d’examen rare et peut provoquer de vastes perturbations. Personne ou organisation liée: type de relation, période, statut, description, pertinence, sources et niveau de confiance.

Mozilla: origine historique du projet et hébergeur de son infrastructure, des années 2000 à aujourd’hui, contexte actif; elle a lancé les travaux des navigateurs sur les TLD effectifs et soutient l’identité du projet. GitHub publicsuffix/list: plateforme active de source et d’examen; elle héberge les données, tests, tickets et demandes d’intégration, assurant le contrôle des modifications et la transparence. Registres de TLD: sources de politique faisant autorité, catégorie active de longue date; ils soumettent et vérifient les frontières de la section ICANN.

ICANN et IANA: documentation active de la zone racine et des registres, apportant le contexte de délégation des TLD.

Propriétaires de domaines privés: demandeurs actifs de la section PRIVATE; ils déclarent les frontières administratives des services multilocataires, importantes pour l’isolation des sites cloud et des plateformes. Firefox / Gecko: utilisateur historique et actuel dans les navigateurs; il emploie les données PSL ou de TLD effectifs pour des fonctions du navigateur. Chromium / Chrome: utilisateur actif de longue date; il prétraite et emploie la liste pour les décisions relatives aux sites et cookies, à l’échelle inter-fournisseurs.

Écosystème WebKit / Safari: catégorie active d’utilisateurs; il emploie les notions de suffixe public dans le comportement de la plateforme Web. CA/Browser Forum et autorités de certification: écosystème actif de normes et d’utilisateurs; ils emploient les notions de domaines contrôlés par les registres pour les politiques d’émission et de certificats génériques. Let’s Encrypt: autorité de certification utilisatrice active; elle emploie les notions de domaine enregistré dans les limites de débit et les opérations d’émission, avec des conséquences économiques concrètes.

Bibliothèques de langages et de systèmes: nombreuses implémentations dérivées qui fournissent aux applications des analyseurs et instantanés, avec une forte diffusion en aval. Plateformes cloud, sociales et publicitaires: nombreux utilisateurs tiers pouvant associer des fonctions ou limites de produits aux entrées PSL, source documentée de pression d’assistance et de pouvoir politique involontaire. Un logo, l’importation d’une bibliothèque ou une référence normative ne crée aucune autorité de gouvernance.

Les fournisseurs de navigateurs restent responsables de leur implémentation, les autorités de certification de leur politique d’émission et les plateformes de leurs limites présentées aux clients. La PSL est une dépendance commune sans calendrier de publication commun. Son écosystème ressemble à une chaîne d’approvisionnement de données: preuves en amont, fusion canonique, transformation, empaquetage, publication du produit et adoption finale par les clients sont des étapes distinctes.

La PSL n’est pas une entreprise classique et ne publie ni chiffre d’affaires, ni bénéfice, ni valorisation, ni effectif salarié autonome. Ses apports économiques sont le travail bénévole, l’infrastructure associée à Mozilla, les efforts des registres et l’ingénierie réalisée par les organisations utilisatrices. L’absence de prix ne signifie pas que la dépendance est sans coût. Examiner les soumissions, maintenir les tests, gérer le transfert des demandes d’assistance, enquêter sur les régressions et coordonner les retours en arrière consomme une expertise rare. Preuves financières et de financement vérifiées.

Indicateur ou élément de financement: valeur ou statut vérifié, période, sources et qualification.

Chiffre d’affaires autonome: non publié ou sans objet à la date limite; il s’agit d’un jeu de données communautaire, non d’une société d’exploitation déclarée. Bénéfice ou perte autonome: non publié ou sans objet; ne pas l’estimer. Effectif de responsables rémunérés: non publié; les documents officiels insistent sur les ressources bénévoles. Soutien de l’infrastructure Mozilla: hébergement et contexte historique actuels ou passés; aucun budget complet du projet n’est publié. Contribution des registres: preuves de politique et temps du personnel, coût distribué supporté par les demandeurs.

Coût des fournisseurs en aval: intégration de l’analyseur, tests et mises à jour de publication, non consolidés par la PSL. Licence: la MPL 2.0 autorise la réutilisation selon ses conditions; le traitement des dérivés et l’actualisation des données restent sous la responsabilité de l’utilisateur. Valeur économique: importante mais non quantifiée de façon indépendante à la date limite; l’ensemble des preuves ne permet pas d’attribuer une valorisation de marché à des données de sécurité partagées.

Risques de financement et de pérennité: épuisement des bénévoles et retards d’examen; demandes d’assistance non financées redirigées par de grands fournisseurs; dépendance aux infrastructures d’hébergement et de dépôt; capacité limitée de vérification proactive des entrées obsolètes; conséquences croissantes sans effectifs correspondants; utilisateurs en aval bénéficiant du projet sans fournir de ressources d’examen; absence de budget commun pour les tests de compatibilité inter-fournisseurs.

Les retours en arrière d’urgence peuvent exiger une attention rapide sur plusieurs fuseaux horaires. La PSL présente l’économie classique d’une dépendance publique numérique: le coût marginal de réutilisation est presque nul, mais l’exactitude et la gouvernance nécessitent un travail expert concentré. Le risque n’est pas une hausse du prix de l’abonnement, mais une croissance des conséquences plus rapide que celle des capacités de maintenance. Une réponse durable ne suppose pas nécessairement de transformer la liste en fournisseur commercial.

Les organisations en aval peuvent financer une infrastructure neutre, contribuer aux tests, assurer directement leur service client et éviter de concevoir des politiques produit où une fusion par des bénévoles externes devient l’unique issue. La liste n’a pas d’implantation physique significative. Sa géographie est celle de l’espace de noms DNS mondial, des territoires et politiques des registres, des lieux où se trouvent les bénévoles et des circuits de publication des produits en aval.

Les entrées peuvent représenter des structures nationales, génériques, municipales, éducatives et propres à des plateformes privées. La présence dans la section d’un pays ne signifie pas que le projet PSL possède ou réglemente cet espace de noms. Lieu ou empreinte: fonction confirmée et qualification. Espace de noms DNS mondial: les règles couvrent des domaines nationaux, génériques et d’infrastructure; la couverture dérive des politiques et évolue. Infrastructure Mozilla et GitHub: site Web, dépôt et canaux de distribution; hébergement numérique, non siège autonome.

Territoires des registres de TLD: sources de la politique d’enregistrement de la section ICANN; l’autorité reste propre à chaque registre et au droit applicable. Domaines de plateformes privées dans le monde: sources des frontières de location de la section PRIVATE; l’inscription est demandée par le propriétaire et n’est pas une désignation réglementaire. Canaux de publication des navigateurs et logiciels: ils distribuent mondialement des instantanés dérivés; le calendrier dépend du produit et de la version.

Terminaux des utilisateurs finaux: ils appliquent localement les décisions de frontière; un utilisateur peut disposer de données obsolètes ou modifiées. La liste traduit des politiques d’enregistrement diverses sur les plans géographique et institutionnel dans une syntaxe unique. Cette syntaxe commune favorise l’interopérabilité, mais ne doit pas être confondue avec un régime politique mondial unique: chaque règle provient d’une décision propre à un registre ou propriétaire de domaine.

Règle exacte, caractère générique et exception: un langage à trois règles

Le langage est volontairement réduit. Les règles exactes désignent un suffixe, les caractères génériques couvrent un label variable et les exceptions retranchent un nom qui correspondrait autrement à une règle plus large; cette simplicité rend l’examen possible tout en préservant la précision des conséquences.

La Public Suffix List ne vend aucun produit. Elle maintient un jeu de données de politique compact, une procédure de validation et un point de distribution que d’autres logiciels transforment en décisions de sécurité et d’identité. Ses activités doivent être analysées selon leurs conséquences, non selon la taille de l’organisation. Maintenance de la liste canonique: ajout, actualisation et suppression des règles de suffixe public. Principaux utilisateurs ou bénéficiaires: navigateurs, bibliothèques, autorités de certification, services et développeurs, via le dépôt GitHub et le fichier de données canonique.

Rôle d’infrastructure: jeu de données partagé sur les frontières administratives. Limite principale: aucune garantie complète d’exhaustivité ou de fraîcheur de la politique.

Examen de la section ICANN: enregistrer les frontières contrôlées par les registres sous des espaces de noms délégués. Principaux utilisateurs ou bénéficiaires: registres de TLD et utilisateurs ayant besoin de frontières formelles d’enregistrement, au moyen de demandes étayées par des preuves. Rôle d’infrastructure: cartographier la politique des registres sous la zone racine. Limite principale: la politique peut changer avant qu’une copie en aval soit mise à jour. Examen de la section PRIVATE: enregistrer les politiques de propriétaires de domaines pour des plateformes de sous-domaines multilocataires.

Principaux utilisateurs ou bénéficiaires: plateformes d’hébergement, cloud et applicatives, au moyen de demandes autorisées par le propriétaire. Rôle d’infrastructure: séparer en sites distincts des locataires ne se faisant pas mutuellement confiance. Limite principale: aucune garantie générale de confiance ou de sécurité.

Spécification du format: définir la syntaxe exacte, générique et d’exception ainsi que la correspondance. Principaux utilisateurs ou bénéficiaires: responsables des bibliothèques et navigateurs, grâce à l’algorithme et aux exemples du wiki public. Rôle d’infrastructure: analyse interopérable et calcul d’eTLD+1. Limite principale: les implémentations peuvent diverger sur la canonisation et le repli. Validation automatisée: contrôler le format, le tri, les doublons et les cas de test. Principaux utilisateurs ou bénéficiaires: demandeurs et responsables, au moyen de l’intégration continue, de l’outil de contrôle et de la suite de tests du dépôt.

Rôle d’infrastructure: réduire les erreurs humaines d’examen. Limite principale: impossibilité de modéliser tous les effets propres aux produits.

Vérification de l’autorité: confirmer qu’un registre ou propriétaire de domaine soutient la frontière demandée. Principaux utilisateurs ou bénéficiaires: responsables et opérateurs de domaines concernés, au moyen de documents, de la validation des contacts et parfois de preuves DNS TXT. Rôle d’infrastructure: empêcher les modifications de politique non autorisées. Limite principale: les contacts des sociétés et registres peuvent changer ou répondre lentement. Distribution quotidienne: publier une copie canonique issue du dépôt.

Principaux utilisateurs ou bénéficiaires: applications et systèmes de mise à jour, grâce au point de téléchargement de publicsuffix.org. Rôle d’infrastructure: source stable des données actuelles. Limite principale: les utilisateurs peuvent mettre en cache ou prétraiter les données pendant beaucoup plus longtemps.

Comment les logiciels calculent le domaine enregistrable

La détermination du domaine enregistrable relève d’un algorithme, non d’une supposition. La canonisation, la correspondance, la priorité des exceptions et le principe de la règle la plus longue doivent être appliqués de façon cohérente, même si les utilisateurs choisissent encore leur politique de repli et de sections.

Flux des modifications et historique du dépôt: rendre visibles les changements, leur justification et les échanges d’examen. Principaux utilisateurs ou bénéficiaires: responsables des implémentations, chercheurs et opérateurs, via l’historique Git, les demandes d’intégration et le flux Atom. Rôle d’infrastructure: auditabilité et suivi des mises à jour. Limite principale: les échanges publics peuvent ne pas refléter des contacts privés de validation. Recommandations de sécurité et d’usage: mettre en garde contre l’utilisation abusive comme données de validité DNS, de confiance ou de contournement.

Principaux utilisateurs ou bénéficiaires: équipes produit et demandeurs, au moyen des avis du site et du wiki. Rôle d’infrastructure: préserver les frontières sémantiques et la sécurité des utilisateurs. Limite principale: les fournisseurs en aval ne sont pas tenus de suivre les recommandations.

Prise de contact pour les entrées obsolètes: demander à certains titulaires si leurs entrées demeurent nécessaires. Principaux utilisateurs ou bénéficiaires: opérateurs déjà présents dans la section PRIVATE, au moyen d’une procédure manuelle de courriels à faible volume. Rôle d’infrastructure: hygiène des données et sécurité des suppressions. Limite principale: échelle manuelle très limitée. Discussion communautaire: examiner le format, la sémantique et les questions de maintenance.

Principaux utilisateurs ou bénéficiaires: responsables, registres et responsables d’implémentation, via les tickets, demandes d’intégration et la liste de diffusion. Rôle d’infrastructure: coordination de la politique entre fournisseurs. Limite principale: la participation ne représente pas formellement tous les utilisateurs.

Retour en arrière et correction: annuler ou modifier les entrées nuisibles après constat d’effets involontaires. Principaux utilisateurs ou bénéficiaires: sites touchés et utilisateurs en aval, au moyen d’une nouvelle demande d’intégration et de sa propagation. Rôle d’infrastructure: reprise après erreur. Limite principale: chaque correction subit son propre délai en aval. Documentation de la diffusion en aval: expliquer que les produits dérivés contrôlent leurs copies et leurs usages. Principaux utilisateurs ou bénéficiaires: demandeurs et clients des produits, grâce aux recommandations du wiki.

Rôle d’infrastructure: clarifier la frontière de responsabilité. Limite principale: les utilisateurs peuvent continuer d’imputer aux responsables les politiques de tiers.

Gouvernance du code de conduite: fixer les attentes de participation publique. Principaux utilisateurs ou bénéficiaires: membres du projet, par l’intermédiaire des règles communautaires de Mozilla et GitHub. Rôle d’infrastructure: protéger la collaboration bénévole. Limite principale: ne crée aucune capacité d’assistance rémunérée. La valeur opérationnelle de la liste vient de sa retenue. Elle utilise un langage volontairement limité et demande aux auteurs de prouver une frontière plutôt que de décrire toute une activité.

Cette conception légère permet une vaste réutilisation, mais ne peut représenter toutes les nuances commerciales ou sécuritaires ajoutées par les systèmes en aval.

La connaissance des versions est essentielle, car les utilisateurs se mettent à jour selon des calendriers différents. Un navigateur, un service de certificats et une bibliothèque applicative peuvent tous utiliser des données valides dérivées de la PSL tout en étant temporairement en désaccord après une modification en amont. Les rapports d’incident doivent nommer précisément le fichier ou le commit de chaque chaîne.

ICANN et PRIVATE: deux formes d’autorité

Les sections ICANN et PRIVATE représentent des formes de preuve différentes. Une délégation adossée à un registre et la frontière entre locataires d’une plateforme privée peuvent avoir des conséquences analogues dans un navigateur sans disposer de la même autorité institutionnelle.

Le formulaire de soumission fait partie de l’infrastructure. Ses attestations obligent le propriétaire du domaine ou le registre à considérer les conséquences pour les cookies, les certificats et la propagation avant de demander aux bénévoles de publier une règle susceptible d’être copiée dans le monde entier. Les implémentations doivent normaliser le nom d’hôte interrogé et les règles avant la comparaison. Le guide formel impose une comparaison en minuscules et en Punycode tout en conservant les distinctions pertinentes des noms de domaine pleinement qualifiés, comme un point final.

La canonisation empêche que des encodages visuellement différents produisent des décisions de frontière incohérentes. La limite opérationnelle tient au fait que le traitement Unicode, les labels invalides et l’analyse des URL propre aux bibliothèques peuvent encore diverger avant l’exécution de l’algorithme PSL. Une ligne ordinaire comme co.uk correspond aux labels situés à droite d’un domaine. La règle détermine les labels constituant le suffixe public lorsqu’elle est prépondérante.

Les règles exactes représentent directement les structures courantes des registres. Limite opérationnelle: une règle exacte ne peut exprimer toutes les exceptions ni une politique d’enregistrement évoluant dynamiquement. Une règle commençant par un * à gauche correspond à un label arbitraire à cette position. Dans un espace de noms comme *.ck, elle peut traiter les labels de deuxième niveau comme des suffixes publics sans les énumérer. Les caractères génériques représentent de manière compacte les registres dont la frontière publique s’applique à de nombreux labels.

Limite opérationnelle: seul un caractère générique à gauche est valide, et les erreurs des utilisateurs peuvent élargir excessivement la correspondance. Une règle commençant par! prévaut sur une correspondance générique ou exacte plus large. Lorsqu’une exception prévaut, l’algorithme retire son label le plus à gauche pour déterminer le suffixe public. Les exceptions représentent des noms enregistrables à l’intérieur d’une structure générique autrement publique.

Limite opérationnelle: des erreurs d’ordre ou d’analyse peuvent inverser la frontière prévue pour les cookies ou les sites. Un domaine est comparé à toutes les règles. Une exception l’emporte; sinon, la règle correspondante comportant le plus de labels prévaut; en l’absence de correspondance, * est la règle par défaut. Le principe de la correspondance la plus longue résout de façon déterministe les structures de politique qui se chevauchent. Limite opérationnelle: certains usages refusent les suffixes inconnus au lieu d’appliquer la règle par défaut; le comportement du produit doit donc être documenté.

Le domaine enregistrable correspond au suffixe public accompagné d’un label supplémentaire. Pour un hôte sous example.co.uk, l’algorithme renvoie co.uk comme suffixe et example.co.uk comme domaine enregistrable. Cette frontière eTLD+1 est une unité pratique pour le regroupement des sites et les politiques.

La demande bénévole aux conséquences mondiales

Une demande d’intégration peut changer la manière dont les logiciels regroupent les domaines partout dans le monde. L’examen porte donc sur l’autorité du demandeur, la politique existante, le comportement des tests et la disponibilité du demandeur après la fusion.

Limite opérationnelle: le domaine enregistrable ne correspond pas dans tous les contextes à une origine, une organisation, un compte ou un propriétaire juridique. Les règles de la section ICANN correspondent aux domaines de la zone racine de l’IANA et aux subdivisions définies par les registres. Les modifications doivent provenir de sources autorisées du registre, de l’ICANN ou de l’IANA, ou s’appuyer sur des documents officiels et une validation. Cette section fournit une cartographie à plus forte confiance de la politique formelle d’enregistrement.

Limite opérationnelle: le label « ICANN » est un raccourci historique et ne transforme pas la PSL en base de données gouvernée par l’ICANN. Les détenteurs de domaines privés peuvent demander des frontières lorsqu’ils attribuent des sous-domaines à des parties ne se faisant pas mutuellement confiance. Seul un représentant autorisé du titulaire peut demander la modification, car le propriétaire en supporte les conséquences. La section permet à l’isolation des sites dans les navigateurs de refléter la location sur les plateformes cloud.

Limite opérationnelle: l’inscription n’apporte aucune garantie générale de sécurité et peut affecter les cookies ou certificats de façon inattendue. Les recommandations peuvent utiliser un enregistrement TXT _psl ou des documents de registre afin de confirmer l’autorité ou la politique. Un jeton publié dans le DNS fournit aux responsables une preuve que la partie contrôlant l’espace de noms approuve la demande. Il réduit la dépendance à l’identité par courriel et aux affirmations de tiers. Limite opérationnelle: le contrôle DNS à un instant donné ne garantit ni l’exactitude à long terme de la politique ni l’autorité de l’organisation.

Les agents utilisateurs emploient la frontière de suffixe public afin d’empêcher une réponse de définir un cookie pour un suffixe de registre partagé. Un cookie peut normalement être limité au domaine enregistrable ou à un hôte subordonné, mais pas à co.uk ou à un autre suffixe public.

Ce mécanisme empêche un titulaire d’injecter un état dans des sites sans lien. Limite opérationnelle: le traitement effectif suit les spécifications des cookies des navigateurs et peut inclure, au-delà des données PSL, des règles relatives aux hôtes seuls, à SameSite et au partitionnement. Les navigateurs déterminent un site à partir du schéma et du domaine enregistrable pour certaines décisions de sécurité et de confidentialité. L’eTLD+1 dérivé de la PSL aide à regrouper les sous-domaines tout en séparant les locataires sans lien sous un suffixe public.

Le mécanisme affecte les cookies, le stockage, la navigation et les systèmes de lutte contre le pistage. Limite opérationnelle: les notions d’origine, de site tenant compte du schéma et d’ensembles de sites liés peuvent produire des frontières différentes de l’eTLD+1. Les politiques de certificats peuvent employer la section ICANN pour déterminer les labels contrôlés par les registres et empêcher l’émission de certificats génériques trop larges. Une autorité de certification ne devrait pas émettre un certificat générique immédiatement sous un suffixe contrôlé par un registre, comme *.com.

D’une fusion à des milliers de copies dérivées

La liste canonique n’est que le début d’une chaîne d’approvisionnement. Les bibliothèques la transforment, les fournisseurs l’empaquettent et les produits se mettent à jour selon leurs propres calendriers, si bien que plusieurs versions de « la PSL » sont utilisées simultanément.

La liste fournit une frontière d’enregistrement pratique aux contrôles de l’infrastructure à clés publiques du Web. Limite opérationnelle: les autorités de certification peuvent traiter différemment les entrées PRIVATE et doivent utiliser une version actuelle correctement analysée. Les autorités de certification et services en ligne peuvent regrouper les noms par domaine enregistré afin d’appliquer des quotas ou politiques de compte. Les frontières dérivées de la PSL peuvent empêcher un titulaire de contourner des limites au moyen de sous-domaines ou empêcher des locataires sans lien de partager un même quota.

Le fichier devient une infrastructure de politique économique et opérationnelle. Limite opérationnelle: les responsables rejettent explicitement les demandes visant uniquement à contourner les limites d’un tiers; ce fournisseur reste propriétaire de sa politique. Le projet copie chaque jour l’état du dépôt vers une URL stable de publicsuffix.org.

Les utilisateurs peuvent interroger cette URL au maximum une fois par jour et employer les flux de modifications ou métadonnées de version pour détecter les mises à jour. Un point pris en charge réduit l’usage de sources obsolètes ou non officielles. Limite opérationnelle: une publication quotidienne en amont ne contraint pas les produits à une actualisation quotidienne et ne garantit pas un retour en arrière immédiat. Les navigateurs et bibliothèques peuvent compiler la liste texte en arbres de préfixes, DAFSA, tables binaires ou paquets propres à un langage.

Le prétraitement accélère les recherches et intègre les données aux systèmes de publication. La liste peut ainsi fonctionner à l’échelle d’un navigateur sans interrogation réseau à chaque navigation. Limite opérationnelle: la transformation peut omettre des sections, introduire des différences d’analyse ou figer un instantané jusqu’à la prochaine version du produit. Le modèle automatisé recueille l’identité du demandeur, son autorité, le cas d’usage, les tests et la reconnaissance des conséquences.

Les responsables associent contrôles automatisés, examen des preuves et discussion publique avant la fusion. Cette procédure constitue le principal contrôle de gouvernance d’un jeu de données réutilisé mondialement. Limite opérationnelle: l’examen bénévole n’a aucun délai garanti, et un formulaire complet ne prouve pas l’absence de tout effet dangereux en aval. Une règle nuisible ou erronée est corrigée par une nouvelle modification du dépôt. La liste corrigée passe ensuite par le point canonique et le canal de mise à jour de chaque utilisateur dérivé. L’historique des versions rend la correction transparente et reproductible.

Limite opérationnelle: les délais en cascade peuvent laisser la mauvaise règle dans des logiciels déployés longtemps après son annulation.

Cookies, certificats et multiplication des usages

Les cookies ont fourni le problème de sécurité initial, mais les données orientent désormaisdocument.domain, l’affichage des URL, le regroupement de l’historique, les politiques de certificats, la logique des robots d’exploration, les limites de débit et d’autres choix de produits. Ces usages sont liés sans être identiques.

La sécurité des navigateurs exigeait des connaissances que les seuls labels DNS ne pouvaient fournir. À surveiller: l’évolution du partitionnement des cookies et des définitions de site. 2. Service de TLD effectifs de Mozilla: une liste propre au navigateur a démontré l’efficacité d’une solution fondée sur des données de politique. À surveiller: archives historiques et hypothèses de compatibilité. 3. Ressource publique inter-fournisseurs: Publicsuffix.org et GitHub ont rendu une liste canonique réutilisable par les produits. À surveiller: continuité de l’hébergement, de la licence et du dépôt. 4.

Expansion de la section PRIVATE: les plateformes multilocataires ont obtenu des frontières au niveau des titulaires sous des domaines privés. À surveiller: croissance des entrées privées et politiques obsolètes. 5. Algorithme formel et intégration continue: la correspondance documentée et les tests automatisés ont réduit les interprétations incohérentes. À surveiller: conformité des analyseurs dans les principales bibliothèques. 6. Avertissements sur la diffusion par des tiers: les responsables ont précisé que les fournisseurs ne devaient pas transférer au projet PSL leur politique client et leur assistance.

À surveiller: nouvelles dépendances de produits et schémas de renvoi. 7. Modèle obligatoire de 2026: les attestations et la cohérence de l’examen sont devenues des défenses explicites contre les soumissions générées sans contexte. À surveiller: qualité de l’examen, retard accumulé et difficultés pour les demandeurs légitimes. 8. Versionnement canonique actuel: l’horodatage et les métadonnées de commit intégrés permettent des mises à jour reproductibles. À surveiller: adoption par les utilisateurs des contrôles de version et de la télémétrie de retour en arrière.

Les produits peuvent intégrer la liste et ne l’actualiser qu’avec une version de l’application ou du système d’exploitation. Une politique correcte en amont peut rester sans effet lorsque d’anciens clients classent mal les frontières. Traitement éditorial: nommer la version du produit et l’âge des données; mettre en place des mécanismes fiables de mise à jour. La section PRIVATE consigne la politique de location d’un propriétaire de domaine, non un audit de sécurité ou de légitimité. Les services qui assimilent l’inscription à un label de confiance créent une fausse assurance.

Traitement éditorial: préciser explicitement l’absence de valeur de confiance et séparer la frontière de la réputation. Les cookies, certificats, limites de débit, regroupements d’historique et protections contre le pistage poursuivent des objectifs différents. Une même frontière peut convenir à un mécanisme et être trop large ou trop étroite pour un autre. Traitement éditorial: documenter pour chaque utilisateur le choix des sections, le repli et le modèle de menace. Utilisation abusive pour valider statiquement les domaines: certains logiciels emploient l’appartenance à la PSL pour décider si un nom est valide.

Les TLD et politiques changent; des données obsolètes peuvent refuser des domaines valides ou accepter des domaines retirés. Traitement éditorial: employer le DNS, l’IANA et les registres pour l’existence, et actualiser fréquemment la PSL lorsqu’elle sert d’heuristique. Des fournisseurs demandent à leurs clients de solliciter une modification de la PSL pour échapper à leurs propres restrictions. Cela surcharge les bénévoles et peut entraîner des changements nuisibles aux cookies ou protections contre le pistage.

Traitement éditorial: imposer aux fournisseurs d’assister leurs clients et de repenser directement leur politique. L’examen exige des preuves de politique, une autorité sur le domaine, une maîtrise de la syntaxe et un jugement sur l’impact. Quelques responsables deviennent un goulet d’étranglement pour des modifications d’importance mondiale. Traitement éditorial: ne pas promettre de délais; les bénéficiaires en aval devraient apporter des ressources et des tests. Une correction doit se propager par chaque circuit de publication dérivé.

Les utilisateurs peuvent constater des comportements divergents entre navigateurs et services pendant longtemps. Traitement éditorial: suivre l’adoption des commits et versions et prévoir un comportement réversible. Le courriel, l’identité sur le dépôt et le contrôle DNS peuvent ne pas représenter parfaitement l’autorité d’un registre ou d’une entreprise. Une modification non autorisée pourrait changer les frontières de sécurité de tout un espace de noms. Traitement éditorial: employer les documents officiels, l’attestation du propriétaire et la validation DNS selon les besoins.

Les bibliothèques peuvent diverger sur Unicode, les points finaux, les labels mal formés, les suffixes inconnus et l’inclusion des sections. Un même nom d’hôte peut donc produire des domaines enregistrables différents. Traitement éditorial: tester selon l’algorithme formel et des cas communs de conformité. Limites sémantiques d’une liste: le langage représente une frontière, mais non la propriété des comptes, les relations entre sociétés ou les politiques dynamiques. Les systèmes en aval peuvent en déduire un modèle d’identité plus fort que ne le permettent les données.

Traitement éditorial: employer la PSL comme une donnée parmi d’autres, non comme une base universelle de propriété des sites. Absence de responsabilité centrale en aval: les responsables ne peuvent forcer les utilisateurs à actualiser ou interpréter correctement les entrées. Un utilisateur peut accuser la liste d’une décision contrôlée ailleurs. Traitement éditorial: retracer chaque incident depuis la règle en amont jusqu’aux données dérivées et au code du produit.

Le projet documente des pressions d’utilisation abusive et des risques structurels, et non des actes répréhensibles établis de ses responsables. L’ensemble des sources impose de ne pas transformer les contraintes des bénévoles en accusations. Traitement éditorial: attribuer les avertissements et examiner les incitations institutionnelles sans inventer de faute.

La procédure bénévole ne peut fournir un engagement de service commercial. Les organisations dont les droits des clients, les limites de débit ou les politiques de certificats dépendent de la PSL restent responsables de l’assistance, du repli et du retour en arrière; elles ne peuvent transférer ces obligations aux responsables.