Catégorie : objets

Objet virtuel avec rôle

Jusque là, la très grande majorité des objets créés ont ou ont eu un contenu et donc une empreinte numérique unique leur correspondant. Cela a été le cas pour les images utilisées comme icônes dans sylabe par exemple.

Le problème par exemple avec l’usage direct de l’objet d’une icône fait que si on veut la mettre à jour ou tout simplement en utiliser une autre à la place il faut faire un lien de mise à jour. Or ce lien de mise à jour n’a pas de contexte, c’est à dire de champs méta dans le lien. Ainsi la mise à jour s’applique partout alors que ce n’était pas forcément le but recherché.

La solution est de ne pas faire référence directement à une image que l’on veut utiliser dans une application mais à un objet intermédiaire. Cet objet n’a même pas besoin d’avoir un contenu, il est virtuel puisque son empreinte est créé de toute pièce sans contenu. Et du fait du fonctionnement de nebule, il n’aura probablement jamais (dans un temps raisonnable) de contenu correspondant à son empreinte.

Ainsi, on ne référence plus dans une application des icônes mais des objets intermédiaires. Et les icônes à utiliser n’ont plus à être des liens de mise à jour u mais deviennent naturellement des liens de dérivation f avec comme champs méta l’objet intermédiaire ou l’objet de l’application. Je pense que l’objet intermédiaire est le mieux comme champs méta.

Comme l’empreinte de cet objet virtuel est purement indicative, on peut lui mettre n’importe quelle valeur de n’importe quelle taille. Il est cependant raisonnable de choisir une taille assez conséquente et différente des tailles usuelles des empreintes, c’est à dire différent de 64, 128, 224, 256, 384, 512, 768, 1024, 2048, 4096, etc…
Chaque application peut utiliser les mêmes valeurs pour ces objets intermédiaires ou choisir par exemple une valeur préfixe identique suivi de valeurs aléatoires jusqu’à avoir une taille raisonnable.

Nommage d’entité – préfix

Le nommage des objets permet d’inclure un préfixe et un suffixe.

Pour les fichiers nébulisés, le suffixe correspond à l’extension du nom de fichier. Cette extension ne fait pas partie du nom.

Pour une entité, le préfixe peut être utilisé pour contenir le titre d’une personne ou un grade. Mais le suffixe n’a pas d’utilité au premier abord. Mais une entité peut disposer de plusieurs entités qui lui sont rattachées. Afin de distinguer l’entité maîtresse des autres entités, le suffixe peut les différencier en leur donnant une distinction ou un rôle précis.

Entités de recouvrement

Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.

D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.

Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.

D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.

Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.

Définition des groupes

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’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. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

NÅ“ud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Liens de propriétés d’un objet

Rien de vraiment nouveau pour ce début d’année 2016.

Via la librairie php, on pouvait récupérer une ou des propriétés d’un objet avec le contenu de ces propriétés, on peut maintenant récupérer juste le ou les liens correspondants. Ainsi il est possible d’extraire facilement d’autres informations sur ces propriétés comme la date ou l’entité créatrice…

Sondages et votes

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

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

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

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

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

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

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

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

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

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

La sécurité des suppressions de données

Le piratage de Sony Pictures a provoqué une véritable onde de choc dont les ramifications sont parfois inattendues. L’article The Security of Data Deletion de Bruce Schneier fait l’apologie d’une stratégie ‘agressive’ de suppression des données obsolètes dans les entreprises. Puisqu’il n’est pas possible de garantir la confidentialité des données d’une entreprise, même une parmi les plus grosses, il est préférable de supprimer ces données lorsqu’elles sont obsolètes.

On peut aussi parler de l’intégrité puisque si un pirate a réussi à récupérer quelques téraoctets de données sans se faire prendre, il a tout aussi bien pu en altérer au passage. Si la cryptographie peut nous aider à ce niveau pour signer les données et messages, elle ne pourra pas grand chose si les postes utilisateurs, leurs programmes et donc leurs clés sont compromises…

Mais revenons à la politique de suppression des données. Parler de politique agressive est un peu exagéré. La notion d’agressivité sous-entend de supprimer dès que possible une donnée lorsqu’elle n’est plus utilisé. Il est fait référence dans l’article à ce que l’on transmettait par téléphone avant l’informatique, les informations annexes que l’on ne notaient pas finissaient par être rapidement oubliées, au pire déformées… ou au mieux sujettes à confirmation.

