Catégorie : Réflexions

Identification de cosignataires

Suite de l’article Cosignature – méthode de surcharge des signatures.

Si la surcharge de signature dans le champs signature ne pose pas de problème, la désignation des entités signataires successives et leur ordre est plus complexe.

La première méthode proposée consistait à placer pour commencer l’ID de la pseudo entité co-signataire puis à concatèner successivement et dans l’ordre de signature les ID des entités signataires.

Mais si cela paraît suffisant pour retrouver les identifiants des différents signataires, la méthode n’est pas propre parce que l’on a un tas par défaut non structuré des entités signataires, informe. Et il peut être difficile de savoir que le lien est sur-signé en l’absence de signe clair.

Il est plus judicieux d’introduire un séparateur dans le champs signataire. La présence du séparateur implique automatiquement que le lien est sur-signé. Mais cela impose de revoir le code de validation et de traitement des liens.

Il est aussi possible de considérer les consignataires comme un groupe. Cependant la pseudo entité co-signataire ne peut pas être utilisée comme groupe parce que toutes les entités la constituant n’ont pas forcément signé le lien et ensuite parce que l’ordre de sur-signature n’est pas forcément cohérent avec l’ordre des entités, et le respect de l’ordre de vérification des signatures est indispensable. On peut imaginer aussi créer un groupe enfant du groupe de fait constitué par la pseudo entité co-signataire mais cela veut dire en pleine vérification des liens de synchroniser et lire un objet, donc conceptuellement de remonter d’un niveau. Donc ce n’est pas applicable.

Export des articles de blockchain et transaction vers le blog de qantion

Les projets développés autour de nebule avaient peu de réflexions propres et les différentes réflexions revenaient invariablement à la gestion d’information, donc vers le blog de nebule. Il n’en est pas tout à fait de même pour les réflexions sur la blockchain et les transactions qui sont souvent propres au projet qantion aujourd’hui mis en place.

Afin de garder une cohérence dans les réflexions menées sur le nouveau blog dédié à qantion, les différentes articles du blog de nebule traitants de blockchain et de transactions ont été dupliqués ici et anti-datés.

Toutes nouvelles réflexions liées à la blockchain ou aux transactions seront faites sur le blog de qantion, et seront dupliquées ici si elles intègrent aussi une réflexion de portée plus fondamentale sur la gestion d’information.

Lien à quatre champs objets ?

Les réflexions initiales avaient montré qu’il était impossible de créer des liens entre objets de seulement deux champs, c’est à dire juste objet source et objet destination. Enfin, c’est possible mais ça n’est pas utilisable puisqu’il faut pouvoir indiquer dans le lien la relation faite entre les deux objets.

Le champs méta décrit la relation entre les deux objets source et destination. Ce champs méta est vu comme une information à propos de l’information principale, donc une méta donnée. Mais avec le temps il apparaît plus comme ayant le rôle d’objet opérateur, c’est à dire un descripteur de l’opération entre les objets source et destination.

La réflexion autour de la crypto-monnaie et de la messagerie pousse à considérer qu’un champs supplémentaire pourrait être utile comme contexte, c’est à dire de contextualisation du lien par rapport à un usage.

Un des usages serait par exemple la définition d’une option des applications. Ce lien contient en champs source le nom de l’option, en champs cible la valeur attribuée à l’option et en champs méta le fait que ce soit une option. Ajouter un champs permettrait de définir une option pour une autre entité.

Cependant le besoin d’un nouveau champs peut être aussi le signe d’une mauvaise structure de liens. Par exemple le champs méta du lien de définition d’une option est redondant avec son champs cible qui désigne une option particulière, sous-ensemble des options.

Et rajouter un quatrième champs aux lien va nécessiter la revu de tout le code actuel pour tenir compte de ce champs.

Il avait été pesé au début la possibilité, à l’extrême, de ne pas avoir de limite (ou en avoir une mais large) du nombre de champs. Cette façon de travailler aurait ralenti le code et il en aurait surtout résulté une perte de performance à cause d’une non optimisation des liens.

Quoiqu’il en soit, plus le temps passe plus la modification de la structure des liens deviendra délicate. Mais le gain aujourd’hui n’est pas jugé suffisant par rapport au travail à fournir pour évoluer vers des liens à quatre champs.

