Catégorie : oubli

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 ?

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.

PFS sans connexion

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

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…

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

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…

Gestion temporelle partielle

Il y a deux façons de gérer le temps et deux façons pour le prendre en compte.

C’est la suite des articles Horodatage, ISO 8601, suite et Marque de temps.

La référence de temps, ou pas

On peut gérer le temps comme étant un prérequis commun à tous les acteurs. Dans ce cas, toutes les machines doivent synchroniser leurs horloges internes sur une source commune. Tout le monde travaille avec la même heure, le même espace temps et la même référence. Ici on ne tient pas compte du fuseau horaire qui est un bricolage de décalage non pas temporel mais sur l’affichage uniquement. Aujourd’hui, l’orientation de tous les systèmes d’informations, c’est la synchronisation globale, c’est à dire la même partout sur la planète.
On pourrait aussi simplement considérer que chaque machine, chaque utilisateur, a un espace temps qui lui est propre. Pas de synchronisations à faire mais se pose alors l’interprétation d’une date donnée par une autre machine. Il faut prévoir un mécanisme de correction du temps des autres machines, par rapport à une référence. On retrouve cette référence commune mais elle peut dans certains cas être soi-même, c’est à dire je suis à la bonne heure et je compense l’heure des autres. En cas d’absence de référence externe, il faut retenir le décalage de chacune des machines avec lesquelles on communique.
Avoir une référence commune implique une communication régulière avec cette référence. Il faut donc une connexion réseau, même partielle. Plus la précision attendue dans la synchronisation est forte, plus les moyens tant en réseau qu’en relais doivent être importants, rapides et fiables. Sur des réseaux isolés ou fortement fragmentés, la synchronisation du temps devient illusoire. Et cela peut arriver partout sur la planète : catastrophe naturelle, guerre, dictature, repli sur elles-même des nations, etc…

Le problème sur la référence de temps n’est pas que théorique. Ce ne serait pas « juste un problème d’affichage ». Beaucoup de protocoles de sécurisation s’appuient aujourd’hui sur le temps et exigent un horodatage assez précis. Lorsque l’on se connecte au site web de sa banque, lorsque l’on renvoie un message signé, lorsque l’on se connecte à un réseau d’entreprise, les jetons de session et autres certificats électroniques ont une durée de vie limitée ou une date d’expiration. Tous ces services impliquent d’avoir un réseau pour fonctionner et peuvent délivrer une référence de temps en même temps que ces services. Par contre, des documents comme les passeports sont aussi émis avec une date d’expiration et il serait difficile de vérifier leur validité sans une référence de temps commune.

Le système de gestion du temps dans nebule est encore aujourd’hui basé sur l’horloge interne de la machine qui exploite les liens. Il utilisera aussi l’entité kronos comme référence. Mais il est prévu de calculer et mémoriser les décalages de temps entre machines. Cette capacité à mémoriser les variations de temps rend l’ensemble plus résilient en cas de catastrophe ou tout simplement de fragmentation volontaire des réseaux. A faire…

Sur un réseau maillé comme sur Internet, la structure globale ressemble à un fractal dans lequel on peut zoomer et retrouver les mêmes formes de connexions entre nÅ“uds de réseau. Un réseau Internet fragmenté serait sûrement toujours maillé et toujours interconnecté, mais la structure globale ressemblerait plutôt à une nébuleuse, c’est à dire sans structure marquée. Dans ce deuxième cas, les synchronisations de temps seraient souvent conflictuelles.
Le postulat que l’on peut simplement synchroniser tout le monde sur une seule et unique référence de temps est une facilité de notre époque. Mais c’est une facilité qui n’est ni évidente ni définitivement acquise.

Prise en compte des événements futurs, ou pas

Avec synchronisation du temps entre les machines ou pas, il peut arriver d’une marque de temps soit dans le futur ou interprétée comme telle. Que fait-on dans ce cas ? Est-ce une erreur de l’émetteur ? Est-ce une erreur de synchronisation ? Est-ce une erreur de zone de temps ? Est-ce un acte malveillant ?
Et c’est pareil pour une date du passé qui ne correspond manifestement pas à l’ère informatique. Est-ce une erreur de référence de temps ?

