🚲 Tanguy Ortolo a écrit 12690 commentaires

Je trouve cela triste de voir par exemple une croix et un croissant symboliquement connoté et d'avoir envie de gerber. Je suis un athée convaincu, je n'aime vraiment pas certains organismes religieux (type le Vatican) et je râle quand les religieux tentent d'imposer leurs mœurs partout. Mais, un symbole religieux associé à la paix, non je n'aurais pas envie de gerber.

Ça tombe bien, la colombe, le rameau d'olivier ou l'arc-en-ciel comme symboles de la paix viennent justement de la Genèse. :-) Bon, ce ne sont pas franchement des symboles religieux pour autant, simplement des symboles inspirés par un récit religieux.

Après le scandale Volkswagen, la prise d'otage de John Deere. Ce n'est que le début. Les utilisateurs de logiciels vont commencer à se poser les bonnes questions et à vraiment comprendre l'importance des logiciels libres.

Ah, non, je ne pense pas. Enfin, peut-être vont-ils comprendre, mais ça ne changera pas du tout leur attitude.

C'est souvent comme ça, il y a un risque avec telle ou telle chose, les gens s'en foutent et quand on leur explique, ils nous traitent de paranos. Puis ce risque se réalise, ça fait éventuellement du bruit, on leur avait bien dit, ils comprennent, et ne changent rien.

Par exemple :

• Communiquer en clair avec des services centralisés, ça peut être espionné. Les gens : meuh non, soyez réaliste, ils ne vont pas espionner tout le monde, et puis on n'a rien a caché. Snowden. On vous l'avait bien dit. Rien ne change.
• Acheter des livres verrouillés ça craint, l'exploitant peut les supprimer à distance. Les gens : meuh non, ils n'oseraient jamais, voyons ! Amazon supprime des bouquins achetés par des clients. et tout le monde s'en fout.
• Acheter des produits connectés qui dépendent d'un service fourni par une entreprise ça craint, le jour où le service ferme vous n'avez plus qu'une brique. Les gens : on s'en fout, on achète sans regarder, donc on ne s'en rend même pas compte. Et puis, c'est tout poli et brillant ce nouveau machin, ça ira très bien dans mon salon. Des services ferment, des gens se retrouvent avec des briques, on leur avait bien dit mais tout le monde s'en fout toujours.

Personnellement, je me contente de conseiller mes proches et les gens qui me le demandent, et de savoir que quoi qu'il arrive, je ne suis pas concerné par ces problèmes.

Et CIC aussi donc, puisque c'est la même banque que le Crédit Mutuel (à un détail près, le CM appartient à ses clients, alors que le CIC n'appartient pas à ses clients mais au CM, donc indirectement aux clients du CM).

À un détail près, au CM et au CIC, ce n'est apparemment que le numéro du premier compte que quelqu'un a ouvert qui constitue son identifiant client.

Aucune idée, mais des banques utilisent ça comme prétendu second facteur, donc si elles sont censées respecter cette norme, soit c'est dedans, soit elles ont réussi versé un bon pot-de-vin à l'auditeur qui a vérifié leur conformité.

Ha, une norme qui impose une authentification à deux facteurs, mais qui considère comme valide la date de naissance comme second facteur, quelle blague...

Autant que je sache, deux facteurs, c'est censé signifier des éléments d'authentification parmi deux de ces trois catégories :

• quelque chose que l'on sait (typiquement, un mot de passe) ;
• quelque chose que l'on est (typiquement, une empreinte digitale) ;
• quelque chose que l'on a (par exemple une carte à puce, un générateur de codes, une grille de codes ou un téléphone).

