Archive for the ‘stockage’ Category

PFS sans connexion

Lundi, mai 22nd, 2017

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

Suppression et oubli

Mardi, décembre 13th, 2016

Comme évoqué il y a déjà un certain temps dans l’article sur Le paradoxe du droit à l’oubli, il n’est pas évident du tout que la suppression pure et simple d’une information soit généralement la meilleur solution.

Pour les individus, l’oubli d’une information est vu soit comme un trouble cognitif soit comme une nécessité. C’est un problème si l’information que l’on avait acquise n’est plus disponible alors que l’on en a grand besoin. Les personnes qui perdent la mémoire perdent toute autonomie. D’un autre côté, se souvenir de tout est aussi un problème. La trop grande quantité d’information sur des évènements sans intérêt perturbe la vie courante.

Dans nebule, la suppression des objets répond à deux besoins. Le premier besoin correspond à la récupération de la place mémoire pour stocker d’autres objets plus récents et à priori plus importants. Et le deuxième permet surtout dans la vie courante de ne pas se surcharger d’informations qui n’ont pas d’intérêt immédiat… voir plus d’intérêt du tout.

Mais cette suppression qui est une manière courante de travailler en informatique n’est elle pas problématique ?
L’oubli est la vraie raison de la suppression des objets. Un autre mécanisme doit être trouvé pour remplacer la nécessité de supprimer des objets. Le retrait des liens attachés à un objet ne supprime pas ces liens mais les enlève de l’usage courant. La pondération des émotions d’un objet et le traitement qu’il en est fait permet de gérer aussi le bannissement dans un contexte social des entités.

Le sujet devra être approfondi avant tout mise en applications…

Renforcement de la lecture des objets

Jeudi, novembre 17th, 2016

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

La sécurité des suppressions de données

Lundi, février 9th, 2015

Le piratage de Sony Pictures a provoqué une véritable onde de choc dont les ramifications sont parfois inattendues. L’article The Security of Data Deletion de Bruce Schneier fait l’apologie d’une stratégie ‘agressive’ de suppression des données obsolètes dans les entreprises. Puisqu’il n’est pas possible de garantir la confidentialité des données d’une entreprise, même une parmi les plus grosses, il est préférable de supprimer ces données lorsqu’elles sont obsolètes.

On peut aussi parler de l’intégrité puisque si un pirate a réussi à récupérer quelques téraoctets de données sans se faire prendre, il a tout aussi bien pu en altérer au passage. Si la cryptographie peut nous aider à ce niveau pour signer les données et messages, elle ne pourra pas grand chose si les postes utilisateurs, leurs programmes et donc leurs clés sont compromises…

Mais revenons à la politique de suppression des données. Parler de politique agressive est un peu exagéré. La notion d’agressivité sous-entend de supprimer dès que possible une donnée lorsqu’elle n’est plus utilisé. Il est fait référence dans l’article à ce que l’on transmettait par téléphone avant l’informatique, les informations annexes que l’on ne notaient pas finissaient par être rapidement oubliées, au pire déformées… ou au mieux sujettes à confirmation.

Si la messagerie instantanée est assez informelle, la messagerie classique est beaucoup plus formelle, surtout en entreprise. On est dans ce dernier cas assez loin de la conversation libre par téléphone.

Une entreprise ne peut pas non plus supprimer sans discernement ses données sous prétexte qu’à un instant donné elles n’ont plus d’utilité. Ces données, c’est la mémoire de l’entreprise. Les supprimer c’est supprimer la mémoire de l’entreprise, une des choses les plus importantes puisque c’est l’accumulation de son savoir faire, de son savoir sur ses clients et ses racines. Supprimer les données anciennes d’une entreprise, c’est comme supprimer la mémoire à long terme des individus, c’est catastrophique pour eux et pour la société dans son ensemble.

