rakoo a écrit 932 commentaires

Ceci dit, j'imagine qu'avec un proxy, on peut changer cela, le proxy faisant office de passerelle d'internaute, c'est lui qui déchiffre les informations

Bien sur ça existe, et il en parle même dans l'article: le déchiffrement dégraderait les performances de 74%. C'est une des raisons qui fait qu'il est contre.

Elle s'applique aux données binaires.

Il existe, mais passe par feedburner.

Ou alors, peut être que c'est juste les gens de ta boite qui étaient nuls, rien a voir avec les chinois ?

J'utilise moi-même yaxim que je trouve beaucoup plus stable que Chatsecure, même s'il ne propose pas l'OTR.

Enfin, quand je dis utiliser, c'est qu'il est installé et prêt à l'emploi, mais ça va rarement plus loin…

Ouais mais ça le faisait moins, sur le coup.

Comme dit en dessous, c'est DANE. Le problème de DANE est qu'il part du principe que les enregistrements DNS arrivent intacts depuis le NS du domaine jusqu’à chez toi, ce qui est pour le moment hautement illusoire. Il faut utiliser DNSSEC (ou autres) pour acheminer les enregistrements, mains DNSSEC c'est une autre paire de manches a installer et maintenir.

Ou alors se reposer sur un truc style protocole bitcoin (ou bitcloud ! http://bitcloudproject.org/) pour stocker la clé de validation ?

Et bien justement, dnschain permet ça. Le principe est simple: il y a deja des specifications pour enregistrer ses noms de domaines et son identite dans Namecoin. Malheureseument Namecoin c'est son monde a part avec son client specialement fait pour. C'est la que dnschain fait le pont, puisqu'il permet d'acceder aux informations depuis des moyens connus:

$ dig @dns.dnschain.net okturtles.bit

$ curl http://dns.dnschain.net/d/okturtles

J'ai souvent entendu ce "mais de toute façon mon site c'est juste du contenu public, statique". La tu pars du principe que passer en HTTPS a un cout non négligeable. Je pense au contraire que le cout est négligeable (je ne prends pas en compte la cabale mondiale des CA qui est un non-sens total) et qu'il faudrait plutôt expliquer pourquoi rester en HTTP.

Comme dit plus bas, dans le pire des cas, HTTPS non authentifié est moins pire que HTTP tout nu, et pourtant le deuxième ne lève aucun avertissement. Parce qu'en fait, ton problème, c'est pas tant HTTP vs HTTPS: c'est surtout que tu veux pas avoir a cliquer de bouton en plus juste pour lire ce satané contenu. Il faudrait donc inverser la réaction du navigateur entre HTTP tout nu et HTTPS non authentifié: le premier pose de gros problème, le deuxième est potentiellement dangereux mais on laisse l'utilisateur juger si le site est le bon ou pas.

Sinon dans les avantages, j'en vois un autre intéressant quand même: tu es sur que le contenu n'a pas été modifié. Encore une fois, depuis l'endroit ou se situe la clé privée associée au certificat.

à moins de réorganiser en permanence ses données défragmenter

"Mes collègues sont tellement formidables que j'amène des croissants demain matin pour les remercier!"

Du coup, y'aurait pas moyen de mettre un bouton "c'est du foutage de gueule, réécrivez-moi ça" ?

Et ben pour le coup je vais citer mon langage préféré du moment, mais qui a l'avantage de répondre au cahier des charges: Golang.

Je pense que Go remplacerait avantageusement C++ ici:

• extrêmement simple, la spec tient sur une page. Pas besoin de la lire, c'est juste pour dire que c'est extrêmement simple à apprendre pour quelqu'un qui sait déjà programmer, donc plus simple que C++ pour un débutant complet
• il a toutes les fonctionnalités "standard" attendues d'un langage impératif tout en gardant une syntaxe assez proche (c'était d'ailleurs un des buts des créateurs: un langage qui ressemble au C)
• la distinction est claire entre valeurs et référence, modulo les appels de fonctions qui se font tous avec .. À part ça les signatures des fonctions indiquent clairement ce qui est attendu
• typé, statiquement si les choses sont faites correctement
• le compilateur est extrêmement rapide et affiche des erreurs de compilation sont (subjectivement) claires
• une lib standard extrêmement fournie, il y a peu de chances qu'ils aient besoin d'une dépendance externe pour quoi que ce soit
• s'ils veulent faire les choses proprement, il y a tout ce qu'il faut pour se faire ses tests (unitaires ou non), son benchmarking et même son profiling avec la librairie standard. Super intéressant pour comprendre pourquoi une fonction prend autant de temps, ou pour commencer à toucher du doigt les allocations mémoire et voir où partent les précieux octets de la RAM.

Par contre, tout ce qui parle de concurrence (les channels, go) doit à mon avis être évité pour des débutants complets parce que ça ne leur apportera pas grand chose et ne se transposera pas facilement dans d'autres langages.

Ça dépend où tu arrêtes l'apprentissage, pour moi l'intérêt qu'il soit répandu est que tu trouveras plus facilement des libs pour aller plus loin et, surtout, de l'aide. Je pars du principe que l'apprentissage ne s'arrête pas au cours, mais c'est peut-être parce que dans le cas de la programmation je suis biaisé…

Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil

Si on reste dans le contexte "Premier langage pour apprendre la programmation", ie le sujet du 'nal, ça a du sens de chercher un langage plus répandu.

chiffrer avant de toucher le serveur n'est pas suffisant.

Et encore, il faut être sur que la clé n'est pas envoyée au serveur. Et comme le client de SpiderOak n'est pas open source, aucun moyen d’être sur.

Et bah ça doit faire un bail que t'as pas essaye alors, parce que moi je me sers très souvent de la recherche sur serveur et ça marche comme voulu. Mon compte est un Gmail, mais je pense pas que ça change quoi que ce soit.

reprendre K9mail (client libre sur android) et de lui ajouter le chiffrement de bout en bout ?

Ça existe déjà avec la combinaison K9mail + APG.

Seul (gros) défaut: APG ne fait que du chiffrement inline et pas via Multipart, ce qui donne un truc moche quand le MUA ne comprend pas PGP (c'est-à-dire l'énorme majorité des cas). Plus d'infos ici.

À part ça, ça marche tip top.

OK, je note : faire une chose gratuitement excuse de tout.

C'est pas une excuse, c'est une explication. Quand on reçoit un service de bénévoles qui font sur leur temps libre, faut pas s'attendre a un niveau de qualité maximale. Non pas que ça soit normal; juste, faut pas s'attendre a la lune.

Le passage en question:

À la croisée des libertés publiques et des enjeux économiques, la confrontation peut directement opposer un opérateur de l’Internet à un État: Twitter en Turquie. Ainsi le gouvernement turc, estimant que la souveraineté et l’intérêt national transcende les intérêts commerciaux, estime légitime de bloquer certains sites Internet et de leur demander d’installer une
représentation dans le pays qu’ils opèrent. Devant cette situation, Twitter a fait le choix de ne pas s’installer afin de ne pas s’exposer à la législation turque. Il est intéressant de noter qu’une entreprise étrangère défie directement le gouvernement de l’État dans lequel elle propose ses services en adressant un tweet à ses utilisateurs turcs contenant une procédure de contournement des mesures de blocage.

Je vois pas en quoi le rapport prône cette censure, il ne fait que citer l'affaire en restant assez neutre (la sous-partie est intitulée Des acteurs privés en passe de défier les États)

J'ai pas lu le reste, mais pour le coup je veux bien croire qu'il est assez nationaliste (ou plutôt européaniste), ne serait-ce que dans le titre: L'Europe au secours de l'Internet.

À l'usage, ce n'est pas un peu le bazar d'avoir une partie du JS mêlée au HTML ?

Il est temps de se demander vraiment ce que veut dire réellement la séparation des activités. Je sais pas si tu as déjà vu des applications web un peu grosses, mais dans la soi-disant couche "présentation" (ie HTML), il y a toujours un bout de "logique" (un semi-langage en plus, pas HTML mais pas javascript, qui permet de définir le contenu final en fonction des données, qui boucle sur ces données, etc…). La seule séparation qui existe vraiment dans ces cas-là est la séparation des langages, ce qui n'est pas intéressant du tout.

Je t'invite à regarder cette vidéo, présentée par l'un des types derrière React. Il y parle du framework, mais il invite surtout à réellement réfléchir sur ce que tu veux faire pour ton application: l'historique des technos web fait que tu veux naturellement séparer HTML, CSS et JS mais en fait ce qui t'intéresse réellement c'est séparer ton application en composants interopérables et réutilisables, quelles que soient les technologies/langages/frameworks que tu utilises pour les créer.

L'exemple proposé s'écrit facilement avec le standard jQuery.

C'est un exemple; je pense qu'il faut voir ça à l'usage, sur des applications un peu plus grosses.

gatejs est un proxy, c'est a dire qu'il fait du MitM, sauf que l'utilisateur est d'accord. Du coup quand un client veut faire du TLS avec un serveur, elle ne sécurise plus les applications jusqu'au bout mais seulement jusqu'au proxy, qui va lui se charger de chiffrer les données jusqu'au serveur distant. Le truc c'est que pour signaler que le proxy est de confiance, il faut bien le dire d'une manière ou d'une autre sur le client.

Le problème, c'est quand il n'y a aucune flexibilité dans les certificats gérés par l'applicaiton, et que celle-ci interdit tout intermédiaire…

Han j'ai lu un peu trop vite, je croyais que tu parlais de donner un TLD par personne, en référence a ceux qui n'ont pas la chance d'avoir un nom de domaine pertinent dans un TLD existant et qui du coup ont demande un TLD rien qu'a eux. Mea Culpa.

Supaire.

Comme ça, au lieu d'avoir un beau système hiérarchique qui est techniquement capable de tourner a l’échelle de la planète, chacun des serveurs racines devra avoir une ligne par être humain. C'est sur, ça va marcher du tonnaire.

C'est ça qui m’embête avec la multiplication des TLDs: on s’écarte de plus en plus du système de délégation qui permet le dynamisme qu'a connu internet jusqu’à aujourd'hui, pour en revenir a un système ou chaque décision est prise unanimement par l'ICANN.

C'est vrai, Go n'est pas adapté aux plateformes limitées en mémoire. C'est pourquoi j'ai prévu de garder le protocole simple pour qu'il puisse être ré-implémenté par d'autres si nécessaire (et puis ça me donnera une excuse pour essayer de nouveaux langages, comme ça).

Non, une religion, c'est une secte dont le gourou est mort sans laisser de note rappelant que c'était des bobards.