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.

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.

Revers Polish Notation

Le mécanisme décrit dans l’article Copier/coller et marquage pourrait être avantageusement réutilisé par un module d’application afin de mettre en place une pile. Cette pile pourrait ensuite être manipulée via un langage de type Revers Polish Notation (RPN ou RPL). En plus des opérations de base de manipulation de la pile, d’autres opérations pourraient être ajoutées par l’application ou par chaque modules présents. Par exemple le module de gestion des liens pourrait ajouter des opérations sur les liens dont la copie d’un lien (pile niveau 1) en remplaçant le hash source du lien par un nouvel objet (pile niveau 2). Etc…

Copier/coller et marquage

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.

php, gd et mbstring

Pour une installation sous Linux, ne pas oublier les paquets php-gd et php-mbstring permettant d’avoir accès aux fonctions de modification graphique et à mbstring qui va notamment convertir les textes en utf-8.

C’est utilisé par la bibliothèque nebule procédurale incluse dans le bootstrap. Donc si pas de mbstring disponible, ça plante dès le début…

Les documentations sont déjà à jour :

Sous FreeBSD et OpenBSD, il faut compiler php avec gd et mdstring, ou l’installer via les portages avec ces dépendances. Bon… ça fait un moment que le code n’a pas été testé sur ces plateformes par manque de temps.

Debian 8 n’est pas concerné. C’est par défaut en dépendance de php.

L’idéal serait de pouvoir s’en passer pour simplifier l’installation… à voir…

Blockchain et nebule

C’est une première réflexion sur la blockchain et une implémentation avec les mécanismes de liens mis en place par nebule.

La, ou plutôt, les blockchains sont en plein essor et représentent non seulement un avenir proche pour échanger de l’argent mais aussi un avenir pour tout ce qui aujourd’hui nécessite un tiers de confiance. Les tiers de confiances peuvent être imposés ou choisis. Une blockchain permet de ne plus déprendre d’un tiers de confiance mais en conservant certains rôles remplis par un tiers de confiance. On ne se contente pas de remplacer le tiers de confiance, on sécurise même ses rôles en réduisant (voir supprimant) tous les abus de position dû à la place privilégiée du tiers de confiance.

La blockchain permet une validation globale et expose toutes les transactions à la vue de tous. Cette notion de globale implique en fait un réseau global : l’Internet.
Cette nécessité de la présence de l’Internet est potentiellement problématique. Rien ne permet d’affirmer que l’Internet survivra à moyen terme. Une fragmentation peut survenir brusquement. Et si l’Internet se retrouve fragmenté, il sera très difficile, sinon impossible, de le réunifier de nouveau. La gestion de l’information tel qu’elle est portée par nebule permet de survivre à un isolement des réseaux, l’ensemble est résilient à une fragmentation de l’Internet… même si ce ne sera pas aussi facile, rapide et fluide qu’aujourd’hui.

La blockchain permet de graver une information. L’information est une transaction financière, une transmission d’un bien réel ou virtuel. Cela veut dire une impossibilité d’annuler une opération, une transaction.
Avec nebule, les liens qui peuvent matérialiser une transaction peuvent être annulés soit par l’entité qui les émet, soit par soi-même. Si cette propriété de suppression de lien est problématique, il faudra définir un nouveau type de lien non annulable. Mais il est peut-être possible de trouver un processus présentant le même résultat tout en utilisant des liens annulables. Et il faut que celui-ci soit capable de fonctionner de façon globale tout en étant résilient à une fragmentation partielle ou forte du réseau.

Chargement de liens

Les applications génèrent par elles-même les liens dont elles ont besoin pour répondre aux usages des utilisateurs.

Il est possible de transmettre des liens qui ne peuvent être générés localement. C’est le cas des mises à jours d’applications.
Pour cela, il existe deux méthodes et deux moyens. Le code correspondant à été ré-écrit dans la bibliothèque nebule.

