xryl669 a écrit 94 commentaires

Je ne vois aucun lien vers le code source pour MediaInfo. La page dit bien que c'est open source, mais ça doit être une licence en open source si tu les trouves, ou un truc comme ça.

Exactement. La vrai différence entre le natif et le pas natif, c'est que le natif utilisant les fonctions du système, s'intègre parfaitement avec toutes les fonctions du système, comme le lecteur audio TTS pour ceux qui ont des soucis à la lecture (et STT pour les inputs), l'IME, les gestionnaires de mots de passe, le presse papier, le bon skin quelque soit le thème choisi, le dictionnaire et la correction automatique, le ClearView dépendant de l'écran choisi, les bonnes fontes, etc…

Et là, je ne parle que des zones de texte, mais le même problème s'applique au checkbox, les progress bars, qui peuvent et sont automatisées (il y a des utilitaires qui surveillent les progress bars et peuvent éteindre l'ordi lorsqu'elle est arrivé à complétion sous Windows).

Le pire, c'est que le web comme vous dîtes, est super bien intégré avec les widgets natifs, justement et que quasiment tout ce que j'ai cité là au dessus fonctionne dans un navigateur, et sous Electron / Tauri et autre.

Bref, pour faire un soft cross platform qui fonctionne le mieux pour tous, la solution Electron ou Tauri, ou, à la limite, iced sous Rust qui utilise tous le modèle DOM (qui est donc super connu, débuggé, sans surprises et facile à recruter pour les développeurs).

Je pense donc qu'un nouvel entrant dans ce but, c'est mort né (sauf peut être si basé sur Servo histoire d'avoir une taille de binaire non délirante et de pas avoir 10 versions de webkit installé sur une machine).

Il reste donc l'interface graphique pour l'embarqué (où LVGL existe avec Squareline comme éditeur graphique et générateur de code), et l'immediate mode type egui sous Rust (qui présente les mêmes défauts que Slint, mais c'est plus ancien et mieux intégré, la plupart des bugs sont résolus)

Contrairement à ce qui est écrit, l'interface est tout sauf native. C'est du dessiné, comme GTK, QT et autre.

Par exemple, faîtes un click droit sur une zone texte, et vous n'aurez pas le menu classique de copier/coller des zones de texte.

Il émule l'UI native, pour ressembler à l'interface de l'hôte. Mais ça foire complètement sur les hôtes qui ne sont un minimum customisés. Donc sous Linux avec ses 10000 environnements graphiques, vous aurez du pseudo GTK, thème de base. Sous windows, faut pas avoir choisi un thème sombre, etc…

Sur le web, les zones textes ne supportent pas le copier/coller, les IME, etc..
Sur la version mobile de la démo web (et que sur celle-ci, pourquoi?) il utilise un truc pas kocher du tout: il met un < input > caché sous le canvas de dessin. Il donne le focus à l'input lorsqu'une zone de texte est sélectionné, pour faire apparaître le clavier virtuel.

Sauf que c'est toujours le même input quelque soit la zone de texte dans l'interface, donc exit tous les automatismes, genre gestionnaire de mots de passe, autofill, etc…

En gros, sauf pour l'embarqué, c'est assez inutile. Et pour l'embarqué, il y a LVGL qui est quand même LA référence.

Ça utilise weboob (web out of browser), qui est techniquement un web scraper. C'est à dire que ça simule un utilisateur qui se connecte via l'interface web de la banque.

Attention à ne pas les mettre à jour, car avec les derniers firmwares, l'imprimante ignorera la calibration de position des toner pour les cartouches compatibles.

J'ai la mienne depuis 2010, aucun problème, utilisée quotidiennement. Mise à jour par ma fille parce que l'imprimante lui disait de le faire.

Bam, impossible d'avoir une impression correcte depuis, les couleurs sont nickel en haut de page, mais bavent en bas. Impossible de recalibrer, l'imprimante ignore le résultat de la calibration puisque j'ai des toner compatibles.

Il faudrait revenir à une version antérieure du firmware, sauf que je ne sais plus quelle version elle avait.

Bref, manœuvre douteuse de la part de Brother qui fait que plus personne dans mon entourage n'achètera cette marque à l'avenir. Bravo Brother qui préfère avoir 0% de énormément que 80% de beaucoup!

