Archive for the ‘sociabilité’ Category

Cosignature et validation de transactions

Jeudi, août 22nd, 2019

Un mécanisme de cosignature fonctionnant sur le principe de quota peut être une réponse possible à la validation de transactions dans un groupe fermé d’entités. La difficulté est que chaque entité peut ne pas reconnaître la même composition du groupe du fait du traitement social des liens du groupe. Mais si le groupe est explicitement définit dans l’objet de groupe avec le quota attendu, alors cela devient jouable…

Filtre social de liens sur réputation du signataire

Vendredi, février 15th, 2019

Dans les filtres sociaux des liens, deux nouveaux types sont ajoutés : reputation et unreputation

Cela permettra à terme le tri par rapport à la réputation d’une entité. Cependant, la pondération des entités n’étant pas implémentée, ces deux filtres sont pour l’instant équivalents au filtre social none.

Traitement social des liens sur liste

Jeudi, février 14th, 2019

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

Soi-même ou moi-même

Mercredi, février 13th, 2019

Dans la partie gestion sociale de la bibliothèque de nebule, il y avait peu de sous-parties dédiées à des calculs sociaux des liens. Il y avait notamment une partie self dédiée à la reconnaissance de ses propres liens, et son inverse notself pour exclure ses propres liens d’une recherche.

Cependant, la bibliothèque reconnait en quelque sorte deux type de soi. Il y a le soi de l’entité connectée et le soi de l’entité que l’on regarde. En quelque sorte un moi et un soi. Quand on désigne moi-même il est fait explicitement référence à ma personne, ou dans notre cas à son entité. Alors que le soi-même désigne le moi-même d’une personne, qui peut être quelqu’un d’autre, dans notre cas une autre entité.
Dans la bibliothèque, cette distinction apparaît dans la place de deux variables qui portent le même nom $currentEntity. Utilisée dans la classe très généraliste nebule, elle désigne l’entité connectée (déverrouillée). Utilisée dans la classe Applications elle désigne l’entité que l’on regarde, de la même façon que l’on désigne un objet que l’on regarde.

Cela a mené à devoir dissocier le traitement social pour refléter cette distinction. Ainsi self et notself références maintenant l’entité que l’on regarde (au travers d’une Application). Et myself et notmyself désigne l’entité connectée elle-même, c’est à dire l’entité active.

Ce comportement peut parraître subtil mais il prend tout son sens dans l’application messae et le module messagerie de sylabe. en effet, l’affichage de la liste des conversations se fait par rapport à une entité, donc des conversations de soi-même d’une entité. Mais si on ne précise pas d’entité alors c’est de l’entité connectée que l’on parle, donc soi-même.

D’autres types de traitement sociaux des liens seront ajoutés plus tard. Il faudra notamment trouver un moyen de pondérer les liens de ses amis…

Réorganisation des entités spéciales – groupes d’entités

Jeudi, décembre 20th, 2018

Suite de l’article Réorganisation des entités spéciales – inventaire de départ.

Le regroupement d’entités par rôle correspond à la création d’un groupe d’entités, groupe auquel on va donner le rôle. Il va être possible avec le groupe de définir de nouveaux filtres sociaux de tri des liens. Ces filtres viendront remplacer un filtre historique, restricted, qui a un rôle important mais dont le nom devient ambiguë.
Par exemple, à l’entité maître du code bachue il sera possible d’adjoindre d’autres entités pour valider du code. Cela permet de recréer l’équivalent de l’ajout de plusieurs dépôts logiciels différents. Il est même envisageable pour une entité de désactiver bachue spécifiquement du groupe.

L’entité locale de l’instance va aussi avoir des droits plus étendus. Elle pourra être, via des options, équivalente à toutes les autorités globales, y compris le maître du tout (puppetmaster). Bien sûr ces droits ne seront valables que sur l’instance de serveur qui lui est rattachée… et toute entité qui décidera de l’ajouter dans un groupe de droits.

Définition des groupes

Dimanche, mai 20th, 2018

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

(suite…)

Réputation d’entité et chaînage

Mardi, mai 15th, 2018

Le système de chaîne de blocs tel que abordé dans les articles Blockchain et nebule et Le cas de la messagerie ne peut être implémenté dans nebule.

Cependant la réflexion sur un mécanisme proche en terme de fonctionnalité ouvre tout un champs de possibles. Cela permet notamment d’introduire de la confiance là où à priori il n’y en a pas.

