🚲 Tanguy Ortolo a écrit 12224 commentaires

À mon avis, ta prédiction est trop optimiste, j'ai peur qu'il se passe bien pire, à savoir : que Mozilla mette ça en place, et que ce soit finalement accepté sans faire trop de vagues. Ce serait bien pire, parce que ce serait un pas de plus, avec un effet cliquet si vous voulez, vers l'acceptation définitive de DRM applicatifs, considérés comme quelque chose de normal.

Je trouve déjà totalement flippant le seul fait qu'un acteur comme Mozilla envisage d'utiliser à son tour des DRM applicatifs, qui, à l'époque où on commençait à en parler, avec une technologie de Microsoft et d'Intel il me semble, nommée Palladium, avaient rencontrés une telle opposition que même une société comme Microsoft avait dû faire marche arrière dessus. Que de chemin parcouru depuis, pour qu'un acteur du libre puisse à son tour se lancer là-dedans, et que cette décision soit saluée comme un progrès ! On est à fond dans l'effet cliquet, ou la stratégie du pied dans la porte, peu importe comment on l'appelle, mais ça n'augure rien de bon.

Si Mozilla constate qu’ils se tirent une balle dans le pied, ils changeront d’avis.

Sauf que la simple concurrence ne suffit pas à pousser les acteurs à agir pour le bien de l'humanité, en tout cas pas dans un domaine aussi technique. Il faut une volonté particulière pour cela, et voir une organisation qui luttait dans ce sens se mettre à faire du DRM, c'est, comment dire, gerbant, en fait.

S'il s'agit de rendre impossible l'utilisation d'extensions non validées par Mozilla, sans possibilité pour l'utilisateur de désactiver cette restriction, il n'y a pas le moindre doute, c'est du DRM applicatif, ce que Microsoft avait tenté de faire avec Palladium avant de faire marche arrière, que TiVo avait mis en place pour la première fois, puis qu'Apple avait repris de façon massive dans leurs téléphones, avant que cette idée ne se répande un peu partout.

Maintenant, ce qui m'amuse, c'est que la possibilité de signer des extensions existe depuis des années avec les logiciels Mozilla, et que je n'ai jamais vu une extension signée jusqu'à présent, seulement des avertissements : cette extension n'est pas signée, voulez-vous l'installer ?

Comme l'immense majorité des plugins PGP pour navigateur Web, il ne prend en charge que le format obsolète de PGP en ligne, et pas le format actuel PGP/MIME.

Ça me rappelle qu'il y a quelques années, j'avais reçu un appel de Médiamétrie, qui proposaient de me rappeler pour une étude sur l'usage de la télévision. J'avais répondu que je n'avais pas de téléviseur, et que je ne regardais pas la télévision sur mon ordinateur : malgré ça, je les intéressais quand même, et on avait convenu d'une heure de rendez-vous pour répondre à cette étude. Sauf qu'à la date et à l'heure dite, j'avais bien fait en sorte de me libérer, mais ils ne m'ont jamais rappelé…

C'est donc presque trop beau pour être vrai et comme disait Virgile (qui n'était pas ivre) : "Timeo Danaos et dona ferentes".

Et tu écoutes des Romains sobres, sachant que par ailleurs in vino veritas ?

Il s'agit donc d'un logiciel qui fournit les fonctions suivantes, si j'ai bien compris :

• serveur de courrier (SMTP) ;
• serveur de boîte aux lettres (IMAP) ;
• serveur Web et Webmail ;
• serveur WebDAV ;
• serveur CardDAV.

C'est bien ça ?

Et ton numéro de carte bancaire.

Alors franchement va falloir que vous m'expliquez pourquoi vous, administrateurs réseau, utilisez encore cette vieillerie d'FTPS ?!

À mon avis, la raison principale en est que, comme comme SFTP a moins de trente ans, Microchiottes Windaube ne le prend pas en charge nativement, contrairement à FTPS.

Et c'est du JPEG… Pour quelqu'un qui fait des logos, évoquer un contexte différent de ce dont on parle (un prompt DOS pour une faille GNU) et en plus utiliser un format d'image inadapté, ça cumule…

/me court se cacher. Il faut dire que quand on a lu jusqu'au bout, on ne se souvient pas forcément du début. :-)

Ça c'est de la belle cryptanalyse, merci de l'avoir partagée, même si ça m'a fait perdre pas mal de temps ! Son auteur a-t-il contacté MISC ou un autre journal pour y rédiger un article ?

