Archive for the ‘Réflexions’ Category

Relais d’authentification sans partage de secret

Lundi, mars 4th, 2019

Dans l’article sur les relais d’authentification, on a vu qu’il était possible très simplement de déverrouiller une entité sur un serveur distant en rejouant l’authentification. Mais cela implique de transmettre le mot de passe de cette entité. Et cela veut dire aussi que la clé privée est déverrouillée sur le serveur distant.

Il est théoriquement possible de réaliser un mécanisme d’authentification sans partage de secret. Dans ce cas une instance déverrouillée sur un serveur distant ne disposerait ni du mot de passe ni de la clé privée de l’entité. Il faut donc implémenter un mécanisme qui permette au serveur distant de venir interroger le serveur local avec la session de l’entité en cours. Le mot de passe de l’entité étant stocké dans le cache de la session PHP, il serait impossible au serveur distant de l’obtenir. Mais il peut dans ce cas accéder aux objets protégés et notamment aux secrets de chiffrement des objets. Pour les liens dissimulés c’est par contre plus complexe.

Avec un tel relai il est possible de se connecter sur un serveur distant sans divulguer son mot de passe tout en disposant de l’accès aux objets protégés et à la possibilité de signer des liens.

Un serveur distant compromis pourrait le temps de la session accéder aux objets protégés. Mais une fois la session fermée, dans la fenêtre du navigateur sur le serveur local, aucun autre objet protégé ne pourrait plus être ouvert. Au minimum, tous les nouveaux objets protégés ne seraient pas accessibles. Pour les plus anciens… ça dépend du temps d’ouverture de la session…

Relais d’authentification

Lundi, mars 4th, 2019

Il est théoriquement possible depuis une instance d’une entité déverrouillée sur un serveur, local, de demander à ouvrir une nouvelle instance sur un autre serveur, distant. Cette authentification peut simplement être faite en rejouant le mot de passe de l’entité du serveur local. Il faut que le serveur distant connaisse l’entité et dispose de l’objet de la clé privée accessible avec le mot de passe. La nouvelle instance serait alors ouverte dans un nouvel onglet du navigateur.

Cela implique la transmission du mot de passe. Il faut impérativement passer par une connexion chiffrée (TLS) avec authentification (certificat) du serveur distant afin de protéger le transit du mot de passe.

Cela implique aussi que le serveur distant va connaître le mot de passe de l’entité, au moins le temps de la session. Il faut donc avoir autant confiance dans le serveur distant qu’en le serveur local.

Il est cependant possible aussi de transmettre le mot de passe d’une sous-entité vers le serveur distant. Ainsi on peut penser centraliser sur un serveur/périphérique local une entité maîtresse et ses sous-entité, et utiliser certaines sous-entités exclusivement sur des serveurs distants, y compris des serveurs de faible confiance.

Cela veut dire que l’on doit pouvoir associer une localisation avec une entité.

En fait, cela est très simple à réaliser. Il suffit de générer un lien HTTP vers le serveur distant avec en argument l’application, l’entité et le mot de passe… le tout dans un nouvel onglet.

Et en ajoutant dans le lien HTTP un mode et une vue il est même possible de chaîner l’authentification vers un troisième serveur. On a dans ce cas un niveau de relai d’authentification et un peu de dissimulation.

Ceci n’est pas implémenté. Suite au prochain épisode…

Éviter un projet de blockchain mort-né

Vendredi, mars 1st, 2019

L’article du blog de MultiChain.com intitulé « Avoiding the pointless blockchain project » fait le tour des points à respecter pour justifier la mise en place d’une blockchain dans un projet.

Il se trouve que les différents points sont concordants avec le projet nebule qui lui n’est pas une chaîne de blocs.

La lecture est intéressante. La blockchain peut être aussi privée, et donc pouvoir être localisée et non nécessiter d’être unique et synchronisée au niveau mondial. Mais dans ce cas se pose la question de la quantité suffisante de nœuds pour calculer et valider les blocs. Et si on revient vers des nœuds privés pour une blockchain privée, alors on perd l’intérêt d’une chaîne de blocs de transactions… et on revient sur un système avec un tiers de confiance.

