Jiehong a écrit 592 commentaires

Je suis tout à fait d'accord avec toi Zenitram : c'est mal foutu pour ceux qui s'en fichent.

D'ailleurs, je ne pense pas que les courriels chiffrés/signés décollent avec la technologie actuelle. Il faut une nouvelle technologie pensée pour ça, et qui est bien plus transparente pour tout un chacun.

Le problème d'une nouvelle technologie, c'est qu'elle mettra au moins une décennie à être intégrée aux clients mél.

Personnellement, je me sens beaucoup plus à l'aise quand j'ai la même disposition sur le smartphone et sur le PC…

Ça paraît logique, mais ce n'est pas ce que je fais en fait.

Je suis en qwerty sur le téléphone (français/anglais) à la « swipe », mais je suis en bépo sur l'ordi.

Résultat : je ne fais pas attention à la différence :

• je sais où sont les touches sur le qwerty, et ça marche bien sur le téléphone ;
• mes doigts savent parfaitement où sont les touches du bépo.

Je viens de faire un essais en changeant la disposition pour du bépo sur mon téléphone, et j'ai vraiment du mal. Je cherche mes lettres, alors que je tape en bépo (en aveugle) depuis plus de 3 ans.

Petit inconvénient du bépo sur un clavier virtuel : comme il y a plus de touches, elles sont un peu plus petites, et j'ai pas des doigts de pianistes :/

ah oui, mais là… Je suppose que ça ne les intéresse pas du tout, et qu'ils ne veulent pas savoir…

et pour les questions : http://www.phildev.net/pgp/pgp_clear_vs_mime.html

En tous cas, merci beaucoup du temps que tu passes à répondre à mes questions :)

Merci pour le retour, ;)

De rien. Je vais prendre le temps de donner mon avis plus en détails.

