Résumé

  • Le RFC 2057 examinait l’écart entre les destinataires connus lors d’un envoi et les personnes susceptibles de lire ses copies.
  • Bradner reconnaissait un contrôle possible sur certaines pages Web, sans l’assimiler à une garantie sur l’identité et l’âge de tous les lecteurs.

Un expéditeur envoie un courriel à l’adresse d’une liste de diffusion. Le programme destinataire le redistribue aux abonnés, dont l’expéditeur ne connaît pas nécessairement les adresses. Parmi eux peut figurer une autre liste, qui recommence l’opération. Cette remise à un redistributeur est l’un des mécanismes décrits par Scott Bradner en novembre 1996 : les inscriptions changent automatiquement ; un éventuel modérateur sélectionne les messages, sans pour autant certifier l’âge des personnes qui les liront (§ 3.2.1).

Signé par Scott Bradner, de Harvard University, le RFC 2057 provient d’une déposition présentée dans une contestation du Communications Decency Act de 1996 aux États-Unis. Bradner interroge l’exigence, telle qu’il la décrit, de faire empêcher par l’émetteur l’accès de mineurs à certains contenus. Publié à titre informatif, le document précise qu’il ne constitue aucune norme Internet. Il expose une argumentation technique dans une controverse déterminée (en-tête et § 1).

Ce que l’adresse ne disait pas

Les acteurs n’occupaient pas des positions interchangeables. Dans le tableau institutionnel de 1996 dressé par Bradner, l’IETF contribuait aux normes permettant aux machines de communiquer ; InterNIC participait à l’attribution d’adresses et à l’unicité des noms. Cette coordination ne fournissait ni registre des âges ni contrôle des lecteurs. Les exploitants, eux, conservaient la maîtrise de leurs propres ordinateurs, réseaux et liaisons. Coordonner les identifiants ne revenait pas à gouverner toutes les consultations (§ 2).

Le courriel révélait déjà cette séparation. Une adresse indiquait où livrer, non qui lirait. Bradner évoquait les renseignements déclarés par les utilisateurs, les alias, les relais de courrier anonymisant l’expéditeur et les comptes partagés. La réception pouvait être différée : l’arrivée du message et sa lecture ne coïncidaient pas. Même identifier le titulaire d’un compte ne suffisait donc pas à identifier la personne devant le terminal. Selon son appréciation de 1996, une inscription préalable, les vérifications par carte bancaire ou l’entretien de fichiers de codes auraient ajouté une importante charge administrative ; il ne s’agissait pas de coûts mesurés par une étude comparative (§ 3.1).

Les copies passaient sous d’autres décisions

Pour USENET, Bradner décrivait des messages copiés et conservés sur des serveurs indépendants. Chaque gestionnaire choisissait les groupes reçus et réglait l’accès local. Un nouveau serveur pouvait rejoindre la diffusion par accord avec un voisin, sans solliciter les auteurs des messages. Dans cette organisation, l’émetteur ne pouvait imposer sa décision à chaque détenteur d’une copie. La perte de maîtrise à l’origine ne signifiait pas absence de décisions : celles-ci se poursuivaient ailleurs (§ 3.2.2).

La discussion en direct sur IRC présentait, dans son analyse, une autre difficulté : des participants sous pseudonyme entraient et sortaient de conversations relayées entre serveurs. Bradner estimait en 1996 que les vérifications répétées perturberaient les échanges. Il précisait toutefois n’avoir jamais personnellement exploité de serveur IRC. Son propos relevait donc d’une appréciation technique déclarée, pas d’une enquête de déploiement qu’il aurait menée (§ 3.2.3).

L’exception du Web était bien réelle, mais locale

Pour FTP et Gopher, Bradner invoquait les limites des logiciels alors disponibles pour la consultation anonyme. Les comptes FTP individuels lui paraissaient entraîner une charge d’administration incompatible avec une large ouverture. Cette appréciation de 1996 concernait les moyens qu’il décrivait, non toutes les réalisations futures de ces protocoles (§§ 4.1–4.2).

Le Web introduisait une exception essentielle. Sur certains sites, un formulaire pouvait transmettre des renseignements à un programme CGI ; selon le résultat, le serveur accordait ou refusait l’accès à une page. L’exploitant disposait donc d’un contrôle à l’origine. Mais autoriser un compte ou une connexion ne prouvait pas, à soi seul, qui se trouvait devant un terminal partagé. Bradner jugeait en 1996 l’entretien du dispositif exigeant en travail. Il rapportait aussi des restrictions imposées par certains hébergeurs à l’utilisation de CGI, en précisant tenir cette information de tiers (§ 4.3).

Son exemple d’un cache de l’autre côté de l’Atlantique décrivait une seconde consultation servie depuis une copie, sans nouvelle demande au site d’origine. C’était une illustration du mécanisme, non un déploiement identifié. Le contrôle de la première remise ne se prolongeait pas automatiquement jusqu’à cette lecture. De même, les accès aux fichiers comptabilisés par un serveur ne constituaient ni un décompte certain des personnes ni une preuve de leur âge (§ 4.3).

Les contrôles évoqués ensuite intervenaient ailleurs : filtrage à l’entrée d’un établissement, blocage par le logiciel de l’utilisateur, étiquetage des contenus. Bradner privilégiait en 1996 les contrôles du côté de l’utilisateur, sans fournir d’essai comparatif ni démontrer une efficacité générale. Une étiquette descriptive ne garantissait pas que chaque logiciel de réception soit configuré pour l’appliquer ; consulter volontairement un contenu n’attestait pas davantage la majorité du lecteur (§§ 5–6).

Le texte s’achevait sur une infrastructure mondiale sécurisée capable d’établir l’âge des destinataires, dont Bradner plaçait la conception hors de son propos : il ne la construisait ni ne la démontrait. Ses objections de 1996 ne prouvaient donc pas une impossibilité permanente. Elles n’effaçaient ni les responsabilités locales ni la question distincte des obligations juridiques. Le problème documenté demeurait le décalage entre les informations disponibles au premier transfert et une exigence concernant les lecteurs ultérieurs (§ 8).

Sources

Le texte intégral du RFC 2057 et sa version HTML présentent le même document. La notice du RFC Editor et la fiche documentaire de l’IETF en précisent l’identité et le statut ; ces quatre accès ne constituent pas quatre témoignages indépendants.