L’effet réseau est quelque chose de très difficile à faire démarrer même en ayant de bons arguments.
Justement, l'un des points forts de Matrix est qu'il permet de réutiliser une identité qui existe déjà ailleurs pour s'authentifier dans le réseau. Pas besoin de créer un nouveau compte.
j’ai du mal à voir comment un protocole peut faire mieux qu’XMPP.
Ben il suffit d'observer. XMPP c'est super hein, techniquement on peut faire plein de trucs avec, yapluka déployer. Sauf que c'est ce yapluka qui me chagrine, et qui fait qu'en pratique très peu de personnes font, et XMPP n'est toujours pas le protocole qui domine le domaine. On pourrait dire que c'est IRC qui reste le protocole majoritaire des salons de discussion publics (voire même privés), avec Slack qui commence doucement à lui manger des parts (surtout dans les privés). Il n'y a pas encore de protocole d'IM un poil ouvert qui soit majeur, pour le microblogage encore moins, pour la diffusion d'informations il y a très clairement RSS+HTTP qui se fait doucement manger par Twitter…
Bref, XMPP est tip top techniquement mais il n'a pas su être suffisamment convaincant pour devenir une référence (dans le sens "Nan mais allo quoi, tu fais de la messagerie instantanée/des salons de discussion/du pubsub/de la communication entre entités en général mais t'utilises pas XMPP"). De ce point de vue j'ai du mal à voir comment Matrix fera la différence cela dit, mais pourquoi pas !
MSN et Jabber c'est pas exactement la même chose, en fait. Moi aussi je suis attiré par les autres protocoles qui brillent parce qu'ils sont tout neufs et ne sont pas en XML (comme matrix par exemple), mais l'"abandon" de XMPP par des grands acteurs (je mets Google dans le même panier) n'est pas une preuve de l'inutilité de XMPP, au contraire même.
Il faut bien voir que l'intérêt de ces acteurs est de créer un enclos dans laquelle les utilisateurs restent, et de contrôler au maximum les entrées et sorties. La fédération, si chère à XMPP, est un défaut qui ne peut être contre-balancé que par la prospective d'attirer plus d'utilisateurs en interne. C'est pour ça que GMail fait du SMTP et se fédère ainsi au reste du monde, mais ils le font parce qu'il y a beaucoup à y gagner; Facebook fait du HTTP parce qu'ils ne contrôlent pas toute la chaîne jusqu'à leurs serveurs et doivent donc utiliser les mêmes outils que le monde extérieur. Google a un avantage sur ce point, ils contrôlent une partie des navigateurs et peuvent donc se permettre des choses qui cassent la compatibilité.
Pour le moment les maigres avantages à supporter XMPP pour un géant comme Facebook (on peut à peine dire que plus de monde utiliserait Facebook, vu que les clients XMPP tendent à être utilisés par des gens qui se soucient un peu de leur vie privée) ne valent pas les inconvénients (quelqu'un pourrait offrir les mêmes fonctionnalités que Facebook, mais à l'extérieur).
En revanche ce qu'on peut regretter, c'est l'absence d'entité qui s'impose comme référence dans le domaine XMPP: la messagerie instantanée simpliste est de loin l'utilisation la plus répandue aujourd'hui alors que XMPP est capable de bien plus.
Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,…) ? Tout est là, mais personne ne fait la totalité comme le fait IRCCloud avec irc ou Slack dans leur propre univers. Vu de loin j'ai même l'impression que matrix essaie de construire un ensemble de logiciels qui fournit les fonctionnalités. À un moment j'ai cru que DuckDuckGo avait un plan quand ils ont annoncé qu'ils ouvraient les inscriptions sur leur serveur, mais on dirait qu'ils ont un prosody qui tourne et ça s'arrête là.
XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien…
XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là. Il y a bien juick qui à un moment permettait de poster via un bot XMPP, et buddycloud qui a ses propres XEPs. Bon sur ce point le gros problème c'était que l'implémentation dépendait du serveur, et grâce aux 2 XEPs (encore merci les gars !) on va pouvoir développer, mais encore une fois, rien n'a percé.
À force de voir "X abandonne XMPP" on est décu en se disant que XMPP a perdu. À l'inverse il faut plutôt être décu de ne pas voir plus de "X utilise XMPP pour dominer le monde", c'est-à-dire des nouveaux entrants qui utilisent XMPP comme avantage compétitif et qui démontrent la viabilité de XMPP comme brique de base pour fournir des services. Mais ça grouillote toujours dans le monde XMPP, donc penser que XMPP est mort est juste faux.
(Je pense également que si il y a si peu de services offerts au public avec XMPP, c'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis: l'innovation ne vient quasiment jamais des serveurs mais bien des clients, à savoir le bout de la chaine, là où il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose)
Ah mais non, après examen plus précis de 355 et 356, ces deux XEPs ne sont pas spécifiques aux composants donc mes questions n'ont pas vraiment de sens, pardon.
Déjà, félicitations pour l’avancée, grâce a ça on pourra voir des composants (au sens XMPP) se développer sans être spécifique a un serveur. Excellent !
En fait si j'ai bien compris, ici il s'agit d’étendre un peu les capacités des composants. Du coup on se retrouve avec:
la XEP-0114 qui est une standardisation d'une pratique répandue (a l’époque)
la XEP-0225 qui veut nettoyer un peu ça mais qui n'est pas encore standard
deux XEP qui permettent aux composants d'agir plus comme des serveurs que comme des clients
Du coup j'ai deux questions:
Est-ce qu'il y a des cas d'utilisation dans lesquels une des deux XEP pourrait etre utile mais pas l'autre ? Dit autrement, pourquoi deux XEP et pas une seule ?
Est-ce qu'il n'y avait pas moyen de pousser pour une mise a jour du protocole des composants, c'est-a-dire dépoussiérer 225 en y ajoutant vos cas d'utilisation ?
Je suis tout à fait d'accord pour dire qu'il y a beaucoup (trop?) d'éléments du langage qui peuvent rappeler la différence, qui peuvent blesser sans que le locuteur ne s'en rende compte… mais de là à prêter une intention malfaisante à tout le monde, je trouve que tu y vas un peu fort.
J'imagine que ce genre de trucs c'est pour montrer que le monde il est trop machiste et qu'il y a tout plein de mecs et pas assez de femmes.
Je crois que tu hallucines un peu, le but du machin est de lancer une requête sur wikidata. Il n'y a aucun jugement de valeur porté sur le résultat (en tout cas, aucun dans le journal et aucun dans l'annonce). Techniquement oui c'est sexiste, parce qu'il y a une distinction sur le sexe… mais ça reste une donnée. Seule son interprétation peut être considérée comme négative.
On n’a jamais viré sans ménagements une CA des magasins des navigateurs.
Ah bah si justement: CNNIC a été supprimé du magasin Chrome et du magasin Firefox, a peine 1 semaine après les faits. Après je suis a peu près sur qu'une racine américaine n'aurait jamais été enlevé aussi vite.
C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde ? (et ne me dit pas que les serveurs devraient partager leur cles TLS…). Ça resterait quand même plus simple de ne pin qu'un seul truc au niveau de Google.
Plus haut encore: on transfère le problème de CA à l'ICANN, donc au gouvernement américain.
Tiens, voici un article bien biaisé par un expert en crypto qui soulève quelques problèmes avec DNSSEC. J'ai tendance à être d'accord avec lui, même si ça ne résout toujours pas le problème.
Le pinnage c'est très bien, ça permet de repérer assez rapidement quand quelque chose de louche se passe sur le réseau, mais c'est dommage de limiter ça à HTTP; il y a une proposition "concurrente" sous la forme de TACK, qui cette fois fournit la possibilité de pinner mais directement au niveau TLS, du coup:
TACK est dispo pour toutes les applications, pas seulement pour HTTP
Ça garde les couches bien séparées proprement. Chacun chez soi et les sessions seront bien sécurisées
Lorsque le certificat doit être changé légitimement (parce que la clé privée a fuité, par exemple), HPKP empêche tout accès (impossible de lire de potentiels nouveaux en-têtes HTTP puisque la couche TLS est totalement bloquée); TACK se limite à la couche TLS, et est ainsi capable de fournir les nouveaux éléments indiquant "le certificat a changé, update ton pin"
Malheureusement c'est pas tout rose:
TACK est un peu plus radical et propose de se passer complètement de X.509 en signant directement les clés TLS des serveurs. Du coup ça doit être assez indigeste à déployer sur un gros domaine avec des serveurs qui doivent être changés un minimum fréquemment. En fait TACK se veut un système alternatif aux CAs [1]. Techniquement TACK pourrait être utilisé pour pinner les certificats dans la chaîne plutôt que les serveurs eux-même, mais c'est pas
Comme c'est niveau TLS, c'est autrement plus dur à déployer que 3 lignes dans un nginx.conf.
"Malheureusement" au rythme où vont les choses c'est HPKP qui gagnera, et tout ce qui n'est pas HTTP se retrouvera, une fois de plus, relégué au second rang.
[1] Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain. Le système actuel d'autorités de certifications est mauvais parce que les acteurs en haut de la chaine sont mauvais, mais le reste de l'infrastructure reste quand même solide; typiquement ici, ça aurait totalement du sens de ne gérer la confiance qu'au niveau du domaine, pas au niveau de chacun des serveurs, et ça c'est déjà fourni par le système de CAs.
Des entreprises privée telle que FaceBook le font déjà. Pourquoi se priverais on de le faire pour la sécurité nationale.
Ça ne surprendra personne ici, mais Facebook a mes données parce que je les lui donne volontairement, c'est écrit dans les TOS; en revanche il est impossible de se désinscrire de l'État (ou alors j'aimerais bien voir ses TOS, tiens)
Or pour trouver l'aiguille dans la meule de foin, il faut bien vérifier toute la meule. Ce qui reviendrais a mettre sous la surveillance automatisée d'ordinateur tout internaute français.
Alors ça c'est bien le truc que j'ai toujours pas compris. On nous parle de surveillance ciblée sur des individus louches, mais cette surveillance est anonyme pour éviter des débordements … Du coup ça veut dire que c'est pas ciblé ? Une sorte de précision chirurgicale à dommages collatéraux ?
En outre, tout utilisateur de l’œuvre a l'obligation d’indiquer le nom de l’auteur
Vu que ça vient du ministère de la Culture, je pense qu'on peut considérer ça comme une source plutôt sûre, mais en même temps techniquement c'est pas écrit …
Mea culpa, je ne savais pas qu'il y avait obligation de citer l'auteur (je pensais qu'il y avait juste interdiction de fourvoyer sur la paternité, genre "c'est moi qui ai fait ca" ou "on ne sait pas qui a fait ça"), par contre la CC0 reste (si je ne m'abuse) applicable en France justement parce qu'elle contient la clause suivante:
Dans la mesure du possible et sans enfreindre la loi en vigueur
avec l'alternative:
Licence Publique Supplétive. Au cas où une partie quelconque de la Renonciation serait jugée juridiquement nulle ou sans effet pour quelque raison que ce soit en vertu de la loi en vigueur, la Renonciation devra être préservée dans la mesure maximum permise
Autrement dit CC0 n'est pas "domaine public", c'est "le plus possible vers domaine public, dans les limites de la loi du coin".
Non, justement, CC0 c'est la CC qui a 0 clauses (d'où son nom si je ne me trompe pas), donc pas de SA, pas de NC, et pas de BY. Ça veut dire du coup qu'il n'est pas obligatoire pour le ré-utilisateur de citer la source, même si ça reste un geste appréciable.
TextSecure n'est pas qu'un logiciel (libre), c'est aussi un moyen de mettre le chiffrement des communications a la portée de tous. La crainte principale avec F-Droid est que les utilisateurs téléchargent un logiciel potentiellement cassé (pas parce que F-Droid injecte volontairement des bugs, mais parce que la version sur F-Droid est ancienne), qui ne peut pas être mis a jour rapidement (puisqu'il est géré par un tiers), qui ne peut pas remonter les problèmes, mais qui a toujours le même nom; il y a donc de fortes chances que les utilisateurs de F-Droid considèrent TextSecure comme tout cassé (voire pire: qu'ils ne sachent pas que leurs messages peuvent accidentellement être lus par un tiers parce que le chiffrement de leur version est troué) alors qu'ils n'ont même pas la bonne version. En gros il n'y a pas que le logiciel en jeu, il y a aussi l'image d'Open Whisper Systems en jeu derrière.
Note d'ailleurs que moxie n'interdit pas, il est juste fortement contre. Et si quelqu'un veut vraiment installer TextSecure sans passer par les services Google, il peut compiler et installer sur sa machine.
Mes excuses, je pensais que tu te servais de S3 ou de GCS comme d'un bête espace de stockage brut, et que la logique sur les données pouvait se faire côté client ou côté proxy. Dans ce cas-là, camlistore aurait pu t'être utile: en implémentant un blobserver.Storage, tu peux décider où sont lus et où sont écrits les bouts de données, ce qui te permettrait de lire depuis "bucket1" et d'écrire dans "bucket1-test". Note que par défaut Camlistore déduplique déjà automatiquement les données (ce qui fait que les blobs stockés dans S3/GCS n'auraient aucun sens en tant que tel), et que tu peux rajouter par dessus la compression, le chiffrement, le cache…
Ça aurait été, à mon avis, beaucoup plus simple que de faire un proxy HTTP de 0.
Effectivement si la hiérarchie de l'organisation dans S3/GCS compte, camlistore ne peut pas t'aider. Mais je continue de penser qu'il est mauvais de faire trop confiance à un fournisseur de stockage dans les nuages, et qu'il vaudrait mieux les considérer comme un fournisseur de stockage brut.
si c'est juste pour dire qu'il n'y a pas d'autre limite que celle que du client, et si dans le cas du débit des limites sont mentionnées que trouve tu à redire?
Je suis pas Renault mais je suis d'accord avec lui: dire "illimité, puis on verra en tant voulu" c'est mettre des règles a la tête du client. Une limite dite explicitement, même absurde, est plus honnête qu'une limite qui n'est pas dite.
rsync.net propose un accès FTP et SFTP, en plus de quelques commandes bien pratiques pour le transfert et le backup. Par contre on est clairement dans une autre gamme de prix, et a mon avis dans une utilisation plus proche de ce qui t’intéresse, a savoir un bête accès distant que tu utilises avec tes propres outils, contrairement a hubiC qui est clairement oriente alternative a dropbox, avec son logiciel dédié et son interface web.
L'offre de Crashplan est plutôt orientée entreprise
Faux, il y a toujours eu une offre particuliers, avec d'ailleurs un segment "Famille" qui te permettait de sauvegarder plusieurs ordinateurs dans le nuage (l'offre payante de base ne permet d'en sauvegarder qu'un seul) et un côté "Amis" qui te permettait de faire des sauvegardes sur un autre ordinateur (que ce soit ton NAS ou la machine de quelqu'un d'autre à travers internet).
TextSecure avait été supprimé à cause d'un conflit avec le développeur
La phrase parait anodine, mais je pense qu'il est important de préciser: Moxie (le développeur principalement connu derrière TextSecure) veut ces critères pour mettre son application sur un store alternatif:
Un moyen de mettre à jour automatiquement l'application. On peut comprendre le besoin dans la mesure où les failles cryptographiques sont extrêmement importantes à corriger
Une signature de l'APK faite par l'équipe principale. Ça nécessite des builds reproduisibles, ce qui n'existait pas jusqu'à récemment
Un système de crash reporting performant. C'est pas tout de distribuer l'application, si elle crashe il faut que le projet soit au courant pour pouvoir régler le problème rapidement
Des statistiques d'utilisation sur la machine utilisée
F-Droid ne fournit (fournissait?) pas ça, donc les développeurs n'ont pas voulu supporter une nouvelle version qui leur apporterait plus de problèmes qu'autre chose. Son argumentaire, c'est qu'un store alternatif c'est un peu comme un download.com, il y a bien des trucs dessus avec le nom que tu cherches mais t'es pas sûr de savoir sur quoi tu tombes. Au moins avec Google Play il y a un lien beaucoup plus fort entre l'application et le développeur, qui permet d'obtenir plus d'informations plus précises pour améliorer le produit.
[^] # Re: comme pour les RFC ?
Posté par rakoo (site web personnel) . En réponse au journal [Les Échos] "Guerre de religions" entre OOxml et l'ODF. Évalué à 2. Dernière modification le 06 juin 2015 à 21:47.
EDIT: j'ai rien compris.
[^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par rakoo (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique . Évalué à 2.
Justement, l'un des points forts de Matrix est qu'il permet de réutiliser une identité qui existe déjà ailleurs pour s'authentifier dans le réseau. Pas besoin de créer un nouveau compte.
Ben il suffit d'observer. XMPP c'est super hein, techniquement on peut faire plein de trucs avec, yapluka déployer. Sauf que c'est ce yapluka qui me chagrine, et qui fait qu'en pratique très peu de personnes font, et XMPP n'est toujours pas le protocole qui domine le domaine. On pourrait dire que c'est IRC qui reste le protocole majoritaire des salons de discussion publics (voire même privés), avec Slack qui commence doucement à lui manger des parts (surtout dans les privés). Il n'y a pas encore de protocole d'IM un poil ouvert qui soit majeur, pour le microblogage encore moins, pour la diffusion d'informations il y a très clairement RSS+HTTP qui se fait doucement manger par Twitter…
Bref, XMPP est tip top techniquement mais il n'a pas su être suffisamment convaincant pour devenir une référence (dans le sens "Nan mais allo quoi, tu fais de la messagerie instantanée/des salons de discussion/du pubsub/de la communication entre entités en général mais t'utilises pas XMPP"). De ce point de vue j'ai du mal à voir comment Matrix fera la différence cela dit, mais pourquoi pas !
# Prise de position
Posté par rakoo (site web personnel) . En réponse au journal [Les Échos] "Guerre de religions" entre OOxml et l'ODF. Évalué à 10.
Ça tranche sévère, l'État rigole pas avec ça !
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par rakoo (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4. Dernière modification le 30 mai 2015 à 15:27.
MSN et Jabber c'est pas exactement la même chose, en fait. Moi aussi je suis attiré par les autres protocoles qui brillent parce qu'ils sont tout neufs et ne sont pas en XML (comme matrix par exemple), mais l'"abandon" de XMPP par des grands acteurs (je mets Google dans le même panier) n'est pas une preuve de l'inutilité de XMPP, au contraire même.
Il faut bien voir que l'intérêt de ces acteurs est de créer un enclos dans laquelle les utilisateurs restent, et de contrôler au maximum les entrées et sorties. La fédération, si chère à XMPP, est un défaut qui ne peut être contre-balancé que par la prospective d'attirer plus d'utilisateurs en interne. C'est pour ça que GMail fait du SMTP et se fédère ainsi au reste du monde, mais ils le font parce qu'il y a beaucoup à y gagner; Facebook fait du HTTP parce qu'ils ne contrôlent pas toute la chaîne jusqu'à leurs serveurs et doivent donc utiliser les mêmes outils que le monde extérieur. Google a un avantage sur ce point, ils contrôlent une partie des navigateurs et peuvent donc se permettre des choses qui cassent la compatibilité.
Pour le moment les maigres avantages à supporter XMPP pour un géant comme Facebook (on peut à peine dire que plus de monde utiliserait Facebook, vu que les clients XMPP tendent à être utilisés par des gens qui se soucient un peu de leur vie privée) ne valent pas les inconvénients (quelqu'un pourrait offrir les mêmes fonctionnalités que Facebook, mais à l'extérieur).
En revanche ce qu'on peut regretter, c'est l'absence d'entité qui s'impose comme référence dans le domaine XMPP: la messagerie instantanée simpliste est de loin l'utilisation la plus répandue aujourd'hui alors que XMPP est capable de bien plus.
Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,…) ? Tout est là, mais personne ne fait la totalité comme le fait IRCCloud avec irc ou Slack dans leur propre univers. Vu de loin j'ai même l'impression que matrix essaie de construire un ensemble de logiciels qui fournit les fonctionnalités. À un moment j'ai cru que DuckDuckGo avait un plan quand ils ont annoncé qu'ils ouvraient les inscriptions sur leur serveur, mais on dirait qu'ils ont un prosody qui tourne et ça s'arrête là.
XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien…
XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là. Il y a bien juick qui à un moment permettait de poster via un bot XMPP, et buddycloud qui a ses propres XEPs. Bon sur ce point le gros problème c'était que l'implémentation dépendait du serveur, et grâce aux 2 XEPs (encore merci les gars !) on va pouvoir développer, mais encore une fois, rien n'a percé.
À force de voir "X abandonne XMPP" on est décu en se disant que XMPP a perdu. À l'inverse il faut plutôt être décu de ne pas voir plus de "X utilise XMPP pour dominer le monde", c'est-à-dire des nouveaux entrants qui utilisent XMPP comme avantage compétitif et qui démontrent la viabilité de XMPP comme brique de base pour fournir des services. Mais ça grouillote toujours dans le monde XMPP, donc penser que XMPP est mort est juste faux.
(Je pense également que si il y a si peu de services offerts au public avec XMPP, c'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis: l'innovation ne vient quasiment jamais des serveurs mais bien des clients, à savoir le bout de la chaine, là où il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose)
[^] # Re: Fusion avec XEP-0114
Posté par rakoo (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
Ah mais non, après examen plus précis de 355 et 356, ces deux XEPs ne sont pas spécifiques aux composants donc mes questions n'ont pas vraiment de sens, pardon.
# Fusion avec XEP-0114
Posté par rakoo (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
Déjà, félicitations pour l’avancée, grâce a ça on pourra voir des composants (au sens XMPP) se développer sans être spécifique a un serveur. Excellent !
En fait si j'ai bien compris, ici il s'agit d’étendre un peu les capacités des composants. Du coup on se retrouve avec:
Du coup j'ai deux questions:
Est-ce qu'il y a des cas d'utilisation dans lesquels une des deux XEP pourrait etre utile mais pas l'autre ? Dit autrement, pourquoi deux XEP et pas une seule ?
Est-ce qu'il n'y avait pas moyen de pousser pour une mise a jour du protocole des composants, c'est-a-dire dépoussiérer 225 en y ajoutant vos cas d'utilisation ?
[^] # Re: sexisme
Posté par rakoo (site web personnel) . En réponse au journal Liste des maires féminines des plus grandes villes du monde d'après Wikidata.. Évalué à 6.
Je suis tout à fait d'accord pour dire qu'il y a beaucoup (trop?) d'éléments du langage qui peuvent rappeler la différence, qui peuvent blesser sans que le locuteur ne s'en rende compte… mais de là à prêter une intention malfaisante à tout le monde, je trouve que tu y vas un peu fort.
[^] # Re: sexisme
Posté par rakoo (site web personnel) . En réponse au journal Liste des maires féminines des plus grandes villes du monde d'après Wikidata.. Évalué à 3.
Je crois que tu hallucines un peu, le but du machin est de lancer une requête sur wikidata. Il n'y a aucun jugement de valeur porté sur le résultat (en tout cas, aucun dans le journal et aucun dans l'annonce). Techniquement oui c'est sexiste, parce qu'il y a une distinction sur le sexe… mais ça reste une donnée. Seule son interprétation peut être considérée comme négative.
[^] # Re: Et DANE simplement
Posté par rakoo (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 4.
Ah bah si justement: CNNIC a été supprimé du magasin Chrome et du magasin Firefox, a peine 1 semaine après les faits. Après je suis a peu près sur qu'une racine américaine n'aurait jamais été enlevé aussi vite.
[^] # Re: TACK
Posté par rakoo (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 2.
C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde ? (et ne me dit pas que les serveurs devraient partager leur cles TLS…). Ça resterait quand même plus simple de ne pin qu'un seul truc au niveau de Google.
[^] # Re: Et DANE simplement
Posté par rakoo (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 3.
Plus haut encore: on transfère le problème de CA à l'ICANN, donc au gouvernement américain.
Tiens, voici un article bien biaisé par un expert en crypto qui soulève quelques problèmes avec DNSSEC. J'ai tendance à être d'accord avec lui, même si ça ne résout toujours pas le problème.
# TACK
Posté par rakoo (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 6.
Le pinnage c'est très bien, ça permet de repérer assez rapidement quand quelque chose de louche se passe sur le réseau, mais c'est dommage de limiter ça à HTTP; il y a une proposition "concurrente" sous la forme de TACK, qui cette fois fournit la possibilité de pinner mais directement au niveau TLS, du coup:
Malheureusement c'est pas tout rose:
nginx.conf."Malheureusement" au rythme où vont les choses c'est HPKP qui gagnera, et tout ce qui n'est pas HTTP se retrouvera, une fois de plus, relégué au second rang.
[1] Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain. Le système actuel d'autorités de certifications est mauvais parce que les acteurs en haut de la chaine sont mauvais, mais le reste de l'infrastructure reste quand même solide; typiquement ici, ça aurait totalement du sens de ne gérer la confiance qu'au niveau du domaine, pas au niveau de chacun des serveurs, et ça c'est déjà fourni par le système de CAs.
[^] # Re: Un résumer ?
Posté par rakoo (site web personnel) . En réponse au journal Puis ils sont venus me chercher, et il ne restait personne pour protester. Évalué à 9.
En vrac:
Ça ne surprendra personne ici, mais Facebook a mes données parce que je les lui donne volontairement, c'est écrit dans les TOS; en revanche il est impossible de se désinscrire de l'État (ou alors j'aimerais bien voir ses TOS, tiens)
Une infographie de Gandi qui explique un peu le processus
Alors ça c'est bien le truc que j'ai toujours pas compris. On nous parle de surveillance ciblée sur des individus louches, mais cette surveillance est anonyme pour éviter des débordements … Du coup ça veut dire que c'est pas ciblé ? Une sorte de précision chirurgicale à dommages collatéraux ?
[^] # Re: La suite pour nous utilisateurs ?
Posté par rakoo (site web personnel) . En réponse au journal La vie privé connectée disparait de France. Évalué à 3.
Fais ta part du boulot, camarade !
[^] # Re: Quoi d'autre ?
Posté par rakoo (site web personnel) . En réponse au journal Le Dessous des cartes + Creative Commons = ♥. Évalué à 2.
Justement, je ne serais pas aussi catégorique:
Vu que ça vient du ministère de la Culture, je pense qu'on peut considérer ça comme une source plutôt sûre, mais en même temps techniquement c'est pas écrit …
[^] # Re: Quoi d'autre ?
Posté par rakoo (site web personnel) . En réponse au journal Le Dessous des cartes + Creative Commons = ♥. Évalué à 4.
Mea culpa, je ne savais pas qu'il y avait obligation de citer l'auteur (je pensais qu'il y avait juste interdiction de fourvoyer sur la paternité, genre "c'est moi qui ai fait ca" ou "on ne sait pas qui a fait ça"), par contre la CC0 reste (si je ne m'abuse) applicable en France justement parce qu'elle contient la clause suivante:
avec l'alternative:
Autrement dit CC0 n'est pas "domaine public", c'est "le plus possible vers domaine public, dans les limites de la loi du coin".
[^] # Re: Quoi d'autre ?
Posté par rakoo (site web personnel) . En réponse au journal Le Dessous des cartes + Creative Commons = ♥. Évalué à -2.
Non, justement, CC0 c'est la CC qui a 0 clauses (d'où son nom si je ne me trompe pas), donc pas de SA, pas de NC, et pas de BY. Ça veut dire du coup qu'il n'est pas obligatoire pour le ré-utilisateur de citer la source, même si ça reste un geste appréciable.
[^] # Re: Précision
Posté par rakoo (site web personnel) . En réponse à la dépêche SMSSecure : les SMS et MMS chiffrés sur Android, ce n'est pas fini !. Évalué à 2.
TextSecure n'est pas qu'un logiciel (libre), c'est aussi un moyen de mettre le chiffrement des communications a la portée de tous. La crainte principale avec F-Droid est que les utilisateurs téléchargent un logiciel potentiellement cassé (pas parce que F-Droid injecte volontairement des bugs, mais parce que la version sur F-Droid est ancienne), qui ne peut pas être mis a jour rapidement (puisqu'il est géré par un tiers), qui ne peut pas remonter les problèmes, mais qui a toujours le même nom; il y a donc de fortes chances que les utilisateurs de F-Droid considèrent TextSecure comme tout cassé (voire pire: qu'ils ne sachent pas que leurs messages peuvent accidentellement être lus par un tiers parce que le chiffrement de leur version est troué) alors qu'ils n'ont même pas la bonne version. En gros il n'y a pas que le logiciel en jeu, il y a aussi l'image d'Open Whisper Systems en jeu derrière.
Note d'ailleurs que moxie n'interdit pas, il est juste fortement contre. Et si quelqu'un veut vraiment installer TextSecure sans passer par les services Google, il peut compiler et installer sur sa machine.
[^] # Re: Déduplication
Posté par rakoo (site web personnel) . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 2.
Mes excuses, je pensais que tu te servais de S3 ou de GCS comme d'un bête espace de stockage brut, et que la logique sur les données pouvait se faire côté client ou côté proxy. Dans ce cas-là, camlistore aurait pu t'être utile: en implémentant un blobserver.Storage, tu peux décider où sont lus et où sont écrits les bouts de données, ce qui te permettrait de lire depuis "bucket1" et d'écrire dans "bucket1-test". Note que par défaut Camlistore déduplique déjà automatiquement les données (ce qui fait que les blobs stockés dans S3/GCS n'auraient aucun sens en tant que tel), et que tu peux rajouter par dessus la compression, le chiffrement, le cache…
Ça aurait été, à mon avis, beaucoup plus simple que de faire un proxy HTTP de 0.
Effectivement si la hiérarchie de l'organisation dans S3/GCS compte, camlistore ne peut pas t'aider. Mais je continue de penser qu'il est mauvais de faire trop confiance à un fournisseur de stockage dans les nuages, et qu'il vaudrait mieux les considérer comme un fournisseur de stockage brut.
[^] # Re: double usage
Posté par rakoo (site web personnel) . En réponse au journal Le chiffrement en France. Évalué à 2.
D'accord, mais dans ce cas la je prends quelle colonne dans les tableaux qu'ils donnent ?
[^] # Re: externalisation <=> compétences
Posté par rakoo (site web personnel) . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 5.
Je suis pas Renault mais je suis d'accord avec lui: dire "illimité, puis on verra en tant voulu" c'est mettre des règles a la tête du client. Une limite dite explicitement, même absurde, est plus honnête qu'une limite qui n'est pas dite.
[^] # Re: Accès via FTP / SFTP ?
Posté par rakoo (site web personnel) . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 2.
rsync.net propose un accès FTP et SFTP, en plus de quelques commandes bien pratiques pour le transfert et le backup. Par contre on est clairement dans une autre gamme de prix, et a mon avis dans une utilisation plus proche de ce qui t’intéresse, a savoir un bête accès distant que tu utilises avec tes propres outils, contrairement a hubiC qui est clairement oriente alternative a dropbox, avec son logiciel dédié et son interface web.
[^] # Re: Déduplication
Posté par rakoo (site web personnel) . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 2.
Tu n'as pas assez cherché, alors :)
[^] # Re: Crashplan
Posté par rakoo (site web personnel) . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 3.
Faux, il y a toujours eu une offre particuliers, avec d'ailleurs un segment "Famille" qui te permettait de sauvegarder plusieurs ordinateurs dans le nuage (l'offre payante de base ne permet d'en sauvegarder qu'un seul) et un côté "Amis" qui te permettait de faire des sauvegardes sur un autre ordinateur (que ce soit ton NAS ou la machine de quelqu'un d'autre à travers internet).
# Précision
Posté par rakoo (site web personnel) . En réponse à la dépêche SMSSecure : les SMS et MMS chiffrés sur Android, ce n'est pas fini !. Évalué à 5.
La phrase parait anodine, mais je pense qu'il est important de préciser: Moxie (le développeur principalement connu derrière TextSecure) veut ces critères pour mettre son application sur un store alternatif:
F-Droid ne fournit (fournissait?) pas ça, donc les développeurs n'ont pas voulu supporter une nouvelle version qui leur apporterait plus de problèmes qu'autre chose. Son argumentaire, c'est qu'un store alternatif c'est un peu comme un download.com, il y a bien des trucs dessus avec le nom que tu cherches mais t'es pas sûr de savoir sur quoi tu tombes. Au moins avec Google Play il y a un lien beaucoup plus fort entre l'application et le développeur, qui permet d'obtenir plus d'informations plus précises pour améliorer le produit.
(Cf la discussion sur le sujet)