Pour qu’un lien soit traité, il faut que les trois soit validées :

  1. permitWrite : permet d’écrire des objets ou des liens.
  2. permitWriteLink : permet d’écrire des liens.
  3. permitUploadLink : permet de charger des liens.

Les deux méthodes sont :

  • le transfert d’un lien individuel ;
  • le transfert d’un fichier contenant (potentiellement) plusieurs liens.

Les deux moyens sont deux possibilités de transmettre les liens :

  • via l’application upload directement ;
  • via le module module_upload de l’application sylabe.

Lors du chargement d’un lien, quelque soit la méthode ou le moyen, le lien est d’abord vérifié structurellement.
Ensuite la vérification de la signature du lien et de son signataire répond à un processus plus complexe dépendant de deux options et de l’état de connexion d’une entité :

  1. permitPublicUploadLink : permet de charger des liens signés sans qu’une entité en cours ne soit déverrouillée, quelque soit le signataire.
  2. permitPublicUploadCodeMasterLink : permet de charger des liens signés par le maître du code (bachue) sans qu’une entité en cours ne soit déverrouillée.
  3. $this->_unlocked : variable qui donne l’état de déverrouillage de l’entité en cours d’utilisation, càd qu’une entité est connectée.

Si l’entité locale est déverrouillée, le transfert d’un lien devient une action légitime de l’entité. Tous les liens signés sont écrits si ils sont valides (structure et signature). Tous lien non signé est ré-écrit et signé par l’entité en cours; puis écrit.

Cette ré-écriture de lien est une ré-appropriation du lien. Est-ce que cette ré-appropriation peut poser problème ?

Bonne année 2018

Une nouvelle année signifie la mise à jour de toutes les dates à côté des licences… que ce soit dans les différents code mais aussi des sites web statiques et des blogs.

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Cette focalisation à temps plein sur l’évolution de l’interface est bénéfique à la qualité de l’affichage des applications et à leur utilisabilité. Mais elle est temporaire, pendant ce temps il n’y a de travail ni sur le fond ni sur la théorie et les problématiques spécifiques à nebule.

Références d’images

Afin d’accélérer la recherche d’une image à afficher dans une application, en fait en général des icônes, la recherche bascule de la résolution des graphes de mise à jour à l’utilisation de références. Comme définit dans l’article Propriété d’un objet et référence par rapport à un objet, une icône est définit par une référence unique. Cette référence permet de retrouver rapidement un objet. Le gain de temps de traitement est du même ordre que ce qui est décrit dans l’article Objet de référence contre suivi du graphe des mises à jours pour chaque icône, c’est à dire plusieurs fois dans l’affichage d’une page là où le bootstrap n’intervient qu’une seule fois.

Cela peut être utilisé aussi pour rechercher l’image de fond de l’interface même si ce n’est pas une icône.

Chaque icône dispose d’une référence unique, un objet sans contenu, dont l’identifiant n’est visiblement pas une empreinte d’objet.

L’implémentation est fonctionnelle dans la partie graphique de la bibliothèque nebule, reste à convertir toutes les applications et leurs modules…

Messages et protection

Une protection des messages basés les objets et liens de nebule peut être mise en place. Cette protection ne vise pas à dissimiler la présence d’un message mais à dissimuler son contenu. La dissimulation de la présence d’un message, plutôt nommée offuscation, est un autre sujet à part entière.

Mais cette protection peut ne pas être efficiente et elle peut se retrouver mise à mal du fait du fonctionnement même des liens de chiffrement (type k). Le lien de chiffrement va associer l’empreinte du message en clair avec l’empreinte du message chiffré. Hors un message de petite taille va avoir une forte probabilité avec le temps d’être (re-)créé par ailleurs et donc de dévoiler le contenu d’un message protégé. Et même pour un message plus conséquent, si il est partiellement ou complètement redécoupé en sous-objets via des liens de subdivision (type s), peut voir une partie de son contenu protégé dévoilé. La subdivision peut être par ailleurs légitime dans le cas d’un pré-découpage par mots pour la recherche sur mots clés.
La protection doit donc être adaptée dans le cas de la messagerie.

