🚲 Tanguy Ortolo a écrit 12091 commentaires

Oui alors forcément, à part JPEG et PNG, on n'aura jamais de format vraiment universel, si on entend par là supporté par absolument tout.

Par contre, WebP est suffisamment répandu pour qu'on puisse s'attendre à :

• un support par tous les navigateurs, tous les afficheurs et outils de traitement d'image ;
• pouvoir ouvrir des bugs pour les logiciels qui ne le supporte pas, et que ces bugs ne soient pas immédiatement fermés parce que c'est un format exotique dont tout le monde se moque.

Bon, vous auriez un exemple, histoire qu'on puisse comparer sérieusement ?

Pour info, avec une image de 16×16, toute transparente avec quelques traits de noir pur, j'obtiens :

• un PNG optimisé de 1 kio ;
• un GIF de 767 octets ;
• un WebP de 62 octets.

Ouille, ça pue ça. Je me demande quel est l'intérêt de Google là-dedans. Espérons qu'ils y reviendront si tout le monde s'y met.

Après tout, Mozilla a mis trois ans avant de considérer l'ajout de WebP à leurs logiciels. Là, Google ont foncé pour intégrer JPEG XL dans Chrome, puis ont fait marche arrière. Au moins, ils sont techniquement prêts à le remettre.

Alors non, pas pour des icônes toutes petites. Du SVG, ça reste du XML, assez verbeux.

Comparé à une image matricielle assez grande, c'est imbattable. Mais pour une icône, on prend moins de place en matriciel correctement compressé en fait.

Tiens, j'avais oublié la chronologie. HEIF a mis huit ans pour convaincre Apple, quelques fabricants d'appareils photo et zéro acteur du Web. AVIF a mis quatre ans pour convaincre tout le monde logiciel. JPEG XL a mis moins d'un an pour commencer à convaincre une partie du monde logiciel, à un rythme qui rappelle celui de WebP.

Après, qui gagne, on s'en moque un peu. Lorsqu'on a un choix de format à faire, la seule question à se poser, c'est : quel format répond à mes besoins et a le plus de chances d'être toujours lisible dans dix ans. Et actuellement, la réponse, c'est généralement WebP (pris en charge partout), AVIF (presque partout), peut-être JPEG XL (sera sans doute pris en charge partout, mais pas encore), mais certainement pas HEIF qui n'est pas lisible et ne le sera peut-être jamais sur certains systèmes.

Le fait de pouvoir lire du HEIF, c'est très bien, surtout quand on a un appareil photo qui sort ce format-là. Mais ce n'est pas la même chose lorsqu'on est amené à choisir volontairement un format pour une image qu'on vient de produire ou qu'on veut stocker à long terme.

Ça ne me dit rien, mais ça a l'air cousin de la compression par ondelettes de JPEG 2000. Parce que contrairement à JPEG qui compresse par blocs, la compression basée sur une transformée en ondelettes travaille sur l'image entière, avec des fonctions qui n'ont de valeur significative que localement. En conséquence, il me semble qu'il n'y a pas vraiment de notion de pixel dans ce contexte théorique.

Exact, j'avais oublié. Et d'ailleurs, PNG permet aussi de faire du gris ou du RGBA sur 16 bits par canal. Si un modérateur a le temps de corriger :

Publié en 1996 par le W3C, le format PNG a été conçu pour remplacer GIF, qui souffrait de limitations techniques et de problèmes de brevets. Il permet de compresser sans perte une image avec une palette de 8 ou 256 couleurs, en niveau de gris sur 1 à 16 bits ou en RVB sur 8 ou 16 bits par canal, avec une transparence optionnelle par canal alpha sur 8 ou 16 bits.

C'est peut-être une niche, mais je ne sais pas si d'autres formats sont sur cette niche et font mieux que le PNG là-dedans.