Je plussois. Entre l'article qui confond puissance (W) et consommation (J), et le préjugé sur le temps de chauffe, je ne peux que conseiller à l'auteur de comprendre que 1000W pendant 1ms consomme moins que 10W pendant 1s.

De plus, ceux qui ont démonté une telle imprimante verront que ce n'est pas le laser qui est utilisé pour chauffer (car là, le laser, ça a un rendement pourri, 30% au maximum), mais une bête lampe à incandescence emprisonnée dans une tube en métal peint en noir (appelé fuser)

Sur les nouvelles imprimantes "laser", ils utilisent maintenant des diodes (plus du laser, car meilleur rendement)

Par contre, dans les nouvelles versions de firmware de Brother sur les imprimantes lasers, ils ont désactivé la calibration de position des têtes d'impressions pour les cartouches compatibles. Résultat, ça marche avec des cartouches compatibles (10x moins chères) mais les couleurs bavent (et ceux malgré les multiples tentatives de calibration réalisées dans le menu ou à la main suivant la procédure de maintenance). Il faut donc récupérer la puce des toners officiel et remplacer la puce des cartouches compatibles (ce que, si vous avez, comme moi, utilisé pendant des années des cartouches compatibles, vous n'avez plus).

C'est pas de l'obsolescence programmée (illégal) car l'imprimante fonctionne toujours un petit peu, mais je pense que vu le prix de l'imprimante laser où le principe est n'est pas de payer l'imprimante via ses cartouches, c'est une honte.

Ce qui fait que je ne conseille ni n'achète plus de Brother, ni HP. Dommage car elles sont increvables.

Les données (chunks/multichunks) sont immutables. C'est uniquement l'index qui mute et qui est ensuite recopié sur le serveur/répertoire à distance (puis swappé/rename avec le précédent de manière atomique).
Donc c'est assez sûr en fait, tu ne peux avoir de corruption à aucun moment sur le répertoire de backup.

En cas de corruption du support de stockage, détecté par un checksum/hash qui ne colle pas, vu que l'index contient toutes les révisions précédentes, au pire tu retrouveras une version précédente.

Par contre, en cas de corruption du support de stockage sur les données, là, je n'ai pas de protection (type Reed Solomon, ECC, Turbocodes). Vu que j'utilise des machines en RAID1, je me dis que c'est peu probable que ça arrive pile sur 2 disques au même endroit en même temps. Il faudrait ajouter de la redondance idéalement…

Pardon, j'aurais du dire sur la même architecture, plutôt que la même machine. C'est pas une archive, c'est un backup. Typiquement si tu as un problème (disque, machine qui crame), tu va changer le matériel défectueux et restaurer ta sauvegarde. Personnellement, vu que je sauvegarde /etc avec, je me vois mal changer d'architecture entre la restauration et la sauvegarde.

Si tu veux passer sur un nouveau type d'architecture, c'est possible, mais il faut lancer une VM pour faire tourner Frost dans l'ancien endianness, restaurer puis re-sauvegarder hors de la VM. Je n'en ai jamais eu la demande, je pense que c'est juste un problème théorique qui a aucune utilité pratique.

Dans la pratique, je suis passé d'un backup en ARM64 vers AMD64 sans problème lorsque j'ai changé mon NAS. Architecture différente mais compatible en endianness.

Borg est apparu après que j'ai commencé Frost.

J'ai d'ailleurs une issue encore ouverte qui me demande de comparer avec Frost.
Donc pour résumer à ce que j'ai compris:

1. Borg fait de la déduplication comme Frost, en utilisant un rolling checksum (type Adler32 chez Frost, ppargon je crois chez Borg)
2. Borg est écrit en python (Frost est natif, non interprété) avec le code de la crypto en C/Cython, Frost utilise OpenSSL et est donc accéléré en HW si disponible.
3. Borg compresse en LZ4, Zlib, Zstd (Frost, c'est seulement en Zlib et BSC, une sorte de LZMA 2x plus efficace). J'avais des plans pour implémenter Zstd, mais finalement, BSC, ça marche suffisamment bien, j'ai eu la flemme de changer.
4. Chaque chunk de données est identifié par son checksum, un hash SHA1 (soit 24 octets) chez Frost, la corruption est très improbable. Chez Borg, c'est un SHA256 (soit 32 octets). Je m'attends à ce que l'index chez Borg soit au moins 33% plus gros.
5. Borg v2 fait de l'authenticated encryption (AES_OCB/AEAD) alors que Frost fait du Encrypt en AES_CTR then MAC.
6. Les 2 fournissent un "driver" FUSE pour monter les archives
7. Borg ne fait pas de mmap sur ses index, et donc il faut avoir suffisamment de mémoire vive pour charger l'index en entier dans la mémoire. Ce qui limite, AMHA, à environ 100k fichiers par Go de mémoire sur Borg. Frost n'a pas ce problème.
8. Borg est beaucoup plus maintenu, il a en place une sorte d'organisation qui peut recevoir des dons (support pour les personnes en difficulté). Frost, c'est pas le cas.
9. Borg fonctionne à la fois comme serveur et comme client, il peut être appelé par SSH pour gérer l'envoi et la réception de chunks/multichunks. Ce qui nécessite une bonne connexion de données, pour la sauvegarde à distance et surtout la possibilité de lancer un processus sur un serveur distant. Frost lui travaille au niveau du système de fichier, donc il est indépendant du serveur et se base sur FUSE pour monter un serveur distant localement. Typiquement, ça veut dire que Frost fonctionnera sur de l'Amazon S3, du SSH/SFTP, du FTP, du Webdav, car il existe des "drivers" FUSE pour chacun de ces formats.
10. De plus, Frost utilise un index des fichiers local donc démarre beaucoup plus rapidement la sauvegarde, comparé à Borg qui doit le télécharger à chaque backup. Pour donner un ordre d'idée de la taille de l'index, il fait 1.7GB pour un backup de 136G (compressé) depuis 7 ans.

Voilà.

Bon, comme tu l'as vu toi même, effectivement, l'idée c'est de mmaper un fichier (quitte à le réagrandir avec ftruncate), et de créer directement les structures de données dans l'espace mémoire mappé du fichier (en C++ avec le placement new, je ne sais pas en Rust comment faire). Ce qui évite toute copie de données (vu que tu travailles directement dans le fichier) mais ça nécessite de ne pas avoir de pointeur mais des index dans d'autres conteneur (ce qui n'est pas plus mal en fait, ça rend le code beaucoup plus stable).

Du coup, lors d'une itération de ton archive, tu peux directement "pointer" sur les données précédentes, que tu n'as même pas besoin de lire physiquement. Ce n'est pas le cas en mode "read" où tu dois charger tout l'index en mémoire pour le modifier.

Évidemment, le prix à payer, c'est la portabilité, c'est à dire que sur les machines big endian (est-ce que ça existe encore ces choses ?) ne peuvent pas lire une archive LE, car il faut swapper les entiers avant de les utiliser. Mais pour une solution de backup, vu que tu restaures l'archive sur la même machine que tu sauvegardes, l'endianness ne change pas, ce n'est pas un problème.