Liens des options

Mardi, février 26th, 2019

Le lien permettant de définir une option, si elle est autorisée à être modifiée, est constitué d’un type l, du nom de l’option, de sa valeur et d’un objet méta de référence nebule/option.

Cette forme de lien est bonne pour un usage locale et personnel des options. Mais il se prête mal à la gestion des options d’entités sous contrôle. Par exemple si on a un serveur de diffusion de contenu, on peut être amené à changer son comportement. Cette forme de lien impose dans ce cas de générer un lien avec l’entité instance du serveur… et donc de connaître obligatoirement son mot de passe.

Peut-être serait-il judicieux de changer maintenant la forme du lien pour inclure une entité. L’objet méta n’a pas grande utilité ici comme référence fixe. La référence pourrait devenir le nom de l’option… et les noms des options deviendraient des objets réservés.

Suite au prochain épisode…

Options de désactivation de protection et de dissimulation

Mardi, février 19th, 2019

La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.

Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :

  • permitProtectedObject : Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de type k.
  • permitObfuscatedLink : Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de type c.

Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.

Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.

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…

Contenu de lien dissimulé

Jeudi, janvier 17th, 2019

Le lien dissimulé contient, tel que défini par l’article Anonymisation/dissimulation des liens, un lien complet signé. La vérification d’un lien chiffré nécessite de vérifier la signature du lien chiffré et du lien déchiffré.

Il est peut-être plus intéressant de ne mettre dans la partie dissimulée que le contenu du lien sans la partie signature, et donc sans la partie signataire. Ainsi, un lien dissimulé ne pourait pas être réutilisé hors du lien dissimulé puisque seul le lien dissimulé et signé.

Si on le rapport par exemple à un système d’élection (cf Sondages et votes), le lien d’attribution d’un ticket n’est ainsi plus partageable pour prouver un vote. Dans ce cas cela pourrait aussi être couplé à la méthode…. ah zut… l’article sur la méthode de PFS sans connexion n’a pas encore été écrit :'(

La suite au prochain épisode…

Réorganisation des entités spéciales – gestion

Jeudi, janvier 17th, 2019

Suite des articles Réorganisation des entités spéciales – inventaire de départ. et groupes d’entités.

L’application option permet aujourd’hui d’afficher les autorités globales et locales. Cette interface avec l’instance nebule du serveur doit être le seul point de gestion de ces entités et de leurs rôles. Cette application va donc devoir évoluer pour prendre en compte les évolutions des entités spéciales, et pas seulement les afficher.

Bonne année 2019

Dimanche, janvier 13th, 2019

Une nouvelle année signifie la mise à jour de toutes les dates à côté des licences… que ce soit dans les différents code mais aussi des sites web statiques et des blogs.

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Par rapport à début 2018, la réorganisation de la partie graphique est bien avancée. De nouvelles réflexions se font sur une possible implémentation de crypto-monaie basée sur nebule, et donc sur la réliance que l’on peut en espérer. Les réflexions continent aussi sur la réorganisation des rôles provilégiés par groupes.

La documentation technique de nebule migre maintenant vers une pseudo-application dédiée gérée par le bootstrap. Mais la documentation est en fait contenu, et mise à jour, par la bibliothèque.

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.

Blockchain, billets et valeur

Jeudi, octobre 25th, 2018

Dans la réflexion sur l’implémentation d’un équivalent de blockchain dans nebule, il apparaît un problème qui n’est pas vraiment technique.

La blockchain permet de transmettre des billets électroniques sous la forme de transactions dans des blocs. Avec nebule, on peut utiliser les liens comme transactions et des objets prenants le rôle de billet électroniques, ou utiliser des objets de transactions pour des objets portants de la valeur. Dans les deux cas on peut le faire avec un mécanisme assurant de la confiance dans les transactions.