Ce parallèle avec l’individu n’est pas anodin. La capacité d’une entreprise c’est la somme des individus qui la composent démultiplié par le patrimoine technique.
Et le parallèle peut aller plus loin. L’individu ne retiendra pas tout d’une conversation téléphonique. Des informations annexes seront perdus parce que non mémorisées par l’un ou l’autre des interlocuteurs. Ensuite, avec le temps, chaque interlocuteur va oublier certaines informations pas très importantes, progressivement. Au final, après un grand laps de temps, il ne subsistera de la conversation téléphonique que l’essentiel de l’information. Il faut donc bien de la même façon supprimer les données éphémères d’une entreprise mais il ne faut pas tout supprimer. Avec le temps, seul doit subsister l’essentiel des informations du passé. Les idées doivent être résumées et les informations techniques doivent être épurées de leurs pré-calcul et des données annexes.
Comme fil conducteur, on peut essayer d’avoir la vision d’un historien sur le passé de l’entreprise pour savoir ce qui a de l’intérêt ou pas. Et ainsi, naturellement, toutes les conversations hors champs vont disparaitre.

Tel que déjà définit précédemment pour le projet nebule, les données doivent pouvoir être supprimer automatiquement après un certain délai ou conservées explicitement. Une pondération appliqué aux objets déterminera le délai de conservation, ou plutôt de non-suppression. Et un seuil déterminera à partir de quelle pondération un objet sera à garder définitivement. Ce seuil peut évoluer avec le temps et faire disparaitre après coup des objets qui initialement étaient au dessus du seuil de suppression. La pondération reflète l’importance des objets, positivement ou négativement.

Pour finir, n’est-il pas plus simple d’être respectueux dans ses messages même à usage interne ? A défaut d’empêcher le vol d’information, au moins on évite déjà les propos embarrassants, une charge de moins dans la réparation des dégâts. Mais quelque part, cela reflète un état d’esprit dans l’entreprise, une certaine culture des individus qui la composent… bref, pas très sain…

Arborescence virtuelle

Samedi, novembre 29th, 2014

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki – Réflexion – analyse des applications – Système de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Lien de type d, précisions

Mercredi, juillet 9th, 2014

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

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

d comme delete.

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

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

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

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

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

Supprimer un grand nombre d’objets anciens

Vendredi, mai 2nd, 2014

La fonction d’oubli, bien qu’indispensable, n’est pas encore en place. Elle nécessite la mise en place préalable de la pondération sur les objets. Cette pondération est elle-même un dérivé des avis et émotions.

En attendant, il peut être nécessaire de supprimer un grand nombre d’objets anciens et qui perdent vite de la valeur avec le temps. Typiquement cela concerne les sauvegardes d’un serveur. Les sauvegardes ont une forte utilité mais seule la dernière en date a vraiment de l’importance. Tout au plus peut-on garder des sauvegardes plus anciennes pour pouvoir remonter dans le temps, au cas où. Mais si on fait une sauvegarde journalière, la plupart des sauvegardes n’ont plus d’intérêt après quelques jours, voir le lendemain.

Voici comment supprimer des objets par lot dans nebule, et surtout en bash.

1 Lister

Première étape, lister tous les objets que l’on souhaite ‘oublier’. Ici, les objets sont ceux qui font plus de 10Mo et qui sont anciens de plus de 90 jours.
Lancer :
find pub/o/ -mtime +90 -size +10M | cut -d '/' -f 3 > aSupprimer.txt

Le fichier aSupprimer.txt contient la liste des objets qui répondent aux critères. Il serait tentant de supprimer directement les fichiers, mais ceux-ci pourraient réapparaître suite à une synchronisation. Il est préférable de les marquer supprimés.

2 Supprimer

Deuxième étape, faire supprimer et marquer comme supprimés les objets précédemment listés.
Lancer :
. lib_nebule.sh
. env.sh
export nebule_publ_entite=$(cat pub/e)
export nebule_priv_entite=$(cat priv/e)
read -s -p "Mot de passe : " nebule_pass_entite
nebCheckKeyPass
cat aSupprimer.txt | while read O ; do echo $O ; _l_wr $(_l_gen 0 d $O 0 0) ; rm pub/o/$O ; done

Et voila, les objets sont supprimés et marqués comme supprimés. Le fichier aSupprimer.txt peut être lui aussi supprimé…

Multi-entité et suppression d’objet

Dimanche, novembre 17th, 2013