Il est ainsi envisageable de gérer la réputation des entités non pas dans des blocs mais par de multiples signatures de liens de réputations (positifs ou négatifs) par diverses entités. C’est le même mécanisme que la pondération. Le problème dans ce cas est la non prise en compte de liens d’entités que l’on ne connaît pas. L’annuaire est peut-être un facilitateur à ce niveau pour le cas d’entités inconnues.
Une nouvelle entité devrait commencer par se déclarer auprès d’un annuaire. Depuis l’annuaire cette nouvelle entité aurait accès aux autres entités, mais pas immédiatement puisque n’étant connue d’aucune entité, tout dialogue serait impossible. Le mécanisme dans l’annuaire peut prévoir une sorte de mise en relation entre entités qui ne se connaissent pas. Les premières entités rencontrées pourraient être des modérateurs. Ensuite, en fonction de la réputation acquise auprès des premières entités il serait possible pour la nouvelle entité de commencer à solliciter, toujours via l’annuaire, de nouvelles entités plus ‘timides’. Un mauvais comportement de la nouvelle entité dès le début entraînera rapidement un bannissement.
Pour éviter les bannissement abusifs par coalition, parce qu’il faut considérer qu’on ne peut pas plaire à tout le monde, il faut comprendre que le bannissement ne sera effectif que pour les entités ayant émis une réputation négative et toutes autres entité qui leurs font confiance. Mais la nouvelle entité sera toujours reconnue par les entités ayant émis une réputation favorable.

Nous devons dès maintenant considérer que, à moyen terme, l’intelligence artificielle sera à même de tromper, mieux que les humains, les barrières de filtrage anti-robots. Les techniques actuelles fonctionnent encore mais leurs méthodes sont déjà vouées à l’échec. Et puis l’important n’est pas de filtrer des robot qui peuvent être légitimes, mais plutôt d’isoler les sources d’actes malveillants. Et là nous ne sommes plus dans la détection du qui suis-je mais dans la détection comportementale. On peut imaginer aussi que des entités (humains ou robots) se comportent correctement un certain temps afin de monter en estime et traverser des barrières comportementales mais dans le but de s’attaquer à une cible de haute valeur, dans ce cas le prix en temps de création est élevé.

Lien et prise en compte à seuil social

Vendredi, avril 20th, 2018

Dans le traitement des liens et leur prise en compte, la notion de coefficient social permet de donner un ordre de prise en compte de ces liens.

L’exemple typique est le lien de mise à jour. Lorsque l’on a plusieurs liens de mise à jour d’un objet vers différents objets, on va ordonner les liens non chronologiquement mais par importance. L’importance ici est calculé sur l’importance sociale donnée aux entités qui ont générées les liens.

Il est possible dans certains modèles de calcul de l’importance sociale des liens de tenir compte du type de lien, voir de certains champs comme le champs méta.

Cependant, le tri par socialité des signataires des liens ne marche que si il y a plusieurs liens différents disponibles. Si il y a un seul lien de mise à jour d’un objet, et que le signataire, est jugé socialement peu fiable, peut-être faut-il ne pas prendre en compte ce lien. Cela revient à mettre en place un seuil social de prise en compte des liens. Mais à partir de quel seuil se fait la prise en compte d’un lien ? Faut-il plusieurs seuils en fonction du type de lien ?

Référencement par défaut

Dimanche, mars 25th, 2018

Suite des articles Références d’images, Propriété d’un objet et référence par rapport à un objet et Objet de référence contre suivi du graphe des mises à jours.

La recherche par référence se fait par rapport à un contexte. Ce contexte est définit par le champ méta des liens.

Pour les images, le contexte est définit par un objet contenant ‘nebule/objet/image/reference‘, soit l’ID 1ca96e517fc6ccca45080244c594dd777dc5d3bde0f872f961c28a4e9749ba82.

Pour la bibliothèque nebule en php, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/bibliotheque‘, soit l’ID 4297b53cfab1fc41f7820a47d1c21fbf7d0ab83a5ee4f94331c1e0ba1cbb99cf.

Pour les applications, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/applications‘, soit l’ID e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b.

Etc…

Mais il n’y a pas que des usages dans des contextes techniques qui sont à prendre en compte. On peut permettre à l’utilisateur de gérer ses références. Pour cet usage un objet de référencement ‘nebule/reference‘ est dédié, soit l’objet 7339ea8fd26c67c3857ca94f9bac47d3841a3b75e799609720b8cc739732a161. La version publique actuelle de sylabe ne le reconnaît pas encore mais c’est le cas dans la version en cours de développement.