On peut tenir compte d’une marque de temps problématique et l’interpréter telle quelle vis-à-vis des autres date. Dans le cas d’une suppression de lien marqué dans le futur, cette suppression est valable. Mais, parce qu’elle est dans un futur un peu lointain, il va devenir impossible de réhabiliter ce lien avant cette date puisque sa suppression sera toujours valide temporellement. Il faudrait un nouveau lien plus loin dans le futur qui, lui, empêcherait la suppression avant cette nouvelle date dans le futur… On ne s’en sort pas.

On peut ne pas tenir compte d’une marque de temps invalide et l’écarter du traitement comme étant incohérente. Dans ce cas un lien de suppression dans le futur ne serait plus utilisé avant que notre espace temps ne soit arrivé effectivement à cette date.
Mais dans ce cas la synchronisation de temps ou l’utilisation d’une référence de temps a beaucoup plus d’importance puisque des dates du calendrier arabe, hébraïque, indien, chinois ou copte n’ont pas la même signification. Des événements interprétés comme étant dans le futur seront automatiquement ignorés alors qu’ils sont peut-être valides.

La non prise en compte de liens avec une date dans le futur semble la meilleur solution, mais elle n’est pas encore implémentée dans nebule. A faire…
L’implémentation doit aussi permettre de gérer sereinement les décalages, prévisibles, du temps entre différentes machines même si elles ont la même référence de temps. En dessous de la seconde, une synchronisation globale est illusoire. Avec une connexion à Internet intermittente, une précision de l’ordre de la minute est plausible. Il faut donc prévoir un paramètre afin de définir le décalage maximal de temps que l’on accepte pour des liens dans le futur.

L’utilisation de la norme ISO8601 est indispensable mais pas suffisante. Tous les calendriers n’utilisent pas cette forme et bien sûr n’ont pas la même référence de temps. De plus, si il permet une grande précision, il ne permet pas de manipuler le temps sur ce que l’on appelle le temps long. Il serait intéressant de pouvoir manipuler d’autres calendriers, peut-être avec un préfixe spécifique.

Lien juste à temps

Les liens de nebule n’ont pas vocation à permettre un traitement complexe des données, juste à permettre leur transmission et faciliter le traitement.

Manipuler des données avec des échéances n’est possible qu’en associant un objet contenant une date avec un objet méta spécifique. Le traitement à échéance est réalisé par le programme qui interprète cette forme de lien. Il est facile de réaliser au niveau des liens d’une prise en compte « Ã  retardement » d’un lien. Le modèle pourrait être l’encapsulation d’un lien dans un autre lien d’un type particulier, sur le modèle du lien offusqué. Au lien d’une clé de chiffrement, ce pourrait être une date de prise en compte.
Ce nouveau type de lien est de fait en concurrence avec un lien avec une date dans le futur. Mais cela présenterait quand même quelques avantages. Le premier, c’est que la date pourrait être aussi une période de prise en compte. Mais surtout, là où un lien dans le futur pourrait être supprimé parce que considéré invalide, un lien dédié à cet usage serait beaucoup plus légitime.

Cette idée est encore à réfléchir…

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

Liens d’émotions

La mise en place des émotions sur les objets appelle plusieurs questions.

Catégories

Vu le nombre d’émotions gérées, il va devenir nécessaire de les segmenter en catégories. On peut maintenir la catégorie ‘émotions‘ qui regroupe tout ressentit humain, plutôt subjectif. On peut ajouter une nouvelle catégorie ‘avis‘ pour tout ce qui est plus objectif.

Pondération

Une réflexion qui commence à dater un peu sera la mise en place d’une pondération aux objets. Cette réflexion concerne avant tout la possibilité d’oublier progressivement dans le temps les objets avec le moins d’importance. L’oublie peut être réalisé automatiquement à partir d’un certain seuil. Le seuil peut progressivement augmenter dans le temps jusqu’à un seuil maximum au dessus duquel les objets concernés seront conservés, sauf suppression volontaire.

