4665 links
  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
page 1 / 1
  • Flicage sur le web : après la presse et ma banque, mon employeur

    Il y a bientôt un mois, j'ai emmerdé ma banque avec les ressources (police de caractères, CSS, JavaScript) qu'elle fait télécharger automatiquement depuis des acteurs économiques états-uniens (Google, AppDynamics, Tealium, etc.) lors de la consultation de son nouvel (sic !) espace personnel en ligne. C'est contraire au RGPD en plus d'être un non-sens technique. J'explique tout cela dans un shaarli dédié. J'en avais fait de même en février / avril 2020 avec la presse en ligne.



    Depuis, je me suis trouvé dans une dissonance : les sites web de mon employeur (une administration) contiennent eux aussi Google Fonts, Bootstrap CDN, jsDelivr, Cloudflare, Fastly, jquery.com / OpenJS, Amazon, Microsoft, etc. à gogo. Emmerder les autres, c'est bien, mais nettoyer devant sa porte au préalable, c'est mieux.

    Certes, je peux me prévaloir d'un email, envoyé en mars 2020 à l'équipe des développeuses, au directeur technique et aux directeurs adjoints de la direction informatique, dans lequel je signalais le problème (fuite de données personnelles injustifiable), j'expliquais le non-sens technique que cela constitue sous l'apparence de la simplicité ("tout le monde est dev' !"… forcément, si l'on utilise les paramètres par défaut d'un framework, que l'on suit le premier tutoriel venu, et que l'on ignore une partie des implications de nos choix…), et j'exposais la complication juridique qui se profilait : l'arrêt Schrems II de la Cour de Justice de l'Union européenne (CJUE) n'avait pas encore été rendu ‒ juillet 2020 ‒, mais il y avait déjà de lourds indices (décision Schrems I de la CJUE ‒ invalidation du Safe Harbor ‒, décision C-40/17 de juillet 2019 de la CJUE, prise de position sur les contenus tiers du 14 novembre 2019 du commissaire à la protection des données de Hambourg, etc.).

    Deux ans plus tard : rien. Aucune amélioration sur les sites web existants. Aucune réflexion en cours sur cette problématique. Aucun inventaire des sites web non-conformes n'a été produit. Aucune planification de la mise en conformité a été élaborée. Pire, plusieurs sites web mis en service ces derniers mois / année, postérieurement à Schrems II donc, contiennent des ressources externalisées chez les ricains, ce qui illustre une méconnaissance (la sensibilisation du personnel est une obligation du RGPD) ou un désintérêt.

    J'ai donc envoyé une LRAR au DPO de mon employeur doublée d'une plainte à la CNIL. J'y rappelle l'ancienneté de mon signalement, l'aspect juridique, et l'aspect technique. J'y joins un inventaire de 27 sites web non-conformes avec le motif de non-conformité et mes préconisations pour devenir conforme. J'y demande à ce qu'il conduise une action de prévention / sensibilisation / information auprès de nos développeuses afin que les futurs sites web soient conformes par conception voire qu'il définisse (ou qu'il fasse définir) et valide une configuration conforme par défaut de nos frameworks web (afin de faciliter le transfert des savoirs au sein d'une équipe en croissance) et/ou qu'il contrôle chaque site web / service avant sa mise en service.



    Je ne publie pas mes proses car elles en disent long sur mon employeur et ma localisation, et leur caviardage les rendraient inutiles, mais l'argumentaire est le même que pour ma banque. Résumé :

    • Depuis Schrems II, il n'existe plus de transfert automatique des données personnelles des Européens vers les États-Unis, il faut des cadres contraignants ;

    • Une fois cette difficulté levée, il faut toujours une base légale pour collecter et traiter des données personnelles. Comme on l'a vu, l'externalisation de l'hébergement de styles CSS, de polices de caractères et de codes JavaScript génère forcément un tel traitement ;

    • Externaliser chez des acteurs européens ne suffit donc pas ;

    • Dans le cas présent, pas de repli possible sur l'intérêt légitime, car héberger, en interne, des CSS, des polices et du JavaScript est possible à coût insignifiant, donc ça ne valide pas les obligations de nécessité et de proportionnalité de l'intérêt légitime ;

    • Il reste le consentement explicite, mais… ;

    • …Si une fonctionnalité essentielle d'un site web, ou un site web dans son ensemble, ne fonctionne plus quand on refuse le flicage, comme c'est le cas de deux sites web de mon employeur, alors le consentement est réputé vicié donc il ne peut être une base légale du traitement ni permettre le transfert de données personnelles à des entités états-uniennes ;

    • …Le recueil du consentement en permanence gonfle tout internaute et il est pénible à obtenir : il faut le recueillir avant le chargement des ressources externalisées, donc, dans le cas de styles CSS et de polices de caractères, avant que le site web soit mis en forme, avant son chargement (oui, quand le site web n'est pas jojo). Or, comme il existe une solution moins pénible pour l'usager et moins chronophage pour les développeurs, l'internalisation des ressources, celle-ci devrait être privilégiée (principe de proportionnalité, toujours).



    Il y a trois nouveautés par rapport à l'argumentaire envoyé à ma banque :

    • Sur un site web qui charge les derniers tweets d'un utilisateur donné en utilisant le widget Twitter, on peut soit virer cette fonctionnalité (tout le monde s'en fiche, ça excite uniquement les directions de la communication), soit récupérer les tweets côté serveur / backoffice avec les API de Twitter, soit conditionner le chargement du widget Twitter au clic du visiteur sur un bouton « j’autorise le transfert hors de l’UE d'informations personnelles (adresse IP, site web consulté) et leur traitement par Twitter (États-Unis) ». C'est ce que fait Doctolib pour son encart de localisation d'un praticien, par exemple ;

      • Même raisonnement pour des vidéos Google YouTube incrustées dans une page web.
    • Les logiciels proposent parfois des paramètres de configuration pour éviter le chargement de ressources externalisées. Exemples : Gitlab permet de désactiver Gravatar et Kibana permet de désactiver la récupération des nouveautés auprès de l'éditeur à chaque connexion ;

    • À défaut d'une solution évidente à mettre en œuvre ou durant sa mise en œuvre ou en présence d'un doute sur la base légale (consentement éclairé ou vicié car le service est largement atrophié en cas de refus ?), la moindre des choses est de prévenir l'usager (« En utilisant ce champ de recherche, j’autorise le transfert hors de l’UE d’informations personnelles (adresse IP, objet de ma recherche) et leur traitement par Google (États-Unis) », par exemple). Ça marque une connaissance du sujet, une volonté de se mettre en conformité, et, en cas d'audit ou de contrôle par la CNIL, c'est apprécié ;



    Inventorier les sites web de mon employeur, rédiger mon courrier à son DPO et ma plainte à la CNIL m'a pris 15 h. Tu m'étonnes que pas grand monde s'y colle. L'équivalent de deux jours de salariat. Oui, j'ai fait tout ça sur mon temps libre afin d'avoir plus de liberté : pas de comptes à rendre et sortir du groupe social que constitue mes collègues et chefs permet d'agir "contre" ce que pense ce groupe (c'est-à-dire "osef des requêtes qui partent aux USA, y'a plus grave dans la vie").



    Je ne suis pas plus naïf que lorsque j'ai écrit à ma banque ou aux journaux : je sais que ma démarche est vaine. Le DPO de mon employeur va s'en cogner car, chez mon employeur comme partout ailleurs, il existe des non-conformités manifestes à gogo (sans exagération ni pinaillage) dont certaines sont bien plus graves que ce que je signale-là. Idem pour la CNIL. Certes, mais il faut bien commencer quelque part et, sur ce sujet, il est simple de se mettre en conformité. Dans les deux cas (DPO et CNIL), cela leur permet de mesurer l'ampleur du problème. Ça informe les autorités compétentes. Si elles font rien, ça permettra d'illustrer en quoi elles sont déficientes et de réclamer leur remplacement (on peut difficilement s'époumoner sur un système qu'on n'a pas éprouvé).

    Mais bon, me signaler à des tiers, les GAFAM, tout au long de ma journée de travail, ce n'est pas cool. Ben oui, car notre authentification centralisée (SSO) charge des ressources depuis Google et Cloudflare, idem pour certains de nos outils métier comme notre IPAM qui charge du Google et du Microsoft.


    Le courage peut prendre de nombreuses formes, dit-il avec un sourire. Il faut beaucoup de bravoure pour faire face à ses ennemis mais il n’en faut pas moins pour affronter ses amis. Et par conséquent, j’accorde dix points à Mr Neville Londubat.

    Harry Potter à l'école des sorciers.



    Merci Aeris pour le coup de papatte. :)

    Fri 27 May 2022 11:26:49 AM CEST - permalink -
    - http://shaarli.guiguishow.info/?HTzlDg
Links per page: 20 50 100
page 1 / 1
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

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