GuiGui's Show

Depuis un peu plus d'un an, l'interface web de Google YouTube ne m'affiche plus les vidéos au motif que je devrais me connecter pour prouver que je ne suis pas un robot.

Il s'agit d'un blocage fondé sur une notation arbitraire et opaque des adresses IP. À ce stade et vu le peu d'infos dont je dispose, la responsabilité semble être partagée entre les géants du Net (car il n'y a pas que Google) et mon Fournisseur d'accès à Internet associatif.

Au début, j'utilisais yt-dlp avec un tmpfs (= un ramdisk) comme destination.

Un tmpfs se vide à chaque redémarrage de l'ordinateur. Comme le consigne la doc, le paramètre -o crée les dossiers qui n'existent pas, donc j'utilisais yt-dlp -o /tmp/ytd/%(title)s.%(ext)s via un fichier de configuration (j'vais y revenir).

Puis Google YouTube a aussi appliqué le blocage par IP aux flux vidéo eux-mêmes.

J'utilisais donc yt-dlp et la fonctionnalité mandataire SOCKS de SSH via un alias dans mon terminal (alias ytd='yt-dlp --proxy socks5://127.0.0.1:6666').

Bien souvent, le son est séparé de l'image, donc avant de regarder une vidéo, il faut attendre le téléchargement entier des deux pistes et la fusion par yt-dlp (via ffmpeg).

