Graphe des entités autorités

Afin d’organiser une certaine intendance autour de la diffusion du code des applications, un certain nombre d’entités sont nécessaires.

Le modèle utilisé est assez classique est simple, c’est un schéma de parenté. Il peut être amené à évoluer dans le futur.

La structure du graphe reconnue est la suivant :

  • Le maître du tout (puppetmaster)
    • Les autorités de la sécurité
    • Les autorités du code
    • Les autorités du temps
    • Les autorités de l’annuaire

Une évolution est en cours d’intégration avec la nouvelle version des liens. Si l’entité qui chapeaute toutes les autres est unique, chaque groupe d’autorités n’est plus seulement une entité mais devient un groupe d’entités à pouvoir identique.

Il est à prévoir que le maître du tout deviendra aussi, un jour, des autorités globales. Mais la forme n’est pas encore défini.

Chaque entité ici considérée doit être un objet entité EID (Entity ID) valide avec lien de type, un lien de nommage et un lien de localisation (URL web).

D’un point de vue sémantique, on quitte progressivement la notion de maître historique pour aller vers la notion d’autorité. Outre le rapport à l’esclavage, on est soumis au maître, on se soumet à l’autorité.

Le puppetmaster est un EID qui peut être remplacé. Il va faire référence par des liens dédiés vers les différents d’autorités au moyen de RID dédiés :

  • Autorités de la sécurité
    • a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288
  • Autorités du code
    • 2b9dd679451eaca14a50e7a65352f959fc3ad55efc572dcd009c526bc01ab3fe304d8e69.none.288
  • Autorités du temps
    • bab7966fd5b483f9556ac34e4fac9f778d0014149f196236064931378785d81cae5e7a6e.none.288
  • Autorités de l’annuaire
    • 50e1d0348892e7b8a555301983bccdb8a07871843ed8f392d539d3d90f37ea8c2a54d72a.none.288

C’est à dire que tout EID désigné par un de ces RID (l>RID>EID), et signé par le puppetmaster, devient une autorité dans le groupe considéré.

Périmètre fonctionnel bootstrap – libpp

Jusque là le bootstrap intégrait une bibliothèque PHP procédurale (libpp) de nebule héritée et remaniée avec le temps mais ayant gardée tout ce qui était fonctionnel.

Or pour le bootstrap certaines fonctionnalités n’ont pas d’utilisé. Et comme il va falloir réécrire et revoir en grande partie cette bibliothèque, c’est le bon moment pour la simplifier. Et on va commencer par supprimer les parties sans utilité.

Au niveau cryptographie, seul la génération et la vérification des liens est utile. Le chiffrement d’objets n’a pas de raison d’être présent. La dissimulation de liens n’a pour l’instant pas d’utilité non plus.

La gestion des attributs d’objets n’a pas d’utilité mais il faut garder la capacité à suivre les mises à jours d’un objet et être capable d’aller chercher des mises à jour. Mais afin de réduire la complexité, seul le HTML sera utilisable.

Les liens supportés seront mono-registre et mono-cœur.

Le travail fait avant par la bibliothèque de nebule en bash permettait de générer un nouveau puppetmaster. Cela va devenir une nouvelle fonction dans le périmètre du bootstrap, et donc de la libpp. Il faut donc conserver la capacité de générer de nouvelles entités et de générer des liens.

Une autre partie qui va être intégrée au bootstrap, c’est la possibilité de faire les mises à jours des applications. Il faut donc que le bootstrap soit capable de parler avec le reste du monde. Seul le HTTP sera pris en compte pour ça. Et cela concerne aussi les entités.

Tout le reste fera partie de la bibliothèque en PHP orienté objet (libpoo).

Réorganisation des entités spéciales – gestion

Suite des articles Réorganisation des entités spéciales – inventaire de départ. et groupes d’entités.

L’application option permet aujourd’hui d’afficher les autorités globales et locales. Cette interface avec l’instance nebule du serveur doit être le seul point de gestion de ces entités et de leurs rôles. Cette application va donc devoir évoluer pour prendre en compte les évolutions des entités spéciales, et pas seulement les afficher.