La reconnaissance des liens pour les références ne va pas être faite tout à fait de la même façon en fonction de l’usage. On doit être plus restrictif sur les références concernant les applications que pour celles de l’utilisateur. On va se base sur un calcul social de tri différent.

Et pour faciliter la gestion des références par l’utilisateur, un module dédié est en cours de développement. Il est dédié aux utilisateur donc il se base par défaut sur l’objet de référencement dédié aux utilisateurs mais peut très bien se baser sur d’autres objets de référencement.

Enfin, un lien de référence pourra être dissimulé.

Entité multi-rôles – compromission et divergence

Samedi, mars 10th, 2018

Suite des articles Entité multi-rôles et suite, Nommage d’entité – préfix, Entités multiples, Changement d’identifiant d’entité et Entités multiples, gestion, relations et anonymat.

La segmentation d’une entité en plusieurs entités avec des rôles différents va nécessiter un peu de travail. La notification du rôle dans le préfixe de nommage des entités ne semble pas opportune.

Lors du changement de mot de passe d’une entité, la clé publique ne changeant pas, l’entité reste référencée par le même identifiant, c’est à dire l’empreinte de l’objet de la clé publique. Par contre l’objet de la clé privée va changer, il faut donc un lien pour retrouver cette nouvelle clé privée. Ce n’est pas encore implémenté mais ici rien de compliqué.
Ça va se compliquer avec le problème de diffusion de l’objet de la nouvelle clé privée afin que l’utilisateur puisse l’utilisé pour s’authentifier sur une autre instance serveur. Là on a l’utilité de permettre facilement la synchronisation d’une entité en préalable à une authentification.

Il y a cependant un problème majeure de sécurité des entités. en effet les anciennes clés privées restent toujours présentes et permettent toujours de déverrouille l’entité. Il ne suffit pas de faire une suppression de l’objet concerné, cela n’a que peu de chance de fonctionner face à un attaquant.
Il est possible de générer une nouvelle entité avec sa propre clé publique, ou de tout le cortège d’entités dans le cas du multi-entités. On peut même imaginer ne changer que l’entité d’authentification. Puis on fait des liens pour dire à tout le monde que l’entité a été mise à jour et marquer le lien de parenté. Cela veut malheureusement dire qu’il faut refaire tous les liens avec la nouvelle entité. Peut-être est-ce l’occasion de faire du ménage et oublier des choses…

Quelque soit le mécanisme, il ne protège pas de la compromission d’une entité par un attaquant. Celui-ci peut réaliser une mise à jours de l’entité qui sera vu comme légitime par les autres entités. La récupération de l’entité est possible puisqu’elle existe toujours mais comment vont se comporter les autres entités lorsque l’on va faire une deuxième mise à jours d’entité… en concurrence avec la première. Il y a peut-être un moyen de faire jouer le côté social des relations entre entités et de volontairement créer un challenge entre les deux mises à jours de l’entité et toutes les entités tierces.
Ou alors on accepte la survivance simultané de ces deux entités qui vont progressivement diverger avec le temps. Là aussi un tri social pourra se faire mais plus naturellement.

La solution à ce problème peut être l’usage d’une entité faisant autorité et capable d’imposer une mise à jour d’entité en particulier. Mais on essaie de se débarrasser des autorités encombrantes ce n’est pas pour les réintroduire au premier coup de froid.
Il existe une autre forme d’autorité, ce peut être une entité à soi mais que l’on n’utilise pas au jours le jour et stockée à la maison au chaud. Les cambriolages étant encore un risque contemporain cette entité de recouvrement peut être dupliquée en d’autres lieux. Évidement son vol ne doit pas permettre de prendre le contrôle de l’ensemble.

Il restera toujours le vol sous contrainte. Mais ça on ne peut rien y faire de toute façon.

L’hégémonie d’un mécanisme unique de gestion des identités est un problème puisque une fois ce mécanisme corrompu il n’existe plus de recours pour récupérer son identité.

Ce problème n’a pas vraiment de solution complète et pas encore d’orientation précise pour gérer les conflits. Il reste encore du travail de réflexion…

Pondération et structure hiérarchique

Mercredi, août 30th, 2017

Suite de la gestion de la pondération.

Dans une structure ou une organisation hiérarchique, forme courante d’organisation, une autorité peut être amenée à déléguer son pouvoir à un autre individu. C’est le cas notamment lors d’une vacance.