Est-ce que WebP ne pourrait pas faire mieux ? Même sans palette, une image avec très peu de couleurs pourrait être très efficace à compresser. Je n'ai pas essayé, mais ce serait intéressant à vérifier. Si ce n'est pas le cas, clairement, une image avec peu de couleurs gagnerait à rester en PNG.

Ton avis sur HEIF me parait assez radical et infondé

Infondé, et puis quoi encore ? Alors, voyons un peu les fondements en question.

HEIF est :

• miné de brevets problématiques ;
• pris en charge par aucun navigateur ;
• pris en charge par certains outils d'affichage et de traitement d'image.

AVIF est :

• libre de brevets problématiques ;
• pris en charge par tous les navigateurs ;
• pris en charge par certains outils d'affichage et de traitement d'image.

JPEG XL est :

• conçu et promu comme successeur de JPEG à long terme ;
• libre de brevets problématiques ;
• pris en charge par certains navigateurs (c'est tout jeune, ça commence à peine) ;
• pris en charge par certains outils d'affichage et de traitement d'image (dont la liste est déjà plus longue que celle de HEIF).

Je m'avance peut-être, mais HEIF a l'air clairement d'être promu à un avenir aussi radieux que la connectique Thunderbolt. Il a peut-être convaincu quelques acteurs, mais côté navigateurs, c'est très, très mal parti, aucun n'a suivi. En face, on a un concurrent qui a déjà réussi à s'imposer (AVIF, bon courage pour le rattraper vu ce qui arrive ensuite). Je doute qu'HEIF réussisse à percer dans quelques années, puisqu'il y en a un autre qui débute et est bien parti pour s'imposer encore plus (JPEG XL, qui est vraiment conçu avec ce qu'il faut pour remplacer JPEG à long terme).