L’ajout d’un sel avant chiffrement ne résout pas le problème puisqu’il ne masque pas le lien entre le texte clair et chiffré. Par contre il est peut-être possible de pré-saler l’objet à chiffre et ne le reconnaître que sur son empreinte pré-salée.
A travailler…

Modification du thème du bootstrap

Le thème graphique du bootstrap se transforme un peu pour mieux coller à la nouvelle vision développée dans la Réflexion sur l’évolution de l’interface web pour nebule.

L’application 0 voit maintenant ses icônes centrées dans la page et a une icône dédiée au bootstrap/break.

020171022-shot-2017-10-22_18-13-55

Réflexion sur l’évolution de l’interface web pour nebule – dans klicty

Suite des articles Réflexion sur l’évolution de l’interface web pour nebule, objets, entités et entités 2.

Voici l’évolution en cours de l’interface de klicty.

La vue des entités pour se connecter :

020171022-shot-2017-10-22_18-15-25 Continuer la lecture de Réflexion sur l’évolution de l’interface web pour nebule – dans klicty

Réflexion sur l’évolution de l’interface web pour nebule – entités 2

Suite de la réflexion sur l’évolution de l’interface web pour nebule, objets. et entité.

Il y a deux façons d’afficher des objets.

La première ressemble à ce qu’il y avait avant, mais en plus complet. Les boutons d’action sont affichés sous la barre de titre de l’objet :

20170907-shot-2017-09-07_22-19-28

Continuer la lecture de Réflexion sur l’évolution de l’interface web pour nebule – entités 2

Réflexion sur l’évolution de l’interface web pour nebule – entités

Suite de la réflexion sur l’évolution de l’interface web pour nebule et objets.

Le code de génération graphique de l’affichage des objets progresse. La mise en place d’une fonction getDisplayList() permet de gérer beaucoup plus facilement une liste d’objets.

Voici un comparatif d’une liste d’entité avec l’ancienne méthode et la nouvelle :

 20170902-shot-2017-09-02_18-35-52

Et :

20170902-shot-2017-09-02_19-09-22

Pondération et structure hiérarchique

Suite de la gestion de la pondération.

Dans une structure ou une organisation hiérarchique, forme courante d’organisation, une autorité peut être amenée à déléguer son pouvoir à un autre individu. C’est le cas notamment lors d’une vacance.

Rapporté à une entité dans nebule, une entité a qui on donne une forte pondération, à qui on fait confiance, sera toujours prioritaire sur une autre de moins forte pondération. Comment permettre une vacance ? Est-ce que l’on peut mettre en place une forme de délégation de pondération ? Est-ce que ce lien de délégation est simplement annulé en fin de vacation ?

Cela pose aussi question sur la forme de la pondération. Elle est normalement globale. Mais ne faut-il pas gérer une pondération par rôle en plus ? Doit-il être géré comme une pondération avec un contexte social ?

Réflexion sur l’évolution de l’interface web pour nebule – objets

Suite de la réflexion sur l’évolution de l’interface web pour nebule.

Au moyen d’une nouvelle fonction d’affichage dans la bibliothèque nebule, la fonction getDisplayObject(), il est maintenant possible de déléguer plus facilement l’affichage d’une liste d’objets ou d’entités.

Voici l’affichage inséré dans un textes :

20170829-inline

Les différents formats d’affichage en blocs avec une hauteur de 32px, 64px, 128px puis 256px :

20170829-bloc-1

20170829-bloc-2


 20170829-bloc-3


 20170829-bloc-4

Plusieurs blocs s’assemblent pour remplir toute la largeur disponible en rapport avec leur largeur propre. Les informations internes affichées des blocs sont complètement indépendantes les unes des autre. Cela donne :

