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…

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

janvier 17th, 2019

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

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

Bonne année 2019

janvier 13th, 2019

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

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

Par rapport à début 2018, la réorganisation de la partie graphique est bien avancée. De nouvelles réflexions se font sur une possible implémentation de crypto-monaie basée sur nebule, et donc sur la réliance que l’on peut en espérer. Les réflexions continent aussi sur la réorganisation des rôles provilégiés par groupes.

La documentation technique de nebule migre maintenant vers une pseudo-application dédiée gérée par le bootstrap. Mais la documentation est en fait contenu, et mise à jour, par la bibliothèque.

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

décembre 20th, 2018

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

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

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

L’évolution des applications

novembre 12th, 2018

Une installation de l’application Facebook actuel sur un téléphone vieux de 6 ans montre les errements et la dérive des applications.

En 6 ans, l’interface à changée un peu avec quelques fonctionnalitées… Mais au fait, les utilise-t-on vraiement ? Non. On continue à utiliser majoritairement Facebook comme avant, ce pour quoi il a été fait. Les nouvelles fonctionnalitées tiennent plus du cosmétique. Quelques imports d’autres applications (hashtag, stories) peinnent à percer, rien de révolutionnaire.

Depuis tout ce temps, le code aurais dû être optimisé de folie, accéléré… et bien c’est tout l’inverse, ça rame sévèrement sur un vieux téléphone. et pourtant ce que l’on faisait sur Facebook à cette époque pas si lointaine reste similaire.

La puissance des machines commence à stagner, voila donc l’exemple à ne pas suivre.

Blockchain, billets et valeur

octobre 25th, 2018

Dans la réflexion sur l’implémentation d’un équivalent de blockchain dans nebule, il apparaît un problème qui n’est pas vraiment technique.

La blockchain permet de transmettre des billets électroniques sous la forme de transactions dans des blocs. Avec nebule, on peut utiliser les liens comme transactions et des objets prenants le rôle de billet électroniques, ou utiliser des objets de transactions pour des objets portants de la valeur. Dans les deux cas on peut le faire avec un mécanisme assurant de la confiance dans les transactions.

Chaque billet est porteur d’une valeur. Cette valeur n’est pas fixe, c’est juste une convention, et elle va dépendre de plusieurs paramètres. Le volume de billets pouvant évoluer avec le temps, à la hausse, la valeur de chaque billet va naturellement baisser juste du fait de l’augmentation des billets pour une valeur globale constante. Cette valeur monétaire peut évoluer aussi dans le temps avec les transactions d’achat ou de revente des billets eux-même, indépendamment de la valeur d’origine qu’ils représentaient.

Or si cette valeur monétaire peut évoluer dans le temps, elle doit malgré tout être initialisée à un moment. On passe par exemple d’un objet physique ayant une valeur d’usage à une monnaie qui transporte cette valeur initiale. Il y a une sorte d’échange de valeur entre un objet physique et un objet virtuel. Mais comment vas-t-on faire pour générer des billets décentralisés de façon à permettre l’échange de valeur ? Les billets doivent-ils pré-exister ?

Création d’objet et dissimulation des liens

septembre 23rd, 2018

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Non vérification crypto et lecture seule – Centre de données et répartition

septembre 15th, 2018

Suite de l’article sur la Non vérification crypto et lecture seule.

Le problème des très gros objets peut être résolu avec un fonctionnement segmenté de l’application. D’un côté on a l’application principale qui structure et délivre des informations aux utilisateurs, par exemple la page de diffusion des vidéos. Et de l’autre un serveur uniquement dédié au stockage des objets volumineux.

L’application principale peut fonctionner classiquement sur une ou plusieurs instances et faire référence à du contenu, y compris volumineux, hébergé sur un autre serveur. Le contenu est constitué d’objets parfaitement référencés par leurs empreintes et dont l’usage est définit par des liens. On ne fait là qu’exporter le problème des gros objets.

Un serveur uniquement dédié au stockage des objets volumineux va devoir résoudre le problème de la vérification des objets volumineux sans avoir à se poser de question sur leurs pertinences. La pertinence des données, ce sont les applications qui la gère avec les liens. Ce serveur devient ainsi un centre de distribution de données (CDN) dont la stratégie de vérification peut être adaptée. Et là, l’usage des instances sur ces serveurs étant très restreint en fonctionnalité, il est possible d’alléger la vérification des objets. La vérification peut ne plus être systématique avant un téléchargement par un client mais peut être préprogrammée périodiquement lors de faibles sollicitations. Cela veut dire qu’il faut faire confiance à un serveur qui, peut-être, n’est pas entièrement sous contrôle. Il reste possible bien sûr de vérifier la validité des objets après téléchargement.

Reste un petit engrenage à ajouter là dedans. Il faut que la ou les applications, dans des instances différentes, soient capable non seulement de manipuler la référence d’un objet volumineux sans l’avoir effectivement à portée, mais soient aussi capable de faire pointer l’utilisateur sur le bon point de stockage de l’objet volumineux. C’est à dire qu’elles soient capable de désigner le bon centre de données au bon moment.
Pour cela, soit chaque application dispose d’une configuration définissant quel (unique) centre de données utiliser pour les objets dont la taille (défini par un lien de propriété) est supérieure à une limite de vérification. Soit l’application crée un lien (de propriété) définissant pour chaque objet volumineux sur quel centre de données il est disponible. La première solution est la plus simple, la seconde est la plus souple, et les deux peuvent cohabiter.

L’air de rien, le lien définissant sur quel centre de données est disponible un objet volumineux, la deuxième solution, existe déjà. Pour une entité il est possible de définir un lien avec pour objet méta ‘nebule/objet/entite/localisation‘ afin de donner des points de présences d’une entité. Cet objet méta réservé, non utilisé aujourd’hui, pourrait être abandonné et directement remplacé par l’objet méta ‘nebule/objet/localisation‘ plus générique. Ça tombe bien, ce dernier existe déjà… ne reste maintenant qu’à l’implémenter dans le code…

Non vérification crypto et lecture seule

août 12th, 2018

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.