Catégorie : lien x

Sch̩ma lien dissimul̩ Рtimestamp

Suite à l’article sur le nouveau schéma des liens dissimulés, une précision s’impose concernant les champs Timestamp, les marques de temps.

Le lien à dissimuler contient une marque de temps qui est très souvent nécessaire à l’interprétation du lien, et notamment lors de sa suppression. De l’autre côté nous avons aussi une marque de temps sur le lien dissimulé cette fois. Mais nous ne devons pas avoir une copie directe de la marque de temps du lien à dissimuler vers le lien dissimulé parce que cette marque de temps va se retrouver potentiellement dans d’autres liens générés au même moment… et pourrait donner des indications sur le lien à dissimuler.

Il faut donc que la marque de temps du lien dissimulé soit clairement non reliée à la marque de temps du lien à dissimuler.

Du coup, un autre problème émerge, comment fait-on pour supprimer un lien à dissimuler, et donc en même temps le lien dissimulé ?

Le lien de suppression du lien à dissimuler doit être le même avec comme champs action x. Mais comme il contient toutes les informations, à part le champs action, du lien à dissimuler, il faut aussi dissimuler le lien de suppression. Jusque là, c’est facile il a une marque de temps différente et en lisant les liens dissimulés on peut voir la suppression.

Mais faut-il aussi un lien de suppression du lien dissimulé de suppression ? Et où celui-ci doit-il être stocké ?

La notion de lien dissimulé et à dissimuler est assez pénible à écrire, et donc à lire. Il faut peut-être aussi revoir le vocabulaire à ce niveau pour que ce soit plus fluide…

Blockchain et nouveau lien

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 ?

Définition des groupes

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.

Continuer la lecture de Définition des groupes

Entités de recouvrement – configuration

Suite des articles Entités de recouvrement et implémentation.

L’objet de référence de définition des entités de recouvrement est l’objet contenant :

nebule/objet/entite/recouvrement

De nouvelles options permettent de gérer la prise en compte des entités de recouvrement par la bibliothèque nebule en PHP :

  1. permitRecoveryEntities (boolean, critical) : commutateur global d’activation des entités de recouvrement via les liens des autorités strictement locales. Par défaut à false.
  2. permitRecoveryRemoveEntity (boolean, careful) : commutateur qui permet à une entité de supprimer le partage de la protection d’un objet avec une entité de recouvrement. Par défaut à false.
  3. permitInstanceEntityAsRecovery (boolean, critical) : commutateur de définition de l’entité instance locale comme entité de recouvrement. Outrepasse les liens. Par défaut à false.
  4. permitDefaultEntityAsRecovery (boolean, critical) :commutateur de définition de l’entité par défaut comme entité de recouvrement. Outrepasse les liens. Par défaut à false.

Toutes les options sont en lecture seule, c’est à dire que les liens d’options ne sont pas pris en compte. Au besoin, ces options doivent être modifiées dans le fichier d’environnement.

A false, par défaut, la première option désactive complètement la détection des entités de recouvrement et le mécanisme de partage de protection des objets pour les entités de recouvrement.

La deuxième option, si à true, permet à une entité de supprimer le partage de protection à une entité de recouvrement particulière. Cette action doit être faite après la protection, réalisée systématiquement, et sur tous les objets protégés un par un. Cette option va faire disparaître le bouton de suppression de partage de protection dans les affichages, mais elle est aussi vérifiée lors de la suppression effective du partage de protection d’un objet si l’utilisateur tente la suppression de force.

Le lien de déclaration d’une entité de recouvrement a la forme :

  • action : f
  • source : entité instance locale, par exemple = 3af39596818c1229d7a3d08b9f768622903951305df728609a68a2957f7f3882
  • cible : entité de recouvrement, par exemple = 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
  • méta : objet de référence de recouvrement

La désactivation est un lien de type x.

Les liens doivent être signés de l’entité instance locale ou de l’entité par défaut en fonction des options de permission.

