Loi Renseignement : imbroglio sur le statut de l’URL

La Commission nationale de contrôle des techniques du renseignement (CNCTR) a rendu public son avis sur le projet de décret relatif aux techniques du renseignement. Un point central y a été abordé : la question des URL. Est-ce une donnée de connexion ou de contenu ?

Ce décret publié fin janvier est fondamental : il définit la liste des données de connexion que peuvent aspirer les renseignements, soit les 6 services dit du premier cercle (DGSI, DGSE, DPSD, DRM, DRNE et TRACFIN), la longue liste de ceux du second cercle et bientôt, peut-être, l’administration pénitentiaire.

En pratique, donc, qu’est-ce qu’une donnée de connexion ? Habituellement, on définit sous l’expression l’ensemble des données de contenant, jamais celles du contenu. Pour la téléphonie, c'était clair : un numéro de téléphone, des appelants, des appelés, une heure, étaient des données de connexion. Internet a cependant fait sauter ce modèle rendant du coup nécessaire une définition solide puisque de ce statut, dépend la technique de recueil.

La loi sur le renseignement permet en effet le déploiement d’outils d’aspiration d’ampleur des données de connexion, tout en exigeant un formalisme plus rigoureux lorsqu’il s’agit d’effeuiller correspondances, échanges téléphoniques et autres vidéos.

L’éclairage du Conseil constitutionnel

Pour aider à y voir plus clair, le Conseil constitutionnel avait donné quelques éclairages à l’occasion d’une question prioritaire de constitutionnalité posée par la Quadrature du Net, FDN et FFDN. Il faut dire que les trois requérantes n’étaient que peu satisfaites du Code de la sécurité intérieure.

La loi sur la confiance dans l'économie numérique et le Code des postes et des télécommunications résument en effet l’expression de « données de connexion » par l’appellation vague d’« informations et documents ». Pour la valider, le juge s’est spécialement focalisé sur le point VI de l'article L. 34-1 du Code des postes et des communications électroniques : ces données techniques, conservées et traitées par les opérateurs « portent exclusivement » sur l'identification des personnes utilisatrices des services, sur les caractéristiques techniques des communications et sur la localisation des équipements terminaux (log de connexion). Elles ne visent donc jamais « le contenu des correspondances échangées ou des informations consultées, sous quelque forme que ce soit, dans le cadre de ces communications. »

Dans leur décision, les sages de la rue de Montpensier ont dès lors asséné que « le législateur a suffisamment défini les données de connexion, qui ne peuvent porter sur le contenu de correspondances ou les informations consultées ».

À sa lecture, Benjamin Bayart (FDN) nous faisait alors part de sa satisfaction : « le juge constitutionnel rappelle ce que sont les informations et documents et qu’il ne peut y avoir dans le lot des contenus ni des informations consultées ». Conclusion ? « Pour moi, quand le ministre nous explique qu’on va surveiller ceux qui regardent des vidéos de décapitation, il se met le doigt dans l’œil jusqu’au coude ». Est-ce si sûr en pratique ?

Le décret de janvier 2016 sur les données de connexion

Ce décret du 14 janvier 2016 a rendu applicable le recueil automatisé des données de connexion : il a dressé dans le dur la liste de ces fameuses données de connexion, en interdisant bien entendu toute entorse à la jurisprudence constitutionnelle. 