En matière de conseil de formats, je maintiens qu'aujourd'hui, il n'y a aucune raison, lorsqu'on enregistre une image après création ou retouche, de choisir ce format, AVIF est juste mieux, parce qu'il est lisible partout. Et si donc, vous avez enregistré une image en AVIF, et que dans deux ans, HEIF s'impose (et que JPEG XL échoue, ce qui m'étonnerait beaucoup), ça n'aurait aucune importance, AVIF restera lisible.

Eh bien, BitTorrent, tout simplement. Pas besoin de traqueur si les fichiers en question sont publics, la DHT fait bien l'affaire. Tout ce qu'il te faut, c'est un client BitTorrent initial, qui dispose du fichier et qui reste en service. Il servira de fournisseur initial, et dès que le fichier sera disponible ailleurs, il deviendra juste un fournisseur du fichier comme les autres.

Je comprends.

Mais le paiement avec une redirection vers le site de la banque pour confirmation permet aussi bien de vérifier que la transaction est bien du montant attendu, vers le bon marchand, et qu'on est bien en train de valider avec la banque et non avec un intercepteur.

L'argument selon lequel l'application bancaire serait le seul moyen pour l'utilisateur de vérifier que le paiement est bien conforme à ce qu'il attend est juste faux. C'est un choix de la banque, mais certainement pas la seule option disponible.

Certes, n'empêche que le changement peut être imposé par d'autres acteurs que le parlement européen.

Je viens seulement de me rendre compte d'une subtilité. Le fait de considérer que le handicap vient de la non-adaptation de l'environnement et de la société, c'est très bien. Mais ça ne plaide pas spécialement pour une tournure comme « en situation de handicap » : « personne handicapée », c'est déjà très bien !

Une personne handicapée, c'est comme une personne discriminée, une personne ignorée, maltraitée ou ce qu'on veut : c'est quelqu'un qui subit un problème. On ne parle pas de personne en situation de discrimination, n'est-ce pas ?

S'il y a bien un terme que j'évite déjà, c'est de parler d'un handicapé, ce qui pour le coup le réduit pas mal à son handicap.

Pas forcément, on a un précédent avec 3-D Secure.

En fait c’est très souvent refusé par le marchand et pour une bonne/mauvaise raison

Aucune importance, ce genre de cas, c'est super facile à gérer par les acteurs en position de force (les banques, les intermédiaires de paiement et les législateurs) : il suffit d'imposer la bonne solution. Les marchands peuvent s'adapter, et s'ils râlent il suffit de les laisser râler, le monde continuera à tourner.

Je trouve ahurissant que les banques acceptent l'intégration de leurs systèmes de paiement par iframe, et le fait que les marchands le demandent n'explique rien du tout. En matière de paiement en ligne, les demandes de la sécurité informatique devraient être considérées comme des ordres non négociables, prioritaires sur tout le reste.

Tous les agrégateurs dignes de ce nom supportent l'importation et l'exportation de listes de flux en OPML.

Mais accessoirement, ça pourrait être une bonne occasion de passer à une agrégation centralisée, avec un service d'agrégation installé sur un serveur, auquel tu accéderais depuis le terminal que tu veux.

Le plus connu est TinyTinyRSS, mais personnellement j'utilise FreshRSS, qui a l'avantage de ne pas nécessiter de faire tourner un serveur de base de données (c'est une vraie maladie des développeurs Web ça, utiliser presque systématiquement un serveur de base de données…).

Les alternatives à l'iframe ne se résument pas à avoir un site marchand qui demande tout et fait lui-même des requêtes à un prestataire de paiement hein.

Il y a aussi une dernière alternative, la seule qui tient la route à mon avis : rediriger le client vers le prestataire de paiement, qui une fois le paiement effectué redirige le client vers le site marchand avec des paramètres qui permettent à ce dernier de vérifier que le paiement a été effectué.

Avec un iframe, c'est juste pareil en terme de fonctionnalité sauf qu'en plus on s'assure que le client n'a aucun moyen de vérifier qui est le prestataire de paiement et si la frame de confirmation de paiement est bien celle de sa banque plutôt qu'un phishing. C'est pour cela que je suis sidéré que les banques permettent cela.

Merci pour les explications, c'est très intéressant. Mais c'est quoi le truc avec le prénom Camille au juste ? C'est pratique comme prénom, c'est épicène, mais au point de l'utiliser comme synonyme de « gens », tout de même…

Bon, euh, le problème des iframe, ça vient des banques. Ça pourrait facilement être interdit, il suffit d'ajouter un en-tête HTTP pour interdire l'intégration d'une page dans un cadre ou dans un cadre flottant.

Il est ahurissant que cette pratique ait été tolérée au départ, mais ça peut très bien se résoudre, c'est juste une question de volonté de la part des banques et des intermédiaires de paiement. Et la volonté, ça se fabrique très bien à coup de règlement européen.

Disons que c'est un facteur de possession. Il en faut toujours un autre, par exemple un code secret ou une empreinte digitale.

Tu rentres ton mot de passe bancaire ordinaire, puis le code reçu par SMS. Mais ça marcherait aussi bien avec n'importe quel second facteur potentiellement indépendant d'un téléphone, genre un TOTP ou une grille de codes.

Ça, je vais vite le vérifier, parce que je vais justement demander un appareil physique comme ça et voir ce que ça donne.

Ce qui est clair vu la description qu'ils en donnent, c'est que cet appareil n'intègre pas de carte SIM et d'abonnement qui va avec, ou de carte wifi ou quoi que ce soit qui lui permette d'avoir une connexion avec la banque. Ça a l'air d'un appareil autonome, parfaitement incapable d'afficher la moindre information en provenance de la banque. Et c'est censé pouvoir servir pour les achats en ligne avec 3-D Secure.

Par ailleurs, j'ai un sérieux doute sur ce qu'impose le DSP2 et dans quel cas : pour rappel, les achats sans 3-D Secure, ça existe toujours, c'est même très répandu (allez, au hasard, pour l'achat de timbres en ligne chez la Poste, qui demande simplement le numéro de carte, la date d'expiration et le code de sécurité, à l'ancienne), donc probablement pas du tout illégal. On peut donc en déduire que le fait de permettre un paiement en ligne sans dispositif séparé permettant au client de valider l'achat en connaissant le montant et le marchant n'a rien d'illégal.

Donc « les banques ne peuvent pas utiliser du TOTP simple parce que c'est illégal », je ne pense pas que ce soit vrai, en tout cas pas de façon aussi simpliste.

Je ne comprends pas.

DSP2 impose une 2FA contextuelle, aka qu’il soit impossible de procéder à un MITM par un site de phishing ou de drop shipping (l’objectif est que tu puisses être certain du montant et du destinataire de la transaction et que tu ne vas pas filer une 2FA qui va en vrai te débiter 2000€ chez un revendeur chinois obscur au lieu de 2€ chez Ebay).
Le moyen de 2FA doit afficher obligatoirement le montant et le destinataire à côté de l’OTP de manière à ce que l’utilisateur ne puisse pas les ignorer. Il est réputé les avoir vérifier avant de communiquer l’OTP.
Tous les moyens offline sont donc de facto illicites.

Ben non. Le formulaire dans lequel on rentre un OTP est une page de la banque, qui précise justement le montant et le commerçant.

Ils mettent parfois ça dans une iframe, ce qui empêche de vérifier que c'est bien notre banque, mais ça, c'est juste un choix technique débile, pas une nécessité.

Et c'est bien le gros soucis du journal aussi, il ne prend pas en compte des éléments importants comme l'utilisabilité.

Non mais sérieusement, l'utilisabilité. La seule utilisabilité qui a un sens, c'est celle qui fait passer les clients à la concurrence quand c'est pénible à utiliser. Ou qui, au contraire, fait venir les clients tellement c'est mieux qu'ailleurs.

Et donc, pour rappel, on est sur un sujet où le changement de fournisseur, c'est à dire le changement de banque, est un acte assez coûteux. Oui, je sais, c'est facilité par les services obligatoires de mobilité bancaire. Je le sais d'autant mieux que j'ai changé quatre fois de banque en quinze ans, la dernière fois étant il y a un peu plus d'un an, donc j'ai une vue assez récente de ce genre de procédure. Et je peux vous dire que c'est loin d'être trivial, il y aura toujours un acteur incapable de prendre en compte la demande de changement de compte.

Bref, sur ce sujet, en tant que public de DLFP, je pense que nous sommes assez motivés pour pouvoir, sur un motif assez sérieux, engager la démarche de changer de banque. Or justement, nous sommes assez nombreux a avoir rapporté ici même de sérieux soucis d'utilisabilité. Et à être restés dans la même banque, malgré ces problèmes.

Alors imaginer que la pénibilité de saisir quatre chiffres est assez significative pour qu'une banque perdre des clients à cause de ça, franchement, c'est prendre les gens pour plus fainéants (pour taper des chiffres) et plus motivés (pour changer de banque) qu'ils ne le sont.

En parallèle, les mêmes banques appliquent parfois des trucs comme une temporisation après ajout d'un bénéficiaire de virement avant de pouvoir lui envoyer de l'argent. Le truc parfait pour oublier de passer l'ordre de virement trois jours après. Et pourtant, ça ne décourage pas les clients, qui ne changent pas de banque malgré un truc aussi casse-pied. Alors les quatre chiffres à saisir, à d'autres, c'est bidon comme motif pour ne pas mettre en place un système d'authentification un minimum accessible (comprendre : pas réservé à ceux qui ont un téléphone sous iOS ou Android non modifié).

Pour être plus explicite : des empreintes, c'est comme un mot de passe, ça se vole très bien. Encore plus facilement d'ailleurs.

Et des empreintes, c'est comme un mot de passe, en cas de vol, ça se change. Euh, non, en fait. En cas de vol, c'est juste foutu pour la vie.