Exposé d’une difficulté conceptuelle qui gênerait gravement la mise en place d’un système de surveillance automatisée des contenus : la dépendance des moyens de surveillance automatisée sur une coopération minimale des créateurs de contenus.
Introduction
Le rapporteur de la Loi sur la Confiance dans l’Économie Numérique (LcEN), Jean Dionnis du Séjour, a indiqué à plusieurs reprises, devant les parlementaires et dans les média, que les systèmes de reconnaissance textuelle sont au point, et que leur taux de "réussite" les rend apte à permettre l’application pratique d’une obligation de surveillance par les hébergeurs des contenus hébergés. Il a cité un certain nombre de fournisseurs d’outils aptes, selon lui, à opérer cette surveillance de manière satisfaisante.
En dehors de leur coût prohibitif (ces solutions commencent chez Verity à une centaine de milliers d’euros), une limite conceptuelle mine l’utilité de ces outils pour le but recherché : ils reposent sur la coopération du créateur du contenu à l’effort de reconnaissance. En effet, des manipulations triviales des contenus peuvent rendre un texte inaccessible et strictement incompréhensible pour un programme informatique, sans en gêner significativement l’accès ou la compréhension par des visiteurs.
Contenus "en clair"
Un contenu hébergé sur un site web est accessible à l’hébergeur de deux manières :
- accès par le web : visualisation des pages via un fureteur ou outil équivalent, dans des conditions similaires à celles des visiteurs (via un robot visitant des sites web de manière autonome ou au moyen d’un filtre installé par le fournisseur d’accès analysant les pages consultées par ses clients internautes)
- accès aux fichiers : consultation des fichiers stockés sur les disques des serveurs (au moyen d’un robot de consultation des fichiers géré par le fournisseur d’hébergement ; cette méthode couvre l’accès direct au contenu stocké dans des bases de données)
Dans le premier cas, on a accès aux contenus dans leur contexte de publication, mais on est limité par toute restriction d’accès mise en place par le créateur (identification HTTP avec mot de passe par exemple).
Dans le second cas, on dispose de tous les contenus effectivement hébergés, mais on peut perdre le contexte, voire le sens même, selon l’organisation technique du contenu.
On peut à la rigueur admettre l’idée que des contenus accessibles au public le sont aussi, sans distorsion, aux systèmes de recherche de contenus automatisés, par exemple au moyen d’outils du type de ceux utilisés par les moteurs de recherche, les "robots d’indexation", qui pourront accéder aux contenus tant de manière externe (via le serveur web) qu’interne (via le système de fichiers).
Un contenu mis en ligne "en clair" est susceptible d’être surveillé par des outils autonomes. La publication sous cette forme de contenus litigieux peut donc provoquer une réaction automatique (envoi d’un message à un responsable pour vérification manuelle par exemple).
Contenus inaccessibles
Toutefois, dans certains cas, un contenu ne sera pas accessible à de tels outils opérant de manière externe. Il peut s’agir de choix techniques particuliers, la mauvaise volonté de la personne publiant le contenu n’étant pas forcément en cause.
Exemple 1 : accès à du contenu via un lien construit en JavaScript.
Au lieu de construire un lien en indiquant simplement l’URL de la page cible dans une balise de lien, on peut utiliser un bout de script ayant le même effet qu’un lien, mais agissant différemment. Au lieu d’un lien classique ainsi codé :
<a href="page.html">Lien vers la page</a>
… on indique le code suivant :
<a href="JavaScript:location('page.html')">Lien vers la page</a>
Les robots d’indexation ne savent pas interpréter le JavaScript, pour diverses raisons conceptuelles et indépassables (notamment le fait que le JavaScript peut engendrer une infinité d’états du contenu, dont aucun ne pourrait être reconnu comme final par une machine). Un lien tel qu’indiqué ci-dessus ne permettrait donc pas à un robot d’indexation travaillant à travers le serveur web de trouver la page "page.html", bien que son accès soit tout à fait transparent et évident pour les utilisateurs de l’immense majorité des fureteurs grand public.
Sans mauvaise intention, un tel lien pourrait être utilisé sur un site utilisant des cadres (frames), pour modifier le contenu de deux cadres à la fois, ou simplement suite à un mauvais choix ergonomique. Exemple : les produits du catalogue en ligne de la CAMIF ne figurent pas dans les bases de Google, car les liens vers les pages du catalogue utilisent le JavaScript, ces pages étant toutefois accessibles aux visiteurs du site dans difficulté particulière.
Exemple 2 : accès à du contenu via un formulaire HTML.
Au lieu de construire un lien en indiquant simplement l’URL de la page cible dans une balise de lien, on peut utiliser un formulaire HTML ayant le même effet qu’un lien, mais s’affichant d’une façon différente. Au lieu d’un lien ainsi indiqué :
<a href="page.html">Lien vers la page</a>
… on indique le code suivant, pour obtenir un bouton plutôt qu’un lien textuel :
<form action="page.html"> <input type="submit" value="Lien vers la page"> </form>
Les robots d’indexation ne savent pas interpréter les formulaires HTML, pour diverses raisons conceptuelles et indépassables (notamment le fait qu’il n’est fonctionnellement pas souhaitable que des formulaires puissent être utilisés par des robots). Un lien tel qu’indiqué ci-dessus ne permettrait donc pas à un robot d’indexation travaillant à travers le serveur web de trouver la page "page.html", bien que son accès soit tout à fait transparent et évident pour les utilisateurs de l’immense majorité des fureteurs grand public.
Sans mauvaise intention, un tel lien pourrait être utilisé dans le cas d’un accès payant à un contenu (nécessitant la saisie d’un identifiant et d’un mot de passe), ou simplement suite à un mauvais choix ergonomique. Exemple : les fiches pays du site du Monde ne figurent pas dans les bases de Google, car leur accès est réservé aux visiteurs identifiés via un formulaire.
Conclusion
Un robot d’indexation travaillant "en local", à travers le système de fichiers, continuerait d’accéder sans difficulté au fichier "page.html" dans les deux exemples indiqués ci-dessus.
Un contenu mis en ligne "en clair" mais non accessible par des liens standards n’est susceptible d’être surveillé par des outils autonomes que si ceux-ci travaillent à travers le système de fichiers du serveur, mais pas via le serveur web.
Contenus chiffrés
Il est par ailleurs possible de chiffrer du contenu. Cela peut se faire de manière relativement simple pour le créateur de contenu et transparente pour le visiteur.
Un encodage trivial comme le ROT13 utilisé dans les forums de discussions peut être utilisé. Il consiste en le remplacement d’une lettre par la 13ème lettre suivant dans l’alphabet. Ainsi, un A est-il remplacé par un N, un B par un O, un R par un E (en revenant au début de l’alphabet). Un encodage de ce type doit être appliqué par le créateur du contenu au moment de la mise en ligne, et le décodage doit être effectué par le visiteur. Ce décodage peut se faire de manière automatique, au moyen de mécanismes agissant au niveau du serveur ou au niveau du fureteur du visiteur.
(Cet encodage, très ancien, sert à masquer un contenu de manière simple et conventionnelle. Il est par exemple utilisé dans des forums de discussion sur le cinéma pour parler de la fin d’un film sans gâcher le plaisir des spectateurs ne l’ayant pas encore vu, et qui liraient le paragraphe en question par inadvertance. Il est pratique car l’alphabet comportant 26 lettres, la même fonction [lettre + 13] est utilisable à la fois pour le codage et le décodage.)
Exemple 1 : décodage côté serveur
Voici un fragment de code PHP permettant le codage, puis le décodage d’un contenu chiffré en ROT13 à chaque affichage de page :
<?php
$messageSecret = 'prpv rfg ha zrffntr frperg';
$lettreVersChiffre = array('a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5, 'f' => 6,
'g' => 7, 'h' => 8, 'i' => 9, 'j' => 10, 'k' => 11, 'l' => 12, 'm' => 13, 'n' => 14,
'p' => 16, 'q' => 17, 'r' => 18, 's' => 19, 't' => 20, 'o' => 15, 'u' => 21,
'v' => 22, 'w' => 23, 'x' => 24, 'y' => 25, 'z' => 26);
$alphabet = array(false, 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l',
'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z');
for ($i = 0; $i < strlen($messageSecret); $i++) {
$lettreSecrete = substr($messageSecret, $i, 1);
$chiffreSecret = $lettreVersChiffre[$lettreSecrete];
if ($chiffreSecret > 0) {
$chiffreDecode = ($chiffreSecret + 13) % 26;
$lettreDecode = $alphabet[$chiffreDecode];
} else {
$lettreDecode = $lettreSecrete;
}
$messageDecode .= $lettreDecode;
}
echo 'Message décodé : ';
echo $messageDecode;
?>
Note : dès la version 4.2.0 de PHP, il est possible d’utiliser la fonction str_rot13() pour obtenir le même résultat. L’exemple ci-dessus peut donc encore être simplifié :
<?php
$messageSecret = 'prpv rfg ha zrffntr frperg';
$messageDecode = str_rot13($messageSecret);
echo 'Message décodé : ';
echo $messageDecode;
?>
Le résultat du code ci-dessus est "Message décodé : ceci est un message secret". Il est à noter que ce code peut être utilisé tant pour le codage que pour le décodage d’un texte. N’importe quelle méthode triviale de chiffrage du contenu peut être utilisée, pour peu que l’encodage et le décodage soient simples.
Les visiteurs et les robots d’indexation opérant via le serveur web reçoivent ainsi le contenu en clair. Celui-ci peut donc être surveillé depuis l’extérieur. Un outil de surveillance accédant au contenu via le système de fichiers sera en revanche incapable de l’indexer, car il est stocké de manière illisible (ici, "prpv rfg ha zrffntr frperg" qui n’a aucun sens).
Exemple 2 : décodage côté client
À défaut d’effectuer le décodage sur le serveur, on peut aussi le faire effectuer par le fureteur du visiteur. Voici la transposition (un peu fastidieuse) du code ci-dessus en JavaScript pour interprétation sur la machine du visiteur :
<html>
<body>
<script language="JavaScript">
messageSecret = 'prpv rfg ha zrffntr frperg';
lettreVersChiffre = new Array();
lettreVersChiffre['a'] = 1;
lettreVersChiffre['b'] = 2;
lettreVersChiffre['c'] = 3;
lettreVersChiffre['d'] = 4;
lettreVersChiffre['e'] = 5;
lettreVersChiffre['f'] = 6;
lettreVersChiffre['g'] = 7;
lettreVersChiffre['h'] = 8;
lettreVersChiffre['i'] = 9;
lettreVersChiffre['j'] = 10;
lettreVersChiffre['k'] = 11;
lettreVersChiffre['l'] = 12;
lettreVersChiffre['m'] = 13;
lettreVersChiffre['n'] = 14;
lettreVersChiffre['o'] = 15;
lettreVersChiffre['p'] = 16;
lettreVersChiffre['q'] = 17;
lettreVersChiffre['r'] = 18;
lettreVersChiffre['s'] = 19;
lettreVersChiffre['t'] = 20;
lettreVersChiffre['u'] = 21;
lettreVersChiffre['v'] = 22;
lettreVersChiffre['w'] = 23;
lettreVersChiffre['x'] = 24;
lettreVersChiffre['y'] = 25;
lettreVersChiffre['z'] = 26;
alphabet = new Array(false, 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z');
messageDecode = '';
for(i=0;i<messageSecret.length;i++) {
lettreSecrete = messageSecret.substr(i, 1);
chiffreSecret = lettreVersChiffre[lettreSecrete]; if (chiffreSecret > 0) {
chiffreDecode = (chiffreSecret + 13) % 26; lettreDecode = alphabet[chiffreDecode]; } else { lettreDecode = lettreSecrete; }
messageDecode += lettreDecode;
}
document.write('Message décodé : ');
document.write(messageDecode);
</script>
</body>
</html>
Avec tout fureteur équipé de JavaScript, le visiteur verra le même contenu en clair qu’à l’exemple précédent : "Message décodé : ceci est un message secret". En revanche, aucun outil de surveillance automatisée ne pourra recevoir le contenu en clair, ni dans le cadre d’un accès via le système de fichiers (puisque que contenu n’est pas stocké en clair), ni dans le cadre d’un accès via le web (puisqu’en général, les robots n’interprêtent pas le JavaScript), ni même dans le cadre encore plus hypothétique d’un filtrage au niveau du fournisseur d’accès (puisque le contenu reste chiffré jusqu’au fureteur du visiteur). Voir cet exemple mis en pratique.
Conclusion
Un chiffrage trivial du contenu publié sur internet est peu pratique, et risque d’avoir des effets non souhaités (impossibiliter de trouver le site en question au moyen des moteurs de recherche par exemple) que la plupart des créateurs de contenus jugeront inacceptables. Toutefois, cela montre bien qu’un internaute souhaitant à tout prix éviter que le contenu qu’il publie soit "remarqué" par des outils de recherche automatisés peut le faire de manière très simple.
Conclusion générale
Ces exemples très simples montrent qu’avant même que soit mis en place un un système de surveillance automatisée, il existe des moyens de le circonvenir. D’une certaine façon, c’est heureux : cela montre que le comportement des ordinateurs est encore très loin de ressembler à l’intelligence et la compréhension humaines. Mais une modification mineure d’un système de publication web au moyen de techniques similaires à celles indiquées ci-dessus peut rendre le stockage et l’affichage de contenu chiffré tout à fait transparent non seulement pour le visiteur, mais aussi pour le créateur de contenu.
Dans l’ensemble, tout système de surveillance automatique est appelé à échouer, car l’automatisme est fondé sur un certain nombre de règles. Notre nature humaine fait que nous sommes aptes à imaginer des manières de contourner ces règles. La course entre les règles et les moyens de les contourner peut tourner à l’avantage de l’une ou de l’autre partie, mais en général, plus les règles sont compliquées et dépendent de systèmes sophistiqués, plus elles sont faciles à contourner.
Cet exposé ne tient pas compte des difficultés rencontrées par les outils eux-mêmes, que l’on peut supposer énormes à l’heure actuelle (risques élevés de "faux positifs" et "faux négatifs"), car les notions litigieuses sont complexes et les outils informatiques très peu adaptés à la compréhension de contenus. Il n’entre pas non plus dans les ambitions de ce document de s’élever (comme il convient de le faire) contre l’idée que la surveillance automatique d’activités humaines puisse avoir le moindre aspect positif et être le moins du monde souhaitable.
Le seul objectif était de montrer, exemples à l’appui, que si les éditeurs de contenus illégaux cherchent activement à éviter la détection, ils y arriveront très facilement. C’est une des nombreuses raisons pour lesquelles une éventuelle obligation de surveillance a priori par les fournisseurs d’accès à internet ou d’hébergement est conceptuellement vouée à l’échec.
À propos de ce document
Cet exposé a été préparé par Raphaël Mazoyer, membre du conseil d’administration d’Ouvaton, société anonyme coopérative d’hébergement de sites internet, et co-fondateur de Splandigo, une agence web basée à Amsterdam. Projet lancé en 1999, Ouvaton a ouvert ses services en 2000 et est fort, en avril 2004, de plus de 2400 clients coopérateurs, qui hébergent environ 4500 sites web. Pour plus d’informations, vous pouvez contacter Ouvaton à l’adresse coordination@ouvaton.net.
Document créé le 2 avril 2004, dernière mise à jour le 5 avril 2004.