Le premier facteur est presque systématiquement un mot de passe. Selon les banques, le second facteur peut être un générateur de codes, un téléphone (par envoi d'un SMS, avec une sécurité discutable), une grille de codes (le plus sûr à ma connaissance, et accessoirement sans doute le moins cher) ou la date de naissance du client. Cette dernière est une vaste blague, parce qu'elle n'est absolument pas liée au corps ou à la propriété du client, mais clairement à la connaissance (en plus assez partagée), ce qui en fait un second premier facteur, et certainement pas un second facteur valide.

À noter qu'une authentification à deux facteurs peut très bien utiliser un unique moyen technique, par exemple une carte à puce pourvue d'un code : pour l'utiliser, il faut dont posséder la carte, et connaître son code. Par rapport à un mode de passe, cela a l'avantage que ce code n'est jamais transmis, pas même à la banque, et que celle-ci pourrait très bien ne pas le connaître.

Ah oui, l'accessibilité de ces trucs est certainement épouvantable.

Je ne vois pas trop en quoi clavier virtuel et clavier physique diffère sur le point « observation par dessus l’épaule ».

Il me semble plus facile de suivre les mouvements d'un pointeur de souris à l'écran (lents, parce que l'utilisateur doit faire un effort pour repérer la position, aléatoire, de chaque chiffre), que les frappes de touche (rapides, parce que l'utilisateur utilise sa mémoire mécanique de la position des touches).

Quant au keyloggers, j’ai du mal à croire qu’il n’existe pas de "clickloggers" permettant de capter le code secret de la même manière...

Le clicklogger en question enregistrera sans problème qu'on a cliqué à telle position sur l'écran, mais pour déterminer ce qu'il y avait d'affiché à cet endroit, il faut y coupler une caputre d'écran, ce qui est un poil plus contraignant qu'un simple keylogger. Rien d'infaisable, évidemment, mais c'est nettement plus chiant, et nettement moins automatique à analyser.

Par ailleurs il serait tout à fait envisageable d’avoir un clavier virtuel possédant lettres et signes ponctuation.

Positionnées aléatoirement aussi ? Là, tu va faire fuir tes clients, qui en auront vite marre de passer cinq minutes à saisir leur mot de passe...

pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.

Alors, déjà, l'idée d'utiliser un token, c'est d'ajouter dans l'authentification quelque chose qui est de l'ordre de la propriété physique (en plus d'un code qui relève de la connaissance). Pour info, ces tokens utilisent un algorithme pour générer un code à partir d'un secret (l'algorithme standard pour cela s'appelle TOTP), mais tant que ça ne sort pas de l'appareil en question, ça relève bien de la propriété. En revanche, dès qu'on s'amuse à utiliser ça avec un générateur de code sur téléphone par exemple, ça s'approche un peu plus de la connaissance.

Autrement, il y a une alternative au token algorithmique, qui est la grille de codes : c'est une carte en papier, avec un tableau dont les colonnes et les lignes sont numérotées, et qui contient dans chaque case un code unique choisi de façon aléatoire. Par rapport à un token, ça ne coûte presque rien, ça n'utilise pas d'algorithme, pas de secret partagé (en fait c'est l'ensemble de la grille qui est un secret partagé), ni d'électronique d'aucune sorte, et c'est donc invulnérable aux attaques qui portent sur ces caractéristiques. Mais à moins de changer régulièrement de grille, ça peut être vulnérable à une réutilisation d'un code déjà passé qui aurait été intercepté.

pourquoi les banques n'autorisent elles pas les mot de passe avec une suite de caractères (chiffres, lettres, symboles) ? (Je me doute que derrière ça doit avoir un impact sur les gros systèmes qui hébergent les applis métier)

Certaines l'autorisent, en tout cas le CIC et le Crédit Mutuel (c'est le même groupe). En revanche, cela les empêche d'imposer une saisie de chiffre à la souris (vulnérable à l'observation par dessus l'épaule et à l'interception par un démon local mais pas aux key loggers), et leur implique donc de permettre la saisie du clavier (peu vulnérable à l'observation par dessus l'épaule, mais vulnérable aux key loggers et à l'interception par un démon local).

Je ne sais pas comment on définit une machine qui fournit un travail, mais en tout cas, il ne me semble pas raisonnable de mettre un four dans cette catégorie, ça me semble plutôt être un outil. Le four ne produit rien quand on l'allume, il chauffe, mais ça ne sert à rien si on ne met pas un truc à cuire dedans. C'est comme des plaques de cuisson, une casserole, une perceuse, une voiture...

Contester un paiement, c'est facile. Mais contester une partie d'un paiement, c'est infaisable. Le coup des options payantes est tout à fait pertinent, imaginons un fournisseur de téléphonie mobile qui t'abonne d'office à un service de nouvelles sportives par SMS, gratuit le premier mois. Tu ne l'as jamais demandé, mais lui considère que tu y as souscris, même si c'est faux, c'est ce qu'ils ont noté dans leur base de données. Souscrire ainsi un client à un service sans qu'il l'ait demandé, c'est parfaitement interdit, mais c'est fait et c'est comme ça, libre à toi de les attaquer en justice si tu as le temps.

Toujours est-il qu'après un mois, il va commencer à majorer ta facture coût de ce service. Deux possibilités :

• si tu paies par un moyen à ton initiative, chèque ou virement, tu peux leur écrire pour contester la facture, et leur régler ce que tu leur dois vraiment, donc minoré du coût de ce service non demandé ; à ce moment, le fournisseur aura le choix entre :
  • considérer cela comme un défaut de paiement, suspendre l'abonnement, lancer une procédure de recouvrement de créance et perdre un client ;
  • accepter de retirer l'abonnement au service non demandé et conserver un client ;
• si tu paies par prélèvement, ils auront déjà prélevé le montant indûment majoré, ce qui ne laisse que deux options :
  • annuler le prélèvement, et se retrouver en défaut de paiement intégral pour ce mois, avec le fournisseur qui déclenchera alors probablement une suspension d'abonnement et une procédure de recouvrement de créance, puisque quand un client ne paie pas du tout, il n'y a rien à perdre ;
  • écrire au fournisseur pour lui demander un remboursement de la somme indûment prélevée, et espérer...

Ça s'appelle une fourniture de service, pas du salaire.

J'ai déjà rejeté et révoqué des mandats ou paiements SEPA en ligne, la banque ne demande rien, tu le fais et ça se met en place directement et voilà.

Non, ce que tu as fait, c'est mettre annuler des prélèvements, et mettre des créancier en liste noire. Ta banque peut à tort appeler ça une révocation, ça n'en est pas une, pour la simple raison que ce n'est pas ta banque qui a le mandat, mais le créancier. Pour le révoquer, c'est à lui qu'il faut écrire, et c'est à lui de prendre en compte cette révocation en cessant de prélever, puisque tout nouveau prélèvement serait un prélèvement sans mandat valide, qui passerait très bien mais en totale violation avec le règlement SEPA, lui faisant risquer une radiation globale.

Au cas où ça n'apparaîtrait pas assez clairement dans ce que je viens d'écrire, la prise en compte d'une révocation de mandat dépend uniquement du bon vouloir du créancier. Comme on peut s'attendre à ce que certains ne prennent pas en compte les révocations, les banques proposent souvent une possibilité de bloquer un créancier, de sorte que les prélèvement qu'il pourra tenter seront refusés.

Cela m'est arrivé récemment avec l'assureur d'un prêt immobilier. Ayant remboursé mon prêt par anticipation, j'écrivis à l'assureur pour lui signaler que le prêt était terminé, que par conséquent ma police d'assurance prenait également fin, et qu'ayant déjà réglé la dernière cotisation, je ne leur devais plus rien. Dans la même lettre, je leur signifiai la révocation de leur mandat de prélèvement, leur rappelant qu'ils n'avaient plus rien à prélever sur mon compte, et qu'ils n'avaient désormais plus le droit de le faire. Eh bien, ça ne loupa pas, quelques semaines après, je reçus de leur part une lettre où ils se plaignaient que leur tentative de prélever une nouvelle cotisation avait échouée, que j'étais en défaut de paiement et que si ça continuait ils allaient faire appel à un cabinet de recouvrement, de sorte que je dus leur répondre pour leur rappeler que je n'étais plus client, que cette cotisation était indue, que leur mandat de prélèvement avait été révoqué, que leur tentative était en violation du règlement SEPA et que, en gros, je ne paierai pas. Au vu de leur dernière réponse, je crois qu'ils ont bien compris et laissé tomber l'idée de me soutirer quoi que ce soit.

Bref, tout ça pour dire qu'avec les prélèvements SEPA, il y a deux risques :

• de se faire débiter par un créancier inconnu, donc a fortiori sans mandat, ce qui est du vol pur et simple ;
• de se faire débiter par un créancier qui n'a pas bien compris qu'on n'est plus client et qui n'a pas pris en compte ma révocation de son mandat (c'est en fait très, très fréquent, un fournisseur n'ayant aucun intérêt à correctement prendre en compte le départ de clients).

Les deux cas sont des violation du règlement SEPA ; pour le premier, une annulation de la transaction frauduleuse suffit, mais pour le second, qui risquerait de se répéter, seule une liste noire permet d'en venir à bout.

Un TIP SEPA, c'est un mandat de prélèvement. Valable pour un seul prélèvement, mais le créancier peut s'amuser à l'utiliser plusieurs fois, c'est interdit, mais ça marche.

Correction, avec SEPA, par défaut, tout créancier, aussi bien le Trésor Public qu'EdF, peut déjà piocher à son bon vouloir. C'est interdit sans mandat signé par le client, mais c'est tout de même possible. Certaines banques permettent de bloquer les prélèvements sauf pour une liste définie par le client, mais pas toute.

Les mieux est encore de consulter la norme POSIX. Et effectivement, seq ne fait pas partie des utilitaires standard... Je ne sais pas comment faire ça sans.

Attention, c'est du Bash, ou du Zsh, mais plus du simple shell POSIX.

Sans pipe ni recourcs à xargs:

commande $(for i in $(seq 1 100); do printf 'arg '; done)

Un truc qu'il suffit d'installer pour que ça marche, c'est un peu l'esprit du client officiel, Certbot. Bon, il faut aussi le lancer. Mais il est conçu pour les cas simple, et il ne faut pas rêver, un client qu'il suffit d'installer et qui marche dans tous les cas, même avec plusieurs serveurs derrière un proxy inverse, un NAT, avec des ports différents et je ne sais quoi encore, ça n'existera pas. Pour les installation qui dépassent le simple serveur domestique, il faut plutôt compter sur les clients alternatifs qui permettent une grande personnalisation.

Paperwork n'est-il pas en Python ? Parce qu'il y a des bindings Python pour DjVuLibre.

Pour Tesseract, apparemment il y a une libtesseract, mais je ne sais pas ce que ça vaut.

Dans ce cas, tu pourrais prendre en charge le DjVu en lecture, pour importer des fichiers réalisés extérieurement.

Comme tu dis un problème se pose lorsqu'on te demande des originaux et ta solution parait pertinente.
Dernièrement j'ai arrêté de stocker un pdf mais je passe par un jpeg avec un facteur de qualité de 97, au final je n'ai pas trop regardé la perte de qualité mais dans tous les cas ça prends moins de place.

Avant même de regarder la qualité de la compression, il faut déjà s'occuper de la finesse de la numérisation. Si c'est du 100 ou 150 dpi, ça va se voir tout de suite, parce que ce sera pixelisé façon fax. En 200 dpi, ça se verra mais pas forcément immédiatement. En 300 dpi, ça se verra en étant un peu attentif. Et en 600 dpi, ce sera invisible sauf à vraiment chercher très attentivement, et encore. En supposant une impression à 300 dpi.

Salut,

J'ai une suggestion de fonctionnalité : une prise en charge du format DjVu, qui est parfaitement adapté pour les documents numérisé, et qui peut également être OCRisé.

Par exemple, mon cas d'usage pour le DjVu est le suivant. Je souhaite à numériser mes documents avec une qualité suffisante pour qu'une fois réimprimés, un humain ne se rende pas spontanément compte qu'il s'agit d'une copie1, même s'il pourra toujours le remarquer en l'examinant attentivement. Dans la mesure où nous ne décelons plus facilement les points à partir de 300 dpi, il faut pour cela numériser à 600 dpi. Essayez de stocker ça sous la forme d'un PDF, et vous obtiendrez quelque chose de très lourd, avec en prime une compression avec perte. Essayez cela en DjVu, et vous obtiendrez quelque chose de moins de 100 kio.

Pour info, DjVu est vraiment faire pour cela, avec plusieurs niveaux d'optimisation :

• le document est séparé en arrière-plan (image en couleur) et premier plan (texte bitonal) ;
• l'arrière-plan est codé avec une compression par ondelettes ;
• le premier-plan est codé à la façon du JBIG, avec notamment une reconnaissance des formes répétées (la même lettre à plusieurs endroits de la page).

Pour produire un document DjVu à partir d'images (TIFF dans mon cas), j'utilise didjvu, puis ocrodjvu avec tesseract pour y ajouter une couche de texte par OCR. Les documents DjVu peuvent être lus avec Evince, donc probablement avec le bibliothèque Poppler.

Notes :

1. Il ne s'agit pas de faire un faux ou de prétendre qu'il s'agit d'un original. Simplement, lorsqu'on me demande sans plus de précision un document dont je n'ai qu'un exemplaire, il est évidemment hors de question de fournir l'original, aussi je fournis donc une copie, sans précision à ce sujet. Il est arrivé qu'on me refuse un dossier parce qu'en le voyant, mon interlocuteur avait rapidement remarqué qu'il s'agissait d'une copie : dans ce cas, avec une meilleure qualité, on peut augmenter les chances qu'il accepte un tel dossier.

• Démarrer le système d'installation en UEFI, et surtout pas en BIOS. En effet, après avoir installé GRUB, il doit le déclarer à la carte mère en passant des appels UEFI qui vont bien, et pour ça, il faut avoir démarré en UEFI, sinon c'est impossible, et on se retrouve avec GRUB installé mais absent du menu de démarrage proposé par la carte mère, et avec donc aucun moyen de le lancer.

Pour info, pour que ta clef USB soit démarrable en UEFI :

• elle doit être partitionnée en GPT, ou éventuellement MBR (c'est plus rare, mais c'est possible) ;
• elle doit avoir une partition de type "EFI System Partition";
• cette partition doit être formatée en FAT32 (c'est le seul système qui soit pris en charge par tous les UEFI, mais ceux de chez Apple lisent également le HFS+) ;
• il doit y avoir sur ce système un fichier /EFI/BOOT/BOOTX64.EFI (pour un PC en 64 bits ; le nom serait différent pour une autre architecture) ;
• ce fichier doit être un exécutable UEFI pour PC en 64 bits, en pratique ce sera GRUB ou un autre chargeur de démarrage, voire un noyau Linux avec l'emballage UEFI qui va bien.

C'est ça, on l'a forcé à verrouiller son bouquin, bien sûr. Parce que le publier sur son site Web, c'était sûrement interdit. Non, utiliser la DRM Adobe, c'est un choix qu'il a fait sciemment et volontairement, ou qu'il a ignoré ou délégué volontairement, et on peut dont tout à fait lui reprocher.