Bruno Michel a écrit 3285 commentaires

Ce serait effectivement une manière assez plus maladroite de faire! ;)

Oui, mais pourtant, je l'ai déjà vu plusieurs fois sur des projets nodejs en production. Ce n'est pas toujours facile de voir à l'avance où ça va se produire. Et même quand on le sait, ce n'est pas facile à transformer. Ça demande d'une part de modifier du code synchrone en code asynchrone (normalement, ce n'est pas très compliqué, c'est juste du travail de bucheron) et, d'autre part, il faut réussir à introduire le découpage qui va bien (là, c'est plus compliqué).

Si on prend ton exemple, et que l'on ajoute la version bloquante pour comparer :

const http = require('http');
const process = require('process');
const crypto = require('crypto');
const url = require('url');

const server_port = 8080;
const server_iterations = 400000;

const fibo_initialize_a1 = "I don't like secrets.";
const fibo_initialize_a2 = "God is my co-pilot.";

function combine(a1, a2) {
    return crypto.createHmac('sha256', a1)
        .update(a2)
        .digest('hex');
}

function fiboLoop(n, k, a1, a2, callback) {
    var collaborate_p = (k % 20 === 0);

    if(n == k) {
        callback(a2);
    } else {
        if(collaborate_p) {
            setTimeout(() => {
                fiboLoop(n, k + 1,  a2, combine(a1, a2), callback);
            }, 1);
        } else {
            fiboLoop(n, k + 1,  a2, combine(a1, a2), callback);
        }
    }
}

function fibo(n, callback) {
    fiboLoop(n, 0, fibo_initialize_a1, fibo_initialize_a2, callback);
}

function blockingFibo(n) {
    var a1 = fibo_initialize_a1, a2 = fibo_initialize_a2, tmp;
    for (var i = 1; i <= n; i++) {
        tmp = a2
        a2 = combine(a1, a2);
        a1 = tmp;
    }
    return a2;
}

function safeParseInt(text, _defaultValue) {
    var parsedInt = parseInt(text);
    var defaultValue = _defaultValue || 0;
    return isNaN(parsedInt) ? defaultValue : parsedInt;
};

http.createServer(function (req, res) {
    var parts = url.parse(req.url, true);
    var query = parts.query;
    var iterations =
        ('n' in query)
        ? safeParseInt(query['n'])
        : server_iterations;

    console.log('Receive fibo ' + iterations);

    if ('blocking' in query) {
        var f = blockingFibo(iterations);
            res.writeHead(200, {'Content-Type': 'text/plain'});
            res.write('Hello World! ' + f);
            res.end();
            console.log('Done blocking fibo ' + iterations);
    } else {
        fibo(iterations, (ax) => {
            res.writeHead(200, {'Content-Type': 'text/plain'});
            res.write('Hello World! ' + ax);
            res.end();
            console.log('Done fibo ' + iterations);
        });
    }
}).listen(server_port);

On se rend compte que la version coopérative est beaucoup plus lente :

$ time curl 'http://localhost:8080?n=100000'
Hello World! b04e954ac754919c16edf386311af04c0a41ef30f99c2239e479c42941572397curl 'http://localhost:8080?n=100000'  0,01s user 0,00s system 0% cpu 6,727 total

$ time curl 'http://localhost:8080?n=100000&blocking'
Hello World! b04e954ac754919c16edf386311af04c0a41ef30f99c2239e479c42941572397curl 'http://localhost:8080?n=100000&blocking'  0,01s user 0,00s system 2% cpu 0,411 total

Les utilisateurs ne seront pas très contents s'ils doivent attendre 7 secondes à chaque fois qu'ils s'authentifient. Et il y a d'autres solutions, comme déporter ces calculs dans d'autres processus. Mon expérience de projets nodejs en production montre que ce n'est pas évident de trouver les parties de code qui vont poser problème (surtout qu'ils se situent en général pas dans le code que l'on écrit soi-même, mais souvent dans une des centaines de bibliothèques que l'on importe via npm) et, qu'en pratique, la latence n'est pas géniale.

C'est sympa cette distinction. En pratique ça se passe comment? Il faut annoter ses routines ou bien le compilateur s'en sort tout seul? Aussi c'est un peu bizarre de penser qu'une fonction change de catégorie si on la “pepper-printf” pour déboguer.

Ça se passe comme en nodejs : le développeur n'a pas besoin d'annoter ça, le runtime du langage va faire en sorte que les calculs se passent dans le thread principal (pour nodejs) ou les threads principaux (pour go), et quand il y a une opération bloquant d'I/O, on passe ce contexte d'exécution sur un thread dédié aux I/O. Et quand l'opération d'I/O est finie, le contexte d'exécution est de nouveau dans un état où le scheduler peut l'exécuter sur un des threads principaux. La grosse différence, c'est qu'un processus nodejs n'utilise qu'un seul cœur (en gros) alors qu'un processus go peut utiliser tous les cœurs.

Si on cherche à faire facilement du redimensionnement de capacité, la bonne stratégie dépend du contexte.

Oui, bien sûr, quand on fait des projets un peu conséquents, avec des besoins de performances ou de haute disponibilité, le langage est moins importante que l'architecture globale. Mais le fait qu'un processus nodejs ne sache utiliser qu'un seul cœur reste une bonne épine dans le pied quand on conçoit ces architectures.

Un des gros inconvénients du modèle de Nodejs est d'avoir un seul fil d'exécution en collaboratif. Cela veut dire que si ce fil d'exécution est bloqué pendant 100ms pour calculer le hash d'un mot de passe avec une fonction moderne de hashage comme scrypt, il n'y a aucune autre requête HTTP qui va être traitée pendant ce temps et la latence va augmenter de 100ms pour toutes les requêtes de ce processus.

Je préfère le modèle de multi-tâche de Go. En tant que développeur, je peux créer plein de goroutines (des fils d'exécution très légers) et le runtime de Go les place dans des threads (en préemptif). On a également la distinction entre les threads dédiées aux appels système et les autre threads dédiés aux traitements. Le nombre de threads dédiés aux traitements est la variable d'ajustement pour la montée en puissance, il est limité par la variable d'environnement GOMAXPROCS. Mais, par défaut, c'est le nombre de cœurs de la machine et c'est une très bonne valeur par défaut. J'apprécie beaucoup d'avoir par défaut la version la plus efficace, alors que pour Nodejs, ça demande souvent encore un peu de boulot de passer d'un seul à plusieurs processus : écrire le petit bout de code pour cluster, faire attention aux variables globales qui ne le sont plus (cache, pools de connexions à la base de données), etc.

Là tu décris le paterne reactor. C'est une façon de faire de l'évènementiel. On doit pouvoir dire qu'il s'agit de tout ce qui est réactif.

Désolé, je ne comprends toujours pas. Ça veut dire quoi « être réactif » ? Qu'est-ce qui est du domaine de la programmation événementielle si ce n'est l'utilisation du patern reactor ? Si la programmation événementielle, c'est réagir à des événements, j'ai l'impression que la définition englobe toutes les implémentations côté serveur, je ne vois pas comment un serveur pourrait ne pas « réagir » à des requêtes réseau.

je viens de trouver une conférence d'un développeur de sozu. Je te l'ai mis au timecode qui parle de ça, ils font de l'eventloop monothread.

Merci, je vais regarder ça, ça m'intéresse beaucoup !

et au passage il explique que haproxy (comme nginx) est aussi une eventloop monothread

C'est de moins en moins vrai pour le côté mono-thread. Le multithread arrive pour haproxy et il me semble que nginx a des pools de threads de nos jours.

Je connais mal les green threads comment ils se comportent par rapport aux contexte switch ?

https://dave.cheney.net/2015/08/08/performance-without-the-event-loop est une introduction aux goroutines de Go de ce point de vue. En gros, chaque goroutine est très légère, on peut facilement en avoir des dizaines de milliers ou plus. Le runtime de Go lance plusieurs threads, un par coeur (en fait, c'est configurable via une variable d'environnement mais c'est la valeur par défaut) qui vont servir à exécuter ces goroutines. Et il lance également des threads pour les opérations bloquantes d'I/O. Il fait ensuite en sorte que chaque thread d'exécution exécute une goroutine pendant un laps de temps assez court, puis passe à une autre. Si une goroutine est en attente, que ce soit parce qu'elle va faire une opération d'I/O ou qu'elle attende d'envoyer ou recevoir une valeur sur un channel, elle n'est plus éligible à être exécuté sur ces threads.

comment le runtime d'un langage est plus à même de faire des choix que CFS ?

Je ne pense pas que le runtime du langage fasse de meilleurs choix que CFS, par contre, il peut faire ce choix plus rapidement. Et un autre avantage est qu'une goroutine (ou plus généralement un green thread) coûte beaucoup moins cher en RAM. Le problème C10K était notamment hostile pour les programmes qui utilisaient un thread par connexion car la RAM était rapidement saturée.

comment se comporte le contexte swicth ? c'est juste qu'on reste dans l'espace utilisateur ?

Oui, on reste dans l'espace utilisateur. En général, les green threads marche en mode coopératif : ce n'est pas un scheduler qui vient interrompre l'exécution, mais le green thread qui vérifie régulièrement s'il doit laisser la main à un autre green thread (par exemple, lors du lancement du garbage collector). Enfin, les opérations à faire pour passer d'un green thread à un autre sont, il me semble, moins couteuses que pour passer d'un thread à un autre.

comment cela se passe par rapport aux caches CPU ?

Je ne sais pas.

Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ?

• dl.google.com est écrit en Go qui sert pour tous les téléchargements de Google (dont les mises à jour de Chrome)
• Træfik, un autre reverser proxy
• Caddy, un serveur http
• Consul et etcd, dans le monde devops

Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.

Je suis un peu perdu, mais pour des serveurs, si les systèmes à base d'acteurs/goroutines/green threads sont des manières événementielles de coder, qu'est-ce qui ne l'est pas ?

De mon point de vue, il y a d'un côté la programmation événementielle, avec un seul thread, une boucle événementielle et des callbacks (potentiellement abstraits via des promises, futures, observables). Et de l'autre côté, on a des modèles qui s'exécutent sur plusieurs threads et du parallélisme. Nodejs est dans la première catégorie, Elixir et Go dans la seconde.

Pour les serveurs où les performances (et notamment la latence) sont importantes, j'ai l'impression que le premier modèle est nettement en déclin (la hype, c'était plutôt vers 2010-2013), avec notamment beaucoup de Go. Nodejs a plutôt l'air de survivre auprès des développeurs Front (que ce soit pour des outils à la webpack, browserify, babel, etc. ou pour avoir le même code Angular/React/Vue qui tourne côté client et côté serveur).

Ça peut devenir plus compliqué, je suis d'accord, mais les API comme Rx sont très populaires aujourd'hui et je trouve que les Functional Reactive Programming sont plutôt lisible (voir elm par exemple, même si ça n'est pas pour du serveur).

Par contre, pour ce qui passe dans une interface graphique ou dans le navigateur, oui, là, je trouve que le modèle de programmation événementielle colle bien. Et ça a l'air plus vivant. Mais les raisons ne sont pas les mêmes et l'historique non plus (JavaScript en 1995, mais je crois que les débuts datent des bibliothèques graphiques de Smalltalk dans les années 80).

Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.

Non, il dit que JavaScript a fait des progrès, notamment avec le mot clef async, mais que le modèle du JavaScript reste inférieur pour les serveurs à celui de Go.

J'ai l'impression de revenir dans le passé, d'une bonne dizaine d'années, avec ce journal. poll, epoll et kqueue doivent tous exister depuis au moins 15 ans, ça me fait bizarre d'en entendre parler avec "plus récemment".

Le C10K problem est un problème relativement général qui constate que les serveurs n'arrivent pas à dépasser une limite de 10 000 connexions simultanées quelque soit le matériel qui est dessous

Pareil, ce problème est vieux. Actuellement, même une Raspberry Pi doit arriver à surmonter ça sans problème. De nos jours, la limite pour un serveur doit plutôt être dans les centaines de milliers de connexions dans la majorité des cas, et quelques millions pour les implémentations un peu plus poussées. J'ai par exemple en tête le travail sur Phoenix, un framework web écrit en Elixir et qui tourne donc sur la machine virtuelle d'Erlang, pour atteindre les 2 millions de websockets sur un seul serveur (2015). En cherchant rapidement, j'ai trouvé un truc en Java qui tient les 10 millions de connexions. Aucun de ces deux exemples n'utilisent de la programmation événementielle.

Je me rappelle qu'il y a quelques années, vers 2010-2012, je m'intéressais à la programmation événementielle, d'abord avec EventMachine en Ruby, puis avec Node.js. Mais, ça donnait du code compliqué et les autres langages ont fini par faire mieux (Go notamment). D'ailleurs, je trouve intéressant l'entretien avec Ryan Dahl, créateur de Node.js, où il explique que Go a un meilleur modèle d'IO que nodejs pour les serveurs. Voici une citation rapide, mais il y a plus de détails dans l'entretien complet :

That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.

Je viens de trouver un article en anglais qui explique comment configurer Firefox aux petits oignons pour qu'il protège au mieux votre vie privée (par contre, c'est de la configuration avancée, ça demande de bien comprendre ce que l'on fait) : http://12bytes.org/tech/firefox/firefoxgecko-configuration-guide-for-privacy-and-performance-buffs

Il faut quand même faire attention aux images et aux URL relatives pour les liens.

Pour ma part, j'en suis toujours à essayer de comprendre ce que font les différentes extensions (j'en découvre régulièrement des nouvelles) et lesquelles utiliser pour mon usage. Du coup, je ne me sens absolument pas en capacité de conseiller d'autres personnes selon leur profil, en dehors de choses très génériques comme : utilisez au moins un bloqueur de pub (uBlock Origin par exemple), ou uMatrix est très bien pour les experts (et seulement pour eux).

J'espère que certains contributeurs du site vont pouvoir aller plus loin et proposer d'autres dépêches sur le sujet. Si c'est le cas, j'essayerais de participer à ces dépêches, mais je me sens pour le moment trop confus sur ces sujets pour initier et structurer moi-même les dépêches en question.

Sur ces données, combien étaient renseignées volontairement par l'utiliateur? Le niveau de fiabilité est très différent dans les deux cas. Tout ce qui est déduit du comportement de navigation n'est pas fiable, ça ne serait par exemple pas opposable devant un tribunal.

La NSA avait accès aux traces GPS, aux réseaux de personnes (untel est ami avec untelle sur Facebook, lui a envoyé un mail, un SMS ou l'a appelé par téléphone), aux historiques de sites consultés et plein d'autres choses. Ils sont intéressés par croiser les données : si une personne Américaine a passé des coups de fil vers l’Afghanistan, a téléphoné à d'autres personnes américaines pour lesquelles on pense qu'elles se sont radicalisés d'un point de vue religieux, qu'elle a commandé des câbles électriques sur Amazon et qu'elles consultent les sites web d'un paquet de magasins qui vendent de l'engrais, la NSA va se dire qu'elle prépare potentiellement un attentat et va envoyer le SWAT lui rendre une petite visite de courtoisie. Pour les personnes à l'étranger, les actions sont plutôt la torture à Guantánamo ou l'envoi de drones tueurs, pas les tribunaux. Un autre domaine qui intéresse beaucoup les services secrets est l'espionnage économique : ça peut être très intéressant de savoir que les dirigeants de deux grands groupes se sont retrouvées dans la même pièce au même moment.

Mais, encore une fois, l'espionnage par des États est une problématique différente de celles par les grandes sociétés de consommation. Il se trouve juste que la NSA a trouvé pratique de piocher dans les base de données des GAFAM et vu les montants investis là dedans, ça montre que ces bases de données ont beaucoup de valeur.

Oui, mais si on prend Firefox, c'est globalement la même chose.

Firefox est plus respectueux de la vie privée que Chrome (ou moins pire, selon le point de vue adopté). Ils essayent de s'améliorer mais c'est compliqué. Un des motto du web est d'assurer la compatibilité avec les sites existants : c'est toujours possible d'afficher dans la dernière version des navigateurs des sites qui ont été fait il y a 10 ou 20 ans. Et beaucoup de choses dans le monde du web ont été standardisées à une époque où on n'avait pas conscience des dérives possibles en termes de vie privée (par exemple, les cookies, ça date du siècle dernier). Enfin, les GAFAM ont des moyens bien supérieurs à ceux de Mozilla.

Pour Mozilla, il est important que Firefox conserve des parts de marché significatives pour pouvoir peser sur les standards dans le futur. Cela demande de consacrer beaucoup d'efforts aux performances, à l'implémentation des dernières nouveautés HTML5, CSS4, ES6+, etc. Et, au final, cela limite fortement ce que Firefox peut faire pour limiter les atteintes à la vie privée.

comme si Firefox obéissait plus à n'importe quelle demande d'un tiers plutôt qu'à son utilisateur.

J'aime beaucoup le texte "User-agent: moz://a" de Steve Klabnik à ce sujet. Il souhaite changer la vision de Firefox, passer d'un navigateur à un User-Agent, c'est-à-dire se recentrer sur être au service de l'utilisateur plus que sur un navigateur dont le rôle est de faire de ce que les sites web lui disent de faire.

Aussi, pour les autres services type dépot de scripts et de polices, je n'ai pas trouvé trace d'identifiant envoyé à Google lors de requêtes.

Je viens de regarder, j'ai un cookie nommé NID sur .gstatic.com. La page d'aide https://www.google.com/policies/technologies/types/ indique à propos de ce cookie :

La plupart des utilisateurs de Google ont un cookie de préférence appelé "NID" qui est enregistré dans leur navigateur. […] Le cookie NID contient un ID unique […]

Je peux rater quelque chose mais je ne vois pas d'autre intérêt que le pistage pour l'utilisation de cookies avec un identifiant unique sur un domaine qui ne sert que des fichiers statiques.

C'est en train d'arriver, mais très doucement. Ce n'est pas facile à réglementer car ce n'est pas très visible, que ça reste un sujet assez technique et que l'on peut voir que nos hommes politiques ne sont pas toujours très à l'aise avec les technologies modernes. Mais ça arrive quand même. Un grand bond en avant a été le vote par le parlement européen du RGPD, qui va vraiment entrer en action à partir de mai 2018.

Stocker des données, ça coûte cher. Stocker des données massives, ça coûte très cher.

Non, le stockage de données ne coûte pas cher. Les services de type Drive (Dropbox, Google Drive, Cozy Cloud) offrent plusieurs Go gratuitement à leurs utilisateurs. Si ça coutait cher, ils ne pourraient pas se le permettre.

Les analyser aussi, parce que les calculs statistiques sont lourds, et parce que les infrastructures nécessaires pour calculer rapidement quelle pub il faut afficher en fonction de votre profil, ça coûte cher aussi.

J'ai entendu plusieurs fois Tristan Nitot dire que Facebook dépensait 5€ par an et par utilisateur (ça date peut-être un peu, mais ça doit rester sous les 10€ par an par utilisateur). Ça inclut les salaires, les serveurs de calcul, le stockage des photos et vidéos, la bande passante et plein d'autres choses. Et pourtant, Facebook fait parti de ceux qui stockent le plus de données sur leurs utilisateurs (et gagnent plein de sous grâce à la publicité ciblée).

Au final, si une dizaine d'euros par personne peut se permettre, à terme, d'aller vers cette industrie du pistage, ça me parait un grand maximum

Google a des revenus annuels provenant de la vente de publicité ciblée qui représentent à peu près 100 milliards d'euros. Même en comptant 5 milliards de personnes connectées à Internet, ça fait 20 euros par personne par an. Et on ne parle que de Google.

Bref, si quelqu'un (genre les génies du FBI des séries US) avait magiquement accès à ces données, il ne pourrait pas en faire grand chose

Heu, tu as raté les révélation de Snowden ??? La NSA a eu accès aux bases de données de Google, Facebook, Microsoft et ils en ont fait l'outil d'espionnage le plus efficace de tous les temps.

Mais sans parler des états, les GAFAM (Google, Apple, Facebook, Amazon et Microsoft) ont un pouvoir énorme. Prenons un exemple : Google a accès aux traces GPS de quasiment tous les utilisateurs de smartphone android. Ils peuvent en déduire quand une personne va à l’hôpital, dans quels restaurants elle va (d'ailleurs, Google Maps peut te proposer de noter des restaurants dans lequel tu es passé), là où elle habite, et plein d'autres choses. Uber avait, à partir de ses mêmes données de géolocalisation, fait une liste de personnes qui avaient découché (pour dire ça poliment, c'était plutôt Walk of shame et Rides of glory les termes utilisés par Uber).

Ça n'est bien entendu pas une raison pour ne rien faire, et c'est quand même assez étonnant que les navigateurs ne prennent pas des décisions simples et claires pour limiter le phénomène

La bonne blague, le navigateur majoritaire est développé par Google, dont 90% des revenus viennent de la publicité ciblée. Ils ne vont quand même pas tuer leur poule aux œufs d'or.

Je serai intéressé par la démonstration que GoogleAnalytics peut suivre l'itinéraire d'un utilisateur sur plusieurs sites.

Google Analytics est capable de donner des informations sur l'age, sexe, centres d'intérêts des utilisateurs ayant visité un site. Je ne vois pas comment il pourrait faire ça sans faire de croisements des données entre plusieurs sites.

GoogleAnalytics ne fait appel à un cookie tiers mais à un cookie dit "first-party".

Google Analytics peut aussi faire appel à un cookie third-party quand certaines fonctionnalités liées à la publicité sont activées.

GoogleAnalytics stocke un identifiant unique par domaine suivi, dans les cookies du domaine suivi. C'est cet identifiant qui est envoyé au serveur de GoogleAnalytics. Donc 2 sites web ayant installé GoogleAnalytics renverront à GoogleAnalytics des identifiants différents et non identiques comme ca aurait pu l'etre si GoogleAnalytics utilisait un cookie tiers.

Certes, il y a des identifiants différents par site, mais Google Analytics remonte plein d'autres informations en même temps : adresse IP, navigateur, OS, langue, taille d'écran, etc. Techniquement, je ne vois rien qui empêche Google d'associer les identifiants par site pour une même navigation grâce à cette empreinte.

Je vous invite à regarder de plus près et lire la doc GoogleAnalytics.

Fait, mais elle ne permet pas de conclure sur la manière dont Google Analytics fonctionne vraiment. Par exemple, le glossaire parle de Données ne permettant pas une identification personnelle, avec cette définition : ce sont les informations enregistrées sur les internautes de telle manière qu’il est impossible de les identifier ou d’y faire référence de manière personnelle. Et Google semble à plusieurs reprises esquiver des questions en jouant sur la frontière entre données personnelles et données ne permettant pas une identification personnelle (ie pour Google, même s'il a un profil assez précis sur Google Analytics commun à plusieurs sites, il va considérer ça comme des données ne permettant pas une identification personnelle, ce qui lui permet d'éviter d'en parler sur des questions sur la vie privée et de ne pas avoir à fournir ces données quand une personne lui demande l'ensemble des données personnelles que Google possède à son sujet).

Autre ambiguïté : sur la page d'aide Protection des données sur Google Analytics, les paramètres de confidentialité affichent ce point :

Paramètres des comptes Google : depuis le 28 juin 2016, les utilisateurs Google peuvent examiner les paramètres leur permettant de mieux contrôler les données collectées concernant leur activité sur des sites et dans des applications partenaires de Google. Pour l'instant, ces paramètres n'ont aucun impact sur les fonctionnalités, les conditions d'utilisation, les règles de confidentialité, la sécurité des données ni sur les règles de partage de données de Google Analytics.

J'aimerais bien que l'on m'explique ce que cela veut dire. Comment Google fait-il pour associer un compte Google à des données collectées dans Google Analytics (alors qu'il considère les données de Google Analytics comme ne permettant pas une identification personnelle) ?

Au final, je résumerais ça en 3 points :

• Techniquement, Google a tout ce qu'il faut pour associer un identifiant Google Analytics d'un site à un identifiants Google Analytics d'un autre site.
• Il présente des fonctionnalités qui paraissent très difficilement réalisable sans avoir unifié un profil de navigation entre plusieurs sites.
• Dans la documentation de Google Analytics, il transpire que c'est un bon moyen d'alimenter les services de publicité de Google.

Donc, certes, je n'ai pas la preuve que Google ait des profils unifiés de la navigation des internautes grâce à Google Analytics, mais ça me paraît très improbable que ce ne soit pas le cas.

Je n'en ai pas la moindre idée, je ne travaille généralement qu'avec des petits documents (moins d'un Mo).

À noter qu'il existe d'autres alternatives pour manipuler du JSON :

• JMESPath et son interface en ligne de commande, jp ;
• jl, pour JSON Lambda ;
• et des outils autour de jq.

C'est un besoin très spécifique et assez compliqué à mettre en place. Ça ne sera mis en place que si un contributeur externe est prêt à faire le gros du travail.

Dans ce cas précis, à moins que les gens de Cozy ne viennent me contredire, ces données sont stockées sans mesure de protection particulière dans la base, de manière à garantir leur utilisation pour la bonne fonctionnalité du service.

Je te contredis : on chiffre ces identifiants avant de les mettre en base de données.

Ceci dit, plus généralement, oui, il faut faire confiance à Cozy : les identifiants vont forcément être déchiffrés avant d'être utilisés pour se connecter au site de la banque, donc un admin/sys peut y avoir accès. Si tu n'as pas confiance dans Cozy, il y a la possibilité de s'auto-héberger.

Et sur le plus long terme, la méthode d'avoir un outil tiers (nous avions pensé à une extension navigateur) qui aliment le cozy sans que celui-ci n'ait accès aux identifiants est effectivement une approche plus séduisante. Mais il y a beaucoup de boulot pour y arriver, donc ça ne sera pas pour tout de suite.

Merci beaucoup pour ces encouragements !

La sortie de Cozy Cloud est une super nouvelle, je vais enfin pouvoir le recommander autour de moi !

Cool !

Concernant le partage de fichiers et dossiers entre Cozy, pourquoi ne pas réutiliser le protocole de ownCloud/Nextcloud ? Ça permettrait plus d'interopérabilité entre les clouds open-source et vous n'auriez pas à développer un autre protocole.

Sous la notion de partage, on peut retrouver beaucoup de choses : ça va de donner un accès en lecture à de la synchronisation bidirectionnelle.

Le protocole de partage d'ownCloud/NextCloud consiste à donner un accès en lecture/écriture sur certains répertoires/fichiers sur son cloud (via WebDAV, je crois) : si Alice partage un répertoire avec Bob, les fichiers de ce répertoire sont sur le cloud d'Alice mais pas sur cloud de Bob. Si Bob veut lire ou écrire dans un fichier de ce partage depuis une de ces applications, ça va aller faire une requête sur le cloud d'Alice. Ça veut dire que le jour où le cloud d'Alice est indisponible ou qu'Alice est révoqué le partage, Bob n'a plus accès à rien.

Une autre approche possible (et qui me semble mieux correspondre à Cozy) serait que Bob ait en permanence une copie des fichiers/données sur son cloud et que le répertoire partagé chez Alice et chez Bob soit synchronisé en tâche de fond.

Je ne sais pas quels standard vous comptez utiliser pour la synchronisation des contacts et agenda, mais j'espère que ça sera dav

Nous allons très certainement proposer du dav, mais ce n'est pas forcément par là que l'on va commencer. Les utilisateurs de smartphone sous android n'ont pas l'air très à l'aide avec ça : il faut installer une app tierce (DAVdroid par exemple) et ça demande une configuration pas évidente. Une idée serait que l'app mobile Cozy fasse la synchro et on irait plus rapidement en nous reposant sur le protocole de réplication de CouchBD/PouchDB. Rien n'est décidé à ce stade, ce sont des pistes de réflexion.

https://github.com/nextcloud/cloud_federation_api

Dommage que le dépôt ne contient d'un fichier README de 3 lignes et une fichier LICENCE. Attendons la suite pour voir si c'est intéressant. J'ai peur que ce soit comme Open Cloud Mesh, une coquille vide avec quelques trucs très génériques mais qui ne sont pas suffisants en pratique pour faire du partage ou, au contraire, que ce soit très spécifique à NextCloud. Mais je ne demande qu'à être agréablement surpris !

Il peut être intéressant d'avoir un mot des admins pour expliquer pourquoi ce n'est pas fait

Manque de bras. On aurait bien besoin de renforts pour faire tourner le site, que ce soit des contributions ponctuelles sur le code, filer des coups de main dans l'espace de rédaction (aider à finaliser des dépêches oubliées ou coordonner des efforts sur les dépêches récurrentes comme le noyau linux), mais aussi sur la partie administration système. Pour l'admin sys, c'est plus compliqué, car donner un accès à nos serveurs implique d'avoir bien plus confiance dans la personne, mais si quelqu'un est motivé pour contribuer, on peut en discuter pour mettre en place une entrée progressive.

Est-ce que cela demande un gros travail pour eux (et forcément pas prioritaire) ?

Ce n'est pas très prioritaire. Par exemple, on n'utilise pas des versions récentes des distributions Debian et Ubuntu sur nos serveurs et ça paraît plus urgent de faire ça avant d'avoir des trous de sécurité que de mettre en place de l'IPv6.

Pour la question de la masse de travail, je crois que l'on n'y a pas réfléchi. La première étape serait de contacter la fondation Free (notre hébergeur) pour savoir ce qu'ils en pensent.

Par rapport à Google, on pourrait amener le respect de la vie privée, parce que, oui, clairement, on ne pourra pas faire plus facile.

Par rapport à Workspace, il y a plusieurs points :
- la question de la notoriété (bon, pour le moment, Cozy n'est pas connu du grand public, si ce n'est un petit peu via Tristan Nitot, donc ça ne changerait pas fondamentalement les choses)
- ensuite la question du positionnement : Workspace est présentée comme une solution pour PME, la plupart des gens ne vont pas aller voir ce qu'il y a derrière, alors que Cozy n'a pas cette barrière
- et après, la question de la facilité (je n'ai pas d'avis sur la question, je n'ai pas testé Workspace).

On peut chipoter, mais je te cite :

mai 2018 est la date à partir de laquelle les amendes commenceront à tomber du fait que le RGPD est applicable à cette date

Ça dit bien que mai 2018 est la date de mise en application du RGPD et je pense que c'est bien la date de mise en application qui intéresse les gens, pas tellement la date d'entrée en vigueur.

C'est dispo.

Par contre, bizarre, normalement il n'y a des "Bientôt disponible" que pour les captures d'écran sur les remboursements de santé. Peut-être un problème de cache.

Nous avons passé pas mal de temps à évaluer les différentes approches possibles pour nous. En gros, il y en a quatre principales :

• passer par Linxo (accord commercial)
• passer par Budget Insight (accord commercial)
• s'appuyer sur Weboob (développement open-source)
• développer nos propres connecteurs en JavaScript (open-source également).

Et le choix est difficile. Linxo et Budget Insight offre pas mal de choses qui ne sont pas dans weboob :

• la catégorisation bancaire (dire qu'une écriture bancaire est dans « Santé », « Énergie » ou « Courses »)
• des modules à jour (les banques changent souvent leurs sites, il faut modifier les modules weboob, Budget Insight contribue souvent mais avec un retard de plusieurs semaines, probablement pour garder un avantage concurrentiel)
• un déploiement simplifié (pour utiliser les versions les plus récentes des modules bancaires de weboob, il faut généralement installer le cœur de weboob depuis la branche master, c'est assez « sport » pour nos administrateurs système)
• ne pas se faire blacklister (les banques ont recours au blocage par adresse IP, il faut au choix : avoir un agrément PCI DSS qui permet de discuter avec les banques et bientôt plus avec la DSP 2, ou jouer au chat et à la souris avec les banques).

Dans ce contexte, Weboob paraît être le pire choix pour les cozys hébergés chez sur notre infrastructure. Par contre, c'est une piste intéressante pour les auto-hébergés.

La piste que je trouve la plus intéressante est la dernière : développer nos propres connecteurs en JS. Ça permettrait notamment de les faire tourner ailleurs que sur nos serveurs : par exemple, dans le client desktop de cozy, dans une extension d'un navigateur web, etc. Et ça a pas mal de bonnes propriétés :

• les identifiants pour se connecter à sa banque ne seraient plus dans le Cozy (ou alors chiffré en zero knowldege)
• les banques ne peuvent plus bloquer ça (et, je ne suis pas juriste, mais légalement, si elles le feraient, je pense qu'elles seraient en infraction avec la GDPR)
• ça paraît bien coller avec le modèle de Cozy.

Ceci dit, il doit y avoir quelque chose comme 200 banques en France (moins si on regroupe les versions régionales d'un même groupe) et donc beaucoup de boulot pour en arriver là.

Pour commencer, on travaille actuellement sur la catégorisation bancaire. Et en attendant, on voulait quand même proposer l'application Banks et on passe par Linxo. C'est peut-être du temporaire ou c'est peut-être pour du long terme, ça va dépendre de nos réflexions et de la manière dont les banques vont s'adapter aux nouvelles réglementations (DSP 2 et GDPR). Si elles proposent des API propres avec de l'OAuth et sans délai, c'est sûr que ça va pas mal nous faciliter la vie.

Il manque beaucoup d'application par rapport au store auquel on pouvait être habitué

C'est un choix assumé. Dans cozy v2, on avait pas mal d'applications, mais c'était surtout des démos, avec peu de fonctionnalité, pas mal de bugs et une interface pas toujours très réussie. Pour Cozy v3, on a préféré mettre l'accent sur la qualité et n'avoir que quelques applications, mais avec une expérience utilisateur aboutie et que l'on peut mettre dans les mains de personnes qui ne soient pas des spécialistes de l'informatique.

N'avez vous pas lancé la sortie grand public quelques semaines trop tôt ?

Je ne sais pas, c'est très subjectif. Pour certains, Cozy Cloud était déjà utilisable il y a quelques mois. Pour d'autres, l'absence des applications de gestion des contacts et calendriers est rédhibitoire. J'ai entendu plusieurs fois dans l'univers des start-ups que si on est à l'aise avec notre produit au moment du lancement, c'est que l'on a probablement trop attendu.

Par contre, il y a une certaine vérité derrière cela. La date était définie depuis quelques semaines et lors des derniers jours avant le lancement, on a voulu bien faire et mettre les bouchées doubles pour vraiment offrir le meilleur, mais ça s'est retourné contre nous. On a aussi introduit quelques régressions dans l'urgence. Le problème des miniatures pour les photos fait typiquement parti de cette dernière catégorie.

Si j'ai bien compris seul les fichiers textes sont dans CouchDB ?

Oui, dans CouchDB, il n'y a que des données textuelles (du JSON pour être précis). Tous les fichiers que l'on peut voir dans son drive sont stockés en dehors de CouchDB. On conserve toutefois les meta-données des fichiers dans CouchDB, qui sert juste d'index.

Dans tous les cas félicitation pour le travail accompli.

Merci beaucoup !