Réorganisation des entités spéciales – groupes d’entités

Suite de l’article Réorganisation des entités spéciales – inventaire de départ.

Le regroupement d’entités par rôle correspond à la création d’un groupe d’entités, groupe auquel on va donner le rôle. Il va être possible avec le groupe de définir de nouveaux filtres sociaux de tri des liens. Ces filtres viendront remplacer un filtre historique, restricted, qui a un rôle important mais dont le nom devient ambiguë.
Par exemple, à l’entité maître du code bachue il sera possible d’adjoindre d’autres entités pour valider du code. Cela permet de recréer l’équivalent de l’ajout de plusieurs dépôts logiciels différents. Il est même envisageable pour une entité de désactiver bachue spécifiquement du groupe.

L’entité locale de l’instance va aussi avoir des droits plus étendus. Elle pourra être, via des options, équivalente à toutes les autorités globales, y compris le maître du tout (puppetmaster). Bien sûr ces droits ne seront valables que sur l’instance de serveur qui lui est rattachée… et toute entité qui décidera de l’ajouter dans un groupe de droits.

Blockchain et nebule – Le cas de la messagerie

Suite de l’article Blockchain et nebule.

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

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

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

Réorganisation des entités spéciales – inventaire de départ

L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.

Le bestiaire

Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.

L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.

L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.

L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.

Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.

Les rôles

On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.

Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.

La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…

L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.

La réflexion continue…

Bugg d’affichage des autorités globales dans option

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

bootstrap – Mise en ligne

Une nouvelle 020170508 version du bootstrap est mise en ligne.

Le développement continue sur l’application option avec sa séparation de la gestion des autorités globales et locales.

La réflexion est toujours en cours sur l’avenir des autorités globales mais les autorités locales vont sûrement être scindées en plusieurs rôles sous des dénominations différentes.

Pas d’installateur complet pour cette fois, les deux applications sylabe et klicty sont mise à jour.

Le code est disponible ici :

94373583d31df5241fdf19de50be0e65fb6f65387188866818aebadd5a7217c5

Entités de recouvrement – implémentation

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

bootstrap – Désactivation des applications par défaut

Le bootstrap sait maintenant gérer les applications activées. Ça se passe à deux niveaux.

  1. L’application 0 de sélection des applications n’affiche que les applications activées.
  2. Le moteur de sélection de l’application à afficher ne permet pas de sélectionner une application si elle n’est pas activée.

L’activation d’une application se fait sur trois critères :

  1. C’est l’application par défaut définit par l’option defaultApplication, elle est par défaut activée et non désactivable.
  2. C’est une des applications en liste blanche. La liste blanche est une constante définie dans le bootstrap et dans la bibliothèque. Elleet non désactivable.
  3. L’entité instance du serveur a activé explicitement l’application par un lien.

L’entité maître du code bachue ne peut pas activer une application sauf à modifier les constantes dans le code.

Une application peut être activée/désactivée via l’application option, la seule application aujourd’hui en liste blanche. Il faut aller dans la partie des applications et il faut être connecté avec l’instance entité du serveur.

020161127 shot-2016-11-27_18-52-59

Le lien d’activation d’une application a la forme :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence d’activation = e0e9ce893ea87b91f6e276b3839fed99f050168a0eb986354adc63abb3d7335c
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

La désactivation est un lien de type x.

bootstrap – Avec ou sans pré-chargement des applications

Le pré-chargement des applications par le bootstrap va permettre d’améliorer l’expérience utilisateur lors du premier chargement d’une application. Même si les applications n’ont pas encore été optimisées pour en profiter pleinement, c’est déjà fonctionnel et efficace.

Par contre, comme énoncé dans l’article pré-chargement des applications – indexation, certaines applications n’ont pas forcément un intérêt à être pré-chargées.
C’est le cas de l’application defolt qui se charge très vite et dont la page de pré-chargement n’apporte rien, voir casse un peu le principe de la page par défaut.
Et c’est aussi le cas de l’application upload qui charge vite mais qui peut à l’avenir permettre la synchronisation d’objets et de liens entre serveurs. Hors le passage par une page intermédiaire oblige le serveur distant à gérer le cookie de connexion avant de pouvoir envoyer des données.

