Catégorie : liens

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…

Transfert de liens et de confiance

Les réseaux fragmentés posent des problèmes plus importants que le maintient de la cohérence du système d’horodatage. CF Gestion temporelle partielle.

Certains protocoles de sécurisation des échanges deviennent bancales sans synchronisation de temps. Mais il y a plus grave. La cohérence du temps entre plusieurs machines peut être négligé sur une courte période, les horloges ne vont pas dériver exagérément et il y a peu de change que des certificats expirent. Par contre, il devient difficile de transmettre de nouveaux contacts avec un grand niveau de confiance. les relations de confiance sont souvent dépendantes de services centralisés, services qui ne sont plus forcément joignables. Ces services ont le rôle d’annuaires globaux. Il faut dans ce cas faire confiance aux seuls intermédiaires que l’on a sous la main, et que l’on connaît (au moins dans nebule). On doit utiliser des entités comme des annuaires locaux.

Dans ce cas, il est peut-être utile de voir si la définition d’un nouveau type de lien ne pourrait pas répondre à ce besoin. Ce serait un lien signé par une entité que l’on connaît et qui transmettrait un lien d’une autre entité, inconnue. Un lien serait encapsulé dans un autre de la même façon que pour un lien offusqué. La validité et la pondération du lien de l’entité inconnue seraient les mêmes que si le lien venait de l’entité connue. Ce serait une forme de relais de liens.

Ce type de lien aura peut-être aussi une utilisé pour les annuaires d’entités. Cela pourrait faciliter la mise en relation entre deux entités qui ne se connaissent pas.

Mais, c’est aussi un risque qui faut analyser. On commence dans ce cas à prendre en compte des liens d’une entité que l’on ne connaît pas et que l’on ne peut directement vérifier. Il faut voir ça comme si l’entité qui fait le relais des liens s’appropriait elle-même le lien. Cette entité peut diffuse des liens invalides, c’est à dire dont la signature est invalide, sans que l’on puisse le vérifier. L’affiche de ces liens ou leur interprétation doit être peut-être adapté pour montrer cette particularité…

Partage simplifié d’une entité

Pour l’utilisateur d’un logiciel de communication, mémoriser un mot de passe complexe est une tâche ardue, voir sans intérêt.

Le problème est le même avec les pages web, leurs noms doivent être facile à retenir et à retaper sans faute. Et il en est ainsi pour les correspondants dont il faut se souvenir au pire de leurs adresses emails ou au mieux de leurs noms ou pseudonymes. Dans certains cas, il faut se souvenir du pseudonyme et du site web sur lequel on peut trouver un correspondant.
Le projet nebule vise notamment à fédérer des identités en même temps que les données. Mais cela entraîne inévitablement l’utilisation d’identifiants globalement uniques, donc longs.
Certains projets comme minilock visent à essayer de réduire ces identifiants avec des encodages comme le Base58.

On peut aussi utiliser uniquement une localisation, c’est à dire adresse de type http ou email. Ainsi, pour une adresse http, il faut héberger à une adresse précise une entité par défaut. Si un hébergeur veut gérer plusieurs entités, il ne pourra pas les garder facilement dans le même espace, le même nom de domaine, mais il devra au contraire les séparer dans des espaces différents. Mais est-ce vraiment la solution ?

Dans l’article sur le Détournement de liens de mise à jour (CF blog sylabe), on a vu qu’il était possible de créer une sorte de pseudonyme d’entité nebule. C’est un détournement du lien de mise à jour depuis un objet fictif vers, dans notre cas ici, une entité définie. Prenons comme exemple un prénom Fabio auquel correspondrait un objet fictif fab10. Ainsi, sur une instance de nebule, cet objet reverrait systématiquement vers l’entité de l’utilisateur. Ça résout le problème localement.

Cependant, on peut facilement imaginer que tous les utilisateurs qui ont se prénom vont avoir des prétentions sur cet objet fictif. Comment va se résoudre le conflit ?
Assez mal en fait. Si on a des amis en commun, on devrait rapidement retrouver le bon identifiant de l’entité. Mais ça se corse si on a deux entités avec des prétentions sur ce pseudo dans nos entité proches. Dans ce cas, c’est le calcul social qui va déterminer l’entité qui pourra hériter du pseudo, et cela fait une chance sur deux de ne pas tomber sur la bonne entité…
En plus, on peut imaginer aussi que dans une situation de harcèlement ou de dénigrement, des entités agressives essayent aussi de s’approprier le pseudo. Cela pourrait rendre le pseudonyme difficile à utiliser puisqu’il ne renverrait que rarement à la bonne entité.

