GuiGui's Show

[…] le « paquet européen de protection des données à caractère personnel », composé du règlement n° 2016/679 du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données (RGPD) et de la directive n° 2016/680 du 27 avril 2016, dite directive « Police-Justice ».
[…]
Le RGPD a vocation à s’appliquer à l’ensemble des traitements de données à caractère personnel dans les Etats membres, à la fois dans le secteur public et le secteur privé, à l’exception toutefois des traitements mis en œuvre pour l’exercice d’activités qui ne relèvent pas du champ d’application du droit de l’Union européenne, telles que les activités de sûreté de l’Etat ou de défense nationale, et ceux mis en œuvre aux fins de la directive « Police-Justice ».

Ooook. Trois contextes (champs d'application) distincts :

• Directive européenne Police-Justice : pénal, application des peines judiciaires, prévention, maintien de l'ordre, PNR, etc. ;
  
  
• Loi Informatique et Libertés (1978) : sûreté de l'État et défense nationale (car ce ne sont pas des compétences de l'UE donc hors directive Police-Justice et RGPD) ;
  
  
• RGPD pour le reste.

Droits en plus et/ou en moins entre la directive Police-Justice et le RGPD (notamment un droit d'accès restreint voire indirect pour la directive).

Identifier le titre et l'auteur d'une musique : SongRec est un client Shazam (Rust, GPL) disponible sur GNU/Linux.

Depuis un fichier, un micro, ou les haut-parleurs (une option de SongRec évite même d'aller configurer la boucle sortie son standard vers entrée son standard dans PulseAudio / Alsa / autre).

flatpak install --user flathub com.github.marinm.songrec
flatpak run com.github.marinm.songrec

Avant, quand je cliquais sur un fichier dans une page web, Firefox m'affichait une popup. Si je choisissais d'ouvrir, le fichier était stocké dans /tmp. Et il y restait même après la fermeture du fichier (j'ai parfois récupéré des trucs après coup). Si je choisissais de télécharger, Firefox le rangeait dans ~/Téléchargements.

Depuis que Debian stable est passé à la version 102 de Firefox, celui-ci range tout dans ~/Téléchargements, qui devient un vrai zouk.

Pour retrouver l'ancien comportement : browser.download.start_downloads_in_tmp_dir à true dans about:config.

J'ai également constaté que Firefox commence le téléchargement (dans /tmp si « start_downloads_in_tmp_dir » est à true) avant que je choisisse d'ouvrir ou de télécharger. Johndescs me dit que ça fait déjà quelques versions. En tout cas, ça a rien à voir avec ce que je viens de décrire : même avec « start_downloads_in_tmp_dir » à false (valeur par défaut), Firefox télécharge en anticipation.

En février 2022, la CNIL a mis en demeure plusieurs sites web de ne plus utiliser Google Analytics : transfert illégal de données personnelles vers les États-Unis, car ils ne présentent pas de garanties suffisantes de respect de la vie privée.

La problématique fondamentale qui empêche ces mesures de répondre à la problématique de l’accès aux données par des autorités extra-européennes est celle du contact direct, par le biais d’une connexion HTTPS, entre le terminal de la personne et des serveurs gérés par Google. […] Les requêtes qui en résultent permettent à ces serveurs d’obtenir l’adresse IP de l’internaute ainsi que de nombreuses informations sur son terminal. Celles-ci peuvent, de manière réaliste, permettre une réidentification de celui-ci et, en conséquence, l’accès à sa navigation sur l’ensemble des sites ayant recours à Google Analytics.

J'en profite pour rappeler que le RGPD ne prévoit pas d'approche par les risques en matière de transfert de données persos vers un pays qui ne présente pas un niveau adéquat de protection de la vie privée. Donc, peu importe la probabilité qu'un européen fasse l'objet d'une demande des autorités ricaines.

Je découvre les recommandations du CEPD sur les mesures supplémentaires à mettre en œuvre lors d'un transfert de données personnelles hors de l'UE et en l'absence de décision d'adéquation.

En juin 2022, la CNIL a publié cette notice sur l'utilisation d'un reverse proxy comme mesure technique supplémentaire autorisant le transfert vers les États-Unis.

Cette méthode peut être utilisée avec d'autres destinations / produits / outils que Google Analytics.

Elle me semble être une mauvaise idée à tous les niveaux :

• Technique :
  • La complexité pour bien configurer le proxy (afin qu'il supprime toutes les données personnelles) dépasse le niveau moyen des informaticiens actuels. De même, il faut prévoir le suivi dans le temps des normes (HTTP/2 ajoute-t-il des entêtes systématiques qui contiennent des données personnelles ?) et de ce que l'on dissimule derrière le proxy (la dernière version du produit récupère-t-elle des données persos supplémentaires ? Changement d'URL de la ressource. Etc.). À plus ou moins long terme, ça va nécessairement se terminer en fuite de données persos vers la destination :( ;
    
    
  • Toutes les données personnelles ne peuvent pas être retirées. Exemple : la langue (entête HTTP « Accept-Language ») en fonction de ce qu'on dissimule, ou des entêtes plus techniques qui peuvent contenir l'URL du site web d'où l'on vient comme HTTP CORS.
• Organisation :
  • L'opacité induite empêche un audit extérieur. C'est, à mon avis, la pire chose. Sans proxy, n'importe qui peut utiliser uMatrix et/ou les outils de développement web de son navigateur web pour constater l'existence d'un transfert de données personnelles. Or, il n'est pas possible, ni au quidam ni au bien informé, de constater ce qui transite entre un reverse proxy et la destination finale (toutes les données personnelles ont-elles été retirées ?). Cela signifie qu'il faut s'en remettre à une conformité interne (très souvent inexistante) ou à un improbable (statistiquement) contrôle de la CNIL ou au signalement d'un (ex-)employé ;
    
    
  • Il faut mener une réflexion approfondie sur l'impossibilité de ré-identifier une personne avec les données transmises… et l'actualiser lorsque le produit dissimulé change (la nouvelle donnée récupérée est-elle personnelle ? Si oui, peut-on la pseudonymiser ou la retirer ? Etc.). Le temps ne serait-il pas mieux investi dans la mise en place une vraie alternative conforme au RGPD ? Sauf que, le coût de l'analyse et de la mise en place sera minoré par les chefs ("ho, un proxy, c'est facile, apt-get install et c'est réglé"), donc la solution de reverse proxy sera privilégiée, à tort.
• Politique et économie :
  • Réponse technique à un problème qui ne l'est pas. Fuite en avant pour conforter nos habitudes. Manque de volonté pour définir une politique économique volontariste permettant l'émergence d'acteurs européens avec le même niveau de service que les ricains à l'aide d'un protectionnisme réglementaire que permet le RGPD. Solution du statu quo. "Un proxy c'est bien, car on ne sait pas et on ne saura pas faire aussi bien en UE". Défaitisme.

Dans le cas d'un outil de mesure d'audience (Google ou autre), l'utilisation d'un reverse proxy retire une grande partie de l'intérêt de l'outil. :D

La CNIL a une mission de conseil (article 8 de la loi I&L), mais pas de n'importe quoi. Là, on se tire une balle dans le pied, surtout avec l'absence de contrôle depuis l'extérieur. :(

Sans surprise, ce qui devait arriver arriva : https://www.linforme.com/tech-telecom/article/transfert-de-donnees-vers-les-etats-unis-le-figaro-epargne-par-la-cnil_1801.html

Certes, la Société du Figaro a bien mis en œuvre dans l’intervalle de ces trois années des mesures techniques (en l’occurrence, une « proxyfication », consistant en l’utilisation d’un serveur intermédiaire pour limiter les risques d’identification des internautes), mais les choix opérés n’ont pas été jugés suffisamment solides par la CNIL. Dans un courrier daté du 4 juin, adressé à la plaignante et qu’a pu lire l’Informé, Marie-Laure Denis, présidente de l’autorité relève qu’ils « n’ont pas permis d’éviter le transfert de données à caractère personnel des utilisateurs du site web LeFigaro.fr vers les États-Unis ».

Si je résume :

• Google Analytics. Transfert illégal de données personnelles vers les États-Unis. Mise en demeure de la CNIL du 10/02/2022 portant sur l'utilisation de Google Analytics. Raisonnement simplifié : téléchargement d'un script = contact direct entre un terminal et les serveurs de Google = transfert de données personnelles (adresse IP, site web consulté ‒ entête HTTP « Referer » ‒, date et heure de la consultation, modèle du terminal et du navigateur web ‒ entête HTTP User-Agent ‒ ainsi que quelques caractéristiques techniques ‒ comme la langue du système, entête HTTP Accept-Language ‒, etc.). Données pouvant être croisées par des acteurs hégémoniques. Rapatriement des données collectées par ledit script (dans le cadre de la mesure d'audience) auprès d'une entité ricaine. Peu importe si les données sont stockées dans l'UE, le CLOUD Act ricain s'applique ;
  
  
• AT Internet Xiti. Probablement soumis au CLOUD Act. Indices (selon la grille d'analyse contenue dans le mémorandum remis par un cabinet d'avocats ricain au ministère de la justice des Pays-Bas) : société commerciale rachetée en 2021 par l'américaine Piano Software Inc. (je l'ai appris dans un commentaire sur le blog de David Libeau) ; Comme l'indique le communiqué de presse, Piano est l'actionnaire unique d'AT Internet ; Pour compenser, Piano a annoncé la délocalisation de son siège social en Europe, mais ça change rien si le bidule UE est toujours une filiale du bidule ricain (ce que le communiqué ne dit pas) ; De même, Piano est toujours immatriculée dans le Delaware (chercher ici) ; Elle dispose toujours de plusieurs bureaux aux États-Unis (New York, Philadelphie, cf. son site officiel) ; Elle doit encore compter de très nombreux clients états-uniens puisqu'il s'agit de sa clientèle historique ;
  
  
• Matomo Cloud. Transfert illégal de données personnelles vers les États-Unis. Sur son site web, la société commerciale indique être basée en Nouvelle-Zélande, qui fait l'objet d'une décision d'adéquation de l'UE (ce qui autorise les transferts de données personnelles, article 45 du RGPD), ce que l'on vérifie auprès de la CNIL. Jusque-là, c'est conforme (même si une décision d'adéquation avec un pays membre des Five Eyes me fait tiquer). Matomo déclare aussi avoir recours au CDN (Cloudfront) d'Amazon Nouvelle-Zélande, ce qui l'exclurait de toute ingérence états-unienne. Or, il s'agit possiblement d'une filiale de l'entité ricaine dédiée au marketing, au lobbying, etc. De plus, il existe un seul réseau informatique mondial Amazon (AS16509 pour les connaisseurs), qui est piloté, maintenu, et contrôlé par Amazon États-Unis, qui a donc la main sur les serveurs, les données et les journaux (logs), et doit donc répondre aux autorités ricaines ;
  
  
• Cloudflare Web Analytics (chargement d'un JavaScript depuis « static.cloudflareinsights.com »). Transfert illégal de données personnelles vers les États-Unis. Même raisonnement que pour Google. Notons que la présentation de son outil par Cloudflare est trompeuse : « Nous ne prenons pas les « empreintes numériques » des internautes par le biais de leur adresse IP, de la chaîne agent-utilisateur ou de toute autre donnée dans le but d'afficher une analyse. ». Même si Cloudflare ne traite conserve pas ces données personnelles, elle les a reçues…

Ouiiii, on peut installer, entre le visiteur d'un site web et Google / Amazon, un reverse proxy qui retire (strip) les entêtes HTTP contenant des données personnelles, afin de continuer à utiliser ces outils. Mais, si l'on externalise, ce n'est pas pour se farder un reverse proxy, normalement. Surtout que sa conformité au RGPD nous tombe dessus (est-il bien configuré) ? D'autant que ça retire une bonne partie de l'intérêt d'une mesure d'audience.

Oui, on peut continuer à utiliser un Matomo installé sur des serveurs détenus par une entité UE (soi-même ou un prestataire).

Plus d'un an après, et suite à une question du député Latombe, le ministère de l'éduc' nat' nous apprend qu'il a demandé (quand ?) de stopper les déploiements d'Office 365 ainsi que ceux de la solution de Google (Workplace ?). RGPD, transferts illégaux de données personnelles vers les États-Unis (Schrems II), décision de la CNIL et circulaires de 2021, tout ça. Bref, rien de neuf, mais ça fait mine d'avancer.

Dès 2019, l'Allemagne et les Pays-Bas ont partiellement banni Office 365. Allemagne : un seul Land puis suspension de l'interdiction le temps des négociations avec MS ; Pays-Bas : uniquement Office Online et les applis mobiles Office. En 2022, les danois ont suspendu durant un mois l'utilisation des Chromebooks et de Google Workplace.

J'ai hâte (ou pas) de voir la réaction de Microsoft. Va-t-on partir sur de la revente de licence à des clouds souverains ? Sur du On-Premises (ça n'a pas l'air d'être populaire pour l'instant) ?

J'ai hâte (ou pas) de voir l'absence d'action de la part des bahuts exsangues que la gratuité d'Office 365 arrange bien. Le député évoque d'ailleurs la concurrence déloyale (et l'accoutumance) que cela constitue. Le ministère rappelle une de ses anciennes réponses : limiter le périmètre couvert par des licences gratuites, limiter la durée du "contrat", ne pas accorder d'exclusivité, blablabla.

Une analyse d'impact sur la protection des données personnelles portant sur Microsoft Teams, OneDrive, SharePoint et Azure Active Directory réalisée en février 2022 par le ministère de la justice et de la sécurité des Pays-Bas.

Mes notes :

• La section 702 de la loi FISA prend fin en 2023. Pour continuer, il faudra le renouvellement du Congrès.
  
  
• Pages 66 et suivantes : un tableau recensant toutes les lois ricaines qui permettent d'obtenir des données personnelles d'un client européen ;
  
  
• Le chiffrement de bout en bout des appels Teams est à venir ;
  
  
• À ce jour, même quand les données (et le reste) sont stockées dans l'UE, la télémétrie et les journaux d'audit sont transférés aux États-Unis. Idem pour les noms d'utilisateurs, de fichiers et de chemins dans OneDrive et SharePoint. Ça ne devrait plus être le cas fin 2022. Les rapports de sécurité seront toujours transférés aux États-Unis, même avec la « EU Boundary » (cf. ci-dessous) afin de proposer un niveau de sécurité harmonisé au niveau mondial ;
  
  
• Les clauses contractuelles-types (les dernières datent de 2021) sont valides mais le CEPD exige des garanties supplémentaires, que souvent les sociétés ricaines ne peuvent fournir, (excepté le chiffrement de bout en bout), ce qui les rend caduques. Rien de neuf (la CNIL le rappelait déjà dans sa mise en demeure de février 2022 portant sur l'utilisation de Google Analytics) ;
  
  
• La surveillance ricaine est classée comme risque faible + préjudice grave (si ça arrive). Très faible nombre de demandes des autorités ricaines, combativité de Microsoft contre les demandes infondées des autorités états-uniennes, promesses de MS de contester toutes les demandes infondées et de compenser pécuniairement toute divulgation en infraction avec le RGPD (ha… donc t'es pas sûr de tout contester ?). Pour moi, les promesses engagent que ceux qui y croient (Microsoft avait fini par renoncer à contester), et, en avril 2022, l'APD autrichienne a rappelé que le RGPD ne prévoit pas d'approche basée sur les risques en matière de transfert vers des pays tiers non adéquat (ce qui est le le cas des États-Unis à ce jour) ;
  
  
• Microsoft est maline et insiste lourdement sur l'intérêt économique suprême qu'elle a à veiller à une stricte et exigeante protection des données persos des ricains. C'est beau. Comme si le business ne pouvait pas se maintenir par d'autres moyens genre entrave à la concurrence, différenciation technique, hégémonie culturelle, etc. ;
  
  
• Sans accord de coopération CLOUD Act, les demandes des autorités ricaines auraient peu de chance d'aboutir selon le CEPD (EDPB et EDPS). Ça contraste avec le mémorandum rédigé en août 2022 pour le même ministère des Pays-Bas par un cabinet d'avocats ricain. Cependant, les accords de coopération concernent une partie seulement du CLOUD Act (cf. mémo). Pour le reste, les sociétés commerciales pourraient contester les demandes des autorités ricaines en manipulant trouzemilles concepts juridiques… Mais bien sûûûûr qu'elles le feront ;
  
  
• L'EDPB et l'EDPS bossent depuis mi-2021 sur le cas d'Office 365 ;
  
  
• Microsoft EU Boundary : Microsoft proposera, à la fin de 2022, à ses clients Entreprise et Education, un traitement des données exclusivement dans l'UE. Un cloud séparé est évoqué (MS le fait déjà pour la Chine et pour le gouvernement ricain). Comment ? Dans une société qui n'est pas une filiale de MS USA (sinon CLOUD Act) ? Avec des employés (européens) dédiés ? Aucune précision. Le mémorandum sus-cité évoquait déjà cette « UE Boundary ». Beaucoup d'exceptions et de conditionnel, en tout cas. Actualisation ici.

Bref, je note que ça met du temps à converger / gamberger (points 6 et 8), et que ça souhaite quand même bien sauver la mise aux GAFAM (points 7 et 10).

La Banque Populaire refuse d'effacer des informations personnelles de mon dossier : situation familiale (célibataire, marié, pacsé, etc.), statut d’occupation d’un logement (locataire, propriétaire, etc.) et depuis quand, catégorie socio-professionnelle générale et détaillée, et statut INSEE. Elles seraient collectées et conservées dans le cadre de la réglementation sur la lutte contre le blanchiment des capitaux et le financement du terrorisme (LCB-FT).

Pour moi, en me basant sur les lignes directrices de l'ACPR, ce n'est pas le cas, au moins pour les trois premières (le statut INSEE et la CSP sont dérivés de la profession dont la collecte est obligatoire), mais les banques doivent procéder à une évaluation du risque LCB-FT que représente un client (futur ou actuel), et pour ce faire, elles peuvent collecter environ nawak.

Même s'il y a absence de pertinence, d'adéquation à la finalité affichée, et de nécessité des informations ? Celles énumérées ci-dessus sont insignifiantes, dépourvues de sens, et inutiles pour évaluer un risque LCB-FT (un célibataire blanchit-il plus de fric ? Un propriétaire finance-t-il plus le terrorisme ? Et réciproquement ?). La proportionnalité entre l'objectif et l'atteinte à la vie privée est également questionnable : le peu d'infos qui ne peut pas forcément être déduit des opérations sur un compte bancaire, pouf, la banque veut les collecter…

Du coup, hop, plainte à la CNIL.

ÉDIT DU 02/12/2022 : ajout de la réponse de la CNIL datée du 28/11/2022. Résumé : incompétence de la CNIL, renvoi vers l'ACPR. Ma plainte n'a pas été clôturée pour autant. FIN DE L'ÉDIT.
ÉDIT DU 29/12/2022 : ajout de la réponse de la CNIL datée du 05/12/2022 suite à mon complément interrogatif du 02/12/2022. Résumé : pas d'info utile, plainte clôturée. FIN DE L'ÉDIT.

Introduction

Bonjour,

Le 21/01/2020, par LRAR, j'ai demandé à la conseillère qui m'est affectée à la Banque Populaire <CENSURE> d'effacer certaines données personnelles de mon dossier client.
Refus, un verrou informatique mettrait mon dossier en défaut même si « au vu du peu de services souscrits, elles sont effectivement inutiles ».

Le 22/02/2020, par LRAR, j'ai demandé l'effacement de ces même données au DPO.
Refus, données collectées et conservées dans le cadre des obligations légales de la BP <CENSURE>.

Réponse insatisfaisante du DPO : elle est basée sur des obligations légales inexistantes et elle ne m'informe pas de la raison réelle et précise pour laquelle chaque donnée litigieuse est conservée et l'utilisation qu'en fait BP <CENSURE> (en quoi elle est pertinente pour atteindre la finalité annoncée).

Je sollicite l'intervention de la CNIL pour appuyer ma demande d'effacement de certaines de mes données personnelles auprès de la BP <CENSURE>.

Vous trouverez, en pièce jointe, la version détaillée de ma plainte.

Bonne journée.

Plainte détaillée

Elle contient au moins une erreur : l'échange téléphonique avec la conseillère bancaire qui m'est affectée n'a pas eu lieu le 17/12/2020 mais le 17/12/2019.

Bonjour,

Je suis client de la Banque Populaire <CENSURE> (« BP <CENSURE> » ou « BP » ci-après).

Le 21/01/2020, j’ai sollicité, par LRAR, la conseillère bancaire de mon agence qui m’est affectée pour lui demander d’effacer, de mon dossier client, ma situation familiale, mon statut d’occupation de mon logement (locataire / propriétaire, et depuis quand), ma catégorie socio-professionnelle (CSP) générale, ma CSP détaillée et mon statut INSEE. Cf. PJ1.

En l’absence de réponse et d’exécution de ma demande (ces données se visualisent dans l’espace client web de la BP), j’ai contacté ladite conseillère, par téléphone, le 18/02/2020. Elle m’a indiqué ne pas pouvoir procéder à la suppression des données personnelles sus-énumérées au motif qu’un verrou informatique mettrait en défaut mon dossier, car il s’agirait d’informations obligatoires, même si, dans mon cas, au vu du peu de services souscrits, elles sont effectivement inutiles.

Le 22/02/2020, j’ai demandé, par LRAR, l’effacement des données personnelles sus-référencées au DPO de la BP <CENSURE>. Cf PJ 2.

Le 02/03/2020, le DPO de la BP <CENSURE> m’a répondu que ces données personnelles ne peuvent pas être effacées, car elles sont collectées dans le cadre de la réglementation permettant de lutter contre le blanchiment d’argent et le financement du terrorisme, sans toutefois citer un quelconque de ces textes. Cf. PJ 3.

Le 10/03/2020, j’ai répondu au DPO de la BP <CENSURE>, par LRAR, qu’a minima, le recueil de la situation familiale et du statut d’occupation d’un logement (et depuis quand) n’est pas une obligation légale. L’Autorité de Contrôle Prudentiel et de Résolution (ACPR) confirme cela dans ses lignes directrices rédigées à la demande des organismes financiers, cf. https://acpr.banque-france.fr/contenu-de-tableau/lignes-directrices-relatives-lidentification-la-verification-de-lidentite-et-la-connaissance-de-la. Cf pages 1 et 2 de PJ 4.

En l’absence de réponse malgré la bonne réception de ma LRAR, j’ai relancé le DPO de la BP <CENSURE> le 07/12/2020. Cf page 3 de PJ 4.

Je n’ai pas reçu de nouvelle réponse du DPO de la BP <CENSURE>. À ce jour, les données personnelles sus-énumérées sont toujours affichées dans mon espace client web, ce qui démontre qu’elles n’ont pas été effacées de mon dossier client

Il découle de ce qui précède (absence d’obligation légale) que la réponse du DPO de la BP <CENSURE> est un prétexte mensonger, un paravent. Ce n’est pas la première fois que je peine à prendre connaissance de la finalité et de la base légale réelles pour lesquelles la BP <CENSURE> collecte et conserve certaines de mes données personnelles. Il s’agit d’une infraction au RGPD à part entière qui n’aide pas à avoir confiance.

    Le 17/12/2020, par téléphone, ma conseillère m’a informé qu’il est strictement obligatoire de lui communiquer mon niveau de revenus. Devant mon insistance, elle m’a avoué que la convention de compte incluait une autorisation de découvert, et que celle-ci impose la déclaration d’un niveau de revenus. Cela fait sens (évaluation de la solvabilité, etc.), mais je ne voulais pas de ladite convention de compte (et je l’ai signifié à la conseillère qui tentait de me la vendre), donc il était inutile de collecter mon niveau de revenus au motif d’un produit qu’elle incluait.

    Durant la même conversation, elle m’a informé qu’il est obligatoire de lui communiquer le nom et l’adresse postale de mon employeur… avant de reconnaître, devant mon insistance, que c’est nécessaire uniquement pour obtenir une ristourne sur la cotisation liée à la convention de comptes… à laquelle je n’envisageais pas de souscrire, pour rappel.

    Ainsi, si j’avais écouté ma conseillère sans la questionner avec insistance, je lui aurais communiqué des données personnelles dont le recueil est présenté, à tort, comme étant obligatoire, ce qui n’est pas le cas, ni légalement ni contractuellement (profil de la relation et niveau de risque).

    La réponse du 02/03/2020 du DPO de la BP <CENSURE> est incomplète et ne satisfait pas aux exigences de transparence du RGPD : il ne m’indique pas, pour chaque donnée personnelle dont je demande la suppression, la raison précise (quelle disposition réglementaire) de sa collecte et de sa conservation, l’utilisation qui en est faite par BP, et les conséquences d’une demande de suppression de ma part. Or, nous avons vu ci-dessus que le refus de communiquer le nom de mon employeur, dont la collecte m’a été présenté, par ma conseillère, comme une obligation, entraîne uniquement l’absence d’application d’une ristourne, pas la fin de la relation contractuelle, ce qu’il m’appartient d’accepter ou de refuser librement. Il pourrait en être de même pour les données litigieuses, mais l’opacité est entravante.

Sur le fond, la BP <CENSURE> ne peut se prévaloir d’une quelconque obligation légale pour conserver ma situation familiale, mon statut d’occupation d’un logement (et depuis quand), et, dans une moindre mesure, ma CSP et mon statut INSEE.

    En effet, le Code monétaire et financier n’impose pas leur recueil par un organisme financier. De même, l’arrêté du 2 septembre 2009 pris en application du R561-12 du même code ne les énumère pas comme étant des éléments d’information susceptibles d’être recueillis par un organisme financier. Si le même arrêté prévoit le recueil des « activités professionnelles actuellement exercées », il ne prévoit pas d’en dériver le statut INSEE ni la CSP, ni la date de début de l’activité. L’arrêté du 6 janvier 2021 relatif au dispositif et au contrôle interne en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme apporte aucun changement sur ces points.

    La dernière version des lignes directrices de l’ACPR (https://acpr.banque-france.fr/sites/default/files/media/2022/05/11/20220404_lignes_directrices_revisees_relatives_identification_verification_connaissance.pdf) confirme cette absence d’obligation légale et réserve une collecte fine et précise de l’activité professionnelle aux personnes publiquement exposées. Je n’ignore pas que des lignes directrices sont un instrument de droit souple qui ne permet pas de définir une interdiction générale, mais l’énumération et l’analyse de la réglementation par l’ACPR est factuelle. De plus, ces lignes cadrent, définissent les objectifs à atteindre, les moyens minimaux à mettre en œuvre, les critères d’évaluation, l’état d’esprit, la logique, et la réflexion à mener, etc.

    De plus, la pertinence (et donc la nécessité) des données personnelles sus-énumérées comme éléments d’information utiles pour lutter contre le blanchiment et le financement du terrorisme dans le contexte d’évaluation du profil / niveau de risque de la relation contractuelle n’est pas avérée. Un célibataire blanchit-il plus d’argent ? Une propriétaire finance-t-elle plus le terrorisme ? L’intuition met en évidence l’absence de causalité et l’insuffisance de ces données personnelles pour évaluer le risque cible. Encore une fois, dans ses lignes directrices pour évaluer le profil de risque de la relation contractuelle, l’ACPR ne reprend pas ces éléments. Ils ne sont même pas des éléments minimaux de cette évaluation, ils sont exclus de la vision à avoir de la problématique. D’après l’ACPR, une évaluation pertinente du risque se base plutôt sur la « compréhension de l’activité financière du client », sur la provenance, le montant et la destination des fonds, sur la nature de la clientèle (personne publiquement exposée ?) et des services (un compte courant est un produit financier à « risque standard »), etc.

La BP <CENSURE> ne peut se prévaloir de mon consentement puisque je lui demande l’effacement de ces données personnelles depuis plusieurs années.

Ma situation ne correspond pas à celles, référencées dans sa notice RGPD (https://www.banquepopulaire.fr/votre-banque/reglementation/protection-des-donnees-personnelles/), pour lesquelles la BP <CENSURE> fait valoir son intérêt légitime :

• Ces données personnelles ne servent pas à prévenir la fraude ni à lutter contre la criminalité financière. En effet, le test en trois étapes (intérêt, nécessité, balance des droits) n’est pas validé :

  • La situation familiale, le statut d’occupation d’un logement, la CSP (générale et détaillée) et le statut INSEE ne sont pas des informations pertinentes pour atteindre l’objectif affiché lorsque le client est une personne physique qui n’est pas une personne publique exposée et dont le seul service souscrit est un compte courant, c’est-à-dire un produit à « risque standard », car lesdites données ne permettent pas de « comprendre les opérations » entrantes sur ledit compte (origine), au sens de l’ACPR, ni d’apprécier la « nature de la clientèle » ;
    
    
  • L’ACPR ne référence pas les données personnelles sus-énumérées comme étant des informations pertinentes dans le cadre de la lutte contre le blanchiment des capitaux et le financement du terrorisme, donc leur pertinence dans la lutte contre la fraude et la criminalité financière… Fraude-t-on plus quand on est en couple ou quand on est locataire ? ;
    
    
  • La collecte est intrusive et déloyale : la banque biaise la justification qu’elle donne à son client (cf. mon témoignage ci-dessus) et utilise le fait d’être un service nécessaire au quotidien pour lui demander tout et son contraire, car la peur des conséquences d’un refus de communication rode. Les banques sont des ogres qui concentrent notre intimité alors la conservation du peu d’informations qu’elles ignorent n’est pas réjouissante et caractérise, entre autres éléments, un déséquilibre entre l’intérêt de la banque et les droits de ses clients.
• Ces données ne servent pas non plus à prévenir et gérer les incivilités à l’égard du personnel BP ni à assurer la sécurité des locaux et du SI de BP (aucun lien entre les données en question et ces finalités) ni à évaluer le niveau de risque lié à une demande de crédit (j’ai jamais formulé une telle demande durant toute ma relation contractuelle avec BP) ;
  
  
• Enfin, elles ne servent pas à mener des enquêtes de satisfaction (la présente plainte porte sur des informations consignées dans mon dossier client en dehors de toute enquête de satisfaction), ni à améliorer la relation client (en quoi ? Là encore, le test en trois étapes n’est pas validé pour le jeu de données en question, pour les mêmes raisons d’absence de pertinence et de proportionnalité), ni à prospecter ou à communiquer (la page 10 de la notice RGPD de la BP énonce que seuls les noms, prénoms, adresse, date et lieu de naissance sont concernées par ce cas et j’ai refusé, dès le début de la relation contractuelle, tout démarchage et n’en ai jamais reçu, donc si mes données personnelles sont conservées à cette fin, leur conservation est inutile).

En l’absence d’obligation légale, d’intérêt légitime, de consentement, ou d’une autre base légale recevable, BP ne saurait valablement justifier la conservation de mes données personnelles sus-énumérées et son refus de procéder à leur effacement. Il s’agit d’une collecte inutile de données personnelles, contraire au principe de minimisation du RGPD.

J’ajoute que la collecte (ou l’actualisation) des données personnelles sus-énumérées s’est déroulée suite à une perte de ma carte bancaire en 2018-2019. Ma conseillère BP m’a forcé à actualiser mon dossier avant de donner suite à certaines de mes demandes. J’ai laissé traîner de nombreux mois avant d’accepter, car j’avais besoin d’une banque et de moyens de paiement en état de marche (tout en refusant ce que j’ai pu, comme la communication du nom et de l’adresse de mon employeur ou mon niveau de revenus, cf. ci-dessus). Il apparaît néanmoins que, de ces faits, la collecte (ou l’actualisation) de mes données personnelles a été illicite et déloyale (client pris au piège).

De même, en l’absence de réponse de ma part, certaines informations présentes aujourd’hui dans mon dossier client BP ont été inventées : je ne suis pas devenu <CENSURE> le <CENSURE> ; Je n’ai pas été embauché le <CENSURE>. D’autres informations ont été déduites, à tort, des opérations sur mon compte courant : si la Direction Régionale des FInances Publiques <CENSURE> vire ma rémunération, il ne s’agit pas pour autant de mon employeur (elle centralise le paiement pour les administrations de la région).

C’est aussi pour ces deux motifs (collecte forcée et données incorrectes) que je demande la suppression desdites données personnelles.

En conclusion, devant l’obstination de la BP <CENSURE>, je sollicite l’intervention de la CNIL pour appuyer ma demande d’effacement de certaines de mes données personnelles de mon dossier client BP <CENSURE> : situation familiale, statut d’occupation d’un logement (locataire / propriétaire / etc.) et depuis quand, catégorie socio-professionnelle générale et détaille, et statut INSEE).

Dans le cas où l’effacement d’une donnée entraînerait la fin de ma relation contractuelle avec la BP <CENSURE>, ma demande d’effacement de ladite donnée est caduque et je demande, à la place, comme je l’ai écrit au DPO de la BP <CENSURE> en mars 2020, l’obtention de la raison précise (quelle disposition réglementaire) de sa collecte et de sa conservation, et l’utilisation qui en est faite par la BP.

Bonne journée.

Réponse de la CNIL du 28/11/2022

[…]

Je vous informe que la CNIL n’a pas vocation à se prononcer, au cas par cas, sur le profil de la relation contractuelle établie entre un client et sa banque qui définit le degré d’exposition au risque de blanchiment ou de financement du terrorisme et, par conséquent, la nature des informations susceptibles d’être collectées auprès de ce client afin de se prémunir de ce risque.

A cet égard, il appartient aux établissements financiers d’ajuster leur obligation de vigilance en fonction de l'évaluation du risque de blanchiment de capitaux et de financement du terrorisme propre à chaque relation d'affaire, ou à chaque client.

Enfin, et pour votre parfaite information, je vous indique que l’Autorité de Contrôle Prudentiel et de Résolution (ACPR) a, parmi ses responsabilités, reçu la mission de contrôler la mise en œuvre effective des mesures de lutte contre le blanchiment des capitaux et le financement du terrorisme (articles L561-36 et suivants du Code monétaire et financier). Ainsi, les entités appartenant au secteur financier sont soumises au pouvoir de contrôle de cette autorité, mais également à son pouvoir de sanction dans le cas où elles enfreindraient une disposition législative ou réglementaire.

Par conséquent, si vous l’estimez utile, vous pouvez vous rapprocher de l’ACPR afin de recueillir toute information complémentaire, notamment sur cette règlementation.

[…]

Même début de réponse qu'en 2020. Pourtant, cette fois-ci, j'ai bien expliqué en quoi la collecte de ces données persos n'est ni adéquate à la finalité recherchée, ni nécessaire, ni proportionnée. Mais, a priori, la CNIL n'a pas compétence pour apprécier cela dans le cadre de la lutte contre le blanchiment et le financement du terrorisme.

Je copie ici ce que m'inspirait la réponse datée de 2020 de la CNIL : « C'est là où ça me dépasse… L'ACPR défini un socle minimal que les banques peuvent dépasser par extrême prudence. La CNIL dit que la réglementation LCB-FT permet à une banque de demander ce qu'elle veut. Le jour où un banquier expliquera qu'il croit voir une corrélation entre la taille du zboub et le blanchiment de fric, il pourra collecter ladite taille chez ses clients afin d'évaluer le risque dans le cadre de la LCB-FT ?! Sérieux… »

En 2020, la CNIL me renvoyait vers le médiateur de la consommation auprès de ma banque. Cette fois-ci, elle me renvoie vers l'ACPR. L'extrême prudence n'étant pas une infraction à une disposition législative ou réglementaire du Code monétaire et financier, je ne vois pas comment l'ACPR pourrait agir (ceci dit, la réponse de la CNIL m'invite à me rapprocher de l'ACPR uniquement pour me faire expliquer la réglementation) … Qui, alors ?

Mon complément interrogatif du 02/12/2022

Puisque ma plainte n'avait pas été clôturée suite à la réponse du 28/11/2022, j'ai posé les questions que je soulève au point précédent : la réglementation LCB-FT ne fixant pas de limite supérieure à ce qui peut être collecté par une banque, comment éviter les abus ? Qui peut contrôler ? Quid du principe de minimisation du RGPD (collecter uniquement ce qui est nécessaire) ? Pourquoi n'est-il pas de la compétence de la CNIL de vérifier l'adéquation, la nécessité, et la proportionnalité d'une collecte de données persos (la base juridique de l'obligation légale n'y fait pas obstacle) ?

Bonjour,

Je vous remercie pour votre réponse.

Un point échappe à ma compréhension : malgré tout, les données personnelles collectées par une banque ne doivent-elles pas être en adéquation avec la finalité recherchée, ainsi que nécessaires et proportionnées à ladite finalité ? Sans cela, une banque peut recueillir tout et n'importe quoi au prétexte qu'elle y voit une corrélation avec la LCB-FT : port de lunettes, nombre de voitures, taille, poids, etc. Un RT ne doit-il pas collecter uniquement ce qui est nécessaire à une finalité (minimisation) ?

Qui contrôle cela ? L'ACPR rédige des lignes directrices, qui ont valeur de socle minimal conseillé. Rien interdit à une banque d'être sur-prudente, donc je doute que l'ACPR puisse agir.

Pourquoi la CNIL ne peut-elle pas évaluer la pertinence (adéquation / nécessité / proportionnalité) d'une collecte de données persos dans le cadre de la LCB-FT ? Interdiction légale ?

Bonne fin de semaine.

Réponse de la CNIL du 05/12/2022

Ma plainte a été clôturée dans la foulée.

[…]

Le cadre juridique de ces obligations est fixé par la Directive européenne n°2005/60/CE du 26 octobre 2005, qui a été transposée en droit français le 31 janvier 2009. La plupart de celles-ci figurent dans le Code monétaire et financier au Livre V, Titre VI « Obligations relatives à la lutte contre le blanchiment des capitaux, le financement des activités terroristes et les loteries, jeux et paris prohibés », articles L561-1 et suivants.

Enfin l'objectif poursuivi par le traitement de ces données est la mise en place d'une surveillance adaptée aux risques de blanchiment de capitaux et de financement du terrorisme pendant toute la durée de la relation d’affaires. Dans ce cadre, la banque conserve les documents d’identification de son client aussi longtemps que dure la relation commerciale et pendant 5 ans à compter de la cessation de cette relation. Ceux relatifs aux opérations sont conservés 5 ans à compter de leur exécution.

[…]

Je ne suis pas plus avancé. :(

Je ne comprenais pas pourquoi des responsables de traitement de données personnelles (RT) proposent de s'opposer à un traitement de données personnelles basé sur leur intérêt légitime (exemple). Pour moi, je pouvais m’opposer qu’à ce que je consentais (puisque le reste est soit obligatoire, soit relève de l'intérêt légitime qui existe précisément pour avoir rien à demander à la personne qui fait l'objet d'un traitement). Or…

vous avez consenti – vous devez alors retirer ce consentement et non vous opposer ;

Donc :

• Si consentement : retirer le consentement (et pas s'opposer, joie de la nuance) ;
  
  
• Si obligation légale ou nécessité au contrat ou préservation des intérêts vitaux : aucune opposition possible ;
  
  
• Si intérêt légitime ou mission d'intérêt public :
  • Si prospection commerciale : l'opposition est de droit ;
    
    
  • Pour tout le reste, il faut justifier d'une « situation particulière » (exemple : une décision basée sur ton profilage te désavantage) et personnelle (il n'est pas possible d'invoquer des motifs d'ordre général comme des préoccupations portant sur la sécurité d'une base de données, source : arrêt du Conseil d'État de 2019). L'opposition est à la discrétion du RT. Si le traitement est mis en œuvre afin qu'il puisse faire valoir ses droits en justice ou sécuriser son système informatique, aucune opposition possible. Pour les autres cas (genre lutte contre la fraude ou analyse de tendance), le RT prétextera un motif impérieux, tu pourras rien prouver, et lala. Donc, en pratique, en dehors du démarchage, le droit d'opposition est marginal / exceptionnel, pas généralisé (il permet de gérer des cas très précis).

Depuis fin 2020, OpenStreetMap (OSM) utilise le CDN de la société commerciale ricaine Fastly pour diffuser une carte géographique alternative à Google Maps (et consorts). Ce n'est pas conforme au RGPD. Fin 2021, j'ai exposé mon insatisfaction et mon opposition dans un coup de gueule sur les alternatives libristes et dans une réponse. En gros, je me méfie du mécénat d'entreprise et du poids démesuré des sociétés Fastly, Cloudflare, Akamai, Amazon Cloudfront, etc. dans nos vies numériques.

Seule la carte géographique du site web officiel est concernée. Les cookies déposés par le site web officiel (connexion, stockage du dernier emplacement géographique consulté, etc.) ne sont pas transmis à Fastly. Les recherches (en mode simple ou en mode calcul d'itinéraire) non plus. L'intégration de Fastly est soignée. D'autres sites proposant la même carte ne sont pas forcément concernés.

Néanmoins, la carte géographique est découpée selon un quadrillage (pour faire simple). Chaque case, qui se nomme une tuile (« tile » en anglais), est une image. Elle est téléchargée indépendamment des autres via une requête web dédiée. L'URL de chaque tuile qui compose la carte transite par Fastly. Dans le journal de ses serveurs web, elle consigne donc une association entre une date et heure de consultation, une adresse IP, le modèle et quelques caractéristiques techniques d’un terminal, et les URLs de tuiles qui, en fonction du niveau de zoom, peuvent être extrêmement précises (porter sur un petit territoire) et qui ont de l’intérêt pour l’utilisateur d’OSM (il consulte les infos sur ce lieu et/ou sur ses alentours).

J'ai beaucoup hésité avant de déposer une plainte CNIL. Je pense qu'il faut secouer ses amis (je contribue à OSM, j’ai financé un serveur de mise en cache des tuiles, etc.), leur dire quand ce qu'ils font n'est pas ouf. De même, le recours à Fastly par OSM constitue un abus de confiance, car OSM est très souvent présenté comme une cartographie libre, communautaire / collaborative, alternative à Google Maps, alors, qu’au final, elle repose en partie sur un acteur états-unien déjà présent dans les coulisses de (trop) nombreux sites web, et que cet acteur reçoit des données personnelles sur les utilisateurs de la carte OSM… tout comme Google Maps.

Que peut faire OSM ? Recourir à un CDN européen ou à un mix de CDNs de différentes nationalités. Communiquer sur l'existence de cartes dépourvues de Faslty (même si le niveau de service n'est pas identique). Informer (au sens de l'article 49.1a du RGPD, c'est-à-dire exposer le risque encouru).

J'ai également signalé que l'éditeur en ligne d'OSM n'est pas fonctionnel s'il ne télécharge pas des scripts JavaScripts auprès du projet jsDelivr (qui repose sur Fastly et Cloudflare). Ne pas internaliser quelques scripts quand on gère un projet informatique de cette ampleur et que l'on héberge un éditeur de carte géographique, ce n'est pas crédible. J'ai constaté le proxy pour télécharger des trucs depuis l'IGN. J'ai laissé pisser le téléchargement d'un script depuis Microsoft (virtualearth.net) parce qu'à un moment…

Place à ma plainte.

Introduction

Bonjour,

Depuis fin 2020, pour afficher sa carte géographique sur son site web (https://www.openstreetmap.org/) la fondation OpenStreetMap a recours au CDN de la société commerciale états-unienne Fastly. Les contacts directs entre le terminal du visiteur / utilisateur de ladite carte et les serveurs informatiques de Fastly génèrent des transferts de données personnelles vers les États-Unis en infraction avec les articles 44 et suivants du RGPD.

Je vais signaler ses manquements à la fondation OpenStreetMap en parallèle. Je vous rappelle l’arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a confirmé que l'exercice des droits n'est pas un pré-requis à une plainte pour sanction auprès d'une APD en cas de violation du RGPD.

Vous trouverez, en pièce jointe, la version détaillée de ma plainte.

Bonne journée.

Plainte détaillée

Bonjour,

Pour diffuser sa carte géographique sur son site web (https://www.openstreetmap.org/), la fondation OpenStreetMap (« OSM » ci-après) a recours au CDN de la société commerciale états-unienne Fastly :

    $ dig +short tile.openstreetmap.org
    dualstack.n.sni.global.fastly.net.
    146.75.117.91

Un réseau de distribution de contenus (CDN) est un hébergeur informatique qui dispose de serveurs informatiques répartis dans une zone géographique donnée (pays, continent, monde) et qui s’intercale entre l’hébergeur informatique final d’un service en ligne et les utilisateurs dudit service. Il existe plusieurs modes de fonctionnement d’un CDN :

• Dans le premier, le CDN est uniquement un intermédiaire de transport, c’est-à-dire qu’il n’est pas destinataire des communications, donc il les répartit et/ou les transmet, sans les déchiffrer ni accéder à la requête web, à un ensemble de serveurs appartenant au client final (ce pourrait être OSM dans le cas présent). Il reçoit alors uniquement l’adresse IP du visiteur et celle du site web de destination, mais pas les entêtes HTTP. Il ne consigne (journalise) pas les communications. Exemples de prestations de ce type : atténuateurs d’attaques par déni de service distribué (DDoS), optimisateur BGP, IP flottante / répartition passive de la charge ;
  
  
• Dans l’autre mode de fonctionnement, bien plus courant, le CDN possède plusieurs copies du contenu à servir (mise en cache), il est le destinataire des communications, donc il les déchiffre, il accède à la requête web, il la traite, il reçoit et consigne (journalise) l’adresse IP du visiteur, l’URL complète, et les entêtes HTTP (qui contiennent des données personnelles), et il sert le contenu web au visiteur.

Dans le cas présent, Fastly est un CDN du deuxième type. Pour s’en assurer, il suffit de constater la présence des entêtes HTTP ajoutés par Fastly à sa réponse à une requête web (cf. sa documentation officielle https://developer.fastly.com/reference/http/http-headers/X-Served-By/) :

    $ curl -s -o /dev/null -D - 'https ://tile.openstreetmap.org/18/132752/90191.png' |grep -E '^x-(served|cache)'
    x-served-by: cache-hhn4054-HHN
    x-cache: HIT
    x-cache-hits: 1

Il y a donc un contact direct entre le terminal de l’utilisateur d’OSM, et les serveurs informatiques de Fastly.

En tant qu’intermédiaire incontournable entre OSM et son utilisateur, Fastly reçoit et consigne l’URL complète consultée par un terminal (adresse IP, modèle, caractéristiques techniques, etc.).

Seule la carte géographique est diffusée via Fastly. Les données saisies dans le champ de recherche (en mode simple ou en mode calcul d’itinéraire) et les cookies (pour stocker le dernier endroit géographique consulté et en cas de connexion sur le site) ne sont pas transmis à Fastly (nom de domaine dédié à la carte géographique).

En revanche, la carte est découpée selon un quadrillage. Chaque case se nomme une tuile (« tile » en anglais). Elle est téléchargée indépendamment des autres cases via une requête web dédiée. Concrètement, une tuile est une image. Évidemment, plus le niveau de zoom est faible, plus une tuile est associée à un grand territoire géographique (exemple : la tuile https://tile.openstreetmap.org/5/15/10.png stocke une grande partie du Royaume-Uni et de l’Irlande). Plus le niveau de zoom est important, plus une tuile est associée à un petit fragment de territoire (exemple : la tuile https://tile.openstreetmap.org/18/132752/90191.png stocke le bâtiment de la CNIL).

Les URLs des tuiles transitent par Fastly. Dans le journal de ses serveurs web, cette société commerciale consigne donc une association entre une adresse IP, une date et heure de consultation, le modèle et quelques caractéristiques techniques d’un terminal, et les URLs de tuiles qui, en fonction du niveau de zoom, peuvent être extrêmement précises (porter sur un petit territoire) et qui ont de l’intérêt pour l’utilisateur d’OSM (il consulte les infos sur ce lieu et/ou sur ses alentours).

Comme l’a jugé la Cour régionale de Munich (décision 3_O_17493/20 portant sur l’utilisation de Google Fonts) et comme l’APD autrichienne (décision du 22 avril 2022 portant sur l’utilisation de Google Analytics) et vous-même (mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’avez analysé, les téléchargements de tuiles sus-référencés depuis les serveurs informatiques de la société commerciale états-unienne Fastly génèrent en eux-mêmes et de facto des transferts hors de l’Union européenne (UE) de plusieurs données personnelles de l’utilisateur d’OSM : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de ses consultations de la carte d’OSM, la marque, le modèle et des caractéristiques techniques de son navigateur web et de son terminal (entête HTTP User-Agent, etc.), l’URL des tuiles (et donc, avec un zoom important, le centre d’intérêt de l’utilisateur d’OSM, le lieu géographique consulté), etc.

    Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique, comme Fastly, qui, par sa présence dans les coulisses de nombreux sites web, peut suivre une personne au sein d’un site web et entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.

D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser des transferts des données personnelles sus-présentées en dehors de l’UE.

À ce jour, il n’existe plus de décision d’adéquation entre l’Union européenne (UE) et les États-Unis, l’arrêt « Schrems II » (C-311/18) de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.

Comme l’EDPS (décision numéro 2020-1013) et vous-même (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt « Schrems II » de la CJUE au motif de la hiérarchie des normes et de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.

    Dans sa politique de confidentialité (https://wiki.osmfoundation.org/wiki/Privacy_Policy), OSM ne mentionne pas l’existence de transferts de données personnelles à un pays tiers non adéquat. De plus, on peut avoir la certitude qu’OSM met en œuvre aucune mesure technique complémentaire, car son site web inclut des instructions techniques ordonnant au navigateur web de son utilisateur le téléchargement automatique et en arrière-plan d’images (les tuiles) directement auprès des serveurs informatiques de Fastly. Dès lors, une requête de téléchargement émise par le navigateur web de l’utilisateur OSM ne chemine pas par l’infrastructure technique d’OSM (dit autrement, il y a un contact direct entre le terminal de l’utilisateur d’OSM et les serveurs informatiques de Fastly), donc elle échappe totalement à OSM, qui peut, de ce seul fait, prendre aucune mesure technique.

    Comme l’analyse l’autorité de protection des données personnelles autrichienne (décision du 22 avril 2022 portant sur l’utilisation de Google Analytics), le RGPD ne prévoit pas d’approche basée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.

OSM ne recueille pas explicitement le consentement de son lecteur pour les transferts de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ces transferts peuvent comporter pour lui, comme l’impose l’article 49.1a du RGPD. Le consentement prévu par cet article n’est, de fait, pas applicable ici.

La nécessité des transferts des données personnelles sus-énumérées aux États-Unis au motif de l’exécution d’un contrat (article 49.1b du RGPD) est irrecevable :

• OSM peut recourir à un CDN (ou à tout autre type d’hébergement informatique) européen disposant de serveurs informatiques localisés dans l’UE. Ou, pour ne pas pénaliser les autres régions du monde (le cas échéant), recourir à plusieurs prestataires régionaux (un pour l’UE, un autre pour le reste du monde, par exemple) et rediriger ses utilisateurs sur les serveurs de l’un ou l’autre des prestataires avec une répartition DNS géolocalisée (OpenStreetMap le fait déjà pour son moteur de recherche interne Nominatim et pour d’autres de ses services) ;
  
  
• OSM peut mettre en avant des versions de sa carte dépourvues de Fastly comme https://tile.openstreetmap.fr/ (propriété de l’association OpenStreetMap France et hébergée en France) ;
  
  
• En tout état de cause, OSM peut informer ses utilisateurs des risques (au sens de l’article 49.1a du RGPD) et conditionner le chargement de sa carte géographique à leur consentement.

En conclusion, lors de la consultation de la carte OSM, les téléchargements automatiques des tuiles depuis les serveurs informatiques détenus par la société commerciale états-unienne Fastly, et les transferts de données personnelles vers les États-Unis qui en découlent sont donc illégaux.

Le site web d’OSM propose une fonctionnalité permettant d’intégrer un fragment de la carte à un site web (pour illustrer un propos, indiquer un lieu, fournir une indication géographique, etc.). Le chargement de la carte depuis le site web « contenant » / « intégrateur » se fera alors depuis les serveurs de Fastly, ce qui, de fait, rend ledit site web non conforme au RGPD.

Le recours à Fastly par OSM constitue un abus de confiance, car OSM est très souvent présenté comme une cartographie libre, communautaire / collaborative, alternative à Google Maps, alors, qu’au final, elle repose en partie sur un acteur états-unien déjà présent dans les coulisses de (trop) nombreux sites web, et que cet acteur reçoit des données personnelles sur les utilisateurs de la carte OSM… tout comme Google Maps.

OSM a recours à Fastly seulement depuis fin 2020. Elle ne saurait donc ignorer les décisions de justice et d’APD sus-énumérées : les règles du jeu existaient avant son passage à Fastly.

Son éditeur en ligne de sa carte géographique (onglet « Modifier » sur le même site web), fait automatiquement télécharger des scripts JavaScripts depuis le CDN du projet jsdelivr.net qui repose sur les serveurs informatiques des CDN des sociétés commerciales états-uniennes Cloudflare et Fastly.

    L’argumentaire est identique à celui déroulé ci-dessus concernant la carte géographique d’OSM. La nécessité du recours à jsdelivr et du transfert de données personnelles qui en découle n’est pas recevable, car il est techniquement, juridiquement et économiquement possible d’héberger lesdits scripts sur les serveurs informatiques d’OSM. Surtout quand on est capable d’héberger un éditeur de carte sur lesdits serveurs (qui peut le plus peut le moins). À défaut, il est possible de recourir à un hébergeur européen disposant de serveurs localisés dans l’UE.

Je vais signaler, à la fondation OpenStreetMap, ses manquements au RGPD afin qu’elle s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’elle entreprendrait, les faits relatés ci-dessus constituent en soi une violation du Règlement qui justifie à elle seule le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.

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