Cosignature et validation de transactions

Un mécanisme de cosignature fonctionnant sur le principe de quota peut être une réponse possible à la validation de transactions dans un groupe fermé d’entités. La difficulté est que chaque entité peut ne pas reconnaître la même composition du groupe du fait du traitement social des liens du groupe. Mais si le groupe est explicitement définit dans l’objet de groupe avec le quota attendu, alors cela devient jouable…

Transcodage et translation

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.

Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.

Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.

Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

PFS et liens dissimulés

La méthode de PFS sans connexion spécifique à nebule est sensible à la capture de trafic ou la surveillance des créations de fichiers directement sur un serveur compromis. C’est aussi vrai en regardant simplement la date des fichiers.

L’article décrivant le mécanisme est encore à rédiger.

Cependant, peut-être que la dissimulation de liens et le travail sur une système de fichier sans mémoire temporelle peuvent aider à renforcer cette PFS. A voir…

Monnaies, transactions et individus

Il existe deux méthodes pour gérer les échanges de valeurs entre deux entités, ou individus.
La première consiste à suivre des objets définis comme de la monnaie et de faire des transactions de réattribution de ces objets entre entités. Le solde pour une entité est l’addition de la valeur tous les objets de monnaie en possession de l’entité.
La seconde consiste à suivre pour chaque entité un indicateur de balance de la valeur dont dispose chaque entité. Le solde est à lecture immédiate et toute transaction consiste en la soustraction d’une valeur sur un compte couplé à l’addition de la même valeur sur un autre compte.

La seconde méthode ne fonctionne pas ou très mal dans le cadre d’une cryptomonnaie sans intermédiaire de confiance, c’est à dire sans une banque pour centraliser le compteur des valeurs des comptes. La transmission de valeur devient complètement impossible sans échange avec l’intermédiaire de confiance.
Mais la première méthode n’est pas forcément mieux loti. Elle permet dans le monde réel un échange de billets sans passer par un intermédiaire de confiance. Mais dans le monde informationnel (dit aussi virtuel ou numérique), la propriété d’unicité spatial et temporel n’existe plus. Et donc il faut sceller à la vue de tous une transaction avec un intermédiaire de confiance. Celui-ci peut être une chaîne de blocs, ça ne fait que décaler l’intermédiaire de confiance vers le code et ses concepteurs.

Continuons sur la réflexion d’une cryptomonnaie.
On voit aujourd’hui plusieurs acteurs étatique ou organisationnels générer de la monnaie virtuelle et/ou revendiquer sa régulation. L’extrême limite de cette pratique serait que tout le monde puisse générer sa propre monnaie… et donc qu’il y ai des taux de change entre les monnaies de tous les individus.

Chaque individu et chaque robot peut justifier d’une certaine quantité de travail par unité de temps, par exemple on peut supposer que l’humain dispose de 16 heures d’activité par jours. Dans ces 16 heures, on va réduire à 8 heures la part allouable à autrui. Mais cette capacité de travail n’a pas de valeur directe, ce n’est pas parce que l’on a une capacité de travail de 8 heures par jour que l’on va travailler 8 heures par jour. Cependant, chaque individu peut générer chaque jours une valeur, comme une monnaie, qui représente la capacité de travail journalier. Appelons la monnaie temporelle.
Il reste encore à donner de la valeur à cette monnaie temporelle.
D’un autre côté nous retrouvons des entreprises, regroupement d’individus, qui utilisent le temps de travail disponible des individus sur un patrimoine constitué d’outils de travail ou de données afin de transformer des objets, et donc d’ajouter de la valeur. Nous pourrions associer la monnaie temporelle des différents employés avec une sorte de monnaie patrimoniale afin de dégager une monnaie véhiculant de la valeur, laquelle monnaie serait rétrocédée en partie aux employés.
Comment seraient représentées ces différentes monnaies dans un système d’information ?

La réflexion n’est pas terminée…

Cosignature Рm̩thode de surcharge des signatures

Dans la continuité de la réflexion sur la cosignature, suite et orientation, voici une première réflexion sur un méthode alternative.