Cette méthode est donc loin d’être parfaite. Elle peut être raisonnablement utilisée soit dans un petit groupe d’utilisateurs soit si elle est associée à une localisation http, email, etc…

Nommage multiple et protéiforme

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

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

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

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

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

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

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

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

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

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

Lien de type d, précisions

La documentation a été complétée pour le lien de type d :

L’objet est marqué comme à supprimer d’un ou de tous ses emplacements de stockage.

d comme delete.

Le champs HashCible peut être nuls, c’est à dire égal à 0. Si non nul, ce champs doit contenir une entité destinataire de l’ordre de suppression. C’est utilisé pour demander à une entité relaie de supprimer un objet spécifique. Cela peut être utilisé pour demander à une entité en règle générale de bien vouloir supprimer l’objet, ce qui n’est pas forcément exécuté.

Le champs HashMeta doit être nuls, c’est à dire égal à 0.

Un lien de suppression sur un objet ne veut pas forcément dire qu’il a été supprimé. Même localement, l’objet est peut-être encore présent. Si le lien de suppression vient d’une autre entité, on ne va sûrement pas par défaut en tenir compte.

Lorsque le lien de suppression est généré, le serveur sur lequel est généré le lien doit essayer par défaut de supprimer l’objet. Dans le cas d’un serveur hébergeant plusieurs entités, un objet ne sera pas supprimé si il est encore utilisé par une autre entité, c’est à dire si une entité a un lien qui le concerne et n’a pas de lien de suppression.

CF : Documentation_-_nebule_v1.2 – Action_d_-_Suppression_d’objet

Lien de type c, précisions

La documentation a été complétée pour le lien de type c :

Ce lien contient un lien chiffré. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité.

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal.

Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.

CF : Documentation_-_nebule_v1.2 – Action_c_-_Chiffrement_de_lien

Lien de type f, précisions

La documentation a été complétée pour le lien de type f :

Le nouvel objet est considéré comme enfant ou parent suivant le sens du lien.

Le champs HashMeta doit être vu comme le contexte du lien. Par exemple, deux objets contenants du texte peuvent être reliés simplement sans contexte, c’est à dire reliés de façon simplement hiérarchique. Ces deux mêmes textes peuvent être plutôt (ou en plus) reliés avec un contexte comme celui d’une discussion dans un blog. Dans ce deuxième cas, la relation entre les deux textes n’a pas de sens en dehors de cette discussion sur ce blog. Il est même probable que le blog n’affichera pas les autres textes en relations si ils n’ont pas un contexte appartenant à ce blog.

CF : Documentation_-_nebule_v1.2 – Action_f_-_Dérivé_d’objet

Canaux cachés dans les liens

Il est difficile de lutter contre les canaux cachés dans les protocoles. C’est notamment le cas pour nebule avec les liens. Tous les champs du registre sont potentiellement concernés mais différentes stratégies peuvent être mises en place pour détecter à postériori le canal ou réduire fortement le débit utile à la transmission de données.

Le champs le plus facile à utiliser pour un canal caché est le champ action. Sa vérification doit être vérifiée pour que sa taille soit strictement limité à un caractère et uniquement à un des types de liens attendus.

Le champs date peut être exploité dans ses valeurs de plus faible poids comme la seconde ou ses sous multiples. Tant que l’ordre temporel des liens est respecté, il est tout à fait possible de mettre des valeurs arbitraires et donc du contenu encodé en chiffres décimaux.
De plus, comme on ne s’oriente pas vers une interprétation stricte de la norme ISO 8601, il devient possible d’utiliser une grande précision dans les sous multiples de la seconde. C’est à dire que l’on peut placer un grand nombre de chiffres en fin de date tant que ce sont des chiffres décimaux.
La vérification de la date peut inclure une taille limite pour réduire la quantité de données cachées.

Les champs des objets peuvent référencer des objets fictifs, et donc en fait ces champs peuvent contenir des données convertis en hexadécimal. Il est possible de vérifier que ces champs objets ont une taille compatible avec les algorithmes de hash. Il est possible de vérifier si ceux-ci ont tous les attribut que l’on attend d’un objet, voir qu’ils sont bien disponibles.

Le champs de l’entité signataire ne peut pas être modifié n’importe comment, mais en utilisant plusieurs entités différentes on peut faire un canal caché sous forme d’une sorte de morse. Cela peut peut-être être détecté en regardant les entités en question.

