La LCEN a enfin son décret d'application... et déjà critiqué

Sept ans après la promulgation de la Loi pour la Confiance dans l’Economie Numérique (LCEN), le Gouvernement a publié le 1er mars 2O11 le décret relatif à la conservation des données. Ce décret, très attendu, établit la durée de rétention et la liste des données qui doivent être conservées par les fournisseurs d’accès à Internet (FAI), les hébergeurs et les éditeurs de service, l’objectif étant de “permettre d’identifier toute personne ayant contribué à la création d’un contenu mis en ligne”.

Pourquoi tout ce temps ?

J’avoue ne pas comprendre comment il peut se passer sept ans entre la promulgation de la loi et la publication au Journal Officiel d’un décret indispensable pour son application. Il s’est passé 3 ans entre la promulgation de la loi (21 juin 2004) et la demande d’avis à la CNIL et à l’ARCEP (24 septembre 2007). La CNIL a répondu le 20 décembre 2007. L’ARCEP a répondu le 13 mars 2008… Puis encore 3 ans avant ce décret du 25 février 2011.

Lenteur des ministères, priorités politiques qui changent au gré du vent ? Je ne sais pas quelle est la raison de cette lenteur. Une chose est sûre : ce n’est pas le travail de ré-écriture suite aux avis de la CNIL et de l’ARCEP qui aura pris du temps ! Le décret a été très peu modifié entre ses versions 2007 et 2011. Les demandes de clarification et les interrogations de l’ARCEP n’ont malheureusement pas trouvé d’écho dans la version remaniée.

Les données à conserver

Les fournisseurs d’accès à Internet doivent conserver pendant un an :

L’identifiant de la connexion ;
L’identifiant attribué par ces personnes à l’abonné ;
L’identifiant du terminal utilisé pour la connexion lorsqu’elles y ont accès ;
Les dates et heure de début et de fin de la connexion ;
Les caractéristiques de la ligne de l’abonné ;

Les hébergeurs et éditeurs de services doivent conserver pendant un an pour chaque opération de création, de modification et de suppression de contenu :

L’identifiant de la connexion à l’origine de la communication ;
L’identifiant attribué par le système d’information au contenu, objet de l’opération ;
Les types de protocoles utilisés pour la connexion au service et pour le transfert des contenus ;
La nature de l’opération ;
Les date et heure de l’opération ;
L’identifiant utilisé par l’auteur de l’opération lorsque celui-ci l’a fourni ;

Les FAI, les hébergeurs et les éditeurs de services doivent conserver les informations fournies lors de la création d’un compte pendant un an après la suppression du compte :

Au moment de la création du compte, l’identifiant de cette connexion ;
Les nom et prénom ou la raison sociale ;
Les adresses postales associées ;
Les pseudonymes utilisés ;
Les adresses de courrier électronique ou de compte associées ;
Les numéros de téléphone ;
Le mot de passe ainsi que les données permettant de le vérifier ou de le modifier, dans leur dernière version mise à jour ;

Enfin, si le service est payant, les informations suivantes relatives au paiement doivent être conservées pour chaque opération de paiement pendant un an :

Le type de paiement utilisé ;
La référence du paiement ;
Le montant ;
La date et l’heure de la transaction.

Les données mentionnées aux 3° et 4° ne doivent être conservées que dans la mesure où les personnes les collectent habituellement.

A peine publié, déjà critiqué

Le décret fait déjà l’objet de critiques, aussi bien de la part des professionnels du secteur que des ONG ou des particuliers sensibles à l’extension du champ de la surveillance. Cinq grandes catégories de critiques se dégagent :

sur l’étendue des données à conserver
sur la nature des données à conserver
sur l’ambiguïté de rédaction du décret
sur l’application immédiate
sur le coût financier

L’étendue des données à conserver

Sur l’étendue des données à conserver, la définition est très large puisqu’elle inclut toutes les créations, modifications et suppressions de contenu. Avec une définition aussi large, si je clique le bouton “J’aime” sur Facebook, je crée un contenu. Si deux minutes plus tard, je décide de revenir sur mon choix, Facebook devra néanmoins conserver pendant un an mon clic “J’aime” puis mon clic “Je n’aime plus”. C’est un exemple très simple, mais il montre bien l’étendue des données à conserver dans le cadre de cette définition très large de création de contenu.

L’ARCEP avait pourtant relevé dans son avis de 2007 “qu’il appartiendra aux personnes mentionnées à l’article 6-I de la loi du 21 juin 2004 de conserver une quantité exponentiellement croissante de données, ce qui risque de rendre les dispositions de ce projet de décret difficilement applicables tant pour des raisons techniques que financières." Il est dommage que le Gouvernement n’ai pas tenu compte de l’avis de l’ARCEP en précisant mieux la création de contenu.

En l’état, le texte du décret prête le flanc aux attaques. L’Association française des Services Internet communautaires (Asic), qui représente notamment Dailymotion, Google France et Facebook, “envisage de déposer un recours en annulation devant le Conseil d’Etat” (voir cet article du Point)

La nature des données à conserver