Rapporté à une entité dans nebule, une entité a qui on donne une forte pondération, à qui on fait confiance, sera toujours prioritaire sur une autre de moins forte pondération. Comment permettre une vacance ? Est-ce que l’on peut mettre en place une forme de délégation de pondération ? Est-ce que ce lien de délégation est simplement annulé en fin de vacation ?

Cela pose aussi question sur la forme de la pondération. Elle est normalement globale. Mais ne faut-il pas gérer une pondération par rôle en plus ? Doit-il être géré comme une pondération avec un contexte social ?

Échange ou téléchargement d’objet et lien de mise à jour

Mardi, juin 6th, 2017

Dans l’article Échange ou téléchargement d’objet, on a vu qu’il y avait deux façons de récupérer le contenu d’un objet. Il y a une deuxième différence qui peut apparaître dans certains cas, c’est la transmission du contenu d’origine ou de celui d’un autre objet si il a été créé un lien de mise à jour de l’objet demandé.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. Les liens de mise à jour ne sont pas utilisés parce que l’empreinte de l’objet est vérifié après téléchargement et que si le serveur envoie un autre objet, fut-il une mise à jour, l’objet sera rejeté.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. Mais dans ce cas les liens de mise à jour sont exploités et le contenu renvoyé par le serveur peut ne pas avoir l’empreinte de l’objet demandé.

La prise en compte des liens de mise à jour est toujours délicate parce que cela peut permettre de substituer un objet par un autre. Cette manœuvre est complètement visible dans les liens et nécessite un bon échantillonnage des liens par rapport à leurs poids sociaux.

Modification de l’ordre de prise en compte des propriétés d’un objet

Jeudi, mars 30th, 2017

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. (suite…)

Suppression et oubli

Mardi, décembre 13th, 2016

Comme évoqué il y a déjà un certain temps dans l’article sur Le paradoxe du droit à l’oubli, il n’est pas évident du tout que la suppression pure et simple d’une information soit généralement la meilleur solution.

Pour les individus, l’oubli d’une information est vu soit comme un trouble cognitif soit comme une nécessité. C’est un problème si l’information que l’on avait acquise n’est plus disponible alors que l’on en a grand besoin. Les personnes qui perdent la mémoire perdent toute autonomie. D’un autre côté, se souvenir de tout est aussi un problème. La trop grande quantité d’information sur des évènements sans intérêt perturbe la vie courante.

Dans nebule, la suppression des objets répond à deux besoins. Le premier besoin correspond à la récupération de la place mémoire pour stocker d’autres objets plus récents et à priori plus importants. Et le deuxième permet surtout dans la vie courante de ne pas se surcharger d’informations qui n’ont pas d’intérêt immédiat… voir plus d’intérêt du tout.

Mais cette suppression qui est une manière courante de travailler en informatique n’est elle pas problématique ?
L’oubli est la vraie raison de la suppression des objets. Un autre mécanisme doit être trouvé pour remplacer la nécessité de supprimer des objets. Le retrait des liens attachés à un objet ne supprime pas ces liens mais les enlève de l’usage courant. La pondération des émotions d’un objet et le traitement qu’il en est fait permet de gérer aussi le bannissement dans un contexte social des entités.

Le sujet devra être approfondi avant tout mise en applications…

Intégration des groupes dans la librairie php

Lundi, février 1st, 2016

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Entités multiples

Mardi, décembre 23rd, 2014

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é.

Nébuleuse sociétale et confiance – Chiffrement par défaut

Mercredi, juillet 16th, 2014