20170829-assemblage-bloc

La fonction permet aussi un affichage en liste avec un objet par ligne :

20170829-lignes

Quelques possibilités :

  • Le carré de l’icône peut être remplacé par une image ou masqué.
  • Le carré de la couleur n’est pas modifiable est dépend uniquement de l’ID de l’objet, mais peut être masqué.
  • Le nom de l’objet peut être remplacé par un texte.
  • L’identifiant de l’objet peut être masqué.
  • Les entités ou objets de référence (au dessus du nom) peuvent être masqués et si la liste est trop longue il se réduisent aux carrés de couleur et d’icône, voir juste au carré de couleur.
  • Les icônes de protection, de dissimulation et de verrouillage sont activables (en fond vert) et peuvent être masqués.
  • Les émotions sont calculés automatiquement et peuvent être masquées.
  • Le compteur est personnalisable et peut être masqué.
  • Certains éléments ne peuvent pas être affichés ensemble, surtout quand la place est limitée.
  • Les blocs sont centrés par défaut, leurs assemblages aussi.

Il reste à faire la deuxième partie de ces affichages d’objets, c’est à dire de les rendre utilisables autrement que juste par des liens hypertextes. L’idée est de rendre les carrés de l’icône et de la couleur sensible au clic pour afficher un menu complet des actions sur l’objet. Les actions seront dépendantes des modules via la mise en place de nouveaux points d’accrochage (hooks).

Réflexion sur l’évolution de l’interface web pour nebule

Au fil du temps l’interface graphique, communément appelée Interface Homme-Machine (IHM), implémentée dans les dérivés de nebule s’améliore et se structure autour de la bibliothèque commune. Cette bibliothèque incorpore de mieux en mieux la préparation de plus en plus d’éléments graphiques communs.

Cependant elle reste insatisfaisante.

Il n’est pas question de parler d’un interface d’application qui apporterait quelques solutions à certains problèmes mais entraînerait de fait bien des problèmes d’interopérabilité et le suivi des codes qui vont avec.

L’interface web semble la plus adaptée aujourd’hui mais traîne malgré sa bonne standardisation la question de la gestion des multiples supports d’affichages. La philosophie habituelle à la mode consiste à faire gérer par même page l’ensemble des affichages possibles dans tout le gradient entre les plus minuscules smartphones et les ordinateurs aux écrans très haute résolution. Sans parler du très faible écart en résolution des écrans à mettre en parallèle à leur l’écart de tailles.

C’est sans compter aussi le questionnement sur l’usage invasif et disproportionné du JavaScript (JS). De plus en plus de pages web sur Internet incorporent des parties de code/JS/images/etc venant de différents CDN. L’éclatement du moteur de la page en de multiples dépendances est tenable avec l’Internet actuel mais est profondément en opposition au fonctionnement de nebule et est par nature très sensible à la fragmentation possible de l’Internet dans le futur. Le JS trop pointu est clairement une source de dysfonctionnement ainsi qu’une source de problèmes de sécurité.

L’interface comporte deux parties:

  1. le contenu de la page contenant l’information principale attendue par l’utilisateur ;
  2. le cadre de la page avec des informations liées à l’environnement de l’information affichée ou à l’application.

Ces deux parties doivent être plus clairement décorrélées graphiquement. L’idée est d’essayer de rendre plus léger, aérien, le contenu et plus discret le cadre.

La vision d’avenir, sauf catastrophe, ce sont d’un côté des écrans toujours plus grands avec des résolutions toujours plus fines. Quand on dit grand c’est vraiment grand, au point que de vouloir mettre en plein écran une application n’ai plus vraiment de sens. Et d’un autre côté une scission des appareils nomades en de multiples composants plus ou moins autonomes parmi lesquels l’écran sera détaché au plus près des yeux de l’utilisateur, là encore avec des résolutions très fortes et avec de la transparence (canal alpha). Il faut aussi voir disparaître le clavier et la souris au profit du tactile, de la commande vocale et du pilotage par les yeux et même via une interface avec le cerveau. Il faut penser dès maintenant à préparer l’affichage des pages pour qu’il y ai une continuité entre la page web affichée aujourd’hui et celle affichée avec les évolutions prévisibles de demain.