Le champs signature n’est pas facilement exploitable. Tout au plus peut-on faire du morse en jouant sur la date pour générer une signature qui commence ou termine par un chiffre précis. Il est plus probable que le champs date soit exploité à la place pour un canal caché.

La documentation va être modifiée pour réduire les problèmes avec les champs date et action.

Modes de traitement

Le projet nebule en lui-même donne un cadre stricte dans la forme des objets et des liens. Mais il ne donne que des orientations sur le traitement, c’est à dire l’interprétation, de ces objets et surtout de leurs liens.

Il existe aujourd’hui trois stratégies dans le traitement des objets et des liens.

Le mode ouvert

C’est la façon la plus simple d’utiliser les objets et les liens puis qu’aucune vérification n’est réalisée.

Cela implique pour commencer que les empreintes des objets ne sont pas vérifiées. Ces empreintes sont donc de pures URI avec un faible attachement au contenu des objets qu’elles référencent. Cette considération entre en conflit avec l’un des fondements du projet nebule puisque l’empreinte est strictement attaché à un objet, son contenu en fait, et que toute modification de cet objet entraîne implicitement la création d’un nouvel objet avec une empreinte propre.

Les liens ne sont pas vérifiés, ce qui veut dire que leur provenance, n’étant pas assurée, ne peut pas être non plus utilisée. Ainsi, les liens sont vus sont leur forme la plus réduite, c’est à dire la forme équivalente RDF avec la date et l’action.

Le traitement s’en trouve extrêmement accéléré. Il est pas contre impossible d’établir un échange digne de ce nom ne serait-ce qu’entre deux entités. Les notions de propriétés public et privée n’ont pas de fondement dans ce cas. On ne peut envisager ce fonctionnement que sur un périmètre restreint d’un centre de calcul et dédié à une tâche unique. On peut tout au plus envisager une passerelle vers le monde extérieur qui vérifierait scrupuleusement les entrées et signerait les sorties.

Ce mode de traitement n’est pas recommandé dans le cadre du projet nebule.

Le mode social

La prise en compte du côté social implique que l’on tienne compte de l’émetteur des liens, et donc de la validité de ceux-ci. A l’opposé du mode ouvert, cette façon de procéder est la plus complexe et la plus lente. Mais c’est aussi la plus intéressante.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Comme nous sommes dans un environnement social, c’est à dire avec de multiples entités, nous devons procéder à un tri des liens en fonction de leur provenance. Les objets sont vérifiés mais leur usage dépend exclusivement de leurs liens, et donc notamment des émetteurs de ces liens.

Lorsque deux actions sont contradictoires, il faut tenir compte de l’environnement sociale et plus seulement du facteur temporel. Il y a des différences dans la confiance que l’on accorde aux autres entités, et donc dans les liens quelles génèrent. Le tri des liens est réalisé suivant une pondération qui reflète la relation avec les entités émettrices. C’est une pondération en tout point sociale et est attachée aux entités.

L’offuscation de liens permet de cacher ou de tromper une entité sur la vraie pondération qu’on lui accorde. Mais il fait garder à l’esprit que plus elle est discordante plus elle a de chance d’être découverte ou au minimum de provoquer de la confusion.

Une pondération peut aussi être envisageable sur les objets. Cela permet en augmentant la pondération de réduire proportionnellement l’influence des autres entités sur un objet précis.

Enfin, une pondération peut être réalisée sur le type de lien et éventuellement en fonction d’un des objets référencés par un lien.

Ici, pour le projet nebule, clairement tout est quasiment à faire. La pondération des entités n’est pas encore formalisée. La pondération des objets et théorique. Et la pondération sur le type de lien n’est qu’une prévision par rapport aux modèles actuels.

Le traitement des objets et des liens, déjà ralentis par les vérifications de base, est encore plus complexe du faire des calculs de pondérations, et donc plus lent encore.

Ce mode de traitement est celui adopté par la librairie nebule de référence en php. Par extension, c’est aussi le mode de traitement utilisé dans le projet sylabe.

Le mode strict

