Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.
C’est un peu plus compliqué que ça. 2 traitements différents portant sur la même donnée peuvent effectivement avoir des bases légales différentes, mais la donnée initiale elle-même a déjà fait l’objet d’un traitement (sa collecte) avec une certaine base légale et tous les traitements derrière ne peuvent du coup qu’avoir une base légale compatible avec la base légale initiale.
Il est impossible de faire un traitement ultérieur d’une données sous la base légale « intérêt légitime » si la base légale initiale de la collecte de cette donnée ne contenait que « consentement ». Ton point de collecte définit le périmètre maximal qu’il ne sera jamais possible de dépasser sur l’ensemble des traitements ultérieurs présents ou futurs qui sera fait sur ces données.
Et mon point est justement là : Metabase est la porte ouverte à toutes les fenêtres, les utilisateurs envisageant difficilement quelles requêtes vont être toujours dans le scope légale de la collecte initiale. Ce n’est pas parce que la donnée est à dispo et que tu peux en sortir un joli dashboard sous Metabase que ce que tu fais est autorisé.
Et ce n’est pas parce que tu renseignes ton registre de traitement avec le nouveau traitement et sa base légale qu’il devient magiquement légal s’il reste incompatible avec la finalité et base légale de la collecte initiale.
Voir par exemple les condamnations pour finalités incompatibles avec la collecte initiale de la donnée.
Tu manipules très souvent des données personnelles hein… Ou dit autrement des stats sans données personnelles à l’origine ou à la fin sont généralement assez peu intéressantes.
Et bien penser aussi qu’un traitement de données personnelles, c’est aussi la collecte de la donnée, et pas uniquement l’extraction ou affichage ultérieur. Si l’origine même de ta donnée contient une donnée perso (facture, paiement, etc), alors sa réutilisation pour des finalités autres que initiale est encadrée voire proscrite.
Typiquement des stats sur ta compta sont aussi touchées par le RGPD parce que ta facture initiale contient de la donnée perso, même si la stat finale, elle, ne contient pas de données perso.
Et la base légale (« intérêt légitime ») et finalité (« suivre mon commerce ») de tes stats seraient plutôt en contradiction avec la finalité initiale de la facture (« encaisser un paiement ») et sa base légale (« obligation légale »). Tu n’as donc pas le droit de partir de ton stock de facture pour établir tes stats de commerce (détournement de finalité et utilisation d’une base légale incompatible).
Si Metabase est un outil extrêmement puissant, c’est aussi typiquement le genre d’outil qui sera très rapidement bordeline niveau conformité RGPD.
Le fait de pouvoir dynamiquement faire tout plein de requêtes, de recroiser les données dans tous les sens voire mettre à dispo les données brutes non agrégées est la porte ouverte à tous les détournements de finalité.
La conformité RGPD limite souvent la puissance de Metabase, puisque les données brutes doivent nécessairement (article 5.c) être déjà agrégées et leur format interdire (article 5.b) le détournement de finalité, donc de limiter les possibilités de requêtes ou de création de dashboard « à la volée ».
Et Metabase se transforme du coup en « simple » visualiseur avancé permettant de filtrer par date/catégorie des tables pré-définies, perdant beaucoup de sa flexibilité.
Il y a bien d’autres tests que juste les ciphers avec CryptCheck, et beaucoup ne sont pas encore affichés sur l’interface faute d’avoir des personnes compétentes en UI/UX pour me filer un coup de patte :)
En l’occurence le « E » s’explique ici par le manque de HSTS.
Quant au banques, si au moins elles n'obligeaient pas à utiliser des applis merdiques et propriétaires pour le 2FA… Et encore ils n'ont pas osé à la CÉ (ils sont en retard mais bon, c'est pas nouveau).
DSP2 impose(ra) forcément du « propriétaire » à ce niveau.
Plus exactement il impose une 2FA « contextuelle » pour éviter les man-in-the-middle. Ça suppose d’afficher des données supplémentaires à l’OTP pour que l’utilisateur puisse identifier de manière fiable le demandeur de l’OTP.
Dans le cas d’une validation de virement ou de paiement, c’est par exemple le montant de la transaction ainsi que son destinataire, pour éviter un attaquant qui ferait proxy et te débiterait le montant qu’il souhaite à son propre profit si on se limitait au seul OTP.
Dans celui de la connexion, ça pourrait être l’affichage d’un symbole spécifique connu uniquement de toi et de ta banque. Une banque belge dont j’ai perdu le nom avait implémenté ça dans un token OTP matériel d’ailleurs, mais je n’en retrouve plus la référence…
En pratique ça demande(ra) donc du développement spécifique à chaque banque et même si la théorie derrière est libre et commune (T-OTP), chaque banque risque d’avoir sa propre application ou fonctionnement pour couvrir ce besoin de « contextualisation ».
C’est même la raison n°1 de pourquoi les banques préfèrent encore violer la DSP-2 et ont demandé une rallonge de 2 ans pour continuer avec le SMS, elles n’ont actuellement pas de solution conforme à disposition.
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
Je veux dire par là que SCSV protège uniquement des attaques (semi) passives consistant à bloquer la connection TCP à la détection d’une connexion TLSv1.2 en espérant que le client va retenter derrière en TLSv1.1.
À partir du moment où on considère un attaquant actif capable d’éditer le flux, alors il shootera SCSV de la même manière qu’il modifierait les paquets pour supprimer les ciphers safe et forcer une connection vers 3DES. Il lui suffit de supprimer le flag SCSV de la demande de connexion TLSv1.1. Le handshake n’étant pas signé…
A noter que 0.2% ça peut être rien pour toi, mais pour un support client de millions de personnes, c'est de la thune à dépenser pour dire aux clients d'upgrader leur bousin ce qui eut assez mal passer. Tu ne peux pas ne pas faire la différence entre des entités qui gèrent TLS 1.3 avec CHACHA20 mais aussi TLS 1.1 et des entités qui gèrent que TLS 1.1.
Axa ou N26 l’ont fait. Je ne vois du coup pas ce qu’il y a d’insurmontable.
PS : pour le downgrade de suite de chiffrement, au temps pour moi, remplacer 1.2 par 1.3… Le besoin est donc surtout de gérer 1.3, et si je comprend bien alors 1.1 peut être encore gérer sans risque pour les clients 1.3.
Ils ont déjà du mal à supporter 1.2, alors 1.3, si on l’a d’ici 10 ans je serais étonné…
Et encore une fois, avoir du 1.3 & des trucs pétés dans la boucle, c’est s’ouvrir la porte à toutes les fenêtres. On ne peut/doit pas parier la sécurité de son bordel sur une conjonction improbable d’éléments divers et variés…
« Alors tu es safe si tu as du 1.3 ou du 1.2 avec du SCSV et je laisse des trucs pétés uniquement sur 1.1 en espérant que tu ne tomberas pas dessus par l’opération du saint-esprit »
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
SCSV permet simplement de ne pas downgrade vers TLSv1.1 si le client et le serveur supportent TLSv1.2 (le serveur verra passer une demande en 1.1 avec le flag SCSV et va hurler).
Ça ne permet pas de protéger d’un downgrade de (TLSv1.2) ECDHE-ECDSA-AES256-GCM-SHA384 vers (TLSv1.2) DES-CBC3-SHA qui est pété depuis 2016 et sweet32 si le site en face supporte les 2.
En gros ça protège le protocole (TLSv1.2/1.1/1.0) et pas les ciphers suites (AES, 3DES, RC4…), il faut attendre TLSv1.3 pour corriger ça avec un handshake lui-même signé (en TLSv1.2 il ne l’est pas).
Comme tu pourras le voir ici, une suite de chiffrement permettant d’être A+ est compatible avec la quasi-totalité du monde à l’exception de IE6/XP, qui sont une hérésie en 2020 de toute façon.
Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…
Mais sinon, oui ça a l'air de faire partie des sites "intégristes" qui ne regardent que si tu supportes un "mauvais" protocoles même si c'est pour supporter des vieux clients sans réduire la sécurité des nouveaux clients
Le problème est que trop de sites se réfugient derrière cette pseudo-compatibilité pour ne pas faire évoluer leur sécurité. 3DES est pété depuis déjà 2016 (4 ans bordel…) et on le trouve encore sur les banques & le reste.
Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3 (><) et moins ou Firefox 26 et moins. Des trucs de 2015 qui étaient DÉJÀ pétés en 2016 et la disparition de 3DES.
Ces sites montrent bien un véritable problème de sécurité pour ne pas avoir fait les mises-à-jour nécessaires et mettre tous les autres utilisateurs (qui eux ont fait les mises-à-jours) en péril…
merci TLS 1.2 et la non possibilité d'inciter à prendre un vieux protocole si au milieu).
Ça c’est globalement faux. Il existe pas mal de moyen de contraindre un site à négocier une suite pétée à partir du moment où le serveur supporte une suite merdique.
Tu peux très bien négocier du AES128-SHA voire du DES-CBC3-SHA alors que tu es bien en TLSv1.2 (cas de google.fr).
L’employeur n’a pas légalement pas besoin de te demander ton avis avant d’utiliser un service de dématérialisation. Il doit uniquement te permettre de t’y opposer, et ceci n’importe quand.
Une fois un service choisi, il relève du coup de l’intérêt légitime pour l’entreprise d’utiliser ce service.
J’ajouterais un 2nd « intérêt légitime + obligation légale » puisqu’on est ici dans le cadre professionnel, donc avec une obligation de subordination qui fait qu’un employeur peut t’imposer ce genre d’outils.
Posté par Aeris (site web personnel) .
En réponse au journal Flatpak.
Évalué à 7.
Dernière modification le 12 octobre 2018 à 19:59.
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Pourtant unattended-upgrades est active par default avec Debian et Gnome: https://wiki.debian.org/UnattendedUpgrades
Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.
Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.
Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.
D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…
Sinon concernant les tests, la quasi majorités des logiciels libres importants sont aujourd'hui couvert par un nombre de tests suffisamment important pour garantir leur bon fonctionnement dans un environnement donnée
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
encore faut-il que les sysadmins se donne la peine de réaliser ces mises à jours compte tenu du risque que cela représente. Quand tu as la possibilité de réaliser ces mises à jours dans une environnement reproductible, tu n'as plus aucune raison pour ne pas les faire étant données que tu as toujours la possibilité de revenir en arrière si dans le pire des cas tu observais un problème après avoir effectué l'upgrade.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.
Tout le monde, toi y compris : Firefox, OpenSSH, libSSL, le kernel Linux etc.
C'est le propre d'une faille de sécurité : transformer un logiciel bienveillant en un logiciel malveillant.
Et donc tu arrêtes d’embarquer en dur tes libs ou de te transformer en leur mainteneur.
Pour justement te mettre à jour le plus vite possible quelque soit l’état d’utilisation des logiciels à la fin.
Et tu vires immédiatement tout ce qui ne supporte pas la nouvelle versions patchée.
Pour résumer, tu as la reproductibilité pour une image donnée et un contexte d’exécution donné.
Dès que tu reconstruits l’image en changeant une dépendance, tu ne garanties plus rien (incompatiblité fonctionnelle).
Dès que tu changes le contexte d’exécution (passage alpine/debian, ou changement de distribution hôte), tu ne garanties plus rien non plus (incompatibilité ABI).
L'isolation des dépendances à au moins l'avantage de permettre la reproductibilité de l’environnement, de pouvoir exécuter des tests dans un environnement contrôlé et rentre tout processus de mise à jour automatisable plus facilement.
Pour moi c’est justement exactement le contraire.
L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/µClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
Ton idée de maj auto vient de sauter aussi du coup.
On est en deux mille dix huit ; 2go c'est que dalle, parce que, comme indiqué ci dessus c'est une seule fois : les applications suivantes utiliseront le même runtime. Au pire si un deuxième runtime est installé les fichiers identiques ne seront pas dupliqués sur le disque. Je préfère perdre 2go que des heures sur des problèmes idiots de dépendance. Mais votre temps est peut être moins précieux que le mien!
Et c’est exactement avec ce type d’argumentation qu’on en est là aujourd’hui…
Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport
Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.
Les gens se feront un plaisir de packager un logiciel propre.
Ça prend 40 ans à packager pour beaucoup d’applis parce que les devs font juste n’importe quoi et ne pensent pas à leur release avant.
Oui, un soft qui embarque la moitié du monde, les packageurs ne vont pas se presser au portillon…
# Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 7. Dernière modification le 04 février 2022 à 20:58.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
[^] # Re: Un petit peu HS
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 5.
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 1. Dernière modification le 29 novembre 2021 à 10:43.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Ça donne par exemple :
https://www.linkedin.com/pulse/gdpr-has-big-implications-business-intelligence-nick-ringle?articleId=6408376440735301632
https://wiiisdom.com/white-paper/business-objects-gdpr-compliance/
https://tdwi.org/articles/2018/06/04/biz-all-gdpr-impact-on-bi-1.aspx
et tant d’autres sujets qui sont actuellement complètement passés sous silence devant la facilité de ces outils de sortir du cadre réglementaire.
Voir aussi par exemple cette condamnation à 50.000€ d’amende, pour avoir eu un outil de BI trop ouvert.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 2.
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -2. Dernière modification le 28 novembre 2021 à 14:39.
C’est un peu plus compliqué que ça. 2 traitements différents portant sur la même donnée peuvent effectivement avoir des bases légales différentes, mais la donnée initiale elle-même a déjà fait l’objet d’un traitement (sa collecte) avec une certaine base légale et tous les traitements derrière ne peuvent du coup qu’avoir une base légale compatible avec la base légale initiale.
Il est impossible de faire un traitement ultérieur d’une données sous la base légale « intérêt légitime » si la base légale initiale de la collecte de cette donnée ne contenait que « consentement ». Ton point de collecte définit le périmètre maximal qu’il ne sera jamais possible de dépasser sur l’ensemble des traitements ultérieurs présents ou futurs qui sera fait sur ces données.
Et mon point est justement là : Metabase est la porte ouverte à toutes les fenêtres, les utilisateurs envisageant difficilement quelles requêtes vont être toujours dans le scope légale de la collecte initiale. Ce n’est pas parce que la donnée est à dispo et que tu peux en sortir un joli dashboard sous Metabase que ce que tu fais est autorisé.
Et ce n’est pas parce que tu renseignes ton registre de traitement avec le nouveau traitement et sa base légale qu’il devient magiquement légal s’il reste incompatible avec la finalité et base légale de la collecte initiale.
Voir par exemple les condamnations pour finalités incompatibles avec la collecte initiale de la donnée.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -3.
Tu manipules très souvent des données personnelles hein… Ou dit autrement des stats sans données personnelles à l’origine ou à la fin sont généralement assez peu intéressantes.
Et bien penser aussi qu’un traitement de données personnelles, c’est aussi la collecte de la donnée, et pas uniquement l’extraction ou affichage ultérieur. Si l’origine même de ta donnée contient une donnée perso (facture, paiement, etc), alors sa réutilisation pour des finalités autres que initiale est encadrée voire proscrite.
Typiquement des stats sur ta compta sont aussi touchées par le RGPD parce que ta facture initiale contient de la donnée perso, même si la stat finale, elle, ne contient pas de données perso.
Et la base légale (« intérêt légitime ») et finalité (« suivre mon commerce ») de tes stats seraient plutôt en contradiction avec la finalité initiale de la facture (« encaisser un paiement ») et sa base légale (« obligation légale »). Tu n’as donc pas le droit de partir de ton stock de facture pour établir tes stats de commerce (détournement de finalité et utilisation d’une base légale incompatible).
# Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -4. Dernière modification le 28 novembre 2021 à 12:24.
Si Metabase est un outil extrêmement puissant, c’est aussi typiquement le genre d’outil qui sera très rapidement bordeline niveau conformité RGPD.
Le fait de pouvoir dynamiquement faire tout plein de requêtes, de recroiser les données dans tous les sens voire mettre à dispo les données brutes non agrégées est la porte ouverte à tous les détournements de finalité.
La conformité RGPD limite souvent la puissance de Metabase, puisque les données brutes doivent nécessairement (article 5.c) être déjà agrégées et leur format interdire (article 5.b) le détournement de finalité, donc de limiter les possibilités de requêtes ou de création de dashboard « à la volée ».
Et Metabase se transforme du coup en « simple » visualiseur avancé permettant de filtrer par date/catégorie des tables pré-définies, perdant beaucoup de sa flexibilité.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Il y a bien d’autres tests que juste les ciphers avec CryptCheck, et beaucoup ne sont pas encore affichés sur l’interface faute d’avoir des personnes compétentes en UI/UX pour me filer un coup de patte :)
En l’occurence le « E » s’explique ici par le manque de HSTS.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 6. Dernière modification le 20 juillet 2020 à 11:31.
DSP2 impose(ra) forcément du « propriétaire » à ce niveau.
Plus exactement il impose une 2FA « contextuelle » pour éviter les man-in-the-middle. Ça suppose d’afficher des données supplémentaires à l’OTP pour que l’utilisateur puisse identifier de manière fiable le demandeur de l’OTP.
Dans le cas d’une validation de virement ou de paiement, c’est par exemple le montant de la transaction ainsi que son destinataire, pour éviter un attaquant qui ferait proxy et te débiterait le montant qu’il souhaite à son propre profit si on se limitait au seul OTP.
Dans celui de la connexion, ça pourrait être l’affichage d’un symbole spécifique connu uniquement de toi et de ta banque. Une banque belge dont j’ai perdu le nom avait implémenté ça dans un token OTP matériel d’ailleurs, mais je n’en retrouve plus la référence…
En pratique ça demande(ra) donc du développement spécifique à chaque banque et même si la théorie derrière est libre et commune (T-OTP), chaque banque risque d’avoir sa propre application ou fonctionnement pour couvrir ce besoin de « contextualisation ».
C’est même la raison n°1 de pourquoi les banques préfèrent encore violer la DSP-2 et ont demandé une rallonge de 2 ans pour continuer avec le SMS, elles n’ont actuellement pas de solution conforme à disposition.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 4. Dernière modification le 19 juillet 2020 à 22:14.
Je veux dire par là que SCSV protège uniquement des attaques (semi) passives consistant à bloquer la connection TCP à la détection d’une connexion TLSv1.2 en espérant que le client va retenter derrière en TLSv1.1.
À partir du moment où on considère un attaquant actif capable d’éditer le flux, alors il shootera SCSV de la même manière qu’il modifierait les paquets pour supprimer les ciphers safe et forcer une connection vers 3DES. Il lui suffit de supprimer le flag SCSV de la demande de connexion TLSv1.1. Le handshake n’étant pas signé…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Axa ou N26 l’ont fait. Je ne vois du coup pas ce qu’il y a d’insurmontable.
https://cryptcheck.fr/https/connect.axa.fr
Ils ont déjà du mal à supporter 1.2, alors 1.3, si on l’a d’ici 10 ans je serais étonné…
Et encore une fois, avoir du 1.3 & des trucs pétés dans la boucle, c’est s’ouvrir la porte à toutes les fenêtres. On ne peut/doit pas parier la sécurité de son bordel sur une conjonction improbable d’éléments divers et variés…
« Alors tu es safe si tu as du 1.3 ou du 1.2 avec du SCSV et je laisse des trucs pétés uniquement sur 1.1 en espérant que tu ne tomberas pas dessus par l’opération du saint-esprit »
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3. Dernière modification le 19 juillet 2020 à 22:03.
Il faudrait que je refasse tourner la moulinette, mais en mai 2019, c’était une grosse catastrophe…
https://imirhil.fr/tls/banks.html
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 7. Dernière modification le 19 juillet 2020 à 21:56.
SCSV permet simplement de ne pas downgrade vers TLSv1.1 si le client et le serveur supportent TLSv1.2 (le serveur verra passer une demande en 1.1 avec le flag SCSV et va hurler).
Ça ne permet pas de protéger d’un downgrade de (TLSv1.2) ECDHE-ECDSA-AES256-GCM-SHA384 vers (TLSv1.2) DES-CBC3-SHA qui est pété depuis 2016 et sweet32 si le site en face supporte les 2.
En gros ça protège le protocole (TLSv1.2/1.1/1.0) et pas les ciphers suites (AES, 3DES, RC4…), il faut attendre TLSv1.3 pour corriger ça avec un handshake lui-même signé (en TLSv1.2 il ne l’est pas).
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 4.
Comme tu pourras le voir ici, une suite de chiffrement permettant d’être A+ est compatible avec la quasi-totalité du monde à l’exception de IE6/XP, qui sont une hérésie en 2020 de toute façon.
Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Le problème est que trop de sites se réfugient derrière cette pseudo-compatibilité pour ne pas faire évoluer leur sécurité. 3DES est pété depuis déjà 2016 (4 ans bordel…) et on le trouve encore sur les banques & le reste.
Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3 (><) et moins ou Firefox 26 et moins. Des trucs de 2015 qui étaient DÉJÀ pétés en 2016 et la disparition de 3DES.
Ces sites montrent bien un véritable problème de sécurité pour ne pas avoir fait les mises-à-jour nécessaires et mettre tous les autres utilisateurs (qui eux ont fait les mises-à-jours) en péril…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Ça c’est globalement faux. Il existe pas mal de moyen de contraindre un site à négocier une suite pétée à partir du moment où le serveur supporte une suite merdique.
Tu peux très bien négocier du AES128-SHA voire du DES-CBC3-SHA alors que tu es bien en TLSv1.2 (cas de google.fr).
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
https://cryptcheck.fr/https/cryptcheck.fr
Certains y arrivent pourtant :)
[^] # Re: Le RGPD est clair pour ceux qui pensent qu'il est clair ^^
Posté par Aeris (site web personnel) . En réponse au journal « votre bulletin de paye électronique ». Évalué à 8. Dernière modification le 06 juin 2019 à 00:32.
Ne pas oublier aussi que le consentement n’est QU’UN des moyens légaux opposables à une collecte de données.
Au pif, on a aussi
En l’occurrence ici, je vois au moins 2 moyens possibles permettant l’utilisation de ce service sans avoir de consentement à recueillir :
Décret n° 2016–1762 du 16 décembre 2016 relatif à la dématérialisation des bulletins de paie et à leur accessibilité dans le cadre du compte personnel d’activité
https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000033625104&categorieLien=id
L’employeur n’a pas légalement pas besoin de te demander ton avis avant d’utiliser un service de dématérialisation. Il doit uniquement te permettre de t’y opposer, et ceci n’importe quand.
Une fois un service choisi, il relève du coup de l’intérêt légitime pour l’entreprise d’utiliser ce service.
J’ajouterais un 2nd « intérêt légitime + obligation légale » puisqu’on est ici dans le cadre professionnel, donc avec une obligation de subordination qui fait qu’un employeur peut t’imposer ce genre d’outils.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 7. Dernière modification le 12 octobre 2018 à 19:59.
Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.
Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.
Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.
D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…
Ou encore gpgme 1.1, quand on en est à la 1.12…
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 3.
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 3.
Et donc tu arrêtes d’embarquer en dur tes libs ou de te transformer en leur mainteneur.
Pour justement te mettre à jour le plus vite possible quelque soit l’état d’utilisation des logiciels à la fin.
Et tu vires immédiatement tout ce qui ne supporte pas la nouvelle versions patchée.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 1.
Pour résumer, tu as la reproductibilité pour une image donnée et un contexte d’exécution donné.
Dès que tu reconstruits l’image en changeant une dépendance, tu ne garanties plus rien (incompatiblité fonctionnelle).
Dès que tu changes le contexte d’exécution (passage alpine/debian, ou changement de distribution hôte), tu ne garanties plus rien non plus (incompatibilité ABI).
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 1.
Pour moi c’est justement exactement le contraire.
L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/µClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
Ton idée de maj auto vient de sauter aussi du coup.
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 9.
Et c’est exactement avec ce type d’argumentation qu’on en est là aujourd’hui…
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 4.
Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.
Les gens se feront un plaisir de packager un logiciel propre.
Ça prend 40 ans à packager pour beaucoup d’applis parce que les devs font juste n’importe quoi et ne pensent pas à leur release avant.
Oui, un soft qui embarque la moitié du monde, les packageurs ne vont pas se presser au portillon…