A l’origine, le projet nebule s’appliquait à des entités autonomes. C’est à dire que les entités fonctionnaient localement dans un environnement réservé et ne dépendaient pas d’une entité maître.
Cependant, ces deux points ne sont plus assurés. Le cas du projet sylabe montre que de multiples entités peuvent coexister sur un serveur et surtout dans le même environnement. Ce pourrait être le cas aussi dans une famille qui utilise le même ordinateur, et donc le même environnement. La sûreté de fonctionnement veut que les objets publiques soient partagés pour économiser des ressources, et que les objets protégés ne soient à aucun moment disponibles aux entités qui n’ont pas la clé de déchiffrement.
De plus, pour assurer des transferts anonymisés, il est nécessaire de créer des entités dédiées à ce rôle. Ces entités ne doivent pas avoir de lien avec la véritable entité d’un utilisateur. Mais cet utilisateur doit pouvoir gérer ces entités esclaves et notamment détenir les mots de passe de celles-ci. Il se crée donc une petite hiérarchie d’entités. Il reste à assurer la non-liaison entre l’entité maître et les entités esclaves. Il faut penser que ce lien peut être remonté par les liens de type l, f, u, k, et e… sauf à les chiffrer…
A voir.

Suite à la réflexion sur le nettoyage des liens, et suite, l’expérience de sylabe montre que la suppression des objets en environnement partagé n’est pas évident. En effet, si je décide de supprimer un objet et un certain nombre de liens affairant, que ce passe-t-il ?
Pour les liens, ce n’est pas grave puisque ce sont mes liens. Les autres entités sont sensées disposer de leurs propres liens.
Pour l’objet, peut-être qu’une autre entité s’en sert aussi. Le supprimer sans concertation n’est pas la bonne méthode. Demander une concertation est inimaginable, surtout si certaines entités effectivement disponibles sur un serveur ne sont en fait plus utilisées.
Il se pose une question sur l’appartenance de l’objet. On pourrait très bien supprimer un objet du serveur, si une autre entité en a besoin elle le synchronisera simplement ailleurs et du coup il réapparaîtra sur le serveur. C’est aussi potentiellement un déni de disponibilité si cet objet n’est présent que sur ce serveur ou si on arrive à demander simultanément la suppression sur tous les serveurs hébergeant cet objet. D’après la théorie, un objet n’appartient à personne contrairement aux liens.

La suppression d’un objet qui pose un vrai problème de sécurité ou de droit d’utilisation dans un pays peut être géré de façon exceptionnelle. L’entité à qui appartient le serveur peut se voir disposer du pouvoir de suppression améliorée d’objets sur son serveur ainsi que la possibilité de le placer en liste de bannissement. Il faut de toute façon mettre en place la gestion de la liste de bannissement de l’entité cerberus : nebule/danger.

Localisation de fichiers

Samedi, mars 30th, 2013

Une étape importante dans l’utilisation de nebule, c’est d’importer des données. Ces données sont typiquement des fichiers existants. Cette opération d’importation de fichiers, c’est la nébulisation de fichiers.

La nébulisation de fichiers ne présente pas à priori de difficultés. On calcule son empreinte et on lui associe tout un tas d’informations telles que son type mime, sa taille, etc…

Il y a cependant une propriété des fichiers qui pose un problème.
Un fichier est classiquement reconnu par son nom. ce nom est une propriété du fichier au même titre que sa taille par exemple. L’extension de fichier n’est qu’un indicateur, peu fiable, de son type. L’extension de fichier est repris comme suffixe du nom.
Il peut y avoir plusieurs fichiers qui portent le même nom (et même suffixe) et qui ont ou non le même contenu. Ils doivent dans ce cas être disposés dans des emplacements différents. Cet emplacement peut être repris comme préfixe. L’emplacement est la traduction textuelle de l’arborescence de répertoires dans lequel se trouve un fichier. Et l’emplacement peut être soit relatif (à un autre emplacement), soit absolu. Dans tous les cas, il fait implicitement ou explicitement référence au disque, la distinction entre les deux dépendant de la notation faite par les différents systèmes d’exploitations. Nous ne prendrons ici que l’emplacement absolu, seul à pouvoir discriminer de façon certaine deux fichiers au même nom.
On peut aussi avoir deux fichiers de même nom/suffixe dans le même répertoire, mais sur deux machines différentes. Dans les différentes notations, il est donc préférable de se restreindre à l’utilisation de notations impliquant le nom de machine. Sinon on risque de pouvoir restaurer correctement un fichier en cas de besoin (si c’est le but).