Seulement, l’incertitude demeure au regard du statut de l’URL : est-elle donnée de contenu ou de contenant ? Répétons-le : dans le premier cas, la horde des services de renseignement ne peut la découvrir qu’en passant par l’interception de la communication (à supposer qu'elle ne soit pas tunnelisée), soit du chirurgical, avec un protocole opérationnel serré. Dans le second cas, c’est le chalutage à partir d’outils automatisés qui s’ouvrent à eux.

Sur ce point, le texte interdit logiquement aux services d’aspirer le « contenu des correspondances échangées ou des informations consultées », mais ils peuvent librement traiter les données qui sont notamment « relatives à l'acheminement des communications électroniques par les réseaux ». On n’est donc guère avancé.

La CNIL et l’anonymisation des URL

Dans son avis sur l’ébauche de ce texte, révélé dans nos colonnes, la CNIL a considéré que l’URL est « porteuse par nature des informations consultées ». Elle a donc une nature mixte puisque « si elle est nécessaire à l’acheminement d’une communication, l’URL permet également de révéler des informations consultées. ». Et puisque le Conseil constitutionnel nous dit que les données de connexion ne portent pas sur ces « informations consultées », le principe doit être clair pour tout le monde : la CNIL refuse que les URL tombent dans le champ des données de connexion.

Sauf que la CNIL tolère aussi la conservation des URL par les opérateurs, au-delà « du temps nécessaire à l’acheminement de la communication » mais à la stricte condition qu’ « une mesure d’anonymisation [soit] mise en œuvre. »

Le cheminement des URL dans l’avis de la CNCTR

Une mesure d’anonymisation d’URL ? Vendredi, au Journal officiel, la CNCTR a fait publier son avis sur le même projet de décret. Elle y partage l’analyse de la CNIL à savoir que les URL sont « comme des données mixtes, qui peuvent comporter à la fois des données de connexion et des mots faisant référence au contenu de correspondances échangées ou d'informations consultées ». Du coup, pas de doute : « le recueil de ces données dans le cadre des accès administratifs aux données de connexion ne saurait permettre de recueillir un tel contenu ».

Elle apporte ces briques supplémentaires au débat : « le recueil ne peut avoir pour objet que de reconstituer, grâce aux seules parties d'URL pertinentes, le chemin informatique utilisé pour échanger des correspondances ou consulter des informations ».

On doit comprendre que lorsque l’URL est la dernière porte avant d'accéder véritablement à l'information, elle peut être traitée par les services du renseignement au titre des données de connexion, mais pas lorsque la porte s'ouvre sur le contenu. Les différents outils du renseignement ne peuvent donc aspirer ces URL « que si une analyse approfondie (…) permet, en l'état des possibilités techniques, d'en éliminer le contenu des communications. Ainsi, en ce qui concerne les URL, seuls les éléments qui déterminent le chemin utilisé pour échanger des correspondances ou consulter des informations peuvent être recueillis, les autres éléments devant être éliminés. C'est à cette condition que la CNCTR admet le recueil d'URL dans le cadre d'accès administratifs aux données de connexion ».

Voilà donc comment s'anonymise une URL… Ce qui permet de déboucher sur une situation cocasse où l’Uniform Resource Locator (URL) peut ne pas être une donnée de localisation du contenu, alors que c'est sa fonction première.

« C’est n’importe quoi »

Contacté, Stéphane Bortzmeyer, ingénieur, juge que l’approche est pour le moins cavalière. « Dire qu’une URL est une donnée de connexion, c’est n’importe quoi. Prenez celles de Next INpact où on y trouve déjà le titre. Même un nom de domaine est une information très précise sur ce que l’on consulte : http://www.lutte-ouvriere.org/ donne des informations tout aussi précises sur l’engagement de l’internaute. Un nom de domaine relatif aux alcooliques anonymes peut aussi être révélateur de ce sur ce que l’on est. L’exemple est d’ailleurs cité dans le RFC 7626 sur les DNS Privacy Considerations : un nom de domaine est en lui-même une information qu’on peut avoir de bonne raison de garder privée ». Autre rappel : « N’oublions pas en outre qu’il y a des sites réduits à une seule page. »

La CNCTR n’a pas visé les Request for comments (RFC), les bonnes pratiques de l'industrie, mais le modèle défini par l'Union internationale des télécommunications (UIT) dans sa recommandation X.200 portant sur l'interconnexion de systèmes ouverts. L’avis de l’ingénieur en R&D est du coup rugueux : « les gens qui font ce genre d’avis ne connaissent que les GAFA, un modèle très proche de la téléphonie, sans avoir idée qu’il y a d’autres modes d’utilisation du réseau comme celui d’avoir son propre domaine. Si on écrit à rees.fr, on a une requête qui indique plus précisément à qui on communique. »

Mais est-ce que les requêtes DNS sont en elle-même des données personnelles au sens de la loi informatique et libertés ? « Cela dépend. Sur Gmail.com, elles ne sont pas révélatrices, pas plus que sur Google Analytics. D’autres sur Bortzmeyer.org, LaQuadrature.net, Alcooliques-Anonymes.fr, etc. sont beaucoup plus spécifiques. Les réseaux ne fonctionnent pas comme le laisse entendre l’avis de la CNCTR. Dans le monde du mobile, les opérateurs interfèrent pas mal avec les communications (proxys HTTP transparents, par exemple). En outre, tous les opérateurs (mobile ou pas) gèrent des résolveurs DNS. »

Au regard de ces flous persistants, on en vient du coup à la conclusion intermédiaire que s’il s’agit effectivement de ne garder que le nom de domaine, soit cela ne servira à rien (Gmail.com), soit cela restera intrusif (Alcooliques-Anonymes.fr)…

Une donnée non pertinente pour les réseaux

Selon Alexandre Archambault, techniquement parlant, l’URL n’a d’importance que dans la couche périphérique d'Internet, au niveau du navigateur et du serveur. « En principe, un réseau de FAI ne voit pas passer l’URL qui est du ressort de la couche logique, non de la couche physique. Prenons l'exemple d'un contenu qui fâche les pouvoirs publics, tel que http://www.facebook.com/mechant_djihadiste.  Pour obtenir le contenu recherché, le navigateur va devoir envoyer une requête HTTP à un serveur web dont il ne connait pas l'IP. Pour cela, il doit interroger un service, qui s'appelle le DNS, une sorte de gigantesque annuaire permettant d'obtenir l'adresse IP d'un serveur Internet. Le DNS ne se souciant nullement de la partie contenu, dont l'architecture est du ressort exclusif du fournisseur de contenu, le navigateur va donc découper l'URL pour ne retenir que la partie pertinente, ici www.facebook.com, et la soumettre au DNS. Le DNS renvoie alors l'adresse IP vers laquelle le navigateur doit aller adresser sa requête pour obtenir le contenu associé à l'URL demandée l'utilisateur final. Vu de l'opérateur, nous avons donc deux requêtes. »

Deux requêtes ? L'ancien responsable des affaires réglementaires chez Iliad/Free nous détaille l'alternative : « Une requête vers le DNS et dans laquelle l'URL telle que renseignée dans le navigateur par l'abonné n'apparait pas. Une autre vers le serveur Internet, prenant dans notre cas présent la forme de paquets Internet vers l'adresse IP telle que retournée par le DNS. Or ici l'URL n'est pas présente dans les entêtes des paquets TCP (ie vues en clair, et traitées par les routeurs du FAI et prestataires Internet traversés), elle est encapsulée dans le contenu de la communication. Dit autrement, vu du réseau, il s'agit d'une donnée de contenu, non pertinente pour l'acheminement de la communication qui lui s'effectue sur la base des adresses IP.  En outre, n’oublions pas la popularité des Content Delivery Networks (CDN) qui peuvent être amenés à traiter les requêtes de livraison de contenus pour le compte de Facebook ou d'autres, de façon totalement transparente pour l'utilisateur final qui lui aura tapé ou cliqué sur http://www.facebook.com/mechant_djhihadiste. »

« Le problème de ce type d’avis est qu’il procède d’un usage un peu trop prétorien ». Le même admet néanmoins que ce type de requête peut trouver une utilité sur un réseau « proxyfié », dans le cadre de l’intranet d’une entreprise par exemple, ou à la rigueur via la boite noire programmée par la loi Renseignement et celle sur la surveillance des communications internationales qui vont pouvoir ouvrir les paquets Internet pour extraire les URL. Seulement, « sur les réseaux de nouvelles générations, on ne voit pas l’URL. Ce n’est pas une donnée pertinente contrairement à l’IP. De plus, la tendance est au HTTPS, où la partie après le nom de domaine navigue chiffrée dans les paquets. »

Sèche conclusion là encore : « tout ceci repose sur une approche biaisée : on part du haut, les besoins des services, sans se caler avec la réalité de l'exploitation des réseaux, source des données recherchées et traitées par les services de renseignement. Internet n’est pas un monopole d’État. Guidés par le principe de liberté de l’industrie, les opérateurs et les FAI se calent sur les standards pour considérer que le routage se fait sur l'IP principalement, ainsi que pour les couches basses du réseau directement sur l'AS (Système Autonome, un ensemble de réseaux IP partageant une même politique de routage cohérente) et même OSPF (open shortest path first) pour les grosses interconnexions. »

La directive Vie privée et Communication électronique

Contacté également, l’avocat Hugo Roy estime que la notion de données techniques de l'article L. 34-1 doit nécessairement s'analyser à la lumière de la directive 2002/58. « Tout le problème est dans l'articulation de cette directive et accessoirement, la Charte des droits fondamentaux de l'UE telle qu'appliquée par la CJUE, avec la loi française ».

Pourquoi ? Le juriste qui s'occupe de l'association French Data Network nous rappelle que « l'article 5 et l'article 6 de la directive 2002/58 prévoient d’une part que le contenu de la communication ne peut pas être écouté, intercepté ou stocké par le FAI. D’autre part, que les données relatives au trafic doivent être effacées ou rendues anonymes lorsqu'elles ne sont plus nécessaires à la transmission d'une communication. Ce principe connaît une dérogation, prévue à l'article 15 de la directive (qui doit se faire dans les limites du contrôle fixé par la CJUE pour ne pas constituer une ingérence disproportionnée). En somme pour déterminer les obligations applicables du point de vue du FAI, il faut déterminer le statut de l'URL: soit l'URL relève du contenu de la communication soit l'URL est une donnée relative au trafic ».

De deux choses l’une, là encore : « si l'URL est une donnée relative au trafic alors il faut que l'article L. 34-1 prévoie bien que le FAI doive conserver cette donnée (sinon, le FAI serait en violation de son obligation d'effacer ou rendre anonyme). Or, ce n'est pas prévu ni au niveau de la loi ni au niveau du décret (art. R10-13 CPCE). L'URL par conséquent ne peut pas être entendue comme une donnée conservée et traitée au sens du VI de l'article L34-1 CPCE (visé par le Conseil constitutionnel dans sa décision 2015-478 QPC). Si l'URL relève du contenu de la communication alors il faut que le FAI soit légalement autorisé à écouter, intercepter ou stocker cette URL. Or, rien ne le prévoit. Par conséquent, on voit mal au nom de quoi un service de renseignement pourrait accéder à des URL auprès des FAI, puisque les URL ne sont pas une donnée relative au trafic du point de vue du FAI et quand bien même elles le seraient, la loi prévoit que les FAI doivent les rendre anonymes puisque l'article R10-13 CPCE ne les vise pas. »

Réagissant à la délibération CNIL, le même juriste estime que c’est « se méprendre dès l'origine sur le fait que l'URL est une donnée nécessaire à l'acheminement de la communication ! La CNIL nous dit qu’au-delà du temps nécessaire à l'acheminement de la communication, l'URL doit être anonymisée. Mais ce temps est égal à zéro puisque l'URL n'est pas nécessaire à l'acheminement de la communication par le FAI. »

La prudence de l’ARCEP, les éclairages complémentaires de la CNCTR

Dans son avis sur le même projet de décret, l’ARCEP avait elle aussi souligné qu’il « pourrait être délicat pour les opérateurs de communications électroniques, de déterminer de manière suffisamment certaine, parmi les catégories d’informations ou de documents (…) celles qui sont couvertes par le secret des correspondances ou portent sur des informations consultées ».

Elle avait demandé à ce que ces incertitudes soient levées, invitant le gouvernement « à définir précisément la nature des informations ou documents en cause »…

Les interrogations actuelles sur le décret de fin janvier montrent que ce travail explicatif reste toujours à faire. Contactée, la CNCTR a bien voulu nous apporter un petit complément : de son point de vue, une URL considérée comme donnée de connexion « peut aller au-delà du slash, mais doit s’arrêter aux données de contenu. »

Face aux exemples de Stéphane Bortzmeyer, elle ajoute que surfer sur le site de L.O., ou des alcooliques anonymes n’est pas automatiquement révélateur d’un engagement politique ou d’une addiction quelconque. Face à cela, l'ingénieur rappelle la logique de Nicolas Sarkozy pour qui, si on consulte un site web djihadiste, on est djihadiste. De même, « à ce compte-là, autant autoriser des caméras à l'entrée des sex-shops gays "le fait d'aller dans un lieu gay ne signifie pas forcément qu'on est gay". »

Quoi qu'il en soit, la CNCTR refuse de nous en dire plus, considérant avoir été au bout de ses explications dans son avis. « On a donné le maximum de lignes directrices. C’est maintenant aux différents services de nous présenter des demandes conformes à ce document. »

L’exemplaire exemple anglais

Si on résume, les outils du renseignement français pourront théoriquement aller bien au-delà de l’url http://www.nombiduletrucmachin.fr/ tout en respectant les vœux du Conseil constitutionnel et des autorités indépendantes. Si les services peuvent collecter au-delà du slash, il n'est pas dit exactement à quel endroit ils doivent s'arrêter. Une variable (par exemple http://www.google.fr/search?q=variable) est-elle considérée comme une donnée de connexion ou de contenu ?

En pratique, la récupération de ces informations ne sera pas si simple, les opérateurs considérant ces données comme non pertinentes. Bien entendu, toute cette cuisine interne étant couverte par le secret, il est à craindre que le Conseil d’État ne puisse que très tardivement intervenir sur ce champ…

Enfin, sans pouvoir aujourd’hui dire exactement ce que pourront faire les services du renseignement français, difficile de ne pas comparer la situation avec le travail parlementaire mené actuellement outre-Manche.

En plein débat sur l’Investigatory Powers Bill (PDF), une commission a déjà épinglé plusieurs dispositions relatives aux données de connexion, dont la définition a été jugée « pas claire, inutile et récursive » (point 76). La même commission a donc appelé le gouvernement à proposer « une définition limpide et compréhensive des données, une fois le projet de loi présenté ». Elle a surtout jugé que la distinction actuelle entre donnée de contenu et donnée de contenant était désuète, l’une et l’autre organisant une intrusion non pas moindre, mais différente dans la vie privée (points 56 et 57).