Cette pondération peut être bien sûr utilisable en permanence pour trier l’affichage des objets.

La mise en place des émotions est le bon moment pour introduire la mise en place de la pondération. Il ne reste plus qu’à en définir les modalités.

Chiffrement

Une autre réflexion qui date un peu mais prend progressivement de l’importance, c’est la possibilité de chiffrer les liens. Le but est d’offusquer que l’on ne souhaite pas rendre publics tout en permettant leur bonne transmission aux destinataires légitimes.
Il y a plusieurs manières d’offusquer les liens :

  1. La première est de créer un objet de liens, objets que l’on chiffre ensuite vers son destinataire. Cette méthode, si elle est assez bonne en terme de performance de déchiffrement, nécessite cependant que tous les liens offusqués soient consultés en même temps que tout les liens normaux d’un quelconque objet, pour savoir si un lien secret ne le concerne pas spécifiquement. On obtient de fait un ou plusieurs objets de liens chiffrés attachés à son entité. L’inconvénient, c’est qu’il est impossible de transmettre un lien particulier à une autre entité sans devoir recréer un nouvel objet de liens chiffré.
  2. La seconde méthode est de faire du chiffrement de lien à la volée. C’est à dire qu’un lien a offusquer est chiffré et reste présent individuellement au milieu des autres liens. Cependant, ce lien va contenir un partie chiffrée, partie qui ne correspond donc pas à un objet réel, ce qui est en contradiction avec la forme actuelle des liens. L’avantage, les liens chiffrés voyagent naturellement avec les autres liens. L’inconvénient, le lien chiffré ne peut être rattaché qu’à un seul objet et à une entité. Le lien avant chiffrement fait référence à trois objets, on perd donc avec le lien chiffré la référence aux deux autres objets. Cela veut dire que le lien chiffré est valable si on consulte l’objet source, mais n’est plus reconnu si on consulte l’objet destination. Cet inconvénient risque de perturber la résolution inverse d’un arbre de mise à jour par exemple.
  3. La troisième méthode est d’exporter la partie chiffrée dans un objet en tant que tel. Cette méthode a l’avantage de profiter du mécanisme de chiffrement déjà implémenté pour les objets. Liens et objets sont transmis naturellement vers un destinataire du lien. Et on retrouve l’inconvénient de la deuxième méthode. En plus, on complexifie l’analyse des liens d’un objet puisqu’il faut aller consulter d’autres objets pendant le processus de lecture des liens, et donc d’autres liens…

La mise en place du chiffrement des liens va créer de fait une nouvelle version de nebule, la v1.2.

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.

Le paradoxe du droit à l’oubli

La fonction d’oubli en cours de réflexion dans nebule prévoit bien quelque chose d’équivalent à ce qui est en cours de réflexion au niveau du gouvernement français. Mais le texte de loi qui en résultera sera sans doute contraignant dans la mise en application effective de l’oubli, c’est à dire la suppression de données. le projet nebule, de son côté propose une suppression volontaire.

Il est tout à faire compréhensible que certaines personnes puissent souhaiter supprimer des données les concernant sur internet, c’est à dire publiques. Mais cette suppression ne doit être faite que si elle porte atteinte à cette personne, sinon cela porte atteinte au droit de mémoire de tout le monde. De plus, la théorie nous montre qu’il est illusoire de vouloir espérer une suppression complète de données. On ne peut que demander la suppression. La loi ne peut que gérer les conflits sur la mauvaise utilisation des données par autrui.

C’est même un paradoxe que de vouloir définitivement oublier une information définie. Pour cela, il faut prévoir de transmettre l’information de suppression de l’information définie à ceux qui détiennent cette information définie.
Et si quelqu’un remet en ligne plus tard la même information définie comme ayant été supprimée. Que va-t-il se passer ?
On doit donc garder l’information de suppression… qui fait référence voir contient l’information définie à supprimer. Donc cette information définie ne peut être supprimée.

CF : www.pcinpact.com droit-a-oubli-acteurs-web-2-0-degomment-consultation-cnil

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.

