Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle et transcodage, voici le nommage des liens transcodés :
/l/HashEntitéDestinataire_HashObjetTranscodé
Cela répond aussi au problème du nettoyage puisque la forme du nom n’entre pas en conflit avec les ID des objets, il est discernable des fichiers de ségrégation des liens dissimulés et il est clairement rattaché à une entité.
La clé de transcodage ainsi que l’algorithme seront abordés plus tard.
La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.
L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.
La structure typique des dossiers de l’implémentation en bash :
/home/user
+-> /neb
+-> /pub
| +-> /l
| +-> /o
+-> /priv
+-> /l
+-> /o
Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.
Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité et ségrégation partielle, la réflexion et l’implémentation sur le stockage et l’échange des liens dissimulés progresse.
La méthode de ségrégation des liens dissimulés développée est suffisante pour retrouver les liens dissimulés et les partager. Mais si le partage est efficace parce que l’on ne récupère que les liens dissimulés des entités connues, la lecture des liens n’est clairement pas efficace.
Lors de la consultation des liens d’une objet particulier, il faut lire tous les liens de l’objet, facile, et lire l’intégralité des liens dissimulés parce que l’on ne sait pas à l’avance quelle entité à dissimulé des liens pour cet objet. Il manque de pouvoir localement (indépendamment du partage) stocker les liens en fonction des objets source, cible et méta. Mais il faut aussi ne pas dévoiler cette association d’objets cités dans la partie dissimulée du lien, ce qui permet rapidement de lever la partie dissimulée.
Il est possible de transcoder les identifiants des objets cités par le lien dissimulé. On parle bien de travailler toujours sur des fichiers de stockage dédiés aux liens dissimulés, et donc indépendamment des liens non dissimulés. Ce transcodage doit permettre de ne pas révéler l’association entre les objets cités par le lien dissimulé. Ce transcodage peut être commun à tous les objets avec une clé de codage commune, ou chaque objet peut disposer de sa propre clé de codage. Et bien sûr, chaque entité dispose de sa/ses clés de transcodage, donc chiffrées avec la clé privée.
Un transcodage avec une clé unique est plus facile puisque l’on peut chiffrer cette clé et la stocker à un endroit unique, mais il est moins sûr que le transcodage à clés individuelles.
Pour commencer on va partir sur la base de la clé unique de transcodage.
Les liens dissimulés dans des fichiers transcodés sont lisibles publiquement et peuvent potentiellement être synchronisés mais ils n’ont pas vocation à remplacer les liens dissimulés dans les fichiers dédiés à la ségrégation et utilisés lors du partage des liens.
Le nettoyage des fichiers des liens dissimulés et transcodés devient un nouveau problème.
Plusieurs entités pouvant localement générer des liens dissimulés, et donc utiliser des clés de transcodage différentes, il n’y a pas de méthode de nettoyage générique des liens dissimulés dans les fichiers transcodés. Seule une entité peut faire le nettoyage de ses propres fichiers transcodés. Il faut donc que ces fichiers transcodés soient clairement associés à une entité.
Il est possible par contre de supprimer tous les fichiers transcodés d’une entité (ou plus). Il faut dans ce cas que l’entité, une fois déverrouillée, reconstitue ses fichiers transcodés.
Cela lève un nouveau problème, comment savoir que tous les fichiers transcodés sont présents et qu’ils sont à jour. Avec cette méthode, il ne faut pas que les fichiers dédiés à la ségrégation des liens dissimulés pour une entité soient manipulés par une autre entité parce que les fichiers transcodés ne seront pas synchrones. Et les transferts ne sont pas possibles.
Les entités ne doivent pas synchroniser les liens dissimulés des autres entités !
Il reste encore des réflexions à mener autour de cette méthode de transcodage.
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.
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.
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.
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…
Nouveau schéma du lien dissimulé :
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…
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.
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…
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à …
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…
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…
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…
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…
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.
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…
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.
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.
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.