La relation entre les êtres humains est resté assez stable dans son contenu mais à beaucoup évolué dans sa forme avec la technique. Le la taille d’un village, d’une tribu, la dimension du réseau social d’un individu a fortement grandi et a cessé de coller à sa zone géographique proche. Mais il n’a pas forcément grossi pour autant, il ne s’est que dilaté. Il garde d’ailleurs une forme nébuleuse dense au centre et distendu en périphérie.
Le téléphone a accéléré la vitesse de transmission des informations et de fait a permis d’étendre encore plus la portée des échanges, et donc l’influence des individus. Cette extension a fini par atteindre sa taille limite, celle du monde.
Mais les échanges d’informations ne se limitent pas à l’influence, politique, des autres. On y retrouve des choses qui n’ont pas grand intérêt à première vue comme la correspondance familiale ou la propagation de la culture. Cependant, ces deux exemple ont une importance profonde dans l’identité de l’individu d’une part et de la société d’autre part.
Le réseau social individuel n’est plus depuis longtemps calqué sur son influence physique directe. Si il n’est pas évident de parler de réseau social d’un groupe d’individus, ou société, on peut quand même se raccrocher à son influence directe. Et l’influence des sociétés ne sont que rarement exactement calquées sur leurs influences physique directe, c’est à dire sur les frontières d’un pays.
Une société ne doit pas être vue comme une forme nébuleuse unique de relations sociales mais comme une forme nébuleuse sociétale composée d’une multitudes de formes nébuleuses entremêlées. Une société est composée d’une multitude de formes nébuleuses individuelles avec quelques structures communes, mais surtout, pour les individus, avec une majorité de liens au sein de la nébuleuse sociétale. Le nationalisme ou communautarisme, du point de vue du réseau social, sont des tentatives pour imposer des structures uniques fortes et donc de forcer la nébuleuse sociétale à se scinder en de multiples formes sous-sociétales. Il existe une multitude de formes sous-sociétales susceptibles de développer une forme de communautarisme puisqu’il est en pratique impossible d’avoir une nébuleuse individuelle approchant la forme nébuleuse sociétale dans son ensemble. Le nationalisme use de sa forme de nébuleuse sociétale pour revendiquer une influence physique y compris hors des frontières de l’état qui le définit à l’origine.
Le réseau Internet est un support d’information, il permet de diffuser la connaissance à tout un chacun. Mais ce n’est pas sont seul rôle, il permet aussi de relier les individus. C’est à dire qu’il sert de support universel à la forme nébuleuse des relations sociales d’un individu. Nous avons encore des échanges sociaux directs entre individus, instantanés, mais ils ne sont plus ni exclusifs ni même nécessaires ou systématiques.
Le projet nebule se doit donc de faciliter le partage de l’information, de la connaissance, mais il se doit aussi de faciliter les échanges sociaux entre individus. Le projet nebule doit être capable de coller au plus prêt de la nébuleuse de l’information d’un individu, mais aussi de la nébuleuse de son réseau social.

La messagerie telle qu’elle a commencée était un message manuscrit sur un support papier ou équivalent et pouvait mettre plusieurs mois pour arriver à destination… quand ça arrivait…
Aujourd’hui, un message traverse le monde en quelques secondes avec une très grande probabilité d’arriver à destination. Le plus long, c’est maintenant d’attendre que le destinataire ouvre son message. Tout le monde fait confiance à la messagerie électronique et à une bonne confiance dans les échanges postaux nationaux et internationaux.

Et puis il y eu Edward SNOWDEN.

La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.
Là, subitement, on a une grosse crise de confiance. On se dit qu’on ne va peut-être pas laisser tous ses œufs dans le même panier. Le projet nebule peut sous cet éclairage paraître un peu trop intrusif et exclusif (des autres).

Cette crainte vis-à-vis du projet nebule est à la fois recevable, et non recevable.
Le projet sylabe, annexe de nebule, est une implémentation suivant les paradigmes actuels en terme d’échange de l’information, et surtout en terme de concentration de l’information. Il est conçu volontairement dès le début pour centraliser les données sur un serveur de l’Internet. C’est cette concentration sur une machine que l’on ne maîtrise pas qui pose de gros problèmes aujourd’hui. C’est cette concentration sur des machines chez des grosses sociétés au USA qui permet à la NSA (entre autres) de violer l’intimité numérique des individus sans raison valable. Et c’est fait de telle façon que les individus gardent confiance dans cette concentration de leurs données.

Mr SNOWDEN a cassé la confiance que nous avions dans la concentration de nos données, la confiance pour ces grosses sociétés américaines, et la confiance dans l’Internet même. Il a montré que quelque chose ne fonctionnait pas bien. Mais il l’a fait pour que ça s’améliore, pour que nous fassions les efforts nécessaires pour reconstruire l’Internet et la confiance que l’on attend de lui.