Sachant que la clef privée contient la clef publique, enfin, ce qu'on appelle clef privée avec GnuPG contient ce qu'on appelle clef publique, tu aurais pu exporter simplement ta clef privée, et repartir de là avec un .gnupg tout neuf.

Si tu repars sur une nouvelle clef, avant de la publier, assure-toi qu'elle est bien conforme aux recommandations actuelles (RSA 4096 bits). Et révoque l'ancienne.

Tu peux exporter ton ancienne clef (publique et privée) avec :

% gpg --export KEYID > KEYID.pub
% gpg --export-secret-keys KEYID > KEYID.sec

Ensuite, tu peux bazarder ton .gnupg (à ta place, je le déplacerais seulement), puis repartir proprement en important ces deux clefs.

% apt-cache show nodejs-legacy 
Package: nodejs-legacy
Source: nodejs
Version: 0.10.29~dfsg-1.1
Installed-Size: 101
Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>
Architecture: all
Depends: nodejs (>= 0.6.19~dfsg1-3~)
Conflicts: node
Description-en: evented I/O for V8 javascript (legacy symlink)
 Node.js is a platform built on Chrome's JavaScript runtime for easily
 building fast, scalable network applications. Node.js uses an
 event-driven, non-blocking I/O model that makes it lightweight and
 efficient, perfect for data-intensive real-time applications that run
 across distributed devices.
 .
 This package contains a symlink for legacy Node.js code requiring
 binary to be /usr/bin/node (not /usr/bin/nodejs as provided in Debian).
 .
 No other Debian packages should depend on this package.  For more
 information, see
 <http://lists.debian.org/debian-devel-announce/2012/07/msg00002.html>
Description-md5: c72fe66177b6537572dbe9b186ed3611
Homepage: http://nodejs.org/
Section: web
Priority: extra
Filename: pool/main/n/nodejs/nodejs-legacy_0.10.29~dfsg-1.1_all.deb
Size: 80220
MD5sum: e24bd87bf4fdb50351fc3d45ee6513d2
SHA1: 13a4f1176c5dd68fcba446636179acf0fe52c2f5
SHA256: becae245cc8b8c7fc611d7af3a099ba6983eadc5f0c8f6473df613f669788e9a

En France, tu reçois un chèque, il te faut 15 jours pour être sûr d'avoir l'argent. S'il est refusé, c'est pour ta pomme. Alors les banques ont créés des chèques 'certifiés', pour combler et rassurer les banques.

Ce que tu appelles chèque certifié, c'est en fait un chèque de banque. C'est un chèque qui n'est pas émis par un client, mais pas sa banque. Par exemple, client à la BNP, si je demande un chèque de banque, la BNP va prélever le montant sur mon compte et faire elle-même un chèque (émetteur : la BNP elle-même). Ainsi, ce chèque est endossable par la banque du destinataire, indépendamment de l'état de mon compte, puisqu'il est tiré sur un compte de la BNP elle-même. Il n'y a ainsi plus de risque lié à l'individu qui a fourni ce chèque, mais seulement un risque lié à sa banque.

Or, on peut indiquer dans un entête HTTP (HTTP Public Key Pinning, épinglage de clé public HTTP) l’autorité de certification qui produit les certificats valides du site. Firefox prend désormais en compte cet entête pour empêcher la connexion s’il détecte un certificat non-conforme à ce qui est indiqué par l’entête. Voir le brouillon de la RFC de l'IETF pour les plus courageux.

Donc ils ont mis en œuvre un système d'épinglage de clefs qui est à l'état de brouillon. En revanche, le système plus général et plus sûr DANE, qui lui n'est pas à l'état de brouillon mais bien publié, toujours pas ?

Ça reste un effet de mode, vu que ça ne se faisait pas ou très peu il y a, disons, dix ans, et qu'il y avait déjà des associations.

Car, dans ce que j'imaginais, si un tel système (qui a l'avantage de réduire à presque zéro les fraudes) avait été poussé par les banques, un champs "référence" aurait été joint au virement contenant la référence qu'attendait le commerçant/créancier.

Bon, alors bienvenue dans le monde réel, parce qu'avec SEPA, les virement contiennent un champ référence. L'ennui c'est que toutes les banques ne permettent pas de le remplir, super non ?

Le problème d'un virement c'est que comptablement ça peut prendre une éternité à identifier et c'est pour ça que les fournisseurs n'aiment pas toujours. Savoir qui on prélève est facile, identifier quelle dette est sensée recouvrir un chèque ça peut être rapide (si le payeur joint le papillon de règlement pré découpé) mais identifier un virement apparaissant sur un compte bancaire peut tourner au cauchemar, voir être impossible.