La prise en compte du côté social est partielle, elle a même une forme exclusive. On se situe à mi chemin entre le mode ouvert et le mode social en terme de complexité.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Contrairement au mode social, la prise en compte des entités n’est pas globale mais au contraire exclusive. On ne reconnaît que les liens de certaines entités précises. Afin de simplifier encore plus le traitement, il n’y a pas de priorisation ou de pondération dans l’exploitation des liens. Si plus d’une entité est reconnu, toutes ont le même poids et donc le même pouvoir de décision dans l’utilisation des objets. On attend ici des décisions rapides, fiables et reproductibles dans un environnement large mais avec un groupe très restreint d’objets et de liens à prendre en compte. Tout le reste est ignoré.

C’est un fonctionnement de type paranoïaque. Les notions de propriétés publique et privé sont assurées mais les échanges avec d’autres entités sont très limités et potentiellement conflictuels parce que non pondérés, non régulés. Ce fonctionnement est tout indiqué pour gérer la sécurisation de certains outils informatiques comme le déploiement de code.

Le cas le plus représentatif est par exemple la reconnaissance des entités puppetmaster, bachue et cerberus dans la validation de la librairie nebule de référence en php mais aussi du code du projet sylabe.

Ce mode de traitement est utilisé par le bootstrap en php et la librairie nebule de référence en bash. Le bootstrap ne reconnaît que les objets de bachue ou de l’autorité locale moyennant un bannissement de cerberus et sous la supervision de puppetmaster.

Anonymisation de lien – correction du registre

Voici une petite correction suite à l’article sur l’Anonymisation de lien.

Tant que l’on en est encore dans la mise en place du code pour gérer le lien de type c, une petite modification est réalisée sur le registre de ce type de lien.

Si on regarde la philosophie dans l’ordre des champs du registre des liens, l’objet méta est souvent une sorte d’opérateur entre deux objets. Cet objet méta peut souvent être vu comme annexe ou de valeur nulle dans certains cas. Le lien de type k contient notamment une entité destinataire qui peut consulter l’objet, et une clé de session chiffrée. On a ici le choix pour l’objet méta entre l’entité et la clé de session. J’opte pour la clé de session.

Voici donc le nouveau registre de lien de type c :

Signature_Signataire_TimeStamp_c_EntitéCible_LienChiffré_CléSession

 

Anonymisation de lien

MàJ 11/06/2014 : le registre de lien a été changé : Anonymisation de lien – correction du registre

Dans la version 1.2 de nebule, le nouveau lien de type c a pour rôle d’anonymiser les actions des entités. Cette anonymisation doit permettre de cacher la relation entre l’entité d’un côté et ses actions sur des objets de l’autre. Il faut donc cacher non seulement le type de lien mais aussi que le lien relie ces objets. C’est la suite des articles liaison secrète et suite de fin 2012.

Il faut malgré tout permettre la libre diffusion des liens générés pour que ceux-ci soient transmis sur un réseau public et ouvert notamment via des entités relais. Cette transmission est assurée par le fait que l’entité signataire apparaît en clair puisqu’il faut être capable de vérifier la signature du lien.

L’anonymisation consiste en l’offuscation du vrai lien dans un lien caractéristique, le lien de type c. Le vrai lien, celui qui a un intérêt, est chiffré et intégré au lien de type c. Pour que la vérification des liens soit la plus simple possible, elle ne doit pas gérer le lien offusqué différemment. Le registre du lien doit donc être identique aux autres liens à l’exception de l’action et ce registre doit passer les mêmes tests de validation.

Si le lien offusqué mentionne l’entité signataire, il doit peut-être pouvoir être lisible par une autre entité. C’est le cas si l’on souhaite partage un lien de la même façon que l’on pourrait souhaiter partager un objet. Il faut donc que le lien offusqué fasse aussi référence à l’entité destinataire. L’entité destinataire, ou entité cible, qui peut être la même que l’entité signataire, sera positionnée dans le registre en 5ème position. Cette place est habituellement occupée par l’objet source.

Il faut prévoir une clé de session (un mot de passe) pour chiffrer le lien (chiffrement symétrique) parce que celui-ci n’a pas forcément une taille adéquate pour le chiffrement asymétrique. La clé de session chiffrée doit être encodé en hexadécimal. La clé de session chiffrée sera positionnée dans le registre en 6ème position. Cette place est habituellement occupée par l’objet destinataire.

Enfin, le lien offusqué, chiffré, doit être encodé en hexadécimal. Le lien offusqué sera positionné dans le registre en 7ème position.

Voici donc le registre de lien de type c :

Signature_Signataire_TimeStamp_c_EntitéCible_CléSession_LienChiffré

Le lien à offusquer est chiffré (symétrique) avec la clé de session et ajouté en position 7. La clé de session est chiffrée (asymétrique) avec la clé publique de l’entité cible et ajoutée en position 6. L’entité cible est ajoutée en position 5.

