Pour remplacer mon Samsung S3, j'ai eu recours à la place de marché du Bon Coin.
Les emails transactionnels sont émis par des sociétés commerciales états-uniennes (Twilio, Adobe).
Ils contiennent des liens et des images de traçage (détecter l'ouverture ou un clic sur un lien). L'essentiel est hébergé par des entités ricaines (Amazon, Twilio, Piano AT Internet). Mêmes les images rédactionnelles (qui participent au contenu) sont diffusées via Amazon Cloudfront.
Le site web est diffusé via le CDN Coudfront d'Amazon et il incorpore plusieurs scripts JavaScript de sociétés commerciales états-uniennes et/ou qui sont hébergés par de telles sociétés : protection anti-fraude Datadome (dd.leboncoin.fr) diffusée via Amazon Cloudfront, régie pub Google Doubleclick, CMP Didomi diffusée via Amazon Cloudfront, Hubvisor diffusé via Fastly, etc.
Tout cela n'est pas conforme au RGPD. Pour les liens et images de traçage, lire ici. Pour les CDN, les scripts et les hébergeurs ricains, voir là.
Du coup, hop, réclamation déposée auprès de la CNIL il y a plusieurs mois.
Bonjour,
Le 02/01/2023, j’ai acheté sur la place de marché du Bon Coin (https://www.leboncoin.fr/).
Tout au long de l’inscription puis de l’achat, Le Bon Coin (LBC) m’a envoyé des emails sur le déroulé / suivi de ma commande, pour me présenter ses fonctionnalités, etc.
Comme l’indique leur entête « Received », certains de ces emails (« Votre code de vérification leboncoin », « Suite à votre achat sur leboncoin ») sont émis par des serveurs emails de la société commerciale états-unienne Twilio Inc., qui agit comme prestataire emailing du Bon Coin. Twilio est soumise au Cloud Act, cf. ma démonstration dans ma réclamation CNIL numéro <CENSURE>, qui est incompatible avec le RGPD. Il y a donc transfert illégal de données personnelles, a minima l’adresse emails du client LBC, vers un État tiers non adéquat sans mesures complémentaires.
D’autres emails (« Bienvenue au boncoin ! », « Achetez en ligne en toute sécurité sur leboncoin ») sont émis par des serveurs emails de la société commerciale états-unienne Adobe Inc. Il y a tout autant transfert illégal de données personnelles à une entité tout autant soumise au Cloud Act.
Des emails (« Votre code de vérification leboncoin », « Nouveau message sur leboncoin », « Bienvenue au boncoin ! », « Achetez en ligne en toute sécurité sur leboncoin », « Suite à votre achat sur leboncoin ») contiennent des liens de traçage (d’après votre terminologie https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger) contenant deux identifiants uniques, l’un permettant d’identifier la campagne, l’autre un email précis dans cette campagne. Ces liens peuvent utiliser un domaine interne (« Votre code de vérification leboncoin » = url1513.auth.leboncoin.fr, « Bienvenue au boncoin ! » et « Achetez en ligne en toute sécurité sur leboncoin » = t.news.leboncoin.fr) ou celui d’un prestataire (« Suite à votre achat sur leboncoin » = « https ://link.trustpilot.com/ls/click »).Notons que les liens de la forme « t.news.leboncoin.fr » ou « link.trustpilot.com » pointent sur des serveurs de la société commerciale états-unienne Amazon. Ceux de la forme « urlXXXX.auth.leboncoin.fr » pointent vers des serveurs informatiques de Twilio. Cela signifie que le navigateur web du client LBC qui cliquera dessus contactera ces serveurs avant d’être redirigé vers la destination finale prévue par LBC (son site web, les réseaux sociaux, etc.). Il y a donc transfert de données personnelles (adresse IP du client LBC, empreinte de son navigateur web, etc.) vers un État tiers non adéquat. Là encore, la localisation effective des serveurs importe peu : étant la propriété d’Amazon, le Cloud Act est de pleine application.
Des emails (« Votre code de vérification leboncoin », « Nouveau message sur leboncoin », « Bienvenue au boncoin ! », « Achetez en ligne en toute sécurité sur leboncoin », « Suite à votre achat sur leboncoin ») contiennent une image de traçage (1 pixel * 1 pixel, transparente, dont le nom comporte un identifiant unique) permettant de détecter et consigner l’ouverture d’un email. Ces images peuvent être hébergées sur un domaine interne (« Votre code de vérification leboncoin » = « http ://url1513.auth.leboncoin.fr/wf/open? », « Bienvenue au boncoin ! » et « Achetez en ligne en toute sécurité sur leboncoin » = t.news.leboncoin.fr) ou celui d’un prestataire (« Votre code de vérification leboncoin », « Nouveau message sur leboncoin » = « https ://logws1360.ati-host.net/hit.xiti » = la société commerciale Piano AT Internet soumise au Cloud Act, cf. ma réclamation CNIL numéro <CENSURE>).Notons que les images « urlXXXX.auth.leboncoin.fr » sont hébergées sur les serveurs informatiques de Twilio. Celles des domaines « t.news.leboncoin.fr » et « logws1360.ati-host.net » sont hébergées chez Amazon. Cela signifie qu’à l’ouverture de l’email par le client LBC, ces images seront téléchargées automatiquement. Il y a donc transfert illégal de données personnelles (adresse IP du client LBC, empreinte de son logiciel de messagerie, etc.) vers un État tiers non adéquat.
Ces liens et images de traçage ne sont pas conformes au RGPD selon le CEPD (section V de WP 118) et vous-même (https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger). LBC n’est pas soumis à une quelconque obligation légale, ni à une quelconque nécessité pour l’exécution du contrat, ni à une quelconque obligation technique de procéder à ce traçage. Le client LBC n’est pas informé et ne consent pas à ce traitement.
L’écrasante majorité des emails (« Votre code de vérification leboncoin », « Récapitulatif de votre commande […] sur leboncoin », « Nouveau message sur leboncoin », « Votre paiement a été autorisé », « Bonne nouvelle, le vendeur a confirmé la disponibilité de votre commande », « Votre colis pour la commande […] a bien été envoyé », « Confirmation de réception de votre colis pour la commande […] », « Suite à votre achat sur leboncoin ») contiennent des images rédactionnelles (des images qui participent au contenu de l’email) diffusées via le CDN Cloudfront d’Amazon. Ces images seront téléchargées automatiquement à l’ouverture de l’email. Comme pour tous les téléchargements sus-décrits, il y a donc un contact direct entre le logiciel de messagerie du client LBC et les serveurs informatiques d’Amazon, ce qui génère un transfert illégal de données personnelles (adresse IP du client LBC, empreinte de son logiciel de messagerie, etc.) vers un État tiers non adéquat.
Le site web LBC (texte, images, etc.) est lui-même diffusé via le CDN Cloudfront d’Amazon, y compris le composant d’authentification (auth.leboncoin.fr). Il incorpore plusieurs scripts JavaScript de sociétés commerciales états-uniennes et/ou qui sont hébergés par de telles sociétés : protection anti-fraude Datadome (dd.leboncoin.fr) diffusée via Amazon Cloudfront, régie pub Google Doubleclick, CMP Didomi diffusée via Amazon Cloudfront, Hubvisor diffusé via Fastly, etc.
Tous les transferts de données personnelles sus-énumérés, web et emails, sont illégaux au sens des articles 44 et suivants du RGPD (Schrems II, votre mise en demeure du 10 février 2022 portant sur Google Analytics, décision de l’APD autrichienne du 22 avril 2022 portant sur Google Analytics, etc., pour un argumentaire détaillé, je vous renvoie à mes précédentes réclamations CNIL toujours en cours de traitement). La politique de confidentialité de LBC (https://www.leboncoin.fr/dc/cookies) se contente d’affirmer que ces transferts se font à « destination des pays reconnus comme assurant un niveau adéquat de protection de vos données personnelles ou, à tout le moins, sur la base des garanties appropriées prévues par la loi »… alors que c’est au RT de mettre en œuvre des mesures complémentaires concourant à ces garanties. Bref, LBC met en œuvre aucune mesure complémentaire dans le cadre des transferts internationaux sus-décrits.
Enfin, la version texte des emails de présentation de LBC (« Bienvenue au boncoin ! », « Achetez en ligne en toute sécurité sur leboncoin ») ne contient pas de lien pour s’y opposer. L’espace perso web permet de s’opposer aux emails « nouveaux messages », mais pas à ceux-ci. Le seul moyen de s’opposer est d’utiliser les liens prévus à cet effet dans la version HTML des emails de présentation. Comme elle contient des liens et des images de traçage, cela est disproportionné.
Tout cela illustre une carence du Bon Coin dans le choix, le pilotage et l'audit de ses sous-traitants en matière de données personnelles, ce qui constitue une entorse aux articles 24 et 28 du RGPD.
Je sollicite l’intervention de la CNIL afin qu’elle mette un terme aux infractions au RGPD référencées dans la présente, et qu’elle sanctionne Le Bon Coin.Je vous rappelle l’arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a confirmé que l'exercice des droits (accès, opposition, etc.) n'est pas un pré-requis au dépôt d’une plainte auprès d'une APD en cas de violation du RGPD et qu'une APD peut donc agir même si la personne physique concernée par un traitement de données personnelles n'a pas (encore) fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
Cogitiel = logiciel monolithique de gestion des adhésions, cotisations, etc. de la CGT.
Comme les autres syndicats, la CGT est constituée de syndicats d'établissement (CGT entreprise machin, par exemple), qui adhérent à une union nationale (ex. : CGT Éduc'action) et/ou à une fédération nationale (ex. : FERC SUP) qui, elles-mêmes, adhèrent à la Confédération Générale du Travail, la fameuse CGT. Il y a également un maillage territorial, constitué par les unions départementales et locales, qui permettent de rassembler et de coordonner en fonction de la géographie plutôt que des métiers (interprofessionnel).
Le secrétaire général (président) d'une union locale m'a divulgué (à un tiers, donc) des données persos sur des adhérents d'un syndicat d'établissement, alors que ce syndicat n'est même pas dans sa zone de chalandise. Pourquoi y a-t-il accès ? Le Cogitiel n'octroie-t-il pas trop de droits ? Le RGPD impose la sécurité des données persos et leur traitement minimal et proportionné.
Du coup, hop, signalement à la CNIL il y a plusieurs mois.
Bonjour,
Fin février, je voulais entrer en contact avec le syndicat CGT d'une entité de ma ville.
De passage dans les locaux de l'Union Locale <CENSURE> (UL) de la CGT, j'ai demandé à son secrétaire général (SG) s'il connaissait personnellement des membres de ce syndicat, s'il en avait déjà croisé lors de rencontres organisées par l'UL, etc. afin de faciliter ma prise de contact.
Le SG de l'UL a alors fait une recherche dans le Cogitiel, le logiciel web de gestion des adhésions, cotisations, etc. À ma connaissance, il est maintenu par la Confédération (c'est-à-dire la CGT), que je considère donc comme étant la responsable du traitement, d'où la présente réclamation vise la Confédération et non pas l'UL <CENSURE>.
Une recherche dans le Cogitiel dépasse le cadre de ma question, c'est une sur-réaction, je demandais à un individu s'il en connaissait d'autres, rien de plus. J'ai prévenu le SG sur l'instant, mais il a continué sa recherche dans le Cogitiel.
Ensuite, le SG a tourné l'écran de son ordinateur vers moi, me divulguant les noms, prénoms, date de naissance, adresse postale, numéros de téléphone, adresse emails, statut (à jour de cotisation, etc.), etc. de tous les syndiqués du syndicat que je cherchais. Il m'a noté, sur un post-it, l'adresse emails de deux syndiqués jeunes et à jour de cotisation. Cf. PJ 1.
Cela constitue une divulgation illicite de données personnelles à un tiers en cela que je ne suis pas syndiqué à l'UL, et que son secrétaire général, qui me "connaissait" depuis peu via le mouvement social autour de la réforme 2023 des retraites, n'avait pas de preuve d'une éventuelle syndicalisation CGT de ma part, etc. De plus, l'association entre ces adresses emails et l'appartenance syndicale de leur détenteur, donnée personnelle sensible, ne semble pas être publique.
J'ai également été étonné que le secrétaire général de l'UL <CENSURE> ait accès aux données personnelles des membres d'un syndicat d'établissement qui n'est pas dans la zone géographique de chalandise de ladite UL. En effet, le syndicat recherché est national et basé à Paris, donc il n'est pas affilié / adhérent à l'UL <CENSURE>.De ce que j'en sais, le Cogitiel a une structure arborescente (les syndiqués sont rattachés à un syndicat, lui-même rattaché à plusieurs structures que sont les unions, les fédérations, etc.). Une gestion fine des droits apparaît donc comme possible (en sus d'être désirable et une obligation RGPD).
L'UL <CENSURE> me semble détenir trop de droits (de lecture, etc.) sur trop d'items (structures, fiche de syndiqués, etc.) du Cogitiel. Il s'agit d'une atteinte à la confidentialité des données personnelles des syndiqués de la CGT et au principe de minimisation : l'UL devrait avoir accès uniquement à ce qui la concerne, aux syndicats de sa zone géographique de chalandise, dans le cas présent. Le fait que ce ne soit manifestement pas le cas constitue une entorse aux articles 32, 5.1.c, et 5.1.f du RGPD.
D'une manière générale, de ce qui m'a été donné à voir, le Cogitiel est une usine à gaz monolithique développée il y a des années et dont l'utilisation (pour y saisir les membres d'un syndicat, par exemple) nécessite une formation. Le contexte humain n'aide pas : peu de personnes actives pour beaucoup de choses à faire (comme dans beaucoup d’associations), un certain jemenfoutisme de la législation, etc. Ce double contexte technique et humain laisse à penser que le Cogitiel ne garantit aujourd'hui pas la confidentialité des données personnelles des syndiqués, alors qu'il devrait justement insister sur cela afin de palier aux contextes décrits.
La présente a pour objectif d'informer la CNIL de la divulgation de données personnelles sus-relatée et de la solliciter afin qu’elle mette un terme à l'infraction au RGPD référencée dans la présente, et qu’elle sanctionne la CGT.Je vais communiquer les mêmes éléments au DPO de la CGT.
Je vous rappelle l’arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a confirmé que l'exercice des droits (accès, opposition, etc.) n'est pas un pré-requis au dépôt d’une plainte auprès d'une APD en cas de violation du RGPD et qu'une APD peut donc agir même si la personne physique concernée par un traitement de données personnelles n'a pas (encore) fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
La mairie de mon bled me propose d'accomplir une formalité administrative par emails… alors qu'elle se repose sur Microsoft Office 365. De même, elle utilise Google Analytics, une police de caractères Google Fonts, et la régie pub Google DoubleClick sur son site web.
Tout cela n'est pas conforme au RGPD (raisonnement général). Plusieurs Autorités de Protection des Données persos (APD) ont déjà sanctionné l'utilisation de Google Analytics (CNIL, 10 février 2022) et de Google Fonts (Cour régionale de Munich, 20 janvier 2022).
Du coup, hop, réclamation déposée à la CNIL il y a plusieurs mois.
Bonjour,
Le 16/03/2023, j'ai voulu déclarer la nouvelle direction d'un syndicat professionnel de salariés auprès de la mairie <CENSURE> (formalité administrative obligatoire).
Un agent de la mairie m'a indiqué que cela se fait par email auprès du directeur du service juridique de la mairie. On m'a communiqué son adresse emails professionnelle de la forme [prénom].[nom]@<CENSURE_nom_domaine_mairie>.
Avant l’envoi de mon email, je me suis rendu compte que la mairie <CENSURE> délégue son service emails à la société commerciale états-unienne Microsoft :
$ dig +short MX <CENSURE_nom_domaine_mairie>
0 <CENSURE>.mail.protection.outlook.com.J'ai prétexté un rejet de mon email par Microsoft, les agents de la mairie m'ont laissé procéder à une déclaration papier. Donc, une procédure d'évitement de Microsoft est encore possible… Pour combien de temps ?
L'utilisation d'un service emails de Microsoft par la mairie <CENSURE> n'est pas conforme au RGPD en cela qu'elle génère des transferts de données personnelles vers un État tiers non adéquat (Schrems II, votre mise en demeure du 10 février 2022 portant sur l'utilisation de Google Analytics, décision de l’APD autrichienne du 22 avril 2022 portant sur Google Analytics, absence d’obligation contractuelle et de recueil du consentement, absence de contrainte technique ou financière, etc., pour un argumentaire détaillé, je vous renvoie à mes précédentes réclamations CNIL toujours en cours de traitement), cf. articles 44 et suivants du RGPD.
La politique de confidentialité de la mairie <CENSURE> (https://<CENSURE>/confidentialite/) ne référence pas ces transferts de données personnels vers un État tiers non adéquat ni les mesures complémentaires que la mairie pourrait mettre en œuvre dans ce cadre.
Dans le cas d’espèce, afin de satisfaire la formalité déclarative, mon email devait contenir a minima les noms, prénoms, date et lieu de naissance, adresse postale actuelle, et fonction (au sein du syndicat) de l'équipe dirigeante d'un syndicat, ce qui associe, auprès d'un tiers non adéquat, une appartenance syndicale, donnée personnelle sensible, à des personnes clairement identifiées.
Cela illustre également une carence de la mairie <CENSURE> dans le choix, le pilotage et l'audit de sa sous-traitance en matière de données personnelles, ce qui constitue une entorse aux articles 24 et 28 du RGPD.
Autre sujet. Afin de remplir avec pertinence la présente, j’ai consulté le site web de la mairie <CENSURE> et notamment sa politique de confidentialité. Avant toute acceptation des cookies, le site web de la mairie <CENSURE> (https://<CENSURE>/) fait automatiquement télécharger Google Analytics, Google DoubleClick, et une police de caractères Google Fonts. Ces ressources web sont toujours actives et téléchargées même en cas de refus des cookies dans le bandeau dédié.Ces téléchargements induisent des transferts de données personnelles vers la société commerciale états-unienne Google, c’est-à-dire vers un État tiers non adéquat. La Cour régionale de Munich a déjà sanctionné l’utilisation de Google Fonts dans sa décision 3_O_17493/20.
La politique de confidentialité de la mairie (https://<CENSURE>/confidentialite/) ne mentionne pas un quelconque contact en matière de données personnelles.Je sollicite l’intervention de la CNIL afin qu’elle mette un terme aux infractions au RGPD référencées dans la présente, et qu’elle sanctionne la mairie <CENSURE>.
Je vous rappelle l’arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a confirmé que l'exercice des droits (accès, opposition, etc.) n'est pas un pré-requis au dépôt d’une plainte auprès d'une APD en cas de violation du RGPD et qu'une APD peut donc agir même si la personne physique concernée par un traitement de données personnelles n'a pas (encore) fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
La coopérative des Mutins de Pangée propose des films sans DRM.
La partie technique est déléguée à la société commerciale française Kaemo (Kinow) qui, elle-même, a recours aux CDN et à l'hébergement informatique des sociétés commerciales états-uniennes Cloudflare et Amazon (services Cloudfront et AWS), y compris pour la diffusion des films. Les seuls moyens de paiement proposés sont les sociétés commerciales états-uniennes Paypal et Stripe.
Cela génère de fait des transferts illégaux de données personnelles (adresse IP, numéro de carte bancaire, films visionnés, informations techniques sur le navigateur web et l'ordinateur, etc.) aux États-Unis. Raisonnement ici. L'EDPS, l'APD des institutions européennes, a déjà sanctionné l'utilisation de Stripe dans sa décision 2020-1013.
Comme celle visant OpenStreetMap, cette réclamation, déposée il y a plusieurs mois, a été un crève-cœur : 1) j'aime ce que fait les Mutins, les films sans DRM, ça va dans le bon sens (cela exonère-t-il pour autant de toute critique ?) ; 2) je suis forcé de reconnaître que ça marchait moins bien avec l'ancien hébergeur, Infomaniak : téléchargements saccadés et faible débit depuis Orange, Free, et SFR (mais ça fonctionnait impec depuis OVH qui dispose d'une interconnexion avec Infomaniak, comme quoi, c'est possible d'agir sans recourir aux ricains).
Bonjour,
Le 14/03/2023, j'ai consulté le catalogue VOD (https://www.cinemutins.com/) des Mutins de Pangée.
L'hébergement informatique est sous-traité à la société commerciale française Kaemo (Kinow), qui, elle-même, a recours aux CDN et à l'hébergement informatique des sociétés commerciales états-uniennes Cloudflare et Amazon (services Cloudfront et AWS), y compris pour la diffusion des films (ce qui est étrange, puisque qu’Amazon, avec son service Prime Video, officie sur le même marché).
De plus, les seuls moyens de paiement proposés sont les sociétés commerciales états-uniennes Paypal et Stripe.
Cela génère de fait des transferts de données personnelles (adresse IP, numéro de carte bancaire, films visionnés, informations techniques sur le navigateur web et l'ordinateur, etc.) vers un État tiers non adéquat. De plus, dans sa décision numéro 2020-1013, l'EDPS a sanctionné l'utilisation de Stripe.
Ce qui s'approche le plus d'une politique de traitement des données personnelles sont les CGV de la plateforme (https://www.cinemutins.com/p/conditions-generales-de-ventes). Celles-ci n'exposent pas les mesures complémentaires que la société Les Mutins de Pangée mettrait en œuvre dans le cadre de ces transferts internationaux.
Le site web du prestataire Kinow (https://fr.kinow.com), qui est diffusé via Amazon Cloudfront et qui grouille de ressources web détenues et/ou hébergées par des sociétés commerciales états-uniennes (Google Analytics, Google Fonts, Google DoubleClick, Google Tag Manager, Fonticons / Cloudflare, etc.), ne met pas à disposition une quelconque politique de traitement des données personnelles qui permettrait de prendre connaissance des éventuelles mesures complémentaires mises en œuvre par ce sous-traitant dans le cadre de ces transferts internationaux.
En conséquence, les transferts de données personnelles sus-énumérés sont illégaux au sens des articles 44 et suivants du RGPD (Schrems II, votre mise en demeure du 10 février 2022 portant sur Google Analytics, décision de l’APD autrichienne du 22 avril 2022 portant sur Google Analytics, etc., pour un argumentaire détaillé, je vous renvoie à mes précédentes réclamations CNIL toujours en cours de traitement).
Cela illustre également une carence des Mutins de Pangée dans le choix, le pilotage et l'audit de leur sous-traitant en matière de données personnelles, ce qui constitue une entorse aux articles 24 et 28 du RGPD.
Je sollicite l’intervention de la CNIL afin qu’elle mette un terme aux infractions au RGPD référencées dans la présente, et qu’elle sanctionne les Mutins de Pangée.
Je vous rappelle l’arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a confirmé que l'exercice des droits (accès, opposition, etc.) n'est pas un pré-requis au dépôt d’une plainte auprès d'une APD en cas de violation du RGPD et qu'une APD peut donc agir même si la personne physique concernée par un traitement de données personnelles n'a pas (encore) fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
En octobre 2022, j'ai signalé à la CNIL que, pour diffuser des vidéos sur son site web, elle utilisait un prestataire français, Webcastor, qui s'héberge sur des infrastructures états-uniennes (voir).
En janvier 2023, le DPO de la CNIl m'a répondu avoir, à titre préventif, internalisé l'hébergement des vidéos et être en discussion, avec son prestataire, sur la conformité de sa solution avant de décider si la CNIL continuera à y avoir recours.
Je lui répondais dans la foulée qu'il n'avait pas internalisé les vidéos, mais seulement celles que j'avais pointé alors qu'il lui incombe de procéder à une mise en conformité totale (ce n'est pas à moi de pointer chaque vidéo). De nouvelles vidéos avaient été mises en ligne après l'ouverture de ma réclamation…
Je n'ai jamais eu de réponse. D'où cette nouvelle réclamation déposée mi-avril 2023.
Depuis, j'ai constaté, sans étonnement, que la CNIL s'en fout complet du RGPD : elle a refait appel à ce prestataire, toujours hébergé par des entités ricaines, pour diffuser le direct de son colloque dédié à ses 45 ans (voir 1 et 2) et celui du Privacy Research Day.
Bonjour,
Dans ma réclamation CNIL numéro <CENSURE>, je signalais à la CNIL que plusieurs vidéos de son site web étaient diffusées via le service Streamfizz de la société commerciale française Webcastor, qui, elle-même, déléguait son infrastructure technique à plusieurs sociétés commerciales états-uniennes (Vercel, Amazon, Microsoft, Google, DigitalOcean, Stellate, Fastly), y compris la production d'un journal des événements (lecture de la vidéo, pause, reprise, recherche, etc.). Il s'agissait de transferts illégaux de données personnelles vers un État tiers non adéquat.
Dans sa décision de clôture de ma réclamation du 10 janvier 2023, la CNIL m'informait que les vidéos concernées « ont en effet été rendues directement accessibles à partir du site institutionnel cnil.fr » et que des « échanges sur la conformité au RGPD de la solution Streamfizz […] se poursuivent […] avec la société Webcastor ». Cf. PJ 1.
Le 10 janvier 2023, j'ai informé le DPO de la CNIL, qui m'a transmis la décision de clôture, que des vidéos du site web de la CNIL étaient toujours diffusées via le service Streamfizz de Webcastor. J'illustrais cela par la vidéo air2022 (https://www.cnil.fr/fr/rediffusion-air2022-retrouvez-levenement-en-video) mise en ligne trois semaines après l'ouverture de ma réclamation et la vidéo bac à stable EdTech (https://www.cnil.fr/fr/bac-sable-edtech-la-cnil-accompagne-10-projets-innovants, https://www.cnil.fr/fr/la-cnil-propose-un-nouveau-bac-sable-pour-accompagner-linnovation-numerique-dans-le-domaine-de, https://www.cnil.fr/en/edtech-sandbox-cnil-supports-10-innovative-projects). Cf. PJ 1.
Cela démontre une carence dans la mise en conformité du site web de la CNIL suite à ma réclamation numéro <CENSURE>.
À ce jour, ces vidéos sont toujours diffusées via le service Streamfizz de Webcastor. Cette dernière a toujours recours à la palanquée de sociétés commerciales états-uniennes pour diffuser lesdites vidéos.
Il y a donc toujours des transferts illégaux de données personnelles vers un État tiers non adéquat depuis le site web de la CNIL.
Bonne journée.
Bonjour Monsieur,
Vous nous avez saisis d'une plainte (P<NUMÉRO_CENSURÉ> du <DATE_CENSURÉE>) concernant les modalités de diffusion des vidéos de la CNIL.
Comme indiqué dans le cadre de la clôture de votre précédente plainte (P<NUMÉRO_CENSURÉ>), je vous confirme que les travaux se sont poursuivis avec la société Webcastor afin de proposer une nouvelle solution de mise à disposition des vidéos de la Commission. Cette nouvelle solution est en cours de déploiement.
Nous ne manquerons de vous tenir informé de l'issue prochaine de ces travaux.
Bien à vous,
Bonjour,
Dans sa décision que vous m’avez relayé le 10/01/2023, le secrétaire général adjoint de la CNIL écrit également que « des mesures conservatoires ont été prises afin de modifier les conditions d'hébergement et de diffusion des vidéos concernées ». Ces mesures sont présentées comme étant l’une des actions de la CNIL ayant permis « d'apporter une réponse appropriée à la situation » signalée.
Par retour d’email le 10/01/2023 et par la présente réclamation, je tente de vous faire constater que ces mesures préventives ont été partielles car portant sur les seules vidéos que je vous ai explicitement signalées dans ma réclamation <NUMÉRO_CENSURÉ> d’octobre 2022, alors qu’en toute logique, elles auraient dû être appliquées à l’intégralité des vidéos diffusées sur le site web de la CNIL, surtout celles mises en ligne postérieurement à ma réclamation, comme air2022.
Or, même aujourd’hui, ce n’est pas le cas : les vidéos référencées dans la présente réclamation, et probablement d’autres, sont toujours diffusées via la solution Streamfizz de Webcastor qui a toujours recours aux mêmes prestataires états-uniens (au moins pour son lecteur, la géolocalisation, et les stats).
Quant à l’émergence d’une solution conforme au RGPD (donc sans recourir au Data Privacy Framework) proposée avec / par Webcastor, je suis dubitatif dans la mesure où les diffusions en direct du colloque des 45 ans de la CNIL (23/05/2023) et du Privacy Research Day (14/06/2023, soit 8 mois après ma réclamation <NUMÉRO_CENSURÉ>) étaient assurées via Webcastor et ses prestataires états-uniens… Le direct de vos 45 ans fait d’ailleurs l’objet de la réclamation <NUMÉRO_CENSURÉ> (l’information est publique).
Bonne semaine.
P.-S. : sans rapport immédiat avec la présente réclamation, je vous informe que le script JavaScript « https ://cnil.fr/sites/cnil/files/js/js_oQ-FFnywjdD92uXfscXi9VUSDMJk5b1ZOrahSz_1pvo.js » inclus à la fin de chaque page du site web de la CNIL fait télécharger le script « https ://cdnjs.cloudflare.com/ajax/libs/jquery-mousewheel/3.1.13/jquery.mousewheel.min.js » auprès de la société commerciale états-unienne Cloudflare. Ce fut déjà le cas les 17 et 18 juin 2023 avant d’être corrigé suite à un signalement (là encore, l’info est publique). Je n’ai pas l’énergie d’ouvrir une demande dédiée…
Ces six derniers mois, j'ai apporté à la CNIL des éléments nouveaux concernant plusieurs de mes réclamations. Dans deux autres, la CNIL m'a informé avoir contacté le DPO de la structure que je mets en cause.
En conséquence, j'ai mis à jour les shaarlis suivants :
J'ai trouvé deux solutions pour ne plus avoir à investir mon temps pour défaire les saloperies que mozilla fourre à tour de bras dans firefox.
La première option c'est le user.js de arkenfox: https://github.com/arkenfox/user.js […]
la seconde option c'est de remplacer firefox par librewolf: https://librewolf.net/ […]
J'ai déjà lu Antichesse évoquer plusieurs fois Librewolf, mais ça ne me convient pas : il n'est pas empaqueté dans Debian. Pour un logiciel en contact avec le monde extérieur, sur lequel plusieurs vulnérabilités sont corrigées chaque mois (quasiment), ce n'est pas acceptable. Oui, Librewolf propose un dépôt maison, mais c'est aussi bien géré que tous les autres dépôts de ce style (en moyenne), donc il n'y a pas de différenciation entre màj de sécurité et màj fonctionnelle, donc on change de versions tous les deux jours. Sans moi. J'aime Debian justement parce que tout ne change pas tous les quatre matins.
Concernant le user.js d'Arkenfox :
Il reste deux modes : soit j'utilise le user.js, soit, à chaque mise à jour de Firefox, je lis les changements détectés par Arkenfox et je les applique. Au final, si l'on réfléchit, je ne peux pas échapper à une étude de user.js avant de le mettre en prod' (sinon je ne peux pas définir les paramètres que je veux forcer contre l'avis d'Arkenfox). Idem à chaque mise à jour de Firefox, pour la même raison (peut-être voudrais-je conserver un paramètre pas top). Du coup, qu'apporte la machinerie proposée par Arkenfox ? La suppression des vieux paramètres via un script dédié ? Oui, mais, dans mon about:config, j'ai des paramètres qui ne sont plus fonctionnels depuis plusieurs versions et mon Firefox fonctionne, donc bon, ce n'est pas ma priorité.
Au final, j'ai décidé d'aller lire, lors d'une mise à jour de Firefox, les changelogs d'Arkenfox entre mon ancienne version et la nouvelle. Et pour chaque paramètre, décider ce qui me convient puis répercuter ou non le changement dans about:config.
Pour l'instant, j'ai rattrapé mon retard entre le user.js qui correspond à ma version et mes paramètres. J'ai mis à jour mon antique shaarli dédié à ma configuration Firefox.
Le plus intéressant est l'activation de resistFingerprinting
(RPF) qui a déjà été évoqué dans la rivière shaarli. Attention toutefois : ça désactive, entre autres, les thèmes sombres des sites web, notamment ceux sur lesquels je n'ai pas de compte pour changer ça (YouTube, GitHub, etc.).
À noter également : la First Party Isolation (privacy.firstparty.isolate
) n'est plus maintenue. Elle est remplacée par le Network Partitioning et la Total Cookie Protection (nom vendeur de la Dynamic First Party Isolation) qui est activée uniquement quand la FPI est désactivée et que l'on active la Enhanced Tracking Protection (« Protection renforcée contre le pistage » dans l'onglet « Vie privée et sécurité » des préférences) en mode strict (le mode personnalisé n'active pas TCP).
Je retiens également qu'Ublock Origin peut désormais supprimer les paramètres traçants des URLs quand on lui ajoute les listes adéquates (voir). Pour ce faire, j'utilisais l'extension Pure URL mais très peu de paramètres sont pris en charge (utm, fb, et quelques autres).
Enfin, je retiens que l'extension HTTPS-Everywhere de l'EFF est en fin de vie, remplacée par le mode « HTTPS uniquement » de Firefox.
Ironiquement, tu réponds à mon shaarli qui évoque le paramètre « dom.block_download_insecure » de Firefox… alors qu'Arkenfox ne prévoit rien pour ce paramètre. :D
Merci pour la trouvaille. :)
La CJUE a rendu son jugement (contre Meta) :
Toute personne peut demander à une administration de lui communiquer la correspondance que celle-ci a entretenu avec d'autres entités. Exemple : les observations qu'une administration a produites dans le cadre d'une saisine de la CADA (voir). Évidemment, il y a des exceptions : vie privée, secret des affaires, la décision doit être intervenue, etc.
Pour vérifier les actions de la CNIL dans le cadre de mes réclamations, je lui ai demandé de me communiquer sa correspondance avec les responsables de traitement (RT) mis en cause.
J'ai mis à jour mes shaarlis sur Silkhom, Danitis, et Cogent avec les courriers de la CNIL.
Au final, dans 2/3 des cas, la CNIL a appuyé l'ensemble de mes griefs énoncés explicitement dans ma réclamation (un grief énoncé dans mes échanges avec un RT, joins à ma réclamation, mais non repris dans celle-ci n'est pas appuyé). Dans le dernier cas, la CNIL s'est contentée d'appuyer ma demande d'effacement sans rien dire de la base légale inapplicable ni de la durée de conservation excessive, pourtant évoquées dans ma réclamation. Dans 3/3 des cas, pas de contrôle ni de sanction, juste une invitation à vérifier sa conformité dans l'un des cas.
J'étais en train de mettre un serveur distant à la casse en révoquant toutes les clés d'un conteneur chiffré (cryptsetup luksErase <dev>
) puis en écrasant la table des partitions au format GPT avec dd
quand Johndescs me demande si j'ai supprimé « la table GPT de backup en fin de disque ».
Ha oui, tiens, plusieurs sources web disent qu'il y a une sauvegarde de la table GPT dans les 33 derniers secteurs d'un disque au max, soit 16,5 octets au max ((33 * 512 octets) / 1024).
Pour le fun, je veux constater ça par moi-même.
fdisk -lu
me dit : « Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors ».
Regardons les 1000 derniers secteurs. 3907029168 - 1000 = 3907028168.
dd if=/dev/sda skip=3907028167 | hexdump -vC
[…]
00078e00 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
00078e10 90 ca 57 b3 c7 18 fa 48 97 a9 9e ae 35 69 6c e0 |..W....H....5il.|
00078e20 28 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 |(...............|
00078e30 00 00 00 00 00 00 00 00 62 00 69 00 6f 00 73 00 |........b.i.o.s.|
00078e40 5f 00 67 00 72 00 75 00 62 00 2d 00 73 00 64 00 |_.g.r.u.b.-.s.d.|
00078e50 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |a...............|
00078e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078e70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078e80 af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 |.=....rG.y=i.G}.|
00078e90 34 ea 7a 69 e4 99 67 40 b9 df c0 40 3e 12 a8 4c |4.zi..g@...@>..L|
00078ea0 00 10 00 00 00 00 00 00 ff 07 80 3e 00 00 00 00 |...........>....|
00078eb0 00 00 00 00 00 00 00 00 70 00 72 00 69 00 6d 00 |........p.r.i.m.|
00078ec0 61 00 72 00 79 00 00 00 00 00 00 00 00 00 00 00 |a.r.y...........|
00078ed0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078ee0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078ef0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078f00 af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 |.=....rG.y=i.G}.|
00078f10 2d 41 c0 3f a0 c1 12 49 bf 5c cf ee 89 d0 6e 77 |-A.?...I.\....nw|
00078f20 00 08 80 3e 00 00 00 00 ff 6f d0 e8 00 00 00 00 |...>.....o......|
00078f30 00 00 00 00 00 00 00 00 70 00 72 00 69 00 6d 00 |........p.r.i.m.|
00078f40 61 00 72 00 79 00 00 00 00 00 00 00 00 00 00 00 |a.r.y...........|
00078f50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078f60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078f70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00078f80 6d fd 57 06 ab a4 c4 43 84 e5 09 33 c8 4b 4f 4f |m.W....C...3.KOO|
00078f90 3e d2 b7 22 c5 0e 82 44 80 e4 62 e0 85 fb 59 fc |>.."...D..b...Y.|
00078fa0 00 70 d0 e8 00 00 00 00 ff 67 e0 e8 00 00 00 00 |.p.......g......|
00078fb0 00 00 00 00 00 00 00 00 70 00 72 00 69 00 6d 00 |........p.r.i.m.|
00078fc0 61 00 72 00 79 00 00 00 00 00 00 00 00 00 00 00 |a.r.y...........|
0007ce00 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...|
0007ce10 29 6e 0e d5 00 00 00 00 af 88 e0 e8 00 00 00 00 |)n..............|
0007ce20 01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00 |........".......|
0007ce30 8e 88 e0 e8 00 00 00 00 d0 d2 1f c2 dc 91 bb 4f |...............O|
0007ce40 9f e7 c8 a4 04 7b 91 bc 8f 88 e0 e8 00 00 00 00 |.....{..........|
0007ce50 80 00 00 00 80 00 00 00 90 23 af 95 00 00 00 00 |.........#......|
Utilisons Wikipedia pour déchiffrer ça.
L'entête secondaire est sur le dernier secteur du disque. On la reconnaît grâce à sa signature, « 45 46 49 20 50 41 52 54 » (« EFI PART » en ASCII ).
Ensuite, on a la table des partitions. Habituellement, une entrée de la table occupe 128 octets soit 8 lignes de hexdump
. On y voit quatre partitions (la distinction primaire / logique n'existe plus) :
La première depuis l'entête (et donc la dernière sur le disque) est une partition swap de Linux. Je le sais grâce à l'identifiant unique de son type : « 6d fd 57 06 ab a4 c4 43 84 e5 09 33 c8 4b 4f 4f ». Attention, comme l'explique la note de Wikipedia, une partie des octets est inversée à cause du little-endian.
fdisk
le dit) donc la taille de la partition est : 1046527 * 512 = 535821824 octets soit 512 Mo environ ;Aucune de ces partitions n'a un quelconque attribut (drapeau). Ils sont situés dans les 8 octets qui précédent le nom de la partition.
Un drapeau = 1 bit. Une partition cachée = bit 62 = 63e bit. Pas de montage auto = bit 63 = 64e bit.
Les logiciels n'ont pas l'air d'accord sur le rôle de chaque bit de drapeau. sgdisk
considère que le 1er bit (bit 0) signifie partition système là où parted
considère qu'il signifie partition cachée. Inversement, gparted
ne reconnaît pas ce que sgdisk
considère être une partition cachée (63e bit). Les deux outils sont d'accord sur le 3e bit (amorçable par d'anciens BIOS). gparted
reconnaît aucun des autres drapeaux.
Sur ce coup, gparted
est mal fichu, notamment parce qu'il présente comme drapeau ce qui n'en est pas, comme « bios_grub » (qui désigne une partition de boot BIOS, qui est un type de partition).
Évidemment, y'a encore cette histoire de little-endian, donc (binaire avec xxd
, hexa avec hexdump
, format gdisk
, format sgdisk
, sens pour parted
) :
Du coup, j'ai également effacé cette table GPT secondaire avec dd if=/dev/urandom seek=3907028167 of=/dev/sda
.
Ça me rappelle l'un de mes articles vieux de 13 ans dans lequel je décortique un MBR. :D
Cela fait environ dix ans que j'ai fait des choix de rangement de mes journaux informatiques (logs) sur mes serveurs personnels. Il est grand temps de faire un bilan et d'améliorer ce qui doit l'être.
Sur un système GNU/Linux, les journaux sont éclatés en fichiers par catégorie (facility) et par priorité. Un même message peut être consigné dans plusieurs fichiers.
Je pense que cette organisation en gros pâtés n'est pas intuitive ni optimale.
Ce que je fais :
Ça se fait facilement en rajoutant des fragments de configuration dans /etc/rsyslog.d
. Ainsi, pour CRON, je crée un fichier /etc/rsyslog.d/cron.conf
contenant cron.* -/var/log/cron.log
.
De base, les journaux archivés (« .log.1 », « .log.2.gz », etc.) sont stockés à côté du journal courant. Du coup, /var/log
devient rapidement un fouillis dans lequel je peine à m'y retrouver. C'est encore plus prononcé quand on a des obligations de conservation sur un temps long.
Ce que je fais : une arborescence séparée /var/log/archives/<nom_logiciel_ou_service>
.
Cela suppose de surcharger tous les fragments de configuration déposés dans /etc/logrotate.d/
par des paquets logiciels. Pour éviter d'incessantes questions lors des mises à jour desdits paquets, j'utilise dpkg-divert
. Exemple : dpkg-divert --add --rename --divert /etc/logrotate.d/apache2.dpkg-dist /etc/logrotate.d/apache2
qui ordonne de ranger le fichier /etc/logrotate.d/apache2 livré par un paquet dans /etc/logrotate.d/apache2.dpkg-dist. logrotate ignore les fichiers dont le nom termine par « .dpkg-dist ».
Tantôt des fichiers de configurations dans /etc/logrotate.d
commençaient par la périodicité, tantôt par la durée de conservation, tantôt par… De plus, je n'utilisais pas les mêmes directives partout sans justification (ifempty
, par ex.).
C'est galère pour chercher visuellement ou automatiquement des informations.
J'ai tout harmonisé au format : paramètres généraux puis paramètres du journal courant puis paramètres des archives puis scripts. Donc : périodicité, rotate, missingok, ifempty, create, olddir, compress, delaycompress, sharedcripts, postrotate.
Il y avait des divergences mineures entre mes serveurs persos pour un même journal. C'est corrigé.
Debian est passé de mysql
à mariadb
, donc les noms des journaux n'étaient plus parlants (ceci dit, la configuration demeure toujours dans /etc/mysql
donc bon…), des directives rsyslog étaient devenues inutiles (elles ne capturaient et donc ne redirigeaient plus rien) et, c'est désormais rsyslog qui journalise tout (cf. /etc/mysql/mariadb.conf.d/50-server.cnf
), donc le script postrotate dans la configuration de logrotate semble insuffisant, j'y ai rajouté /usr/lib/rsyslog/rsyslog-rotate
.
Lors de l'activation de HTTP/2 sur ce site, je suis passé de php sous forme de module pour Apache httpd à php-fpm
. Désormais, il y a un journal pour le gestionnaire (php-fpm) qui était pris en charge par logrotate via une configuration livrée avec le paquet, mais qui, du coup, n'archivait pas dans mon arborescence séparée ni pour une durée pour laquelle j'avais consentie.
L'ennui, c'est que le nom du journal, « php7.4-fpm.log », changera à la prochaine mise à jour majeure de Debian, car la version de php changera (7.3 -> 7.4 -> 8.2). Le fragment de configuration pour logrotate sera livré dans le paquet, mais ne contiendra pas mes directives. Configurer PHP-FPM pour envoyer son journal à rsyslog ne résout pas ce problème : l'arborescence de configuration dépend aussi de la version de PHP (/etc/php/<VERSION>/fpm/php-fpm.conf
), donc elle sera effacée par la mise à jour. Vu le cycle de vie très rapide de php-fpm, l'objectif de ce nommage dépendant de la version est de pouvoir installer simultanément plusieurs versions de PHP sur un même système.
J'ai créé un fichier /etc/logrotate.d/php
:
/var/log/php*-fpm.log {
[…]
postrotate
# Demander à la "bonne" version des php-fpm de réouvrir son journal
binname=$(find /usr/lib/php/ -iname 'php*-fpm-reopenlogs')
if test -x "$binname"
then
$binname;
fi
endscript
}
Hé oui, là encore, le binaire qui permet de dire à php-fpm de changer de journal dépend du numéro de version…
Mais, ça ne suffit pas : logrotate.conf inclut les fragments de conf' présents dans /etc/logrotate.d, dont php et php-X.Y-fpm. Logrotate consignera que deux fragments de conf' portent sur un même journal et terminera en erreur, pour ces deux fragments, donc le journal de php ne sera pas archivé et le script pas exécuté. Je crée donc un fichier /etc/cron.daily/php
:
#!/bin/bash
# dpkg-divert une éventuelle nouvelle config suite màj majeure Debian
if test -f /etc/logrotate.d/php*-fpm
then
confpath=$(find /etc/logrotate.d/ -type f -name 'php*-fpm')
dpkg-divert --quiet --add --rename --divert "${confpath}.dpkg-dist" "$confpath"
fi
J'ai déjà expliqué ce point : je créais un journal par hôte virtuel, donc deux journaux par site web, un pour HTTP, l'autre pour HTTPS.
Ce distinguo ne m'a rien apporté en dix ans. Notamment car, par défaut, Apache httpd ne journalise pas les erreurs TLS. Je ne vais pas activer cela vu que j'en n'ai pas eu besoin et que ça risque de souvent biper à tort vu mon certificat x509 signé par une autorité de certification maison.
Shaarli consigne une erreur à chaque robot qui accède, sans définir le referer (la case n'existe alors pas dans le tableau $_SERVER), aux liens qui permettent de changer le nombre de liens par page. Et comme shaarli redéfinit error_reporting… Bref, dans index.php
de shaarli, remplacer le error_reporting existant par : error_reporting(E_ALL^E_WARNING^E_NOTICE);
.
La bibliothèque de fonctions de RSS-Bridge qui fait l'interface avec l'API de Twitter, TwitterClient, consigne des événements en mode debug ("je réutilise le token mise en cache", "je demande un nouveau token", etc.) qui atterrissent dans le journal des erreurs de l'hôte virtuel. Aucune condition autour de ces directives, donc pas d'autre moyen de les faire taire que de les commenter…
Un plugin de mon Wordpress, mon thème perso Wordpress et Shaarli généraient des erreurs pour des fonctions dépréciées, pour une syntaxe erronée (function_exists()
attend le nom d'une fonction avec ses parenthèses ou entourée de guillements), etc. J'ai corrigé tout ça.
ejabberd consignait en permanence des erreurs TLS liées à mon certificat x509 autosigné. C'est inutile et ça conservait des données personnelles (l'essentiel de mes contacts ont un serveur Jabber perso donc le nom de domaine est une donnée personnelle). J'ai réduit la verbosité d'ejabberd (loglevel: 2
dans /etc/ejabberd/ejabberd.yml
). Le reste était des messages au démarrage "tu charges tel module sans charger tel autre, c'est inhabituel". J'ai corrigé ça.
Lors de la définition de ma politique de journalisation, je me suis fait embarquer par la légende urbaine qui voudrait qu'on doit conserver le journal des accès à un serveur web pendant un an, idem pour un serveur emails ou de messagerie. La réalité est plus nuancée et dépend de l'usage et du contexte. J'ai tout détaillé dans un autre article. Au final, je ne suis pas concerné par les obligations légales de conservation de données de connexion.
De plus, par paresse intellectuelle et par peur du manque, je consignais des journaux techniques sur la même durée (un an) alors que ça n'a aucun intérêt. Consigner les journaux d'OpenDNSSEC durant un an quand la durée de vie de mes signatures est d'une semaine, ça n'a aucun intérêt (s'il y a une erreur, mes services seront inaccessibles dans la semaine). Consigner les transferts de zones DNS sur la même durée est tout aussi inutile, là encore en relation avec la durée d'expiration de mes zones sur mes serveurs DNS secondaires. Idem le journal de ntpd qui consigne rien après son démarrage… Etc.
Je me rassurais : la plupart de ces journaux ne comportent aucune donnée personnelle. Pour ceux qui en comportent, comme celui de mon serveur emails, ce n'était pas bien grave car, à part les spammeurs et les scanneurs de ports / TLS / etc., ça consignait ma correspondance… que je conserve de toute façon dans mon logiciel de messagerie.
Parfois, cette durée de conservation m'a été utile. Exemple ? Vérifier les paramètres pris en charge par les gros fournisseurs emails avant de renforcer mes configurations TLS. L'ennui, c'est que tout peut toujours être utile. Avoir un micro en permanence sur toi quand t'es chez ton employeur permettra de prouver ta bonne foi lors d'un contentieux… ou que t'es en tort. Surveiller ton/ta partenaire de cul permettra de détecter sa tromperie… ou la tienne. Fliquer toute la population augmente la probabilité de retrouver l'auteur d'une infraction… ou un dissident politique. C'est précisément le sens des arrêts de la CJUE sur la rétention des données de connexion : l'équilibre entre la préservation de la vie privée et les autres intérêts. Dans le cas d'usage que je cite, je pouvais très bien faire mon étude au fil de l'eau, avant de modifier mes paramètres TLS, en conservant uniquement mes résultats (tel fournisseur emails prend en charge uniquement TLS 1.0, par ex.). C'est un boulot régulier (avant chaque effacement du journal), c'est la seule contrainte.
Désormais, j'ai défini deux catégories de journaux :
weekly
+ rotate 1
) ;weekly
+ rotate 5
) afin d'être sûr qu'ils englobent un mois entier, de son 1er jour à son dernier (explication) ;weekly
+ rotate 4
), soit un mois glissant ;monthly
+ rotate 5
).Quand on veut réduire la durée de conservation de ses journaux, il faut penser à systemd-journald.
Sur un système Debian, journald s'interpose entre les logiciels et rsyslog, même quand c'est rsyslog qui ouvre la socket UNIX pour un logiciel (postifx, par ex.). Il reçoit donc tous les messages syslog. Or, par défaut, il implémente une politique basée sur l'occupation de l'espace disque (détails).
On peut réduire l'occupation disque maximale des journaux, mais je ne suis pas fan : en cas de pic d'activité (ou d'attaque), les journaux pertinents peuvent être écrasés par ceux du pic…
On peut désactiver partiellement journald (détails, dernière ligne), mais ce n'est pas à l'épreuve du temps vu que journald a des usages pertinents et qu'il est appelé à prendre une place centrale.
On peut faire un mix entre une politique d'occupation disque et une politique basée sur le temps (détails). En ce qui me concerne, j'ai configuré MaxRetentionSec=5week
. Il s'agit, chez moi (cf. section précédente), de la durée maximale désirée des journaux qui transitent par message syslog (apache httpd et nginx écrivent eux-mêmes leurs journaux, idem pour apt et dpkg).
Dans la plupart des journaux, la date et l'heure d'un message sont exprimées dans un format difficilement exploitable comme « Jul 1 01:23:45 » ou « 01/Jul/2023:01:23:45 ».
Cela complique l'affichage simultané de plusieurs journaux dans l'ordre chronologique. On peut faire zcat $(ls -rv)
, mais bon, paye ta simplicité lors d'une urgence, et ça suppose que tous les journaux soient dans le même dossier. Surtout si les journaux englobent plusieurs mois : sort
classera « Jul » (juillet) avant « Jun » (juin), par exemple, et selon le type de tri, il classera 10,11,12, etc. après 01 et avant 02… Oui, il est possible de préciser à sort
de longs paramètres pour trier comme il faut, mais, là encore, paye ta simplicité…
De même, cela complique une recherche dans les journaux : « Jul 1 » (deux espaces) mais « Jul 10 » (une espace). Rien de grave, mais c'est pénible.
Le pompon, c'est la date+heure au milieu d'une ligne, notamment dans les journaux des serveurs web. Le journal est chronologique, donc la date est la clé du tri implicite, donc elle devrait être en début de ligne, en lieu et place de l'adresse IP qui est l'une des infos du message, pas une caractéristique de ce dernier comme l'est la date. Là encore, ça complique un tri avec sort
.
Tout cela constitue l'une des raisons qui m'a fait reculer à chaque fois que j'ai réfléchi à la réduction de la durée de conservation de mes journaux : une durée de conservation de quelques semaines, un mois au max, est souvent la plus apropriée, mais en monthly
+ rotate 0
, logrotate supprime le journal des derniers jours d'un mois dès le 1er jour du mois suivant (voir), donc on part sur rotate 1
donc 2 mois de conservation… De plus, descendre en dessous d'un mois, c'est choisir une périodicité quotidienne ou hebdomadaire, et donc devoir agréger plusieurs journaux pour obtenir une vision sur « quelques semaines - 1 mois », et donc se retrouver face au problème de tri énoncé ci-dessus…
Il existe deux ensembles de formats de date+heure faciles à manipuler : ISO 8601 et RFC 3339. Les arguments sont ici. Les deux normes ne sont pas équivalentes, certains formats communs aux deux normes, d'autres non, voir.
Comment les utiliser ?
D'après sa documentation, rsyslog permet d'utiliser le format « %Y-%M-%D %h:%m:%.6s%Z:%z », dérivé de « %Y-%M-%D %h:%m:%.3s%Z:%z » (seul le nombre de chiffres après la seconde change), qui est un format commun au RFC 3339 et à ISO 8601.
Pour l'utiliser dans tous les journaux dont rsyslog à la charge :
# echo '$ActionFileDefaultTemplate RSYSLOG_FileFormat' > /etc/rsyslog.d/0-dateformat.conf
# systemctl restart rsyslog
(Préfixer le nom du fichier par « 0 » permet qu'il soit le premier inclus dans /etc/rsyslog.conf
. Sans cela, le format de date+heure des logiciels dont le fragment de config' rsyslog serait inclus avant resterait inchangé.)
Inventaire :
ejabberd
ne permet pas de changer le format de ses journaux ni d'envoyer ses messages à syslog ;logger
(voir). À chaque requête, un processus logger
est lancé. Ça me paraît bien gourmand pour rien en comparaison d'une écriture dans une socket UNIX syslog… De plus, comme déjà dit ci-dessus, journald "interceptera" les messages syslog et procédera à une double journalisation, qui consommera de l'espace disque, et désactiver journald, même partiellement, est à contre-courant de l'histoire.Le format combined des journaux des accès, qui répond à mes autres besoins, est défini dans /etc/apache2/apache2.conf
, il n'y a plus qu'à l'adapter à ce qu'on veut en se reposant sur la doc' ou en utilisant un exemple tout prêt.
Le format des journaux des erreurs et les formats possibles sont définis dans la doc'. On notera que le format des journaux des accès (ISO 8601) ne peut pas être repris dans le journal des erreurs. Le format qui s'en rapproche le plus est « %Y-%M-%D %h:%m:%.6s » qui, comme dit plus haut, ne fait partie ni d'ISO 8601, ni du RFC 3339, mais en est très proche et en présente les mêmes avantages.
Pour appliquer le format :
# Journaux des accès
echo 'LogFormat "%{%Y-%m-%dT%T}t %h %l %u \"%r\" %>s %O \"%{Referer}i\" \"%{User-agent}i\"" combined-with-iso8601' > /etc/apache2/conf-available/iso8601-log-format.conf
echo 'LogFormat "%{%Y-%m-%dT%T}t %v:%p %h %l %u \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined-with-iso8601' >> /etc/apache2/conf-available/iso8601-log-format.conf
a2enconf iso8601-log-format.conf
# Dans chaque hôte virtuel
CustomLog ${APACHE_LOG_DIR}/<vhost>/access.log combined-with-iso8601
# Pour other_vhosts_access.log
dpkg-divert --add --rename --divert /etc/apache2/conf-available/other-vhosts-access-log.conf.dpkg-dist /etc/apache2/conf-available/other-vhosts-access-log.conf
echo 'CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined-with-iso8601' > /etc/apache2/conf-available/other-vhosts-access-log.conf
# Journaux des erreurs
echo 'ErrorLogFormat "%{cu}t [%-m:%l] [pid %P:tid %T] %7F: %E: [remote\ %a] %M% ,\ referer:\ %{Referer}i"' >> /etc/apache2/conf-available/iso8601-log-format.conf
# Dans chaque hôte virtuel (oui, pas besoin de préciser le format, il est unique, sauf si on le surcharge dans un hôte virtuel)
ErrorLog ${APACHE_LOG_DIR}/<vhost>/error.log
# /var/log/apache2/error.log est défini dans /etc/apache2/apache2.conf, il n'y a rien à faire
(Je rappelle que le format des journaux des erreurs, globaux ou par hôte virtuel, ne peut pas être modifié, cf. ci-dessus.)
Le format combined des journaux des accès, qui correspond à mes autres besoins, est défini dans la doc', il n'y a plus qu'à l'adapter. Toutes les variables utilisables (TLS, communication avec le backend, etc.) ne sont pas mentionnées, il faut creuser ailleurs dans la doc' :(. En tout cas, on a la variable « $time_iso8601 » qui fait ce qu'on veut.
Mise en pratique :
Le journal global des accès est défini dans nginx.conf avant l'inclusion des confs situées dans conf.d/… donc il faut modifier nginx.conf, soit pour inverser cet ordre, soit pour ajouter nos directives directement dedans, ce que j'ai fait…
dpkg-divert --add --rename --divert /etc/nginx/nginx.conf.dpkg-dist /etc/nginx/nginx.conf
cp /etc/nginx/nginx.conf.dpkg-dist /etc/nginx/nginx.conf
# Dans nginx.conf
log_format combined-with-iso8601 '$time_iso8601 $remote_addr - $remote_user "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';
access_log /var/log/nginx/access.log combined-with-iso8601;
# Dans chaque hôte virtuel
access_log /var/log/nginx/<vhost>/access.log combined-with-iso8601;
Deleting or removing all emails from Postfix queue
To remove all mail from the queue, enter:
postsuper -d ALLTo remove all mails in the deferred queue, enter:
postsuper -d ALL deferred
Sur un système GNU/Linux, logrotate
est l'outil qui permet d'archiver périodiquement les journaux, de les compresser, puis de les supprimer en fonction d'une durée de conservation ou d'un volume d'espace disque occupé.
Il y a quelques petits pièges et trucs à savoir. C'est ce que nous allons voir.
Le manuel de logrotate expose : « Log files are rotated count times before being removed ». logrotate conservera donc X journaux en sus du journal courant / actuel. rotate 0
: dès la périodicité atteinte, le journal actuel ne sera pas archivé, il sera supprimé. rotate 1
: un journal archivé sera conservé en sus de l'actuel. rotate 2
= deux journaux archivés en sus du journal courant. Etc.
Donc la couverte sera minimum X * périodicité, maximum X+1 * périodicité. Si la périodicité est mensuelle :
rotate 0
: le journal actuel sera effacé après un mois, donc tu gardes pile un mois d'historique, mais, dès le 1er jour du mois suivant, tu perds tout cet historique, y compris celui de la veille (dernier jour du mois précédent), donc la durée minimale de conservation est 0 ;rotate 1
: un journal actuel et un journal archivé, donc un message sera conservé deux mois au maximum (si elle a été consignée le premier jour du premier mois), et un mois au minimum (les entrées du 31e jour du mois X ne seront pas effacées le 1er jour du mois X+1) ;rotate 12
conserve 12 mois minimum, 13 mois maximum (au dernier jour du 13e mois, dans le journal « .log.12.gz », tu auras des données qui remontent jusqu'au 1er jour d'il y a 12 mois. Au 31 juillet 2023, tu as les messages du 1er juillet 2022).La période est glissante. logrotate calcule la périodicité depuis son dernier passage. Il calcule donc un jour, une semaine, un mois, etc. depuis son dernier passage, pas depuis le premier jour d'une semaine ou d'un mois. (Il conserve ses états dans /var/lib/logrotate/status
.)
C'est pour ça que si, avec une périodicité hebdomadaire (par ex.), on veut conserver un mois entier, de son 1er jour jusqu'à son dernier, rotate 4
peut ne pas suffire. Exemple : juillet 2023 est sur 6 semaines, de la semaine 26 (01-02/07) à la semaine 31 (31/07). Avec rotate 4
, si logrotate archive le journal le lundi à 0 h, alors les 1 et 2 juillets, qui seront stockés dans le journal « log.4.gz », qui deviendra « log.5.gz » ce soir-là, seront effacés. S'il archive le mercredi, alors rotate 4
est suffisant. Mais cela ne se prévoit pas : on peut forcer le passage de logrotate le 1er jour d'une semaine ou d'un mois à la main avec -f
, mais, par suite, le système peut être arrêté ou logrotate peut ne pas être exécuté pour toute raison, etc. rotate 5
(qui conserve au max 6 semaines) semble plus adéquat.
De nos jours, ce n'est plus CRON qui exécute logrotate mais un timer systemd (/lib/systemd/system/logrotate.timer
), ce qui explique qu'il est désormais exécuté à minuit pile.
(L'usage usuel de CRON prévoit un mécanisme de lissage : les tâches planifiées quotidiennes, hebdomadaires et mensuelles sont lancées à des heures différentes entre elles et entre deux systèmes. Ces heures sont définies automatiquement lors de l'installation du système, cf. /etc/crontab
. Généralement, ça tombe dans les 6 h du mat'.)
logrotate ne supprime pas les vieux journaux au-delà de la périodicité configurée. Exemple : si tu passes de rotate 12
à rotate 1
, les journaux existants nommés de « log.3.gz » à « log.12.gz » ne seront pas supprimés.
Le mode de fonctionnement nominal de logrotate, c'est de renommer (et donc déplacer tant qu'on reste sur un même système de fichiers, cf. man 2 rename
;) ) le journal courant vers le dossier des archives puis d'exécuter un script pour informer le logiciel qui écrit dedans de passer à un nouveau fichier.
Certains logiciels ne prévoient pas cette fonctionnalité. Pour éviter de les redémarrer, logrotate propose la directive de config' copytruncate
: le journal courant est copié dans les archives puis il est vidé (cf. man 2 truncate
).
Jusqu'à la mi-2018, un bug rendait inopérante une directive rotate 0
cumulée avec copytruncate
: le journal courant était copié, mais pas effacé.
logrotate propose un mode debug (logrotate -d </chemin/vers/la/config>
) qui permet de tester toute la conf' ou seulement un fragment.
Quand on utilise copytruncate
+ rotate 0
, la sortie du mode debug contient des incohérences. Exemple : « weekly 0 = weekly (no old logs will be kept) […] copying /var/log/rotate 0
et donc que la copie doit être évitée.
J'ai testé : rotate 0
produit concrètement le même effet avec ou sans copytruncate
. C'est uniquement l'affichage du mode debug qui est erroné.
En revanche, avec copytruncate
, il existe toujours un bug lors de la suppression du vieux journal. En mode normal, avec rotate 0
, logrotate renomme le journal courant « log.1 » puis le supprime. Normal. En copytruncate
, il fait pareil, mais il supprime aussi le fichier « log.2.gz » s'il existe. Ça n'a pas de sens : ce journal doit être supprimé uniquement avec rotate 1
, comme en mode normal. De même que « log.3.gz » sera supprimé par rotate 2
, etc. D'ailleurs, « log.2.gz » est aussi supprimé avec rotate 1
+ copytruncate
… Bref, il y a un bug quand rotate 0
et copytruncate
sont utilisées en même temps mais ça n'a pas d'incidence sauf si l'on réduit la durée de conservation de son journal (log.2.gz sera alors peut-être effacé alors qu'on ne le souhaite pas).
(J'arrive pas à croire que je ne l'ai pas shaarlié plus tôt, ce logiciel.)
Merci Alex.
En France, comme dans le reste de l'Union européenne (UE) et un peu partout ailleurs, les opérateurs de communications électroniques ouverts au public et les hébergeurs informatiques de contenus accessibles au public sont tenus de conserver certaines données durant un certain temps pour certaines finalités légales à tendance répressive (enquêtes pénales, renseignement, et droit de communication des administrations). On nomme ça la rétention des données de connexion. (Cette désignation est trompeuse puisque la conservation d'autres jeux de données est également obligatoire.) Le régime juridique des données de connexion est distinct de celui des interceptions (portant sur le contenu des communications) qui ne sera pas traité ici.
Durant les dix dernières années, ce cadre a évolué, donc je voulais faire le point. De plus, je me suis toujours demandé quelles obligations précises pèsent sur moi avec mon site web perso, mes serveurs emails et de messagerie instantanée persos, etc. Voyons ça.
Dernière mise à jour : août 2025.
Plan :
2000 : la loi française 2000-719 codifie, dans la loi 86-1067 relative à la liberté de communication, l'obligation, pour les Fournisseurs d'accès à Internet (FAI), les hébergeurs, et les Fournisseurs de services Internet (FSI) de conserver les données permettant l'identification de l'auteur d'un contenu. On est donc avant le 11 septembre, le Patriot Act, blablabla, hein. ;)
2001 :
2011 : le décret 2011-219, précisant la LCEN, est, avec l'ancienne version du R10-13 du CPCE, la dernière définition du régime français avant le grand chamboulement. Il prévoit la conservation des données de connexion suivantes : données d'identité (nom, prénom, etc.), d'abonnement (adresse IP, numéro de téléphone, etc.), de facturation, de trafic (appels, SMS, donc fadettes, date+heure+durée de chaque communication, etc.), et de localisation (d'un smartphone, à la granularité de la couverture d'une zone par une antenne).
2013 : la Loi de programmation militaire, notamment son article 20, octroie, pour la première fois, l'accès aux données de connexion aux services de renseignement (au sens très large, il existe de nombreux « services de renseignement du second cercle »), et aux agents des ministères de l'économie et du budget (articles L246-1 et L246-2 du Code de la sécurité intérieure, CSI) pour la sécurité nationale, la sauvegarde des éléments essentiels du potentiel scientifique et économique de la France, ou la prévention du terrorisme, de la criminalité et de la délinquance organisées et de la reconstitution ou du maintien de groupements dissous (L241-2 CSI). En réalité, le L246-2 CSI parle d'« informations ou documents » et le L246-1 « des informations ou documents traités ou conservés » par les intermédiaires techniques, ce qui est susceptible de dépasser le cadre des données de connexion. L'accès est en différé (L246-1 CSI) ou en temps réel (L246-3 CSI).
2014-2022 : dans plusieurs arrêts, via plusieurs questions préjudicielles renvoyées par plusieurs juridictions nationales, la Cour de Justice de l'UE (CJUE) invalide la directive 2006/24/CE et précise les exigences découlant du droit de l'UE. Arrêts notables (il y en a d'autres) : Digital Rights Ireland (2014, communiqué de presse), Tele2 Sverige et Watson (2016, communiqué de presse), La Quadrature du net ‒ LQDN ‒ et Privacy International (2020, communiqué de presse), Prokuratuur (2021, communiqué de presse), Commissioner of the Garda Síochána (2022, communiqué de presse), et SpaceNet (2022, communiqué de presse).
La conservation préventive, généralisée et indifférenciée des données de connexion est une atteinte disproportionnée à la vie privée, même si lesdites données ne sont pas exploitées, dès lors qu'un ensemble de données est susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne. Par dérogation :
(SpaceNet) La CJUE se montre inflexible. Le régime allemand post-2015 prévoyait : conservation 4 semaines pour la localisation, 10 semaines pour le reste, dans les deux cas uniquement pour les infractions particulièrement graves, sous le contrôle préalable d'un juge, par un mécanisme de conservation rapide, avec un cahier des charges technique pesant sur les opérateurs, etc. Pourtant, la CJUE le retoque car, indépendamment de la durée de la conservation, de la nature des données conservées, de la quantité de données conservées, et des conditions d'accès, il était « susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne ». Conclusion : la modulation de la durée, de la quantité, etc. n'a aucune incidence sur le raisonnement de la CJUE. On retrouve ce point dans Prokuratuur.
Analyse par les commentateurs :
2015-2020 :
2020 : dans son arrêt Breyer contre Allemagne (résumé ici), la Cour Européenne des Droits de l'Homme (CEDH) valide la collecte de données d'identité des détenteurs d'une carte SIM prépayée : l'ingérence est nécessaire et proportionnée.
2021-2022 : le Conseil d'État (avril 2021), la Cour de cassation (juillet 2022) et le Conseil constitutionnel (décembre 2021, mai et juin 2022) ajustent, a minima et à contrecœur, le droit français au droit de l'UE. Il s'agit de neutraliser l'effet de la jurisprudence de la CJUE.
Conseil d'État :
Sur la conservation :
Pas d'utilisation des données de connexion pour les autres infractions (non-graves), à l'exception des données d'identité.
Sur l'accès par les services de renseignement :
Arrêts de la Cassation (juillet 2022) :
Quand ces arrêts ont été rendus, la loi avait déjà changé (en juillet 2021 et en mars 2022, cf. infra) ;
Théoriquement, après les arrêts CJUE, le Parquet (le procureur), qui est l'autorité de poursuite (en sus de ne pas être indépendant de l'exécutif), ne peut plus valider les demandes d'accès aux données de connexion des OPJ dans les enquêtes préliminaires ou de flagrance (qui constituent l'écrasante majorité des investigations). Dans les informations judiciaires (commissions rogatoires), c'est le juge d'instruction qui valide les demandes. S'il est indépendant (magistrat du siège), il n'est pas extérieur à l'enquête, donc la CJUE risque de tiquer. Néanmoins, dans l'attente d'une réforme, la Cour de cassation a jugé qu'il n'y aura pas de nullité de procédure sauf si le prévenu peut montrer, au juge du fond, un préjudice, c'est-à-dire que l'accès à ses données de connexion aurait été interdit s'il y avait eu un contrôle indépendant. Il s'agit de la déclinaison du principe juridique « pas de nullité sans grief ». Donc les magistrats peuvent toujours demander l'accès aux données de connexion. Il s'agit d'un contrôle a posteriori à longue échéance. « La Cour de cassation […] a fixé des conditions si strictes qu’aucune nullité ne pourra être prononcée. » (source, page 123) ;
La Cour tolère l'exploitation, par ricochet, par le mécanisme de la conservation rapide, des données de trafic et de localisation recueillies à des fins de sécurité nationale dans des affaires de criminalité grave qui n'en relèvent pas, et le repêchage de données de connexion obtenues illégalement, ce que la CJUE interdit. À la demande d'un prévenu, un juge du fond pourra prononcer la nullité des réquisitions si elles outrepassent la stricte nécessité, mais même remarque que ci-dessus, en pratique, ça n'arrivera pas, et, là encore, il s'agit d'un contrôle a posteriori longtemps après, ce qui n'est pas conforme à la jurisprudence de la CJUE ;
Elle restreint l'exploitation des données de trafic et de localisation à la criminalité grave (ou aux atteintes à la sécurité nationale, j'vais y revenir). Comme il n'en existe pas de définition, c'est au juge du fond de décider ce qui en relève en fonction de la nature de l'infraction, au regard de la nature des agissements, du préjudice, des circonstances des faits, de la peine encourue, etc. c'est-à-dire, in fine, de la nature de l'infraction et de la peine encourue d'un côté, et de l'appréciation des circonstances sur le fondement des principes de nécessité et de proportionnalité, de l'autre. Ces faisceaux d'indice n'ont pas (encore ?) été repris dans le Code de procédure pénale ;
Conseil constitutionnel :
2021 :
mai : dans son arrêt Big Brother Watch et autres contre Royaume-Uni (communiqué de presse), la CEDH dégage des critères pour valider une législation nationale implémentant une surveillance de masse ou des échanges avec des services de renseignement étrangers. En clair, à mes yeux : les digues ont sauté, il est loin le temps de Klass et autres c. Allemagne et de son paragraphe 41 sur menace de surveillance = entrave à la liberté de communication.
La CEDH a mis en œuvre son contrôle in concreto habituel : point d'impératif absolu (comme dans la démarche première de la CJUE en 2014), mais la recherche d'une insuffisance cumulée de garanties ;
D'abord, en matière de surveillance de masse :
Ensuite, sur l'échange avec des services de renseignement étrangers :
juillet : ajustement à la marge du régime français par l'article 17 de la loi renseignement 2 (loi 2021-998 relative à la prévention d’actes de terrorisme et au renseignement) qui modifie les articles L34-1 CPCE et 6 LCEN, puis par l'édiction des trois décrets français qui régissent actuellement la conservation des données de connexion : 2021-1361 pour les opérateurs au titre du CPCE, 2021-1362 pour les hébergeurs et les opérateurs au titre de la LCEN, et 2021-1363 pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle contre la sécurité nationale.
Sécurité nationale : comme craint, le décret 2022-1327 a pris la suite du 2021-1363, puis le 2023-933, puis le 2024-901.
Conservation :
Accès :
2022 :
mars : deuxième ajustement à la marge du régime français par l'article 12 de la loi 2022-299 visant à combattre le harcèlement scolaire, notamment pour palier les inconstitutionnalités (cf. supra). Ajout de l'article 60-1-2 du Code de procédure pénal, vers lequel renvoient les articles 60-1 et 60-2 (réquisition en enquête de flagrance), 77-1-1 et 77-1-2 (enquête préliminaire), et 99-3 et 99-4 (information judiciaire) du même Code, afin de restreindre l'accès aux données de connexion (hors identité civile) aux infractions les plus graves : crime ou délit >= 3 ans de taule ; identification de l'auteur d'un crime ou délit >= 1 ans de taule commis via un réseau de communication électronique ; à la demande de la victime sur son matériel, si la taule est encourue ; ou recherche d'une personne disparue ou la reconstitution d'un parcours criminel.
septembre : arrêt C-339/20 de la CJUE (communiqué de presse) : les infractions d'abus de marché ne peuvent faire l'objet d'une collecte généralisée des données de connexion (l'Autorité des marchés financiers, AMF, avait obtenu des données de connexion recueillies en enquête pénale).
2023 :
En juin, le Conseil d'État a rendu ses décisions sur les décrets de 2021 / 2022 :
D'abord, la décision CE 468361 sur le décret 2022-1327 (injonction à conserver les données de trafic et de localisation pour la sécurité nationale), attaqué par Free et des individus :
Ensuite, la décision CE 459724 sur les décrets 2021-1361 et 2021-1362 (la conservation en elle-même), attaqués par Free :
En 2023, le Sénat a procédé à une mission d'information « sur les modalités d'investigation recourant aux données de connexion dans le cadre des enquêtes pénales ». Des auditions ont eu lieu en juillet et septembre 2023 (source : agenda de la rapporteure). Un rapport a été produit en novembre. Mes notes ici. En gros :
2024 :
En avril, la CJUE a rendu son arrêt LQDN contre HADOPI (C-470/21) :
Questions en suspens : obtenir l'identité civile à partir de l'adresse IP source d'une connexion est-il possible si l'infraction présumée ne relève pas de la criminalité grave ? Et si c'est le seul moyen d'identifier l'auteur présumé d'une infraction ? Faut-il un contrôle préalable par une autorité indépendante ? Quelles infractions relèvent de la criminalité grave ? ;
La CJUE répond que la correspondance entre une IP source et une identité civile peut être sollicitée pour toutes les infractions pénales, pas juste la criminalité grave, sauf si, conformément à sa jurisprudence antérieure (cf. supra), cela est susceptible de permettre de tirer des conclusions précises sur la vie privée, de tracer l'activité, de profiler l'utilisateur (aka ingérence grave dans la vie privée). Sans trop de surprise étant donné que l'inverse induirait une impunité totale ;
Un contrôle préalable et indépendant est obligatoire uniquement en cas d'ingérence grave. Par défaut, ce n'est pas le cas de l'obtention de l'identité civile à partir d'une IP.
Le délit de contrefaçon peut être considéré, par la France, comme relevant de la criminalité grave au regard de l'atteinte à un intérêt fondamental de la société (lol). Inversement, la contravention de négligence caractérisée n'en fait pas partie (en même temps, c'est dans son type : contravention). Sans trop de surprise au regard de la répartition des compétences entre l'UE et ses États-Membres, la définition de la criminalité grave est donc renvoyée aux États. C'est un désaveu de l'Avocat général qui, dans ses premières conclusions (point 74), proposait de considérer qu'une telle définition devrait être autonome. Je ne conçois pas l'intérêt qu'aurait la France à considérer que le délit de contrefaçon relève de la criminalité grave puisque la CJUE a validé l'obtention d'une identité civile à partir d'une IP pour toutes les infractions.
Sur la conservation, ce qui avait fait monter la CJUE dans les tours dans ses précédents arrêts, c'était qu'elle était confrontée à des législations, notamment la nôtre, française, qui prévoyait aussi la conservation de la date+heure + durée + type + destinataire de chaque communication (point 81). Si la législation prévoit uniquement la conservation des IP sources, c'est bon. Sauf que la législation française prévoit toujours, en sus de la conservation des adresses IP source, la conservation des données de trafic précitées et de localisation pour la sécurité nationale. Réponse de la CJUE (points 83 à 89) : la loi doit préciser de manière claire et précise les modalités de conservation. Ces modalités doivent inclure : la conservation de chaque jeu de données doit être séparée et étanche ; la mise en relation / combinaison (ex. : identité civile <> IP) doit être réalisée par un procédé technique qui ne remet pas en cause l'étanchéité (gné ?) ; la fiabilité de l'étanchéité doit être contrôlée par une autre autorité publique que celle qui accède aux données (vache, encore une entité de plus…). Bref, c'est de la cosmétique… ;
Divers :
2025 :
Sources pour rédiger cette section :
Gros résumé à la truelle de la section précédente.
En droit français (il n'y a plus de législation européenne sur le sujet, uniquement e-privacy qui la permet par dérogation), la rétention des données de connexion est codifiée dans :
Lire la section « Qui est concerné ? » infra sur la répartition des types d'acteurs entre CPCE et LCEN.
Plus précisément, les intermédiaires techniques doivent conserver :
L'accès aux données de connexion est régit par trois régimes :
Pour les enquêtes pénales :
Pour les services de renseignement :
Plein d'administrations disposent d'un droit de communication initialement accordé au fisc (L81 à L102 AH du Livre des procédures fiscales) : douanes (article 65 quinquies du Code des douanes), AMF (L621-10-2 du Code monétaire et financier), DGCCRF et ADLC (L450-3-3 du Code du commerce), sécu dont CAF (L114-19 à L114-21 du Code de la sécurité sociale), Pôle emploi (L5312-13-2 du Code du travail), URSSAF, inspection du travail (8113-5-2 du Code du travail), ANSSI (L2321-3 du Code de la défense), HADOPI (L331-14 du Code de la propriété intellectuelle), etc.
Ce droit porte sur plusieurs types de documents et données (relevé de compte bancaire, par ex.), dont les données de connexion. Rigolo : le Conseil constitutionnel aime rappeler que le droit de communication des données de connexion n'est pas assorti d'une exécution forcée, d'une contrainte, alors que, pour la HADOPI, par exemple, une contravention est prévue en cas de refus de répondre.
Toutes les administrations ne peuvent pas avoir accès aux données de connexion. Tel est le cas de la Sécu ou de Pôle emploi :
De même, toutes les administrations n'ont pas accès aux données de trafic et de localisation. Exemple : l'inspection du travail est limitée aux données permettant d'identifier l'auteur présumé de travail dissimulé (donc numéro de tél / adresse IP et identité civile), cf. 8113-5-2 du Code du travail.
Depuis 2018-2019, suite à des questions prioritaires de constitutionnalité et pour répondre au critère d'indépendance posé par la CJUE (l'autorité de poursuite ne peut pas être celle qui valide / contrôle l'accès aux données de connexion), l'AMF (2017-646/647 QPC), l'ADLC (2015-715 DC), et le fisc (2015-715 DC puis loi de finances pour 2021) demandent une autorisation préalable d'accéder aux données de connexion au Contrôleur des demandes de données de connexion (CDCD), c'est-à-dire un membre du Conseil d'État suppléé par un magistrat de la Cour de cassation (et inversement, par alternance). Voir ici et là.
Les autres administrations sont-elles soumises à un contrôle préalable ? La douane est soumise au contrôle du procureur, ce qui n'est pas conforme à la jurisprudence de la CJUE (mais c'est mieux que l'absence de contrôle d'avant la décision 2018-764 QPC). Le cas HADOPI est devant le Conseil d'État.
Pour les données de trafic et de localisation, est-ce que les crimes, les délits graves et les « manquements graves » dont ces autorités ont la charge relèvent de la gravité délimitée par la CJUE ? L'AMF s'est fait retoquer là-dessus (cf. 2022 dans la section « Historique »). Quid de la lutte contre les entraves à la concurrence (ADLC) ?
De là, se faire communiquer, via une injonction de conservation rapide, les données de trafic ou de localisation que les opérateurs collectent dans le cadre de la sécurité nationale (cf. 2021 dans la section « Historique ») pour traiter des affaires qui n'en relèvent pas, tient-il la route ? A priori, la CJUE a dit non (sauf ce que les intermédiaires techniques détiennent pour leurs besoins, mais la Cour de cassation a dit oui (cf. 2022 dans la section « Historique »).
Conservation :
Accès :
A priori, c'est dans un cadre juridique suisse similaire à celui de la France que ProtonMail a mouchardé l'adresse IP, le modèle, et l'identifiant du terminal de militants français (source). Il s'agit bien de données de compte / d'abonnement et d'identification (source d'une connexion).
On notera que la France a utilisé une procédure de coopération dédiée à la criminalité grave pour une affaire qui n'en relève pas et que les autorités suisses ont laissé faire (car ce n'est pas leur boulot de vérifier si des faits relèvent ou non des conventions d'entraide).
Pour obtenir une collaboration, il faut une équivalence de l'infraction dans le droit suisse (je ne suis pas convaincu que ça freine les demandes puisque les autorités ne reprochent jamais d'être un mouvement social mais des infractions précises comme trouble à l'ordre public, destruction ou dégradation de bien, etc. qui existent dans toutes les législations…).
Comme le note Reflets, on peut déplorer le flou dans la communication de ProtonMail, qui a changé plusieurs pages de son site web depuis cette histoire. Lire aussi l'analyse d'Alex Archambault.
Mais, quoi qu'il en soit, et comme l'écrit très bien Reflets, il existera toujours une conservation et un accès aux données de connexion. Toutes les législations prévoient ça. La vertu des arrêts CJUE et des contentieux LQDN, FFDN, FDN, c'est d'avoir nettoyé les imprécisions et les excès.
Il ne sert à rien de rechercher du « no log », VPN, TOR, etc. Ça ne sera que temporaire. Ça se fera défoncer par les autorités. Tout au plus est-il possible de jouer sur la temporalité, l'absence de coopération judiciaire, etc., mais ça ne se fait pas en souscrivant simplement à un service, cela demande plus d'efforts.
Une fois que l'on a écrit tout ça, comment savoir dans quelle catégorie entre un service usuel genre un site web personnel, et les obligations qui s'imposent à nous ?
Pour rédiger cette section, je me suis appuyé sur le travail du feu groupe juridique de la FFDN (copie ici) et sur le travail de LQDN (copie ici). On notera qu'il s'agit de brouillons. Ils sont faux en cela qu'ils ne tiennent pas compte des décrets de 2021. Le premier écrit ne faisait pas consensus au sein du groupe de travail, notamment sur l'interprétation à retenir (celle, militante, de la CJUE, ou celle du droit français). Ce pan du droit est vraiment ardu.
Deux catégories d'intermédiaires techniques sont concernées :
Les deux régimes (CPCE et LCEN) se recoupent en partie, notamment sur les données à conserver.
Dans les deux cas, la prestation peut être gratuite ou payante, et le fournisseur peut être une personne morale ou physique, ça ne change pas l'existence de l'obligation.
La définition d'un hébergeur est plutôt claire : stockage de signaux, d'écrits, d'images, de sons ou de messages pour leur mise à dispo via des services de communication au public en ligne.
Mais qu'est-ce qu'un opérateur de communications électroniques ? Les définitions sont dans l'article L32 du CPCE mais rien n'est clair. En gros, ça regroupe les personnes qui :
Sachant qu'une communication électronique, c'est toute transmission de signes, signaux, écrits, d'images ou de son par voie électromagnétique et qu'un service de communications électroniques est une prestation qui consiste à fournir de telles communications. Pourquoi le vocable change en plein milieu pour « communication au public » ? Bonne question.
On retrouve les opérateurs réseaux (première définition), les services de voix sur IP (VOIP) comme SkypeOut (deuxième), les Fournisseurs d'Accès à Internet (troisième), les fournisseurs de hotspots Wi-Fi (quatrième), etc.
Les hébergeurs ne sont pas englobés dans la deuxième définition. Par défaut, les fournisseurs de messagerie électronique non plus (je vais y revenir).
La notion qui revient est le caractère public. Un réseau privé n'est pas concerné. (C'est d'ailleurs pour cela que plusieurs entités qui opèrent un réseau informatique à une échelle métropolitaine, par exemple, destiné à un nombre prévisible d'utilisateurs (les salariés et clients / usagers de ces entités, par exemple) prennent le statut juridique de Groupe Fermé d'Utilisateurs ‒ GFU ‒, pour s'éviter les contraintes précitées du CPCE.) L'accès à Internet fournit par un employeur à ses seuls salariés / agents n'est pas concerné. Les services non-publiés (intranet, correspondance privée) ne sont pas concernés.
J'ai un blog Wordpress et un shaarli. Il s'agit de services de communication au public en ligne (article 6, III, 2 de la LCEN) dont je suis l'éditeur (au sens de la loi sur la presse). À ce titre, mon hébergeur doit conserver des données sur moi.
Dans les deux cas, comme sur les réseaux sociaux, d'autres personnes peuvent écrire des articles ou des commentaires. La loi permet deux statuts : soit je suis éditeur (au sens de la loi sur la presse), soit hébergeur (au sens de la LCEN).
Si je modère mes commentaires a priori et à la mano, je suis éditeur de facto, car je choisis les contenus, j'ai le contrôle de ce qui est publié. Le Bon Coin a été reconnu hébergeur en 2014 car les annonces sont modérées par un logiciel (source).
A priori, si j'octroie des droits de publication à un nombre restreint de personnes que je choisis, je suis aussi éditeur, je choisis toujours le contenu, ce n'est pas le tout-venant qui peut publier sur mon site. On notera qu'en droit de la presse, il y a une cascade de responsabilités : l'éditeur (ou le dirlo de publication) sera poursuivi, à défaut ou au titre de complicité, les auteurs aussi, à défaut les imprimeurs, à défaut les diffuseurs, donc, a priori, un éditeur n'a pas obligation de consigner qui a écrit quoi (juste il morflera seul).
Les réseaux sociaux jouent sur les deux tableaux : ils se prétendent hébergeurs mais rendent visibles ou invisibles des contenus, les hiérarchisent, les font modérer selon une charte qui leur est propre par des travailleurs sous-payés (troisième point du 2e bloc), etc., ce qui semble constituer un rôle éditorial. Cependant, la question est loin d'être évidente à résorber, lire 1, 2, 3, 4.
Généralement, la consignation des données relatives aux auteurs de contenus (commentaires, articles, etc.) est effectuée par le site web lui-même, par son code, dans sa propre base de données.
Les requêtes de lecture / consultation d'un site web ne doivent pas faire l'objet d'une journalisation au nom d'une prétendue obligation légale qui n'existe pas. L'article 6 de la LCEN et le titre du décret 2021-1362 sont clairs : l'obligation vise uniquement les personnes qui ont contribué à la création d'un contenu.
Pages Jaunes, qui conservé un tel journal des consultations, s'est ramassée sur ce point en ce quelle n'était pas hébergeur de contenus tiers (cf. section 5 de la délibération 2011-203 de la CNIL qui est l'objet du jugement précité), donc qu'il n'y avait aucun contributeur de contenu à identifier, donc pas d'obligation légale, donc une conservation dénuée de base légale.
D'autres finalités peuvent conduire à journaliser les consultations / lectures / accès, cf. section « Journaux techniques » ci-dessous, mais pas la rétention des données de connexion.
Dans mon cas, j'ai fermé les commentaires sur mon blog (mais sinon Wordpress consigne le cœur des données qu'il est obligatoire de conserver), je n'ai plus publié de contributions extérieures depuis 2011 (et Wordpress ne consigne pas les informations nécessaires), et je suis le seul auteur sur mon shaarli. Je suis uniquement éditeur, donc j'ai rien à conserver au titre d'hébergeur.
Évidemment, mes sites web non-publiés (gestionnaire de ToDo, GLPI, agrégateur RSS, etc.), dont je suis le seul utilisateur, et qui font l'objet d'une restriction d'accès par identifiant+mdp ou par adresses IP, ne sont pas des services de communication au public en ligne, donc ils sont hors périmètre (usage strictement personnel).
Garder un journal des accès web pourrait également permettre de se disculper en cas de piratage qui conduirait à la publication d'un contenu illégal plutôt que d'en assumer la responsabilité éditoriale. D'un côté, il faut que l'attaquant publie sa prose via le web (sinon il ne sera pas journalisé par le serveur web, et à part ça, j'ai uniquement un accès SSH (qui ne consigne pas les actions) et la probabilité d'une attaque réussie diminue avec des logiciels maintenus à jour. D'un autre côté, un tel journal sera inexploitable car l'attaquant se dissimulera derrière des rebonds / intermédiaires, et le contenu, qui sera temporaire (car je m'en rendrais compte rapido) et qui ne relèvera pas de la diffamation / injure / harcèlement / appel à la haine / dénigrement / etc. mais plutôt d'actes rentables genre vente de Viagra, ne sera jamais poursuivi, donc l'occasion de dégainer le journal n'existera pas. Tout montre qu'un tel journal est inutile. Sans compter qu'un piratage doit faire partie des cas de force majeur ou équivalent ("j'ai mis en place des mesures de sécurité, elles ont été contournées, c'est pas d'chance").
J'ai jamais lu que des commentaires ou articles de blog constituent une fourniture de service de communications électroniques entraînant l'application du régime prévu par le CPCE. La directive-cadre européenne 2002/21/CE dispose même de l'inverse (cf. arrêt C‑193/18 de la CJUE, points 29 à 31).
Il s'agit de correspondance privée qui s'entend comme un nombre prévisible et déterminé de destinataires individualisés. Il y a donc une communauté d'intérêt entre l'expéditeur et les destinataires. Cela a été tranché par les juridictions, y compris pour le spam… C'est différent d'un site web ou d'un profil ouvert sur un réseau social auxquels tout le monde peut accéder sans restriction. Donc le statut d'hébergeur ne s'applique pas (puisqu'il n'y a pas mise à dispo via des services de communication au public en ligne).
A priori, les listes de diffusion, les MUC (discussion de groupe) Jabber, IRC, et tant d'autres entrent également dans ce cadre-là.
Attention : parfois, un même service peut relever de plusieurs statuts. Exemple : la publication web ouverte au public des archives d'une liste de discussion ou la mise à disposition au public de pièces jointes ou de calendriers par un webmail (type GMail) sortent du cadre de la correspondance privée, donc le statut d'hébergeur s'applique. J'ai rien de tout ça, donc je suis peinard.
Suis-je un opérateur de communications électroniques ? Auquel cas, la rétention à ce titre s'appliquerait, quand bien même celle à titre d'hébergeur ne s'applique pas. La question se pose pour de gros fournisseurs de messagerie, car si la correspondance est privée, le service en lui-même est ouvert au public (tout le monde peut ouvrir une adresse Outlook, par ex.).
La CJUE a tranché : GMail n'est pas un service de communications électroniques car sa fonction première n'est pas la transmission de signaux (cette charge est majoritairement portée par d'autres acteurs du réseau, quand bien même Google dispose de son propre réseau mondial), donc Google n'est pas un opérateur de communications électroniques, donc le CPCE ne concerne pas GMail. Les juridictions suisses ont tranché dans le même sens pour ProtonMail.
Comme le relève le Conseil d'État (note 48 pages 13 et suivante), la CJUE semble se contredire dans son arrêt LQDN de 2020, sauf à considérer que la différence entre SkypeOut (qui a été reconnu service de communications électroniques) et GMail est que SkypeOut assure, contre rémunération, la responsabilité de la transmission des communications en vertu d'accords passés avec des opérateurs télécoms là où GMail n'en fait rien, que l'essentiel du transport des emails est assumé par d'autres acteurs en best effort.
Sur la qualification juridique de GMail, on peut lire cet excellent historique.
Conclusion : je ne suis concerné ni par la LCEN, ni par le CPCE pour mes serveurs emails et de messagerie instantanée.
De toute façon, j'utilise la fonctionnalité « smtpd_sender_login_maps » de Postfix qui permet d'associer une adresse d'expéditeur à un identifiant+mdp. Donc, si, du temps où mon serveur emails hébergeait aussi une partie de ma famille (ce qui n'est plus le cas, j'en suis le seul usager), les autorités avaient débarqué pour me demander qui a émis tel email à telle date, etc., tant qu'elles me donnaient l'adresse de l'expéditeur de l'email litigieux, je pouvais dire avec certitude, et sans journal, qui en était l'auteur (sauf en cas de vol de l'identifiant+mdp, mais bon…).
Cf. les décrets 2021-1361 (pour les opérateurs au titre du CPCE), 2021-1362 (pour les hébergeurs et les opérateurs au titre de la LCEN) et 2021-1363 (pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle pesant sur la sécurité nationale), ainsi que l'arrêt 459724 du Conseil d'État (CE) qui précise de nombreux points, dont le fait qu'on conserve uniquement ce que l'on collecte dans le cadre normal de l'activité (source) aka ne pas avoir toutes les données n'est pas un problème (en n'avoir aucune, en revanche…, cf. supra).
Pour la participation à l'identification de l'auteur d'un contenu (LCEN), cinq jeux de données sont prévus :
Facturation. Type de paiement, référence du paiement, montant, date et heure (et lieu si transaction physique). Conservation : 1 ans après la fin du contrat ;
Informations techniques sur un terminal ou la source d'une connexion. Conservation : 1 an à compter de la connexion ou de l'utilisation du terminal ou la création d'un contenu.
Il en va de même pour identifier l'auteur d'une communication (CPCE), à quelques variantes près : il faut conserver également le numéro de téléphone appelant (RTC, par ex.), le numéro d'identification du terminal (CE : « données relatives aux connexions internet fixes par wi-fi ». Je comprends adresse MAC) ; les caractéristiques techniques (CE : « données collectées par l'opérateur pour effectuer et justifier la facturation de l'abonné et gérer son réseau, tels que le sens de l'appel, le type d'appel, le rôle de l'abonné, le type de communication ou le volume de données échangées »), date, heure et durée de chaque communication ; les données relatives aux services complémentaires utilisés (CE : « services complémentaires à la fourniture de communication par internet ou par téléphonie, tels que, notamment, les renvois d'appels ou le recours à un commutateur téléphonique privé ») ; les données techniques relatives au terminal et à la connexion (le 4e jeu de données ci-dessus) du destinataire ; et la localisation des communications par téléphone mobile.
Comme le relève Alexandre Archambault, la législation dit que tu peux conserver uniquement ce que tu collectes (cf. article 8 du décret 2021-1362, par ex.), mais l'article 39-3 du CPCE et l'article 6, VI de la LCEN prévoient des peines de prison et d'amende pour non conservation…
J'ai toujours interprété ça comme une manière de sanctionner une intention délibérée d'entraver les services enquêteurs : si t'as aucune donnée, c'est louche, s'il t'en manque certaines, ça passe. Exemples : il n'y a pas de facturation dans le cadre d'une prestation gratuite genre devenir auteur sur mon site web ; il n'y a pas de mécanisme de vérification du mdp pour un commentateur de blog ; il est techniquement impossible de fournir les données techniques du terminal du destinataire s'il n'est pas chez le même opérateur ; un hébergeur de machines virtuelles ne peut pas journaliser les modifications de contenus de son client à cause de la démarcation technique (mais il détient les jeux de données 1 à 3) ; etc. L'arrêt 459724 du CE me conforte dans cette interprétation.
De même, si l'on regarde bien, des outils comme Wordpress ou shaarli ne collectent pas toutes les informations exigées d'un hébergeur : date et lieu de naissance d'un commentateur ? Nature, date et heure d'une opération sur les contenus d'un shaarli ? Etc. Wordpress ne permet même pas de supprimer automatiquement au bout d'un an les données personnelles des auteurs de commentaires (son outil « Effacer les données », en sus de ne pas répondre au besoin ‒ il est conçu pour les demandes RGPD ‒, laisse intacte l'adresse IP, seuls le pseudo et l'adresse emails sont effacés).
Je ne peux m'empêcher de penser que c'est à cause de ça qu'il y a une légende urbaine sur une prétendue obligation de conserver le journal des accès à un serveur web ou le journal d'un serveur emails pendant un an. Démystification : 1, décision du CE contre Pages Jaunes, et explications ci-dessus.
En effet, le cœur des informations exigées (identifiant du contenu, adresse IP de l'auteur, protocole, nature de l'opération, date et heure) peuvent apparaître dans le journal des accès d'un serveur web (l'identifiant du contenu et la nature de l'opération peuvent être précisés dans l'URL, genre, pour shaarli : « POST /?edit_link=20230709_204855 »). Un conseil d'avocat sur le vif consistant à recommander cette journalisation permet d'être agnostique du type de site web utilisé et de ses capacités de journalisation, et donc de protéger le client dans le plus de cas possibles (objectif d'un avocat). Sachant que tout dépend de la question posée, du contexte présenté à l'avocat, etc., ça me paraît crédible.
Bien évidemment qu'on conserve des journaux informatiques, y compris ceux contenant les consultations de contenus, pour d'autres motifs qu'une obligation légale, tels que l'identification et le diagnostic d'un incident ou la sécurisation d'un système (détecter une compromission, parer automatiquement une attaque, etc.).
Mais cela ne peut pas être fait sous couvert de l'obligation légale présentée dans ce shaarli, il faut distinguer les finalités et la base légale, adapter la durée de conservation, etc., et, si les journaux consignent des données personnelles (comme une adresse IP), il faut les anonymiser (selon la finalité, genre vaut mieux anonymiser après l'usage du journal par fail2ban, par ex., sauf à prendre tout intérêt ;) ).
Évidemment, le RGPD s'applique aux journaux contenant des données personnelles.
S'ils répondent aux obligations présentées dans ce shaarli, pour les éléments demandés, alors la base légale est l'obligation légale, la finalité et la durée de conservation sont précisées dans les décrets, etc. Il n'y a plus qu'à y appliquer le reste du RGPD (sécurisation, traçabilité des accès, information, ne pas divulguer tout et n'importe quoi même dans le cadre d'une décision de justice, etc.).
En revanche, si les obligations présentées ci-dessus ne t'incombent pas ou si tu souhaites journaliser plus d'éléments ou pour une durée supérieure à celle prévue par la législation ou en faire un autre usage que ceux prévus par la législation, il faut une base légale et une finalité en adéquation, une nécessité, etc. Ex. : faire des stats d'audience à partir d'un journal des accès d'un serveur web reposera très probablement sur l'intérêt légitime, et la durée de conservation (avant anonymisation) sera proportionnée à cette finalité. Un journal technique pour détecter les attaques et les compromissions reposera probablement sur l'intérêt légitime (idem). Etc.
Dernière mise à jour : août 2025.
J'aime beaucoup la présentation du protocole et le retour d'expérience (les embûches rencontrées et les contournements mis en œuvre genre les recruteurs qui redirigent vers un site web maison d'où un vivier d'offres limité, les recruteurs qui posent des questions imprévisibles, etc.).
Je ne suis pas surpris :
J'ignorais que :
Chiffres :
Il reste plusieurs biais dans la méthodologie :
Je ne suis pas d'accord pour affirmer qu'un premier entretien coûte rien aux sociétés commerciales. C'est une organisation et du temps supplémentaire pour étudier la candidature de manière plus approfondie, donc du fric.
Cela fait 10 ans que mes seules adresses emails personnelles sont liées à mes noms de domaine personnels, et que j'héberge et administre moi-même mes serveurs emails. \o/
Au global sur dix ans, ça tourne sans trop de douleur ni d'entretien. Mais, attention, cela dépend très fortement de l'usage.
En effet, tout administrateur d'un serveur emails doit s'atteler à deux problématiques : le spam entrant, et l'acceptation collective des emails qu'il envoie (émails sortants).
Je n'ai pas d'antispam, pas même de greylisting. Cela exige organisation et rigueur permanentes. Je communique ma véritable adresse uniquement à des gens de confiance et je file une adresse générique ‒ un alias ‒ ou une version suffixée par un délimiteur / tag aux autres, surtout aux sociétés commerciales, aux windowsiens et aux listes de discussion archivées sur le web. (Les alias et les délimiteurs sont également très pratiques pour tracer la revente / fuite d'une adresse emails et pour trier ses emails ‒ on peut ignorer l'adresse d'expédition et/ou elle peut changer en cours de route, ça n'a pas d'incidence sur le tri opéré sur l'adresse de destination, c'est-à-dire l'alias / le délimiteur ‒.) Mon seul regret est de ne pas avoir filé une telle adresse à plus de gens, par faiblesse. Heureusement, je comptabilise une unique conséquence fâcheuse. Bref, rigueur et ténacité. De plus, je n'ai pas besoin d'être contacté par le tout-venant, ce qui simplifie grandement la problématique.
L'acceptation collective se divise en deux : la norme et l'arbitraire. C’est essentiellement l'usage (volumétrie, contenu, destinataires) qui fait passer un serveur emails de l'une à l'autre de ces catégories.
J'ai mis en place toutes les techniques normalisées et informelles : le nom d'hôte EHLO (durant le dialogue SMTP) est déclaré dans le DNS, les adresses IPv4 et IPv6 pointées par ce nom sont celles de mon serveur, et j'ai configuré un reverse (PTR) pour chacune ; SPF ; DKIM ; ADSP ; DMARC ; TLS (avec un certificat auto-signé) + DNSSEC + DANE TLSA, etc. Pour un petit serveur emails (faible volumétrie), tout cela n'est pas obligatoire : DMARC et DKIM sont rarement imposés (GMail impose SPF ou DKIM), ADSP et DANE TLSA encore moins. C'est un investissement notable, mais quand c'est en place, ça ne coûte pas de temps de maintenance.
Surtout, les adresses IP du serveur emails doivent avoir une excellente réputation, c'est-à-dire ne pas traîner dans des listes de blocage (ce qui n'est pas le cas d'OVH, par ex.). SPF, DKIM, ADSP, DANE, etc. servent à rien si tes IP sont tricardes. Donc, il vaut mieux héberger son serveur emails chez un petit prestataire car plus c'est confidentiel, plus ça diminue la probabilité d'avoir des serveurs voisins spammeurs ou mal configurés. En IPv6, le blocage se fait par réseau de taille /64, donc pour ne pas être pénalisé par le comportement d'un voisin de réseau, il faut que l'hébergeur attribue au moins un /64 à ton serveur emails.
Comme tout cela ne suffit pas pour contrer le spam, il y a l'arbitraire. Des réseaux entiers, notamment ceux résidentiels, et des hébergeurs sont bloqués, temporairement ou non, car ils sont considérés comme des spammeurs notoires. Il existe des formalités administratives spécifiques à chaque fournisseur (ex. : Microsoft SNDS et JMRP) que j'ai toujours refusées d'accomplir (les normes, c'pas pour les chiens). Des mots-clés légitimes dans le corps d'un email sont bloqués. Des liens et des PJ légitimes et sans virus sont bloqués. La cadence de fournisseurs de liste de discussion légitimes est freinée. Sitôt qu'on grossit, à peu près tous les fournisseurs emails d'envergure cassent les pieds. Microsoft et GMail sont souvent cités mais c'est également la corvée avec Orange (qui limite la cadence autant que GMail) ou SFR Business (rejet arbitraire en fonction du contenu) ou…
Beaucoup attribuent une intention malveillante aux gros fournisseurs emails : ils voudraient fermer le marché, maintenir un oligopole afin de rendre captifs les usagers de l'email et exploiter toujours plus leur vie privée (GMail analyse le contenu des emails, La Poste ou ProtonMail modifient celui des emails sortants afin d'ajouter leur pub). C'est vrai, bien sûr, mais il ne faut pas expliquer par la malveillance ce que l'on peut expliquer par l'incompétence : à grande échelle, le spam est difficile à juguler et il est possible que les gros fournisseurs emails agissent pour le Plus Grand Bien (tm), mais leur part de marché, donc l'absence de contre-pouvoir, leur permet des prises de position cavalières qui, de fait, ne sont pas remises en question en interne. Une sorte de "ça marche / ça fait le job, je cherche pas plus loin, je réfléchis pas collectif / global" prononcé par un géant. Le poids des acteurs, voilà le cœur du problème, comme bien souvent. La concentration est néfaste. Et de ça, nous tous sommes responsables (absence de formation, laisser-aller vers la facilité, etc.).
Quand j'écris qu'un serveur emails perso tourne sans douleur ni entretien, c'est donc fonction de l'investissement technique initial sus-relaté, du fait que je suis un utilisateur avancé (alias, délimiteur, etc.), que je n'ai pas une quasi-obligation de recevoir les emails du premier venu, que j'émets un très faible volume d'emails (pas d'emails transactionnels ni de listes de discussion, etc.), que je converse plutôt avec des initiés (donc j'évite de fait les pénibles genre Orange, Microsoft Hotmail / Outlook, etc.), etc. Mon constat n'est pas transposable à des organismes (association, société commerciale, administration, peu importe) qui, eux, ont vocation à être ouverts au public, qui peuvent émettre un volume conséquent d’emails légitimes, qui ont des utilisateurs lambda donc peu formés, peu rigoureux, mais exigeants, etc.
Il y a bientôt un an, cet article a beaucoup circulé. Il dit vrai, bien entendu. Mais il manque des nuances que j'ai tenté d'apporter ici. Sans compter la prédominance erronée de l'analyse économique : à l'échelle de Microsoft / Orange / Google, etc., une analyse bayésienne coûte rien, mais sur un grand volume et une diversité d’usagers, elle est inefficace (beaucoup de faux-positifs), notamment car son apprentissage dépend de chaque usager et de sa bonne volonté et foi. Je partage partiellement son avis sur les bandeaux cookies : beaucoup de traitements de données persos étaient illicites depuis longtemps. Ils ne devaient pas perdurer, mais, plutôt que de changer de modèle économique, les acteurs continuent leurs pratiques crades en essayant d’obtenir un consentement vicié, tel le premier charo venu. Les traitements devraient reposer sur des bases légales plus saines, et le consentement devrait être l'exception, pas un prétexte pour dégainer n'importe quel traitement. La seule chose blâmable est la faiblesse des régulateurs.
En fonction de l'usage, un serveur emails perso est encore vivable.
P.-S. : il y a une différence entre l'offre gratuite de Microsoft (Hotmail / Live / Outlook) et les autres (Office 365, etc.). Mon serveur s'est toujours fait écourter quand je contacte des utilisateurs d'Outlook, et l'année écoulée n'a pas fait exception, mais, comme d'habitude, j'ai reçu des réponses de deux des trois destinataires professionnels dont le nom de domaine est porté par les serveurs emails de Microsoft (aucune idée si le troisième a voulu me répondre, mais, je le suppose, demande de devis, tout ça).
Quand on a un certificat auto-signé ou signé par une autorité de certification maison :
For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.
nocerts.example.com CAA 0 issue ";"
CAA utilise l'aspect arborescent du DNS donc une autorisation vaut pour le domaine visé et ses sous-domaines. ;)
J'ai déménagé mon serveur perso (pas celui qui héberge ce site web). Retour d'expérience.
Initialement, ce serveur était hébergé chez moi, sur un Raspberry Pi puis sur un OLinuXino, et raccordé proprement au réseau (condition pour avoir un serveur emails fonctionnel) avec le VPN d'un FAI associatif.
Quand ces ordinateurs ont rendu l'âme (avant les cartes SD, comme quoi), j'avais une contrainte personnelle de forte mobilité. J'ai donc hébergé ce serveur avec les autres auprès d'associations auxquelles je contribuais techniquement et financièrement, ARN et Grifon.
Début 2019, par démotivation et désespoir, j'ai quitté le monde associatif. Comme il est inconvenant de faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement (ne serait-ce qu'à la prise de décision), j'ai déménagé au plus simple : OVH. Ça fait le boulot pour pas cher. C'était censé être temporaire. Mais la flemme s'est installée.
Mon problème est simple : mes emails arrivent de moins en moins jusqu'à leurs destinataires. Quand j'étais auto-hébergé ou chez des assos, seuls quelques fournisseurs emails hégémoniques donc casse-couilles me rejetaient comme Microsoft. À l'inverse, ces derniers mois, je suis tricard, temporairement ou non, chez pas mal d'autres fournisseurs : Infomaniak, Octopuce (qui utilise Spamhaus), SFR (ceci dit, même les serveurs de Gandi se font rejeter), FDN (qui utilise Spamhaus sur ses anciennes listes de discussion), etc.
Deux explications :
MilkyWAN : je leur ai posé deux questions techniques (modèle d'hyperviseur et existence d'un VNC) en septembre 2022, pas de réponse. J'ai bien reçu l'accusé de réception émis par leur formulaire web.
FirstHeberg (anciennement FreeHeberg) :
Ikoula :
PulseHeberg :
Ligne Web Services (LWS) :
OuiHeberg :
OMGSERV :
ONETSolutions :
Chiffres d'affaires 2021 :
Source : societe.com.
J'ai choisi FirstHeberg.
Concernant le port tcp/25 (email), il est bloqué uniquement en sortie et en IPv4. Mes justificatifs caviardés (j'ai conservé les seules infos légalement obligatoires, cf. ci-dessus) ont été acceptés. Contrairement à ce que prétend le site web, le port tcp/587 n'est pas bloqué.
L'espace client ne permet pas de définir un reverse IPv6, mais une demande d'assistance permet de l'obtenir.
L'assistance est plutôt réactive et les réponses sont plutôt de qualité.
Évidemment, tout n'est pas parfait :
On verra comment ça se passe à la longue.
Mon système Debian GNU/Linux est chiffré en intégralité (sauf /boot, même si GRUB permet de s'en passer).
Même procédure que d'habitude. J'ai rencontré aucun des problèmes mentionnés. Ni partition mal copiée ni difficulté pour monter les partitions fraîchement copiées.
J'ai changé la phrase de passe du conteneur chiffré (cryptsetup luksAddKey /dev/sdX
+ cryptsetup luksRemoveKey /dev/sdX
). J'en ai profité pour passer sans encombre à la version 2 de LUKS (cryptsetup convert --type luks2 /dev/sdX
) et à l'algo de dérivation de clé argon2id (cryptsetup luksConvertKey --pbkdf argon2id /dev/sdX
).
Prenant en compte la panne du VNC (cf. ci-dessus), j'ai mis en place un système me permettant de saisir la phrase de passe de mon système chiffré via SSH.