Du coup, pour accélérer les choses, je me suis mis à restreindre la définition des vidéos à 720p max via le paramètre -f de yt-dlp : ytd -f 247+ba (piste vidéo dont l'identifiant est 247 et piste audio de la meilleure qualité disponible). L'identifiant 247 était stable, à part quelques exceptions, de vieilles vidéos, par ex.

Depuis quelques jours, l'identifiant de piste vidéo a changé, et il n'est plus identique entre les chaînes.

yt-dlp ne pourrait-il pas identifier automatiquement la « bonne » piste vidéo ? Bien sûr que si : -f 'bv[height<=720]+ba'. Plusieurs autres filtres (critères) sont disponibles. C'est via un article de Lord que j'ai découvert cette syntaxe.

Certaines chaînes doublent la bande son de leurs vidéos. Pour avoir la meilleure piste vidéo tant que la définition est inférieure ou égale à 720p et la meilleure piste audio tant qu'elle est en français ou la meilleure piste audio sans étiquette de langue : -f 'bv[height<=720]+(ba[language=fr]/ba)'.

yt-dlp accepte d'être configuré via un fichier.

Ce fichier de configuration est cherché dans plusieurs emplacements.

Le plus pratique, car il peut être caché tout en étant à côté des autres fichiers de conf, me semble être ~/.yt-dlp/config. C'est celui que j'utilise.

La syntaxe du fichier est donnée dans la doc précitée. Dans mon cas :

-f 'bv[height<=720]+(ba[language=fr]/ba)'

-o /tmp/ytd/%(title)s.%(ext)s

(Je ne mets pas le proxy, car je ne l'utilise pas en dehors de Google YouTube, donc un alias dans mon terminal est plus adapté).

J'ai déjà beaucoup écrit sur les données de connexion. J'ai actualisé cet article.

Pas de nouveauté, pas de changement en pratique, toujours au stade du blablabla.

Tous ces rapports portent sur l'utilisation des données de connexion dans les enquêtes pénales.

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 »

• Novembre 2023

• En 2022, environ 3 millions de données de connexion ont fait l'objet d'une réquisition (page 11) ;

  • Environ moitié données d'identification, comme l'identité civile de toutes les personnes présentes dans une zone ou l'identité civile derrière un numéro d'appel (page 17). L'autre moitié, c'est les fadettes et la localisation (page 39). Internet semble insignifiant, ce qui explique en partie l'orientation du rapport sur la téléphonie, les 4 grands opérateurs, les OTT (opérateurs sans numérotation = VoIP sans accord commercial avec FAI : Discord, Signal, WhatsApp, etc.), etc. ;
    
    
  • Hausse tendancielle de 10 % par an jusqu'en 2022 (page 11). Graphique page 38. + 0,36 % entre 2021 et 2022 (refonte du cadre législatif FR), page 99. Attention : le rapport tente de faire croire que c'est l'arrêt de la Cour de cassation de 2022 qui aurait mis un frein alors que cela n'est pas flagrant sur le graphique proposé ;
    
    
  • Attention aux chiffres : une demande de bornage pour le même point d'une même enquête = 4 gros opérateurs pour trois antennes (couvrant à 360 degrés une zone) = 12 réquisitions (page 39).

• Le rapport reconnaît un « accès massif aux données de connexion ». Causes :

  • « La facilité d’un tel accès » en ce, qu'avant 2022 (loi sur le harcèlement scolaire, voir ici), cet accès était régi par le droit commun des réquisitions, sans garde-fou, qui permettait de recueillir toute information intéressant l'enquête (page 39) ;
    
    
  • Les enquêteurs ont pris l'habitude de demander, en premier lieu, par réflexe, les facture détaillées, qui contiennent des éléments au-delà de l'infraction, sans rapport avec celle-ci (page 109). Seul l'argent (compensation des opérateurs, cf. infra) a limité le jeu (page 40) ;
    
    
  • Pages 34-37 : premier tri avant de solliciter des mesures plus intrusives comme la géolocalisation en temps réel ou les écoutes (plus pour des questions de thune que d'amour des libertés, à mon avis). Les avocats à tout stade de la procédure. Le droit au silence. Les citoyens ne veulent plus témoigner. Les criminels, sauf les primo, maîtriseraient les techniques de la police scientifique et ne laisseraient plus de traces d'ADN & co (mais des données de connexion si ? J'y crois moyen). Essor des messageries chiffrées (pourquoi, alors, la moitié des réquisitions portent sur des fadettes ?). Gain de temps et d'effectifs RH. Les magistrats voudraient des données de connexion dans les dossiers, même pour du vol à la tire, sinon ils considérent qu'il y a doute qui doit profiter à l'accusé (étonnant, non ?). Les citoyens voudraient l'efficacité de la répression des infractions. Les données de connexion seraient essentielles aux enquêtes liées à la délinquance du quotidien (page 55).

• L'impact des arrêts de la Cour de justice de l'union européenne (CJUE) a été limité :

  • À mon avis, à la lecture du rapport, ils ont calmé le jeu sur l'accès (par une entité indépendante, etc.). Reste la conservation ;
    
    
  • Réactions très diverses des États-Membres. Page 58 : en sus de la France, 12 États-Membres auraient toujours une conservation généralisée. D'autres États-membres ont toujours un accès trop ouvert. D'autres n'ont pas adapté leur législation. Aucune action en manquement de la Commission européenne. Seule l'Allemagne le vivrait bien (elle n'a jamais voulu la rétention des données de connexion). Étude comparative à partir de la page 137 ;
    
    
  • La conservation rapide (injonction faite à un intermédiaire technique de garder ce qu'il détient à l'instant T) implique l'absence d'historique / de rétrospective, ce qui serait insuffisant pour lutter contre la criminalité grave (cf. Slovaquie). Page 61 ;
    
    
  • la conservation ciblée est compliquée à mettre en œuvre, juridiquement et techniquement : quels critères non-discriminatoires utiliser ? Les zones particulièrement exposées à la menace (aéroports, gare, infrastructures, institutions, etc.) ou celles présentant le taux de criminalité le plus important sont-elles pertinentes ? Comment le calcule-t-on (nombre d'infractions uniquement => pouf, toutes les grandes villes sont surveillées) ? Fiabilité (comme en France, la criminalité déclarée par les flics contient de nombreuses erreurs, cf. page 141) ? En Belgique et au Danemark, 67 % de la population est concernée par de la conservation dite ciblée… Quid du déplacement de la criminalité (les quartiers criminels des trois dernières années ne seront pas forcément ceux de demain) ? Et si je prépare mon crime hors des zones ciblées ? Au Danemark, la conservation vise des catégories de personnes : automatique, pour 3 à 10 ans, pour les condamnées (quid de la rédemption ?) et pour ceux qui ont fait l'objet d'une interception téléphonique (en quoi ça prouve quoi que ce soit ?) ;
    
    

  • Dissensions au sein de la Commission européenne (les directions générales s'écharpent, mais, au global, sont plutôt pro-flicage) et entre la Commission, le Conseil européen (pro-flicage) et le Parlement européen (anti-flicage) sur l'équilibre à tenir entre poursuite des infractions et protection de la vie privée. Page 69 ;

  • Les rapporteurs évoquent un possible glissement vers d'autres techniques en France : LAPI, vidéo-surveillance, interceptions des communications, enquêtes administratives (plus intrusives mais ciblées donc moins nombreuses, à mon avis), porosité entre les services de renseignement et la justice (ce dont l'Allemagne est soupçonnée, cf. page 123) ou autres preuves numériques (réquisition d'un smartphone, IMSI catcher, perquisition numérique, etc.) ;

    • À mon avis, pour LAPI et la vidéo-surveillance, il faudra décider si tout cela est ciblé au motif que "peu" d'endroits sont couverts, ou si ça ne l'est pas car, si c'est positionné aux endroits clés, alors c'est « susceptible de tirer des conclusions précises sur la vie privée d'une personne » (mantra de la CJUE pour invalider la rétention généralisée). À mes yeux, une plaque d'immatriculation a le même statut qu'une adresse IP (identification) ;
  • Page 114 : certains demandent toujours des autorisations prospectives : accès aux fadettes d'un suspect puis identification des contacts voire accès aux fadettes et aux autres données de connexion d'un contact, tout ça à partir d'une seule autorisation initiale. Les rapporteurs doutent de la conformité à la jurisprudence de la CJUE qui veut un contrôle préalable de chaque accès. Bref, la leçon n'a pas encore été apprise.
• À partir de la page 137, étude comparative de la conservation des données de connexion dans l'UE. Quelques éléments hallucinants : l'Irlande conservait 2 ans. Aucune mise en conformité après l'arrêt Digital Right Ireland, seulement après Garda Síochána ; Italie : conservation toujours généralisée, pour 6 ans (!) ; Lettonie : 18 mois ; Pologne a ignoré les arrêts CJUE alors que certains pensent que la motivation de la CJUE vient des démocraties illibérales ; Pays-Bas et Slovaquie : seules les données utiles aux besoins techniques ou commerciaux des opérateurs sont disponibles ;
  
  

• Page 85 : la conservation rapide vient de la Convention de Budapest de 2001 sur la cybercriminalité. Celle-ci ne précise pas si cela porte sur l'historique (données conservées). La CJUE n'a rien dit que la conservation rapide, sauf qu'il ne peut y avoir accès pour autre finalité que celle qui a justifié la collecte (criminalité grave != sécurité nationale). Mais une injonction de conservation rapide n'ajouterait-elle pas, après-coup, une finalité, se demandent les rapporteurs. Pour moi, c'est non, mais, au final, on retrouve cette idée de réutilisation pour une finalité compatible dans l'article 5(1)b du RGPD, et, au final, que la conservation ait lieu pour l'obligation légale X ou Y ne change environ rien… ;

• Pages 72 à 74 : règlement européen e-evidence (preuves électroniques dans les procédures pénales), adopté en 2023, entrée en vigueur en 2026 :

  • Rénove le cadre issu de la Convention de Budapest de 2001 sur la cybercriminalité ;
    
    
  • Forcer les grands acteurs du numérique à coopérer avec les autorités judiciaires de manière fluide, y compris pour des enquêtes nationales ;
    
    
  • Comme DMA / DSA : représentant légal dans l'UE dès que service proposé dans l'UE ;
    
    
  • Injonction à produire les preuves sous dix jours (8 h en cas d'urgence) ;
    
    
  • Injonction de conserver les preuves (conservation rapide, quick freeze) pour 60 jours, renouvelable pour 90 jours de plus ;
    
    
  • Les magistrats pourront émettre les deux types d'injonction pour toute infraction pénale en ce qui concerne les données d'identification. Seuls un juge du siège, un juge d'instruction ou une juridiction pourront requérir les données de trafic ou de localisation (que la nomenclature UE inclut dans les données de trafic), et le contenu, si l'infraction présumée est passible d'au moins 3 ans de taule ou pour certaines infractions entièrement ou partiellement commises en ligne (pédoporn, attaque d'un système d'information, terrorisme, etc.). En cas d'urgence, les enquêteurs pourront enjoindre, contrôle a posteriori sous 48 h ;
    
    
  • 2 % du chiffre d'affaires si manquement ;
    
    
  • Quelques gardes fous : si l'État d'émission d'une injonction n'est pas celui où a eu lieu l'infraction ni celui où réside l'auteur présumé, alors ledit État doit notifier sa demande aux autorités du pays d'établissement de l'intermédiaire technique, qui peut bloquer (mais bien sûûûûr). La notification pourra ( ;) ) être automatique pour les États émetteurs qui violent systématiquement l'état de droit ; protections spécifiques pour les avocats, journalistes, secret médical, etc. ;
    
    
  • Bien entendu, s'il n'y a pas de conservation généralisée, les injonctions ne retourneront que les données conservées par les intermédiaires techniques pour leurs besoins techniques ou commerciaux ;
    
    
  • Au final, ça respecte la jurisprudence de la CJUE en matière de données de connexion, d'où il est probable que ça serve de modèle / de fondation ;
    
    
  • Les rapporteurs voient, dans le quantum de peine et dans les infractions spécifiques, l'émergence d'une approche européenne de ce qu'est la criminalité grave (même si elle est déjà définie dans les procédures de coopérations, pour ces seules procédures). Elle ouvrerait la voie à une définition européenne des règles de procédures pénales (ce qui serait contraire à la répartition des compétences prévue par les traités).
• Les officiers de police judiciaire (OPJ) formulent leur demande aux magistrats par téléphone. Les OPJ demandaient aux opérateurs par fax, courrier, email. Faible traçabilité. Depuis 2016, Plateforme nationale des interceptions judiciaires (PNIJ) gérée par l'Agence nationale des techniques d’enquêtes numériques judiciaires (ANTENJ) ;
  
  
• Il faudrait harmoniser le périmètre des autorisations d'accès aux données de connexion car certains parquets les octroient par dossier pour 6 mois, d'autres pour chaque nouvelle ligne identifiée. Une autorisation par ligne semble au-delà des exigences de la CJUE, mais une par dossier ne semble pas acquise (page 113). De même, différences entre parquet et juge d'instruction du même ressort. Différences en fonction des individus mis en cause, du lieu, de l'environnement perso, etc. (page 18) ;
  
  
• De même, il faudrait préciser ce qu'il convient de conserver et combien de temps car l'appréciation varie chez les 4 grands opérateurs. Exemple : la localisation en l'absence de communication serait conservée 1 ans pour 2 d'entre eux, 90 jours pour un 3^e, pas conservé pour le dernier ;
  
  

• Normalement, le droit à la preuve catégorise les moyens de preuve en fonction de leur degré d'atteinte à la vie privée. Or, en matière de preuve numérique (au-delà des données de connexion donc, réquisition smartphone, perquisition numérique, etc.), il n'y a pas eu de réflexion globale, la législation a été complétée au fil de l'eau, au gré des techniques, ce qui induit une disparité des régimes. Un même quantum de peine autorise des techniques plus ou moins intrusives. Une URL est à la fois une métadonnée et un contenu (en ce qu'elle le révèle). Pourtant, les L851-3 (boîtes noires) et L851-2 (accès temps réel) du Code de la sécurité intérieure les chopent (le Conseil constitutionnel a dit non pour les boîtes noires dans sa décision 2025-885 DC sur la loi narcotrafic. Je pense que le rapport confond accès en temps réel aux données de connexion et interception. De même, la liste des applis d'un smartphone en dit long sans être du contenu (pages 31-33). Bref, le clivage contenant (métadonnées) / contenu n'est pas pertinent, il faudrait revoir la classification des différentes données de connexion (identité civile, trafic/localisation, identification c'est-à-dire donnée pivot, comme une adresse IP) ;

• Plateforme nationale des interceptions judiciaires, PNIJ (pages 44-47) :

  • Dernier audit par la CNIL : 2022-2023. Dernier audit par l'ANSSI : 2016 (!) ;
    
    
  • En parallèle du Commissariat aux communications électroniques de défense qui intervient pour la supervision technique (définition des spécifications techniques des équipements déployés par les opérateurs pour mettre en œuvre leurs obligations légales, la mise en place des liaisons entre les opérateurs et les plateformes, la vérification de leur bon fonctionnement et du respect des normes de sécurité informatique, etc.). Le Commissariat est complémentaire à l'Agence nationale des techniques d’enquêtes numériques judiciaires (ANTENJ) qui assure la maintenance correctrice de la PNIJ, le développement de nouvelles fonctionnalités, et l'assistance aux utilisateurs ;
    
    
  • 20 à 30 opérateurs sont branchés sur la PNIJ (sur environ 1800), mais la collecte portant sur les clients des NVMO (opérateurs sans réseau physique) se ferait via les opérateurs disposant d'un réseau physique (hum… pourquoi avoir raccordé 20 à 30 opérateurs si ça sert à rien ?) ;
    
    
  • Traçabilité 3 ans des actions sur la PNIJ ;
    
    
  • La PNIJ ne contrôle pas l'authenticité de la demande : c'est l'OPJ qui saisi sa demande, pas le magistrat qui l'autorise ; la PNIJ ne vérifie pas si l'OPJ est dans le même ressort que le magistrat qui l'aurait autorisé ;
    
    
  • La PNIJ ne couvrirait pas les FAI (je pense que le rapport parle ici uniquement des interceptions, car, il consigne par ailleurs que les données de connexion passent par la PNIJ, et la grille de compensation financière prévoit des actions sur des adresses IP via la PNIJ, mais peut-être uniquement pour les 4 opérateurs…), les Over The Top (surtout ceux extra-UE comme Google ou Meta), ni les opérateurs satellites, ni l'interception en Outre-Mer.

• 20 à 25 % de « hors PNIJ », notamment par des logiciels d'interception tiers (pages 48-49). Le hors PNIJ, qui n'offre pas les mêmes garanties (traçabilité, sécurité, etc.) est anormalement élevé dans certains services (page 49). Attention au chiffre : la PNIJ ne couvre pas toutes les technos ni tous les opérateurs donc est-ce 20-25 % des requêtes que la PNIJ pourrait servir ou 20-25 % de toutes les réquisitions, ce qui a moins de sens ? ;

  • Confirmation que Google et Meta refusent de répondre en direct aux enquêteurs, hors PNIJ, ce à quoi ils ne sont pas tenus, et qu'ils contrôlent l'opportunité (la légitimité) de la demande (page 47) ;

• « Para-PNIJ » : réutilisation des données obtenues via la PNIJ (ou hors PNIJ) dans des logiciels de rapprochement judiciaire (MERCURE, ANACRIM, DeveryAnalytics, etc.) qui n'offrent pas les mêmes garanties (traçabilité, etc.), au titre que la PNIJ manque de fonctionnalités, genre, exemple périmé, la visualisation graphique de la géolocalisation (page 48) ;

  • Logiciels de rapprochement judiciaires :

    • Autorisés par la LOPPSI 2 de 2011, cf. les articles 230-20 à 230-27 et R40-39 à R40-41 du Code de procédure pénale (page 50). Le Conseil constitutionnel a posé une réserve d'interprétation dans sa décision 2011-625 DC : pas de traitement général, c'est par enquête. ;
      
      
    • Autorisés par décret après avis de la CNIL.
      
      
    • Chapsvision rachète tout le monde (MERCURE, Elektron, Deveryware, etc.) ;
  • Les rapporteurs s'inquiètent (pages 51-52) : l'usage de ces logiciels requiert une masse conséquente de données, l'usage constitue un rapprochement automatisé, de la découverte fortuite (donc comment adapter le contrôle, basé sur la gravité de l'atteinte aux droits, quand on ignore à l'avance ce qu'on va découvrir ?), et une absence de traçabilité.
• Avant août 2006, la compensation d'un accès aux données de connexion était librement facturée par les opérateurs (page 42). Depuis, forfait pour investir en matériel + facturation à l'acte, cf. A43-9 du Code de procédure pénal (note 2 en bas de page 41). 69 M€ en 2005, 38 M€ en 2006, 122,5 M€ en 2015 (page 42) ;
  
  
• Page 111 : l'ANSSI n'a pas de compétence pour superviser les équipements utilisés par les opérateurs pour collecter et conserver les données de connexion. La vulnérabilité aux attaques extérieures des systèmes d'information des 4 opérateurs est auditée par l'ANSSI au titre qu'ils sont OIV (c'est pour ça les fuites de données chez 3 d'en eux en 2024-2025 ? :)))) Sources : 1, 2, 3). Le R226-1 du Code pénal donne compétence à l'ANSSI sur l'emploi de dispositifs permettant les interceptions et la géolocalisation en temps réel. Les rapporteurs proposent l'homologation du matériel utilisé par les opérateurs pour collecter et conserver les données de connexion (lol) ;
  
  
• Recherche géographique inversée (qui était dans telle zone géographique à telle heure au lieu de vérifier si tel suspect était dans telle zone). Page 34 : « la liste des utilisateurs présents dans une même zone à un instant déterminé via le recueil des flux ayant transité par une ou plusieurs bornes » ; « Elles permettent également, par recoupement des numéros de téléphone ayant « borné » dans certains lieux au moment de la commission de plusieurs infractions ». Page 38 : « […] soit pour identifier l’ensemble des utilisateurs présents sur une zone par « bornage » […] ». Page 39. Page 122 : « Il va essayer de voir qui pouvait se trouver dans le secteur à l’heure concernée. ». On retrouve cela dans la grille tarifaire de compensation des opérateurs (MT 40 / MT 41). Ainsi, il n'y aurait pas que les mézants ricains qui pratique cela ? :)))) ;
  
  
• L'accès en temps réels aux données de connexion serait plus intrusif que l'accès différé (à ce qui est conservé), car ça recouvrerait aussi les données traitées par les opérateurs pour leurs besoins techniques, comme la localisation GPS (comment un opérateur a-t-il ça ?), les données d'acheminement qui permettent de détecter anonymisation ou VPN, les certificats électroniques ou encore les identifiants et les mots de passe (page 28). Gné ? Ça ressemble à de l'interception des communications, quel rapport avec les données de connexion ? ;
  
  
• La directive e-privacy, qui précise l'application du RGPD dans le domaine des communications électroniques et les dérogations, n'est pas entièrement compatible avec le RGPD, sans plus de précision. Page 70 ;
  
  
• Page 48 : « analyse des flux interne chiffrés » : kézako ? ;
  
  
• On reconnaît un rapport sénatorial à ce qu'à plusieurs reprises, les rapporteurs râlent que la CJUE contraint l'État alors que les grands acteurs du numérique font ce qu'ils veulent, y compris du profilage qui « est susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne » (qui est ce que la CJUE radote dans ses arrêts sur la rétention des données de connexion). Pages 24, 58, 69, 126. Pourtant, il y a le RGPD. Qui les laisse faire ? Pourquoi la CNIL et ses homologues européennes ne font jamais rien ?! Il faut combattre le privé comme le public.

Groupe européen de haut-niveau pour l'accès aux données pour une application efficace de la loi

• Aussi nommé groupe de réflexion « Going Dark » (:O) ou groupe d'experts ADELE (access to data for effective law enforcement) ;
  
  
• Sous l'autorité de la direction générale des affaires intérieures (Home) de la Commission européenne et de la Présidence du Conseil européen, qui sont tous deux pro-flicage, d'après le rapport de la section précédente, page 69 ;
  
  
• Recommandations en juin 2024, rapport final en novembre 2024 ;
  
  
• Ça va bien plus loin que les données de connexion : interception, déchiffrement, coopération, investigation numérique, preuve numérique. Je n'ai lu que les introductions, synthèses / résumés, et sections concernant la rétention des données de connexion ;
  
  
• Les données conservées par les intermédiaires techniques pour leurs besoins techniques ou commerciaux doivent être accessibles aux autorités, y compris si le fournisseur chiffre les métadonnées ou les données d'identité civile ;
  
  
• Forcer l'enregistrement des utilisateurs d'un service (création d'un compte), sans quoi, les fournisseurs de service qui n'ont pas de besoin commercial n'auront rien à communiquer en cas d'injonction (quid de l'adresse IP ?) ;
  
  
• Obligation minimale de conserver les données de connexion permettant d'identifier un utilisateur, comme l'adresse IP source et le numéro de port ;
  
  
• Le reste est basique : harmonisation du cadre juridique sur la rétention des données de connexion et sur l'accès à celles-ci (en se basant sur le règlement e-evidence, cf. supra), cadre indépendant des technos, standardisation des échanges entre acteurs, coopération, le chiffrement pose des difficultés, etc.

Déclaration du Comité européen de la protection des données (CEPD) sur les recommandations du groupe de haut-niveau

• Novembre 2024 ;
  
  
• Le groupe d'experts propose un régime de conservation harmonisé pour tous les fournisseurs de services qui peuvent octroyer un accès à des preuves numériques, peu importe leur type. Le CEPD y voit une extension au-delà des services de communication électroniques accessibles au public qui sont les seuls concernés à ce jour par la rétention des données de connexion, ce qui conduirait à une surveillance généralisée. Et, en effet, à la page 36 de son rapport, le groupe évoque les LLM, les constructeurs automobiles, etc. ;
  
  
• Sur la conservation minimale des éléments permettant d'identifier une personne, le CEPD rappelle qu'il s'agit de conserver l'identité civile et les adresses IP de manière indiscriminée. Dans son arrêt C-470/21 (LQDN / HADOPI), la CJUE a jugé qu'une telle conservation généralisée et indifférenciée est possible pour tout type d'infraction tant qu'elle ne permet pas de tirer des conclusions précises sur la vie privée d'une personne. Ainsi, le CEPD rappelle que toute combinaison des adresses IP avec d'autres données est impossible et que le raisonnement de la CJUE sur la conservation des IP ne s'applique pas forcément à d'autres types de données de trafic ou de localisation dès lors qu'elles permettent de tirer des conclusions précises sur la vie privée d'une personne.

Rapport d'Eurojust sur l'effet de la jurisprudence de la CJUE sur les régimes nationaux de rétention des données de connexion et la coopération judiciaire

• Novembre 2024 ;
  
  
• Je ne l'ai pas lu, je l'ai survolé. On retrouve ce qui a déjà été dit : diversité des durées, des données conservées, des garanties, des procédures, de ce que sont les infractions graves, etc. La plupart des États-Membres continuent de travailler sur le sujet. L'absence de données de connexion perturberait les enquêtes et la coopération judiciaire européenne (comme d'hab', ce point n'est pas vraiment étayé).

Étude sur la conservation des metadonnées des communications électroniques à des fins répressives

• 2020 ;
  
  
• Par un cabinet de conseil belge, pour la direction générale des affaires intérieures de la Commission européenne (pro-flicage, cf. supra) ;
  
  
• Je ne l'ai pas lu, je l'ai survolé ;
  
  
• Page 49 : appréciable diagramme de Venn sur les différents ensemble de données de connexion (identité civile, trafic, identification) ;
  
  
• Page 162 et suivantes : excellente annexe III sur les types de données de connexion conservées par chaque État-Membre de l'UE.

Problème

Une administration met à disposition un téléservice pour effectuer des démarches qui se déroulent sur un temps long (plusieurs années).

Elle notifie par courriel l'avancement d'un dossier. Cette notification ne contient aucune information autre que le numéro de dossier et elle renvoie au téléservice.

Quand on a plusieurs dossiers (en dizaines), il faut donc aller sur le téléservice ou consulter son inventaire (tableur) maison pour savoir de quel dossier il s'agit.

Il m'est donc impossible de prioriser ma réaction en fonction du dossier sans accomplir ces formalités au préalable.

C'est fastidieux. N'y a-t-il pas moins pénible ?

Pistes

J'ai deux idées reposant sur Sieve, un langage de script pour manipuler des emails côté serveur, cf. mon article sur le sujet.

Soit ajouter un drapeau IMAP (flag) contenant le nom du dossier administratif. Usuellement, ces drapeaux sont utilisés pour marquer un état (vu, répondu, etc., cf. RFC 9051), signaler une priorité (urgent, important, etc.) ou trier (perso, pro, etc.).

Soit ajouter le nom du dossier administratif dans le sujet du courriel.

Réalisation

Pour rappel, j'utilise PigeonHole, l'implémentation de Sieve de Dovecot (qui, en sus d'être un serveur IMAP / POP peut aussi être un MDA, un agent local de livraison des emails, qui s'occupe des derniers kilomètres, comme un facteur humain, nommé dovecot-lda).

Drapeau IMAP

D'abord, il faut utiliser l'action addflag <nom_drapeau> de l'extension imap4flags, cf. RFC 5232 :

require ["body", "imap4flags"];

if body :contains "<numéro_dossier_administratif>" {
  addflag "<nom_du_dossier_administratif>";

  stop;
}

Ensuite, il faut configurer ton logiciel de messagerie (MUA) pour qu'il affiche un libellé en fonction du drapeau. Avec Thunderbird, cela se passe dans Édition > Paramètres > onglet Général > rubrique Étiquettes.

Modification du sujet

Dans un courriel, comme dans un courrier, le sujet (objet) est un entête, comme la date, l'expéditeur, etc.

Il existe l'extension Sieve « Editheader » (RFC 5293).

Néanmoins, elle ne permet pas de modifier un entête, uniquement d'en ajouter et d'en supprimer. Dès lors, il me faudra stocker le contenu initial de l'entête entre les deux opérations.

L'extension Sieve « Variables » (RFC 5229) est là pour ça.

Comment affecter le contenu d'un entête existant à une variable ? Le RFC sur l'extension Variables donne la réponse : expression régulière (regex), capture, groupe de correspondance, etc. Tout cela est pris en charge par le comparateur :matches.

Il n'y a plus qu'à assembler ces différentes briques pour composer la solution.

Sur le web, je trouve un exemple tout prêt. Je le recopie :

require ["body", "variables", "editheader"];

if body :contains "<numéro_dossier_administratif>" {
  # On affecte le sujet existant à une variable nommée « varSubject »
  if header :matches "Subject" "*" {
    set "varSubject" "${1}";
  }

  deleteheader "Subject";

  # « last » est pour le confort : insertion de l'entête à la fin des autres entêtes, juste avant le corps
  addheader :last "Subject" "${varSubject} <nom_du_dossier_administratif>";

  stop;
}

Attention : avec Dovecot, il faut activer l'extension Editheader dans la configuration et la recharger avant de pouvoir l'utiliser dans un script, cf. la documentation (sinon : « error: require command: unknown Sieve capability `editheader' ») :

plugin {
  sieve_extensions = +editheader
}

On peut également restreindre les entêtes manipulables par un script Sieve via une liste des entêtes autorisés ou une liste des entêtes interdit. Je préconise d'activer ce paramètre.

Avantages et inconvénients

L'inconvénient principal du drapeau, c'est qu'il faut le définir dans le script Sieve et dans le client de courriels. La duplication d'une information doit toujours être évitée pour simplifier la maintenance. De plus, l'automatisation de l'ajout des drapeaux côté Thunderbird ne va pas être facile et, vu mes dizaines de dossiers administratifs, il est hors de question que je fasse le boulot à la main.

L'autre inconvénient, c'est qu'il faut cliquer sur un email dans Thunderbird pour voir son drapeau. Oui, un drapeau peut être associé à une couleur, mais vu le nombre de mes dossiers administratifs, c'est impossible à mémoriser.

L'inconvénient principal de la modification d'entête, c'est la sécurité et l'intégrité. Ce n'est pas pour rien que Dovecot n'active pas cette extension par défaut et permet de restreindre la manipulation à certains entêtes. Je ne l'aurais pas activée si je n'étais pas le seul utilisateur de mon serveur de courriel. De plus, que se passe-t-il en cas d'incident (plantage, panne d'électricité, etc.) entre la suppression de l'entête et son ajout ?

L'autre inconvénient est que c'est inutilisable sur des courriels que l'on compte utiliser comme preuves. Ce n'est pas mon cas, mais il faut y penser.

Précaution

Pour des raisons de performance, d'intégrité et d'évitement des faux positifs, je préconise de délimiter les emails susceptibles de faire l'objet d'une recherche dans leur corps ou de voir l'un de leur entête être modifié.

Rigolo

Je ne suis pas parvenu à utiliser les drapeaux prédéfinis dans Thunderbird (« Important », « Travail », « Personnel », etc.). Dans mon script Sieve, je les ai écrits en français, en anglais, en respectant la case ou non, rien à faire, Thunderbird les ignore.

Il reste un peu plus d'une semaine pour participer à cette consultation de la CNIL.

Ça serait bien que nous ne soyons pas uniquement les quelques mêmes à participer, afin de donner un élan populaire.

Il n'est pas nécessaire de répondre aux questions. Tu peux simplement exprimer qu'en tant que lambda, tu ne veux pas du tout d'images de traçage dans ta correspondance privée.

En bref, ce qui se joue :

• Un pixel de suivi / pixel espion / image de traçage est une image dans la version HTML d'un email qui informe l'expéditeur à chaque ouverture dudit email. Ça balance date+heure des ouvertures, adresse IP (si tu consultes tes emails au boulot, l'expéditeur peut associer ton employeur à ton identité, idem en vacances), marque et modèle du logiciel de messagerie / navigateur web et du terminal, etc. ;
  
  
• Oui, les webmails et les logiciels de messagerie peuvent les bloquer, mais ce n'est pas systématique. De plus, tout le monde peut afficher ses emails en version texte. Dans les deux cas, il y a toujours un moment où t'as besoin de repasser en HTML (ex. : quand l'expéditeur a inséré une version texte vide) ou de désactiver le blocage (pour diagnostiquer), ou par erreur, donc, tu te fais inévitablement fliquer ;
  
  
• Ces pixels tombent sous le coup de l'article 5(3) de la directive européenne ePrivacy (lire ici) et de sa transposition en droit français, l'article 82 de la loi Informatique et Libertés, qui imposent la nécessité à l'établissement de la communication électronique, ou la nécessité pour fournir un service expressément demandé, ou le consentement. Évidemment, la nécessité n'est pas remplie, donc il reste uniquement le consentement, comme l'affirme le Comité européen à la protection des données depuis 2006 (section V) ;
  
  
• Les mêmes dispositions s'appliquent aux cookies et autres traceurs sur les sites web. On voit le résultat : des bandeaux cookies imbitables à gogo à longueur de temps, un consentement pour plusieurs finalités prétendument connexes avec la mesure d'audience en cheval de Troie, de la mesure d'audience exemptée de consentement à condition d'anonymisation et que le logiciel soit bien paramétré, ce que personne ne peut vérifier, et, lorsqu'elle est saisie, même à l'appui d'un doute raisonnable argumenté, la CNIL se refuse de vérifier au motif que « par principe », c'est exempté de consentement ;
  
  
• En l'état actuel de son projet de recommandations, la CNIL se propose d'importer tout ce merdier dans nos courriels : finalités, y compris chimériques (sécurité), exemptées de consentement sous des conditions inatteignables ou invérifiables par le destinataire (et la CNIL s'y refusera) alors que les pixels espion ne sont pas nécessaires pour les atteindre, solliciter à nouveau le consentement quelques temps après un refus (ce qui signifie des vagues régulières d'emails), consentement en une fois à plusieurs finalités prétendument connexes avec la prospection commerciale comme cheval de Troie, ineffectivité technique du retrait du consentement, aucune obligation de joindre une version texte du message dans chaque email, etc. ;
  
  
• Ce projet de recommandation a été précédé, entre septembre 2023 et juin 2024, d'une concertation non-publique à laquelle ont participé essentiellement des représentants des responsables de traitement qui veulent nous fliquer toujours plus. Absence de respect des principes d'égalité de participation et d'impartialité. Voir le recours intenté par l'association Pour un RGPD respecté.

ÉDIT DU 21/07/2025 : Réponse de l'association Pour un RGPD respecté à la consultation. Tu peux t'en inspirer pour participer, copier-coller, renvoyer vers (« Je partage le positionnement de l'association PURR »), etc. FIN DE L'ÉDIT.

Version française.

Résumés en français : 1, 2.

Au cas où, l'article est chez Archive.org.

On ne peut plus regarder le direct de France 3 sans compte sur leur site web :

$ yt-dlp https://www.france.tv/france-3/direct.html
[francetv:site] Extracting URL: https://www.france.tv/france-3/direct.html
[francetv:site] direct: Downloading webpage
ERROR: [francetv:site] direct: Unable to extract video ID;

Je n'ai pas envie d'avoir un compte France TV. Ce n'est pas nécessaire à la finalité que j'entends poursuivre. Rajouter du flicage, non merci, il y en a déjà assez comme ça (journaux des serveurs web, cookies, traceurs, etc.).

Je récupère une liste de lecture. https://github.com/iptv-org/iptv a bien tourné sur l'une des rivières de shaarlis y a quelque temps. On cherche France 3 dans la liste des chaînes FR :

$ curl https://iptv-org.github.io/iptv/countries/fr.m3u 2>/dev/null | grep -B1 'france3'
#EXTINF:-1 tvg-id="France3.fr" tvg-logo="https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/France_3_2018.svg/512px-France_3_2018.svg.png" group-title="General",France 3 (1080p) [Geo-blocked]
https://raw.githubusercontent.com/Paradise-91/ParaTV/main/streams/francetv/france3.m3u8

vlc ne parvient pas à la lire :

$ cvlc https://raw.githubusercontent.com/Paradise-91/ParaTV/main/streams/francetv/france3.m3u8
VLC media player 3.0.21 Vetinari (revision 3.0.21-0-gdd8bfdbabe8)
[0000555739c375b0] dummy interface: using the dummy interface module...
[00007f0fc4001170] http demux error: local stream 1 error: Cancellation (0x8)
[00007f0fc4001170] adaptive demux error: Failed to create demuxer (nil) Unknown
[00007f0fc4001170] http demux error: local stream 3 error: Cancellation (0x8)
[00007f0fc4001170] adaptive demux error: Failed to create demuxer (nil) Unknown
[00007f0fc4001170] http demux error: local stream 5 error: Cancellation (0x8)
[00007f0fc4001170] adaptive demux error: Failed to create demuxer (nil) Unknown

(Vive les messages d'erreur peu explicites…)

yt-dlp y arrive mais ça ne sert à rien : tant que le téléchargement n'est pas terminé, le fichier vidéo est illisible avec VLC. On peut chaîner yt-dlp et vlc (yt-dlp -o - https://raw.githubusercontent.com/Paradise-91/ParaTV/main/streams/francetv/france3.m3u8 | vlc -), mais, après quelques dizaines de secondes, pouf, plus de son.

Je ne comprends pas pour quoi vlc ne parvient pas à lire la liste de lecture d'iptv-org, car curl (ou wget) la récupère et qu'elle semble parfaitement valide. J'observe néanmoins qu'elle contient les URL officielles de France TV, ce n'est pas une rediffusion. Étant abonné à un Fournisseur d'Accès à Internet associatif, je pense tout de suite à un blocage par IP, notamment car la liste de lecture FR expose clairement « [Geo-blocked] » (cf. ci-dessus) et qu'Akamai, le CDN utilisé par France TV, comme tous les géants du secteur, a tendance à considérer que mon FAI n'est pas digne de confiance. Je route le trafic dans des VPN sortant chez des opérateurs FR et considérés comme de confiance par les grands noms du CDN, mais ça ne fonctionne pas mieux.

Quelque chose m'interpelle : curl ou yt-dlp peuvent récupérer le flux via l'URL officielle contenue dans la playlist d'iptv-org, mais pas vlc :

$ curl -sv https://simulcast-p.ftven.fr/ZXhwPTE3NDc1Mjc0OTV+YWNsPSUyZip+aG1hYz0xNWQzNTU0YjdkZjIzMjk4OWMyYTMyY2RiYTRiM2RlMjI5MzQ5YzYzNDY4YmE2N2Q5YjAxNDZmMjQ2ZmEwMTEz/simulcast/France_3/hls_fr3/France_3-mp4a_96000_fra=1.m3u8 >/dev/null
[…]
< HTTP/2 200 
[…]

$ cvlc https://simulcast-p.ftven.fr/ZXhwPTE3NDc1Mjc0OTV+YWNsPSUyZip+aG1hYz0xNWQzNTU0YjdkZjIzMjk4OWMyYTMyY2RiYTRiM2RlMjI5MzQ5YzYzNDY4YmE2N2Q5YjAxNDZmMjQ2ZmEwMTEz/simulcast/France_3/hls_fr3/France_3-mp4a_96000_fra=1.m3u8
VLC media player 3.0.21 Vetinari (revision 3.0.21-0-gdd8bfdbabe8)
[000055b9470db500] dummy interface: using the dummy interface module...
[00007f6330001a70] access stream error: HTTP 403 error
[00007f6330001a70] http stream error: local stream 1 error: Cancellation (0x8)

Erreur HTTP 403 (accès interdit) pour vlc mais pas pour curl, depuis la même IP. Ça ne sentirait pas le blocage par user-agent (modèle et version du logiciel) ? (--http-user-agent ne fonctionne pas, il faut bien utiliser :http-user-agent= qui modifie le comportement qu'aura vlc avec le flux qui le précède. Source.)

vlc https://raw.githubusercontent.com/Paradise-91/ParaTV/main/streams/francetv/france3.m3u8 :http-user-agent='curl/7.88.1'

C'est bien ça…

Conclusion : vlc https://raw.githubusercontent.com/Paradise-91/ParaTV/main/streams/francetv/france3.m3u8 :http-user-agent='curl/7.88.1' pour regarder FR3.

C'est consternant de se faire autant emmerder par le service public de l'audiovisuel. Public, mais pas trop.

Depuis vendredi dernier (2 mai), une nouvelle saison inédite du jeu télévisé La Carte aux trésors est diffusée les vendredis soirs sur France 3. \o/

Dans le courrier des lecteurs du numéro 116 (février - avril 2025) de Fakir :

Jean-Baptiste nous raconte son mode de vie, avec quelques gros angles morts quand même, mais qui esquisse peut-être un futur…

À longueur de pages, on lit dans Fakir des témoignages de gens qui se sont flingué la santé à l'usine et qui n'arrivent pas à remplir leur caddie. Or, personne ne nous oblige à faire ce qu'on fait (ou à continuer de le faire). Je développe. Ici, dans la diagonale du vide, avec 500 € par mois, t'es le roi du pétrole (ou presque) si t'es proprio de ta bicoque (qui coûte pas cher). Il suffit de s'installer dans un centre-bourg à moitié vide (comme je l'ai fait), avec tous les commerces (je sais, ça devient rare), comme ça on évite de prendre la bagnole (gouffre financier]. La bouffe est pas chère (sauf si on est assez bête pour aller au supermarché). On peut se faire prêter un peu partout des bouts de terrain pour faire un potager (les vieux n'ont plus la force). Le troc marche à fond (légumes, services, etc.), on mutualise les bagnoles, les perceuses, les coups de main pour couper le bois, etc. Y a même du taf chez les artisans (les garagistes du coin s'arrachent les cheveux), dans les commerces et l'aide à la personne bien sûr. C'est sûr, c'est pas la vie de tous ces crétins de richards décérébrés (c'est beaucoup mieux d'ailleurs : moi je vois des loutres et des castors). En fait, je pense qu'on a tous des petits interrupteurs dans la tête, et qu'il suffit de basculer de « je subis ma pauvreté » à « je choisis ma pauvreté ». C'est vachement mieux, on a même l'impression d'être riches, quelque part.

Ça rejoint les propos du diplomate iranien Majid Rahnema dans son livre Quand la misère chasse la pauvreté rapportés dans le numéro 105 de Fakir : la pauvreté est une façon de vivre sobrement mais dignement, en indépendance. La misère, c'est perdre son pouvoir, dépendre économiquement d'une aide extérieure qui ne permet même pas de vivre dignement.

Je me note ça : la messagerie Signal se repose sur turn.cloudflare.com pour STUN (découverte de la présence d'un NAT et de l'adresse IP publique). Source : point d'accès Wi-Fi (hostapd) + wireshark.

J'en retire pas grand-chose. Oui, ça envoie l'IP publique à Cloudflare et ça lui révèle les dates+heures des tentatives d'appel, mais bon, c'est anecdotique. D'un autre côté, ce n'est pas sorcier de proposer un serveur STUN, surtout en comparaison d'un logiciel de messagerie texte+audio+vidéo… Ça jette le doute : si Signal externalise pour si peu, peut-on avoir confiance ? On est dans l'habituelle flemme de faire soi-même…

En revanche, je me demande si Signal utilise turn.cloudflare.com comme serveur TURN auquel cas les flux médias (audio et/ou vidéo) seraient relayés par Cloudflare. Le contenu des communications serait toujours chiffré, mais Cloudflare « saurait » qui parle à qui, quand, à quelle fréquence, etc. Dans ses paramètres, Signal propose une option pour relayer les flux médias via son infrastructure, donc je ne crois pas à l'utilisation du serveur TURN de CF. mais je vérifierai à l'occasion.

La calculette graphique de GNOME, gnome-calculator, plante (son affichage gèle) à son ouverture si elle ne parvient pas à récupérer des taux de change monétaires depuis la BCE et le FMI. LOL. La gestion des erreurs, sérieux… Pas cool non plus, les requêtes réseau à l'insu de l'utilisateur…

Il y a quelques semaines, j'avais contourné avec gsettings set org.gnome.calculator refresh-interval 0. Source. Cela ne fonctionne plus aujourd'hui.

Il faut se déconnecter du réseau, ouvrir la calculette, aller dans le menu, Préfèrences, et choisir la valeur « Jamais » pour le paramètre « Intervalle de rafraîchissement des taux de changes ».