Objet de référence contre suivi du graphe des mises à jours

Le bootstrap retrouve l’application et la librairie nebule à utiliser en suivant des liens. Actuellement, il suit le graphe des mises à jours de l’application sélectionnée et celui de la librairie nebule.

Mais il est possible dans ce cas d’utiliser une autre méthode de suivi des liens pour retrouver la dernière version des applications et de la librairie.

La recherche par les graphes permet de suivre les liens de type u d’objets en objets jusqu’à arriver en bout de branche de l’arborescence des mises à jours. Évidement, il faut tenir compte des liens de type x de suppression de liens. Et il faut aussi que l’objet en bout de branche soit disponible sinon on remonte la branche en sens inverse…
La méthode est efficace mais elle est très longue a jouer.

Il est possible de faire plus simple pour un résultat identique dans notre cas.

La structure de recherche de la dernière version d’un objet a dans notre cas un cheminement complètement sous contrôle. Il n’est pas nécessaire de gérer une profondeur de recherche de plus de un niveau, même avec des liens de mise à jour. En ne fonctionnant plus que sur un seul niveau il est tout à fait possible de n’utiliser que des liens de type f depuis un objet de référence.
Et en plus il est possible de ne plus à devoir gérer les liens de suppression de liens. Un nouveau lien remplace automatiquement le précédent lien. Si il faut supprimer le lien de la dernière mise à jour, il suffit de rejouer à une date plus récente le lien de la version précédente.

Et ainsi il y a gain du nombre d’objets parcourus et gain de temps de traitement sur les quelques liens qui restent.

Cette méthode va être mis en place dès que possible dans le bootstrap.

Gestion du lien de suppression de liens

Le lien de type x permet de supprimer des liens marqués à des dates antérieures.

En dehors de la gestion du temps et de la forme de la marque, comment doit se comporter le code lorsqu’un lien x à la même date qu’un autre lien ?

Dans l’ancienne librairie nebule en php procédurale, le code considérait l’autre lien comme supprimé. C’est à dire que le lien x est plus fort que les autres lors du traitement.

On peut réfléchir à des problèmes qui pourraient survenir, à la marge, sur la gestion des liens.
Cela présente cependant un avantage de conserver ce fonctionnement. Si dans l’interface on souhaite supprimer un lien, soit on utilise la date en cours, soit on précise la date du lien à supprimer. Dans ce dernier cas, si le lien à été régénéré par un autre moyen juste quelques secondes après, voir moins, le nouveau lien ne sera pas supprimé. Ce qui est plus logique.

Changement d’identifiant d’entité

On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.

Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.

Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat

Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.

Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.

Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…

Nettoyage des liens – suite

Ceci est la suite du post précédent sur le nettoyage des liens.

En cas de suppression d’un objet, quels liens doit-on garder ?

Il faut déjà évidemment garder le lien de type d, celui qui marque la suppression de l’objet. Sans ce lien, la propagation de la suppression ne sera pas assurée, et donc l’objet ne sera pas supprimé sur tous les emplacements. Si il est encore présent sur un emplacement connu, il risque d’être téléchargé de cet emplacement et donc en quelque sorte restauré. Ce lien doit être gardé « Ã  vie ».

Il faut garder les liens de type u, c’est à dire voir quel(s) objet(s) est mise à jour l’objet supprimé. Il est préférable dans une chaîne de mises à jours de créer un nouveau lien qui court-circuite l’objet supprimé au milieu de la chaîne.

Il faut garder les liens de type e, les définitions d’équivalences.

Il faut supprimer tous les liens dont on est pas le signataire. Il n’y a pas de raison de garder les liens des autres entités. Les autres entités s’occuperont de leurs liens.

Il faut garder les liens de type k, correspondant au chiffrement. Lors du chiffrement d’un objet, on définit explicitement la suppression de l’objet originel pour ne garder que son dérivé chiffré.