Si la messagerie instantanée est assez informelle, la messagerie classique est beaucoup plus formelle, surtout en entreprise. On est dans ce dernier cas assez loin de la conversation libre par téléphone.

Une entreprise ne peut pas non plus supprimer sans discernement ses données sous prétexte qu’à un instant donné elles n’ont plus d’utilité. Ces données, c’est la mémoire de l’entreprise. Les supprimer c’est supprimer la mémoire de l’entreprise, une des choses les plus importantes puisque c’est l’accumulation de son savoir faire, de son savoir sur ses clients et ses racines. Supprimer les données anciennes d’une entreprise, c’est comme supprimer la mémoire à long terme des individus, c’est catastrophique pour eux et pour la société dans son ensemble.

Ce parallèle avec l’individu n’est pas anodin. La capacité d’une entreprise c’est la somme des individus qui la composent démultiplié par le patrimoine technique.
Et le parallèle peut aller plus loin. L’individu ne retiendra pas tout d’une conversation téléphonique. Des informations annexes seront perdus parce que non mémorisées par l’un ou l’autre des interlocuteurs. Ensuite, avec le temps, chaque interlocuteur va oublier certaines informations pas très importantes, progressivement. Au final, après un grand laps de temps, il ne subsistera de la conversation téléphonique que l’essentiel de l’information. Il faut donc bien de la même façon supprimer les données éphémères d’une entreprise mais il ne faut pas tout supprimer. Avec le temps, seul doit subsister l’essentiel des informations du passé. Les idées doivent être résumées et les informations techniques doivent être épurées de leurs pré-calcul et des données annexes.
Comme fil conducteur, on peut essayer d’avoir la vision d’un historien sur le passé de l’entreprise pour savoir ce qui a de l’intérêt ou pas. Et ainsi, naturellement, toutes les conversations hors champs vont disparaitre.

Tel que déjà définit précédemment pour le projet nebule, les données doivent pouvoir être supprimer automatiquement après un certain délai ou conservées explicitement. Une pondération appliqué aux objets déterminera le délai de conservation, ou plutôt de non-suppression. Et un seuil déterminera à partir de quelle pondération un objet sera à garder définitivement. Ce seuil peut évoluer avec le temps et faire disparaitre après coup des objets qui initialement étaient au dessus du seuil de suppression. La pondération reflète l’importance des objets, positivement ou négativement.

Pour finir, n’est-il pas plus simple d’être respectueux dans ses messages même à usage interne ? A défaut d’empêcher le vol d’information, au moins on évite déjà les propos embarrassants, une charge de moins dans la réparation des dégâts. Mais quelque part, cela reflète un état d’esprit dans l’entreprise, une certaine culture des individus qui la composent… bref, pas très sain…

Arborescence virtuelle

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Localisation des objets

La possibilité de localiser un objet ou juste une entité me travaille depuis un moment. Même si cela n’a pas d’application aujourd’hui, il est plus logique de faire remonter la possibilité de localisation au niveau de l’objet. Ainsi, si il sera toujours possible de localiser une entité, on peut imaginer soit localiser un objet soit aussi s’en servir pour demander à un robot d’héberger cet objet.

Ainsi, l’objet méta contenant la propriété ‘nebule/objet/entite/localisation‘ est doublé de ‘nebule/objet/localisation‘ pour l’instant et disparaîtra à terme. CF wiki.nebule.org – Documentation – nebule v1.2 – Objets à usage réservé

Les propriétés ‘nebule/objet/entite/webaccess‘ et ‘nebule/objet/entite/webaccess/firstofall‘ sont périmées et dès maintenant supprimées.

Les différentes propriétés ‘nebule/objet/entite/suivi/...‘ sont en sursit.

Nommage d’objets et d’entités

Dans la vraie vie, le nommage des personnes a une forme conventionnelle. Il en est de même de fait pour les fichiers puisqu’ils sont tous gérés de la même façon.

Dans nebule, chacun des objets disposent d’un identifiant unique mais aussi d’un nom, même si ce dernier n’est pas obligatoire. Le nom est cependant nécessaire à l’être humain pour classer et retrouver ses données. Pour les entités, qui sont gérées comme des objets, elles ont aussi un nom mais la forme est un peu différente même si le but est similaire au nom de l’objet.