Le problème de la notation des noms de fichiers peut se poser aussi dans le cas de deux fichiers identiques au même emplacement sur deux machines différentes. Si un des fichiers est modifié, cela va entraîner la création d’un lien u pour l’objet correspondant. Si rien ne distingue les deux fichiers, cela implique que l’autre fichier non modifié sera marqué comme lui aussi modifié…

Références :
Nebule blog – Empreinte d’objets et URI
Nebule blog – Fiches perforées
- Nebule blog – Fichiers et chemins
Nebule blog – Système de fichiers
Nebule wiki – Réflexion – analyse des applications – Système de fichiers

Le lien et la subdivision d’objet

Mercredi, janvier 30th, 2013

Un lien particulier avec pour action ‘s‘ permet de faire de la subdivision d’objet. A quoi cela sert-il ?

Il y a deux usages possibles de cette action.

Le premier usage est de permettre de scinder un objet volumineux en une multitude de morceaux, une multitude d’objet plus petits. Ces objets dérivés peuvent avoir des tailles identiques ou non. Ils doivent impérativement être non recouvrants et parcourir l’intégralité de l’objet parent.
En scindant un objet volumineux, il peut être transféré par morceaux vers différents emplacement (d’autres entités). Et donc une autre entité peut simultanément télécharger les multiples morceaux à des emplacements différents. Une fois tous les morceaux rassemblés, l’objet parent, l’original, peut être reconstitué.
C’est une des techniques nécessaires au fonctionnement du P2P par exemple.

Le deuxième usage, c’est de ne faire qu’un seul objet dérivé d’un objet parent plus grand. Cet objet dérivé fonctionne alors comme un extrait de l’objet parent. On ne peut pas reconstituer l’intégralité de l’objet parent à partir de l’objet dérivé.
Bien sûr, plusieurs extraits d’un objet peuvent être faits. Et un extrait plus petit encore peut être retiré d’un autre extrait. Rien ne limite le nombre d’objets dérivés. Rien ne garanti leur non-recouvrement ni qu’ils parcourent l’intégralité de l’objet parent.
L’usage peut par exemple être l’extrait d’une citation dans un livre, un extrait d’une musique, etc…

Actuellement, une subdivision est référencée par un objet contenant une et une seule ligne de type x-y. Mais peut-être serait-il intéressant de permettre plusieurs lignes de type x-y, cela créant un extrait contenant directement la concaténation des différents extraits d’un objet. Quel usage ?

Fragmentation d’objets

Dimanche, décembre 9th, 2012

Un des processus pas forcément nécessaire mais assez important avec le P2P, c’est le sous-découpage des fichiers.

Un serveur diffuse des petits morceaux de fichiers bien référencés mais sans nécessairement avoir tous les fragments. Un client télécharge des fragments différents. Chaque fragments en cours de téléchargement le sont à partir d’autant de serveurs différents. Cela permet d’accumuler progressivement tous les fragments d’un fichier pour le reconstituer à la fin. Et cela permet aussi de télécharger un fichier plus rapidement que si il était téléchargé sur un seul serveur dont la bande passant en upload est bridée.

La fragmentation est déjà possible avec le système de liens actuels de nebule. Mais la gestion de cette fragmentation pourrait être améliorée si on créait un lien spécifique pour désigner les fragments d’un objet. Ce serait le septième type de liens. L’échange des objets dans nebule s’en trouverait amélioré.

L’idée est intéressante, à voir…

Empilement de liens

Mercredi, décembre 5th, 2012

Dans les expériences nebule menées jusque là, les liens ont toujours été attachés aux objets concernés. Et dans une arborescence n’était pris en compte que les liens générés par l’entité maître de cette arborescence. Ainsi les liens générés par une autre entité se sont retrouvés dans une sous arborescence rattachée à cette autre entité. Une arborescence globale découle de l’entité maître et de toutes les entités qu’elle connaît.

De cette façon de procéder résulte une organisation très propre des entités, objets et liens. Cependant, celle-ci n’est pas optimale.

Ainsi, les objets peuvent se retrouver stocké à plusieurs endroits différents de l’arborescence globale. Les liens symboliques sous UNIX/Linux résolvent en pratique ce problème et permettent de ne garder qu’un seul point de stockage par objet, mais ce n’est pas très sexy intellectuellement parlant.