Il faut supprimer les liens de type s, ce qui défini les subdivisions de l’objet. Cet objet n’est plus utilisable pour la récupération de morceaux. Et si il est recréé, les liens de type s le seront aussi naturellement, si besoin.

Jusque là, ça paraît suffisant. Mais que se passera-t-il le jour où, pour quelque raison que ce soit, l’objet venait à être réutilisé (volontairement) ?
Faut-il garder tous les liens de type l et f? Faut-il n’en garder qu’une partie?

Il faut aussi nettoyer les liens qui ont fait l’objet d’une suppression avec un lien de type x. Et il faut garder chaque derniers liens de type x. Ainsi, en cas de restauration de l’objet, les liens supprimés ne pourront être restaurés aussi.

Si c’est une suppression liée à un chiffrement, on doit garder tous les liens de type l et f. Ces liens sont nécessaires puisque l’objet à de bonnes chances d’être déchiffré un jour par le destinataire.

Dans les autres cs, c’est ambigu. Par défaut il vaut mieux garder tous les liens l et f.

Dans le cas d’un serveur que l’on ne maîtrise pas ou qui est mutualisé, la suppression d’un objet doit être marqué par toutes les entités. On ne peut pas supprimer un objet tant qu’une entité l’utilise encore. On entre là dans une forme de gestion en groupe.

Nettoyage des liens

Le nettoyage régulier des liens est quelque chose qui est connu depuis assez longtemps pour être indispensable. Si la quantité de lien que manipulent aujourd’hui les entités reste encore soutenable, nous ne sommes pas loin de gros problèmes de performances dans certains cas.
CF : Mémoire finie, Repérage chronologique.

Le nettoyage est la mise en pratique de l’oubli volontaire et maîtrisé des liens et objets.

Un premier nettoyage, assez facile à mettre en place par script notamment, est le nettoyage des liens. Suivre cette procédure :

  1. Copier tous les liens de tous les objets dans un emplacement temporaire unique. Chaque lien copié doit l’être une fois pour ne pas avoir de doublon. Il est préférable de faire une vérification des signatures des liens au moment de leur lecture. Chaque lien étant copié entre deux et trois fois en fonction du nombre d’objets concernés, la taille total de cet emplacement temporaire sera entre deux et trois fois moins volumineux que l’ensemble des liens des objets.
  2. Dans l’emplacement temporaire, trier les liens par date dans l’ordre chronologique. Ainsi, une fois remis en place, les liens seront déjà naturellement triés.
  3. Dans l’emplacement temporaire, supprimer les liens qui sont concernés par un lien de type x (suppression de lien). Garder le dernier lien de type x pour maintenir la propagation de la suppression du lien.
  4. Supprimer, ou mettre de côté, les liens de tous les objets. Ne garder que l’emplacement temporaire. Pendant ce lapse de temps, les objets restent disponibles mais sont inexploitables parce qu’ils ne seront pas accompagnés de leurs liens.
  5. Faire un import de chaque liens de l’emplacement temporaire, un par un et dans l’ordre. L’import va réattribuer les liens aux objets concernés, dans l’ordre.

Cette procédure ne tient pas compte des liens dans des objets, normalement chiffrés. Et ils ne doivent pas en tenir compte. Cela peut poser des problèmes résiduels de non suppression de liens parce que le lien de type x est non disponible au moment du nettoyage.

A noter qu’après le nettoyage, si des liens ont été marqués comme à supprimer, il doit rester le dernier lien de type x. Si ce n’était pas le cas, il pourrait y avoir des problèmes pour retransmettre la suppression de ces liens.

Tous les liens ne peuvent pas, et ne doivent pas disparaître en même temps que l’objet. Il faut en effet attendre que la suppression de l’objet, dictée par un lien de type d, soit effective partout. Sinon, cet objet va réapparaître et ses liens avec.

Pour nettoyer les objets, il manque la mise en place du système de pondération. Seule cette pondération associée à un seuil est capable de gérer l’oubli de certains objets parmi un grand volume d’objets.
La pondération sera pour plus tard.