On ne peut dans ce cas pas offusquer la relation entre l’entité signataire et l’entité cible. La présence de la première entité est indispensable pour vérifier la signature du lien. La présence de la seconde entité est nécessaire pour que le lien puisse lui parvenir et lui indiquer que le lien la concerne. Le reste du lien est complètement offusqué.

Lors du traitement des liens d’un objet, Il faut à la fois consulter les liens de l’objet mais aussi consulter les liens offusqués attachés à l’entité courante. Ensuite seulement peut se faire le nettoyage des liens marqués supprimés.
On remarquera que cette façon de procéder permet bien sûr de ne pas révéler certains liens, mais aussi de marquer secrètement comme supprimés des liens alors qu’ils sont encore publiquement reconnus comme valides. Dans le même ordre d’idé, on peut camoufler un objet sous un type mime assez banal mais offusquer un lien dévoilant sa vraie nature. Un vrai terrain de jeux de cache cache en perspective !

Il reste un autre aspect de l’anonymat. Il peut être nécessaire de permettre des échanges entre deux entités sans qu’il n’y ai de lien entre elles, même de liens offusqués. Ce problème peut être résolu avec la génération d’entités esclaves le temps de quelques échanges. Il n’est pas possible dans ce cas de rattache directement ces entités esclaves à notre entité principale ni d’héberger cette entité sur son serveur personnel sous peine de dévoiler immédiatement la relation entre les deux. Il faut aussi prévoir un mécanisme pour que des entités puissent attendre des liens d’entités inconnues tout en étant capable de vérifier ces liens. Une fois le contact établit, il devient aisé, via l’offuscation de liens, de prouver sa véritable identité, c’est à dire de faire un lien entre entité esclave et entité maître. Il y a encore de la recherche à faire à ce niveau…

Modification de la librairie php vers la version 1.2 des liens

La librairie en php intègre maintenant les spécificités de la version 1.2 lors de l’écriture des liens par la fonction _l_wr.

L’écriture des liens se fait aussi sur l’entité signataire avec la prise en compte de la spécificité du lien de type c lors de l’écriture. Lorsque c’est un lien de type c, seule l’objet de l’entité signataire du lien reçoit le lien. Ce fonctionnement risque encore de changer en fonction des réflexions autour de ce type de lien.

Mise en cache de validité de liens

Il faut faire attention à la mise en cache du résultat de certaines opérations. Il est très peu probable qu’un lien ou un objet soit modifié au cours du chargement d’une page. Mais la sûreté de fonctionnement de ce mécanisme de cache ne repose que sur ce principe.

Actuellement, dans la librairie en php, la fonction de vérification des liens _l_vr n’intègre pas de cache. C’est à dire que à chaque lecture de liens, ils sont revérifiés.
Si un cache devait être implémenté sur cette fonction, pour un lien définit il devrait prendre en cache l’intégralité du lien et non juste le premier champs de registre. Éventuellement, il pourrait n’intégrer que tous les champs de registre à l’exception de la signature puisqu’elle aura déjà été vérifiée.

La mise en cache de la vérification des objets utilisés _o_vr vient d’être implémentée. Le cache n’est gardé que le temps du chargement d’une page. Il ne vérifie que les objets directement intégrés à la page mais pas les objets externes comme les images. Les objets externes sont vérifiés lors de leur consultation, ce qui correspond en quelque sorte à une nouvelle page.

Nouvelle version nebule v1.2 – lien de type c

Comme nouveauté de la version 1.2, il y a la possibilité d’offusquer les liens afin de renforcer l’anonymisation des entités.

Pour cela, un nouveau type de lien vient d’être ajouté à la documentation : Action c – Chiffrement de lien
Autrement dit, c’est un lien de type c.

Il n’est pas encore pris en compte dans le code. Sa forme exacte n’est pas encore figée.

Ajout d’émotions sur des objets – suite 4

L’ajout des émotions sur les objets n’en finit pas d’arriver… Le code est un peu délicat à manipuler. Certaines choses doivent s’afficher dans certaines conditions et à certains endroits en fonction de l’objet que l’on regarde. C’est la suite de l’article Ajout d’émotions sur des objets – suite 3.