Chaque billet est porteur d’une valeur. Cette valeur n’est pas fixe, c’est juste une convention, et elle va dépendre de plusieurs paramètres. Le volume de billets pouvant évoluer avec le temps, à la hausse, la valeur de chaque billet va naturellement baisser juste du fait de l’augmentation des billets pour une valeur globale constante. Cette valeur monétaire peut évoluer aussi dans le temps avec les transactions d’achat ou de revente des billets eux-même, indépendamment de la valeur d’origine qu’ils représentaient.

Or si cette valeur monétaire peut évoluer dans le temps, elle doit malgré tout être initialisée à un moment. On passe par exemple d’un objet physique ayant une valeur d’usage à une monnaie qui transporte cette valeur initiale. Il y a une sorte d’échange de valeur entre un objet physique et un objet virtuel. Mais comment vas-t-on faire pour générer des billets décentralisés de façon à permettre l’échange de valeur ? Les billets doivent-ils pré-exister ?

Création d’objet et dissimulation des liens

Dimanche, septembre 23rd, 2018

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Non vérification crypto et lecture seule – Centre de données et répartition

Samedi, septembre 15th, 2018

Suite de l’article sur la Non vérification crypto et lecture seule.

Le problème des très gros objets peut être résolu avec un fonctionnement segmenté de l’application. D’un côté on a l’application principale qui structure et délivre des informations aux utilisateurs, par exemple la page de diffusion des vidéos. Et de l’autre un serveur uniquement dédié au stockage des objets volumineux.

L’application principale peut fonctionner classiquement sur une ou plusieurs instances et faire référence à du contenu, y compris volumineux, hébergé sur un autre serveur. Le contenu est constitué d’objets parfaitement référencés par leurs empreintes et dont l’usage est définit par des liens. On ne fait là qu’exporter le problème des gros objets.

Un serveur uniquement dédié au stockage des objets volumineux va devoir résoudre le problème de la vérification des objets volumineux sans avoir à se poser de question sur leurs pertinences. La pertinence des données, ce sont les applications qui la gère avec les liens. Ce serveur devient ainsi un centre de distribution de données (CDN) dont la stratégie de vérification peut être adaptée. Et là, l’usage des instances sur ces serveurs étant très restreint en fonctionnalité, il est possible d’alléger la vérification des objets. La vérification peut ne plus être systématique avant un téléchargement par un client mais peut être préprogrammée périodiquement lors de faibles sollicitations. Cela veut dire qu’il faut faire confiance à un serveur qui, peut-être, n’est pas entièrement sous contrôle. Il reste possible bien sûr de vérifier la validité des objets après téléchargement.

Reste un petit engrenage à ajouter là dedans. Il faut que la ou les applications, dans des instances différentes, soient capable non seulement de manipuler la référence d’un objet volumineux sans l’avoir effectivement à portée, mais soient aussi capable de faire pointer l’utilisateur sur le bon point de stockage de l’objet volumineux. C’est à dire qu’elles soient capable de désigner le bon centre de données au bon moment.
Pour cela, soit chaque application dispose d’une configuration définissant quel (unique) centre de données utiliser pour les objets dont la taille (défini par un lien de propriété) est supérieure à une limite de vérification. Soit l’application crée un lien (de propriété) définissant pour chaque objet volumineux sur quel centre de données il est disponible. La première solution est la plus simple, la seconde est la plus souple, et les deux peuvent cohabiter.

L’air de rien, le lien définissant sur quel centre de données est disponible un objet volumineux, la deuxième solution, existe déjà. Pour une entité il est possible de définir un lien avec pour objet méta ‘nebule/objet/entite/localisation‘ afin de donner des points de présences d’une entité. Cet objet méta réservé, non utilisé aujourd’hui, pourrait être abandonné et directement remplacé par l’objet méta ‘nebule/objet/localisation‘ plus générique. Ça tombe bien, ce dernier existe déjà… ne reste maintenant qu’à l’implémenter dans le code…