Messagerie social

Les objets que l’on échange, y compris les textes, sont perdus dans l’océan des objets dont nous disposons.

Que devient un message ou un objet transmit comme message?

Il est naturellement ajouté aux autres objets. Mais en plus, il a un lien signé par une autre entité, donc on peut considérer que cet objet est aussi lié à cette entité.

Ce lien implicite à une entité fait que cet objet a une visibilité par cette entité, en l’analysant on verra cet objet.

Poussons encore plus loin, et si on analyse tous les liens vers des objets que publie cette entité, que voit-on ?
On va voir dans l’ordre chronologique tout ce qu’elle a jugé intéressant à garder, les objets qu’elle a créé, tous les objets sur lesquelles elle est intervenu, les messages que l’on a échangé avec elle, etc…
Les messages (objets échangés) ne sont visibles que si ils sont publics, ou si ils sont chiffrés et que l’on est destinataire.

Cette vue, ce comportement, c’est presque celui des réseaux sociaux!

Horodatage

Le marquage du temps est un élément primordial dans l’échange d’informations.

Un lien créé vers un objet doit contenir une marque de temps de cette création. Cet horodatage ne semble pas utile au première abord, mais il est nécessaire si l’on veut ensuite pouvoir casser ce lien.

Une information, et donc un lien, doit être considéré comme non effaçable une fois créé. Cette information ayant été à priori diffusée, on en perd le contrôle, et donc la capacité de suppression. A défaut d’être effacé, cette information doit être désactivable. Dans le cas du lien, on le désactive aussi. Cette désactivation sera à son tour diffusée, et de la même façon on en perdra le contrôle.

La création d’un lien doit être vue comme la création de l’objet lien doublé d’une opération de signature cryptographique de ce même objet lien. L’entité validant ainsi le lien de façon forte, sa désactivation doit aussi être faite par une méthode forte, c’est à dire doublée d’une opération de signature cryptographique (par le même signataire en fait).

La désactivation doit aussi être horodaté, pour deux raisons. La première pour simplement savoir quand elle a été faite. La deuxième pour que l’on puisse sans ambiguïté savoir si cette désactivation intervient bien après la création. Et ainsi de suite, le lien ou toute information peut être validé et invalidé plusieurs fois de suite dans le temps.

Le marqueur de temps doit être couvert par la signature. Il doit être systématiquement présent avec la signature.

Référence de temps

Nous avons besoin aujourd’hui de tous avoir le même espace de temps pour pouvoir communiquer et travailler ensemble. Cette état de fait pose déjà le problème de la référence de temps, nous devons avoir la même heure.

Mais cette nécessité de tous travailler avec la même heure se heurte aux grandes distances et les décalages horaires que cela implique bien que les communications n’en soient que peu affectées.

Et comment fait-on si, indépendamment du décalage horaire, deux entités décident volontairement de ne pas travailler avec la même référence de temps? Et si en plus l’unité de temps est différente?

Une première approximation de ce que à quoi on peut s’attendre se pose sous la forme d’une équation du premier degré :

Tv = a Ti + b

Le temps vu Tv est calculé par rapport au temps interne Ti affecté d’un coefficient a et corrigé par un décalage b.

Dans la vraie vie, il faut beaucoup d’efforts pour approcher une synchronisation parfaite entre deux entités. A l’échelle d’un pays, c’est impossible, on se contente de quelques secondes voir quelques minutes de décalage horaire entre toutes les entités. Et chaque horloge interne souffrant d’une dérive plus ou moins grande, il faut régulièrement calculer et compenser cette dérive. Même tous d’accord, nous avons bien notre coefficient a et notre décalage b.

Et encore, on considère là que l’horloge interne de chaque entité est stable dans le temps…

Marqueur de temps

On peut continuer à essayer d’être tous calés sur la même référence de temps. Ou on peut prendre le problème en sens inverse, prendre en compte que chacun a son heure de fonctionnement propre, et calculer quand nécessaire la correction du datage des objets.