Les émotions supportées sont encore sujet à discussion, mais leur fonctionnement est maintenant stable.
Les émotions doivent être considérées comme des groupes, donc les objets que l’on marque avec ces émotions appartiennent en quelque sorte aux groupes d’émotions en question.
On parle ici des émotions, mais la mécanique est exactement la même pour les avis. Seul l’affichage peut varier un peu.

Quelques règles de fonctionnement :

  1. Une émotion est représentée sur un objet par un lien de type ‘f‘ de l’émotion vers l’objet, méta à ‘0‘.
  2. Une émotion sur un objet dérivé lié à l’objet en cours est un lien de type ‘f‘ de l’émotion vers l’objet dérivé avec comme méta l’objet en cours.
  3. Une émotion sur un objet dérivé, donc avec un contexte, n’apparaît pas dans le mode affichage de l’objet, même si on est sur l’objet dérivé en question.

Cela donne par exemple ce genre de vue en mode navigation :

shot-2014-04-22_20-44-57

On remarque que toutes les lignes qui disent que l’objet est de type image/jpeg ont l’émotion ‘J'approuve‘. C’est fait en une seule fois. C’est le même lien derrière qui dit que l’on approuve que l’objet soit de ce type, indépendamment de qui le dit.

Si on se place sur l’objet du milieu dans la petite conversation en cascade, on peut observer ça :

shot-2014-04-22_20-50-34

On voit que les autres commentaires sont fait dans le contexte d’un objet spécifique, un autre objet surtout. On voit aussi qu’une émotion est placée sur l’un des commentaire, cette émotion est cependant dans le contexte de l’objet en cours, ce commentaire, et non dans le contexte de l’objet dans lequel à lieu la discussion. Si on regarde l’affichage précédent, cette émotion n’apparaît pas.

Affichage des liens invalides

La librairie nebule en php permet maintenant la remontée, pour affichage uniquement, des liens invalides. C’est contrôlé par la variable $nebule_listinvalidlinks. Cette fonctionnalité ne sera pas activée par défaut parce que l’utilisateur pourrait confondre un lien compromis avec un problème de synchronisation sans gravité. Quoi qu’il arrive, la synchronisation élimine par défaut les liens invalides.

Voila à quoi cela peut ressembler :

shot-2014-04-12_15-34-58

CF : http://blog.sylabe.org/?p=481

Ajout d’émotions sur des objets – suite 3

Toujours pas de modification dans les émotions de base assumées. On reste sur la roue de Plutchik.

Par contre, la mise en place de la gestion des émotions et avis dans sylabe montre que l’utilisation des liens ‘l‘ n’est pas optimale et qu’il vaudrait mieux utiliser des liens ‘f‘ à la place. Si on change de type de liens, cela rendra caduc les objets ‘nebule/objet/emotion‘ et ‘nebule/objet/avis‘. A la place pourra être utilisé un objet méta comme une sorte de contexte du lien.
CF avancement du 11/04/2014.

Ajout d’émotions sur des objets – suite 2

Voici la suite des articles Ajout d’émotions sur des objets et suite, ainsi que de Liens d’émotions.

La liste d’émotions étant trop grande et malgré tout incomplète, il a été nécessaire de revoir l’ensemble pour le scinder. Plutôt que de réinventer la roue, un petit tour du côté de Wikipédia a permit de prendre un bon départ. La version anglaise de la page émotion est plus complète et plus intéressante.

Il y a plusieurs repères possibles pour traiter et cataloguer les émotions. On va s’arrêter sur les travaux de Robert Plutchik . Le résultat, c’est la roue de Plutchik :

Plutchik-wheel_fr.svg

Continuer la lecture de Ajout d’émotions sur des objets – suite 2

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.

Ajout de sentiments sur des objets

Les derniers développements de sylabe on permit de réactualiser l’ajout de marques tel que j’aime, j’aime pas et bien plus encore.
CF : Blog sylabe – Avancement
Ces marques sont regroupées sous le terme de sentiments. Ils sont matérialisés par des liens de type l de l’objet vers le sentiment (un autre objet) et le méta ‘nebule/objet/sentiment‘.

Ces sentiments ont une signification purement humaine. Le code de nebule ne l’interprète pas et n’en tient pas compte. Mais ces sentiments ont chacun des objets dédiés qui eux ont tout intérêt à être communs à toutes les applications. Ils doivent être propagés quoi qu’il arrive comme tout liens. C’est la raison pour laquelle ils seront définis au niveau de nebule.

Leur affichage sera spécifiquement traduit pour être plus lisible et tenir compte de la langue d’affichage. Continuer la lecture de Ajout de sentiments sur des objets