Catégorie : individu

Monnaies, transactions et individus

Il existe deux méthodes pour gérer les échanges de valeurs entre deux entités, ou individus.
La première consiste à suivre des objets définis comme de la monnaie et de faire des transactions de réattribution de ces objets entre entités. Le solde pour une entité est l’addition de la valeur tous les objets de monnaie en possession de l’entité.
La seconde consiste à suivre pour chaque entité un indicateur de balance de la valeur dont dispose chaque entité. Le solde est à lecture immédiate et toute transaction consiste en la soustraction d’une valeur sur un compte couplé à l’addition de la même valeur sur un autre compte.

La seconde méthode ne fonctionne pas ou très mal dans le cadre d’une cryptomonnaie sans intermédiaire de confiance, c’est à dire sans une banque pour centraliser le compteur des valeurs des comptes. La transmission de valeur devient complètement impossible sans échange avec l’intermédiaire de confiance.
Mais la première méthode n’est pas forcément mieux loti. Elle permet dans le monde réel un échange de billets sans passer par un intermédiaire de confiance. Mais dans le monde informationnel (dit aussi virtuel ou numérique), la propriété d’unicité spatial et temporel n’existe plus. Et donc il faut sceller à la vue de tous une transaction avec un intermédiaire de confiance. Celui-ci peut être une chaîne de blocs, ça ne fait que décaler l’intermédiaire de confiance vers le code et ses concepteurs.

Continuons sur la réflexion d’une cryptomonnaie.
On voit aujourd’hui plusieurs acteurs étatique ou organisationnels générer de la monnaie virtuelle et/ou revendiquer sa régulation. L’extrême limite de cette pratique serait que tout le monde puisse générer sa propre monnaie… et donc qu’il y ai des taux de change entre les monnaies de tous les individus.

Chaque individu et chaque robot peut justifier d’une certaine quantité de travail par unité de temps, par exemple on peut supposer que l’humain dispose de 16 heures d’activité par jours. Dans ces 16 heures, on va réduire à 8 heures la part allouable à autrui. Mais cette capacité de travail n’a pas de valeur directe, ce n’est pas parce que l’on a une capacité de travail de 8 heures par jour que l’on va travailler 8 heures par jour. Cependant, chaque individu peut générer chaque jours une valeur, comme une monnaie, qui représente la capacité de travail journalier. Appelons la monnaie temporelle.
Il reste encore à donner de la valeur à cette monnaie temporelle.
D’un autre côté nous retrouvons des entreprises, regroupement d’individus, qui utilisent le temps de travail disponible des individus sur un patrimoine constitué d’outils de travail ou de données afin de transformer des objets, et donc d’ajouter de la valeur. Nous pourrions associer la monnaie temporelle des différents employés avec une sorte de monnaie patrimoniale afin de dégager une monnaie véhiculant de la valeur, laquelle monnaie serait rétrocédée en partie aux employés.
Comment seraient représentées ces différentes monnaies dans un système d’information ?

La réflexion n’est pas terminée…

Sondages et votes

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

Entités multiples

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

Entités multiples, gestion, relations et anonymat

On peut raisonnablement penser que chaque personne, sauf problème, a une personnalité unique. Et donc qu’une personne a un comportement unique et un réseau sociale unique.

Mais la réalité n’est malheureusement pas aussi simple.
Ne prenons que l’exemple de l’individu employé dans une société. Cet environnement est à considéré comme différent de l’environnement de vie normal, c’est à dire chez soi, dans la vie privée. Au travail, nous avons des « amis imposés par l’employeur » qui forment un réseau social souvent fortement découplé du réseau social privé. Nous avons aussi des attitudes différentes, en phase avec les attitudes que l’entreprise attend de nous. Nous sommes en short à la maison, avachi devant la télévision alors que l’on est en costume 3 pièces au travail, bien assit devant son ordinateur. Les réseaux sociaux ainsi que les échanges avec les autres individus évoluent avec l’environnement dans lequel on se situe. Chacun de nous est unique mais chacun de nous adopte une pseudo-identité variable dans l’espace et le temps. Enfin, on mélange rarement les informations de ces différentes pseudo-identités. On parle rarement en détail de sa journée de travail avec des amis le weekend autour du barbecue.
Sur un réseau social numérique, comme Facebook ou Google+, imposer une identité unique est donc une vision réductrice de l’individu humain. En cherchant à n’avoir que des identités réelles des individus, on se coupe de toutes leurs identités annexes. Et une relation de travail fait typiquement d’une identité annexe.

