GuiGui's Show

Conséquence de mes shaarlis précédents du jour, j'ai mis à jour le bilan de mes réclamations CNIL et ses statistiques.

Pour résumer : j'ai déposé de nouvelles réclamations. À part ça, rien a évolué : mes réclamations, transmises au service des plaintes, n'ont pas reçu de réponse.

J'ai acheté des produits à la FNAC puis j'ai eu recours à son SAV (là encore, un réparateur local ne pouvait rien faire car l'équipementier ne vend pas la pièce détachée).

Des emails transactionnels contiennent des liens et des images de traçage (détecter l'ouverture ou un clic sur un lien). L'essentiel est diffusé via le CDN de la société commerciale états-unienne Akamai Technologies.

Mêmes les images rédactionnelles (qui participent au contenu) sont diffusées via Akamai Technologies ou Amazon ou Google. Les emails contiennent également des polices de caractères Google Fonts.

Le site web de la FNAC est diffusé via le CDN d’Akamai Technologies 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 : assets.adobedtm.com et s.go-mpulse.net = Akamai, cdn.cookielaw.org et cdn.kaminoretail.io = Cloudflare, halc.iadvize.com, cdn.caast.tv et datadome.co = Amazon Cloudfront, via.batch.com = HAProxy Technologies, Inc. Liste non exhaustive, il y en a plusieurs dizaines.

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à.

Ces manquements au RGPD perdurent depuis juillet 2021 a minima.

Du coup, hop, réclamation déposée auprès de la CNIL il y a plusieurs mois.

Réclamation

Bonjour,

Le 15/03/2023, j’ai commandé un produit à la FNAC (en présentiel). En janvier 2023, j’ai initié une démarche de SAV. En 2021, j’ai acheté un produit (en ligne).

Dans le cadre de chacune de ces démarches, la FNAC m’a envoyé des emails sur le déroulé / suivi de ma commande / SAV. Ces emails sont regroupés dans la PJ 1.

Des emails (« Vous avez demandé l'annulation d'un article », « Message important - Votre commande N° […] – N° logistique […] », « Confirmation d'inscription Fnac.com ») contiennent une image de traçage (1 pixel * 1 pixel, transparente, dont le nom comporte un identifiant unique, cf. votre terminologie https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger). Elles permettent de détecter et de consigner l’ouverture d’un email. Elles sont diffusées via le nom de domaine « fr.r.emails.fnac.com ».

Ces images sont diffusées via le CDN de la société commerciale états-unienne Akamai Technologies. Cela signifie qu’à l’ouverture de l’email par le client FNAC, ces images seront téléchargées automatiquement. Il y aura donc un contact direct entre le logiciel de messagerie du client FNAC et les serveurs informatiques d’Akamai, ce qui générera un transfert illégal de données personnelles (adresse IP du client FNAC, empreinte de son logiciel de messagerie, etc.) vers un État tiers non adéquat.

Des emails (« Vous avez demandé l'annulation d'un article », « Message important - Votre commande N° […] – N° logistique […] », « Confirmation d'inscription Fnac.com ») contiennent des liens de traçage constitués de deux identifiants uniques, l’un permettant d’identifier une campagne emails parmi toutes, l’autre un email précis dans une campagne. Ils servent à détecter un clic sur un lien avant redirection vers la destination finale (site web officiel FNAC, réseaux sociaux, etc.). Ces liens utilisent les noms de domaine « fr.r.emails.fnac.com » et, en 2021, « https ://eultech.fnac.com/dynclick/ » (de la société commerciale française Eulerian spécialisée dans le e-marketing et l’analyse de données, qui s’est distinguée en 2019 en vendant des traqueurs first-party à des journaux, comme Libération).

Notons que les liens de la forme « fr.r.emails.fnac.com » pointent sur des serveurs informatiques d’Akamai. Cela signifie que le navigateur web du client FNAC qui cliquera dessus contactera ces serveurs avant d’être redirigé vers la destination finale prévue par la FNAC (son site web, ses réseaux sociaux, etc.). Il y aura donc un contact direct entre le navigateur web du client FNAC et les serveurs informatiques d’Akamai, ce qui générera un transfert de données personnelles (adresse IP du client FNAC, empreinte de son navigateur web, etc.) vers un État tiers non adéquat.

Ces images et liens 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). La FNAC n’est pas soumise à 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 FNAC n’est pas informé et ne consent pas à ces traitements.

Tous les emails contiennent des images rédactionnelles (des images qui participent au contenu de l’email) diffusées via le CDN d’Akamai (« www4-fr.fnac-static.com », « static.fnac-static.com », « fr.f.emails.fnac.com », « multimedia.fnac.com »). Dans certains emails (« Vous avez demandé l'annulation d'un article » et « Votre commande vous attend dans votre magasin Fnac […] »), des images supplémentaires sont téléchargées depuis les serveurs informatiques de la société commerciale états-unienne Google (« www.gstatic.com »). Des polices de caractères du service Fonts de la même société le sont également. Enfin, l’email « Votre commande Fnac.com du […] » contient des images téléchargées depuis les serveurs informatiques de la société commerciale états-unienne Amazon (« banners.wlservices.fr »). Toutes 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 FNAC et les serveurs informatiques d’Akamai, de Google, et d’Amazon, ce qui génère des transferts illégaux de données personnelles (adresse IP du client FNAC, empreinte de son logiciel de messagerie, etc.) vers un État tiers non adéquat.

Le site web de la FNAC (texte, images, etc.) est lui-même diffusé via le CDN d’Akamai Technologies, y compris l’espace client et sa phase d’identification (« secure.fnac.com »). À l’instant même de sa consultation, il fait automatiquement télécharger plusieurs scripts JavaScript de sociétés commerciales états-uniennes et/ou qui sont hébergés par de telles sociétés : assets.adobedtm.com et s.go-mpulse.net = Akamai, cdn.cookielaw.org et cdn.kaminoretail.io = Cloudflare, halc.iadvize.com, cdn.caast.tv et datadome.co = Amazon Cloudfront, via.batch.com = HAProxy Technologies, Inc. Liste non exhaustive, il y en a plusieurs dizaines, je n’ai pas l’énergie de tout cartographier, surtout que ça peut changer souvent.

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 l’utilisation de Google Analytics, décision de l’APD autrichienne du 22 avril 2022 portant sur l’utilisation de Google Analytics, décision 3_O_17493/20 de la Cour régionale de Munich portant sur l’utilisation de Google Fonts, 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 la FNAC (https://www.fnac.com/Help/donneesPersonnelles) se contente d’affirmer que « préalablement au transfert hors Union Européenne, FNAC DARTY prendra toutes les mesures et garanties nécessaires pour sécuriser de tels transferts. »… Bref, la FNAC met en œuvre aucune mesure complémentaire dans le cadre des transferts internationaux sus-décrits. Je rappelle que la localisation effective des serveurs informatiques et des données importe peu, la nationalité états-unienne des sociétés détentrices l’emporte pour l’application du Cloud Act.

Tout ce qui précède illustre une carence de la FNAC 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.

Toutes les infractions énumérées dans la présente perdurent depuis juillet 2021 a minima.

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 FNAC.

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.

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.

Réclamation

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.

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.

Réclamation

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.

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.

Réclamation

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.

Réponse du DPO de la CNIL du 21/07/2023

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,

Ma réponse du 23/07/2023

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…

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 :

• On déporte le suivi chez quelqu'un, donc il faut s'assurer qu'il fasse le taff, comme on l'entend (avec le même modèle de menace, les mêmes compromis sécurité / confort, etc.). Ça suppose de regarder ce qui est fait sur le temps long. Il n'est jamais trop tard pour commencer, donc ce n'est pas un argument ;
  
  
• Des paramètres sont ajoutés ou retirés à chaque nouvelle version de Firefox, donc il faut prévoir un fichier user.js adapté à chacune, me disais-je. Arkenfox le fait. Parfait ;
  
  
• Comment faire si j'ai des désaccords sur un compromis (je souhaite activer un paramètre qu'Arkenfox désactive) ? Il y a toute une mécanique prévue pour redéfinir les paramètres. Parfait ;
  
  
• J'ai lu l'intégralité du wiki (à l'exception des annexes), et ça m'a donné confiance : sur plusieurs points, on sent qu'il sait ce qu'il fait. J'ai quelques désaccords, comme la désactivation d'IPv6 (mais que je la comprends dans le contexte présenté) ou l'inutilité de l'extension LocalCDN, ou les choix webRTC qui me semblent imprudents et moins optimaux que ce que je peux me permettre dans mon cas d'usage (mais les choix présentés sont plus confortables que les miens), mais rien de grave.

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. :)

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.

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.

Ce qui fonctionne

Un journal par logiciel, un dossier par service

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 :

• Un fichier journal par logiciel, pas de duplication ;
  
  
• Quand plusieurs logiciels concourent à un même service (mail = postfix, dovecot, etc.), je crée un dossier qui contient un journal par logiciel ;

Ç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.

Séparer les archives dans une arborescence dédiée

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 ».

Ce que j'ai amélioré

Ordre des directives dans mes configurations logrotate

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.

Harmonisation des paramètres de logrotate entre mes serveurs

Il y avait des divergences mineures entre mes serveurs persos pour un même journal. C'est corrigé.

Prise en compte des "nouveautés"

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

Factorisation de mes journaux web

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.

Correction de configurations afin d'éliminer les messages inutiles

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.

Rétention trop longue

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 :

• Les journaux inutiles (j'y ai jamais rien trouvé d'intéressant) ou utiles à très court terme (lors d'un changement de configuration) : apparmor, bind / nsd (transferts de zones DNS, il faut agir rapidement, cf. ci-dessus pour l'explication), cron (il envoie des emails pour les tâches qui foirent de toute façon), ejabberd (erreurs lors du démarrage, j'y ai jamais rien trouvé en dehors), mariadb (j'y ai jamais rien trouvé, et ça consigne qu'au démarrage), ntpd (idem), opendnssec (il faut agir rapidement, cf. ci-dessus pour l'explication), php-fpm (uniquement les messages du gestionnaire lui-même, pas les erreurs dans le code qui tombent dans le journal des erreurs du serveur web, donc ça consigne uniquement au démarrage et en cas de dépassement des limites configurées), Tiny Tiny RSS (composant qui actualise les flux en tâche de fond et qui ne consigne rien d'utile, les erreurs sont affichées dans l'interface web), btpm / wtmp / lastlog / btmp (je les utilise jamais). Je les conserve 2 semaines (weekly + rotate 1) ;
  
  
• Les journaux utiles à moyen terme :
  • Serveurs web (pour générer des stats d'audience mensuelle et pour diagnostiquer un problème genre compromission par une faille de sécurité que l'on peut mettre du temps à détecter). Je les conserve 6 semaines (weekly + rotate 5) afin d'être sûr qu'ils englobent un mois entier, de son 1er jour à son dernier (explication) ;
    
    
  • Serveur emails (diagnostiquer un problème), auth.log / syslog / daemon.log / messages / kern.log (diagnostiquer un problème, y compris une compromission). Je les conserve 5 semaines (weekly + rotate 4), soit un mois glissant ;
    
    
  • Gestionnaires de paquets (alternatives.log / dossier apt / dpkg.log). Pas de données personnelles + ça m'a déjà été utile plusieurs mois après + Debian les conserve 13 mois par défaut, donc je les conserve 6 mois (monthly + rotate 5).

Penser à journald

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 (postfix, 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).

Penser à logrotate

La plupart des fragments de configuration par défaut pour logrotate contiennent la directive notifempty, qui lui ordonnent de ne pas archiver les journaux, ni de supprimer les plus vieux, si le journal est vide.

On peut donc se retrouver avec des journaux, y compris contenant des données à caractère personnel, vieux de plusieurs années.

Solution : dpkg-divert + corriger la configuration de logrotate.

Format de date

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 ?

rsyslog

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é.)

Logiciels n'utilisant pas syslog

Inventaire :

• btmp, wtmp, lastlog, faillog : fichiers binaires qui se consultent avec des commandes dédiées, donc osef ;
  
  
• apt/, dpkg.log, alternatives.log : ils utilisent le format « %Y-%M-%D %h:%m:%s », qui est proche de ceux des normes sus-citées et qui en présente les mêmes avantages sans en faire partie ;
  
  
• ejabberd/ : ils utilisent le format « %Y-%M-%D %h:%m:%.6s%Z:%z », dérivé de « %Y-%M-%D %h:%m:%.3s%Z:%z » (seul change le nombre de chiffres après la seconde) normalisé dans le RFC 3339. De toute façon, d'après sa doc, ejabberd ne permet pas de changer le format de ses journaux ni d'envoyer ses messages à syslog ;
  
  
• php-fpm : utilise un format merdique. Aucun paramètre pour changer de format. On peut envoyer les messages dans syslog, mais il y a un fichier de configuration par version de PHP, donc, à chaque mise à jour majeure de Debian, il faudra refaire le travail. Tout ça pour quelques messages indiquant que des limites ont été dépassées à cause de robots, ça ne m'intéresse pas ;
  
  
• apache httpd : utilise un format merdique, pour les journaux des accès (globaux ou par hôte virtuel) et des erreurs (idem). On peut le changer ou tout envoyer dans syslog, mais, si l'envoi des journaux d'erreur est propre, celui des journaux d'accès repose sur 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.
  
  
• nginx :
  • D'après sa doc', et contrairement à Apache httpd, les journaux des accès et ceux des erreurs (globaux ou par hôte virtuel) peuvent être envoyés proprement à syslog via une socket. Par harmonie avec mes serveurs Apache httpd et pour éviter une duplication des journaux par journald, je ne vais pas utiliser cette fonctionnalité ;
    
    
  • D'après sa doc', le format des journaux des erreurs (globaux ou par hôte virtuel) ne peut pas être changé. mais il utilise le format « %Y/%M/%D %h:%m:%s » qui est proche de ceux des normes sus-citées et en présente les mêmes avantages sans en faire partie (à cause des slashes…) ;
    
    
  • Le format des journaux des accès (globaux ou par hôte virtuel) peut être changé.

Changer le format des journaux d'Apache httpd

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

Changer le format des journaux des accès de nginx httpd

(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 --no-rename --divert /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;

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.

Comprendre la directive « rotate »

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) ;
  
  
• Ainsi 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).

Durée de conservation glissante

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.

Timer systemd

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'.)

Pas de suppression des vieux journaux

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.

Comportements foireux avec copytruncate

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/.log to /var/log/archives//.log.1 » + il ne mentionne pas la suppression de .log.1. Si l'on regarde le code, le message de debug est affiché avant de tester si l'on est en 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).

Et j'avais répondu. ^^