Une autre méthode est possible afin de remplir de rôle de co-signataires multiples à seuil sans répartition d’un unique secret saucissonné entre plusieurs entités ni nécessité de colocalisation spatial et temporel des entités signataires.

Le point de départ est un objet contenant la liste des combinaisons possibles de cosignatures, c’est à dire les différentes associations de signatures d’entités reconnues valides. La syntaxe de définition de ces associations peut prendre différentes formes. Soit on écrit toutes les associations des entités signataires possibles, soit on écrit les identifiants des entités signataires et la règle de quota attendu.

La signature d’un lien nécessite de s’accorder sur le champ de la valeur de la signature et sur le champ de l’entité signataire.

Le cÅ“ur de la méthode est de réaliser une surcharge progressive des signatures des différentes entités co-signataires jusqu’à obtenir le quota d’une combinaison valide. Cette surcharge est une sur-signature progressive du lien par les entités. Une première entité signe le lien, une seconde entité signe la valeur de la signature de la première, une troisième signe la valeur de la signature de la seconde, etc…
La signature n’étant pas une opération commutative, la vérification de la signature finale doit être vérifiée en réalisant les opérations successives de vérification de signatures avec les clés publiques des entités, mais en sens inverse des signatures. Le cas de tailles de clés différentes n’est ici pas traité.

Comme on réalise une sur-signature progressive et que l’ordre est important, il faut que cet ordre des entités signataires apparaisse quelque part. Il faut aussi que l’on fasse apparaître l’identifiant (ID ou hash) de la pseudo entité co-signataire. Pour cela on va utiliser le champ signataire. On place pour commencer l’ID de la pseudo entité co-signataire puis on concatène successivement et dans l’ordre de signature les ID des entités signataires.

Ce mécanisme nécessite à priori la réunion des différents signataires, ou d’une partie suffisante, afin de réaliser la signature du lien. Il est cependant possible de constituer progressivement la cosignature en sur-signant la signature commune et en s’ajoutant à l’entité signataire finale. Nous répondons bien dans ce cas à une cosignature sans colocalisation spatial ni temporel.

Billets et entité

La réflexion continue autour d’une implémentation d’une monnaie virtuelle.

L’idée que le billet électronique est une entité, donc un bi-clé cryptographique, est intéressante à étudier. Cela permet de le rendre autonome mais il faut dans ce cas considérer que sa clé privée devient publique ou connue de plusieurs autres entités, ce qui revient au même. On ne peut donc pas supprimer la nécessité de gérer la confiance via un tier de confiance ou une chaîne de blocs pour consolider le graphe des transactions.

Mais si ce billet électronique est constitué de la chaîne des entités du billets, alors on a un mécanisme d’anonymisation.

Lien de transaction

La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.

Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?

Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…

Et comment gère-t-on l’oubli volontaire de ces liens ?

Anonymisation des fichiers transcodés

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage et Transcodage des liens dissimulés, il apparaît un problème avec le contenu des fichiers transcodés.

Le fait qu’une entité synchronise des liens dissimulés que d’autres entités partagent et les range dans des fichiers transcodés peut révéler l’ID de l’objet transcodé. Et par tâtonnement on peut retourner ainsi le transcodage de tous les objets.

Il suffit qu’une entité attaquante génère un lien dissimulé à destination d’une entité attaquée concernant un objet en particulier. L’entité attaquée va alors ranger le lien dissimulé dans le fichier transcodé. L’entité attaquante peut alors rechercher quel fichier transcodé contient sont lien dissimulé et en déduire que ce fichier transcodé correspond à l’objet.

En plus, si le lien dissimulé n’a aucune action valable, il ne sera pas exploité, donc pas détecté par l’entité attaquée.

Il faut trouver une parade. Peut-être que l’on peut chiffrer les fichiers transcodé avec la clé de transcodage. A voir…

L’algorithme de transcodage doit être non réversible.

Transcodage des liens dissimulés

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.

Dissimulation, transcodage et dossier privé

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.

Anonymisation/dissimulation des liens – transcodage

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.

Implémentation de la gestion des liens dissimulés

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

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

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

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…

Liens hypertexte et insertions

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.