Je fais effectivement un diff inversé (pas sur les données, seulement sur l'index), comme git pack car à chaque fois que tu lances un backup, c'est beaucoup plus rapide que d'avoir à reconstituer l'index à partir de la genèse. Donc, oui, je modifie l'index en fin de backup en stockant la version la plus récente comme une nouvelle itération, comprendre la hiérarchie complète des fichiers, à la fin de l'index avec un lien vers l'index de la version précédente. Puis dans le header de l'archive, je change le pointeur du catalogue vers la dernière version.

J'ai également une fonction de purge qui élimine les révisions les plus anciennes (probablement la fonction la plus dure à coder pour un système de backup qui déduplique).

La documentation du format est dans le header "Frost.hpp" vers la ligne 268.

C'est assez marrant en soi, car ton projet ressemble beaucoup à ce que j'avais fait avec Frost. Le programme est un logiciel de backup avec déduplication basée sur le contenu (donc capable de détecter l'ajout d'un caractère dans un fichier texte et de ne stocker qu'un bloc autour du changement).

Et on retrouve les mêmes idées que pour Jubako, notamment pour le format d'archive.
J'avais commencé avec du SQLite3 pour l'index (ce que tu appelles Directory + Metadata) mais c'était vraiment trop lent lorsque le nombre de fichier devenait grand (et ce, malgré les index dans SQLite).

Du coup, j'ai créé une archive à la mano, qui est mmappée, et modifiable par génération (c'est à dire que la nouvelle génération peut soit référencer la précédente, soit l'écraser totalement ou partiellement, suivant ce qui est le plus efficace).

Elle fonctionne en gros comme Jubako, mes ContentPack c'est des fichiers indépendants (qui sont compressés, coupés en bloc de taille fixe, puis chiffrés) et mon fichier d'index qui contient les Directory + Metadata (comme c'est du backup, j'y stocke toutes les métadonnées POSIX).

Ça fait 7 ans, utilisé quotidiennement sur 34To et je ne regrette pas du tout d'y avoir investi du temps, c'est super efficace, ça m'a sauvé plus d'une fois.

Si je peux de donner des conseils sur l'évolution du format, il faut absolument regarder du côté des structures mmapables (le gain de performance est délirant) et du stockage de différences (je détecte les différences via un rolling checksum à points de division fixe, ce qui permet de s'adapter à de nombreux formats, comme le texte ou les formats binaires). Ainsi, tu peux découper tes content pack en fonction du contenu (et en virant donc tous ce qui se déduplique facilement). Tu peux aussi gérer l'ajout dans un conteneur, simplement en stockant la différence avec la version présente dans le conteneur.

Dans mon cas, je recalcule toujours la différence entre la version actuelle et la dernière version et je modifie la dernière version pour arriver à la version actuelle, ce qui est beaucoup plus efficace que le contraire.

Si tu affiches l'extension sous forme d'icônes, alors il ne sert à rien de la répéter dans le nom du fichier.
Aussi, je suppose que chaque fichier étant représenté comme un lien, en cliquant dessus on le télécharge ?
Si oui, le bouton Download ne sert à rien.
Le bouton Rename ou Delete devrait utiliser des icônes. Idéalement, ces icônes ne doivent pas être visible par défaut car ce sont des actions "à effet", il faudrait 2 clics pour effacer un fichier ou le renommer. Peut être en mettant ces icônes dans une sorte de menu accordéon, ça pourrait le faire.

Regarde un peu ce genre d'interface:
https://tinyfilemanager.github.io/demo/
https://filegator.io/
https://filerun.com/demo
https://larsjung.de/h5ai/demo/header%20and%20footer/
https://www.filestash.app/ (en mode liste)

Après, vu l'état du code, c'est déjà un cauchemar à lire, sans la gestion des erreurs.

Pourquoi? Parce que ce genre de code spaghetti n'a pas été pensé comme il le faut.
D'ailleurs, exception ou pas, tu as une boucle infinie dans ton code (si getc() > 2 ou al).

Si c'est un parseur que tu veux, tu ne fais pas "en série", sauf cas très simple, mais "en parallèle" avec une gestion d'état. Et là, magie, le code devient beaucoup plus simple à écrire et parser, exceptions ou pas.

State get(State s) 
{
   int c = getc();
   if (c == EOF)        return EOF;

   // Logique du parseur ici
   switch(s) 
   {
   case Start: /* Transition de start à XXX */ 
      if (c == 1)       return ActionA; 
      else if (c == 2)  return NeedMoreInput; 
      return ActionD;
   case NeedMoreInput: /* Transition de start à ActionB ou C */
      if (c==0)         return ActionB; 
      return ActionC;
   default: return EOF;
   }
}

void parse() {
  enum State s = Start;
  while (true) {
    s = get(s);
    // Action du parseur ici
    switch(s) {
       case ActionA : actionA(); break;
       case ActionB : actionB(); break;
       case ActionC : actionC(); break;
       case ActionD : actionD(); break;
       case EOF : return;
    }
  } 
}

Utiliser des exceptions pour faire du retour de fonction, c'est créer 2 chemins (ou plus), là où il n'y en avait qu'un avant. Tu fais ça sur 10 niveaux, tu as maintenant 1024 chemins (ou plus) à tester et valider (donc 10x plus de code de test à écrire). Je te souhaite bien du courage.

Après, si une exception ne fuite pas vers le haut (difficile en général à réaliser), alors oui, les exceptions peuvent être utiles pour simplifier le code, mais il n'y a, dans ce cas, quasiment jamais d'avantage par rapport à des retours normaux bien gérés.
Par contre, avec l'aide de macro simples (remplaçant le try), tu peux capturer un callstack et là oui, c'est super bien pour retrouver le problème et simplifie fortement le code de log (uniquement à destination d'un développeur, car pour le pékin moyen, le log c'est mieux).

Je vois beaucoup de news sur LibreOffice, mais quasiment aucune sur OnlyOffice, qui est, pour moi, bien meilleur (surtout niveau interopérabilité DOCX/XLSX, interface, ergonomie, collaboration, etc).

C'est bien dommage. C'est pas pour critiquer LibreOffice, mais vous faîtes un petit tour des solutions alternative et vous ne citez pas son principal concurrent en open source, c'est sacrément dommage.

Bon, c'est vrai, mais il y a aussi tout ce que tu peux faire en C++ et que tu ne peux pas faire en Rust justement parce que le compilateur tient à forcer une seule méthode de gestion des données.

Par exemple, une liste doublement chaînée, en Rust, sans unsafe, c'est la galère, vu qu'il y a 2 pointeur pour un seul objet. Un structure récursive aussi c'est difficile à implémenter, tu passes un temps fou à te battre avec le compilateur pour qu'il accepte ce que tu lui décris (mais ça c'est grandement amélioré ces dernières années).

En C++, tu peux te tirer une bombe dans le pied avec une seule ligne de code, mais dès que tu as un peu d'expérience, ça devient bien plus rare et de toute façon, assez facile à débugger. La programmation template, aussi c'est franchement le top (mais c'est imbuvable) pour créer du code assez magique et optimal.

En Rust, tu as le pouvoir des macros qui franchement manque au C++ avec le pre-processeur tout pourri.

Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose.

Moi aussi, et c'est aussi l'avis de l'auteur. Mais malgré tout, il existe wg-dynamic pour la gestion des IP dynamiques.

WG c'est plutôt comme un bridge à l'usage. Tu as ta carte Ethernet/Wifi connecté à l'internet et WG crée une interface virtuelle (wg0) avec une IP privée (type 10.x.x.x) et une règle de routage entre les réseaux de telle façon à ce que tu puisses parler, via ce réseau privé (10.x.x.x) aux autres membres du réseau (10.x.x.y et 10.x.x.z etc…).

J'ai du mal à voir l'intérêt d'un proxy ARP ou NDP qui sont au niveau 2 (MAC) sur ce genre de montage, vu que ce genre de proxy sert justement lorsque tu n'as pas de table de routage (c'est quand même hachement plus simple de faire un ip route add via que d'avoir à mettre en place un proxy ARP). D'autant plus que l'ARP c'est du broadcast, donc pas top pour du VPN un peu étendu. Après si tu y tiens absolument, il y a OpenDaylight.

Par internet ? Comme n'importe quel autre logiciel en fait. Wireguard c'est un tunnel crypté, fourni soit avec le noyau ou à côté, comme module, ou en user space, bref, t'as l'embarras du choix.

Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP, tu peux utiliser TURN pour passer le double NAT et ensuite démarrer WG à travers le trou (et c'est même assez simple avec systemd d'ailleurs)

Ce n'est pas le rôle de WG de faire ça (à la Unix-style: WG fait un seul truc et bien). D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

Je pense que tu confuses. Wireguard c'est un outil qui utilise de nombreuse primitives cryptographiques: (ChaCha20 pour le chiffrage symétrique, Curve25519 pour DH, BLAKE2S pour le hashing, HKDF pour la dérivation des mot de passe/clés, …). Tu remarquera qu'il s'agit des primitives "à la mode", c'est à dire celle qui sont le plus efficace et sécurisées pour le moment.

Mais, contrairement à TLS, il n'y a pas de négociation d'algorithmes et de capacités (ce qui est plus source de problème plus que d'intercompatibilité, AMHA), vu que le protocole défini les primitives utilisées.

Si, à l'avenir, une primitive s'avère problématique, je suppose qu'ils feront avancer la version du protocole pour échanger une primitive avec une autre, en rendant obsolète la primitive à problème.

Pourquoi un bash -c ? Tu peux directement lancer /bin/ssh. Par contre, ce genre de service est assez dangereux (lancer en restart automatique un ssh en root, c'est s'exposer à des failles type TOCTOU vu le nombre de fichier parcourus par ssh pour démarrer). Je pense que stunnel est dans ce cas bien plus adapté (ou mieux, Wireguard)

Pour l'animation vectorielle, je te conseille pas Synfig, mais plutôt glaxnimate qui est excellent et produit des animations très légères (comparé à Synfig). L'interface est très proche d'Inkscape, ce qui est un vrai plus.

Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).

Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc…

Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).

En C++ récent, le code devient très vite cryptique, d'autant plus qu'il faut contourner les interprétation fallacieuse du standard par les différents compilateurs.

Pour cela, il y a cppinsights.io qui explique comment un meta programme est interprété (compris) par le compilateur.

Cela permet d'écrire du code template plus robuste, plus complet et plus lisible parfois.

Le payload MQTT est complètement libre, ce n'est pas forcément du JSON. Tu peux y mettre du binaire (pour l'OTA ou pas) ou ce que tu veux. Tu n'es pas du tout obligé d'encoder en base64 des images pour les transmettre.

MQTT existe en différentes version, la 3.1 et la 5 sont actuellement les plus utilisées. La version 5 permet des authentification forte (c'est à dire type Diffie Helman, sans le fâcheux username/password qui doit être stocké en dur dans le client, donc hackable facilement). Il gère également les propriétés sur chaque packet, ce qui permet de réaliser beaucoup plus de chose que la version 3.

Pour les clients MQTT, je te recommande eMQTT5 qui est un client MQTTv5 en C++ pour l'embarqué, type ESP32, (mais fonctionnant également sur Linux / OSX / Windows) et très léger (moins de 80kB sur x86, et 17kB sur Xtensa).

Il possède également un parseur de packet MQTT ce qui est très pratique pour déboguer une communication qui échoue.

De plus à la différence des autres protocoles, MQTT impose au broker de stocker l'état d'un client et d'éxécuter ses dernières volontés en cas de déconnexion, ce qui est super pratique pour l'IoT (qui peut ainsi s'assurer d'avoir un status "connecté/déconnecté" fiable) et permet aussi de récupérer sa session lors d'un connexion ultérieure (pratique pour le roaming, ip changeante, etc…)

Aucun des autres protocoles ne permet ceci (ou alors, c'est en plus, non standard).

Le fonctionnement sur Hellobank / BNP est identique, voire moins sécurisé, vu qu'ils demandent le mot de passe du compte avant d'envoyer le SMS (il n'y a pas de petites économies, hein?)

Ce qui me rends dingue, c'est qu'il n'y a pas de moyen d'éviter cette daube.

Comment un informaticien peut coder ça, sérieux ?
Une simple capture du HTML + CSS et c'est le paradis du phishing.
1. Tu proposes un site bidon avec de la vente de produit pas moins cher que d'habitude.
2. Puis tu demandes de payer avec ta CB. Avec les 4 premiers numéro de la CB, tu identifies que la CB provient du réseau BNP.
3. Tu balances une fausse iframe avec les bons logos et autre DOM/CSS que tu as capturé, et une iframe (inaccessible, dans la marge) sur le site d'Hellobank/BNP pour capturer les formulaires enregistrés (l'identifiant du compte n'est pas codé, il est en clair).
4. L'utilisateur va entrer son mot de passe de connexion. Avec l'identifiant capturé dans l'iframe plus le mot de passe de l'utilisateur, tu te loggues sur Hellobank.
5. Hellobank/BNP va détecter que ce n'est pas la même origine que d'habitude et va donc t'envoyer un SMS avec un code de connexion.
6. Tu demandes à l'utilisateur sur le deuxième page de l'iframe le code reçu.
7. L'utilisateur va entrer le code, forcément (même si le montant de l'achat n'est pas spécifié, car quoi, lui ne sait pas comment doit être le SMS).
8. Voilà, tu peux donc accéder au compte de l'utilisateur. Lui pomper ces données et ses sous.
9. Si tu veux pousser le vice encore plus, tu envoies un pseudo message d'erreur à l'utilisateur dans la troisième page de l'iframe, avec un bouton pour qu'il demande le renvoi du code reçu. (Forcément, aucune banque n'accepte de retaper un code, c'est supposé être du one-shot)
10. L'utilisateur va très probablement cliquer sur le bouton. Parallèlement tu procèdes à un vrai achat pendant ce temps, vu que tu as tout ce qu'il te faut (mot de passe + code SMS entré par l'utilisateur, cette fois pour le "vrai" achat).
11. Voilà, l'utilisateur va recevoir un mail légitime de la banque lui indiquant qu'il a dépensé X€ chez machin chose.

Toi, t'as gagné un accès direct sur son compte pour 3 mois.

C'est franchement donner le bâton pour se faire battre à ce niveau.