Dans nebule, tous les objets peuvent avoir ces propriétés :

  1. nom
  2. prénom
  3. surnom
  4. préfixe
  5. suffixe

Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :

  1. nebule/objet/nom
  2. nebule/objet/prenom
  3. nebule/objet/surnom
  4. nebule/objet/prefix
  5. nebule/objet/suffix

Par convention, voici le nommage des objets pour l’affichage :

prénom préfixe/nom.suffixe surnom

Le prénom et le surnom n’ont que peu d’intérêt.

Les entités disposent naturellement des mêmes propriétés, mais leur nommage pour l’affichage est un peu différent.
Par convention, voici le nommage des entités :

préfixe prénom "surnom" nom suffixe

Ici, c’est le suffixe qui a peu d’intérêt.

Une dernière remarque. Bien que certaines propriétés n’aient pas aujourd’hui de grand intérêt pour l’affichage, le fait de le proposer aux utilisateurs les rend automatiquement inamovibles. Il y aura toujours quelqu’un qui leur trouvera une utilité et les utilisera… d’où l’intérêt dès maintenant d’une convention d’affichage.

La documentation est mise à jour en conséquence : wiki.nebule.org – nebule_v1.2 – Objet

Nommage multiple et protéiforme

Dans nebule, les objets ont forcément un identifiant. Ils ont aussi parfois un nom. Typiquement, c’est le cas lorsque l’objet a pour source un fichier nébulisé.

shot-2014-07-18_20-07-59

Le nom est un texte de caractères compréhensible par les humains. Déjà, en fonction des langues, il se peux que ce texte ne soit pas compréhensible pas tout le monde. Mais on exclut déjà par principe les caractères non imprimables, même si en réalité ça n’a pas beaucoup d’importance. Il vaut mieux que le texte n’ai pas de retour à la ligne, mais ça peut être interprété, traduit et pris en compte à l’affichage.

Pour un fichier, le nom (qui inclus le chemin) a deux rôles :

  1. le classement sommaire par sujets en fonction du chemin et parfois du nom ;
  2. la description sommaire du contenu, un peu comme un titre.

Dans nebule, le nom que l’on peut donner à un objet a le même rôle que le nom pour un fichier. Il donne un titre à l’objet. Par contre, le classement des objets intervient peu avec le nom que ceux-ci pourraient avoir. Ce serait plutôt le rôle de groupes et de nÅ“uds, concept encore en cours d’affinement. Pour un objet, lui donner un nom c’est le lier à un autre objet qui contient le nom avec un lien de type l.

Si un fichier ne peut avoir qu’un seul nom, un objet peut en avoir plus. Il est possible de créer plusieurs liens vers différents objets à utiliser comme noms. Les propriétés de liens multiples et concurrents sont valables aussi pour le nommage.
Lors de l’affichage, comme dans l’exemple ci-dessus, il faut faire un choix. Soit on affiche tous les noms, ce qui peut rapidement devenir problématique et difficilement compréhensible par l’utilisateur. Soit on affiche qu’un seul nom, celui affiché étant celui qui a le plus grand score dans le calcul des relations sociales. C’est cette dernière solution qui est adoptée aujourd’hui.

Mais on peut faire encore mieux. Rien n’interdit un lien pour un titre de renvoyer vers une image. D’ailleurs, ce peut être tout objet sans distinction. C’est l’interprétation du titre qui ici prend son importance. Si on n’interprète que du texte alphanumérique sur une seule ligne, les autres objets seront ignorés comme titre.
Si on décide de prendre en compte aussi les images, il ne sera peut-être pas opportun d’utiliser une image de grande résolution, lourde. On peut utiliser à la place les miniatures, des images dérivées, pour l’affichage comme titre. Les miniatures d’images seront d’ailleurs très régulièrement utilisées lors de l’affichage.
Pour un film, on va peut-être utiliser soit une image fixe soit une petite séquence animée, l’une comme l’autre extraite du film.

L’affichage final peut dans certains cas prendre en compte simultanément plusieurs objets titres mais de types différents. Par exemple accepter une image et un texte, ou un morceau de film, un son et un texte…
Protéiforme ne veut pas dire en forme de protéine mais bien de formes multiples.
Tout est question d’interprétation et de stratégie d’affichage. Tout est possible, aussi.

