Implémentation de la gestion des liens dissimulés

juin 28th, 2019

La bibliothèque nebule en php orienté objet est en cours de modification pour être capable de gérer les liens dissimulés.

La classe qui gère les I/O reçoit une nouvelle fonction parce que la demande de liens dissimulés ne se gère pas de la même façon que les autres liens.
La partie écriture a été modifiée aussi afin de détecter si le lien à écrire est dissimulé ou pas. Dans le cas d’un lien dissimulé le fichier de stockage est différent.
Et lors de la lecture de liens dissimulés, il est possible de préciser un signataire, ce qui cible directement un seul fichier de liens à lire.

La classe qui gère les liens va être modifiée pour être capable d’interroger la classe des I/O pour les liens dissimulés ou non.

Double offuscation de lien ou entités de session

juin 25th, 2019

L’un des problèmes fondamentaux des liens offusqués aujourd’hui est que l’on doit maintenir impérativement la liaison entre l’entité signataire du lien et une entité destinataire. C’est le seul moyen de permettre à l’entité destinataire de « recevoir » des liens d’une entité source signataire.

Mais cette liaison marque un échange entre deux entités, ce qui déjà dévoile quelque chose que l’on ne voudrait pas forcément voir apparaître publiquement. Il faut pouvoir anonymiser cette liaison.

Pour éviter le marquage de cette relation entre deux entités, il y a deux voies possibles utilisant des entités intermédiaires.

La première solution, pas forcément très élégante, est de faire une double dissimulation des liens. Le premier niveau de dissimulation fait intervenir les deux entités précédentes. Le second niveau va sur-dissimuler le lien mais cette fois-ci avec une entité signataire neutre. Chaque entité de la liaison échange génère et échange préalablement une entité neutre qu’ils s’approprient par des liens dissimulés (pour eux-même). Il faut un mécanisme d’échange préalable des entités neutres de la même façon que l’on échangerait préalablement un secret partagé.
Mais cette méthode ne marche pas avec la dernière modification de la structure du lien dissimulé qui impose au lien dissimulé le signataire du lien non dissimulé.

On peut cependant conserver la notion d’entités neutres dédiées à une échange entre deux entités. Pas besoin de sur-dissimulation, il faut juste être capable d’associer une entité neutre à l’entité d’un correspondant. Nous avons dans ce cas des entités neutre pouvant faire office d’entités de session en complément/remplacement d’une clé de session.

Anonymisation/dissimulation des liens – ségrégation partielle

juin 25th, 2019

Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité, la réflexion sur le stockage et l’échange des liens dissimulés continue.

Il était question de créer un dossier spécifique pour stocker les liens dissimulés. Le nommage des fichiers contenant ces liens doit aussi être différent des entités signataires et destinataires des liens, et ce nommage peut par facilité faire référence simultanément à ces deux entités. Mais il est possible de juste appliquer le nommage de ces fichiers dans le dossier des liens. Cette organisation et cette séparation des liens dans des fichiers clairement distincts répond au besoin. Et lors du nettoyage des liens, le traitement peut être différencié par rapport à la structure du nom des fichiers.

Le nommage proposé des fichiers contenants les liens dissimulés :

/l/HashEntitéDestinataire-HashEntitéSignataire

Le hash de l’entité destinataire est en premier, ainsi, pour une entité, tous les liens dissimulés ou non sont dans des fichiers co-localisés, c’est à dire commençant par le hash de l’entité.

Il faut par contre, lors de la synchronisation des groupes et des conversation récupérer à la fois les liens de l’objet de conversation et les liens dissimulés.

Schéma lien dissimulé – timestamp

mai 11th, 2019

Suite à l’article sur le nouveau schéma des liens dissimulés, une précision s’impose concernant les champs Timestamp, les marques de temps.

Le lien à dissimuler contient une marque de temps qui est très souvent nécessaire à l’interprétation du lien, et notamment lors de sa suppression. De l’autre côté nous avons aussi une marque de temps sur le lien dissimulé cette fois. Mais nous ne devons pas avoir une copie directe de la marque de temps du lien à dissimuler vers le lien dissimulé parce que cette marque de temps va se retrouver potentiellement dans d’autres liens générés au même moment… et pourrait donner des indications sur le lien à dissimuler.

Il faut donc que la marque de temps du lien dissimulé soit clairement non reliée à la marque de temps du lien à dissimuler.

Du coup, un autre problème émerge, comment fait-on pour supprimer un lien à dissimuler, et donc en même temps le lien dissimulé ?