On ne s’attardera pas ici plus longtemps sur la justification des entités multiples mais plutôt sur la technique et les possibilités que cela ouvre.

Les premières expériences avec les identités dans nebule montrent qu’un individu peut, bien évidemment, avoir plusieurs entités différentes. Chaque entité peut avoir une « vie » propre, c’est à dire un réseau social à part. Une entité peut mettre en place des entités esclaves, elles sont dans ce cas parfaitement autonomes. Elles restent autonomes même si elles sont tenues par une entité maitresse.
L’entité puppetmaster est le premier exemple d’entité maitresse. Il y a dans ce cas une idée de validation forte. On peut avoir d’autres types de relations entre entité maitresse et entités esclaves. On peut avoir des cas où la validation serait au contraire réduite voir dissimulée, dans les cas où l’anonymat est recherché.

Vis-à-vis de l’interface homme-machine, la notion même d’entités multiples n’est pas triviale. Sur nos systèmes d’information actuels, sur nos ordinateurs, téléphones, tablettes, etc… il est courant de disposer de plusieurs comptes utilisateurs. Mais on ne peut utiliser simultanément qu’un seul compte à la fois. Tout au plus peut-on changer temporairement d’identité (élévation de privilèges par exemple). Chaque action se fait sous une et une seule identité.
Si on utilise plusieurs comptes de messagerie ou comptes de réseaux sociaux numériques, il faut quitter un compte pour pouvoir accéder à un autre.

Dans une interface exploitant nebule, il est cependant possible de travailler de la même façon ou différemment.
On peut disposer de plusieurs entités et se connecter à une et une seule entité à un instant donné.
On peut aussi se connecter à une entité maitresse et basculer, immédiatement après, vers une des entités esclaves. C’est déjà fonctionnel dans sylabe. Il est même possible de revenir facilement vers l’entité maitresse pour éventuellement repartir sur une autre entité esclave. Ainsi on évolue dans des environnements isolés via des entités autonomes. De plus, la relation entre l’entité maitresse et les entités esclaves peut être masqué (offusqué).
Mais il est possible d’aller plus loin. On peut tout à fait imaginer exploiter simultanément plusieurs entités. Cela permet d’avoir une vue synthétique de plusieurs réseaux sociaux ainsi que des échanges associés. Le cloisonnement dans ce cas est invisible pour la consultation tout en restant potentiellement très fort entre chaque entités. En pratique, on pourrait voir les activités de tous les « amis » de toutes les entités esclaves que l’on contrôle même si chaque entité esclave n’a strictement aucun rapport ou aucun lien avec les autres entités esclaves. Il faut par contre définir une entité avec laquelle on agit par défaut, au risque de casser le cloisonnement des entités par des liens inappropriés. On peut même imaginer que des interactions avec un réseau social particulier se fassent avec l’entité esclave attaché au réseau en question, on conserve ainsi le cloisonnement des entités mais pas celui de l’information. En somme, c’est un peu ce que l’on fait déjà avec un logiciel client messagerie et plusieurs comptes de messagerie…

Facebook et l’anonymat

Les positions bougent aussi du côté de Facebook. Dans la suite de l’article précédent sur Google+ et l’anonymat, c’est au tour du premier réseau social de faire des concessions sur la possibilité de créer des comptes anonymes… dans une certaine mesure.

Depuis le 1er octobre, il est possible d’utiliser un pseudonyme. Tout n’est pas encore permit mais l’avancée est de taille alors que la vie privée n’était clairement pas la priorité de Facebook. Et l’anonymat était même malvenu jusque là pour inciter les internautes à avoir de vraies relations d’amitié. Il était aussi quand même plus intéressant pour les publicitaires de disposer d’informations fiables sur les utilisateurs…

Depuis peu, une nouvelle messagerie est en cours d’élaboration, par Facebook, pour permettre des échanges volontairement anonymes. Un vrai retournement… ou une opportunité commerciale de plus…

CF :
– http://www.lemonde.fr/economie/article/2014/10/02/les-pseudonymes-finalement-autorises-sur-facebook_4498801_3234.html
– http://www.lemonde.fr/pixels/article/2014/10/08/facebook-va-lancer-une-application-permettant-des-echanges-anonymes_4502637_4408996.html

