Ce journal constitue un début de réflexion sur la récolte de l’ensemble des données qu’ont peut recueillir sur nous même, et sur la manière de les mettre à disposition à des « demandeur de données ». Je pense en particulier à la recherche scientifique.
Aujourd’hui, ce sont de très gros organismes comme l’état ou les GAFAM qui ont les moyens de récolter des masses de données, et on a très peu de contrôle sur ce qu’ils en font. Ils se constituent en acteur incontournables et poussent à utiliser leurs services à eux pour aggréger le plus de données possibles. Ils ont beaucoup de pouvoir pour savoir qui va acheter ou utiliser les données. On peux les soupçonner légitimement de sacrifier à in moment ou a un autre l’éthique à la rentabilité, y compris de manière non transparente, tout on ne permettant pas l’accès aux données à des acteurs qui pourraient y avoir accos pour faire des choses utiles.
J’ai l’impression qu’il serait possible de les court-circuiter par des techniques de partage de données interopérables et de rendre à l’individu du pouvoir sur l’utilisation de ses données.
Imaginons que des chercheurs fassent des recherches sur les déplacements des citoyens. Beaucoup d’entre nous ont des dispositifs capables d’enregistrer ses déplacements … (et bien d’autre chose). Une manière « classique » de travailler pour un chercheur est de monter une expérience, éventuellement de trouver des volontaires pour remonter les données, de trouver des jeux de données existants …
Imaginons qu’on les autorise, si on le veux bien, à nos données. On pourrait monter un genre de site (ou d’appli) à la mode « financement participatif », mais avec des données à la place des sous. Une « bourse de données » en quelque sorte. Les chercheurs décriraient une expérience, les données dont ils ont besoins, et on pourrait individuellement leur uploader nos données (et les anonymiser) ou leur laisser un accès à la demande.
Je pense que c’est très faisable techniquement, avec un peu de crypto pour aider à garantir la confidentialité, des formats ou des APIs ouvertes pour les formats d’échanges, des logiciels libres pour auditer le code. On peu même imaginer un « conseil scientifique » qui audite les demandes des chercheurs avant de les publier. Une appli type « tinder » pour dire « je veux «changer » ou « je zappe cette expé ». Une demande aux chercheurs de publier le jeu de données qu’ils ont finalement utilisé après coup.
Qu’en penses-tu, libriste ?
# Cozy ?
Posté par Aeris (site web personnel) . Évalué à 3.
Je dis ça, mais c’est un peu exactement ce que fait Cozy, non ?
Tu veux faire des traitements sur des données, tu proposes une application Cozy qui va pouvoir utiliser les données de tes utilisateurs, en local sur leur cozy, pour faire ton traitement, sans jamais avoir toi-même directement accès aux données.
Il y a aussi 1 thèse en cours sur la possibilité de faire la même chose avec du calcul distribué entre tous les cozies, toujours sans accès direct aux données et avec de fortes garanties de confidentialité et d’anonymat.
[^] # Re: Cozy ?
Posté par Thomas Douillard . Évalué à 2.
Intéressant. Je n’avais jamais regardé Cozy de près.
Je ne sais pas si c’est totalement ça. J’ai quelques questions :
A priori oui : https://github.com/Ljinod/cozy-docs/blob/master/src/documents/en/hack/cookbooks/sharing.html.md
Ça semble donc résoudre de problème du partage de données.
Pour le problème de format par contre je sais pas, Cozy semble être conçu pour que l’appli puisse définir ses propres types, donc n’impose par de format, un peu comme Wikidata. Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.
Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?
[^] # Re: Cozy ?
Posté par Aeris (site web personnel) . Évalué à 2.
Non, l’application s’exécute localement sur ton cozy à toi. Tu peux envisager de remonter le résultat de tes analyses à ton serveur par la suite. À terme on aimerait bien que ça suppose l’acceptation de la part de l’utilisateur (cozy en mode pull uniquement par défaut, pour le push il faut autorisation explicite), mais pas géré pour le moment.
Il n’y a actuellement pas d’application permettant de traiter les données de poids, mais on peut déjà facilement crééer un connecteur pour aller récupérer les données des gros silos (fitbit & cie) et les stocker bien à l’abri dans ton cozy, pour ensuite développer des applications pour traiter ces données.
C’est en train d’arriver. On en avait un pour notre v2, là le store pour la v3 est en train de sortir.
[^] # Re: Cozy ?
Posté par Thomas Douillard . Évalué à 2.
Donc non, pour l,instant ça colle pas, tu ne peux pas faire d’étude épidémiologique en te créant un jeu avec les données de 1000 personnes et faire des stats dessus. Tu peux juste faire une analyse locale des données d’un individu.
A la rigueur j’ai l’impression que la fonctionnalité « partage » pourrait coller : «je partage ce type de données sur telle plage de temps avec ce groupe de chercheurs ».
[^] # Re: Cozy ?
Posté par Aeris (site web personnel) . Évalué à 2.
Pour la partie calcul sur 1000 personnes, c’est une thèse qui est en cours chez nous en partenariat avec les labos de l’INRIA
https://www.inria.fr/equipes/petrus
[^] # Re: Cozy ?
Posté par Thomas Douillard . Évalué à 2.
On peut avoir des détails sur la thèse ? L’objectif au moins.
J’ai du mal à voir comment on peut constituer un jeu de donnée en garantissant (j’imagine) que les données restent chez soi (vu que c’est un des objectifs d’owncloud), un minimum d’information doit filtrer.
Par exemple pour calculer une moyenne (genre si on veut calculer la moyenne de l’age des gens qui participent) on peut faire ça de manière incrémentale. Ça nécessite deux nombre : un nombre pour la somme et un nombre pour le nombre de personne dont l’age a été sommé, la moyenne étant la division des deux. Si on imagine une chaîne entre les participants, le premier passe ces deux nombre au suivant, le second connaît l’age du premier (ce n’est plus vrai opur les suivants) … donc le premier ne doit pas passer directement l’info au second. Il pourrait passer par un tiers, l’expérimentateur, mais de même, l’expérimentateur doit peut en déduire l’âge du premier.
J’ai lu des trucs sur les systèmes homomorphes : http://www.pourlascience.fr/ewb_pages/a/article-chiffrement-homomorphe-deleguer-des-calculs-sans-divulguer-les-donnees-35907.php mais dans le cadre d’une expérience scientifique (ouverte), il peut être de bon ton de publier ses données anonymisées pour soumettre son analyse aux autres chercheurs qui voudraient refaire des calculs. Dans ce cas la question deviendrait, est-il possible de créer un jeu de données anonymisé de manière homomorphe, s’il s’agit d’effectuer les calculs chez les clients ?
Plus simplement, s’il s’agit simplement de constituer un jeu de données anonymisé, l’expérimentateur à une « clé privée », diffuse la clé publique à l’ensemble des participants qui chiffrent leurs données, agrègent ces données chiffrées entre eux puis finissent par renvoyer un jeu complet à l’expérimentateur qui a la clé de décryptage sans que l’expérimentateur puisse savoir qui a envoyé quoi mais en pouvant décrypter l’ensemble grâce à sa clé.
Une fois ce jeu anonymisé constitué, il peut servir à toutes les analyses qu’on veut …
[^] # Re: Cozy ?
Posté par Aeris (site web personnel) . Évalué à 4.
Il y a 2 thèses pour être exact :
Le but de faire plus ou moins ce que tu cherches à faire. Lancer un calcul distribué sur des données sans que celui qui a demandé le calcul ne puisse avoir accès aux données.
Ça pose effectivement potentiellement le problème de la vérifiabilité. Au mieux tu peux retenter l’expérience, mais tu ne peux pas vraiment refaire le calcul sur les mêmes données.
[^] # Re: Cozy ?
Posté par Thomas Douillard . Évalué à 3.
Ça me semble un peu paradoxal quand même. Il y a forcément une certaine quantité d’information qui « fuit » sur ces données. On se situe à la limite entre le cas ou le programme qui tourne sur le client fait un « return null » et un ou il fait un « return data accessibles » tel quel. Dans le cas intermédiaire il fait un traitement qu’on peut assimiler à une « compression » avec perte (plus ou moins importante) de l’ensemble des données.
Si l’enjeu c’est l’anonymat, la perte d’information doit être suffisamment importante pour qu’il soit compliqué de remonter à partir des données publiées jusqu’à l’émetteur de ces données. Cela dit si ce sont des données « privées » on a pas forcément de point de comparaison, effectivement. Est-ce que finalement il ne suffirait pas de publier les données privées en rendant les données de l’utilisateur qui sont accessibles par d’autres canaux (l’annuaire par ex) suffisamment « floues » (en ne conservant par exemple que des coordonnées tronquées pour l’adresse) pour qu’il soit difficile de faire le chemin inverse. La question clé serait alors « quelles informations on doit biffer / approximer / agréger » pour que les données publiées au final ne permette pas d’identifier les donateurs d’infos. Une histoire d’entropie des données utilisables pour l’identifier.
Après réflexion, je pense comprendre votre objectif : si les calculs ont lieux chez le client, il a le contrôle sur quel degré d’info il veut laisser fuiter.
[^] # Re: Cozy ?
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 14 septembre 2017 à 23:57.
Le problème est qu’actuellement, on ne sait pas réellement faire d’anonymisation.
Même anonymisées, les données peuvent encore en dire beaucoup sur une personne, via de la corrélation ou des métadonnées.
Une anonymisation efficace fait aussi trop perdre de sens aux données, qui en deviennent moins voire plus du tout utilisables.
Pas mal de recherches scientifiques sur le sujet vont dans ce sens : une bonne anonymisation nécessite de ne plus être capable de traiter les données…
Par exemple pour des données démographiques, il faudrait casser le lien familial entre les individus pour réellement anonymiser le jeu de données (une famille de 7 porte beaucoup d’information par exemple puisqu’est relativement rare), lien qui est pourtant vital pour l’analyse.
Pour des données médicales, il va falloir supprimer tous les patients à pathologies rares, qui sont pourtant les plus intéressantes statistiquement parlant.
Traiter les données nécessitera donc, en tout cas à l’heure actuelle, de lever au moins partiellement l’anonymat des utilisateurs…
C’est pour ça que Cozy considère que rien ne doit sortir du Cozy pour le moment et que tout est calculé localement.
[^] # Re: Cozy ?
Posté par Thomas Douillard . Évalué à 2.
Ça se passe comment pour l’agrégation ?
Vous voulez dire quoi par « sur le même cozy » ? qu’on ne peut pas calculer une moyenne entre deux instances perso de Cozy parce que ce n’est pas « le même Cozy ? »
[^] # Re: Cozy ?
Posté par Aeris (site web personnel) . Évalué à 1.
Pour le moment, il n’y a rien qui sort du Cozy, donc pas réellement d’aggrégation. Les cas d’usages sont donc plutôt orientés « personne ». On peut envisager des applications cozies qui remontent des données à la demande, mais ce n’est pas le but recherché, justement par soucis de confidentialité et de contrôle de tes données (on cherche plutôt à sortir les données des silos, pas à en créer de nouveaux :P).
C’est la thèse en cours qui va nous apporter le calcul distribué tout en étant respectueux de ta confidentialité.
# Retroshare
Posté par NumOpen . Évalué à 1.
http://retroshare.net/index.html
[^] # Re: Retroshare
Posté par Thomas Douillard . Évalué à 2.
Oui ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.