Les points vraiment bons :
- logiciels libres ;
- matériel libre (et là, chapeau bas, car c'est tellement rare) ;
- petit, et semble vraiment sympa.

Quelques points où je me pose des questions :

Cas où les gens utilisent déjà GPG

Je suppose que ça ne va pas changer grand chose. Own-mail va-t-il chercher les clés des correspondants sur un serveur de clés spécifique (par défaut) ou … ?

Cas où les gens n'utilisent pas GPG

Si j'ai bien compris, le courriel envoyé reste dans notre propre boîte mél., et on file un lien https à notre correspondant pour qu'il le lise. Le lien est à usage unique, et peut être protégé par une question.
Plusieurs soucis ici :
- comment on donne le lien finalement ? et le mot de passe/réponse à la question ?
- sans question, le lien n'offre aucune protection s'il est donné sur un canal non sûr (SMS, email en clair, etc.) ;
- si le CA de la connexion SSL n'est pas valide ou inexistant, le navigateur va informer l'utilisateur, qui va sûrement accepter le risque, et la c'est une MiTM sans souci (j'ai bien lu l'entrée sur les MiTM de la FAQ) ;
- c'est vous qui allez héberger les liens il me semble, dans ce cas, et si vous êtes le CA, il faut s'assurer de la sécurité de cette solution ;

Enfin, le message de retour est écrit dans le navigateur via le lien pour lire le message original. Celui-ci est transmit en https, et chiffrée via notre clé publique ?
Il n'y a pas vraiment de moyen d'authentifier celui qui nous réponds, mais bon, pourquoi pas.

Le réceptionnaire n'aura pas de copies du messages d'ailleurs (sauf à la copier-coller).

Bref

Je trouve que c'est un super solution pour s'auto-héberger, sur du matériel libre, et pour ça, c'est vraiment une super idée de projet.
Une fois le code revu, ça serait même formidable de pouvoir utiliser GPG aussi.

Par contre, la solution pour ceux qui n'utilisent pas GPG me semble compliquée, et et uniquement utilisable (si sûre) qu'avec 1 voire 2 personnes, mais pas vraiment plus.

Mais du coup, si l'interface du produit est disponible par https, qu'est-ce qui empêche le même navigateur non opensource avec un code légèrement différent de balancer les messages en clair ?

C'est vrai que c'est bizarre ce truc (et il semble possible d'envoyer un lien https sans question spéciale, contenant le contenu du message en clair).
En outre, ils n'ont pas encore de CA valide pour TLS/SSL…

Bref, c'est une solution d'hébergement personnelle sympathique, mais pour ce qui est de la protection des données, ça me semble bancale : non sûr tant que ça n'a pas été bien vérifié.

Il s'agit donc ici du pouillième de % des journaux notés très négativement, et uniquement ceux-là.

Si cela ne concerne qu'une faible partie des journaux, et que cela ne sert qu'à limiter les commentaires, je ne vois pas de raison légitime pour une telle chose.

Les commentaires sont fermés après un certain temps, de manière totalement égalitaire. C'est amplement suffisant.

Si un journal a une note trop négative, à toi de ne pas aller le lire et de ne pas y donner ton avis. La liberté d'expression appartient à tout le monde, et ils en font ce qu'ils veulent.

Par contre, ça a vieilli au niveau de la langue, et c'est un peu long à lire.

J'imagine que ce commentaire sera dans le même cas dans un siècle ;)

Merci pour ce partage !

OTR ne permet pas l'anonymat ! Tu confonds peut-être avec le « perfect forward secrecy » qui permet de ne pas compromettre les conversation antérieur si une clef est interceptée.
Il faut coupler à quelque chose comme TOR pour avoir un semblant d'anonymat.

J'ai mal utilisé le mot anonymat finalement. Tant que tu ne t'es pas authentifié, t'es « anonyme ».
Bon, mais en fait, c'est pas vraiment correct.

L'anonymat, c'est le fait de ne pas pouvoir être identifié, alors que là c'est le fait que ça puisse être n'importe qui au bout du fil (de la conversation OTR).

Désolé pour l'erreur !

C'est une très bonne question en fait.

Une solution est-elle parfaite en théorie, mais elle ne fonctionne pas en vrai. Est-elle vraiment parfaite alors ?

Pour ma part, la bonne solution est la solution qui marche quand elle est appliquée, sinon, c'est que ce n'est pas une bonne solution (souvent à cause des hypothèses de départ).

Le truc qui rend les choses difficiles, c'est que la communication par courriel n'est pas interactive : tu envoies, l'autre lis plus tard et te réponds encore plus tard.

Les protocoles de messagerie instantanées utilisent le fait que les personnes sont là en même temps pour faire un échange au début, et se mettre d'accord sur une clé commune à l'échange.

C'est d'ailleurs pour ça que l'on a créé le chiffrement y clés publiques : tu te mets d'accord tout seul sur une clé, et l'autre va la reconstruire après. Mais cela nécessite de connaître la clé publique de l'autre à l'avance, d'où le problème de gestions des clés…

Ce sont les brevets sur tout qui sont un souci : logiciels, idées, vivant (mais qui a bien pu avoir cette idée, et qui a pensé que c'était acceptable), etc.

L'idée même de brevet c'est un truc complètement arbitraire, car ça se résume à ça :

• Mon idée, elle est géniale. Mais si quelqu'un d'autre a la même, je lui pète la gueule, ou alors il me file du frique.

Ça ne marche que quand c'est le plus fort qui dit ça !

Non, mais il faut corrompre 2 canaux pour casser le système, cela devient compliqué, même pour un état.

Snowden a permit de montrer que c'était déjà le cas en fait (soit avec l'accord directe de l'opérateur de téléphone, soit avec des antennes permettant de capturer tout le trafic alentour (difficile à repérer après qu'elles sont installées)).

Par contre c'est "juste" une façon supplémentaire de plus de tracer l'utilisateur, si on veut éviter de l'être suffit de ne pas prendre le portable.

Tu peux toujours le prendre avec toi, mais il faut l'éteindre et le mettre dans un sac de Faraday.

Mais c'est plus simple de ne pas le prendre, c'est sûr ^{^}

Le seul risque est l'attaque MiM, qui demande des moyens considérables, car actif, et le vol de clef privé.

Ce n'est pas le seul risque en fait. À quoi sert une signature ?
Une signature permet de s'assurer que le message que tu reçois est le message qui t'a été envoyé (si la signature est valide).

On peut très bien t'envoyer des messages chiffrés avec ta clé publique, en se faisant passer pour quelqu'un d'autre (ta banque, ta copine, bref, n'importe qui).
Tu vas ainsi discuter avec quelqu'un qui n'est pas la bonne personne, même si vos échangent sont chiffrés, c'est franchement pas ce que tu veux.

Il serait donc préférable de signer tout le temps, et de chiffrer quand tu veux.

Il faut donc un 2ième canal pour envoyer les signatures comme les SMS ou autre. Et concernant le vol de clef, seul des clefs à duré de vie courte peuvent limiter le problème. L'idéal serait d'avoir une carte à puce avec la clef dedans.