Le lien de suppression du lien à dissimuler doit être le même avec comme champs action x. Mais comme il contient toutes les informations, à part le champs action, du lien à dissimuler, il faut aussi dissimuler le lien de suppression. Jusque là, c’est facile il a une marque de temps différente et en lisant les liens dissimulés on peut voir la suppression.

Mais faut-il aussi un lien de suppression du lien dissimulé de suppression ? Et où celui-ci doit-il être stocké ?

La notion de lien dissimulé et à dissimuler est assez pénible à écrire, et donc à lire. Il faut peut-être aussi revoir le vocabulaire à ce niveau pour que ce soit plus fluide…

Schéma lien dissimulé

avril 29th, 2019

Nouveau schéma du lien dissimulé :

20190429_lien_c

Liens hypertexte et insertions

avril 29th, 2019

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.

Anonymisation/dissimulation des liens – ségrégation et temporalité

mars 22nd, 2019

Dans l’article sur l’Anonymisation/dissimulation des liens, on a vu que le stockage et le partage des liens dissimulés, de type c, était difficile si on voulait respecter le fonctionnement nominal des liens tels que définis depuis longtemps dans nebule.

Les seuls identifiants objets réels en clair dans le lien sont l’entité signataire et l’entité destinataire. Ce peut être d’ailleurs la même entité qui dissimule ses propres liens. Il n’est donc pas possible de diffuser les liens dissimulés autre part que sur l’entité destinataire.

Cependant les liens dissimulés ne jouent pas le même jeux que les liens en clair. Il faut peut-être les sortir du circuit normal des liens et mettre en place un circuit dédié.

Par exemple on peut dédier un nouveau dossier pour leur stockage, un dossier nommé c par exemple.
On peut aussi imaginer que ce dossier dédié ne serait pas structuré de la même façon. Il doit être fait référence aux entités qui dissimulent des liens, mais il est possible de segmenter encore un tout petit peu. On peut avoir des noms de fichiers de stockage des liens dissimulés faisant référence à l’entité signataire et l’entité destinataire. Ainsi il serait possible de retrouver les liens qui nous concerne et uniquement ceux-là sans avoir besoin d’un tri coûteux.

Il faut penser aussi que les liens dissimulés ne seront pas forcément horodatés correctement. Seul le champ temporel dissimulé sera exploitable pour l’entité destinataire. Les liens ne peuvent donc pas raisonnablement être pré-classés par ancienneté.

Le problème résiduel de performance tien dans le fait que lorsque l’on ouvre une session avec une entité, il faut relire et déchiffrer tous les liens même si l’on en cherche qu’un seul. Il est peut-être possible de stocker les liens dissimulés lus, et donc déjà vérifiés, dans un objet protégé. La vérification pourrait ne plus être faite systématiquement. Cet objet particulier pourrait être lui aussi dans le dossier dédié c, et donc ne pas respecter les contraintes de vérification de son empreinte, et donc de pouvoir être agrandi régulièrement. Dans ce cas la lecture des liens dissimulés se ferait beaucoup plus rapidement.
Reste à savoir quand et comment on alimente ce gros fichier tampon des liens dissimulés…

Protection des objets – les origines

mars 20th, 2019

Le problème de protection des objets de faible taille, tel que décrit dans l’article Protection et faible entropie, n’a pas de solution simple ou élégante. Peut-être qu’il est temps de se questionner sur la pertinence de la façon dont est assurée la protection des objets, de revoir les réflexions à l’origine de la protection des objets.

D’ailleurs, dans le même ordre d’idée, il faudra peut-être aussi se poser des questions par rapport à la dissimulation des liens qui crée un problème différent mais sans solution simple, performante et élégante.

A l’origine, l’usage de la protection des objets n’avait pas été vu avec autant de cas d’usages. L’idée était de pouvoir dissimuler le contenu d’une objet tout en continuant de le tracer, c’est à dire de l’identifier par son empreinte. Il semblait peu utile de dissimuler des choses aussi simple que « oui » ou « non ».
La capacité de pouvoir tracer devait aussi permettre de pouvoir bannir un objet en se basant sur son empreinte en claire. Une fois protégé un objet a une infinité d’empreintes possibles, donc il devient non traçable en pratique.
L’idée était aussi de pouvoir vérifier que le contenu protégé que l’on recevait d’une autre entité correspondait bien au contenu en clair attendu. Ceci avait pour but de ne pas ce retrouver avec un code offensif une fois déprotégé en lieu et place d’un objet anodin. Dans ce cas un contenu offensif peut être écarté rapidement par un simple lien de mise en liste d’exclusion.