Le projet sylabe est donc un reliquat de ce passé. Mais il apporte quand même quelque chose pour le futur. Il centralise les données mais contient les graines de leur décentralisation complète.
Si tout le monde n’est pas prêt aujourd’hui à installer un serveur pour héberger ses données, on y arrive quand même de façon détournée. Certains installent des boîtiers NAS, c’est déjà une forme de réappropriation de ses données. Toutes les maisons ont une box qui fait office de centre multimédia, de NAS. La domotique arrive tout doucement (depuis 20 ans). Ainsi, une instance sylabe pourra être un jour implémentée facilement dans un boîtier pour non seulement héberger nos donnés mais aussi pour nous permettre d’échanger avec nos amis.
Le projet sylabe, une fois implanté ailleurs que sur des serveurs centralisés permettra la mise en place complète de la vision de la nébuleuse de nos informations, complètement décentralisée mais centrée sur nous.

Il reste à traiter le problème de l’anonymat. C’est en cours de définition et d’implémentation.
Cet objectif à part entière, dans le contexte actuel, nécessite qu’une entité puisse nativement et par défaut chiffrer tous ses objets et offusquer tous ses liens, ou presque tous. Cette possibilité sera intégrée rapidement dans le projet sylabe.

Google+ et l’anonymat

Mercredi, juillet 16th, 2014

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

Jeudi, juin 19th, 2014

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.

Liens d’émotions

Vendredi, avril 4th, 2014

La mise en place des émotions sur les objets appelle plusieurs questions.

Catégories

Vu le nombre d’émotions gérées, il va devenir nécessaire de les segmenter en catégories. On peut maintenir la catégorie ‘émotions‘ qui regroupe tout ressentit humain, plutôt subjectif. On peut ajouter une nouvelle catégorie ‘avis‘ pour tout ce qui est plus objectif.

Pondération

Une réflexion qui commence à dater un peu sera la mise en place d’une pondération aux objets. Cette réflexion concerne avant tout la possibilité d’oublier progressivement dans le temps les objets avec le moins d’importance. L’oublie peut être réalisé automatiquement à partir d’un certain seuil. Le seuil peut progressivement augmenter dans le temps jusqu’à un seuil maximum au dessus duquel les objets concernés seront conservés, sauf suppression volontaire.

Cette pondération peut être bien sûr utilisable en permanence pour trier l’affichage des objets.

La mise en place des émotions est le bon moment pour introduire la mise en place de la pondération. Il ne reste plus qu’à en définir les modalités.

Chiffrement

Une autre réflexion qui date un peu mais prend progressivement de l’importance, c’est la possibilité de chiffrer les liens. Le but est d’offusquer que l’on ne souhaite pas rendre publics tout en permettant leur bonne transmission aux destinataires légitimes.
Il y a plusieurs manières d’offusquer les liens :

  1. La première est de créer un objet de liens, objets que l’on chiffre ensuite vers son destinataire. Cette méthode, si elle est assez bonne en terme de performance de déchiffrement, nécessite cependant que tous les liens offusqués soient consultés en même temps que tout les liens normaux d’un quelconque objet, pour savoir si un lien secret ne le concerne pas spécifiquement. On obtient de fait un ou plusieurs objets de liens chiffrés attachés à son entité. L’inconvénient, c’est qu’il est impossible de transmettre un lien particulier à une autre entité sans devoir recréer un nouvel objet de liens chiffré.
  2. La seconde méthode est de faire du chiffrement de lien à la volée. C’est à dire qu’un lien a offusquer est chiffré et reste présent individuellement au milieu des autres liens. Cependant, ce lien va contenir un partie chiffrée, partie qui ne correspond donc pas à un objet réel, ce qui est en contradiction avec la forme actuelle des liens. L’avantage, les liens chiffrés voyagent naturellement avec les autres liens. L’inconvénient, le lien chiffré ne peut être rattaché qu’à un seul objet et à une entité. Le lien avant chiffrement fait référence à trois objets, on perd donc avec le lien chiffré la référence aux deux autres objets. Cela veut dire que le lien chiffré est valable si on consulte l’objet source, mais n’est plus reconnu si on consulte l’objet destination. Cet inconvénient risque de perturber la résolution inverse d’un arbre de mise à jour par exemple.
  3. La troisième méthode est d’exporter la partie chiffrée dans un objet en tant que tel. Cette méthode a l’avantage de profiter du mécanisme de chiffrement déjà implémenté pour les objets. Liens et objets sont transmis naturellement vers un destinataire du lien. Et on retrouve l’inconvénient de la deuxième méthode. En plus, on complexifie l’analyse des liens d’un objet puisqu’il faut aller consulter d’autres objets pendant le processus de lecture des liens, et donc d’autres liens…

La mise en place du chiffrement des liens va créer de fait une nouvelle version de nebule, la v1.2.