Partage simplifié d’une entité

Pour l’utilisateur d’un logiciel de communication, mémoriser un mot de passe complexe est une tâche ardue, voir sans intérêt.

Le problème est le même avec les pages web, leurs noms doivent être facile à retenir et à retaper sans faute. Et il en est ainsi pour les correspondants dont il faut se souvenir au pire de leurs adresses emails ou au mieux de leurs noms ou pseudonymes. Dans certains cas, il faut se souvenir du pseudonyme et du site web sur lequel on peut trouver un correspondant.
Le projet nebule vise notamment à fédérer des identités en même temps que les données. Mais cela entraîne inévitablement l’utilisation d’identifiants globalement uniques, donc longs.
Certains projets comme minilock visent à essayer de réduire ces identifiants avec des encodages comme le Base58.

On peut aussi utiliser uniquement une localisation, c’est à dire adresse de type http ou email. Ainsi, pour une adresse http, il faut héberger à une adresse précise une entité par défaut. Si un hébergeur veut gérer plusieurs entités, il ne pourra pas les garder facilement dans le même espace, le même nom de domaine, mais il devra au contraire les séparer dans des espaces différents. Mais est-ce vraiment la solution ?

Dans l’article sur le Détournement de liens de mise à jour (CF blog sylabe), on a vu qu’il était possible de créer une sorte de pseudonyme d’entité nebule. C’est un détournement du lien de mise à jour depuis un objet fictif vers, dans notre cas ici, une entité définie. Prenons comme exemple un prénom Fabio auquel correspondrait un objet fictif fab10. Ainsi, sur une instance de nebule, cet objet reverrait systématiquement vers l’entité de l’utilisateur. Ça résout le problème localement.

Cependant, on peut facilement imaginer que tous les utilisateurs qui ont se prénom vont avoir des prétentions sur cet objet fictif. Comment va se résoudre le conflit ?
Assez mal en fait. Si on a des amis en commun, on devrait rapidement retrouver le bon identifiant de l’entité. Mais ça se corse si on a deux entités avec des prétentions sur ce pseudo dans nos entité proches. Dans ce cas, c’est le calcul social qui va déterminer l’entité qui pourra hériter du pseudo, et cela fait une chance sur deux de ne pas tomber sur la bonne entité…
En plus, on peut imaginer aussi que dans une situation de harcèlement ou de dénigrement, des entités agressives essayent aussi de s’approprier le pseudo. Cela pourrait rendre le pseudonyme difficile à utiliser puisqu’il ne renverrait que rarement à la bonne entité.

Cette méthode est donc loin d’être parfaite. Elle peut être raisonnablement utilisée soit dans un petit groupe d’utilisateurs soit si elle est associée à une localisation http, email, etc…

Google+ et l’anonymat

Dans un article, le réseau social Google+ revient sur les restrictions de nommage de ses utilisateurs. Il va maintenant être possible de choisir des pseudonymes de façon à profiter du réseau social en ligne tout en permettant un certain anonymat.

Il était temps…

L’étape suivant serait de permettre à tout utilisateur de pouvoir nativement créer des pseudonymes partiellement autonomes. L’idée est en cours de mise en place sur le projet sylabe. La condition du succès est bien sûr que qu’un pseudonyme puisse avoir une vie propre, ses propres relations et groupes (cercles sur G+) et que l’on bascule de façon équivoque de l’entité principale vers un pseudonyme. C’est un bon moyen de répondre à des besoins d’anonymisation tout en facilitant la gestion de l’anonymisation par les vrais utilisateurs.
Il faudra aussi déterminé si un pseudonyme apparait clairement comme tel dans les utilisateurs ou si sa vraie nature reste cachée pour préserver son efficacité.
Bien sûr, il faudra garder à l’esprit que monsieur Google aura accès à toutes les entités, que ce soit les vrais utilisateurs ou leurs pseudonymes. Cela répond dans ce cas aux problèmes légaux pour pouvoir remonter, sur décision d’un juge, à la personne physique derrière un pseudonyme.

Modes de traitement

Le projet nebule en lui-même donne un cadre stricte dans la forme des objets et des liens. Mais il ne donne que des orientations sur le traitement, c’est à dire l’interprétation, de ces objets et surtout de leurs liens.