Le problème vient du fait que le lien de protection de type k, en particulier le lien de chiffrement symétrique, fait l’association entre la valeur claire et la valeur chiffrée de l’information. En disposant de l’empreinte de l’information en claire on peut, si la valeur totale de son entropie est faible (ou si, déduit des parties prévisibles, la valeur totale résiduelle de l’entropie de l’information est faible), on peut dans ce cas recalculer l’information.
Il est théoriquement possible que le recalcule de l’information en claire donne une autre information ayant la même empreinte. Mais l’espace des valeurs calculables étant inférieur à la taille de l’empreinte des objets, càd la valeur totale de l’entropie de l’information recalculée en rapport avec la valeur totale de l’entropie d’une empreinte, et en considérant l’algorithme de prise d’empreinte cryptographique suffisamment robuste, il est très peu probable (de l’ordre de l’inverse de la taille des empreintes) de trouver une autre information de même empreinte. Ce serait même très inquiétant pour l’algorithme de prise d’empreinte cryptographique.

En parcourant le code et les cas d’usages actuels, il apparaît que l’on fait déjà indistinctement référence à un objet en clair ou protégé en utilisant son empreinte pour son contenu en clair ou protégé. Le code se charge de remettre dans le bon sens les deux identifiants.
Ne faire référence que à la partie protégée ne pose pas plus de problème que ça dans les usages actuels puisque l’on a juste besoin d’un identifiant.
Il est alors possible de recalculer l’empreinte, donc l’identifiant, du contenu en clair, et donc de pouvoir potentiellement le confronter à lien de mise en liste d’exclusion.

Le temps est encore à la réflexion mais la solution est peut-être là…

Protection des objets – faible entropie

mars 19th, 2019

Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.

Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.

Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.

La suite au prochain épisode…

Liens de classification des objets

mars 19th, 2019

Les objets que l’on affiche dans les applications sont déjà affublés de certains marquages, même si ils ne sont pas encore tous fonctionnels.

Par exemple, un objet peut être marqué comme dangereux et donc son contenu masqué par défaut. Cependant, les enfers n’ayant toujours pas ouverts, ce marquage n’est pas utilisé.

D’un autre côté, un objet protégé se verra affublé d’un message d’avertissement pour prévenir que son contenu ne doit pas être affiché en public. Ou dans certains cas comme sur les messages, c’est un indicateur qui donne l’état de protection d’un message.

Mais il est un autre type de message qu’il peut être utile de délivrer à un utilisateur. Au delà du fait qu’un objet est protégé, cette protection se justifie sûrement par rapport à la sensibilité du contenu de l’objet. Il est alors légitime de préciser une classification du contenu de l’objet dans certaines circonstances.

Cela permet d’avoir aussi une liste des informations importantes et de les tracer plus facilement.

C’est ce que font les militaires pour marquer les documents sensibles et classifiés. C’est ce que font les industriels pour marquer leurs secrets industriels.

La difficulté ici c’est qu’il n’y a pas de marquage type. Chacun emploie ses propres références de marquages. Il faut donc permettre cette souplesse. De plus, les marques doivent s’additionner et non se remplacer.

On peut imaginer un nouvel objet réservé destiné à gérer les marquages et qui servirait comme champ méta dans les liens de marquage. Les liens de marquages, type l, feront le lien entre l’objet à marquer et un objet de marquage via l’objet de référence.
Peut-être que l’objet de marquage sera lui-même aussi un objet de référence de ce marquage en particulier. Ceci permet de gérer des attributs liés au marquage comme un nom long, un nom court, une couleur, etc…

L’étape suivante sera ensuite de faire apparaître les marquages autours des objets. Est-ce géré comme les messages d’information actuels ? Est-ce géré différemment pour être clairement différencié ? Comme sera géré le multi-marquage ?

Enfin, comme ce système de marquage aura un impact sur les performances, il sera activable au besoin mais pas par défaut.

Pour l’instant c’est une idée non encore implémentée…

Relais d’authentification sans partage de secret

mars 4th, 2019

Dans l’article sur les relais d’authentification, on a vu qu’il était possible très simplement de déverrouiller une entité sur un serveur distant en rejouant l’authentification. Mais cela implique de transmettre le mot de passe de cette entité. Et cela veut dire aussi que la clé privée est déverrouillée sur le serveur distant.