De même, des liens concernant mon entité propre par exemple sont stockés dans l’arborescence de mon entité. Mais il en existe aussi dans une sous arborescence d’une autre entité qui dispose d’une copie de mon entité et a fait ses propres liens sur moi…

Comme le stockage des objets le suggère, il paraît plus opportun de ne créer qu’une seule arborescence très limitée en profondeur. Tout se retrouve au même niveau. Cela résout la dispersion des objets et rassemble près de l’objet tous les liens de toutes les entités que l’on connaît.

Si je souhaite voir tous les liens d’un objet, et donc aussi tout ce que les autres entités en ont fait, la lecture est plus rapide.

Si je souhaite ne voir que mes liens, je filtre sur le champs signataire des liens. Ça ne pose pas de problème.

A quelle entité appartient l’arborescence? Le problème existait déjà, il faut maintenir une valeur particulière désignant sans ambiguïté l’entité maître. Ce peut être un fichier ou une réponse type à une requête standardisée. Cette valeur doit être consultable par tout le monde, elle permet l’initialisation d’un échange plus sécurisé, plus intime, entre serveurs.

Cela introduit cependant une petite différence pour les entités non-maîtres. Elles apparaissaient avant avec une URL pointant dans une sous arborescence de l’URL de l’entité maître. Elles apparaissent maintenant au même niveau. Ainsi, toute entité que l’entité maître connaît peuvent utiliser l’URL de l’entité maître comme nouvelle localisation et améliorer la diffusion de ses propres liens sur le mode P2P.

L’internet des objets et les objets de l’internet

Jeudi, novembre 29th, 2012

Les objets physiques qui peuplent notre environnement habituel ont une caractéristique particulière, ils sont uniques. On peut certes faire une copie, voire reproduire un objet en plusieurs millions d’exemplaires, chaque objet restera unique avec sa matière propre et ses défauts propres. Chaque objet peut être ainsi assemblé, remodelé ou refondu dans un autre objet, cela n’a aucun impact sur ses congénères.

Et les objets du monde numérique?
Ceux-ci ont l’équivalent d’une forme propre comme un objet physique. On peut distinguer un objet numérique d’un autre par cette forme que l’on appellera plutôt empreinte, mais aussi par sa localisation. La localisation est souvent représenté par un identifiant dans une arborescence ou sur un réseau, c’est un classement humanisé et peu fiable. Ainsi cette dualité de l’objet dans l’espace numérique a une conséquence importante immédiate, le même objet exactement peut exister simultanément en plusieurs endroits. Il faut donc considérer que chaque emplacement de l’objet reçoit une copie exacte de l’objet, c’est à dire sans altération, sinon cela devient un autre objet.

(suite…)

Compressibilité des liens

Vendredi, novembre 9th, 2012

Les expériences autour de nebule se font aujourd’hui via des échanges en html. Il pourront se faire plus tard via tout protocole d’échange. indépendamment du stockage des liens, il sera utile de les compresser lors de leur transmission pour gagner de la bande passante réseau. (suite…)

Messagerie social

Mardi, juin 26th, 2012

Les objets que l’on échange, y compris les textes, sont perdus dans l’océan des objets dont nous disposons.

Que devient un message ou un objet transmit comme message?

Il est naturellement ajouté aux autres objets. Mais en plus, il a un lien signé par une autre entité, donc on peut considérer que cet objet est aussi lié à cette entité.

Ce lien implicite à une entité fait que cet objet a une visibilité par cette entité, en l’analysant on verra cet objet.

Poussons encore plus loin, et si on analyse tous les liens vers des objets que publie cette entité, que voit-on ?
On va voir dans l’ordre chronologique tout ce qu’elle a jugé intéressant à garder, les objets qu’elle a créé, tous les objets sur lesquelles elle est intervenu, les messages que l’on a échangé avec elle, etc…
Les messages (objets échangés) ne sont visibles que si ils sont publics, ou si ils sont chiffrés et que l’on est destinataire.

Cette vue, ce comportement, c’est presque celui des réseaux sociaux!

Big data et concept des 4 V

Jeudi, mars 15th, 2012

L’approche Big data est intéressante en plusieurs points, dont notamment le concept des 4 V.

L’expression Big data désigne des ensembles de données qui deviennent tellement gros qu’ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données. (suite…)