Dans sylabe, comme dans nebule, une entité a un nom constitué d’un petit texte, un prénom et même un préfixe sur le même principe. Mais elle peut aussi depuis peu avoir une image, typiquement une photo d’identité. Le nommage multiple et protéiforme existe donc déjà.

Prise d’empreinte homomorphique

Les objets manipulés par nebule sont identifiés, et donc référencés, par leurs empreintes respectives. Ces empreintes sont cryptographiques afin de pouvoir s’assurer que c’est bien le bon objet, afin de pouvoir avoir confiance dans l’intégrité de son contenu. Il est possible dans un seul cas d’avoir plus d’une empreinte par objet, c’est si celles-ci sont calculées avec des algorithmes différents (cf Collisions d’empreintes multi-algorithmique).

Cependant, si la propriété cryptographique des empreintes est indispensable à la confiance, elle entraîne un manque de souplesse dans le référencement des objets. Rien dans la valeur de l’empreinte ne trahis une partie de son contenu. L’empreinte cryptographique reflète uniquement l’intégralité de l’objet. On ne peux pas s’en servir pour retrouver des objets proches dans leur contenu. Tout au plus peut-on vérifier si deux objets sont identiques… ce qui n’a pas d’intérêt puisque dans ce cas c’est tout simplement le même objet.

Sub-division d’objet

La première solution pour résoudre ce problème est d’utiliser des sous-parties d’un objet comme des objets propres, et de les identifier comme tels. Le lien de type s permet justement de lié l’objet principal à ses morceaux.

C’est notamment ce qui est fait dans les logiciels de Paire-à-Paire (P2P – Peer to Peer). Pour qu’un fichier puisse être téléchargé depuis de multiples sources, celui-ci est pré-découpé en morceaux de taille identique pré-définit. Chaque morceau à une empreinte propre et peut être vérifié à la réception. Chaque morceau est téléchargé sur une et une seule source, mais plusieurs morceaux sont téléchargés simultanément depuis plusieurs sources. On augmente ainsi le débit réel de réception du fichier voulu même si les sources ont individuellement un faible débit d’émission. Évidemment, si chaque morceau est valide, le fichier dans son ensemble ne peut qu’être valide.

Une recherche sur mot clé peut avantageusement tirer partie de ce système puisqu’une recherche se fera uniquement sur l’empreinte du morceau correspondant à la recherche. Toute la difficulté est de bien choisir ces morceaux.

Pour du texte, c’est facile. Pour une recherche sur des images ou des vidéos, c’est déjà beaucoup moins évident. Mais quoique l’on trouve, c’est toujours une liste d’objets qui contiennent cette petite sous-partie même si le reste n’a absolument aucun rapport.

Empreinte homomorphique

Une autre solution consiste à essayer de trouver des objets qui ont le plus de contenu en commun. Ce serait une sorte de représentation miniature du contenu de l’objet. On veut quelque chose qui se rapproche plus de l’empreinte des doigts de pieds. On regarde d’abord que cela à bien la forme d’un pied, puis on regarde plus en détail certaines parties morphologiques pour déterminer si les deux pieds sont proches.

On pourrait partir sur le système de sous-découpage utilisé par le P2P. Chaque objet est découpé en petits morceaux de taille identique. Ainsi, si deux objets ont un ou des morceaux en commun, on pourra en déduire que ceux-ci sont proches.
Mais cette méthode pose un problème. Si on prend un objet et que l’on en fait une copie avec pour seule différence un caractère supplémentaire dans le premier bloc de données, alors tous les blocs seront vus comme différents alors que les objets ont clairement des parties communes.
On pourrait imaginer essayer d’optimiser la méthode en travaillant sur des blocs de tailles variables. Mais quels critères adopter pour ajuster les tailles de blocs en fonction des données ?