Il est théoriquement possible de réaliser un mécanisme d’authentification sans partage de secret. Dans ce cas une instance déverrouillée sur un serveur distant ne disposerait ni du mot de passe ni de la clé privée de l’entité. Il faut donc implémenter un mécanisme qui permette au serveur distant de venir interroger le serveur local avec la session de l’entité en cours. Le mot de passe de l’entité étant stocké dans le cache de la session PHP, il serait impossible au serveur distant de l’obtenir. Mais il peut dans ce cas accéder aux objets protégés et notamment aux secrets de chiffrement des objets. Pour les liens dissimulés c’est par contre plus complexe.

Avec un tel relai il est possible de se connecter sur un serveur distant sans divulguer son mot de passe tout en disposant de l’accès aux objets protégés et à la possibilité de signer des liens.

Un serveur distant compromis pourrait le temps de la session accéder aux objets protégés. Mais une fois la session fermée, dans la fenêtre du navigateur sur le serveur local, aucun autre objet protégé ne pourrait plus être ouvert. Au minimum, tous les nouveaux objets protégés ne seraient pas accessibles. Pour les plus anciens… ça dépend du temps d’ouverture de la session…

Relais d’authentification

mars 4th, 2019

Il est théoriquement possible depuis une instance d’une entité déverrouillée sur un serveur, local, de demander à ouvrir une nouvelle instance sur un autre serveur, distant. Cette authentification peut simplement être faite en rejouant le mot de passe de l’entité du serveur local. Il faut que le serveur distant connaisse l’entité et dispose de l’objet de la clé privée accessible avec le mot de passe. La nouvelle instance serait alors ouverte dans un nouvel onglet du navigateur.

Cela implique la transmission du mot de passe. Il faut impérativement passer par une connexion chiffrée (TLS) avec authentification (certificat) du serveur distant afin de protéger le transit du mot de passe.

Cela implique aussi que le serveur distant va connaître le mot de passe de l’entité, au moins le temps de la session. Il faut donc avoir autant confiance dans le serveur distant qu’en le serveur local.

Il est cependant possible aussi de transmettre le mot de passe d’une sous-entité vers le serveur distant. Ainsi on peut penser centraliser sur un serveur/périphérique local une entité maîtresse et ses sous-entité, et utiliser certaines sous-entités exclusivement sur des serveurs distants, y compris des serveurs de faible confiance.

Cela veut dire que l’on doit pouvoir associer une localisation avec une entité.

En fait, cela est très simple à réaliser. Il suffit de générer un lien HTTP vers le serveur distant avec en argument l’application, l’entité et le mot de passe… le tout dans un nouvel onglet.

Et en ajoutant dans le lien HTTP un mode et une vue il est même possible de chaîner l’authentification vers un troisième serveur. On a dans ce cas un niveau de relai d’authentification et un peu de dissimulation.

Ceci n’est pas implémenté. Suite au prochain épisode…

Éviter un projet de blockchain mort-né

mars 1st, 2019

L’article du blog de MultiChain.com intitulé « Avoiding the pointless blockchain project » fait le tour des points à respecter pour justifier la mise en place d’une blockchain dans un projet.

Il se trouve que les différents points sont concordants avec le projet nebule qui lui n’est pas une chaîne de blocs.

La lecture est intéressante. La blockchain peut être aussi privée, et donc pouvoir être localisée et non nécessiter d’être unique et synchronisée au niveau mondial. Mais dans ce cas se pose la question de la quantité suffisante de nœuds pour calculer et valider les blocs. Et si on revient vers des nœuds privés pour une blockchain privée, alors on perd l’intérêt d’une chaîne de blocs de transactions… et on revient sur un système avec un tiers de confiance.

Liens des options

février 26th, 2019

Le lien permettant de définir une option, si elle est autorisée à être modifiée, est constitué d’un type l, du nom de l’option, de sa valeur et d’un objet méta de référence nebule/option.

Cette forme de lien est bonne pour un usage locale et personnel des options. Mais il se prête mal à la gestion des options d’entités sous contrôle. Par exemple si on a un serveur de diffusion de contenu, on peut être amené à changer son comportement. Cette forme de lien impose dans ce cas de générer un lien avec l’entité instance du serveur… et donc de connaître obligatoirement son mot de passe.

