La DSP2 impose dorénavant une authentification dite contextuelle. C’est-à-dire que techniquement, celui qui va valider l’OTP ne doit avoir aucun moyen d’ignorer l’action réalisée (s’authentifier, payer, ajouter un bénéficiaire…), le montant et le destinataire éventuel. Et le système doit être robuste à un « man-in-the-middle physique » par ton voisin de bureau (en gros éviter qu’il soit facile de dire « eh Truc, tu peux valider/me donner ton OTP pour 20€ chez la FNAC » alors que c’est un achat de 1000€ chez AliExpress).
Les moyens offline ne le permettent pas ou vraiment pas facilement, et les systèmes matériels dédiés deviennent trop coûteux (scan d’un qrcode, connexion bluetooth ou wifi pour récupérer l’info, écran plus avancé qu’un afficheur 6× 7 segments, etc). Tu passes de machin débile avec 3 transistors qui se battent en duel à moins de 10€ pièce à des mini-PC avec RAM, puce wifi/caméra et OS à plus de 100€ l’unité.
D’où le recours aux téléphones, qui coûtent pas cher aux banques, dispo partout, facilement mettable à jour…
la possession et le protocole de communication : tu peux parfaitement te faire voler ton téléphone ;
C’est bien pour ça que le SMS n’est plus reconnu comme valide comme facteur de possession depuis quelques années et que l’authenfication du téléphone nécessite bien souvent un facteur biométrique supplémentaire
la sécurisation des échanges et le protocole de transport : un mail peut parfaitement être chiffré, un SMS peut donner une instruction qui ne sera réalisable que par le destinataire ;
Le chiffrement du message ne garantit pas que le détenteur de la clef est bien devant le téléphone. C’est de toute façon exclusivement de la confidentialité et non de l’authentification justement.
Et il n’existe pas d’action réalisable par le destinataire supposé qui ne soit pas réalisable par le destinataire réel. La 2FA est justement là pour se prémunir du 1er, et non pas seulement du 2nd. C’est pour ça par exemple que le facteur de possession de la 2FA bancaire impose des mécanismes obligeant le propriétaire souhaité à faire une action dont il doit forcément avoir conscience, y compris en cas de man-in-the-middle physique.
2FA et utilisation de deux canaux de communication : on sait parfaitement faire du MFA sur un seul canal : avec SSH, je peux avoir une clef que je possède et un mot de passe que je connais, ça fait bien deux facteurs.
Et c’est très difficile à faire dans un environnement décentralisé sans point central comme peut l’être une banque.
Si les banques se sont repliés vers les téléphones mobiles, c’est pas vraiment pour rien, et surtout après s’être fait dégommé la totalité des autres moyens d’authenfication par l’EBA…
On s’attaque réellement à des problèmes durs dont il n’y a pas de solution simple à mettre en œuvre, et dans un contexte « libre, décentralisé, etc » la difficulté est au moins de 2 voire 3 ordres de grandeur supplémentaires (qui est responsable en cas de merde, les certifications, l’interdiction de modification d’un système certifié, tiers de confiance, etc)
attention, celle ci ne concerne que la problématique du CPF.
Et propose 2 alternatives (mail et SMS) qui sont de facto non légalement recevable en l’état de la loi (SIM swap et interception mail). Ces 2 moyens ne sont plus reconnus comme des facteurs de possession depuis plusieurs années mais réduit à un facteur de connaissance.
Toute la difficulté est actuellement là : les facteurs de possession nécessitent aujourd’hui des moyens technologiques pour être mis en œuvre (en tout cas dans des délais de vérification pas trop long)
2 voire 3 des conditions sont difficilement possibles pour la DSP2 par exemple, et c’est globalement pareil pour les autres besoins
ouvertes : Les obligations de certifications sont assez incompatibles avec ce concept, toute modification du système devant être strictement impossible. Ça rend l’ouverture rapidement inutile ou n’apportant rien réellement au système
standard : L’intégration nécessite un accès privilégié aux SI des banques (2FA dite « contextuelle » nécessitant d’obtenir des informations type action/montant/destinataire), difficile d’y mettre en œuvre des trucs « standard », chacun devant développer sa couche d’intégration et préfère du coup faire du custom à sa sauce que de chercher une interface commune avec tout le monde.
accessibles : Lié au 1er point, la certification des solutions d’authentification coûte (très) chère, en particulier en terme d’assurance (qu’est-ce qu’on doit possiblement payer/rembourser si le système merde vu qu’on en endosse la responsabilité). Du coup double problème pour avoir un système « accessible ». Avoir suffisamment de part de marché pour rendre intéressant de certifier un système par les banques par exemple, et de l’autre côté difficulté à financer la certification pour les systèmes non pris en charge par les précédents.
Je peux tout à fait construire un scalpel, une lampe de bloc opératoire, un lit électrique et même l'ordinateur qui piloterait tout ça. J'en ai le droit et même dans mon salon
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
Ce n'est pas mis en avant sur la page de Delta-Chat, mais une personne qui compilerait le logiciel serait au delà de l'utilisateur basique et donc on peut compter sur sa capacité à faire une recherche sur software héritage, et le quelifier d'accès simple.
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
L'utilisateur lambda ayant besoin d'un binaire déjà préparé, il n'a pas besoin des sources, il n'a pas besoin de github.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Je pense que les gens qui installent directement depuis le .deb fourni ne sont pas si nombreux, ce n'est pas le moyen d'accès privilégié pour ce genre de logiciel : c'est le gestionnaire de paquet de ta distrib.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
Un défaut de sécurité, c'est le quotidien de tout producteur de logiciel, le RGPD ne dit pas que tu ne dois jamais avoir de faille, sinon ce serait impossible de distribuer le moindre bout de soft.
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Ce n'est pas parce que Delta Chat héberge ses sources chez Github que Github devient co/sous-traitant du logiciel au sens de cette règlementation.
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
monter/trouver un miroir de github pour virer Microsoft pour auditer le code (violation Schrems II)
passer un doctorat en crypto pour comprendre que la vérification de signature préconisé ne fait rien du tout (défaut de sécurité et de contrôle de la supply chain)
devoir corriger des CVE en migrant sur une version décente de Electron (défaut de sécurité et défaut de suivi obsolescence logicielle)
devoir en fait tout recoder pour virer Electron carrément et donc Google
J’ai pas encore testé, mais je suppose que va aussi :
me falloir monter un miroir de npm.js pour virer Cloudflare (violation Schrems II)
me falloir monter un miroir de crate.io pour virer AWS (violation Schrems II)
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
OK
$ echo "\n" >> com.b44t.messenger_6774.apk
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
KO
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
La DSP2 impose dorénavant une authentification dite contextuelle. C’est-à-dire que techniquement, celui qui va valider l’OTP ne doit avoir aucun moyen d’ignorer l’action réalisée (s’authentifier, payer, ajouter un bénéficiaire…), le montant et le destinataire éventuel. Et le système doit être robuste à un « man-in-the-middle physique » par ton voisin de bureau (en gros éviter qu’il soit facile de dire « eh Truc, tu peux valider/me donner ton OTP pour 20€ chez la FNAC » alors que c’est un achat de 1000€ chez AliExpress).
Les moyens offline ne le permettent pas ou vraiment pas facilement, et les systèmes matériels dédiés deviennent trop coûteux (scan d’un qrcode, connexion bluetooth ou wifi pour récupérer l’info, écran plus avancé qu’un afficheur 6× 7 segments, etc). Tu passes de machin débile avec 3 transistors qui se battent en duel à moins de 10€ pièce à des mini-PC avec RAM, puce wifi/caméra et OS à plus de 100€ l’unité.
D’où le recours aux téléphones, qui coûtent pas cher aux banques, dispo partout, facilement mettable à jour…
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 03 septembre 2024 à 19:29.
C’est bien pour ça que le SMS n’est plus reconnu comme valide comme facteur de possession depuis quelques années et que l’authenfication du téléphone nécessite bien souvent un facteur biométrique supplémentaire
Le chiffrement du message ne garantit pas que le détenteur de la clef est bien devant le téléphone. C’est de toute façon exclusivement de la confidentialité et non de l’authentification justement.
Et il n’existe pas d’action réalisable par le destinataire supposé qui ne soit pas réalisable par le destinataire réel. La 2FA est justement là pour se prémunir du 1er, et non pas seulement du 2nd. C’est pour ça par exemple que le facteur de possession de la 2FA bancaire impose des mécanismes obligeant le propriétaire souhaité à faire une action dont il doit forcément avoir conscience, y compris en cas de man-in-the-middle physique.
Et c’est très difficile à faire dans un environnement décentralisé sans point central comme peut l’être une banque.
Si les banques se sont repliés vers les téléphones mobiles, c’est pas vraiment pour rien, et surtout après s’être fait dégommé la totalité des autres moyens d’authenfication par l’EBA…
On s’attaque réellement à des problèmes durs dont il n’y a pas de solution simple à mettre en œuvre, et dans un contexte « libre, décentralisé, etc » la difficulté est au moins de 2 voire 3 ordres de grandeur supplémentaires (qui est responsable en cas de merde, les certifications, l’interdiction de modification d’un système certifié, tiers de confiance, etc)
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
Et propose 2 alternatives (mail et SMS) qui sont de facto non légalement recevable en l’état de la loi (SIM swap et interception mail). Ces 2 moyens ne sont plus reconnus comme des facteurs de possession depuis plusieurs années mais réduit à un facteur de connaissance.
Toute la difficulté est actuellement là : les facteurs de possession nécessitent aujourd’hui des moyens technologiques pour être mis en œuvre (en tout cas dans des délais de vérification pas trop long)
[^] # Re: Les solutions techniques
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1.
Non contextuel, donc non utilisable dans le cadre de la DSP2 par exemple.
[^] # Re: internet plutôt que téléphone portable
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 5.
2 voire 3 des conditions sont difficilement possibles pour la DSP2 par exemple, et c’est globalement pareil pour les autres besoins
ouvertes : Les obligations de certifications sont assez incompatibles avec ce concept, toute modification du système devant être strictement impossible. Ça rend l’ouverture rapidement inutile ou n’apportant rien réellement au système
standard : L’intégration nécessite un accès privilégié aux SI des banques (2FA dite « contextuelle » nécessitant d’obtenir des informations type action/montant/destinataire), difficile d’y mettre en œuvre des trucs « standard », chacun devant développer sa couche d’intégration et préfère du coup faire du custom à sa sauce que de chercher une interface commune avec tout le monde.
accessibles : Lié au 1er point, la certification des solutions d’authentification coûte (très) chère, en particulier en terme d’assurance (qu’est-ce qu’on doit possiblement payer/rembourser si le système merde vu qu’on en endosse la responsabilité). Du coup double problème pour avoir un système « accessible ». Avoir suffisamment de part de marché pour rendre intéressant de certifier un système par les banques par exemple, et de l’autre côté difficulté à financer la certification pour les systèmes non pris en charge par les précédents.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2.
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2.
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3.
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0.
Il me semble que ça a été corrigé depuis, mais Tchap avait été livré sans aucune réflexion en amont… 1h15 après sa publication, il était déjà pété : https://www.lepoint.fr/high-tech-internet/tchap-il-m-a-suffi-de-1-h-15-pour-trouver-la-faille-de-securite-06-05-2019-2311048_47.php
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3. Dernière modification le 21 février 2024 à 19:40.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2. Dernière modification le 21 février 2024 à 19:35.
C'ert surtout que c'est marqué « ainsi que » dans le texte cité…
C'est tout traitement auto de DCP ou tout traitement non auto d'un fichier de DCP. Fichier étant au sens général (un post-it est un fichier).
Curl et cie c'est le 1.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0.
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2.
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3.
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1.
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
À ceux qui répondrait que je peux récupérer le code sur le site de delta-chat : l’archive n’est pas signée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -3.
Donc pour résumer avant d’utiliser delta-chat :
J’ai pas encore testé, mais je suppose que va aussi :
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
Alors que bon, avec apksigner
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
D’ailleurs y’a même encore plus simple pour le prouver…
YOLO