Je propose une méthode comme base de réflexion à défaut pour l’instant d’être adoptée.
Si on regarde le travail d’un logiciel de compression de données, on constate qu’il recherche les occurrences multiples de données dans l’ensemble d’un document. Il le fait sans tenir compte de la sémantique de ce qu’il trouve. Ainsi des mots très proches sémantiquement ne seront pas agrégés parce que différents. Ensuite, le logiciel de compression fait un classement statistique pour déterminer les occurrences multiples qu’il serait avantageux de réduire. Une phrase qui apparaît quelques fois permet une bonne optimisation. Un mot qui apparaît plusieurs permet aussi un gain de place facile.
Si on reprend le même principe d’analyse, même sans tenir compte de la sémantique des mots, on peut s’attendre à ce que les plus grandes occurrences de mots ou de phrases représentent le ou les sujets du document. C’est ce que fontnotamment les moteurs de recherches (Google, Bing, Yahoo…) lorsqu’ils moulinent les pages web, mais avec l’analyse sémantique en plus.
L’empreinte homomorphique est constituée des 20 premières occurrences redondantes avec leur poids respectifs. L’occurrence peut être représentée par une petite empreinte (CRC) de façon à avoir une taille fixe, mettons 16 caractères hexadécimaux. Le poids peut être représenté en pourcentage sur 4 caractères hexadécimaux (entre 0000 et ffff).
Vue comme ça, l’empreinte générée n’est plus tout à fait homomorphique et n’a pas de propriétés cryptographique.On obtient une empreinte homomorphique de 400 caractères hexadécimaux.

Ainsi, plusieurs documents parlants d’un même sujet ont de fortes chances d’avoir une même empreinte parque bien que différents ils auront les mêmes occurrences redondantes.

Un certain nombre de données annexes vont figurer dans les données utilisées pour la comparaison. Par exemple on peut retrouver les en-têtes internes des documents bureautique. Il faut peut-être pré-filtrer les documents en fonction de leur type pur. Par exemple, un simple fichier texte et un fichier complexe de traitement de texte se verront expurgés de tout ce qui est en-tête et données internes, puis on en gardera que les caractères imprimables convertis en minuscule, sans ponctuation…

Conclusion

Une empreinte homomorphique peut être utilisée avantageusement en complément de l’empreinte cryptographique. Elle n’a d’intérêt que pour des objets ayant suffisamment de contenu. Il faut prévoir un seuil minimum en dessous duquel elle n’est pas calculée. Cette empreinte homomorphique est liée à l’objet par un lien de type l avec comme objet méta « nebule/objet/homomorphe ». Cet objet à usage réservé est ajouté à la documentation.

Mais dans tous les cas, en l’absence de propriétés cryptographique, une empreinte homomorphique ne doit pas être utilisée dans les liens. L’usage n’est pas le même, on fait soit de l’intégrité, soit du référencement.

Supprimer un grand nombre d’objets anciens

La fonction d’oubli, bien qu’indispensable, n’est pas encore en place. Elle nécessite la mise en place préalable de la pondération sur les objets. Cette pondération est elle-même un dérivé des avis et émotions.

En attendant, il peut être nécessaire de supprimer un grand nombre d’objets anciens et qui perdent vite de la valeur avec le temps. Typiquement cela concerne les sauvegardes d’un serveur. Les sauvegardes ont une forte utilité mais seule la dernière en date a vraiment de l’importance. Tout au plus peut-on garder des sauvegardes plus anciennes pour pouvoir remonter dans le temps, au cas où. Mais si on fait une sauvegarde journalière, la plupart des sauvegardes n’ont plus d’intérêt après quelques jours, voir le lendemain.

Voici comment supprimer des objets par lot dans nebule, et surtout en bash.

1 Lister

Première étape, lister tous les objets que l’on souhaite ‘oublier’. Ici, les objets sont ceux qui font plus de 10Mo et qui sont anciens de plus de 90 jours.
Lancer :
find pub/o/ -mtime +90 -size +10M | cut -d '/' -f 3 > aSupprimer.txt

Le fichier aSupprimer.txt contient la liste des objets qui répondent aux critères. Il serait tentant de supprimer directement les fichiers, mais ceux-ci pourraient réapparaître suite à une synchronisation. Il est préférable de les marquer supprimés.

2 Supprimer

Deuxième étape, faire supprimer et marquer comme supprimés les objets précédemment listés.
Lancer :
. lib_nebule.sh
. env.sh
export nebule_publ_entite=$(cat pub/e)
export nebule_priv_entite=$(cat priv/e)
read -s -p "Mot de passe : " nebule_pass_entite
nebCheckKeyPass
cat aSupprimer.txt | while read O ; do echo $O ; _l_wr $(_l_gen 0 d $O 0 0) ; rm pub/o/$O ; done