Les SMS ne transitent pas sur un canal sûr…

Car crypto et recherche (simple, comme le veux l'utilisateur) ça va faire bon ménage :o)

Bah, pas forcément en fait. Ton approche, c'est ce que l'on appelle l'approche « naïve », vu qu'il faut 5 secondes à tout un chacun pour y penser (et personne ne le fait).

Cependant, « Searchable Public Key Encryption » (SPKE) s'intéresse à la recherche de données chiffrées sans avoir besoin de déchiffrer (je te propose un article de recherche datant de 2003 sur le sujet si ça t'intéresse).
Cette même technique permet de mettre des étiquettes sur des messages chiffrés sans en connaître le contenu (en dehors de la présence d'un petit ensemble de mots clés pré-défini).

Me semble que s'il est question d'un ensemble de glyphes cohérents disponible en plusieurs corps et graisses, il faudrait parler de police et non de fonte.

Tout à fait, je me suis planté.

En vrai, c'est surtout la carte par langue qui me fait tiquer : une représentation par alphabet ne serait-elle pas plus représentative du travail accompli et restant à accomplir ?

Je pense que la carte, c'est surtout pour faire classe. En regardant les PDF techniques sur la version sans de graisse regular, on s'aperçoit que ce sont les bouts d’Unicode suivants qui sont supportés : latin basic, latin-1, extension latines A, B et suppléments, extensions IPA, modificateurs et diacritiques combinatoires, Grec (+ extensions) et Copte, Cyrillique et suppléments, ponctuation générale, ainsi que des bouts d'autres zones pour l'instant.

Des glyphes additionnels sont présents, tels que les petites capitales, deux ligatures (fi et fl) ou encore les chiffres elzéviriens.

En outre, l'existence d'un compte github permet de remonter des bogues facilement, voire de soumettre des demandes d'intégrations.

Par contre, je n'ai pas trouvé de raccourci clavier ou d'option pour pouvoir choisir nous-même quand utiliser ce mode, puisque Firefox est loin de le proposer sur toutes les pages.

J'ai trouvé un moyen d'utiliser reader sur n'importe qu'elle page ! (grâce au fait que les onglets ne sont pas chargé au démarrage de FF et que l'adresse est dans l'onglet de reader).
Pour cela, il suffit d'ajouter le préfixe suivant à la page que vous souhaitez voir avec reader:

about:reader?url=
Exemple :

about:reader?url=https://linuxfr.org/


Il est possible de dire à plasma d'utiliser un autre backend dans Display and monitor > Compositor.

Soit tu utilises XRender, ce qui va utiliser ton CPU en priorité, et sera donc plus lent, mais ça devrait marcher correctement.

Soit tu utilises une interface OpenGL telle que GLX ou EGL.
Je te conseille GLX, puisque EGL ne fonctionne pas encore totalement bien partout (notamment avec les pilotes Intel).

Après, tu peux tester entre utiliser OpenGL 2.0 ou 3.1, ce qui peut corriger ton problème.

En dernier recours, tu peux tester avec les pilotes libres d'ATI/AMD, car c'est peut-être un souci du pilote propriétaire.

.kde4 n'est pas utilisé par plasma 5.

Par contre, je n'ai pas trouvé de raccourci clavier ou d'option pour pouvoir choisir nous-même quand utiliser ce mode, puisque Firefox est loin de le proposer sur toutes les pages.

Ça n'existe pas encore, mais un rapport de bogue est ouvert sur ça.

C'est ça !

Je trouve que c'est une très bonne idée, et ça rend plutôt bien ! Si ça se généralise, Latex sera peut-être moins utilisé.

Par contre, pour les formules mathématiques, le MathML, c'est vraiment illisible pour un humain, et ça fout à la poubelle tes connaissances en formules du type Latex. Ça veut donc dire que les formules doivent êtres tapées via un outil. C'est un mauvais choix je trouve.

C'est une bonne direction, et ça serait parfait avec les deux points suivants :

• « recherche reproductible » : les données externes et codes sources utilisées pour générer les graphiques de l'article sont également publiées (ce qui permet de reproduire, et de mieux analyses, voire de faire des méta-analyses plus simplement) ;
• toute publication scientifique est en accès libre (payer pour être publié, droit de lecture gratuit après publication).

À voir si l'usage se généralise (et merci pour ce journal).

Merci !