Titre racoleur assumé.
J’étais en train de répondre au journal qui traite de comment on pourrait obtenir une solution de chiffrement accessible à tous quand je me suis dit qu’un journal serait peut-être plus approprié pour mettre en avant ma réflexion sur le sujet.
La question est intéressante, donc prenons le temps d’y réfléchir.
Réflexion
Le chiffrement, qu’il soit symétrique ou asymétrique nécessite des clés de chiffrements.
La possession de ces clés assure la confidentialité, l’intégrité et parfois l’authentification des messages.
1. Vous devez utiliser des clés de chiffrement.
Partant de là, comment les gérer ? Soit par un intermédiaire technique, en quel cas la sécurité est inexistante. Soit par l’utilisateur.
2. Il faut que la gestion des clés soit faite par l’utilisateur.
Pour cela, il est nécessaire qu’il ait un minimum de connaissances.
3. L’utilisateur doit apprendre.
L’utilisation du chiffrement a également besoin de logiciel.
4. Le chiffrement ne peut se faire que par un logiciel open-source.
(ceci n’est pas un débat idéologique, mais simplement la conséquence du fait qu’il est nécessaire de pouvoir auditer le code pour peut-être avoir confiance dans la solution de chiffrement, qu’il soit libre ou pas n’est pas la question)
Je n’aime pas être trop catégorique, mais je doute que mes propos en gras puisse être remis en question.
le point 2. implique qu’une solution de chiffrement via un site web nécessite une confiance envers son éditeur, ce qui n’est pas génial mais envisageable pour des gens qui voudraient un niveau de sécurité (très) moyen.
Considérons que l’on souhaite le meilleur aux utilisateurs et que cette solution n’est pas acceptable. Essayons alors de lister les caractéristiques nécessaires du logiciel pour chiffrer ses mails.
L’utilisateur ne viendra jamais au chiffrement de lui-même. Jamais.
5. Le chiffrement doit venir à l’utilisateur.
Le web étant devenu synonyme d’internet, l’utilisation d’un client lourd n’est pas le meilleur choix pour faire adopter le chiffrement aux utilisateurs.
6. Le logiciel doit être une solution web.
(peu importe votre avis sur le développement du tout-web)
Le point 5. nous dit qu’une extension pour un navigateur ne serait un bon choix que si sa promotion est intégrée au sein même de l’expérience utilisateur du navigateur. Et que cette extension soit de confiance. Ou alors…
7. La solution de chiffrement doit être intégrée de base dans le navigateur.
Proposition
Ce qu’il faudrait donc c’est qu’un groupe qui développe un navigateur conçu pour protéger votre vie privée intègre une solution de chiffrement de base pour tous ses utilisateurs pour rendre le chiffrement accessible et visible pour tous.
(Tout ceci ne se baserait que sur GPG bien entendu)
Désillusion
Malgré tout, il ne faut pas oublier les trois premiers points :
1. Vous devez utiliser des clés de chiffrement.
2. Il faut que la gestion des clés soit faite par l’utilisateur.
3. L’utilisateur doit apprendre.
Ceci n’est pas un problème technique, et aucune solution technique n’y viendra jamais à bout. C’est un problème d’éducation.
Et le problème de l’éducation numérique est principalement qu’il n’existe pas.
Dans un monde où tout le monde utilise la technologie sans savoir comment elle fonctionne et se revendiquant presque un droit à l’ignorance, le chiffrement n’est pas quelque chose de simple à démocratiser.
Ceci n’est pas un problème technique, et aucune solution technique n’y viendra jamais à bout. (répétition ?)
Il reste également le problème des clés secrètes qui doivent être sécurisées, autant dire que c’est impossible pour l’utilisateur moyen, il faudrait donc des clés jetables (dont l’expiration est définie à la génération et immuable).
Le chiffrement n’est pas compliqué, il demande cependant un petit apprentissage et une bonne hygiène numérique. Si vous n’êtes pas prêt à faire cet effort, n’espérez pas utiliser du chiffrement.
(et vous pouvez pleurer, crier et vous rouler en boule autant que vous voulez, cela ne changera rien aux faits)
# autre exemple
Posté par Adrien . Évalué à 10.
En ce moment, il me semble que le HTTPS soit de plus en plus utilisé. Certes ça n'est pas parfait (autorités de certifications, etc.), mais ça augmente le niveau globale de sécurité.
Et ça fonctionne, car c'est transparent pour l'utilisateur dans la plupart des cas.
peut-être que ce fonctionnement est un compromis intéressant pour les emails ? Genre utiliser S/MIME au lieu de GPG permet de chiffrer sans rencontrer l'apprentissage nécessaire de GPG, malgré quelques inconvénients, mais déjà acceptés pour le HTTPS (autorité de certification).
S/MIME est une piste a creuser, mais malheureusement elle est systématiquement bannis par les geek de linuxfr au profit de GPG.
[^] # Re: autre exemple
Posté par Adrien . Évalué à 3.
typiquement je pense à des actions tels que : chiffrement ou signature des emails automatique des grosses boites, malus pour les emails non signés dans les notations de spam, fonction de recherche dans les emails chiffrés si elle n'existe pas, etc.
Ces actions sont a faire par des informaticiens, et non les utilisateurs, il y a donc une petite chance que ça passe…
[^] # Re: autre exemple
Posté par Ellendhel (site web personnel) . Évalué à 3.
En théorie on peut déjà s'appuyer sur DKIM pour cela : un certain nombre d'en-têtes de courrier peuvent être signés au niveau du serveur (après configuration par l'administrateur, rien à faire pour les utilisateurs) et le serveur du destinataire peut vérifier la signature (ou noter son absence) et décider d'un filtrage spécifique ou non. Je ne connais pas de statistiques à ce sujet, si c'est beaucoup utilisé ou non, mais c'est possible.
[^] # Re: autre exemple
Posté par Julien.D . Évalué à 3.
Oui, alors attention car en effet HTTPS est l'exemple que donne souvent les gens pour montrer que le chiffrement pour tous et sans apprentissage est possible.
Mais ce n'est pas tout à fait la même chose, car HTTPS nécessite aussi un échange de clé, sauf qu'il est transparent à l'utilisateur pour la simple raison qu'il se produit au moment de l'échange. Quelque chose qui n'est pas adapté au mail.
(A et B représentent des adresses mails et des comptes associés)
- A génère un couple de clé, dit à B qu'il souhaite une connexion chiffrée en joignant sa clé publique
- B génère un couple de clé, et envoie à A sa clé publique
- A envoie à B le message chiffré
- B peut déchiffrer le message de A, et lui envoyer une réponse chiffrée
(sans compter les attaques MITM)
En sachant qu'un mail peut mettre du temps à arriver ce n'est pas réaliste, mais cela fonctionnerait dans d'autres protocoles comme XMPP, c'est même le principe d'OTR.
Donc tout cela fonctionne très bien pour des échanges en temps réel, mais pas pour du mail par exemple.
S/MIME je ne connais pas trop, mais on ne peut pas critiquer les faiblesses des autorités de certifications et proposer S/MIME comme solution de chiffrement.
[^] # Re: autre exemple
Posté par Big Pete . Évalué à 4.
Oui, plus généralement, en HTTPS, tu n'authentifie pas l'utilisateur. L'authentification du type se fait généralement par un système de login/mot de passe sur le site.
ça rend la gestion des clés et de son identité numérique plus simple coté client. (mais bon, la sécurité des mots de passe, comment dire …) Bon, maintenant, si il faut authentifier aussi en SSL le client (Two Way ou Mutual SSL dans le jargon), c'est beaucoup moins simple, faut que le client gére ses certificats, ses clés, ben comme en PGP quoi …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: autre exemple
Posté par Le Gab . Évalué à 3.
Je pensais qu'on avait déjà TLS* depuis des lustres.
# Distribution des clefs
Posté par gouttegd (site web personnel) . Évalué à 8.
Tu oublies d’aborder le problème de la distribution des clefs publiques. C’est pourtant une question centrale dans tous les cryptosystèmes asymétriques : comment Alice récupère-t-elle la clef de Bob et comment sait-elle que c’est la bonne ?
Pour celui qui se plaint que S/MIME est « bannis par les geeks » : S/MIME n’est pas une réponse à cette question, le problème de la distribution s’y pose de la même manière que pour OpenPGP — si le problème est moins souvent mentionné pour S/MIME, c’est juste que ce dernier est généralement utilisé en milieu plus « contrôlé » qu’OpenPGP, typiquement dans une grande entreprise où les sysadmins peuvent gérer un serveur de clefs central et configurer les postes utilisateurs pour aller chercher les clefs dessus. C’est inapplicable dans le cas général d’utilisateurs non-liés entre eux par l’appartenance à une même organisation.
(Et S/MIME a ses propres problèmes, comme par exemple le fait qu’un certificat n’est lié qu’à une clef et une seule, ce qui implique notamment qu’on ne peut utiliser que RSA si on veut un certificat avec lequel on peut signer et chiffrer — sinon il faut un certificat pour la signature et un autre, complètement indépendant, pour le chiffrement…)
[^] # Re: Distribution des clefs
Posté par Julien.D . Évalué à 2.
Je pense que la protection de la clé privée pose plus de problèmes que la clé publique, mais les deux reste sensible mais avec des critères différents.
Si je devais proposer une solution réalisable à l'heure actuelle, elle ressemblerait à cela :
Une extension Firefox pré-installée qui permet de se connecter à son compte mail, génère un couple de clé, publie la clé publique sur un serveur de clé et peut chiffrer la clé privée avec un mot de passe.
Du coté expéditeur, lorsqu'on souhaite envoyer un mail à quelqu'un, on essaye de trouver une clé publique sur les serveurs de clé (pas fiable, car n'importe qui peut poster), mais l'extension proposerait à l'utilisateur d'envoyer un mail automatique pour recevoir la clé publique par mail. Cette partie de vérification de clé publique par envoi et réception de clé peut très bien être automatique.
Si un attaquant essaye de mettre une mauvaise clé sur les serveurs de clé, cela serait détecté par la vérification par mail.
En revanche, un fournisseur de compte mail peut très bien se faire passer pour vous sans vérification supplémentaire. Mais on peux très bien imaginer un système de niveau de sécurité :
0 : Pas de clé publique connue, chiffrement impossible
1 : Clé publique trouvée sur un serveur de clé, mais pas vérifier par mail
2 : Clé publique trouvée sur un serveur de clé et vérifier par mail
3 : Clé publique vérifier par un canal sécurisé
4 : Clé publique vérifier lors d'une rencontre physique
Ce n'est pas parfait mais il me semble que ça fonctionnerait pas mal, tout en restant accessible à tous
[^] # Re: Distribution des clefs
Posté par gouttegd (site web personnel) . Évalué à 4.
Pas vraiment d’accord. Les implémentations actuelles d’OpenPGP se chargent déjà de ça (ce n’est fiable que si la machine terminale est sûre mais c’est de toute façon à peu près ce qu’on peut espérer de mieux — aucune solution n’est fiable sur une machine compromise).
La généralisation du chiffrement est à mon avis beaucoup plus freinée par le problème d’utilisabilité que représente la distribution et l’authentification des clefs publiques que par la nécessité de protéger ses clefs privées.
Si tu considères la protection de la clef privée comme un problème important, en quoi ta solution fait-elle mieux que ce qui existe déjà ? Si protéger la clef privée, c’est juste la chiffrer avec un mot de passe, ça tombe bien c’est déjà ce que font toutes les implémentationsd’OpenPGP.
[^] # Re: Distribution des clefs
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Sur une machine de bureau, ça se tient.
Les problèmes se posent néanmoins lorsque l’on songe à utiliser sa clef depuis le courrier d’un téléphone (par ex. K9 le permet), ou depuis un webmail.
[^] # Re: Distribution des clefs
Posté par Larry Cow . Évalué à 2.
Dans ces cas-là, une piste de simplification serait à chercher du côté des sous-clefs. Pour l'instant, c'est un peu hardcore à fabriquer/déployer, mais on pourrait imaginer un système qui te permette de générer ta sous-clef et de la QRiser rapidement pour utilisation depuis OpenKeychain/APG.
[^] # Re: Distribution des clefs
Posté par Julien.D . Évalué à 2.
Ma solution (qui tient plus de la proposition car comme déjà expliqué n'est pas parfaite) est une réponse à la volonté de démocratisation du chiffrement des échanges entre utilisateurs, pas une amélioration de la sécurité des clés privées. Elle n'apporte donc rien de ce coté là, mais propose de faciliter l'accès au chiffrement aux utilisateurs.
[^] # Re: Distribution des clefs
Posté par Adrien . Évalué à 2.
Il me semble que si j'ai une clé S/MIME chez startssl, mes contacts qui utilisent thunderbird n'ont pas besoin de vérifier ma clé puisque l'autorité StartSSL est déjà incluse dedans. N'ayant pas vraiment utilisé S/MIME dans un contexte perso je me trompe peut-être ?
Pour moi c'est justement ça le gros avantage : les gens n'ont pas besoin d'échanger leurs clés, l'expérience utilisateur est donc clairement plus simple. Évidemment ça vient avec des inconvénients, mais il me semble que c'est tout de même mieux que pas de chiffremement du tout.
[^] # Re: Distribution des clefs
Posté par gouttegd (site web personnel) . Évalué à 8. Dernière modification le 10 juin 2015 à 11:10.
Non, mais ça ne résoud pas le problème. Tu as un certificat signé par StartSSL. OK, et si je veux l’utiliser pour t’envoyer un mail chiffré je le récupère comment ?
Les autorités de certification répondent au besoin d’authentification (enfin… oh et puis non, je ne vais pas redire tout le bien que je pense des CA, j’ai du boulot ce matin), mais pas à celui de la distribution.
Ce qui se fait typiquement en entreprise, à ma connaissance, est de distribuer les clefs dans un annuaire LDAP en même temps que les autres coordonnées des employés. Mais c’est indépendant de S/MIME (on pourrait très bien faire la même chose avec des clefs OpenPGP, si les entreprises utilisaient OpenPGP plutôt que S/MIME), et c’est justement parce que S/MIME ne résoud pas, en lui-même, la question de la distribution qu’il faut mettre en place ce genre d’annuaire.
Si, justement.
[^] # Re: Distribution des clefs
Posté par Adrien . Évalué à 2.
effectivement, j'avais mal pigé le problème de la distribution du certificat.
Merci pour cet éclairage !
# Gestion des clés
Posté par RoyalPanda . Évalué à 3.
Comme souligné dans ce journal, le plus gros problème est la gestion des clés. Et à mon avis, le seul moyen de réussir à faire passer ça ce sera quand l'utilisateur n'aura pas besoin de gérer les clés.
Je m'explique : En gros, il faut un outils pour générer des clés jetables qui serait certifiée par l'identité de la personne qui lit le message. La personne devenant la clés plus que la clés elle-même. C'est la dessus que travaille Google et sûrement d'autres entreprises. La meilleure solution est toujours la plus simple, pour l'utilisateur bien sûr.
[^] # Re: Gestion des clés
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si tout les mails sont signés, répondre est facile, la clef est indiqué dans la signature.
Donc répondre en crypté à un mail signé est un non problème. On n'est pas sûr de la personne derrière le mail, mais on sait que l'on parlera toujours à la même personne.
Ensuite, il "suffit" de vérifier le fingerprint avec la personne. Un peu comme quand tu appels une personne pour lui filer ton numéro, celui-ci te le dicte pour vérifier. C'est vrai, c'est plus simple avec un téléphone portable, qu'avec un PC.
"La première sécurité est la liberté"
[^] # Re: Gestion des clés
Posté par maboiteaspam . Évalué à 1.
Donc autant faire comme les micro paiements par mobile,
échange de clefs par téléphone.
Le téléphone peut ensuite servir à synchroniser le PC et charger le nouveau contact.
Si le Pc est capable d'afficher des mails cryptés au format qrcode, le téléphone peut dès lors prendre une photo pour lire puis révéler le message.
Pour ce qui est de l'échange de clefs en ligne, il faut une communication en deux étapes de la part de l'utilisateur.
Première étape, l'introduction, échanges de clefs.
Deuxième étape, communication du contenu utile entre les deux agents.
Ne restent plus alors qu'à prouver son identité.
Ce qui dans l'illustration première du téléphone n'est pas utile, puisqu'il y a contact physique, donc vérification de l'identité.
Rien de très compliqué en fait, non ?
[^] # Re: Gestion des clés
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Y'a plus cas :)
Le plus dure sera sans doute de rester compatible gpg pure, ou juste "compatible enigma".
"La première sécurité est la liberté"
[^] # Re: Gestion des clés
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est exactement ce que j'allais proposer. Tous les courriels sont signés, cela ne coûte rien. Une fois en possession de la signature de la personne dans tes contacts, il est très facile de lui répondre avec un courriel signé et chiffré.
Il est important de rajouter dans le protocole la gestion du changement de signature car les clefs ne sont pas éternelles. Chose qui avait été oublié par exemple dans ssh.
Donc au final, un premier échange en clair mais signé pas confidentiel puis tout devient confidentiel automatiquement…
[^] # Re: Gestion des clés
Posté par gUI (Mastodon) . Évalué à 2.
… où l'on se rendra compte que finalement, l'échange physique de clés, ça reste le top.
C'est pas toujours faisable, et justement, il en découlera une communication moins sécure. On le sait, c'est comme ça.
J'aime bien l'idée finalement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Gestion des clés
Posté par RoyalPanda . Évalué à 1.
Pour information, je ne parlais pas tant des clés publiques qui peuvent être misent sur un serveur tiers de confiance, mais des clés privées que seul l'utilisateur doit connaître et conserver. C'est là tout l'enjeu. Et c'est cet effort la qui est difficile à faire. Et qui ne sera jamais fait, soyons en certain. Donc il faut trouver un autre moyen, ou les clés peuvent être perdues, ignorées etc… Donc, si la clé n'est plus le moyen d'identifier à coup sûr l'utilisateur, alors il faut que l'identité de l'utilisateur soit vérifié autrement.
# Et les métadonnées ?
Posté par Jean-Baptiste Faure . Évalué à -1.
À quoi cela sert-il de chiffrer ses mails si ce qui intéresse vraiment les espions ce sont surtout les métadonnées, à qui tu écris, quand, de qui tu reçois, quand, etc.
[^] # Re: Et les métadonnées ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si la liaison entre serveur de mail passe par TLS, le destinataire est crypté non ?
"La première sécurité est la liberté"
[^] # Re: Et les métadonnées ?
Posté par Jean-Baptiste Faure . Évalué à 5.
Si j'ouvre un mail chiffré avec un éditeur de texte, je peux voir tous les entêtes, il n'y a que le corps du mail qui est chiffré. D'ailleurs Thunderbird me montre bien qui est l'expéditeur, la date et le sujet sans que j'ai besoin de déchiffrer le message. Sinon comment le mail pourrait-il être acheminé à son destinataire sans que tous les serveurs par lesquels passent chaque paquet composant le mail ne connaissent la clé de déchiffrement ?
[^] # Re: Et les métadonnées ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je parle de la deuxième couche entre serveur mail.
"La première sécurité est la liberté"
[^] # Re: Et les métadonnées ?
Posté par Paulo (site web personnel) . Évalué à 2.
Elle n'est déployée, justement, qu'entre serveurs SMTP. Les messages transitent en clair dans les serveurs, ce qui offre des garanties de confidentialité assez limitées. Pire, en pratique elle ne fonctionne que contre les attaques purement passives.
En effet, elle est très souvent opportuniste, et on peut forcer deux serveurs à ne pas activer la couche TLS. C'est malheureusement ce que recommande la RFC 3207: "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.".
En plus, aujourd'hui, les MTA ne vérifient en général pas que le certificat présenté correspond bien au serveur distant, car en général, ce n'est pas le cas. Il suffit alors d'avoir un certificat valide pour n'importe quel domaine sous la main pour faire un MIM.
# Droit à l'ignorance
Posté par Maclag . Évalué à -1.
Pas presque, le commentaire de Zenitram vers lequel tu pointes dis que l'utilisateur revendique complètement un droit à l'ignorance.
Et oui, pour un geek, ça fait mal, mais pour l'utilisateur final, la logique est légèrement différente:
On est en 2015, et la machine n'est toujours pas foutue de faire son boulot correctement toute seule??
De même que le commun des mortels ne sait pas comment fonctionne le moteur de leur voiture alors que imagine une seconde qu'il y ait une grosse fuite d'admission de carburant, un incendie serait vite arrivé. Alors tout le monde devrait être capable de faire cette vérification simple et la faire à chaque démarrage de la voiture, non? Question de sécurité!
Ben non. Ça devrait marcher point barre, c'est bien pour ça qu'on achète les produits et qu'on ne les fait pas nous-mêmes.
L'utilisateur ne devrait pas avoir à apprendre. Ça doit juste marcher!
[^] # Re: Droit à l'ignorance
Posté par Michaël (site web personnel) . Évalué à 10.
Comme d'habitude la comparaison avec la voiture a une pertinence assez limitée: ce qui coince, ce n'est pas que les gens ne s'intéressent pas à l'admission du carburant, mais que les gens ne voient pas trop bien l'intérêt de rouler en voiture, alors à quoi bon passer le permis? La problématique de la démocratisation de la cryptographie dans les correspondances électroniques est essentiellement que:
Dans mon entourage, je vois que:
Les gens motivés par une fonctionnalité d'un logiciel utiliseront le logiciel, et si le logiciel est merdique et a des limitations absurdes, ils l'utiliseront quand même s'ils sont assez motivés et n'ont pas le choix. (Déjà vu: un logiciel de montage vidéo qui a une super fonction de découpe que son concurrent payant n'a pas, qui est gratuit mais qui plante toutes les 5 minutes, et met une bonne minute à démarrer — peut-on imaginer un truc plus gavant à utiliser?)
Les gens motivés par l'utilisation de moyens cryptographiques, soit pour protéger certaines informations concrètes, soit pour des raisons de principe, apprennent à utiliser PGP (via l'intégration à Apple Mail ou à Thunder Bird). Il y a des tonnes de tutos là-dessus et de forums d'entraide.
Bref, si les gens ne s'en servent pas c'est que l'effort à fournir est trop grand par rapport à l'utilité perçue. On peut travailler sur deux plans. Soit on peut diminuer l'effort à fournir, ce qui me paraît difficile puisque le chiffrement à clef asymétrique a une part de complexité qui est irréductible — en plus de l'email de son destinataire, il faut sa clef (qui a un niveau de confiance, une date d'expiration, qu'on va piocher sur un serveur, qu'on vérifie, etc.) — et même si cette complexité est très bien prise en charge par un logiciel (au passage les extensions PGP pour Apple Mail et Thunderbird font un travail raisonnable d'après moi), cela ne la fait pas disparaître. Soit on peut augmenter l'utilité perçue: c'est une question qui a des composantes politiques, économiques et morales, mais pas du tout techniques.
[^] # Re: Droit à l'ignorance
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 11 juin 2015 à 12:36.
Rigolo cet exemple, car je connais de plus en plus de monde ne voyant pas l’intérêt (par rapport à se faire chier à apprendre à conduire) de la voiture et du coup ils ne passent pas le permis (ou ne font plus l'effort de "se maintenir à jour" et oublient comment ça marche). Comme quoi…
Bof. Pour reprendre l'exemple de la voiture, les américains passent un permis plus simple (boite auto) et nous européens on s'emmerde toujours à passer un permis boite manuelle pour le plaisir ("politique") alors que la technique permet la boite auto. A mon avis, si il y avait plus de boites auto, il y aurait moins de gens qui se posent la question de ne pas passer le permis car trop chiant.
Et quand on les voiture toutes auto (conduite incluse) vont arriver, tu auras encore moins de gens à passer le permis "car ça marche sans se faire chier".
L'exemple des clés physiques est aussi bien, car je vois de plus en plus de monde avec des clés "électronques" pour les parties communes (plus facile à convaincre, mais ça commence aussi à arriver pour la porte d'entrée) qui permettent la perte de la clé (un coup de fil, et hop clé désactivée), bref la technique pour simplifier la vie de l'utilisateur plutôt que de lui dire "tu dois en chier, on aime ça, il faut que tu mérites".
La politique/culture et la technique sont mélangées.
Ici (chiffrer, déjà rigolo car on parle de "utiliser GPG" qui est un moyen et non un objectif de l'utilisateur qui n'a absolument rien à foutre de GPG, ça serait toto que ça lui ferait le même effet), la technique est trop merdique par rapport à l’intérêt, tu veux jouer sur augmenter l’intérêt plutôt que de diminuer la complexité, bonne chance, perso je n'y crois absolument pas.
PS : et oui, je revendique clairement mon droit à l'ignorance, sans "presque". Le fait que ce soit vu comme quelque chose de négatif dans le journal montre toute l'incompréhension, et tant qu'il y aura des journaux de ce type, rien n'avancera : le problème n'est pas chez les utilisateurs, il est chez ceux qui disent vouloir généraliser une chose mais qui n'essayent pas de comprendre les gens. Bref, revendication claire et assumée, merci de ne pas mettre "presque" dans la phrase.
[^] # Re: Droit à l'ignorance
Posté par Michaël (site web personnel) . Évalué à 3.
J'en fais d'ailleurs partie :D
Je ne veux rien du tout, j'essaie juste de comprendre pourquoi GPG ne prend pas et ce qu'on peut faire si on veut changer ça. Je ne vais pas tout réécrire mais une solution cryptographique GPG ou autre, sans tiers de confiance, est plus compliquée qu'un simple échange de message. Donc oui c'est plus compliqué, et c'est la vie!
Le but ce n'est pas l'ignorance, c'est l'abstraction: on veut en général interagir avec quelque chose de façon abstraite, c'est l'habitude! :)
[^] # Re: Droit à l'ignorance
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
C'est un peu idyllique et faisant fi du revers de la médaille : pour la voiture électronique on peut déjà citer les attaques sur le RDS, sur l'électronique de bord, etc. ; pour les clés électroniques on peut citer les attaques contre les passes de chambres d'hôtel et aussi les serreurs de voitures, etc. Le fait d'être contactable à distance rend possible d'être contacté à distance, y compris par des gens hostiles. Le fait d'être intelligent/électronique rend possible des attaques répétables/massives. Avant on pouvait saboter tes freins et crocheter ta serrure ; maintenant on peut saboter tes freins, tes phares, ton autoradio et ton allume-cigare à distance, et déverrouiller ta porte, ainsi que de plein d'autres véhicules/maisons en même temps. En espérant que les méchants ne le soient pas trop. Et que les gens mettent à jour leur voiture et leur serrure…
Le fait de ne pas comprendre comment ça marche permet de vendre du rêve, de la guerre propre, du vote électronique, du nucléaire bio, de l'ordinateur parfait, de la vidéoprotection, etc.
Bref faciliter la vie de l'utilisateur oui, lui masquer toutes les problématiques associées non. Il y a un nuancier allant du blanc au noir et de l'acceptation béate à la paranoïa totale.
[^] # Re: Droit à l'ignorance
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 11 juin 2015 à 19:04.
Oui.
et tu fais croire que ça arrive tous les jours.
Pas de pot, les gens voient que ce n'est pas le cas.
Ton discours est le même que les gens qui avaient peur du méchant Internet et il ne faut pas filer son numéro de CB à un vendeur.
Mais pas de pot, la sécurité s'est adapté aux utilisateurs (et non l'inverse… Mais faut-il encore le dire?) et maintenant Amazon est un ogre qui vend, qui vend… Les gens se sont rendu compte que ceux qui colportaient des "bouh, tu vas te faire piquer ton numéro de CB", ben oui, ça arrive, mais pas plus que de te faire voler ta CB physiquement, et les gens "attention" sont juste vu comme ridicule.
Toi, tu vois quelques problèmes et dit qu'il faut que les utilisateurs s’adaptent. A mon avis, mais c'est que le mien, tu es juste vu comme en râleur et d'autres vont se charger de simplifier la vie des utilisateurs avec pas moins (mais pas plus) de sécurité qu'avant, même si tu t'amuses à sortir 2-3 exemples par ci par la pour t'autoconvaincre.
Pas de soucis, continuez à prendre les gens pour des "cons qui doivent apprendre", en attendant le monde avance (sans vous) avec des technologies pire que ce que vous auriez proposé (Apple etc…) mais qui au moins marchent (=sont utilisables).
A faire les gens qui considèrent les autres comme des gamins qui doivent apprendre, vous permettez simplement à d'autres de proposer leur technologies, qui résout le problème (tout en enfermant un peu l’utilisateur chez eux, mais ça n'a pas l'air de vous déranger, pas assez du moins pour mette vos "principes" de côté et proposer une alternative viable, les principes sont plus importants).
Hier le paiement par CB sur Internet, aujourd'hui les clés electroniques, et demain encore un autre truc, mais ça va continuer tranquillement… En virant ces "technologies" qui sont tout sauf utilisables et en les remplaçant par ce que veulent les gens qui comprennent comment fonctionne le monde.
Merci pour la démo, on sait pourquoi Linux ne dépasse 1% de part de marché et pareil pour d'autres technologies "utiles" (mais inutilisables en fait).
Le problème n'est pas l'utilisateur, loin de la, le problème est de celui "qui sait" mais qui est tellement dans son monde qu'il voudrait que tout le monde soit à son niveau, forcément ça ne va pas marcher (tout le monde n'étant pas passionné par la même chose).
[^] # Re: Droit à l'ignorance
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Prends toi un grand verre d'eau, respire, je dis juste que ça ne doit pas être passé sous silence.
[^] # Re: Droit à l'ignorance
Posté par Zenitram (site web personnel) . Évalué à -5.
Prends toi un grand verre d'eau, respire, je dis juste que ça ne doit pas être agrandi comme tu le fais en méthode "je veux faire peur pour continuer à cautionner les gens qui refusent de simplifier au nom d'une demande d'apprentissage".
Oui, c'est facile le copier-coller, donc tu ne devrais pas le prendre mal.
[^] # Re: Droit à l'ignorance
Posté par Julien.D . Évalué à 0.
Je n'ai pas lu de réaction de ta part face à la proposition du journal, en aurais-tu une ? Car là il y a bien un effort d'aller vers l'utilisateur pour lui permettre de chiffrer ses mails avec plus de facilité.
[^] # Re: Droit à l'ignorance
Posté par Zenitram (site web personnel) . Évalué à 1.
quelle proposition?
Tu as cherché… Je n'ai rien dit car il n'y a simplement rien dans le journal, et même ce "rien" va complètement à l'encontre de comment on peut réussir à avoir 25% d'utilisateur ("Ceci n’est pas un problème technique (…) C’est un problème d’éducation", sérieux tu as lu ce que j'ai écrit ici avant de dire que je n'ai pas de réaction au journal? Tu as déjà ma réaction à cette phrase…)
Bref, tu attends quoi d'un journal qui va partir ensuite dans l'oubli et que personne ne va rien faire?
[^] # Re: Droit à la connerie
Posté par Marotte ⛧ . Évalué à 2.
:)
[^] # Re: Droit à l'ignorance
Posté par groumly . Évalué à 3.
Et pourtant, apple a implemente un chiffrement end to end avec imessage. Ils sont incapables de voir les messages passer, et le fbi/cia chient dans leur bennes a cette idee.
C'est pas impossible a faire, mais le probleme est effectivement pas franchement technique, mais politique. Le mail, c'est des milliards de personnes sur un protocole pourri que personne ne veut toucher.
Si tu veut amener le chiffrement pour tous, c'est la dessus qu'il faut travailler (i.e. se debarasser entierement de smtp), pas sur l'education des gens. Et meme les gens eduques font des bourdes (les linuxiens si au fait des pratiques qui vont aller ajouter un ppa des bois a leur distro, par exemple).
Apres, ca veut pas dire que l'education est une mauvaise chose, mais si tu comptes principalement sur ca pour resoudre le probleme, t'es pas sorti de l'auberge.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Droit à l'ignorance
Posté par Ytterbium . Évalué à 3.
Mais c'est quoi la solution technique proposée par Apple pour gérer l'échange de clés et l'authentification ? Parce que d'après ce tableau de l'EFF, l'authentification n'est pas garantie par iMessage, ce qui est l'une des raisons de la complexité de gpg.
[^] # Re: Droit à l'ignorance
Posté par oinkoink_daotter . Évalué à 4.
Parce que c'est Apple qui met en relation les devices, même si les clefs sont générées en local. Donc théoriquement rien n'empêche Apple de se faire passer pour toi auprès de ton correspondant et vice versa. En pratique Apple dit qu'ils ne peuvent pas le faire, mais c'est improuvable.
[^] # Re: Droit à l'ignorance
Posté par Zylabon . Évalué à 7. Dernière modification le 11 juin 2015 à 01:12.
C'est grossier… L'utilisateur… Il y a des centaines de profils d'utilisateurs différent. Quel sens ça a de vouloir tous les réduire à un utilisateur, et quel utilisateur ?
J'aimerais bien en rencontrer un jour, un représentant de ce fameux "l'utilisateur", ces fameux monsieur et madame Michu qui veulent juste cliquer et que ça marche, se foutant de tout le reste.
Les gens que je rencontre sont curieux, lors qu'ils ne parviennent pas à faire quelque chose, ils blâment leur incompétence et pas non le logiciel, même en cas de bug manifeste. Les gens sont généralement curieux, et modeste, ils vont chercher à s'adapter à l'outil, et s'il se trouve être complètement merdique, ils ne le remarquent même pas.
C'est sur l’existence massive de ces "l'utilisateur" que repose une partie signifiante des arguments de Zenitram, et franchement, je trouve cette hypothèse assez irréaliste.
Bien entendu, Zenitram n'a pas le monopole de l'ignare madame michu agitée comme un épouvantail dès qu'un l'utilisation d'un logiciel nécessite plus de 5 secondes pour être pris en main.
Bref à ces gens là je demande : montrez nous ces fameux utilisateurs dont vous parlez tant ou arrêtez de polluer les débats avec ces chimères.
Please do not feed the trolls
[^] # Re: Droit à l'ignorance
Posté par gouttegd (site web personnel) . Évalué à 8.
Attention à ne pas tomber dans la généralisation inverse : l’utilisateur dépeint par Zenitram et Maclag existe aussi.
Personnellement, parmi mes collègues, j’ai aussi bien des utilisateurs « qui veulent juste cliquer et que ça marche »¹ que des utilisateurs « curieux, blâmant leur incompétence lorsqu’ils ne parviennent pas à faire quelque chose ».
¹ Au passage, pour ces utilisateurs-là, même les Mac et leur légendaire simplicité d’utilisation dont on nous rabat les oreilles sont des « putains de bécane de merde qui ne marchent jamais comme il le faudrait ».
[^] # Re: Droit à l'ignorance
Posté par Maclag . Évalué à 5.
Je ne sais pas dans quel environnement tu vis, mais n'ayant aucun informaticien dans mon environnement quotidien, ni aucun geek d'ailleurs, je peux te dire que l'utilisateur qui en sait peu et ne veut pas savoir, c'est quasi 100% de mon entourage à la maison, au boulot, etc.
Les gens ne sont pas curieux ni modestes. La modestie n'entre même pas en ligne de compte ici: ça doit juste marcher. Qu'est-ce que mon égo vient foutre là-dedans?
Si la voiture ne démarre pas, on ne va pas chercher la caisse à outils, on appelle au secours.
Si on a une fuite d'eau, on ne prend pas des cours de plomberie accélérés, on appelle le plombier.
Si l'utilisateur est tellement curieux et adaptable, pourquoi diantre est-ce que toutes les solutions qui consistent à réinventer la roue en plus simple marchent tellement mieux sur le marché? Ils sont cons ces éditeurs, il feraient mieux de rajouter pleins de fonctions très difficilement utilisables mais pratiques, ça cartonnerait, non?
Ben visiblement non: Linux est toujours très bas dans les parts de marché!
Et encore une fois, on peut appliquer le même raisonnement à toutes les disciplines, dans lesquelles les passionnés t'expliqueront que "c'était mieux avant", "change tes plaquettes de frein toi-même", "je comprends pas qu'on puisse vivre dans une maison dont on ne sait rien sur la plomberie!!"
Les questions de sécurité informatique ne sont pas les plus importantes de l'Univers de tout le monde!
[^] # Re: Droit à l'ignorance
Posté par gouttegd (site web personnel) . Évalué à 5.
Je ne suis pas passionné de plomberie, mais non, en effet, je ne comprends pas. Surtout quand en cas de fuite, on attend bêtement que le plombier arrive sans rien faire, sans même couper l’arrivée d’eau principale parce qu’on ne sait même pas où elle se trouve !
Revendiquer un droit à l’ignorance, OK. Mais quand ça affecte le voisin du dessous dont le compteur électrique se retrouve inondé et mis hors d’usage, ce n’est plus de droit à l’ignorance mais de comportement irresponsable dont il est question.
(Oui, c’est du vécu.)
Désolé, mais seuls les ermites vivant loin de toute civilisation ont droit à l’ignorance totale. Vivre en société nécessite de savoir un minimum de choses, dès l’instant où tes actions (ou inactions) ont des conséquences sur tes congénères.
[^] # Re: Droit à l'ignorance
Posté par Maclag . Évalué à 2.
Et donc savoir utiliser GPG est du même niveau basique fondamental requis pour vivre en société que savoir couper l'arrivée d'eau?
[^] # Re: Droit à l'ignorance
Posté par gouttegd (site web personnel) . Évalué à 3.
Où ai-je dis ça ? Je répondais juste à la revendication du droit à l’ignorance, qui d’après toi va jusqu’au droit de ne rien connaître de son appartement, parce qu’il y a des plombiers/électriciens/whatever dont c’est le boulot et à qui on peut se contenter de faire appel sans lever le petit doigt.
[^] # Re: Droit à l'ignorance
Posté par steph1978 . Évalué à 10.
Ce que tu vois comme un droit à l'ignorance, je le vois comme une condamnation à l'ignorance.
Ce que tu décris c'est une volonté des industries qui arrivent à faire croire aux utilisateurs que c'est le bon modèle : "il faut juste que ça marche". Autrement dit "vous inquiétez pas on s'occupe de tout". Au point qu'il va bientôt être illégale de bricoler sa voiture sous peine de violation de copyright.
Je revendique le droit de savoir comment ça marche !
[^] # Re: Droit à l'ignorance
Posté par Maclag . Évalué à 3.
Ah ben là on a un problème fondamental.
Je ne décris pas une volonté des industries de te brider avec un complot mondial.
Je décris ce que veulent les utilisateurs: que ça marche sans les emmerder!
Et je ne vois pas en quoi c'est incompatible avec ton accès à ce qui se passe sous le capôt. Ce sont deux problèmes différents.
La simplification n'impose aucune fermeture.
Si tu penses comme ça alors on n'a pas fini d'agiter la ligne de commande en épouvantail: imagine qu'on en ait plus besoin? Ce serait une volonté des éditeurs de te cacher les commandes? Il vaut mieux donc qu'elle soit indispensable?
[^] # Re: Droit à l'ignorance
Posté par steph1978 . Évalué à 1. Dernière modification le 11 juin 2015 à 06:32.
Doublon
# Protonmail
Posté par elloco (site web personnel) . Évalué à 3.
Salut,
Comme je l'indiquais en réponse d'un autre post juste avant.
En se basant sur des solutions comme https://protonmail.ch/ (il en existe probablement d'autres mais je ne connais que celui-ci) on résout ce problème de la gestion des clés. Les clés sont générées côté client. La clé privée est chiffrée avec votre mot de passe. Le tout est ensuite envoyé au serveur de Protonmail qui se chargera de gérer les clés à votre place.
Comme indiqué dans l'article, passer par un service web n'est pas la meilleure solution, c'est vrai. Mais si ça permet de faire connaître le chiffrement de données aux gens et qu'ils prennent conscience que c'est important, alors c'est un pas dans la bonne direction.
Revenez 10 ans en arrière, les gens ne savaient pas à quoi correspondait le s à https. Maintenant, de plus en plus de gens ne s'imagineraient pas se connecter à leur compte Facebook en http.
[^] # Re: Protonmail
Posté par Inso . Évalué à 7.
"Maintenant, de plus en plus de gens ne s'imagineraient pas se connecter à leur compte Facebook en http."
Ahah… Amha, personne ne ferait attention au fait de se connecter à fb en http.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.