Et voila, les objets sont supprimés et marqués comme supprimés. Le fichier aSupprimer.txt peut être lui aussi supprimé…

Auto déploiement répliqué d’un code

La librairie nebule de référence en php gère maintenant les liens de mise à jour d’objets conformément à la méthode décrite dans l’article sur la Résolution d’un graphe de relations de mise à jour.

Cette fonctionnalité qui paraît au premier abord peu utile tous les jours est en fait primordiale pour diffuser de façon sécurisée les mises à jours de logiciels. Le premier programme à en bénéficier est sylabe. La diffusion du code sous forme d’objet a déjà commencé : Gestion des versions de sylabe – mise en ligne

Ainsi, le code de sylabe va pouvoir être très facilement tenu à jour avec la toute dernière version. Mais cela va aussi grandement simplifier l’installation puisque le code de bootstrap va être capable d’aller automatiquement récupérer immédiatement la dernière version de sylabe avant de permettre son utilisation.

Nous arrivons dans le projet nebule à un point de singularité. Alors que jusque là, les fichiers mais aussi les entités (les utilisateurs) avaient été intégrés à nebule sous forme d’objets, le code de nebule restait lui en dehors des objets. Maintenant, le code de gestion des liens et objets devient lui aussi un objet géré par des liens comme tout objet.

Le code sera initialement signé et diffusé par l’entité bachue. Tout entité à jour deviendra à son tour point de redistribution du code.

Résolution d’un graphe de relations de mise à jour

L’utilisation des liens de mise à jour d’objets est utilisé dans des cas biens spécifiques mais revêt une grande importance par exemple dans la mise à jour de programmes. Cela a notamment des implications sur la sécurité des programmes gérés sous forme d’objets.

Les liens de mise à jour n’ont pas de contraintes et peuvent donc créer des graphes de liens entre objets de forme quelconque. Cependant, l’usage de ces liens dans nebule nécessite que pour un objet donné on obtienne un unique autre objet. Cet objet doit être disponible puisque l’on est dans le cas d’un usage, c’est à dire de son utilisation immédiate.

La résolution d’un graphe de liens permet d’obtenir l’identifiant un objet dérivé unique et disponible pour un objet de départ en tenant compte de la validité des liens. Cette résolution est spécifique à nebule et se fait sous forme arborescente en ne tenant compte de des liens descendants et non bouclés.

Table des matières :

  1. Lien de mise à jour
  2. Remplacement de lien de mise à jour
  3. Mise à jour arborescente
  4. Gestion des objets manquants
  5. Résolution des boucles

Cette méthode de résolution va maintenant être expérimentée grandeur nature dans sylabe pour la gestion des versions des programmes. Continuer la lecture de Résolution d’un graphe de relations de mise à jour

Abandon de certains liens lors du chiffrement

Maintenant que l’IV est utilisé par défaut avec une valeur nulle, il n’a plus à être précisé. Le lien qui était généré vers l’objet nebule/objet/encode/InitialVector pour le préciser n’a plus de raison d’être utilisé.

Il en est de même pour la clé de session. L’objet de la clé de session apparaît naturellement dans les deux liens de chiffrement. Il n’est donc pas nécessaire de re-préciser que c’est une clé de session. Il n’est d’ailleurs pas utilisé dans le processus de déchiffrement. Le lien vers nebule/objet/encode/SessionKey ne sera donc plus généré.

Et de fait, l’objet nebule/objet/encode n’a plus d’utilité non plus. La documentation de nebule v1.1 est mise à jour en conséquence. On supprime ces objets réservés :

  • nebule/objet/encode
  • nebule/objet/encode/InitialVector
  • nebule/objet/encode/SessionKey

Chiffrement et subdivision

Le chiffrement permet offusquer des données, c’est à dire de protéger celle-ci d’une diffusion inappropriée.

La subdivision consiste, à partir d’un objet unique, en la création de plusieurs objet dérivés plus petits. Ces petits objets sont des sous-ensembles de l’objet principal, c’est à dire des morceaux. Ce n’est pas encore implémenté aujourd’hui, mais le type de lien existe pour définir la relation de morcelage entre l’objet principal et les sous-objets.
La subdivision permet de découper un objet en bloc pour qu’il puisse être transmis par morceaux à la manière du P2P.
La subdivision peut aussi et simultanément être utilisée afin de constituer un index de certaines portions intéressantes. Cela peut être par exemple un index des mots dans un texte pour permettre une recherche accélérée sur des mots clés.

