C’est libre, mais la partie serveur tourne sur IIS avec du SQL Server et est développé en ASP.Net /o\
Grosses questions que je me pose sur ce système… À la lecture du papier, la blockchain n’est utilisée que pour les paiements et pour la preuve de stockage. Ça serait de toute façon catastrophique en terme de consommation de ressources de foutre les données dans la blockchain directement.
En pratique, les données me semblent donc être chez un unique stockeur, qui les stocke à sa sauce, donc pour un particulier sur un unique disque non répliqué et non distribué. Stockeur qui devra régulièrement publier des morceaux du fichier pour assurer la blockchain qu’il possède toujours le fichier et percevoir sa dîme.
Et donc en cas de perte du fichier par ce stockeur, il ne sera certes pas payé, mais vous aurez aussi perdu vos données…
SIA n’est donc pas un système de stockage de fichiers décentralisé, redondant et sécurisé, mais un gestionnaire de contrats intelligents, servant à échanger les paiements autour d’un pool de ressources de stockage qui lui n’est ni décentralisé ni redondant.
Je note quand même 2 grossières erreurs dans l’article, qui le décrédibilise assez sur sa conclusion…
La 1ère, la confusion entre libre et gratuit. Un logiciel libre n’est pas forcément gratuit. Et la 2nde en disant que les gens se sont accomodés de Photoshop parce qu’ils ont confiance en Adobe. Non, ils n’ont juste aucune connaissance de l’existence de Gimp et en sont encore moins formés à son maniement…
Enfin, un passage est carrément délictuel en plus d’être faux. Un logiciel commercial peut être très cher (et pourtant libre d’ailleurs) parce qu’il faut aussi que ses auteurs vivent et que certains logiciels sont très complexes à développer. Et même si un logiciel est cher, on n’a certainement pas à le pirater, et encore moins à inciter de le faire publiquement… Surtout que tout logiciel piraté n’est par définition même pas de confiance vu que sa source n’est même plus son auteur originel mais une entité inconnue et potentiellement malsaine, sans qu’il ne soit possible de vérifier ce qu’il embarque (vu que ce n’est pas libre)… La gratuité du libre est aussi se qui est en train de le tuer, puisque sans revenus décents, beaucoup de logiciels libres ne seront pas maintenus…
ça me rassure, ça fait deux articles que je vois passer du monsieur et que - vraiment - je ne comprends rien à ses analyses.
Oui, promouvoir le piratage pour télécharger un logiciel qu'il appelle de confiance, c'est n'importe quoi ! Si justement, il pirate, il ne sait pas exactement ce qu'il pirate ! C'est vraiment n'importe quoi !
Après, il y a des paragraphes assez drôle comme celui-ci :
Pourquoi les logiciels auraient-ils un statut particulier ? Pourquoi exiger des développeurs de logiciels ce que nous ne pouvons exiger des autres créateurs ? Pourquoi ce serait plus éthique qu’ils libèrent leurs codes ? Pourquoi tous les cuisiniers ne devraient-ils pas libérer leurs recettes ? Les laboratoires leurs brevets ? Les écrivains leurs textes ? Généralisée, cette volonté n’est-ce pas une forme de totalitarisme intellectuel ? Est-ce si éloigné du communisme ?
Il n'y a pas de volonté généralisé de tout libérer… Le logiciel libre ne force pas à libérer les logiciels, les développeurs font ce qu'ils veulent. Et puis, il confond tout… Pour un cuisinier, il peut ne pas dévoiler la recette, mais en France, il y a sans doute une obligation à ce qu'il soit honnête sur les ingrédients utilisés (en cas d'allergie par exemple). Bien sur que les brevets sont libérés ! Sinon, la science n'avancerait pas. A partir d'un certain moment, le brevet tombe dans le domaine publique. Idem pour les textes des auteurs ! Et puis, il compare des choses qui sont pas comparables. Un texte non libre ne peut pas avoir autant de conséquences néfastes qu'un code non-libre (donc non examinable).
Passons aussi sur ce paragraphe qui ne veut strictement rien dire :
Il me semble que la libération n’est vitale que si elle contribue à la confiance. L’exemple de la monnaie est particulièrement intéressant. De toute évidence, l’Euro n’est pas une monnaie de confiance. Il est donc vital de créer des monnaies de confiance, et une monnaie étant un lien entre tous, elle doit être libre. C’est l’universalité de la monnaie qui pousse en faveur de son ouverture et de sa transparence.
Il fait de très gros raccourcis sur des domaines qu'il ne connaît pas.
J’ai le droit de hurler très beaucoup ? :s
Ça devrait être interdit de faire de la crypto dans un blog sans avoir passer un permis ><
Entre les erreurs grossières sur ECB (qui ne doit jamais être utilisé, quelqu’en soit la raison) et la mauvaise gestion de la clef et de l’IV (qui est justement le morceau difficile de ce code et qui n’est pas du tout abordé). Snif…
Bien que ça date, il faut croire que tout le monde n'a pas encore pris le temps de lire cet article : https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/
Une société avec une importante augmentation de capitale récemment qui se sépare de son CTO fondateur et ça n'a bien sûr aucun rapport.
Ça n’a aucun rapport avec l’augmentation de capital. Il s’agit uniquement de désaccords internes, qui datent depuis plus longtemps que la levée de fond elle-même.
Ah. Oui c'est un hasard du calendrier :D Et bien sûr le nouvel actionnaire n'a pas voté le départ du CTO, puisqu'il n'a aucun rapport avec tout ça.
L’assemblée générale a été consultée pour trancher entre 2 points de vue. Personne d’autre n’était légitime pour le faire sinon. Pas de lien avec la levée de fond :)
un nouvel actionnaire (donc potentiellement) une nouvelle vision, qui pour sa participation a obtenu droit au chapitre j'imagine donc influe la direction de l'entreprise en participant à l'éviction de celui qui n'a pas la même vision. Le lien me semble évident, mais je dois rater quelque chose.
Tu oublies que la brouille initiale n’est pas de l’initiative d’un quelconque actionnaire. C’est volontairement que le CTO et le CEO ont remis la décision entre leurs mains pour régler un conflit. Pas de nouvelle vision et certainement pas une externe.
Franchement le communiqué complètement aseptisé paru sur le blog ne fait qu'embrouiller les utilisateurs et sympathisants de Cozy, un vrai raté de communication. Au lieu d'aller à la source du problème, il tente de pousser la poussière sous le tapis au moment où tout le monde braque les yeux sur Cozy… Il aurait mieux valu le publier le 13 juillet au soir dans cette optique.
On attend avec impatience le droit de réponse de Frank Rousseau, qui va sûrement éclaircir tout ça.
À lire les réactions affligeantes que ce communiqué provoque par exemple sur LinuxFR.org.
Frank annonce sur son compte twitter qu'il va bientôt poster sur le sujet. https://twitter.com/gelnior/status/755371991033581568
oui, il fait bien. Si c'est comme son entretien sur le blog du Journal du hacker, ça sera autrement plus intéressant que le communiqué Cozy.
Oui, les réactions sont bof et tapent à côté de la plaque… Après niveau com’ on fait aussi avec ce qu’on peut/a/peut faire/ait le droit de faire. Exercice périlleux, avec peu de chance de succès :P
La com peut tout faire (hormis la diffamation) même être transparente, encore faut-il le vouloir.
Quand tu viens de lever 4 millions d'euros et que tu veux te séparer d'un de tes dirigeants, tu as les moyens pour que ça n'arrive pas sur la place publique, même si ça peut revenir un peu cher je le concède. Le vrai raté est là.
Suite à l'article de NexInpact on a un plus d'informations.
[Comment removed by author]
tiens c'est marrant, un pote me disait la même chose pour mon article le danger Github (revue et augmenté). y'a peut-être un besoin à creuser là. Un diff automatique entre deux articles bien résumé et bien intégré. À voir.
Un point de vue en anglais versus hardware : http://mail.fsfeurope.org/pipermail/discussion/2016-April/010912.html. Et là, la situation est beaucoup moins drôle. Sinon, pour ma part, le grand changement c'est la volonté des Etats de prendre de plus en plus de mesures légales pour s'assurer que l'hyper prudent sera de moins en moins prudent :-).
pas forcément récent non, c'est sûr que l'intérêt du public est pas le même pour des articles déjà publiés, mais si ça intéresse le public du Jdh, il n'y a pas de restriction.
Un VNC à travers un tunnel SSH c'est sécurisé pour le coup ? Question innocente, je suis juste en train de me documenter pour m'en faire un et je découvre un peu le système. Si j'ai bien compris à travers le SSH il faut juste ouvrir le port du tunnel, originellement le 22 ?
Oui, VNC over SSH est safe. Et oui du coup tu n’as que le port 22 à exposer, ton VNC sera accédé ensuite via le tunnel, donc pas besoin d’être ouvert au public.
Cet article semble montrer une grand méconnaissance du fonctionnement de TextSecure : Aeris y parle par exemple de meta-données, qui sont exposées plus facilement (selon moi) par SMSSecure que par TextSecure; en effet, les méta-données SMS transitent de manière non chiffrées, et donc tous les acteurs de la chaine (opérateur d’envoi et de réception, états), ainsi que ceux prochent de vous (imsi catchers…) ont connaissance d’avec qui vous dialoguez. Dans le cas de TextSecure, seul le serveur d’Open Whispers Systems sait dire avec qui vous parlez, et vous faites donc confiance aux mêmes personnes qui ont développé l’application et le protocole.
Ensuite, il semble balayer l’argument principal des développeurs: la sécurité n’est pas absolue, et il faut donc la possibilité de rester toujours à jour sur la dernière version. Sait-on si F-Droid a la même rapidité de déploiement que Google Play ? Que se passe-t-il si les développeurs de SMSSecure “oublient” de le déployer sur l’ensemble des stores disponibles ? Si on installe SMSSecure depuis Google Play, on en revient sur la dépendance à Google, et ça m’amène à mon prochain point.
Pour maximiser la batterie d’un téléphone, il faut minimiser le nombre de fournisseurs de solutions push (i.e en avoir un seul) qui gardent une connexion TCP ouverte en permanence sur l’appareil avec un serveur distant. Et là, malheureusement GCM est la référence, donc la dépendance à Google Play (venant déjà du Store d’installation) n’est au final qu’un moindre mal.
Les arguments sur son forfait data vs les SMS illimités sont par contre tout à fait valides, et une spécificité française; de mon point de vue 50mo de data (=50 secondes de vidéo YouTube 1080p) est bien trop peu, mais c’est un autre débat.
En bref, à moins que vous ne conseillez déjà à vos contacts d’installer AOSP et toutes leurs applications depuis F-Droid, il vaut mieux utiliser Signal qui a un protocole considéré comme fiable(au contraire de Telegram), est compatible multi-OS, libre et permet les appels (au contraire de SMSSecure).
Quand je parle « méta-données », c’est tout compris, pas forcément ce qu’il y a DANS les paquets, mais aussi le paquet lui-même, sa date d’arrivée sur GCM, etc. Et là ça pique, une attaque par corrélation (timing attack) et tu arrives à savoir qui communique avec qui (cf dans les commentaires de l’article pour plus de détail). GCM centralise aussi plus fortement les connexions, donc permet de remonter plus facilement à TOUS tes contacts, alors qu’un opérateur autre que le tient n’a accès qu’à tes contacts chez eux.
Pour les mises-à-jour, F-Droid est même plus rapide à déployer que Google Play, puisqu’il n’y a pas de période d’approbation.
Pour la minimisation des fournisseurs push, je suis d’accord. SMSSecure le minimise même au maximum puisqu’il est de 0 (pas besoin de push pour faire du SMS) ! Contre au moins GCM pour TextSecure.
Merci du retour. Effectivement, l’utilisation de GCM ajoute Google comme tiers de confiance au niveau des méta-données (mais encore une fois, pas les états ni les opérateurs). Je ne sais pas par contre si GCM est utilisé de manière systématique pour tous les échanges, mais ça ne change pas grand chose.
Pour Google Play, la période d’approbation existe effectivement, c’est très nouveau et non systématique (et assez opaque). Elle reste réduite à quelques heures.
Je pense qu’on est d’accord sur les faits, après la conclusion est différente car les priorité sont différentes: expérience utilisateur, confiance dans les opérateurs locaux vs une entreprise étrangère, etc.
La réponse de Okhin : https://about.okhin.fr/posts/GMail/
Y’a donc une discussion ouverte sur le sujet.
Et comme d’hab’, « #define threat_model » avant de parler de sécu :)
Oui j'ai vu c'est dommage car finalement qui va lire cet article ? Les Anglais n'iront pas lire l'article en Français, la plupart des Français ne liront pas l'article en Anglais.
Si c'est sur un VPS ça ne sert à rien vu que votre hébergeur peut faire un dump de la mémoire, et que la mémoire, elle, n'est pas chiffrée.
C’est toujours utile parce qu’en cas de saisie, ils n’y vont généralement pas avec des pincettes et n’iront pas jusqu’à réclamer un dump de la mémoire.
Et même dans le cas d’un dédié, ça ne protège pas non plus d’une saisie intelligente à coup de DMA. Ou encore la corruption du /boot pour y planter un keylogger d’exfiltration de la phrase de passe.
De toute façon c’est comme à chaque fois, la sécurité à 100% n’existe pas :) Elle ne fait que répondre à un modèle de menace, ici une saisie offline des disques.
La loi ne nous oblige pas à fournir les mots de passe dans ce genre de situation normalement ?