Peut-être serait-il judicieux de changer maintenant la forme du lien pour inclure une entité. L’objet méta n’a pas grande utilité ici comme référence fixe. La référence pourrait devenir le nom de l’option… et les noms des options deviendraient des objets réservés.

Suite au prochain épisode…

Gestion du cache des objets et liens

février 25th, 2019

La bibliothèque nebule gère maintenant mieux le cache des objets et des liens.

Jusque là tous les objets et liens lus étaient mis en cache. Cela pouvait conduire assez rapidement à une dépassement de la mémoire disponible pour un processus PHP.

Maintenant l’option sessionBufferSize permet de limiter la taille du cache. Par défaut l’option est à 1000. Cette limitation est tout compris, que ce soit les liens ou les différents types d’objets.

Chaque entrée du cache est maintenant datée de sa création ou de sa dernière re-création, c’est à dire à chaque fois qu’elle est utilisée. Au besoin, une place est faite dans le cache pour la nouvelle entrée en supprimant la plus ancienne, càd celle qui n’a pas été utilisée depuis le plus longtemps.

Et en fait cela accélère le calcul des pages parce que l’on a moins de choses à recharger de la session PHP.

Options de désactivation de protection et de dissimulation

février 19th, 2019

La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.

Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :

  • permitProtectedObject : Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de type k.
  • permitObfuscatedLink : Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de type c.

Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.

Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.

Filtre social de liens sur réputation du signataire

février 15th, 2019

Dans les filtres sociaux des liens, deux nouveaux types sont ajoutés : reputation et unreputation

Cela permettra à terme le tri par rapport à la réputation d’une entité. Cependant, la pondération des entités n’étant pas implémentée, ces deux filtres sont pour l’instant équivalents au filtre social none.

Traitement social des liens sur liste

février 14th, 2019

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

Soi-même ou moi-même

février 13th, 2019

Dans la partie gestion sociale de la bibliothèque de nebule, il y avait peu de sous-parties dédiées à des calculs sociaux des liens. Il y avait notamment une partie self dédiée à la reconnaissance de ses propres liens, et son inverse notself pour exclure ses propres liens d’une recherche.

Cependant, la bibliothèque reconnait en quelque sorte deux type de soi. Il y a le soi de l’entité connectée et le soi de l’entité que l’on regarde. En quelque sorte un moi et un soi. Quand on désigne moi-même il est fait explicitement référence à ma personne, ou dans notre cas à son entité. Alors que le soi-même désigne le moi-même d’une personne, qui peut être quelqu’un d’autre, dans notre cas une autre entité.
Dans la bibliothèque, cette distinction apparaît dans la place de deux variables qui portent le même nom $currentEntity. Utilisée dans la classe très généraliste nebule, elle désigne l’entité connectée (déverrouillée). Utilisée dans la classe Applications elle désigne l’entité que l’on regarde, de la même façon que l’on désigne un objet que l’on regarde.

Cela a mené à devoir dissocier le traitement social pour refléter cette distinction. Ainsi self et notself références maintenant l’entité que l’on regarde (au travers d’une Application). Et myself et notmyself désigne l’entité connectée elle-même, c’est à dire l’entité active.

Ce comportement peut parraître subtil mais il prend tout son sens dans l’application messae et le module messagerie de sylabe. en effet, l’affichage de la liste des conversations se fait par rapport à une entité, donc des conversations de soi-même d’une entité. Mais si on ne précise pas d’entité alors c’est de l’entité connectée que l’on parle, donc soi-même.

D’autres types de traitement sociaux des liens seront ajoutés plus tard. Il faudra notamment trouver un moyen de pondérer les liens de ses amis…

Contenu de lien dissimulé

janvier 17th, 2019

Le lien dissimulé contient, tel que défini par l’article Anonymisation/dissimulation des liens, un lien complet signé. La vérification d’un lien chiffré nécessite de vérifier la signature du lien chiffré et du lien déchiffré.

Il est peut-être plus intéressant de ne mettre dans la partie dissimulée que le contenu du lien sans la partie signature, et donc sans la partie signataire. Ainsi, un lien dissimulé ne pourait pas être réutilisé hors du lien dissimulé puisque seul le lien dissimulé et signé.

Si on le rapport par exemple à un système d’élection (cf Sondages et votes), le lien d’attribution d’un ticket n’est ainsi plus partageable pour prouver un vote. Dans ce cas cela pourrait aussi être couplé à la méthode…. ah zut… l’article sur la méthode de PFS sans connexion n’a pas encore été écrit :'(

La suite au prochain épisode…