Cependant, la combinaison du chiffrement et de la subdivision pose un problème de confidentialité.

Que se passe-t-il si on décide de protéger un objet contenant du texte, c’est à dire le chiffrer, mais que l’on ne retire pas les liens de subdivision ?
Si ces liens de subdivision renvoient vers des parties d’un index des mots clés, alors il est possible de reconstituer les grandes idées du texte. Voir il est possible de reconstituer dans le pire des cas l’intégralité du texte déchiffré. On contourne ainsi la protection mise en place.

Il faut cependant noter que si un objet est protégé à posteriori, il a peut-être déjà été copié légitimement. Il pourrait en être de même de certaines parties marquées comme subdivisions.

Afin de minimiser ce problème de confidentialité, il y a plusieurs règles à appliquer :

  1. Ne jamais faire de liens de subdivision sur un objet protégé mais uniquement sur son dérivé chiffré.
  2. Si une protection est activée pour un objet existant, supprimer tous les liens de subdivision.
  3. Si l’objet est nouveau et doit être protégé, ne pas faire de liens de subdivision sur celui-ci mais uniquement sur son dérivé chiffré.

Lorsqu’il sera possible d’offusquer des liens, ces règles pourront être revues.

Multi-entité et suppression d’objet

A l’origine, le projet nebule s’appliquait à des entités autonomes. C’est à dire que les entités fonctionnaient localement dans un environnement réservé et ne dépendaient pas d’une entité maître.
Cependant, ces deux points ne sont plus assurés. Le cas du projet sylabe montre que de multiples entités peuvent coexister sur un serveur et surtout dans le même environnement. Ce pourrait être le cas aussi dans une famille qui utilise le même ordinateur, et donc le même environnement. La sûreté de fonctionnement veut que les objets publiques soient partagés pour économiser des ressources, et que les objets protégés ne soient à aucun moment disponibles aux entités qui n’ont pas la clé de déchiffrement.
De plus, pour assurer des transferts anonymisés, il est nécessaire de créer des entités dédiées à ce rôle. Ces entités ne doivent pas avoir de lien avec la véritable entité d’un utilisateur. Mais cet utilisateur doit pouvoir gérer ces entités esclaves et notamment détenir les mots de passe de celles-ci. Il se crée donc une petite hiérarchie d’entités. Il reste à assurer la non-liaison entre l’entité maître et les entités esclaves. Il faut penser que ce lien peut être remonté par les liens de type l, f, u, k, et e… sauf à les chiffrer…
A voir.

Suite à la réflexion sur le nettoyage des liens, et suite, l’expérience de sylabe montre que la suppression des objets en environnement partagé n’est pas évident. En effet, si je décide de supprimer un objet et un certain nombre de liens affairant, que ce passe-t-il ?
Pour les liens, ce n’est pas grave puisque ce sont mes liens. Les autres entités sont sensées disposer de leurs propres liens.
Pour l’objet, peut-être qu’une autre entité s’en sert aussi. Le supprimer sans concertation n’est pas la bonne méthode. Demander une concertation est inimaginable, surtout si certaines entités effectivement disponibles sur un serveur ne sont en fait plus utilisées.
Il se pose une question sur l’appartenance de l’objet. On pourrait très bien supprimer un objet du serveur, si une autre entité en a besoin elle le synchronisera simplement ailleurs et du coup il réapparaîtra sur le serveur. C’est aussi potentiellement un déni de disponibilité si cet objet n’est présent que sur ce serveur ou si on arrive à demander simultanément la suppression sur tous les serveurs hébergeant cet objet. D’après la théorie, un objet n’appartient à personne contrairement aux liens.

La suppression d’un objet qui pose un vrai problème de sécurité ou de droit d’utilisation dans un pays peut être géré de façon exceptionnelle. L’entité à qui appartient le serveur peut se voir disposer du pouvoir de suppression améliorée d’objets sur son serveur ainsi que la possibilité de le placer en liste de bannissement. Il faut de toute façon mettre en place la gestion de la liste de bannissement de l’entité cerberus : nebule/danger.

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.