Il existe aujourd’hui trois stratégies dans le traitement des objets et des liens.

Le mode ouvert

C’est la façon la plus simple d’utiliser les objets et les liens puis qu’aucune vérification n’est réalisée.

Cela implique pour commencer que les empreintes des objets ne sont pas vérifiées. Ces empreintes sont donc de pures URI avec un faible attachement au contenu des objets qu’elles référencent. Cette considération entre en conflit avec l’un des fondements du projet nebule puisque l’empreinte est strictement attaché à un objet, son contenu en fait, et que toute modification de cet objet entraîne implicitement la création d’un nouvel objet avec une empreinte propre.

Les liens ne sont pas vérifiés, ce qui veut dire que leur provenance, n’étant pas assurée, ne peut pas être non plus utilisée. Ainsi, les liens sont vus sont leur forme la plus réduite, c’est à dire la forme équivalente RDF avec la date et l’action.

Le traitement s’en trouve extrêmement accéléré. Il est pas contre impossible d’établir un échange digne de ce nom ne serait-ce qu’entre deux entités. Les notions de propriétés public et privée n’ont pas de fondement dans ce cas. On ne peut envisager ce fonctionnement que sur un périmètre restreint d’un centre de calcul et dédié à une tâche unique. On peut tout au plus envisager une passerelle vers le monde extérieur qui vérifierait scrupuleusement les entrées et signerait les sorties.

Ce mode de traitement n’est pas recommandé dans le cadre du projet nebule.

Le mode social

La prise en compte du côté social implique que l’on tienne compte de l’émetteur des liens, et donc de la validité de ceux-ci. A l’opposé du mode ouvert, cette façon de procéder est la plus complexe et la plus lente. Mais c’est aussi la plus intéressante.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Comme nous sommes dans un environnement social, c’est à dire avec de multiples entités, nous devons procéder à un tri des liens en fonction de leur provenance. Les objets sont vérifiés mais leur usage dépend exclusivement de leurs liens, et donc notamment des émetteurs de ces liens.

Lorsque deux actions sont contradictoires, il faut tenir compte de l’environnement sociale et plus seulement du facteur temporel. Il y a des différences dans la confiance que l’on accorde aux autres entités, et donc dans les liens quelles génèrent. Le tri des liens est réalisé suivant une pondération qui reflète la relation avec les entités émettrices. C’est une pondération en tout point sociale et est attachée aux entités.

L’offuscation de liens permet de cacher ou de tromper une entité sur la vraie pondération qu’on lui accorde. Mais il fait garder à l’esprit que plus elle est discordante plus elle a de chance d’être découverte ou au minimum de provoquer de la confusion.

Une pondération peut aussi être envisageable sur les objets. Cela permet en augmentant la pondération de réduire proportionnellement l’influence des autres entités sur un objet précis.

Enfin, une pondération peut être réalisée sur le type de lien et éventuellement en fonction d’un des objets référencés par un lien.

Ici, pour le projet nebule, clairement tout est quasiment à faire. La pondération des entités n’est pas encore formalisée. La pondération des objets et théorique. Et la pondération sur le type de lien n’est qu’une prévision par rapport aux modèles actuels.

Le traitement des objets et des liens, déjà ralentis par les vérifications de base, est encore plus complexe du faire des calculs de pondérations, et donc plus lent encore.

Ce mode de traitement est celui adopté par la librairie nebule de référence en php. Par extension, c’est aussi le mode de traitement utilisé dans le projet sylabe.

Le mode strict

La prise en compte du côté social est partielle, elle a même une forme exclusive. On se situe à mi chemin entre le mode ouvert et le mode social en terme de complexité.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Contrairement au mode social, la prise en compte des entités n’est pas globale mais au contraire exclusive. On ne reconnaît que les liens de certaines entités précises. Afin de simplifier encore plus le traitement, il n’y a pas de priorisation ou de pondération dans l’exploitation des liens. Si plus d’une entité est reconnu, toutes ont le même poids et donc le même pouvoir de décision dans l’utilisation des objets. On attend ici des décisions rapides, fiables et reproductibles dans un environnement large mais avec un groupe très restreint d’objets et de liens à prendre en compte. Tout le reste est ignoré.

