Référencement par défaut

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

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…

Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

Blockchain et nebule – Le cas de la messagerie

Suite de l’article Blockchain et nebule.

La blockchain ne permet pas juste de manipuler de l’argent. Une forme de blockchain avec une portée réduite peut se retrouver dans la messagerie. Lorsqu’un message est transmis à des destinataires, ceux-ci vont marquer le message comme lu lorsqu’ils vont l’ouvrir les uns après les autres. On considère ici cette marque de lecture comme publique. Si un message est référencé par une empreinte et que les marques de lectures référencent cette empreinte, alors nous avons une chaîne de blocs indirecte. Un message ne référence pas le message précédent comme cela se fait avec un bloc, mais chaque message est vu et validé collectivement dans une période de temps (idéalement) réduite. Cette validation par les destinataires scelle les messages dans le temps et la chaîne est constituée par l’enchaînement des messages dans le temps, dans une conversation. Il est possible grâce à ce mécanisme de détecter les tentatives de suppression ou d’insertion de messages.

Cette façon de marquer les messages et de les figer dans le temps est une base de travail possible pour l’implémentation de l’équivalent d’une blockchain via les mécanismes de nebule et surtout avec ses restrictions. Ce mécanisme peut permettre un fonctionnement local là où la blockchain nécessite impérativement un consensus global et une cohérence mondiale.

L’utilisation de l’entité maître du temps kronos ne permet de résoudre qu’une partie du problème.

Revers Polish Notation

Le mécanisme décrit dans l’article Copier/coller et marquage pourrait être avantageusement réutilisé par un module d’application afin de mettre en place une pile. Cette pile pourrait ensuite être manipulée via un langage de type Revers Polish Notation (RPN ou RPL). En plus des opérations de base de manipulation de la pile, d’autres opérations pourraient être ajoutées par l’application ou par chaque modules présents. Par exemple le module de gestion des liens pourrait ajouter des opérations sur les liens dont la copie d’un lien (pile niveau 1) en remplaçant le hash source du lien par un nouvel objet (pile niveau 2). Etc…

Copier/coller et marquage

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.