Certaines données visées par le décret n’ont pas de rapport direct avec l’identification de l’internaute. Là encore, l’avis de l’ARCEP était très clair :

“L’Autorité, au regard de la liste des données prévue par l’article 1er, ne peut que s’interroger sur la finalité de certaines d’entre elles. En effet, certaines données n’ont que peu de rapport ou même aucun avec l’identification de la personne ayant créé un contenu. Il en est ainsi notamment des données suivantes :- les caractéristiques de la ligne de l’abonné ;- la nature de l’opération ;- mot de passe ou données permettant de le vérifier ou de le modifier ;- ou encore certaines données relatives au paiement.”

L’objectif du Gouvernement est vraisemblablement de se servir du mot de passe comme d’un outil d’identification à part entière. Peu importe alors que le mot de passe soit stocké en clair ou sous la forme d’un hash SHA-1, MD5 ou autre (cf. remarque concernant l’ambiguïté du stockage du mot de passe). A défaut de permettre d’identifier avec certitude un internaute, l’usage d’un même mot de passe permettrait d’alourdir le faisceau de présomption pesant sur un suspect.

Cette approche comporte cependant des risques importants. D’abord le risque d’erreur : de la même façon qu’une IP ne permet pas d’identifier avec certitude un internaute (hello Hadopi !), un mot de passe n’est pas une preuve. Tout au plus un soupçon. Ensuite, le risque d’atteinte à la vie privée. On ne peut que s’inquiéter du périmètre toujours plus grand des données collectées sur notre vie privée. Chaque année, Big Brother gagne du terrain et rien ne semble prêt à arrêter sa course. Certainement pas la CNIL qui n’a rien trouvé à redire sur la conversation du mot de passe.

L’ambiguïté de rédaction du décret

Certaines définitions ne sont pas claires. Que signifie précisément “Le mot de passe ainsi que les données permettant de le vérifier ou de le modifier, dans leur dernière version mise à jour” ?

Tel qu’il est rédigé, le décret semble exiger la conservation du mot de passe en clair. Je n’ose pas imaginer que ce soit l’intention des rédacteurs du décret. Que signifient “les données permettant de le vérifier” ? Cela pourrait être le hash du mot de passe, mais dans ce cas, il aurait fallu un “ou” au lieu de “ainsi que” (c’est à dire demander de conserver le mot de passe ou le hash). Que signifient les “données permettant de le modifier” ? Mystère.

Numerama a également relevé un bug dans le décret dans la rédaction de l’article 3. Par le jeu des références entre articles, cet article semble imposer aux FAI de conserver les actions de création, modification et suppression de contenu de leurs abonnés. C’est tellement énorme que c’est à l’évidence une erreur de rédaction du décret. C’est un peu dommage pour un décret qui a mis sept ans à murir, non ?

L’application immédiate

Ce décret est d’application immédiate, contre l’avis de l’ARCEP (encore !). Il est évident que tous les acteurs ne peuvent pas être prêts au jour J de la publication du décret, sans avoir eu connaissance au préalable du contenu du décret. Le bon sens aurait été de laisser un an aux acteurs pour s’organiser, pour leur permettre de définir et d’implémenter leur stratégie de stockage, d’archivage, de sécurisation et de récupération des données.

Le coût financier

Des investissements seront souvent nécessaires pour être en conformité avec les exigences du décret. Je vais me répéter, mais l’ARCEP l’avait bien identifié dans son avis :

“Rien ne semble envisagé pour les frais relatifs aux investissements nécessaires pour assurer la conservation et le stockage des données.”
Puis, plus loin :
“L’Autorité, ainsi qu’elle l’a rappelé ci-dessus, tient à ce que, conformément à la décision du Conseil constitutionnel précitée, les coûts que représente pour les opérateurs et les hébergeurs le concours apporté à la sauvegarde de l’ordre public ne leur incombent pas dès lors que les dépenses qui en résultent sont étrangères à l’activité d’exploitation des réseaux et de fourniture de services.Ainsi, en ne prévoyant que pour la fourniture des données le remboursement des surcoûts identifiables et spécifiques supportés par les personnes mentionnées aux 1 et 2 du I de l’article 6 de la loi du 21 juin 2004, le projet de décret semble exclure le remboursement des investissements en matériel de stockage et les développements informatiques associés et aller à l’encontre de la décision précitée.”

Il sera intéressant de lire la position du Conseil d’Etat si l’Asic dépose un recours en annulation.

Epilogue pour SysAdmin

Il est temps de vérifier que vos serveurs sont configurés pour conserver les logs pendant un an. Si vous utilisez logrotate, la configuration par défaut sur Ubuntu pour Apache est de 52 semaines (ok !) mais seulement 7 semaines pour Pure-FTPD. Pensez à vérifier le fichier de configuration général /etc/logrotate.conf et les fichiers de configuration par application contenu dans /etc/logrotate.d/

Extrait de logrotate.conf :

# rotate log files weekly  
weekly  
# keep 52 weeks worth of backlogs  
rotate 52  
# delete logs older than 52 weeks  
maxage 52

Références