C’est un fonctionnement de type paranoïaque. Les notions de propriétés publique et privé sont assurées mais les échanges avec d’autres entités sont très limités et potentiellement conflictuels parce que non pondérés, non régulés. Ce fonctionnement est tout indiqué pour gérer la sécurisation de certains outils informatiques comme le déploiement de code.

Le cas le plus représentatif est par exemple la reconnaissance des entités puppetmaster, bachue et cerberus dans la validation de la librairie nebule de référence en php mais aussi du code du projet sylabe.

Ce mode de traitement est utilisé par le bootstrap en php et la librairie nebule de référence en bash. Le bootstrap ne reconnaît que les objets de bachue ou de l’autorité locale moyennant un bannissement de cerberus et sous la supervision de puppetmaster.

Renouveler son entité

Pour l’instant, les entités sont figées. Mais il faudra prévoir de changer leurs mots de passes et de les migrer vers de nouvelles entités au besoin.

Le changement de mot de passe nécessite de régénérer l’objet de clé privé qui change. Il faut évidemment préalablement déverrouiller l’entité, donc sa clé privée. Une fois le mot de passe changé, il faut lier la nouvelle clé privée à la clé publique puis supprimer le lien de l’ancienne clé privé. Il faut marquer à supprimer l’objet de l’ancienne clé privée.

Dans le cas d’une migration d’entité, c’est un peu plus complexe. Ce besoin répondra souvent suite à un problème de compromission ou de corruption d’entité.
Il faut générer une nouvelle entité autonome. Faire un lien de mise à jour de l’ancienne entité vers la nouvelle. Dans la mesure du possible, ce lien de mise à jour doit être signé à la fois par l’ancienne et la nouvelle entité. Puis l’objet de la clé privée de l’ancienne entité doit être marqué à supprimer à la fois par l’ancienne et la nouvelle entité.
Si l’entité avait été corrompue, c’est à dire qu’il était impossible de la déverrouiller, c’est un vrai problème. Dans ce cas, les liens de mise à jour d’entité et de suppression de clé privée ne pourront être signés par l’ancienne entité. rien ne permet de distinguer une opération légitime suite à un problème d’une tentative de détournement par une autre entité. Il peut tout au plus être possible de regarder si l’entité génère de l’activité, donc qu’elle n’est pas corrompue.
En cas de compromission de l’entité, on peut faire une mise à jour vers une nouvelle entité. Mais celui qui a volé la clé privée de l’entité peut le faire aussi de son côté. Il est difficile dans ce cas de déterminer qui est la véritable nouvelle identité et pas une usurpation… Peut-être le côté sociale, comportemental, d’une entité peut nous aider à posteriori?

RSE ou RSE ?

En recherchant la définition de l’acronyme RSE, je tombe sur deux définitions… Problème assez récurrent en fait avec les acronymes puisque n’importe qui peut en inventer et les utiliser sur la place publique à son bénéfice.

D’un côté j’ai une belle page bien fournie sur Wikipédia et une page gouvernementale officielle parlant de Responsabilité Sociétale des Entreprises :
РResponsabilit̩ Soci̩tale des Entreprises РWikip̩dia
– Qu’est-ce-que la responsabilité sociétale des entreprises – Ministère du développement durable
On y parle donc de responsabilité des entreprises, de développement durable, de gestion de risques, des impacts environnementaux et sociaux, enjeux, investissements, outils, normes, médiatisation, aspects juridiques, etc…

De l’autre un article sur 01net.com qui surfe sur la vague des révélations sur PRISM, ce qui n’est pas un mal en soi :
– Le RSE : un lanceur d’alerte en entreprise – 01net
On retrouve bien en fin d’article un paragraphe sur le RSE, l’environnement et les risques. Mais RSE, répété à l’envie tout au long de l’article, désigne ici Réseau Social d’Entreprise. En gros un simili Facebook restreint au périmètre de l’entreprise.
Mais n’y a-t-il pas déjà un terme pour cette fonctionnalité? Oui, c’est le groupe de travail (groupware). Ah oui, c’est vrai, le créneau sur ce nom est déjà bien plein. D’un autre côté, la RSE ne doit pas plaire à beaucoup de chef d’entreprises. Bref, Voila typiquement un article à visée commerciale…

Mais ce post n’est pas là pour critiquer l’article. Les acronymes posent un problème de gestion de leurs définitions. Celles-ci ont rarement une portée globale, elles n’ont souvent qu’une définition de portée locale ou régionale. C’est cette absence de centralisation qui, à priori, serait la source des conflits.

