5529 links
  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
◄Older
page 30 / 277
Newer►
  • Plainte CNIL portant sur les emails et le site web du Bon Coin

    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.

    Fri Jul 21 14:51:41 2023 - permalink -
    - http://shaarli.guiguishow.info/?IeWOhw
  • Plainte CNIL portant sur le Cogitiel de la CGT

    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.


    Réclamation

    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.

    Fri Jul 21 14:19:01 2023 - permalink -
    - http://shaarli.guiguishow.info/?teyasA
  • Plainte CNIL portant sur le prestataire emails de ma mairie et son site web

    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.

    Fri Jul 21 12:04:02 2023 - permalink -
    - http://shaarli.guiguishow.info/?4WYl2w
  • Plainte CNIL portant sur les prestataires états-uniens des Mutins de Pangé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).


    Réclamation

    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.

    Fri Jul 21 11:42:23 2023 - permalink -
    - http://shaarli.guiguishow.info/?2eon3A
  • Nouvelle plainte CNIL portant sur le lecteur de vidéos du site web de… la CNIL

    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…

    Thu Jul 20 20:11:59 2023 - permalink -
    - http://shaarli.guiguishow.info/?gc1HWQ
  • Mise à jour de réclamations CNIL

    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 :

    • Scaleway ;

    • Silkhom et Expectra ;

    • DILA ;

    • Liens et images de traçage de Pôle emploi ;

    • Météo France ;

    • Sphère emploi de Pôle emploi.
    Thu Jul 20 19:10:47 2023 - permalink -
    - http://shaarli.guiguishow.info/?03eUkw
  • Re : Note: GuiGui's Show Firefox is ready to protect against potentially dangerous downloads | TechRadar - OpenNews

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

    Wed Jul 19 20:57:34 2023 - permalink -
    - https://ecirtam.net/opennews/?cBbU6Q
  • Suite : Des infractions au RGPD constituent-elles une atteinte à la libre concurrence ? - GuiGui's Show

    La CJUE a rendu son jugement (contre Meta) :

    • Dans le cadre d'une enquête pour abus de position dominante, une autorité de la concurrence peut examiner les pratiques de l'entité contrôlée sous le prisme du RGPD lorsque ce constat est nécessaire pour établir l'abus (de position dominante) ;

    • Une autorité de la concurrence ne peut pas sanctionner les manquements au RGPD autrement que sous le prisme du droit de la concurrence, cela reste de la compétence des APD. Elle ne peut pas diverger des décisions identiques ou similaires rendues par les APD ;

    • Une position dominante ne fait pas obstacle à la base légale du consentement, mais c'est un élément pour apprécier s'il a été donné librement et valablement (la charge est au responsable du traitement) ;

    • Les boutons « like » ou « partager » sur un site web, y compris leur activation, ne signifient pas que l'internaute rend manifestement publiques les données sensibles (origine raciale ou éthique, opinions politiques, convictions religieuses, orientation sexuelle, etc.) contenues sur le site web, sauf s'il a, au préalable, activé un paramètre visant à rendre ces données publiquement accessibles à un nombre illimité de personnes ;

    • La pub personnalisée n'empêche pas l'objet principal d'un contrat d'être atteint, donc sa base légale ne peut pas être la nécessité pour exécuter un contrat. De même, les bases légales de sauvegarde des intérêts vitaux (avec le suivi de la pandémie Covid, c'était bien tenté), de l'obligation légale et de la mission d'intérêt public (car FB prétend effectuer des « recherche[s] pour le bien de la société ») ne sont pas adaptées ;

    • Concernant l'intérêt légitime :
      • La publicité personnalisée ne peut pas être fondée sur l'intérêt légitime, surtout que le traitement de FB est étendu (la quasi-totalité des activités en ligne sont prises en compte). Suivant le point précédent, cela signifie qu'il reste uniquement le consentement ;

      • Garantir la sécurité du réseau peut être fondé sur cette base légale, sous réserve que les données soient effectivement nécessaires, s'il n'y a pas moyen de faire moins attentatoire et/ou avec moins de données ;

      • L'amélioration du service peut reposer sur cette base légale, là encore sous réserve de l'ampleur du traitement, et des autres paramètres de l'intérêt légitime.

    Communiqué de presse ici.
    Décision C-252/21 là.

    Suite ici.

    Via https://twitter.com/bayartb/status/1676223642626142208.

    Wed Jul 19 14:38:46 2023 - permalink -
    - http://shaarli.guiguishow.info/?fb6D3Q
  • Correspondance de la CNIL avec des responsables de traitement pour traiter mes réclamations

    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.

    Wed Jul 19 11:19:45 2023 - permalink -
    - http://shaarli.guiguishow.info/?7WEPSQ
  • [ GPT backup table et structure GPT ] Partitioning - ArchWiki

    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.

      • Son nom est « p.r.i.m.a.r.y » (nom par défaut quand on en donne aucun ?). Je le sais car le nom commence au 57e octet d'une entrée de la table des partoches ;

      • Elle commence au secteur numéro « 00 70 d0 e8 » = 0xE8D07000 (hexadécimal après suppression de l'endianness) = 3905974272 (décimal). Elle termine au secteur « ff 67 e0 e8 » = 0xE8E067FF = 3907020799. Elle occupe donc 3907020799 - 3905974272 = 1046527 secteurs. Un secteur = 512 octets (fdisk le dit) donc la taille de la partition est : 1046527 * 512 = 535821824 octets soit 512 Mo environ ;
    • La deuxième partition (depuis la fin, toujours) est une partoche Linux. On la reconnaît grâce à son type : « af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 ». Son nom est identique à la première. Elle occupe 1,3 To environ ;

    • Idem pour la troisième partition. Elle occupe environ 500 Go ;

    • La dernière partition (et donc la première sur le disque) est une partition de boot BIOS (qui permet d'utiliser GPT sans EFI, en gros). Là encore, on la reconnaît grâce à son type : « 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 », qui, interprété en ASCII nous donne « Hah!IdontNeedEFI ». Son nom est « b.i.o.s._.g.r.u.b.-.s.d.a ». Elle occupe environ 1 Mo.

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

    • bit 0 = 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 01 00 00 00 00 00 00 00 = 0000000000000001 = 1:0:1 (system partition) = hidden ;

    • bit 1 = 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 02 00 00 00 00 00 00 00 = 0000000000000002 = 1:1:1 (hide from EFI) = rien ;

    • bit 2 = 00000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 04 00 00 00 00 00 00 00 = 0000000000000004 = 1:2:1 (legacy BIOS bootable) = legacy_boot ;

    • bit 60 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00010000 = 00 00 00 00 00 00 00 10 = 1000000000000000 = 1:60:1 (read-only) = rien ;

    • bit 62 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 = 00 00 00 00 00 00 00 40 = 4000000000000000 = 1:62:1 (hidden) = rien ;

    • bit 63 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000 = 00 00 00 00 00 00 00 80 = 8000000000000000 = 1:63:1 (do not automount) = rien.

    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

    Mon Jul 17 02:12:06 2023 - permalink -
    - https://wiki.archlinux.org/title/Partitioning#GUID_Partition_Table
  • Retour sur l'organisation de mes journaux informatiques et améliorations

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


    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 --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;
    Sun Jul 16 18:31:30 2023 - permalink -
    - http://shaarli.guiguishow.info/?aY4WgQ
  • How To: Postfix Flush the Mail Queue Using CLI - nixCraft

    Deleting or removing all emails from Postfix queue

    To remove all mail from the queue, enter:
    postsuper -d ALL

    To remove all mails in the deferred queue, enter:
    postsuper -d ALL deferred

    Sun Jul 16 14:28:46 2023 - permalink -
    - https://www.cyberciti.biz/tips/howto-postfix-flush-mail-queue.html
  • Rappels et découvertes sur logrotate

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

    Sun Jul 16 10:41:05 2023 - permalink -
    - http://shaarli.guiguishow.info/?vENTuQ
  • Vimdiff, le diff idéal pour les utilisateurs de vim · Guillaume Fenollar - Administrateur Système Linux | DevOps Kubernetes - Nouméa

    (J'arrive pas à croire que je ne l'ai pas shaarlié plus tôt, ce logiciel.)

    Merci Alex.

    Sat Jul 15 21:41:07 2023 - permalink -
    - https://guillaume.fenollar.fr/blog/vimdiff-comparer-avec-vim/
  • Re : La législation des journaux informatiques - GuiGui's Show - Antichesse (o ^ω^ o)

    Et j'avais répondu. ^^

    Thu Jul 13 10:23:46 2023 - permalink -
    - https://cakeozolives.com/shaarli-antichesse/?IAGeKA
  • La législation des journaux informatiques

    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 :

    • Historique

    • Actuellement

      • Droit de communication

      • Un droit français pas conforme à la jurisprudence de la CJUE

      • À la recherche d'un paradis inexistant
    • Futur

    • Concrètement

      • Qui est concerné ?

        • Un site web ?

        • Un serveur emails ? Un serveur de messagerie instantanée ?
      • Que faut-il collecter et conserver ? Combien de temps ?

        • De l'ambiguïté historique à la légende urbaine
      • Journaux techniques

      • RGPD


    Historique

    • 1995 : l'article 13 de la directive européenne 95/46/CE sur la protection des données à caractère personnel, l'ancêtre du Règlement général sur la protection des données à caractère personnel (RGPD), permet aux États de déroger à ses dispositions pour la sécurité nationale, la sécurité publique, la défense nationale, la poursuite des infractions pénales, etc.

    • 1997 : l'article 14 de la directive européenne 97/66/CE sur la vie privée dans les télécommunications, l'ancêtre de la directive e-privacy qui complète et modifie la directive de 95, permet les mêmes dérogations.

    • 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 :

      • Suite aux attentats, la loi française 2001-1062 sur la sécurité quotidienne (LSQ) codifie, dans l'article 32-3-1 du Code des postes et des communications électroniques (CPCE), la conservation et l'accès aux données de connexion pour la recherche, la constatation, et la poursuite des infractions pénales. Mais la pratique était déjà bien établie sur la téléphonie (source, page 40). (C'est aussi la LSQ qui codifie le délit de refus de prélèvement génétique et celui de refus de communication d'une convention de déchiffrement) ;

      • Dès lors, certaines administrations sont autorisées à se faire communiquer les données de connexion pour l'exercice de leurs missions dans le cadre du droit de communication. Dès 2001, les douanes (article 65 du Code des douanes). 2002, le fisc (L83 du Livre des procédures fiscales). HADOPI dès sa création en 2009, bien évidemment. Etc.
    • 2002 : dans son article 15, la directive européenne 2002/58/CE, dite e-privacy sur la vie privée dans les communications électroniques, qui succède à la directive de 97, permet aux États, par dérogation / exception, d'adopter des dispositions qui restreignent ses dispositions pour la sécurité nationale, la sécurité publique, la prévention, la détection et la répression d'infractions pénales, et les utilisations frauduleuses d'un système de communications électroniques. Cette directive ne s'applique pas aux hébergeurs (source, page 13). (Sans rapport : bien entendu, le RGPD reste applicable aux hébergeurs.)

    • 2004 : l'obligation prévue dans la loi 86-1067 est déplacée dans l'article 6 de la loi 2004-575 dite de confiance dans l'économie numérique (LCEN). Le L32-3-1 CPCE est déplacé dans le L34-1 CPCE.

    • 2006 : adoption de la directive européenne 2006/24/CE qui précise et oblige la rétention des données de connexion. Le cadre français, antérieur, n'en est pas une transposition, mais y est conforme. Normal, la France poussait l'UE à adopter ladite rétention. À l'inverse, l'Allemagne a traîné des pieds pour transposer cette directive.

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

      • Les articles L246-1 et suivants seront renumérotés L851-1 et suivants par la loi Renseignement de 2015 à laquelle ils servent de fondement pour l'accès, différé ou en temps réel, aux données de connexion dans un contexte de renseignement.
    • 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 :

        • Les données relatives à l'état civil (identité) peuvent toujours faire l'objet d'une conservation généralisée et indifférenciée pour tout motif (LQDN, point 159) ;

        • Dans le cadre de la lutte contre une menace grave, réelle, et actuelle ou prévisible pesant sur la sécurité nationale, une conservation généralisée et indifférenciée des données de trafic et de localisation est possible ;

        • Dans le cadre de la lutte contre la criminalité grave ou contre les menaces graves à la sécurité publique, la conservation, avec un historique, des données de trafic et de localisation doit être ciblée et non-discriminatoire (par zone géographique, par ex.). Si aucune rétention obligée par la loi, alors il ne reste qu'une conservation rapide (quick freeze), prévue par la Convention de Budapest de 2001 sur la cybercriminalité, c'est-à-dire d'une injonction de conserver, le temps de l'enquête, ce que l'intermédiaire technique détient à l'instant T pour une/des personnes. C'est donc une conservation pour le présent et le futur, mais aussi pour le passé si l'intermédiaire technique conserve des données de connexion pour ses besoins propres (facturation, fonctionnement du service, sécurité du réseau, etc.) ;

        • La conservation généralisée et indifférenciée de l'adresse IP source d'une connexion (communication) est possible pour les mêmes finalités.
      • (Digital Right Ireland, DRI) Des critères objectifs doivent limiter au strict nécessaire le nombre de personnes autorisées à accéder et à réutiliser des données de connexion les plus intrusives, y compris au sein des services de renseignement ;

      • (Tele2) La demande d'accès aux données de connexion les plus intrusives doit être motivée, notamment dans le cadre de la prévention, détection et poursuite des infractions pénales ;

      • (Prokuratuur) L'accès aux données de trafic et de localisation doit être validé / contrôlé par une autorité judiciaire ou administrative indépendante et extérieure à l'autorité qui demande l'accès afin d'exercer un contrôle objectif, impartial et à l'abri de toute influence extérieure. Pas besoin pour les données d'identité (à ce stade, ce n'était pas explicite dans la jurisprudence de la Cour, mais ça le sera). Conséquence en matière pénale : l'autorité de contrôle ne doit pas être impliquée dans la conduite de l'enquête pénale et elle doit être neutre vis-à-vis des parties. Contrôle a priori ou a posteriori dans un bref délai ;

      • (Prokuratuur) Si la conservation des données de connexion n'est pas conforme au droit de l'UE, alors l'accès n'est pas conforme ;

      • (Garda Síochána) Il est interdit d'accéder aux données de trafic et de localisation conservées pour préserver la sécurité nationale pour une finalité présentant un intérêt inférieur, comme la criminalité (= pas de porosité des finalités). En revanche, une finalité supérieure, comme la sécurité nationale, permet d'accéder aux données (de trafic et de localisation) conservées pour une finalité inférieure, comme la criminalité grave. En comparaison, l'article 5(1)b du RGPD autorise la réutilisation seulement pour des finalités compatibles, donc rien d'extraordinaire ici ;

      • (Garda Síochána) Les personnes dont les données de connexion ont été consultées doivent être informées. Là encore, le RGPD et la directive police-justice prévoient ça dès que ça ne nuit plus à l'enquête, donc rien de neuf ;

      • (SpaceNet) La conservation et l'accès aux données de connexion sont deux ingérences distinctes dans les droits fondamentaux, donc elles nécessitent deux justifications distinctes. Ainsi, il n'est pas possible de compenser une collecte élargie par un accès restreint (ce qui a été l'une des planches de salut des États) ;

      • (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 :

        • La CJUE se fonde sur la Charte des droits fondamentaux de l'UE, ce qui lui permet de tacler indifféremment les législations UE (comme la directive 2006/24/CE) et, sous réserve de l'appréciation par les juridictions de renvoi, les législations nationales basées sur une dérogation au droit de l'UE (permise par la directive e-privacy). Cela serait rare en ce que, d'habitude, elle se fonderait sur du droit dérivé (je ne suis pas convaincu : même en matière de RGPD, elle mentionne très vite la Charte dans ses arrêts, et, de surcroît, pour invalider la directive 2006/24/CE, il fallait forcément qu'elle se base sur un texte supérieur) ;

        • La CJUE poserait une interdiction de principe, qu'elle ne nuancerait pas avec les autres impératifs prévus par la Charte des droits fondamentaux de l'UE : la sécurité nationale et la criminalité grave sont des dérogations. Selon moi, c'est normal, car c'est ainsi qu'est rédigée la directive e-privacy : interdiction à des tiers de principe de stocker les communications, sauf dérogations. C'est le vieux principe de droit sur l'interprétation stricte des dérogations et exceptions (le contraire revient à vider le principe de sa substance) ;

        • La CJUE empiète-t-elle sur les compétences des États en matière de sécurité de l'État et de poursuite des infractions, ce que les traités européens ne prévoient pas (autre planche de salut des États, j'y reviendrai) ? Était-il nécessaire d'harmoniser les pratiques des États en ces matières ? Vaste débat ;

        • Ces arrêts de la CJUE ont-ils été motivés par une peur de l'État ? Stasi ? Démocraties illibérales (pour rire : la Pologne n'a pas modifié sa législation suite à ces arrêts) ? Je pense que toutes les démocraties ont vacillé et qu'il fallait calmer le jeu.
    • 2015-2020 :

      • En déposant ou en soutenant plusieurs questions prioritaires de constitutionnalité, les Exégètes amateurs (LQDN, French Data Network ‒ FDN ‒, Fédération FDN ‒ FFDN ‒) ont fait retirer, à plusieurs administrations, leur droit de communication des données de connexion ou l'ont fait assortir d'un contrôle préalable indépendant ou l'ont fait préciser : Autorité des marchés financiers (2017-646/647 QPC), douanes (2018-764 QPC), organismes de sécurité sociale (2019-789 QPC), HADOPI (2020-841 QPC).

      • Dans sa décision 2015-478 QPC, le Conseil constitutionnel a interprété que l'accès par les services de renseignement (articles 851-1 et suivants du CSI, ex-246-1 et suivants, cf. infra) porte uniquement sur les données prévues par la LCEN et le CPCE, c'est-à-dire les données de connexion. De même, il a rappelé que le contenu des communications est hors du périmètre.
    • 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 :

          • Jusqu'au bout, la France aura prétendu ne pas être concernée (le parquet estonien n'est pas le parquet français, blablabla) d'une part car sa législation nationale, conforme à la directive 2006/24/CE, n'en est pas une transposition (la décision CE 388134 de février 2016 du Conseil d'État est révélatrice), et d'autre part, car la conservation est mise en branle pour un motif de sécurité nationale et de poursuite des infractions pénales qui sont des prérogatives des États, pas de l'UE. Comme l'Allemagne (rachat de la dette des États par la BCE), ce qui a retenu le Conseil d'État de parer avec l'identité constitutionnelle de la France, malgré une analyse en droit tout de même, c'est la peur des nationalistes qui pourraient eux aussi remettre en cause la primauté du droit européen dans leurs thématiques favorites, façon Hongrie ;

          • La conservation des données de trafic et de localisation demeure généralisée et indifférenciée pendant 1 an pour la sécurité nationale, donc aucun changement pour les services de renseignement ni pour les opérateurs & co (qui doivent conserver comme avant). Il faut simplement un réexamen périodique de la menace afin de vérifier qu'elle est toujours grave, réelle et actuelle ou prévisible (critères de la CJUE) ;

          • Conservation rapide pour les mêmes données pour la criminalité et la délinquance grave. La conservation ciblée présente des obstacles techniques, donc elle n'est pas une option ;

          • Toujours une conservation généralisée et indifférenciée de l'adresse IP ou du numéro de téléphone source d'une connexion / communication et des données d'identification du terminal utilisé (on pense à l'IMEI, à une MAC, etc.), pour la criminalité, la délinquance grave, la sécurité publique, et la sécurité nationale ;
        • 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 :

          • L'accès en différé (L851-1 du Code de la sécurité intérieure, CSI) ou en temps réel (L851-2 CSI) aux données de connexion par les services de renseignement, et le recours aux boîtes noires (L851-3 CSI) ou à la géolocalisation en temps réel (L851-4 CSI) par les mêmes services, ne font pas l'objet d'un contrôle préalable suffisant. (Ce contrôle était prévu par les décrets 2015-1639 et 2016-67.) En effet, le Premier ministre peut passer outre l'avis de la Commission nationale de contrôle des techniques de renseignement (CNCTR), qui peut contester cela devant la formation spécialisée du Conseil d'État, mais, pendant ce temps-là, la technique de renseignement peut être mise en œuvre. Ce n'est pas suffisant : en dehors d'une urgence, le Conseil d'État veut un avis conforme de la CNCTR ou un contrôle préalable entier par une juridiction ;

          • Contrairement aux requérantes, le Conseil d'État juge que le nombre de personnes pouvant accéder aux données de connexion ou mettre en œuvre d'autres techniques de renseignement est limité, par technique de renseignement et par finalité. Cela est prévu dans les articles L811-4 et R811-1 du CSI (services de renseignement du premier cercle), et L811-2, R811-2 CSI (second cercle), puis R851-1 à R851-4 CSI (pour les données de connexion), R852-1 à R852-2, et R853-1 à R853-3 du CSI (pour les autres techniques).
        • Sur l'absence d'une obligation d'information en cas d'accès : le Conseil ne trouve rien à redire en ce que la loi Informatique et Liberté permet une information et que la CJUE, comme le RGPD, permettent de ne pas informer une personne si ça compromet une enquête ou les missions qui incombent aux services de renseignement ou de police. Pour le CE, seule une minorité de cas donnera lieu à une information, comme une erreur de cible.
      • 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) ;

          • Une réforme est envisagée. Le juge des libertés et de la détention (JLD) se verrait attribuer cette compétence. Mais il est débordé (même si on l'a déchargé des contentieux civils ces dernières années) et il dispose, au moment de sa prise de décision, de très peu d'informations sur l'enquête en cours, donc son accord est majoritairement automatique afin de ne pas entraver l'action publique. Si l'on mettait en place une Autorité administrative indépendante (AAI) ou d'un Service à compétence nationale (SCN), comme l'ANTENJ (en charge de la PNIJ), il s'agirait uniquement d'un avis (à cause de la séparation des pouvoirs) avec un juge pour confirmer les cas de doute. Cela serait en contradiction avec la jurisprudence de la CJUE qui veut un examen obligatoire (contraignant ?) et systématique. De plus, cela serait coûteux et il manquerait une proximité avec les enquêteurs (je trouve ça sain, au contraire). Une autorité nationale de magistrats poserait des difficultés RH et techniques. Une autorité locale rattachée au parquet ne serait pas conforme CJUE. Reste le JLD, y compris sous forme de groupement auprès des Cours d'appel, mais ça implique une charge de travail et un système d'information bien fichu. Il faudrait également prévoir une procédure d'urgence avec un contrôle a posteriori dans un bref délai. Source, pages 18 et 101 et suivantes.
        • Les réquisitions (60-1, 60-2, 77-1-1, 77-1-2, 99-3 et 99-4 du Code de procédure pénale) doivent se comprendre comme des injonctions de conservation rapide et portent tant sur les données de connexion détenues pour les intermédiaires techniques pour leurs besoins techniques et commerciaux, que sur les données conservées pour l'obligation légale (ce que ne dit pas la CJUE, surtout si les données ont été collectées pour une finalité supérieure, ni la Convention de Budapest de laquelle est issue la conservation rapide, voir ici) ;

        • 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 ;

          • La Cour a déjà jugé que relèvent de la criminalité grave : le trafic de stupéfiants dans une maison d'arrêt avec corruption de fonctionnaire ; le banditisme violent, organisé et transfrontalier ; une association de malfaiteurs (hum, dérapage possible car très large) ; et la détention d'arme et d'explosif en lien avec la possible préparation d'une attaque (idem…).
        • La Cass juge qu'un quantum de peine de prison ne suffit pas pour caractériser de grave une infraction, il faut tenir compte des circonstances de l'espèce, donc les enquêteurs doivent motiver. Dans un contexte où le législateur augmente sans cesse les peines, je trouve cela protecteur ;

        • Bien évidemment, les infractions ayant trait à la sécurité nationale (articles 410-1 à 422-7 du Code pénal), comme l'atteinte aux intérêts fondamentaux de la nation (complot, insurrection, appel à s'armer, etc.), les actes de terrorismes, etc., peuvent donner lieu à des réquisitions. Dit autrement : cette finalité de sécurité nationale est poursuivie tant par les services de renseignement que par la justice, ce qui est logique (le renseignement détecte, la justice punit) ;

        • Conséquence de ces arrêts : insécurité juridique pour les magistrats, formalisme pour rédiger les demandes d'accès (nécessité et proportionnalité) pour les enquêteurs, fragmentation des pratiques au niveau national, et garanties en moins pour les citoyens.
      • Conseil constitutionnel :

        • 2021-952 QPC (décembre 2021) : l'accès aux données de connexion dans une enquête préliminaire (77-1-1 et 77-1-2 du Code de procédure pénale, CPP) n'est pas conforme à la Constitution car il faut tenir compte de la nature de l'infraction (criminalité grave), ne pas ouvrir à toutes les infractions ;

        • 2021-976/977 QPC : la collecte généralisée et indifférenciée des données de connexion prévue par l'article L34-1 du CPCE est contraire à la Constitution ;

        • Pour les deux décisions suivantes, la loi avait déjà changé (en mars 2022, cf. infra) ;

        • 2022-993 QPC (mai 2022) : l'accès en enquête de flagrance (60-1 et 60-2 CPP) est conforme car cette procédure est pour un crime ou un délit puni d'une peine de prison et que l'enquête dure 8 jours (elle peut être prolongée si au moins 5 ans de taule sont encourus et si l'enquête ne peut pas être différée). À rebours de la CJUE, il juge qu'il n'y a point besoin d'un contrôle préalable par une juridiction ou une autorité indépendante ;

        • 2022-1000 QPC (juin 2022) : l'accès en information judiciaire (99-3 et 99-4 CPP) est conforme car le juge d'instruction est indépendant (mais pas extérieur à l'enquête comme le voudrait la CJUE), le cadre est défini (information judiciaire) et les conditions sont précisées dans la commission rogatoire.
    • 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 :

          • Finalités : sécurité nationale ou autres intérêts nationaux essentiels contre les menaces extérieures graves ;

          • Les États bénéficient d'une marge d'appréciation pour déterminer le régime qu'il convient de mettre en œuvre, tant qu'il est nécessaire et proportionné, qu'une autorité indépendante veille au respect des garanties, y compris pour définir l'objet et l'étendue de la surveillance, et qu'il existe une supervision indépendante des opérations de surveillance et du respect du pouvoir de l'autorité de contrôle (aka contrôle a posteriori) ;

          • La CEDH dégage des critères pour vérifier les garanties : motif et circonstance de l'interception ; procédure d'octroi de l'autorisation ; procédure pour sélectionner, examiner et utiliser les éléments interceptés ; encadrement des réutilisations ; limites de la durée de l'interception et de la conservation ; encadrement de la destruction des éléments interceptés ; procédure et modalités de la supervision, etc. ;

          • Elle estime qu'un État a un besoin légitime d'opérer en secret donc que celui-ci peut ne pas lui communiquer ses critères. Il faut juste que les juridictions internes vérifient ce qui a été esquissé aux points précédents. Rien d'étonnant, la CEDH raisonne souvent comme ça en matière de liberté d'expression (vérification de la procédure, que la juridiction a bien vérifié la proportionnalité, les garanties, etc. plutôt que "re-juger" l'affaire et la peine en elles-mêmes) ;

          • La Cour juge que la législation britannique antérieure à 2016, pourtant axée sur la sécurité nationale, n'est pas conforme à la ConvEDH par absence d'autorisation indépendante et de définition de l'étendue de la recherche et/ou des termes de celle-ci.
        • Ensuite, sur l'échange avec des services de renseignement étrangers :

          • Critères : prévoir les circonstances des collaborations et celles d'utilisation des renseignements obtenus, et contrôle indépendant a posteriori ;

          • Le régime britannique satisfait à ces exigences.
      • 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 :

          • Conservation de l'identité (5 ans après la fin de contrat, contre un an avant) et des infos d'abonnement / de compte / de paiement (1 an après la fin de contrat / la clôture du compte) pour toutes les infractions, pour la sécurité publique, et pour la sécurité nationale ;

          • Conservation 1 an des données permettant d'identifier la source d'une connexion ou les terminaux utilisés, pour la criminalité, la délinquance grave, la sécurité publique, et la sécurité nationale. La conformité à la jurisprudence de la CJUE n'était pas acquise au moment de cette modification législative. (En mars 2022, la loi précisera ce que sont la criminalité et la délinquance grave, cf. infra) ;

          • Conservation 1 an des données de trafic et de localisation, pour la sécurité nationale ;

          • Au moins, il y a désormais un panachage de la durée de conservation en fonction de la finalité, même si c'est très artificiel (puisque les opérateurs doivent conserver pour sécu natio et que je présume que ça ne va pas s'arrêter demain) ;

          • Notons que ces décrets prévoient enfin la conservation du port source, ce qui permet d'identifier les utilisateurs d'un service en ligne qui partagent une même adresse IP publique (surtout en mobilité), plutôt que de geindre dans la presse que les méchants GAFAM ne collaborent pas avec la gentille police (alors que si, mais c'était infructueux puisqu'aucune correspondance ne pouvait être établie).
        • Accès :

          • Par la justice. Conservation rapide sur injonction du parquet ou des administrations dotées d'un droit de communication pour la prévention et la répression de la criminalité, de la délinquance grave et des autres manquements graves aux règles dont les administrations doivent assurer le respect. « Peuvent être concernées les données du suspect, de son entourage, des victimes, des témoins, ou encore des zones géographique déterminées dès lors qu’elles apparaissent utiles à la manifestation de la vérité. » (source, page 84). « La méthode de la conservation rapide constitue donc en pratique, comme l’a souligné la direction des affaires criminelles et des grâces aux rapporteurs dans le cadre de leurs travaux, « une modalité d’accès aux données de connexion déjà conservées pour d’autres finalités. » » (même source), ce que la CJUE réprouve. En juillet 2022, la Cour de cassation a jugé dans le même sens que la direction des affaires criminelles (cf. supra) ;

          • Par les Renseignements. Les articles 18 et 23 de la loi renseignement 2 modifient les articles L821-1 et L854-9 du Code de la sécurité intérieure (CSI) pour soumettre l'ensemble des techniques de renseignement au contrôle de la CNCTR (comme avant), et, en cas d'avis défavorable, au contrôle impératif de la formation spécialisée du Conseil d'État. Toutes les techniques sont concernées (accès diffèré ou en temps réel aux données de connexion, boîtes noires, géolocalisation en temps réel, données de connexion et communications internationales, autres techniques). Notons quand même que l'échange de renseignements entre services y échappe. Voir la délibération de la CNCTR sur cette évolution législative ;
        • Objections de LQDN : une injonction doit être individualisée ; la collecte généralisée des données de connexion doit rester une exception (CJUE) ; la CJUE a une définition beaucoup plus restrictive de la sécurité nationale que notre droit national qui englobe (cf. L811-3 CSI) les violences collectives (auxquelles le Conseil constitutionnel a rattaché, en 2015, les manif' non déclarées ‒ je pense qu'il s'agit des manifs non autorisées), la prévention de la délinquance et de la criminalité organisées, les atteintes à la forme républicaine des institutions, et auxquelles le Conseil d'État, a ajouté, en 2021, les activités de groupes radicaux.
    • 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).

        • La CEDH a jugé (résumé), en mai 2023, que les données de connexion recueillies en enquête pénale peuvent être utilisées par une autorité de la concurrence (mais ça ne dit rien de la collecte généralisée). L'affaire a été renvoyée en grande chambre en septembre 2023, donc affaire à suivre ;

        • Avant tout cela, la Cour de cassation avait perçu, dès 2019, l'absence d'indépendance de l'AMF. Dans ces deux cas précis (AMF et ADLC), la France a mis en place, dès 2018, un « contrôleur des demandes de données de connexion », cf. section « Droit de communication » infra.
    • 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 :

          • La menace est grave et actuelle : terrorisme (8 attaques depuis 2020, 10 projets déjoués), l'instabilité au Sahel qui vise la France, l'ingérence et l'espionnage liés à la guerre en Ukraine, les groupes radicaux d'ultra-droite et d'ultra-gauche qui troublent la paix publique, et les cyberattaques visant les OIV ;

          • Devant le Conseil, le gouv' peut invoquer des menaces de natures différentes de celles qui l'ont poussé à prendre le décret ;

          • Il n'y a pas d'atteinte disproportionnée à la vie privée (sans argument) ;

          • Il y a un ré-examen périodique (1 an, possibilité d'y mettre fin prématurément, etc.) et un recours effectif devant le Conseil d'État, donc ce serait conforme aux arrêts de la CJUE.
        • 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 :

          • Énième confirmation qu'un intermédiaire conserve uniquement ce qu'il collecte dans le cadre de son activité, ce qui est nécessaire / utile à son activité, aka "tu donnes que ce que t'as" ;

          • Énième confirmation qu'un intermédiaire technique n'a pas à vérifier la véracité des données relatives à l'identité civile (adresse postale, par ex.). Attention, changement en 2024, cf. infra ;

          • Le panachage des finalités pour chaque jeux de données (point 18) diffère de celui de la Cour de cassation (cf. « 2021-2022 » ci-dessus). Sur les données relatives à la source d'une connexion ou aux terminaux : en sus de la criminalité et de la sauvegarde de la sécurité nationale prévues par la Cour de cass, le CE, accepte la lutte contre la délinquance grave et la menace grave contre la sécurité publique, prévues par la loi mais dont la conformité à la jurisprudence de la CJUE n'était pas acquise à date. Pour le reste, identité civile, contrat, facturation, données de trafic et de localisation, la Cour de cass' et le CE sont raccord sur sauvegarde de la sécurité nationale pour les données de trafic et de localisation, et sur la recherche des infractions pénales, la délinquance et criminalité graves, menaces graves contre la sécurité publique, et sauvegarde de la sécurité nationale ;

          • L'obligation de conserver l'identité civile 5 ans, qui conduit à détenir un historique des adresses postales, emails, numéros de téléphone, etc. n'est pas disproportionnée ;

          • Les données de paiement / facturation, c'est-à-dire la date+heure + le lieu des transactions physiques (pour payer le matos et/ou l'abo, etc.), ne sont pas des données de localisation au sens de la directive e-privacy donc elles peuvent être utilisées pour toutes les finalités, pas juste pour sauvegarder la sécu nationale, la sécu publique, et pour la criminalité et la délinquance graves ;

          • Le décret attaqué ne fixe pas les durées de conservation, donc on ne peut pas débattre, dans cette procédure, de la durée de conservation des infos de paiement qui serait excessive et donc contraire au droit de l'UE ;

          • Le décret ne traitant pas de l'accès, par les autorités, aux jeux de données qu'il impose de conserver, on ne peut en parler non plus ;

          • L'ingérence dans la vie privée est nécessaire et proportionnée ;

          • Des précisions ont été apportées sur les données à conserver, voir la section « Que faut-il collecter et conserver ? Combien de temps ? » ci-dessous.
      • 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 :

        • Malgré les ajustements décrits ci-avant, le droit français n'est pas encore entièrement conforme à la jurisprudence de la CJUE et il reste des divergences d'interprétation entre le Conseil d'État, la Cour de cassation, et le Conseil constitutionnel ;

        • L'écrasante majorité des États-Membres de l'UE peinent à mettre leur droit en conformité : la conservation rapide ne serait pas efficace par manque d'historique, la conservation ciblée présente des difficultés juridiques et techniques. Conséquence : les pratiques divergent ;

        • Il existe des dissensions au sein de l'appareil européen (Commission, Conseil, Parlement) ;

        • Au niveau français, le mal est plus profond : nécessaire unification et clarification des régimes juridiques des preuves numériques, des procédures d'accès, etc. ; disposer de systèmes d'information adéquats ; etc.
    • 2024 :

      • En avril, la CJUE a rendu son arrêt LQDN contre HADOPI (C-470/21) :

        • Le Conseil d'État a posé cette question préjudicielle dans le cadre du contentieux CE 433539. Dans ce même dossier, il avait posé une question prioritaire de constitutionnalité (2020-841 QPC). Comme relaté supra, le Conseil constitutionnel avait déclaré les dispositions anti-constitutionnelles en ce qu'elles octroyaient l'accès à toutes les données de connexion et même à tous documents (et données) conservés par les opérateurs ;

        • 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 ;

          • Une adresse IP est une donnée de trafic au sens de la directive e-privacy (point 60), mais, dans le cadre d'un accès pour identifier une personne, il y a lieu de la considérer comme une donnée d'identité / d'abonnement, ce que prévoit la législation française.

          • La question de savoir si l'obtention de l'identité civile à partir d'une adresse IP à l'origine d'une communication est le seul moyen d'identifier l'auteur présumé d'une infraction ou, a minima, le moins intrusif, est un critère de proportionnalité pour décider s'il y a ou non une ingérence grave (points 116 et 119). J'aurais préféré que la CJUE pose une limite claire : l'accès à l'identité civile à partir d'une adresse IP n'est possible, pour toutes les infractions non-graves, que si c'est nécessaire et/ou la méthode la moins intrusive.
        • 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.

          • Sauf que la HADOPI associe le titre d'une œuvre culturelle présumément piratée (c'est-à-dire des données de trafic) à une adresse IP et, par suite, à une identité civile. C'est cette combinaison de données de connexion qui peut constituer une ingérence grave (c'est-à-dire révéler une orientation sexuelle, des convictions politiques, philosophiques, religieuse, etc.) mais uniquement en cas de réitération (une seule œuvre ne permet pas de tirer de conclusions très précises sur une personne). La CJUE juge que l'ingérence est susceptible d'intervenir à la 2e réitération, c'est-à-dire à la 3e itération (pourquoi pas à la 2e ? D'autant qu'une même personne peut se faire flasher plusieurs fois par étape de riposte graduée). Donc il faut un contrôle préalable indépendant et non-automatisé à partir de cette étape, la troisième étape de la riposte graduée. Je ne comprends pas comment cela peut être mis en place : surtout avec des IP dynamiques (ce dont l'Avocat général a conscience), il faut d'abord obtenir l'identité pour savoir si la 3e itération est intervenue, ce qui n'est possible qu'après la réquisition de l'identité civile dont il faut décider si elle doit être contrôlée ou non. J'imagine que le Conseil d'État résoudra cette contradiction apparente par un contrôle indépendant a posteriori à brève échéance (ce qui est conforme à la jurisprudence de la CJUE) ;

          • De même, il faut une séparation interne à la HADOPI afin que les agents ne puissent pas mettre automatiquement en relation une identité avec les titres des œuvres présumément piratées (point 142). Gné ? Le système d'information (SI) de la HADOPI, essentiellement automatisé, doit faire l'objet d'un contrôle indépendant sur son intégrité, sur son respect effectif des garanties, sur l'absence d'abus, etc. (point 146) Donc, il y a la HADOPI, l'entité de contrôle préalable des accès, et l'entité qui audite le SI de la HADOPI. Vache…
        • 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.

          • Aux points 44 à 47 de son arrêt C-178/22 rendu le même jour, la Cour a jugé qu'il revient aux États de définir ce qu'est la criminalité grave tant que cela ne dénature pas ni ne vide de sa substance la directive e-privacy ou sa jurisprudence. De plus, une peine de prison de trois ans ne suffit pas à caractériser de grave une infraction, il faut mettre en balance les droits, il faut que les données soient pertinentes pour constater les faits, etc. (point 50 et suivants). Mais une peine de prison de 3 ans n'est pas un seuil excessivement bas.
        • Un accès pour la lutte contre les infractions pénales permet d'accéder, en sus des données conservées à cette fin en application de la rétention des données de connexion, aux données de trafic et de localisation qui ont été conservées pour les besoins propres des opérateurs (facturation, gestion du réseau, etc.), cf. point 98. Avant cet arrêt, la criminalité grave ou la sécurité nationale donnaient accès aux données de trafic et de localisation détenues pour les besoins propres ; désormais c'est ouvert à toute infraction. Donc une législation nationale ne peut pas prévoir la conservation (additionnelle) des données de trafic et de localisation pour toutes les infractions, seulement pour la criminalité grave, mais OK pour l'accès à celles conservées de base par les intermédiaires techniques. Ça craint ;

        • 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 :

          • HADOPI = pré-pénal, donc e-privacy et la directive police-justice lui sont applicables. En revanche, seul le RGPD est applicable à la collecte, par les ayant-droits, des adresses IP et des œuvres présumées piratées.

          • La CJUE rappelle, au point 97, que l'interdiction de porosité entre des finalités de rang différent ne s'applique qu'aux données de trafic et de localisation, pas aux données d'identité ni aux adresses IP source. Je déduis que même si, actuellement, l'article R10-13 CPCE prévoit la conservation de l'adresse IP pour la criminalité grave (et la sécu publique et nationale), la HADOPI peut y accéder sans requalifier le délit de contrefaçon de criminalité grave.

          • Un volume massif d'infractions présumées (4 millions en 2021) n'est pas une excuse pour procéder à un contrôle automatisé de l'accès aux données de connexion.
        • En bref : sur plusieurs points, il s'agit d'un arrêt régressif qui complexifie excessivement les choses par des détours… La note 38 des deuxièmes conclusions de l'Avocat général annonçait la couleur : renouer le dialogue avec les juges nationaux, adaptation, etc.
      • En juin, la mission de réflexion sur les conditions d'accès aux données de trafic et de localisation par les acteurs de l'enquête pénale, confiée par le ministre de la Justice au conseiller d'État Alexandre Lallet, rapporteur public de la décision CE 393099 du Conseil d'État d'avril 2021, aurait rendu son rapport, mais il est introuvable en ligne. En novembre 2024, ce rapport était en discussion / arbitrage (source, page 13).

      • En novembre, un groupe de réflexion sur le même sujet et piloté par la Commission européenne a rendu ses recommandations et son rapport. Mes notes ici.
    • 2025 :

      • En février, abandon du règlement européen e-privacy qui devait mettre à jour la directive e-privacy de 2002, entre autres pour la rendre entièrement compatible avec le RGPD. Faute d'accord entre les co-législateurs, rien n'avançait depuis 2021. Pour rappel, e-privacy permet, par dérogation, la conservation des données de connexion (cf. supra). Certains États, dont la France, voulaient donc exclure explicitement du principe de confidentialité des communications qu'elle prévoit les activités de prévention et de détection des infractions pénales, d'exécution des sanctions pénales, et de détection et de protection des menaces graves pour la sécurité publique. L'objectif était de réaffirmer la compétence exclusive des États.

      • En juin, la loi 2025-532 sur le narcotrafic modifie l'article L34-1 du CPCE : les opérateurs et FAI doivent vérifier l'identité civile de leurs clients.



    Sources pour rédiger cette section :

    • FDN et autres contre gouvernement à PSES 2015 ;

    • Big Brother habite place Beauvau ? chez Thinkerview en 2018 ;

    • Legal update: on en est où de l'accès aux logs ? au FRnOG 36 de septembre 2022 ;

    • Les innombrables tweets d'Alexandre Archambault auxquels je n'ai plus accès puisque Twitter est désormais fermé aux non-inscrits ;

    • Rapport d'information du Sénat « Surveiller pour punir ? Pour une réforme de l'accès aux données de connexion dans l'enquête pénale » de novembre 2023.


    Actuellement

    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 :

    • Les articles L34-1 et R10-13 du Code des postes et des communications électroniques (CPCE). Dernières modifications par le décret 2021-1361 et la loi 2025-532 sur le narcotrafic ;

    • Article 6(V)A de la loi pour la confiance dans l'économie numérique (LCEN) et décret 2021-1362. Renvoi vers le L34-1 CPCE ;

    • Un décret annuel visant à maintenir la conservation généralisée et indifférenciée pour motif de sécurité nationale. Le dernier est le 2024-901.

    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 :

    • Toutes les données d'identité (état civil), d'abonnement (numéro de téléphone, adresse IP, etc.), de contrat, de compte, de facturation / paiement, etc. doivent être conservées 5 ans pour l'identité, et 1 an après la fin du contrat pour le reste. Finalités : infractions, sécurité publique, sécurité nationale. En sus de ce régime, les pièces comptables (factures) sont aussi soumises à l'obligation fiscale 6 ans et à l'obligation comptable 10 ans ;

    • Toutes les données d'identification (adresse IP source d'une connexion, numéro de téléphone appelant, identifiant de l'utilisateur ou de son terminal, etc.) doivent être conservées 1 an à compter de la communication. Finalité : criminalité, délinquance grave, sécurité publique et sécurité nationale (bien entendu, comme l'intermédiaire technique ignore l'usage de ses utilisateurs, il conserve pour tout le monde) ;

    • Toutes les données de trafic (appels, SMS, emails, connexions, etc.) et de localisation (pour un smartphone) doivent être conservées 1 an à compter de la communication en cas de menace grave pour la sécurité nationale, sur décret du Premier ministre. Un tel décret est actuellement en vigueur ;

    • Dans tous les cas, les entités conservent uniquement les données qu'elles détiennent dans le cadre normal de leur activité (cf. 2023 dans la section « Historique »). Exemples : absence de données de paiement et de facturation sur un service gratuit ; absence de données de localisation hors abonnement de téléphonie mobile ; l'opérateur d'un point d'accès Wi-Fi public gratuit n'a pas l'identité ni la facturation s'il ne le désire pas (attention quand même aux autres lois applicables), mais il a l'identifiant du terminal utilisé (adresse MAC) ;

    • Le présent article traite de l'obligation légale de conserver des données de connexion, mais, bien évidemment, en dehors de ce cadre, les intermédiaires techniques conservent eux-mêmes de telles données pour leurs besoins techniques (fonctionnement du service, prévention des pannes, résolution des incidents, sécurité du réseau, etc.) ou commerciaux (facturation, etc.), cf. R10-14 du CPCE. Certaines entités consignent les connexions à un espace client au titre de l'obligation de traçabilité des accès aux données à caractère personnel tirée du RGPD (la CNIL préconise 6 mois à 1 an, hein ;) ). L'obligation légale de conserver des données de connexion permet seulement de s'assurer que tous les acteurs conservent un ensemble minimal de données pour une durée minimale, etc. ;

    • Pour toutes les données énumérées à l'ensemble des points qui précèdent, un intermédiaire technique peut recevoir une injonction judiciaire de conservation rapide (quick freeze), c'est-à-dire l'ordre de conserver l'ensemble des données de connexion qu'il détient sur des personnes. Il faut donc un système d'information dans lequel on peut empêcher la suppression automatique des données de connexion conservées.



    L'accès aux données de connexion est régit par trois régimes :

    • Pour les enquêtes pénales :

      • Il s'agit du régime des réquisitions judiciaires, donc des articles 60-1 et 60-2 du Code de procédure pénale (CPP) pour les enquêtes de flagrance, 77-1-1 et 77-1-2 CPP pour les enquêtes préliminaires, et 99-3 et 99-4 CPP pour les informations judiciaires ;

      • L'article 60-1-2 CPP restreint ces réquisitions pour toutes les données de connexion sauf l'identité civile : 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 ;

      • Les réquisitions, qui sont ordonnées par le parquet (= procureur) doivent être comprises comme des injonctions de conservation rapide. Elles permettent d'accéder aux données de connexion conservées pour d'autres finalités que l'infraction poursuivie (ex. : accès aux données de trafic et de localisation détenues uniquement pour la sécurité nationale dans le cadre d'une enquête sur un délit), y compris à l'historique. La peine prévue (années de prison) n'est pas suffisante pour qualifier la gravité d'un crime ou d'un délit et autoriser l'accès aux données de connexion (c'est au juge du fond d'apprécier la nullité des pièces en bout de course) ;

      • Pour les demandes venues de l'étranger / international, les intermédiaires techniques doivent renvoyer vers la BEFTI ou la sous-direction de la lutte contre la cybercriminalité (ex-OCLCTIC), car, a priori, y'a pas de raison que si une entité étrangère n'est pas tenue de répondre à une réquisition directe des autorités françaises, l'inverse soit vrai.

      • Dans un procès au civil, les données de connexion, y compris d'identité, ne sont pas communicables. Si c'est demandé, il faut contester durant le procès, car la juridiction est tenue par les propos et prétentions des parties. Exemple : Wikipédia a été contrainte, à tort, de communiquer les données d'un contributeur, cf. 1, 2, 3, 4 ;
    • Pour les services de renseignement :

      • Articles L851-1 (accès différé aux données de connexion), L851-2 (accès en temps réel aux données de connexion), L851-3 (boîtes noires), L851-4 (géolocalisation en temps réel d'un terminal), et 851-6 (IMSI catcher pour localisation et identification uniquement) du Code de la sécurité intérieure (CSI) ;

      • De nombreux services de renseignement, dits du premier ou du second cercle, peuvent accéder aux données de connexion : articles L811-4 et R811-1 du CSI pour le premier cercle, et L811-2 et R811-2 pour le second cercle, puis R851-1 à R851-4 (pour l'accès aux données de connexion), et R852-1 à R852-2, et R853-1 à R853-3 du CSI (pour les autres techniques) ;

      • Les finalités dépendent des techniques de renseignement, mais, en gros, il s'agit de : sécurité nationale, terrorisme, et défense et promotion des intérêts fondamentaux de la Nation. Comme dit plus haut, la sécurité nationale englobe beaucoup de choses : violences collectives, donc manifs non autorisées, activités de groupes radicaux, délinquance et criminalité organisée, complot, insurrection, appel à s'armer, etc. ;

      • Sur autorisation du Premier ministre après avis de la Commission nationale de contrôle des techniques de renseignements (CNCTR). Si avis défavorable, la formation spécialisée du Conseil d'État est obligatoirement saisie et la technique de renseignement ne peut pas être mise en œuvre avant sa décision. Cf. L821-1 et L854-9 CSI ;
    • Pour les administrations : voir la section suivante, mais, en gros, L96 G du Livre des procédures fiscales et des lois sectorielles (le Code du travail, par ex., qui renvoient, ou non, au L96 G), sous réserve de l'indépendance de l'administration, pour les infractions les plus graves (cf. supra : criminalité, délinquance grave) et les manquements graves aux règles qu'elles sont chargées de faire appliquer (cf. L34-1 CPCE).


    Droit de communication

    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 :

    • Pour Pôle emploi, le R5312-47 du Code du taff référence le L5312-13-2 du même Code qui exclut le L96 G du Livre des procédures fiscales, c'est-à-dire les opérateurs de communications électroniques ;

    • Concernant la Sécu dont la CAF, le Conseil constitutionnel a dit non en ce qui concerne les données de connexion, et l'article L114-20 du Code de la sécurité sociale exclut explicitement le L96 G du Livre des procédures fiscales.

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


    Un droit français pas conforme à la jurisprudence de la CJUE

    Conservation :

    • La conservation généralisée et indifférenciée des données de trafic et de localisation est prolongée par décrets depuis 2021. La menace est-elle réellement réelle et actuelle ou prévisible ? Vu la décision du Conseil d'État de juin 2023 (cf. « Historique » supra), peu d'espoir de ce côté-là, surtout que la sécurité nationale est l'une des compétences des États membres de l'UE ;

    • En droit français, la définition de la sécurité nationale est plus large que celle de la CJUE en ce qu'elle englobe, entre autres, les violences collectives, donc les manifs non autorisées, les activités de groupes radicaux, la délinquance et la criminalité organisées, le complot, l'insurrection, l'appel à s'armer, etc. ;

    • Les durées de conservation (5 ans pour l'identité civile, 1 an pour le reste) sont-elles excessives ? D'un côté, la CJUE a jugé qu'elles sont sans incidence sur la conformité ou non d'un régime (tant qu'elles permettent de tirer des conclusions précises sur la vie privée, c'est mort, même pour un jour). De l'autre, le RGPD et la CJUE disent que les données doivent être conservées pour une durée strictement limitée au nécessaire, y compris l'IP source (cf. LQDN 2020, point 156 ou LQDN contre HADOPI, point 93, ou Tele2, point 108, par ex.). En 2023, le Conseil d'État ne s'est pas prononcé au motif que le décret attaqué ne prévoit pas lui-même les durées de conservation (c'est la loi qui le fait) ;

    Accès :

    • Le parquet (aka procureur aka magistrat) autorise les accès aux données de connexion dans les enquêtes de flagrance ou préliminaires (même aux données d'identité et IP sources, même si la CJUE ne l'impose pas). Pour les informations judiciaires, c'est le juge d'instruction. Or, le procureur est celui qui poursuit (il n'est donc pas neutre), et le juge d'instruction n'est pas entièrement extérieur à l'enquête. De plus, dans l'attente d'une refonte, il appartient à un prévenu de saisir le juge du fond de nullités des réquisitions, ce qui constitue un contrôle a posteriori à trop longue échéance, d'autant que les conditions posées par la Cour de cassation sont trop strictes pour qu'une telle démarche aboutisse (cf. « Historique » supra) ;

    • Des administrations agissant comme autorité de poursuites peuvent accéder aux données de trafic et de localisation sans contrôle indépendant préalable. La douane sollicite le procureur. Le cas HADOPI est devant le Conseil d'État (même si la HADOPI ne demande pas les données de trafic aux opérateurs, elle a le titre des œuvres présumées piratées). Quid des autres administrations ? ;

    • Les échanges entre services de renseignement, qui peuvent porter sur des données de connexion, ne font pas l'objet d'un contrôle préalable ;

    • Une injonction de conservation rapide (ce que sont les réquisitions par le judiciaire ou par une administration) donne accès aux données déjà conservées par obligation légale, c'est-à-dire à l'historique. Cette conception, validée par la Cour de cassation en juillet 2022 (cf. supra), même si elle est logique, n'a pas été examinée par la CJUE et n'est pas prévue (à charge comme à décharge) par la Convention de Budapest qui instaure la conservation rapide ;

    • Ces injonctions permettent également d'accéder à des données de trafic et de localisation qui ont été conservées pour une autre finalité que celle faisant l'objet de l'enquête (ex. : les données de trafic et de localisation, conservées pour la sécurité nationale, peuvent être utilisées dans une enquête sur un crime sans rapport avec la sécu nationale). Source 1, page 84 ; Source 2, page 10. La CJUE réprouve cela si la finalité d'accès est inférieure à la finalité de conservation ;

    • Les mêmes injonctions permettant d'accéder aux données de connexion de l'entourage d'un suspect, de personnes présentes dans une zone géographique (cf. point « Recherche géographique inversée »), etc. De même, la conformité des logiciels de rapprochement judiciaire apparaît douteuse : ils manipulent plus de données que nécessaire, ils font du rapprochement automatisé, ils reposent en partie sur la découverte fortuite, etc. ;

    • Qu'est-ce que la criminalité grave dans la conception de la CJUE ? Qu'est-ce que les manquements graves aux règles que les administrations sont chargées de faire appliquer ? En juillet 2022, la Cour de cassation a jugé qu'un quantum de peine ne suffit pas à caractériser de grave une infraction, et la CJUE a été dans le même sens dans son arrêt LQDN contre HADOPI de 2024. Or, c'est ce que prévoit l'article 60-1-2 du Code de procédure pénale. les critères dégagés par la Cassation n'y ont pas été intégrés. De même, cet article ne s'applique pas au droit de communication des administrations qui reste donc câblé sur criminalité, délinquance grave et manquements graves, sauf restriction dans chaque loi sectorielle. Si la CJUE semble avoir laissé aux États le soin de définir ce qu'est la criminalité grave (cf. point « 2024 » de la section « Historique » ci-dessus), y aura-t-il des divergences d'appréciation au sein de l'UE ? Comment seront-elles remontées à la CJUE ? ;

    • En avril 2021, le Conseil d'État a restreint au minimum l'information des personnes de l'accès à leurs données de connexion par les Renseignements : uniquement en cas d'erreur (accès à tort). Conformité douteuse, même si la CJUE semble plutôt aller dans ce sens.


    À la recherche d'un paradis inexistant

    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.


    Futur

    • Le traitement des adresses IP par la HADOPI est toujours devant le Conseil d'État après la question préjudicielle C-470/21. Dossier 433539 ;

    • Analyse d'impact de la Commission européenne en vue d'actualiser les règles de l'UE en matière de conservation des données de connexion. Prévue pour 2025 si la feuille de route est validée en juillet 2025 ;

    • Refonte, en France, de l'accès aux données de connexion dans les enquêtes pénales. Suite à la mission Lallet ;

    • Édiction, en France, du décret précisant l'obligation tirée du L34-1 CPCE de vérifier l'identité civile.


    Concrètement

    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.


    Qui est concerné ?

    Deux catégories d'intermédiaires techniques sont concernées :

    • Les hébergeurs de contenus publics. Pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 2 de la LCEN pour la définition, et article 6, V, A pour l'obligation ;

    • Les opérateurs de communications électroniques ouverts au public. Pour concourir à identifier l'auteur d'une communication. Article R10-13 du CPCE. ET, pour les FAI, pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 1 de la LCEN, et article 6, V, A pour l'obligation qui visent explicitement les FAI, pas l'ensemble des opérateurs de communications électroniques (ce qui est logique : comment publier un contenu sur un téléphone fixe, par ex. ?).

    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 :

    • 1) exploitent un réseau de communications électroniques (ouvert au public)
      ou
    • 2) qui fournissent un service de communications électroniques (idem)
      ou
    • 3) qui offrent un accès à des services de communication au public en ligne
      ou
    • 4) qui offrent au public, au titre d'une activité professionnelle principale ou accessoire, une connexion permettant une communication en ligne.

    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.


    Un site web ?

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


    Un serveur emails ? Un serveur de messagerie instantanée ?

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


    Que faut-il collecter et conserver ? Combien de temps ?

    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 :

    • Identité. Noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone, adresse emails. On notera que, pour un service de communication au public en ligne, l'article 6, III, 1, a ne prévoit pas la communication de la date et du lieu de naissance à l'hébergeur. Normalement, un décret ne peut pas prévoir des choses en sus de la loi… Conservation : 5 ans après la fin du contrat ;

    • Autres informations contractuelles. Identifiant utilisé (?), pseudos utilisés, les données permettant à un utilisateur de vérifier ou de modifier son mdp (email de secours, CE : tous les « canaux de communication déclarés au préalable par l'utilisateur pour permettre la récupération de comptes ») dont 2FA. Conservation : 1 an après la fin du contrat ;

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

      • Pour les opérateurs : identifiant de la connexion (adresse IP, d'après le CE), identifiants attribués à l'abonné, adresse IP et port source (CE : IP publique + port pour les FSI & co, et IP publique + identité civile ou IP privée pour les FAI. Pour l'IP privée, côté FAI, donc, je pensais CGNAT, mais le CE écrit « lorsque elle est partagée entre plusieurs terminaux dans le cas des réseaux locaux », ce qui englobe aussi le NAPT d'une box qui a une IP publique) ;

      • Pour les hébergeurs : identifiant de la connexion à l'origine de la communication (adresse IP), les types de protocoles utilisés pour la connexion au service et le transfert des contenus.
    • Données de trafic et de localisation. Conservation : 1 an après la connexion ou la création d'un contenu. Uniquement sous injonction du premier ministre (ce qui est le cas, cf. décret 2024-901).
      • Pour les opérateurs : dates et heures de début et de fin de la connexion ;

      • Pour les hébergeurs : l'identifiant attribué au contenu (ID dans la BDD, etc.), la nature de l'opération (ajout, modification, suppression ?), les date et heure de l'opération, l'identifiant de l'utilisateur ayant produit le contenu s'il l'a fourni.

    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.


    De l'ambiguïté historique à la légende urbaine

    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.


    Journaux techniques

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


    RGPD

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

    Wed Jul 12 09:44:34 2023 - permalink -
    - http://shaarli.guiguishow.info/?LxxJsA
  • J'ai envoyé 10246 CVs avec un bot, voici ce j'ai appris - YouTube

    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 :

    • ChatGPT sait inventer (genre des exemples de sites web qui n'existent pas…) et bullshiter à la perfection, c'est un outil qui sert uniquement à ça ;

    • Plus l'on donne de contexte à ChatGPT avant de l'interroger, plus ses réponses sont pertinentes (d'où le "match" Enthoven versus ChatGPT pour l'épreuve de philo du bac 2023 manquait de sérieux). Dans le cas d'espèce, c'est important car les prétentions salariales et le sens des mots diffère en fonction du métier ;

    • Le COBOL est toujours demandé (surtout par les banques), c'est connu ;

    • Le bagout a une réelle influence (+22 %, cf. ci-dessous). Est-ce vraiment étonnant dans un monde qui a valorisé Tapie (et tant d'autres), qui se laisse enfumer par n'importe quel label, société commerciale ou politicien, et dans lequel la majorité d'entre nous est impressionnée par ChatGPT plutôt que de remettre en cause la pertinence et l'utilité des situations qui nous imposent de bullshiter et de les refuser ? On a la société que l'on forme.

    J'ignorais que :

    • Stable Diffusion peut être contraint par des extensions pour ajuster la pose d'un sujet, modifier uniquement une partie de l'image, etc. ;

    • Des extensions Chrome toutes simples et gratos permettent de contourner les CAPTCHA (la vidéo illustre ça avec le CAPTCHA de Cloudflare). :O

    Chiffres :

    • 71 % des candidatures ne reçoivent pas de réponse (cf. ci-dessous) ;

    • Les candidatures avec des fautes d'orthographe ont obtenu -3 % de réponses positives. Je suis en désaccord avec Micode : c'est impressionnant sur un grand nombre de candidatures, insignifiant sinon. Aucune influence pour les bac+5 (le diplôme valide de facto le profil ?), mais -12 % de réponse pour un diplôme < bac+5 ;

    • Le niveau d'études augmente le nombre de réponses positives de 5 % pour un profil ingénieur, et ne change rien pour un profil commercial (est-il plus pertinent de mettre en avant ses expériences pros sur ce type de poste ?) ;

    • Faut-il sourire sur sa photo de CV ? Non. (L'expression sur les photos qu'on aperçoit dans la vidéo est neutre.) ;

    • Vendre du rêve, tout enrober, présenter la moindre action comme étant épique (« j'ai ré-organisé le magasin » = « Élaboration d'un plan pour ré-agencer et optimiser les surfaces de vente »), ça rapporte +23 % de réponses positives.

    Il reste plusieurs biais dans la méthodologie :

    • Je pense que le taux de réponse doit fortement varier en fonction du métier recherché. Ou alors il est révélateur que le CV n'est pas adapté à l'offre. Un taux de 71 % est inhabituel pour un emploi en informatique ;

    • La prise en compte des fautes d'orthographe doit dépendre du métier (relations avec le public ou non) et du niveau de qualification. De même, Micode ne précise pas leur ampleur et leur récurrence dans ses candidatures (tout le monde commet des fautes, c'est la fréquence qui est pénalisée, à mon avis) ;

    • L'appréciation du niveau d'études dépend de la qualification du métier. De même, la voix off parle de « grande école » ou non quand l'image montre « Bac+5 » / « Si non bac+5 », alors que ce n'est pas équivalent, surtout dans le commerce (la grande école sert à se constituer un réseau social, rien de plus).

    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.

    Sun Jul 9 20:48:55 2023 - permalink -
    - https://www.youtube.com/watch?v=9aYgKQDOjI0
  • Dix ans d'emails auto-hébergés

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

    Sun Jul 9 14:02:53 2023 - permalink -
    - http://shaarli.guiguishow.info/?7aioyg
  • RFC 8659 - DNS Certification Authority Authorization (CAA) Resource Record

    Mes notes sur CAA.

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

    Sun Jul 9 11:41:25 2023 - permalink -
    - https://datatracker.ietf.org/doc/html/rfc8659
  • Comment identifier des hébergeurs informatiques à taille humaine et les évaluer ?

    J'ai déménagé mon serveur perso (pas celui qui héberge ce site web). Retour d'expérience.


    Historique et problématique

    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 :

    • J'utilise IPv6. OVH attribue une unique IP à chaque client. Or, la norme est d'attribuer un réseau /64 par client. Donc les mécanismes anti-spam bloquent à cette granularité. Donc au moindre voisin (de réseau) spammeur ou mal configuré, vlam, je suis pénalisé. Je suis ainsi listé dans la liste CSS de Spamhaus. Je les ai contactés : un voisin émet en IPv6 sans AAAA ni PTR associé, donc vlam. J'ai contacté ledit voisin : aucune réponse, bien entendu. J'ai contacté l'assistance d'OVH : aucune réponse satisfaisante, bien entendu (l'attribution d'un /64 est en projet, faire un signalement sur l'adresse abuse@). J'ai procédé au signalement abuse : aucune réaction. Quand bien même il y en aurait eu, le problème reviendrait au premier voisin mal-configuré, c'est sans fin ;

    • Mon IPv4 et mon domaine ne sont pas listés dans une liste de blocage (soit on fait le tour des principales, soit on trouve des testeurs multi-listes dans un moteur de recherche). En revanche, OVH est réputé pour être un gros émetteur de spam. Donc, ses réseaux /24 (ou plus grand) et/ou son numéro d'AS sont listés dans des listes de blocage. Aucune solution.


    Cahier des charges

    • Je veux une organisation commerciale. Je ne souhaite pas m'impliquer dans une association ni faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement. De plus, j'ai déjà vu des comportements douteux d'adminsys associatifs, et je n'ai pas la motivation de faire le tri. Ça exclut les CHATONS (d'autant qu'au moins la moitié d'entre eux reposent sur des gros hébergeurs style OVH, Scaleway ou Hetzner ‒ source ‒) ;

    • Je veux une machine virtuelle. Cela exclut beaucoup d'hébergeurs dont O2Switch, Netim, Weboupro, etc. ;

    • Je veux une offre grand-public, une commande automatisée et un espace client qui me procure de l'autonomie dans la gestion quotidienne de ma machine virtuelle. Pas de devis ni de montage spécifique à ma personne ni d'infogérance. Là encore, ce critère exclut beaucoup d'entités dont Octopuce, FullSave, Evolix, etc. ;

    • Je veux une société commerciale française avec des infrastructures en France et une majorité de ses affaires en France. Deux objectifs : 1) déterminer quelle législation s'applique (une grande partie de ma vie numérique passe par ce serveur perso) ; 2) favoriser des acteurs locaux (voir critère suivant). Ce critère élimine beaucoup d'entités dont Hetzner, Infomaniak, Amen (actionnaire italien, groupe européen), IONOS (ex-1&1), Gandi (qui, au début 2023, a fusionné avec une entité néerlandaise, sans compter la somptueuse augmentation des tarifs annoncée et la fin de services cool dont les emails inclus avec un nom de domaine), Oxabox, MonoVM, etc. ;

    • Je veux une entité qui n'est pas marquée au fer rouge comme hébergeant des spammeurs, et qui propose un réseau IPv6 de taille /64 au minimum (lire la fin de la section précédente pour comprendre). Cela est difficile à évaluer objectivement. J'ai utilisé UCEPROTECT et Spamhaus (qui est massivement utilisé) pour vérifier le score de l'AS et de plusieurs réseaux IP de chaque hébergeur. Les chiffres portent sur les 7 derniers jours, donc il faut surveiller quelques semaines pour avoir une vision correcte. J'ai également privilégié les petites entités. L'idée est : plus c'est petit, plus c'est confidentiel, plus ça augmente la probabilité d'éviter les spammeurs et les serveurs mal configurés. Là encore, c'est difficile à évaluer objectivement. J'ai pris en compte le chiffre d'affaires déclaré, la taille du réseau (le nombre d'adresses IP), le contenu et l'aspect du site web (j'ai une expérience qui me permet de juger grosso-modo, tel un Etchebest dans Cauchemar en cuisine). Ça exclut Scaleway (trop gros, mais score spam OK), Ikoula (risque de spam en hausse ces dernières semaines) ;

    • Je veux une connectivité décente aux autres réseaux français. Pour l'évaluer, j'utilise le looking glass du NLNOG, RIPEstat, et BGP HE ;

    • Je veux les services et outils usuels : paiement par prélèvement ou virement bancaire, IPv6, VNC, mode rescue, reverse IP, etc. ;

    • Je privilégie une infrastructure en logiciel libre (KVM, etc.).


    Candidats

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

      • Score spam quasi OK. Moyen mis en œuvre pour le conserver : demander un justificatif d'identité et de domicile. La loi dispose qu'un hébergeur doit collecter noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone et adresse emails (mais les hébergeurs n'ont pas la charge de vérifier ces informations en collectant des justificatifs), donc ça ne me paraît pas être excessif ;

      • Le réseau semble avoir IELO comme transitaire principal (HE et IP Max en sus). J'en ai plutôt une bonne image (bien connecté aux réseaux français), donc ça ne m'inquiète pas ;

      • Site web et espace client épurés, pas trouzemilles scripts, feuilles de style, etc. téléchargés depuis trouzemilles prestataires. Google reCAPTCHA dans la page de contact et Google Fonts sur la page d'accueil tout de même.
    • Ikoula :

      • Score spam en hausse ces dernières semaines, plus élevé que Scaleway. Un réseau blacklisté ;

      • Quelques merdes sur le site web dont jquery.

      • Rachetée par Sewan en 2021. Agglomérat de différentes sociétés française, belge, espagnole, allemande, ricaine du monde des télécoms et de l'hébergement. 130 M€ de CA en 2021 (source = societe.com), soit plus que Scaleway. On s'éloigne de la petite entité.
    • PulseHeberg :

      • Site web derrière Cloudflare. Ça retire toute crédibilité. T'es hébergeur, mais t'es pas capable d'héberger ta vitrine ? Tu vantes ta capacité à résister aux DDOS, mais pas pour ton site web ? De plus, vu comment j'asticote un tas d'entité sur la non-conformité au RGPD que cela représente, laisser passer ça serait incohérent ;

      • Quelques merdes sur le site web : Google Fonts, unpkg.com, etc. ;

      • Un développement tourné vers l'international, notamment vers les États-Unis (leur site web annonce un futur centre de données à San Jose), donc un potentiel conflit de lois à cause du Cloud Act ricain.
    • Ligne Web Services (LWS) :

      • Site web derrière Cloudflare ;

      • Adista en transitaire unique, ça craint un peu.
    • OuiHeberg :

      • Cloudflare ;

      • Connectivité : IPv4 = que des prestataires étrangers dont j'ignore la qualité de leurs interconnexions avec les réseaux français ; IPv6 = uniquement Cogent qui s'est livrée à des guéguerres commerciales avec Google et Hurricane Electric, dont la conséquence était l'impossibilité d'accéder à ces réseaux depuis Cogent.
    • OMGSERV :

      • Cloudflare ;

      • Numéro d'AS introuvable donc impossible de vérifier la réputation et la connectivité du réseau. S'adresse essentiellement aux joueurs en ligne qui sont rarement de bons adminsys, ce qui renforce ma défiance. (Sans compter Teamspeak qui facilite masse d'attaques volumétriques).
    • ONETSolutions :

      • Cloudflare ;

      • Le numéro d'AS que j'ai trouvé annonce aucun préfixe IP, donc impossible de vérifier la réputation et la connectivité du réseau.
    • Inulogic (anciennement Free-h) :
      • Pas d'IPv6 ;

      • Connectivité IPv4 : uniquement Cogent, ça craint.


    Ordre de grandeur

    Chiffres d'affaires 2021 :

    • OVH : 556 millions d'euros ;

    • Scaleway : 94 M€ ;

    • Ikoula : 6,2 M€ (mais société d'un groupe dont la filiale française a déclaré 130 M€) ;

    • FirstHeberg : 1,3 M€ (avec des activités de FAI fibre, téléphonie, etc.) ;

    • PulseHeberg et LWS ne publient pas leur CA. Je n'ai pas cherché les autres entités vu qu'elles ne m'intéressent pas.

    Source : societe.com.


    Retenu

    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 :

    • Propos publics éruptifs (sur le coût de l'électricité, par ex.) ou plaintifs (sur le coût des attaques DDOS il y a quelques années, là où d'autres gens du métier y voyaient une absence d'anticipation et/ou des mauvais choix techniques en connaissance de cause) ou contraire à mes convictions (sur la neutralité du réseau) tenus par le patron. (Twitter est désormais un réseau fermé, donc impossible de pointer les propos, sans compter que telle n'est pas mon intention) ;

    • Lacunes techniques (VNC en panne quasiment une semaine, pas de prélèvement bancaire, la section facturation de l'espace client, IPv6 pas au même niveau d'intégration qu'IPv4, rejet des adresses emails contenant un délimiteur « + », etc.) et rédactionnelles qui entraînent de la confusion (sur le site web et l'espace client, genre écart entre ce qui est annoncé et pratiqué, comme la définition du mdp ou le déblocage du port tcp/25). J'ai remonté tout ça à l'assistance.

    On verra comment ça se passe à la longue.


    Procédure de migration

    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.

    Sat Jul 8 18:29:52 2023 - permalink -
    - http://shaarli.guiguishow.info/?fVRjRA
Links per page: 20 50 100
◄Older
page 30 / 277
Newer►
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community