Meuh non.

Savoir qui on prélève est facile

Oui, parce que le client a fourni ses coordonnées bancaires au fournisseur. Or, s'il veut payer par virement, ces mêmes coordonnées bancaires apparaîtront dans le virement, l'identification est donc triviale.

EDF ne permet pas de payer par virement justement, seulement prélèvement ou TIP à renvoyer par la poste à chaque fois (pour les particuliers et entreprises en tout cas)

En temps normal, non, mais si tu as une facture en retard, entre ne pas être payés et recevoir un virement, je pense qu'ils accepteront le second.

Après, comme je le disais, ce sont les fournisseurs sérieux qui acceptent les virements, et la plupart sont simplement des gignols, EDF compris visiblement, rien de nouveau donc.

D'ailleurs, comment fait-on, sans chèque, pour régler, disons, un médecin ? On lui remet une promesse formelle de virement ?

L'avantage avec un chèque, c'est que le créancier détient l'ordre, le chèque donc, et peut s'estimer raisonnablement satisfait dès qu'il l'a en main, alors qu'avec un virement, il ne peut que compter sur la parole de son client non ?

À noter que, si on parle surtout de fraude avec le prélèvement, le virement peut également être un moyen de fraude, combiné à l'ingénierie sociale. Deux exemples, ciblant plutôt les entreprises, mais avec lesquels des particulier peuvent tout à fait se faire avoir aussi :

• quelqu'un on envoie au comptable, le vendredi soir, une facture avec un IBAN, à payer pour hier, avec un nom et un logo de fournisseur probable, et parallèlement l'appelle en se faisant passer pour le président, expliquant qu'il a passé un achat vachement important, malheureusement hors des règles normalement appliquées dans l'entreprise, pour cause d'urgence : si le comptable paie, ce n'est évidemment pas un fournisseur légitime mais un voleur, qui reçoit le virement ;
• quelqu'un envoie au comptable une lettre aux couleurs d'un vrai fournisseur habituel de l'entreprise, expliquant qu'il a changé de banque et qu'il faut prendre en compte tel nouvel IBAN : si le comptable enregistre ce changement, la prochaine facture ne sera pas versée au fournisseur mais à un voleur…

Éludé seulement. Je ne suis volontairement pas rentré dans la gestion a posteriori des fraudes et des cas litigieux, mon avis étant qu'il est préférable de rendre la fraude impossible, plutôt que de réagir après qu'elle ait eu lieu.

(Comme avec les cartes de paiement sans contact en fait : ça permet un certain type de fraude, et même si les banques assurent qu'elles fournissent tout ce qu'il faut pour se faire rembourser en cas de problème, pas de fraude est à un avis préférable à une fraude qu'il faut détecter et demander à se faire rembourser.)

Ensuite, on aurait pu construire un système d'achat sur internet où le vendeur diffuserait ses coordonnées et les acheteurs feraient des virement sur ce compte.

Régler ses fournisseurs par virement ? Tous les fournisseurs sérieux proposent cela, l'ennui c'est qu'il y a plein de fournisseurs qui sont des guignols évidemment…

Après, pour les achats de détail, ce n'est pas pratique, mais pour des trucs comme les abonnements, je t'assure que si tu dois payer une facture à, disons, ton fournisseur d'électricité, et que tu lui propose de la régler par virement, il est très peu probable qu'il refuse, puisqu'il s'agit d'être payé. C'est comme quand on change de compte en banque, les fournisseurs ne font aucune difficulté à noter le changement puisque s'ils ne le font pas, ils ne seront plus payés !

Il y a aussi un autre truc rigolo, qui est la grande mode actuelle des associations qui demandent, non plus des dons ponctuels, mais des dons mensuels, par prélèvement. Là où c'est intéressant, c'est que ça donne un magnifique argument pour envoyer paître le démarcheur :

• D'accord, je veux bien donner 10 euros par mois, quel est votre identité bancaire ?
• Ah non, ça ne marche pas comme ça, il faut que vous signiez ce mandat de prélèvement.
• Désolé, je ne donne jamais de mandat de prélèvement pour un don mensuel fixe, mais je peux mettre en place un virement permanent.
• Ah non, on ne marche pas comme ça, c'est par prélèvement !
• Dommage, moi je veux bien donner mais de la façon qui me convient, ensuite si vous ne voulez pas de mon don, c'est votre problème. Au revoir Monsieur.