Comment vont se comporter les acronymes dans nebule?
Reprenons le cas de la RSE. En pratique, c’est l’objet cec7b8a511f6d30def09266e7595f1dd9a301b3ba868444d2b14236dccc127b1. Aujourd’hui, cet objet n’existe sur aucune machine supportant nebule, mais si il était créé ce serait avec cette empreinte (sha256).

Premièrement, cet objet peut être marqué par des liens de type subdivision s. Il est en effet possible avec ce type de lien de savoir qu’un texte, un article de presse par exemple, contient cet acronyme. Cela facilite la recherche.
Cet exemple d’acronyme est trop petit mais le principe reste valable, le même article de presse peut être téléchargé morceaux par morceaux par ses abonnés. C’est un fonctionnement de type P2P. Chaque morceau connu peut être téléchargé à des endroits différents, puis l’article de presse peut être reconstitué. En pratique, on accélère donc les échanges d’objets.

Ensuite, L’objet de l’acronyme peut aussi être marqué par des liens de type dérivation f. Ces liens peuvent renvoyer vers d’autres objets contenant la ou les définitions de l’acronyme.
C’est un intérêt pour résoudre les conflits autour des définitions d’acronymes. En effet, chaque lien est signé par une entité, donc on sait qui en est l’initiateur. Et comme toute entité gère individuellement ses propres relations de confiances, la définition d’un acronyme sera donc dépendante des entités à qui on fait confiance, mais aussi en fonction de leur niveaux de confiance relatifs.
Donc, si on a une forte confiance en l’état, ce sera la RSE. Si on a une grande confiance en l’auteur de l’article de 01net, alors ce sera le RSE. Si on est chef d’entreprise, il y a de fortes chances que ce soit la RSE de toute façon…

Individu, sociabilité, universalité

L’affaire PRISM révélée par Edward Snowden n’en finit pas de provoquer des secousses numériques autour de la NSA, des grosses sociétés américaines et de la vie privée des citoyens/sociétés.

On entend parler régulièrement de la possibilité de créer de multiples chemins de communications entre individus. Ici multiple est à comprendre dans le sens où chaque connexion passe par un certain nombre de serveurs différents et ce de façon anonyme pour les serveurs. Ceci dans le but de garantir l’anonymat de l’internaute.

Il existe TOR pour la navigation. Ce pourrait être le cas avec la messagerie (Caliop ?). Mais est-ce une solutions suffisante?
Le journal Lemonde a publié un article sur un internet décentralisé pour des usages centralisés (cf lien). Rien que le titre suffit à exprimer tout le paradoxe de notre utilisation de l’internet…

Un autre problème s’ajoute, l’anonymisation est aussi utilisée par des criminels. Tout en sachant que les criminels d’un pays/communauté sont parfois les héros d’un autre. Comment distinguer l’utilisation légitime, ce qui est bien ou pas? Vaste débat.
Un outil ayant uniquement une structure globale mélange les usages légitimes et réprouvés, quel qu’en soit leur acceptation. Un outil qui respecte une structuration régionale ou locale est plus à même de coller à l’acceptation de certains usages, ou à leur régulation. Il est aussi capable de suivre l’évolution des mÅ“urs et usages tout en permettant des échanges globaux.

Le projet nebule peut-il apporter quelque chose? Je pense que oui, quelque chose de nouveau surtout. Aujourd’hui, tous les efforts portent sur des tentatives de sécuriser les serveurs centraux, les relais intermédiaires, les chemins empruntés et les protocoles. Cette nouvelle chose que propose nebule est de penser directement au niveau de la donnée, de gérer sa confidentialité et ses échanges.

La structure locale de nebule est de taille variable. L’individu est la base. Il met en place naturellement des échanges dits sociaux proches jusqu’à une organisation de la taille d’un pays. Il est aussi capable d’exploiter de façon universelle des informations quelles qu’en soient leurs localisations.

Liens :
РLemonde РBitcoin, BitTorrent, TOR : un internet d̩centralis̩ pour des usages centralis̩s
– http://fr.wikipedia.org/wiki/PRISM_%28programme_de_surveillance%29
– http://fr.wikipedia.org/wiki/Tor_%28r%C3%A9seau%29
– https://www.torproject.org/
– http://www.caliop.net/