Catégorie : suppression

Oubli, nettoyage et suppression des liens

Suite des articles Nettoyage des liens et suite, et Suppression et oubli. Le sujet est déjà ancien et il y a eu quelques réflexions sur les objets mais rien de concert n’a été mis en place. Cette absence d’implémentation s’explique parce que la gestion des relations sociales dans les liens n’est pas assez avancée. Le but est double, gérer le stockage et améliorer les performances.

Cependant il est possible de continuer la réflexion notamment sur les liens qui n’ont pas les mêmes contraintes que les objets. La gestion des liens dissimulés dans des fichiers de liens spécifiquement nommés a créé une brèche dans le nommage strict des fichiers de liens. Une première tentative avait commencée avec le stockages de liens anciens dans des fichiers de liens avec un chaînage au fichier d’origine mais n’avait pas abouti du fait de plusieurs problèmes.

Aujourd’hui il est possible de gérer les liens suivant deux méthodes, l’ancienneté et/ou le surnombre. Et cela va trouver une solution dans deux type d’actions, la suppression ou la mise à l’écart dans des fichiers d’archivage datés dédiés. Il faut une option d’activation de l’oubli des liens, une option de sélection de la méthode et option de sélection de l’action. On peut envisager d’utiliser les deux méthodes simultanément.

Pour la méthode de l’ancienneté, il faut distinguer quel type de lien on doit garder disponible immédiatement. Cela veut dire des options par types de liens pour dire l’ancienneté maximale attendue. La notion de sociabilité des liens et intéressante aussi parce qu’il suffit de garder un seul lien signé par l’entité ayant le plus gros score social.

Pour la méthode du surnombre, il faut aussi distinguer le type de lien parce que certains liens sont indispensables au bon fonctionnement d’un objet. Pour chaque type de liens, on garde les liens les plus récents à concurrence du nombre autorisé. Il faut une option par type de liens de définition du nombre à garder pour chaque types. Peut-être faut-il prévoir une gestion sociale afin de pondérer l’ordre des liens et de garder les liens les plus pertinents.

Certains objets ont des rôles importants comme les codes des applications. Ils sont assez facile à gérer parce que les liens sont signés d’une autorité maîtresse du code. Cela va peut-être nécessiter la création d’un nouveau type social mixant strict et réputation pour les gérer encore plus facilement.

Pour l’action de suppression c’est facile, il suffit de ré-écrire le fichier des liens d’un objet en ne gardant que ceux désirés. Les autres liens sont oubliés et perdus localement. Il n’y a pas de mécanisme de corbeille, si besoin il faut basculer sur l’action de mise à l’écart.

Pour l’action de mise à l’écart, on ré-écrit les liens désirés dans le fichiers des liens de l’objet et on écrit les autres liens dans un autre fichier avec un nommage spécial. Ce nommage commence par l’identifiant de l’objet et se voit ajouter une marque de temps et une valeur aléatoire. L’identifiant permet de relier les liens contenus à l’objet concerné. La marque de temps permet de remonter dans le temps progressivement en cas de besoin. La valeur aléatoire empêche la récupération à distance des liens anciens. Le datage se fait à la journée, reste à choisir la base de temps utilisée.

La mise à l’écart de liens avec un horodatage permet un nettoyage facile à posteriori des liens anciens. Et cela permet aussi localement d’activer une utilisation des liens plus anciens sur la sélection d’une date de départ mais au prix de performances dégradées. Ce paramètre de recherche temporelle doit être un argument de l’URL des applications et doit être contrôlé par une option d’autorisation pour une entité déverrouillée ou non.

Ensuite il y a deux stratégies pour rechercher et traiter les fichiers de liens trop gros et/ou avec des liens trop anciens. Soit on fait une recherche globale systématique à intervalle régulier ou lorsque que les performances baissent. Soit on met en place lors de la lecture des fichiers de liens des détecteurs à seuils afin de détecter à l’usage les fichiers de liens nécessitant un nettoyage, et on les traitent immédiatement ou à intervalle régulier.

Lien de transaction

La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.

Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?

Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…

Et comment gère-t-on l’oubli volontaire de ces liens ?

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…

Suppression et oubli

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

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

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

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

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

Renforcement de la lecture des objets – type hash invalide

Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.

Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.

Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.

L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :

  1. false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.
  2. true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.

Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.

Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.

Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…

Renforcement de la lecture des objets

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

Ajout d’émotions sur des objets – suite 5

Suite des articles sur l’Ajout d’émotions sur des objets et suites 1 2 3 4, et Liens d’émotions.

Les émotions sont une façon de marque un objet avec les sentiments qu’il inspire à un être humain. Les émotions sont plutôt subjectives là où les avis sont beaucoup plus objectifs. L’intensité que l’on peut donner à une émotion est toujours strictement positive, le sens positif ou négatif est déjà porté par l’émotion elle-même.

Les émotions étaient fonctionnelles sur les objets dans la version 2014 de sylabe. Mais le code ayant été entièrement repris en php orienté objet elles n’avaient pas encore été ré-implémentées. Le nécessaire est en cours de remise en place directement dans la librairie afin que les émotions sur les objets soient utilisables dans toutes les applications.

Les avis ne sont pas maintenus.

En parallèle, la réflexion à long terme continue sur la pondération des objets en vue de leur suppression automatique au bout d’une certain temps. C’est la fonction d’oublie. Il faut que cette pondération soit aisée à utiliser, et surtout qu’elle ait du sens pour que l’utilisateur prenne le temps de le faire. Il est clair qu’un champs de quantification de l’importance d’un objet est difficile à appréhender et ne sera pas utilisé. La gestion des émotions devient en fait la solution évidente de pondération. De plus, la pondération d’un objet, qui représente en fait son importance, peut influencer et être influencée par l’importance des objets qui lui sont liés.
Sans pondération, la gestion de l’oublie sera chaotique et peu fiable, donc pas utilisée.

La facilité d’usage et la pertinence de la solution de gestion des émotions et leurs pondérations sont donc déterminantes pour leur adoption et leur utilisation mais aussi plus tard pour la gestion de l’oublie.

Il y a plusieurs façons d’aborder la pondération avec les émotions. Continuer la lecture de Ajout d’émotions sur des objets – suite 5

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.