La dernière version du bootstrap, qui va être bientôt publiée, reconnaît maintenant un lien pour désactiver le pré-chargement d’une application. Le comportement par défaut reste de pré-charger une application. Chaque application pourra, sur initiative du maître du code bachue ou d’une autorité locale, ne plus être pré-chargée.

Le lien de non pré-chargement a la forme :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence de non pré-chargement = 9d019716a5335ee1f3bad59cbb9cc93132b0726129b26b52d6441a66c7c59a8d
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

De plus, le problème de dépassement de mémoire est résolu. Il vient d’une pré-allocation de mémoire de la fonction file_get_content qui se fait parfois sur la totalité de l’argument $maxlen alors que le contenu réel est dérisoire… et qui ne libère pas cette mémoire en fin de fonction.

Enfin, la métrologie a été aussi grandement renforcée. L’avenir dira si cela a un impact négligeable sur les performances ou pas. En fin de bootstrap, les logs contiennent une trace de la mémoire maximum utilisée ainsi que les objets et liens lus et vérifiés :

Nov 27 12:21:36 bachue bootstrap/81bd1a52600b: 0.64311790466309 Mp=9698504 Lr=2720+4 Lv=355+4 Or=361+0 Ov=8+0

Avancement du bootstrap

Une nouvelle version du code du bootstrap en php procédurale est diffusée :

6c902d8c29b965fde6d576ef04e5405c84b1353d01715c4fb96e561ba76e9114

Comme d’habitude, l’identifiant est sont empreinte sha256. C’est le seul code qui ne peut pas être signé.

Sauf problème de dernière minute lors des tests sur Internet, cette version est fonctionnelle et complète.

Il manque par contre les liens signés du maître du code bachue pour désigner la bibliothèque et les applications. Les différentes applications se lancent sauf sylabe qui coince sur un de ses modules. Lorsque l’ensemble sera à peut près stable, le tout sera mis en ligne.

Du fait des grands changements dans la gestion des arguments en ligne et des applications, les applications actuellement en ligne sur Internet ne sont plus compatibles avec le nouveau bootstrap.

Mode de récupération

Un mode de récupération était déjà plus ou moins bien implémenté. Il a été repris à l’occasion de la ré-écriture du bootstrap et il a notamment été corrigé dans la librairie nebule.

L’activation de ce mode de récupération empêche simplement l’entité instance du serveur et l’entité par défaut de devenir autorités locales. C’est à dire que les options qui leur permettent de devenir autorités locales ne sont plus pris en compte.
Le fait d’être autorité locale permet de générer des liens, qui seront réellement reconnus, pour faire des mises à jours de la librairie et des applications au même titre que le maître du code bachue. C’est comme cela que l’on peut travailler le code signé sans avoir recours en permanence au maître du code. Et c’est aussi comme cela que l’on peut mettre en place sa propre application sans qu’elle soit signée du maître du code.

L’activation peut se faire via les arguments de l’URL en ajoutant rescue si l’option permitOnlineRescue est à true.
En cas de besoin, option modeRescue permet à true d’activer et de forcer le mode de récupération sans tenir compte de l’option permitOnlineRescue.

Reprise du bootstrap en programmation procédurale

Depuis une semaine, le code du bootstrap en PHP procédural est en cours de refonte complète. La base utilisée était assez ancienne, elle datait d’avant le passage à la programmation orientée objet.

Ce travail correspond presque à une ré-écriture de zéro du bootstrap. L’inconvénient de cette version c’est qu’il sera pls difficile d’utiliser la librairie nebule sur autre chose qu’un système de fichier, par exemple une base de données. Mais le gros avantage c’est que la maintenance de la librairie est fortement simplifiée par rapport à sa version orientée objet. En effet le bootstrap nécessite quelques ajustements et notamment la désactivation de certaines fonctionnalitées. Ce serait trop compliqué de garder deux librairies orientées objets en parrallèle.

