Non, tu ne peux pas installer tes propres certificats. ’fin ça ne fonctionne pas quoi.
Une banque ne se protégera pas avec un certificat qui n’est pas reconnu out-of-the-box par la majorité des navigateurs du monde. Et ne demandera certainement pas à ses utilisateurs d’installer un certificat random pas reconnu (ça casserait de facto la sécurité).
Et toute la question est là. Une banque n’utilisera pas un certificat/une clef de signature Android qui n’est pas massivement reconnue par tous.
Tu peux faire ta PKI tout seul dans ton coin, mais tu ne peux pas faire de la prod réelle avec des gens non techniques (et pire, avec une sécurité correcte) avec un certificat non reconnu par les navigateurs. Et ça, le libre n’y peut rien.
Dans les autres domaines (DRM dans la musique et la vidéo, protections des consoles, secureboot), toute cette belle théorie s'est toujours fait troué le slip par la pratique.
Absolument pas. TLS et x509 est même la démonstration que « ça marche » et à très grande échelle.
Le problème est « comment devenir une racine de confiance ». Il aura fallu 40 ans à Let's Encrypt pour s’y faire une place. Et très clairement le libre n’y aura eu AUCUNE place pour le coup.
Et avant qu’on ne me tombe dessus, il faut entendre par là que les propriétés du libre n’y ont été d’aucune utilité et n’y sont juste pas possible en pratique. Tu auras beau avoir le code source de LE, pouvoir recompiler le logiciel, pouvoir le redistribuer, tu ne pourras pas refaire LE parce que tu n’es pas une root CA. Et si tu modifies la moindre ligne, tu as toute la certification de LE à repasser pour être à nouveau une root CA.
On n’est pas du tout en train de parler de backdoor, interception, droit root partout & cie qui sont effectivement le rêve humide de la DGSI.
On est juste en train de parler de chaîne de confiance et surtout de racine de confiance et de reconnaissance par les pairs et SURTOUT par les tiers. Et que le libre n’a JAMAIS été capable de mettre en place correctement et ce depuis GPG.
Techniquement : on sait faire sans passer par Google et Apple. Faut « juste » refaire ce que Google fait avec Play Integrity ou ce que Apple fait avec App Attest. C’est de la crypto & cie basique, rien de folichon.
Le problème est après : passer la certif pour arriver à avoir ton attestation approuvée par les banques, et intégrer par les banques. Là déjà, c’est un peu plus coton.
Le faire tout en conservant le côté « libre » des outils : là on est carrément plus proche du mission impossible. Ça suppose aussi de ne pas avoir d’OS rooté de possible par exemple, et que ton OS est qualifié et qu’un utilisateur standard ne doit pas pouvoir le modifier/builder/déployer sans faire sauter la certification.
En fait le problème est le même (en pire) que les autorités de certification de ton navigateur. N’importe qui peut faire la sienne et l’utiliser, éventuellement l’échanger un peu avec le copain d’à côté (CACert). Peu auront la chance de finir dans /etc/ssl/ca-certificates.crt dans Debian ou d’être intégré aux navigateurs. Les process pour y arriver sont trop chers, contraignants, avec des risques assurantiels ou juridiques très importants, du matériel hors de prix à acquérir (HSM…), des salles serveurs sécurisées à mettre en place, des audits annuels à financer et à assurer…
GrapheneOS a typiquement déjà pas mal avancé le boulot mais il faudrait maintenant passer les certifications et inciter les banques à intégrer ce nouveau SDK.
Pour résumer plus simplement, la 2FA niveau bancaire n’est pas que la vérification par le serveur de l’OTP en lui-même, mais aussi la vérification par le serveur du client-même ayant généré l’OTP.
Afin de s’assurer de l’intégrité de toute la chaîne et que le serveur puisse avoir effectivement une bonne certitude de ce qui s’est réellement passé, et en particulier de ce qui aura été affiché par le client.
Pour que la banque puisse avoir une vraie preuve recevable en justice que Mr Machin ne pouvait qu’avoir bien conscience de valider un paiement de 1000€ à AliExpress quand il a validé l’OTP. Avec TOTP tout seul, tu pourrais dire à la banque « ah non, moi j’ai validé 10€ et à Amazon ».
L’OTP seul est limite un élément accessoire dans toute la chaîne.
Que le serveur puisse avoir la garantie que les données contextuelles ont bien été présentées non altérées à celui qui a validé l’OTP est vraiment la partie difficile où le libre n’a pas vraiment de réponse technique viable possible en tout cas actuellement.
Quand tu valides un OTP, ce n’est bien entendu pas le client qui fait la vérification mais le serveur.
La clef est générée côté serveur, est envoyé côté client par un canal CERTIFIÉ à une application CERTIFIÉ (par Google/Apple), qui la stocke dans une enclave CERTIFIÉE géré par un OS CERTIFIÉ et reçoit un token CERTIFIÉ crypto.
Le serveur envoie à ton application (certifiée) les données de contexte (action, montant, destinataire…)
Ton application (certifiée) garantie à la banque que ces données :
ne seront pas altérées
s’afficheront à l’endroit certifié, connu et garanti par la banque, à côté de l’OTP
Ton application (certifiée) transmet à la banque l’OTP, avec une empreinte crypto généré par l’OS (certifié) prouvant que l’application était légitime, non modifiée, et correspondait bien à celle attendue par ta banque
Ta banque vérifie alors À LA FOIS que l’OTP est valide, que ton device est bien celui attendu (signature crypto de ton application avec le token crypto généré à l’enrollement), ET que ton téléphone était safe (signature crypto réalisé par ton OS de l’authenticité de l’application.
La banque a donc la certitude, et la preuve, que :
tu as bien reçu la demande d’OTP et les données contextuelles
ton application était légitime et correspondait à celle fournit par ta banque (pas de modif logiciel)
ton OS était légitime et correspondait à celui livré par ton fournisseur (Google ou Apple)
tu as bien validé l’OTP (2nd facteur d’auth, bio ou code) avec les données nécessairement contextuelles affichées
1+2+3 permet à la banque de certifier que tu as nécessairement eu connaissance des données du 1, affiché exactement à l’endroit attendu, sous la forme attendue, et comme prouvable par le code source détenu par elle, par le téléphone enrollé attendu, 4 que c’était bien toi
La banque peut donc valider l’OTP
Si tu n’as pas 2 et 3, la banque ne peut plus en déduire 4, la 2FA n’est plus valide.
La seule et unique problématique du libre est 2 (incompatible avec le libre) et 3 (difficile à mettre en œuvre sur des OS libres puisqu’il faut les faire certifier et avec une certification reconnue par les banques).
L’existant « bien fait » suppose de revoir la loi. La question n’est pas du tout technique, mais juridique. Et actuellement les choix juridiques ne me semblent pas si déconnants que ça. La fraude a réellement été massive avant l’entrée en vigueur de la DSP2 et je pense que plus ou moins personne ici ne serait content de se faire pouiller son compte en banque sans avoir rien à dire ou à voir ses frais bancaires explosés si la banque devait prendre la fraude à sa charge.
Je suis client, je m'en balec de l'avis de la banque :-)
Oui, sauf que là on est en train de jouer aussi ta responsabilité pénale et financière hein… 🤷 On ne parle pas que de sécurité.
Un OTP légalement valide implique ta responsabilité pleine et entière, en terme pénal et financier.
Un OTP invalide implique celle pleine et entière de la banque.
Tu peux détailler pourquoi tu penses que "lien opération/montant/destinataire" n'est pas établi avec webauthn/TOTP ? (Sachant que les applis mobiles utilisent les mêmes principes…).
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire…).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié…).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles…), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça…).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, etc.
Les téléphones se cassent ou se perdent. On peut même ajouter qu'un téléphone n'est PAS un périphérique de confiance.
La question n’est pas là. Mais que tu as beaucoup plus de chance de prendre soin d’un truc dorénavant omniprésent dans l’intégralité de ta vie quotidienne (à tord ou à raison) que d’un truc qui ne va te servir que 2× dans le mois.
Et le « vrai » problème est surtout le côté « urgence » ou en tout cas non planifié de l’usage de la 2FA. Les périphériques dédiés sont justement dédiés et restreints à un cas d’usage souvent très limité (uniquement chez soi par exemple).
Tu ne peux pas non plus te permettre de te trimballer en permanence avec une valise de matériel dédié sur toi pour chaque usage. Personnellement j’ai 4 banques différentes par la force des choses, et je suis loin d’être le seul (37% de la population a au moins 2 banques).
C’est le côté pratique/omniprésent/dispo partout et en toute circonstance qui fait que le téléphone est plutôt une bonne idée.
On espère toujours ne pas être touché par cette situation, mais par exemple en cas de fraude, un conseiller peut te demander de t’authentifier par 2FA (Boursorama le fait ou en tout cas l’a fait par exemple). Tu n’as pas ton device sur toi ? T’es juste en train de te faire démolir ton compte par un escroc et ton conseiller ne peut pas bloquer les paiements sans ta 2FA. Au contraire le paiement est légitime et la banque suspecte une fraude et l’a bloqué ? Ton conseiller ne le laissera au contraire pas passer sans ton authentification. Ça peut être vite compliqué.
Tu as le plus confiance en quoi? Un téléphone facile à voler avec un android ou pire un iOS privateur et des services tout aussi privateurs ? Un PC de bureau ou un portable avec antivol et un vrai GNU/linux OS libre ?
La question n’est pas ce que TOI tu as le plus confiance mais ce en quoi LA BANQUE a le plus confiance. Cet OTP engage sa responsabilité pénale et financière de ta banque et justement pas (que) la tienne. Si tu parviens à prouver que l’OTP de ta banque ne répond pas aux principes de sécurité légaux, alors ta responsabilité est justement reporté sur la banque (un traitement validé par OTP légal rend irréfutable la responsabilité du client).
Et le problème est là : une banque ne PEUT PAS utiliser un système dont elle n’aurait pas la certification (et les assurances qui vont avec) sur la sécurité du système. Google et Apple les leur apporte. GNU/Linux non.
Et le vol est typiquement inclut dans les modèles de menace des systèmes de 2FA sur mobile (authentification par biométrie ou code personnel nécessaire). C’est bien de la 2FA et non de la 1FA, le seul facteur de possession ne suffisant pas et ne devant pas suffire à valider l’authentification et est couplé à un facteur de connaissance (code) ou d’identité (biométrie).
Je le répète : si les banques aiment les applis mobiles, ce n'est pas pour la sécurité.
Ce n’est pas non plus ce que j’ai dit. C’est essentiellement pour des critères de responsabilité/certification, de contrôle logiciel, et d’assurance. Couplé à des critères de tarif, de disponibilité, de facilité d’accès, de maintenance, etc.
Tout ça mélangé rend le choix du téléphone mobile pas si déconnant en pratique, même si effectivement pose quelques problèmes pour certains cas.
Et à l’inverse les solutions libres ou sur OS libre ou… ne répondent que difficilement aux exigences légales posés (certification, non modification du système, confiance de la banque en le système, contextualisation…).
La BNP propose toujours le MFA par SMS + code secret, donc non toutes les solutions ne sont pas hors jeux.
La BNP est dans l’illégalité (SMS plus reconnu comme 2FA + authentification non contextuelle) et se prend ou se prendra des prunes pour ça et ce système disparaîtra à terme.
C’est un truc qui est effectivement envisageable a priori, mais ça coûte cher et c’est chiant à gérer autant pour les banques que pour les clients. Faut le trimbaler partout avec soit, ça casse, c’est chiant en vacances, etc… Les gens en prennent beaucoup moins soin que leur téléphone, l’oubli, le perde…
Typiquement t’es au boulot, tu veux faire un paiement ou te connecter sur le site de ta banque ? C’est mort, t’as pas ton device…
Et tu le paies 30€. Des téléphones android « bas de gamme » coûtent à peine plus chers pour le coup…
Ça n’impose pas de téléphone, mais le fait que le périphérique soit nécessairement connecté pour traiter la partie dynamique a poussé les banques à passer sur téléphone, le matériel dédié devenant hors de prix et complexe à mettre en œuvre (maintenance, livraison, etc).
Le côté privateur vient avec l’obligation de certification des mécanismes de sécurité, et actuellement seuls les gros (Google et Apple) les ont passé. Et la certification impose « by design » du privateur, ou en tout cas que même un logiciel libre ne puisse pas être modifié (même problème que celui qui s’était posé avec les logiciels de caisse).
Et le côté non standard avec le fait que le système nécessite du coup des interactions avec les SI des banques, qui couplé avec le § précédent rend compliqué d’avoir à passer par un système tiers à certifier ou non certifié, et encore pire sur un système peu courant ou peu contrôler comme Linux (Microsoft ou Apple peuvent éventuellement certifier les softs installés)…
Les banques engagent quand même leur responsabilité pénale et financière sur cette authentification…
Et sur le lien cité, là par contre c’est une interprétation. Le texte réglementaire ne dit pas ça et les propos ne concernait qu’une initiative privée d’un sous-ensemble de prestataire FR (les établissements de la Place française, portés par la Banque de France), le tout nécessitant toujours dans tous les cas de respecter les autres points des articles de la directive (dynamique, certifié, etc).
Toutes les solutions hors téléphone ont fini par se faire dégager pour des raisons de non conformité avec la législation, et à ma connaissance la Banque de France a justement fini par virer cette obligation de fourniture d’un moyen autre.
[…] Le dispositif utilisé pour initier l’opération de paiement […], devraient, par conséquent, inclure l’authentification des opérations par des codes dynamiques, afin que l’utilisateur soit à tout moment conscient du montant et du bénéficiaire de l’opération qu’il autorise.
Article 97(2) de la DSP2
En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.
Donc non, ce n’est même pas une interprétation, c’est écrit en dur explicitement dans la directive.
Pour l’anecdote, on rappellera quand même qu’un système est légalement obligé de supporter l’orthographe correct des noms. Sinon violation de l’article 16 du RGPD.
Une banque a déjà été contrainte par une Autorité de Contrôle à modifier tout son système d’information pour supporter les accents. 😊
C’est un peu plus compliqué que juste avoir une clef et la stocker… Cf ici.
Du coup il y a de la communication sécurisée avec leurs backends bancaires, du push notif pour déclencher la 2FA sans exploser ta batterie avec du polling, de la certification de l’OS pour éviter les systèmes compromis (obligation légale, qui explique le recours à Google et Apple pour la couche de sécu)…
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.
# Celui-là ?
Posté par Aeris (site web personnel) . En réponse au journal L’informatique, ce truc de jeune (!?). Évalué à 10 (+9/-0).
https://lunatopia.fr/blog/les-gamins-ne-savent-pas-utiliser-les-ordinateurs
[^] # 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. Dernière modification le 14 septembre 2024 à 20:54.
Non, tu ne peux pas installer tes propres certificats. ’fin ça ne fonctionne pas quoi.
Une banque ne se protégera pas avec un certificat qui n’est pas reconnu out-of-the-box par la majorité des navigateurs du monde. Et ne demandera certainement pas à ses utilisateurs d’installer un certificat random pas reconnu (ça casserait de facto la sécurité).
Et toute la question est là. Une banque n’utilisera pas un certificat/une clef de signature Android qui n’est pas massivement reconnue par tous.
Tu peux faire ta PKI tout seul dans ton coin, mais tu ne peux pas faire de la prod réelle avec des gens non techniques (et pire, avec une sécurité correcte) avec un certificat non reconnu par les navigateurs. Et ça, le libre n’y peut rien.
[^] # 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. Dernière modification le 14 septembre 2024 à 00:11.
Absolument pas. TLS et x509 est même la démonstration que « ça marche » et à très grande échelle.
Le problème est « comment devenir une racine de confiance ». Il aura fallu 40 ans à Let's Encrypt pour s’y faire une place. Et très clairement le libre n’y aura eu AUCUNE place pour le coup.
Et avant qu’on ne me tombe dessus, il faut entendre par là que les propriétés du libre n’y ont été d’aucune utilité et n’y sont juste pas possible en pratique. Tu auras beau avoir le code source de LE, pouvoir recompiler le logiciel, pouvoir le redistribuer, tu ne pourras pas refaire LE parce que tu n’es pas une root CA. Et si tu modifies la moindre ligne, tu as toute la certification de LE à repasser pour être à nouveau une root CA.
On n’est pas du tout en train de parler de backdoor, interception, droit root partout & cie qui sont effectivement le rêve humide de la DGSI.
On est juste en train de parler de chaîne de confiance et surtout de racine de confiance et de reconnaissance par les pairs et SURTOUT par les tiers. Et que le libre n’a JAMAIS été capable de mettre en place correctement et ce depuis GPG.
[^] # 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 13 septembre 2024 à 17:53.
Techniquement : on sait faire sans passer par Google et Apple. Faut « juste » refaire ce que Google fait avec Play Integrity ou ce que Apple fait avec App Attest. C’est de la crypto & cie basique, rien de folichon.
Le problème est après : passer la certif pour arriver à avoir ton attestation approuvée par les banques, et intégrer par les banques. Là déjà, c’est un peu plus coton.
Le faire tout en conservant le côté « libre » des outils : là on est carrément plus proche du mission impossible. Ça suppose aussi de ne pas avoir d’OS rooté de possible par exemple, et que ton OS est qualifié et qu’un utilisateur standard ne doit pas pouvoir le modifier/builder/déployer sans faire sauter la certification.
En fait le problème est le même (en pire) que les autorités de certification de ton navigateur. N’importe qui peut faire la sienne et l’utiliser, éventuellement l’échanger un peu avec le copain d’à côté (CACert). Peu auront la chance de finir dans /etc/ssl/ca-certificates.crt dans Debian ou d’être intégré aux navigateurs. Les process pour y arriver sont trop chers, contraignants, avec des risques assurantiels ou juridiques très importants, du matériel hors de prix à acquérir (HSM…), des salles serveurs sécurisées à mettre en place, des audits annuels à financer et à assurer…
GrapheneOS a typiquement déjà pas mal avancé le boulot mais il faudrait maintenant passer les certifications et inciter les banques à intégrer ce nouveau SDK.
[^] # 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 13 septembre 2024 à 16:40.
Pour résumer plus simplement, la 2FA niveau bancaire n’est pas que la vérification par le serveur de l’OTP en lui-même, mais aussi la vérification par le serveur du client-même ayant généré l’OTP.
Afin de s’assurer de l’intégrité de toute la chaîne et que le serveur puisse avoir effectivement une bonne certitude de ce qui s’est réellement passé, et en particulier de ce qui aura été affiché par le client.
Pour que la banque puisse avoir une vraie preuve recevable en justice que Mr Machin ne pouvait qu’avoir bien conscience de valider un paiement de 1000€ à AliExpress quand il a validé l’OTP. Avec TOTP tout seul, tu pourrais dire à la banque « ah non, moi j’ai validé 10€ et à Amazon ».
L’OTP seul est limite un élément accessoire dans toute la chaîne.
Que le serveur puisse avoir la garantie que les données contextuelles ont bien été présentées non altérées à celui qui a validé l’OTP est vraiment la partie difficile où le libre n’a pas vraiment de réponse technique viable possible en tout cas actuellement.
[^] # 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.
Tu ne comprends en effet toujours pas.
Quand tu valides un OTP, ce n’est bien entendu pas le client qui fait la vérification mais le serveur.
La clef est générée côté serveur, est envoyé côté client par un canal CERTIFIÉ à une application CERTIFIÉ (par Google/Apple), qui la stocke dans une enclave CERTIFIÉE géré par un OS CERTIFIÉ et reçoit un token CERTIFIÉ crypto.
La banque a donc la certitude, et la preuve, que :
tu as bien validé l’OTP (2nd facteur d’auth, bio ou code) avec les données nécessairement contextuelles affichées
1+2+3 permet à la banque de certifier que tu as nécessairement eu connaissance des données du 1, affiché exactement à l’endroit attendu, sous la forme attendue, et comme prouvable par le code source détenu par elle, par le téléphone enrollé attendu, 4 que c’était bien toi
La banque peut donc valider l’OTP
Si tu n’as pas 2 et 3, la banque ne peut plus en déduire 4, la 2FA n’est plus valide.
La seule et unique problématique du libre est 2 (incompatible avec le libre) et 3 (difficile à mettre en œuvre sur des OS libres puisqu’il faut les faire certifier et avec une certification reconnue par les banques).
[^] # 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.
L’existant « bien fait » suppose de revoir la loi. La question n’est pas du tout technique, mais juridique. Et actuellement les choix juridiques ne me semblent pas si déconnants que ça. La fraude a réellement été massive avant l’entrée en vigueur de la DSP2 et je pense que plus ou moins personne ici ne serait content de se faire pouiller son compte en banque sans avoir rien à dire ou à voir ses frais bancaires explosés si la banque devait prendre la fraude à sa charge.
[^] # 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 13 septembre 2024 à 15:01.
Oui, sauf que là on est en train de jouer aussi ta responsabilité pénale et financière hein… 🤷 On ne parle pas que de sécurité.
Un OTP légalement valide implique ta responsabilité pleine et entière, en terme pénal et financier.
Un OTP invalide implique celle pleine et entière de la banque.
[^] # 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.
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire…).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié…).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles…), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça…).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, 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.
La question n’est pas là. Mais que tu as beaucoup plus de chance de prendre soin d’un truc dorénavant omniprésent dans l’intégralité de ta vie quotidienne (à tord ou à raison) que d’un truc qui ne va te servir que 2× dans le mois.
Et le « vrai » problème est surtout le côté « urgence » ou en tout cas non planifié de l’usage de la 2FA. Les périphériques dédiés sont justement dédiés et restreints à un cas d’usage souvent très limité (uniquement chez soi par exemple).
Tu ne peux pas non plus te permettre de te trimballer en permanence avec une valise de matériel dédié sur toi pour chaque usage. Personnellement j’ai 4 banques différentes par la force des choses, et je suis loin d’être le seul (37% de la population a au moins 2 banques).
C’est le côté pratique/omniprésent/dispo partout et en toute circonstance qui fait que le téléphone est plutôt une bonne idée.
On espère toujours ne pas être touché par cette situation, mais par exemple en cas de fraude, un conseiller peut te demander de t’authentifier par 2FA (Boursorama le fait ou en tout cas l’a fait par exemple). Tu n’as pas ton device sur toi ? T’es juste en train de te faire démolir ton compte par un escroc et ton conseiller ne peut pas bloquer les paiements sans ta 2FA. Au contraire le paiement est légitime et la banque suspecte une fraude et l’a bloqué ? Ton conseiller ne le laissera au contraire pas passer sans ton authentification. Ça peut être vite compliqué.
La question n’est pas ce que TOI tu as le plus confiance mais ce en quoi LA BANQUE a le plus confiance. Cet OTP engage sa responsabilité pénale et financière de ta banque et justement pas (que) la tienne. Si tu parviens à prouver que l’OTP de ta banque ne répond pas aux principes de sécurité légaux, alors ta responsabilité est justement reporté sur la banque (un traitement validé par OTP légal rend irréfutable la responsabilité du client).
Et le problème est là : une banque ne PEUT PAS utiliser un système dont elle n’aurait pas la certification (et les assurances qui vont avec) sur la sécurité du système. Google et Apple les leur apporte. GNU/Linux non.
Et le vol est typiquement inclut dans les modèles de menace des systèmes de 2FA sur mobile (authentification par biométrie ou code personnel nécessaire). C’est bien de la 2FA et non de la 1FA, le seul facteur de possession ne suffisant pas et ne devant pas suffire à valider l’authentification et est couplé à un facteur de connaissance (code) ou d’identité (biométrie).
Ce n’est pas non plus ce que j’ai dit. C’est essentiellement pour des critères de responsabilité/certification, de contrôle logiciel, et d’assurance. Couplé à des critères de tarif, de disponibilité, de facilité d’accès, de maintenance, etc.
Tout ça mélangé rend le choix du téléphone mobile pas si déconnant en pratique, même si effectivement pose quelques problèmes pour certains cas.
Et à l’inverse les solutions libres ou sur OS libre ou… ne répondent que difficilement aux exigences légales posés (certification, non modification du système, confiance de la banque en le système, contextualisation…).
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 3. Dernière modification le 13 septembre 2024 à 12:15.
La BNP est dans l’illégalité (SMS plus reconnu comme 2FA + authentification non contextuelle) et se prend ou se prendra des prunes pour ça et ce système disparaîtra à terme.
C’est un truc qui est effectivement envisageable a priori, mais ça coûte cher et c’est chiant à gérer autant pour les banques que pour les clients. Faut le trimbaler partout avec soit, ça casse, c’est chiant en vacances, etc… Les gens en prennent beaucoup moins soin que leur téléphone, l’oubli, le perde…
Typiquement t’es au boulot, tu veux faire un paiement ou te connecter sur le site de ta banque ? C’est mort, t’as pas ton device…
Et tu le paies 30€. Des téléphones android « bas de gamme » coûtent à peine plus chers pour le coup…
Non conforme (non contextuel), ils doivent se prendre des amendes aussi du coup, et ça disparaîtra à terme
Comme expliqué, le côté lien dynamique (lien opération/montant/destinataire) interdit légalement ce type de solution.
[^] # 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 13 septembre 2024 à 11:13.
Ça n’impose pas de téléphone, mais le fait que le périphérique soit nécessairement connecté pour traiter la partie dynamique a poussé les banques à passer sur téléphone, le matériel dédié devenant hors de prix et complexe à mettre en œuvre (maintenance, livraison, etc).
Le côté privateur vient avec l’obligation de certification des mécanismes de sécurité, et actuellement seuls les gros (Google et Apple) les ont passé. Et la certification impose « by design » du privateur, ou en tout cas que même un logiciel libre ne puisse pas être modifié (même problème que celui qui s’était posé avec les logiciels de caisse).
Et le côté non standard avec le fait que le système nécessite du coup des interactions avec les SI des banques, qui couplé avec le § précédent rend compliqué d’avoir à passer par un système tiers à certifier ou non certifié, et encore pire sur un système peu courant ou peu contrôler comme Linux (Microsoft ou Apple peuvent éventuellement certifier les softs installés)…
Les banques engagent quand même leur responsabilité pénale et financière sur cette authentification…
Et sur le lien cité, là par contre c’est une interprétation. Le texte réglementaire ne dit pas ça et les propos ne concernait qu’une initiative privée d’un sous-ensemble de prestataire FR (les établissements de la Place française, portés par la Banque de France), le tout nécessitant toujours dans tous les cas de respecter les autres points des articles de la directive (dynamique, certifié, etc).
Toutes les solutions hors téléphone ont fini par se faire dégager pour des raisons de non conformité avec la législation, et à ma connaissance la Banque de France a justement fini par virer cette obligation de fourniture d’un moyen autre.
[^] # 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.
Pour le cas des banques, en tout cas ça l’est
https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4039
[^] # 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.
https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX%3A32015L2366%3Afr%3AHTML
Considérant 95 de la DSP2
[…] Le dispositif utilisé pour initier l’opération de paiement […], devraient, par conséquent, inclure l’authentification des opérations par des codes dynamiques, afin que l’utilisateur soit à tout moment conscient du montant et du bénéficiaire de l’opération qu’il autorise.
Article 97(2) de la DSP2
En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.
Donc non, ce n’est même pas une interprétation, c’est écrit en dur explicitement dans la directive.
# Violation RGPD
Posté par Aeris (site web personnel) . En réponse au journal Les caractères accentués dans les logiciels d'ENT. Évalué à 10.
Pour l’anecdote, on rappellera quand même qu’un système est légalement obligé de supporter l’orthographe correct des noms. Sinon violation de l’article 16 du RGPD.
Une banque a déjà été contrainte par une Autorité de Contrôle à modifier tout son système d’information pour supporter les accents. 😊
https://gdprhub.eu/index.php?title=Court_of_Appeal_of_Brussels_-_2019/AR/1006
[^] # 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 11 septembre 2024 à 19:33.
C’est un peu plus compliqué que juste avoir une clef et la stocker… Cf ici.
Du coup il y a de la communication sécurisée avec leurs backends bancaires, du push notif pour déclencher la 2FA sans exploser ta batterie avec du polling, de la certification de l’OS pour éviter les systèmes compromis (obligation légale, qui explique le recours à Google et Apple pour la couche de sécu)…
[^] # 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.