Non vérification crypto et lecture seule

Dimanche, août 12th, 2018

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.

Blockchain et nouveau lien

Samedi, août 11th, 2018

Suite des articles sur la Blockchain et nebule, Le cas de la messagerie et la Réputation d’entité et chaînage.

Le problème de n’avoir que des liens annulables dans nebule, rapporté à une émulation du fonctionnement d’un équivalent de la blockchain, c’est que l’entité initiatrice d’une transaction peut invalider la transaction ou au contraire elle peut se voir contraindre la transaction par un groupe coalisé.

Une solution serait de créer un nouveau type de lien spécifiquement non annulable, c’est à dire non soumis à l’action du lien de type x. Mais ce cas particulier va ralentir le traitement de la lecture et de la vérification des liens là où elle doit être la plus optimale. Mais bon la force de l’usage fait peut-être loi.

Une autre solution pourrait être de se baser sur un objet de transaction. Dans ce cas nous n’avons plus un objet servant de jeton de valeur avec la résolution des liens pour suivre ses évolutions mais un objet de transaction faisant en interne référence à un autre objet jeton de valeur. Dans ce cas, la suppression d’un objet répliqué étant beaucoup plus illusoire, si d’autres entités signent cet objet comme une transaction il est possible de la retrouver même si l’initiateur de la transaction le supprime. Cette méthode pose cependant un problème, quel lien doit être utilisé afin de propager l’objet de la transaction, et donc la transaction elle même, tout en permettant la création de confiance ?

Le message et le messager

Samedi, juin 30th, 2018

Dans sylabe, il y a une implémentation de la messagerie.

Mais la messagerie tel que l’on a l’habitude de l’utiliser est un peu réductrice dans sa forme. L’article d’un blog comme le commentaire sur un réseau social sont aussi des formes de messages. Dans nebule, il est fort probable que ce soit la même information mais avec une présentation différente.

Dans un système de gestion de l’information dans lequel chaque information est intégrée dans un fichier avec ses usages, c’est à dire ses méta-données, une information transmise pour un nouvel usage devient un nouveau fichier. C’est le cas par exemple de la messagerie dans lequel un message retransmit à une nouvelle adresse devient un nouveau message alors qu’il contient la même information à la base. La différence, c’est que les destinataires du premier message ne sont pas forcément au courant du nouveau message et donc du partage de l’information. Ce non partage de certaines informations de diffusions (méta-données) est géré dans nebule par la mise en place de l’offuscation des liens.

La transmission d’un message c’est simplement la transmission d’une information. Ce qui permet au destinataire de savoir qu’une information lui est destiné c’est le fait de l’inclure dans un lien entre cette information et un objet dédié qu’il scrute. L’objet dédié est de fait un groupe d’objets lui étant destinés, ce qui s’apparente à un salon de discussion d’une messagerie. Ce salon de discussion est désigné par le terme de conversation contenant des messages.

Le mécanisme des conversations mis en place étant un retour à la sources des informations et de leurs usages, cela offre beaucoup de possibilités et de nouvelles perspectives. Une conversation peut être fermée et publique, elle est ainsi visible de tout le monde mais seules certaines personnes vont pouvoir légitimement et publiquement dialoguer dans cette conversation. Toute entité qui ne fait pas partie de la conversation fermée peut émettre des messages dans cette conversation mais ceux-ci ne seront pas vus pas les autres entités à part peut-être ses amis. Un groupe d’amis peut donc commenter en directe une conversation fermée sans perturber le déroulement de celle-ci pour les autres écouteurs de la conversation. Le statut d’une conversation peut être changé par un participant, cela n’impacte pas les autres participants, ce dernier peut ainsi décider de passer la conversation en ouverte et voir maintenant la contribution de tout le monde et non plus seulement les participants… sans plus gêner pour autant les participants.

Un nouveau problème arrive, comment présenter dans une interface ces fonctionnements à l’utilisateur, et de façon intuitive ?…

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