Cette nouvelle version introduit cependant quelques nouveautées :

  • Le changement de puppetmaster est complètement fonctionnel.
  • La version de librairie utilisée avec une application est mémorisée pour cette application (le temps de la session PHP) jusqu’à demande d’activation des mises à jours ou fermeture de la session par l’utilisateur.
  • En plus de l’instance de l’applicaiton proprement dite, on mémorise aussi dans la session PHP les instances des classes d’affichage Display, d’action Action et de traduction Translate pour gagner en performance.

La page du bootstrap est en cours de mise à jour pour suivre cette évolution.

C’est cette version qui sera désormés utilisé pour les nouvelles versions des applications.

Nouvelles applications

En plus de messae qui est une application standard à destination des utilisateurs, il y a maintenant 3 autres applications qui sont cette fois plutôt destinées au côté technique de nebule.

Les nouvelles applications :

  • defolt : Application d’affichage par défaut pour les serveurs sans applications interactives.
  • upload : Application de chargement de liens pré-signés du maître du code exclusivement.
  • option : Application de visualisation et gestion des options de configuration, des applications, des entités de recouvrement et entités autorités locales.

Le bootstrap évolue aussi. Une version en php procédurale est reprise en concurrence de la version php orienté objet. Continue reading Nouvelles applications

Ajustement des noms de domaines

Tous les noms de domaines liés aux entités de nebule ont été revus. Le puppetmaster est toujours l’entité autorité racine sous laquelle on trouve maintenant les rôles :

  1. security.master.nebule.org
  2. code.master.nebule.org
  3. directory.master.nebule.org
  4. time.master.nebule.org

Chaque nom de domaine correspondant à un rôle est renvoyé vers une entité déterminée, à savoir aujourd’hui dans l’ordre :

  1. cerberus.nebule.org
  2. bachue.nebule.org
  3. asabiyya.nebule.org
  4. kronos.nebule.org

L’idée, c’est que en cas de problème une entité peut être remplacée par une nouvelle. Et c’est pareil dans le code de la librairie nebule en php.

Les adresses en IPv6 ne sont plus fonctionnelles, mais ça reviendra.

Auto-installation depuis le bootstrap

Le bootstrap est en cours de modification pour pouvoir être posé tout seul sur un nouveau serveur. Il crée dans ce cas l’environnement nécessaire à son fonctionnement et télécharge ce qui manque.

Le but est ici de simplifier au maximum l’installation. Il restera ensuite à changer l’application par défaut, mais c’est un autre problème…

20150926 nebule_bootstrap_-_2015-09-27_00.43.11
Le bootstrap en cours de création de son environnement de travail.

Il reste à faire la partie qui génère une nouvelle entité pour l’instance locale. Par défaut c’est le puppetmaster, mais il n’y a pas de raison que ce soit lui partout. Avec la génération de cette entité, il sera affiché le mot de passe pour que son propriétaire puisse se l’approprier.

Liens marqués entre le puppetmaster et les autres entités

Il y a quelques jours, le puppetmaster a été réveillé pour générer de nouveaux liens. De nouveaux objets de nebule sont maintenant reconnus comme des objets à usage réservé :

  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps

Et il permettent de désigner via un lien de type f les différentes entités qui ont les rôles correspondants.

Le code de la librairie nebule en php et le bootstrap s’en servent désormais pour retrouver les entités avec ces rôles.

CF : sylabe – Avancement

Description de la création d’une nouvelle entité.

La ré-implémentation de la génération d’une nouvelle entité est en cours dans sylabe.

Une nouvelle partie apparaît dans la documentation de référence sur la création d’une entité : Wiki – Documentation nebule v1.2 – Création d’une entité

On y trouve la procédure de référence à implémenter et notamment tout ce qui concerne la manipulation des clés cryptographiques asymétriques et mots de passes.

Changement d’identifiant d’entité

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

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

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

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

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

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