La présence quasi systématique du double carré d’un objet peut permettre de le rendre actif en y cachant un menu des actions possibles simplement en cliquant dessus. Ainsi une liste d’objet ne sera plus polluée par de multiples boutons dans le cadre et sous chaque objets. Le menu lié à l’objet est bien sûr contextuel dans l’application et dépendant du type d’objet. Dans la page qui affiche les entités, cliquer sur une entité fera afficher le menu lui correspondant dans lequel on trouvera le bouton qui permet de se connecter avec cette entité.

Dans les menus du cadre ou des objets, l’activation d’un bouton ne sera plus immédiatement suivi d’une action, et d’un rechargement de page, mais fera apparaître des informations plus précises sur l’action du bouton et demandera un déplacement explicite sur un nouveau bouton pour valider l’action. Ainsi ce fonctionnement n’est pas trop pénalisant pour un usage à la souris et est très adapté à l’usage mobile tactile sur de petits écrans.

Les messages qui s’affichent en début de contenu, typiquement des alertes, seront systématiquement affichés à chaque rechargement d’une page mais devront pourvoir être cachés pour mieux accéder au contenu.

L’affichage du contenu doit être centré par défaut horizontalement et verticalement. Sur un écran de petite résolution on doit limiter l’affichage pour avoir juste ascenseur vertical. Sur un écran de haute résolution le cadre sera suffisamment loin pour que tout ce que l’on fait sur l’objet en cours d’affichage soit clairement une action sur l’objet. On peut à l’avenir imaginer que l’espace du contenu dispose de plusieurs zones qui affichent des objets différents simultanément, et donc potentiellement dans des contextes différents.

Le cadre doit contenir les informations sur l’entité connectée et le contenu doit faire référence au besoin à la vue restreinte à une entité si ce n’est pas l’entité connectée.

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…

Modification des sources d’aléa – implémentation

Suite à l’article Modification des sources d’aléa, la fonction getPseudoRandom a été modifiée dans la bibliothèque PHP orienté objet de nebule pour ne plus consommer du tout de ressource d’aléa mais en gardant une entropie forte.

La génération se fait depuis une graine qui est la concaténation de la date, de l’heure en micro-secondes, du nom de la bibliothèque, de la version de la bibliothèque et enfin de l’identifiant de l’instance locale du serveur. La graine dépendant donc surtout de l’heure avec une grande précision et est spécifique à chaque serveur.

La graine sert à générer via une fonction de hash l’état du compteur interne. Comme la taille du hash est fixe, une boucle permet d’alimenter la sortie en dérivant successivement l’état du compteur interne. À chaque tour de la boucle, l’état du compteur interne est dérivé en calculant le hash de lui-même. À chaque tour de la boucle, on concatène à la sortie le hash de l’état du compteur interne concaténé à une valeur fixe. L’état du compteur interne n’est jamais directement sorti et il est effacé en fin de génération de fonction.

Le bootstrap utilise aussi une génération pseudo aléatoire pour la création notamment d’identifiants temporaires. La bibliothèque PHP procédurale intégrée au bootstrap a aussi été modifiée. Elle fonctionne sur le même principe décrit ci-dessus. Une nouvelle fonction __pr est créée et les fonctions ne nécessitant par un aléa fiable ont été modifiées.

La fonction de hash actuellement utilisée pour la dérivation du compteur interne et la fonction sha256. Comme on attend pas de propriété cryptographique forte dans cette fonction, n’importe quelle fonction de hash peut faire l’affaire.

Ce sera disponible dans la prochaine version diffusée de la bibliothèque de nebule.