Il faut cependant dans ce cas qu’un ou plusieurs liens existent entre les différentes entités, liens qui permettent de calculer de décalage de temps. C’est le rôle du marqueur de temps qui date et signe un objet généré par une entité, objet qui contient sa date de création. Ou du marqueur de temps qui génère régulièrement des objets horodatés que toutes entité peut dater/signer.

Cette méthode nécessite cependant une certaine coopération entre les deux entités. Il y a peut-être moyen de disposer d’une méthode proche par signatures d’objets communs et qui marcherait même en mode non coopératif.

La suite au prochain épisode…

Repérage chronologique

Comment retrouver rapidement les objets récemment créés?

La méthode habituelle, la première à laquelle on pense, c’est de parcourir l’intégralité des objets afin de vérifier le(s)quel(s) sont récents.

Oui mais… Continuer la lecture de Repérage chronologique

Mémoire fini

On part souvent du principe que l’on va gérer nos données en les accumulant dans le temps de façon infinie…

Mais est-ce vrai?

C’est en partie vrai.

Les capacités de stockage évoluent assez rapidement dans le temps. Nous enregistrons de nouveaux fichiers assez régulièrement dans le temps mais pas forcément de façon continu. Ici, pour la réflexion, on ne va retenir qu’une moyenne constante d’enregistrement de données.

Que se passe-t-il si on ajoute régulièrement suffisamment de capacités de stockage, suffisamment pour ne jamais arriver à saturation?
Tout se passe bien, on ne perd rien.

Et si la capacité de stockage n’augmente pas assez vite (dans le cas extrême où elle ne peut plus être augmentée) ?
C’est dans ce cas que doit être prévu un mécanisme de nettoyage (d’oubli), et donc de pertes maîtrisées.

Le stockage de données sous la forme proposée pour nebule risque dans certains cas de générer, et donc de stocker, énormément de données. On doit prévoir ce mécanisme d’oubli nativement.

La perte d’information maîtrisée impose de permettre cette gestion à la main. Mais quelle efficacité d’une gestion à la main pour plusieurs millions de fichiers?
Des mécanismes d’assistance ou d’automatisation doivent être proposés. Ils peuvent avoir plusieurs formes.

Sur quels critères déclarer un fichier périmé?
Plusieurs critères peuvent être pris en compte, et plusieurs combinaisons complexes peuvent être calculées de critères simples :
– le temps de possession de l’objet, plus il est vieux plus il a de chance d’être périmé ;
– si le fichier dispose d’une nouvelle version, il n’est peut-être plus intéressant de le conserver ;
– l’attractivité, ou un critère d’appréciation, donne de l’importance à un fichier dans le temps et doit faciliter sa conservation ;
– l’intensité de l’appréciation peut être exploitée en absolu, un fichier qui appel un très fort sentiment positif ou négatif a des chances de devoir être conservé longtemps ;
– un fichier lié à plusieurs autre fichiers jugés importants a surement besoin d’être lui aussi conservé, il va peut-être hériter par calcul d’une note d’appréciation ;
– d’autres fichiers font références à ce fichier, il faut sûrement le conserver ;
Рmes amis ont gard̩ ce fichier, il doit ̻tre important.

Doit-on supprimer immédiatement un fichier périmé?
Celui-ci peut peut-être servir à quelqu’un d’autre? A-t-on la place de le garder en attendant? Peut-on se contenter de le supprimer lorsque l’on aura besoin de la place qu’il occupe? Doit-on les marquer périmés en attendant ou gérer une liste des objets périmés?
L’analyse des fichiers à marquer peut se faire en continu, moyennant une occupation constant et relativement importante de ressources. L’analyse peut se faire lors d’une phase de repos (activité de sommeil). Une liste peut aussi être maintenu en temps réel sans analyse, juste en classant les objets de façon croissante dans une liste et en faisant évoluer la place des objets en fonction de l’évolution de leurs paramètres.

Une fois un objet marqué comme périmé, comme propager son marquage? C’est à dire, comment vont se comporter les relais avec ces objets dits périmés?
Cette propriété de péremption doit-elle être visible des entités tierces? Ou est-elle purement interne?