Anonymisation de lien

MàJ 11/06/2014 : le registre de lien a été changé : Anonymisation de lien – correction du registre

Dans la version 1.2 de nebule, le nouveau lien de type c a pour rôle d’anonymiser les actions des entités. Cette anonymisation doit permettre de cacher la relation entre l’entité d’un côté et ses actions sur des objets de l’autre. Il faut donc cacher non seulement le type de lien mais aussi que le lien relie ces objets. C’est la suite des articles liaison secrète et suite de fin 2012.

Il faut malgré tout permettre la libre diffusion des liens générés pour que ceux-ci soient transmis sur un réseau public et ouvert notamment via des entités relais. Cette transmission est assurée par le fait que l’entité signataire apparaît en clair puisqu’il faut être capable de vérifier la signature du lien.

L’anonymisation consiste en l’offuscation du vrai lien dans un lien caractéristique, le lien de type c. Le vrai lien, celui qui a un intérêt, est chiffré et intégré au lien de type c. Pour que la vérification des liens soit la plus simple possible, elle ne doit pas gérer le lien offusqué différemment. Le registre du lien doit donc être identique aux autres liens à l’exception de l’action et ce registre doit passer les mêmes tests de validation.

Si le lien offusqué mentionne l’entité signataire, il doit peut-être pouvoir être lisible par une autre entité. C’est le cas si l’on souhaite partage un lien de la même façon que l’on pourrait souhaiter partager un objet. Il faut donc que le lien offusqué fasse aussi référence à l’entité destinataire. L’entité destinataire, ou entité cible, qui peut être la même que l’entité signataire, sera positionnée dans le registre en 5ème position. Cette place est habituellement occupée par l’objet source.

Il faut prévoir une clé de session (un mot de passe) pour chiffrer le lien (chiffrement symétrique) parce que celui-ci n’a pas forcément une taille adéquate pour le chiffrement asymétrique. La clé de session chiffrée doit être encodé en hexadécimal. La clé de session chiffrée sera positionnée dans le registre en 6ème position. Cette place est habituellement occupée par l’objet destinataire.

Enfin, le lien offusqué, chiffré, doit être encodé en hexadécimal. Le lien offusqué sera positionné dans le registre en 7ème position.

Voici donc le registre de lien de type c :

Signature_Signataire_TimeStamp_c_EntitéCible_CléSession_LienChiffré

Le lien à offusquer est chiffré (symétrique) avec la clé de session et ajouté en position 7. La clé de session est chiffrée (asymétrique) avec la clé publique de l’entité cible et ajoutée en position 6. L’entité cible est ajoutée en position 5.

On ne peut dans ce cas pas offusquer la relation entre l’entité signataire et l’entité cible. La présence de la première entité est indispensable pour vérifier la signature du lien. La présence de la seconde entité est nécessaire pour que le lien puisse lui parvenir et lui indiquer que le lien la concerne. Le reste du lien est complètement offusqué.

Lors du traitement des liens d’un objet, Il faut à la fois consulter les liens de l’objet mais aussi consulter les liens offusqués attachés à l’entité courante. Ensuite seulement peut se faire le nettoyage des liens marqués supprimés.
On remarquera que cette façon de procéder permet bien sûr de ne pas révéler certains liens, mais aussi de marquer secrètement comme supprimés des liens alors qu’ils sont encore publiquement reconnus comme valides. Dans le même ordre d’idé, on peut camoufler un objet sous un type mime assez banal mais offusquer un lien dévoilant sa vraie nature. Un vrai terrain de jeux de cache cache en perspective !

Il reste un autre aspect de l’anonymat. Il peut être nécessaire de permettre des échanges entre deux entités sans qu’il n’y ai de lien entre elles, même de liens offusqués. Ce problème peut être résolu avec la génération d’entités esclaves le temps de quelques échanges. Il n’est pas possible dans ce cas de rattache directement ces entités esclaves à notre entité principale ni d’héberger cette entité sur son serveur personnel sous peine de dévoiler immédiatement la relation entre les deux. Il faut aussi prévoir un mécanisme pour que des entités puissent attendre des liens d’entités inconnues tout en étant capable de vérifier ces liens. Une fois le contact établit, il devient aisé, via l’offuscation de liens, de prouver sa véritable identité, c’est à dire de faire un lien entre entité esclave et entité maître. Il y a encore de la recherche à faire à ce niveau…

Liens d’émotions

La mise en place des émotions sur les objets appelle plusieurs questions.

Catégories

Vu le nombre d’émotions gérées, il va devenir nécessaire de les segmenter en catégories. On peut maintenir la catégorie ‘émotions‘ qui regroupe tout ressentit humain, plutôt subjectif. On peut ajouter une nouvelle catégorie ‘avis‘ pour tout ce qui est plus objectif.

Pondération

Une réflexion qui commence à dater un peu sera la mise en place d’une pondération aux objets. Cette réflexion concerne avant tout la possibilité d’oublier progressivement dans le temps les objets avec le moins d’importance. L’oublie peut être réalisé automatiquement à partir d’un certain seuil. Le seuil peut progressivement augmenter dans le temps jusqu’à un seuil maximum au dessus duquel les objets concernés seront conservés, sauf suppression volontaire.

Cette pondération peut être bien sûr utilisable en permanence pour trier l’affichage des objets.

La mise en place des émotions est le bon moment pour introduire la mise en place de la pondération. Il ne reste plus qu’à en définir les modalités.

Chiffrement

Une autre réflexion qui date un peu mais prend progressivement de l’importance, c’est la possibilité de chiffrer les liens. Le but est d’offusquer que l’on ne souhaite pas rendre publics tout en permettant leur bonne transmission aux destinataires légitimes.
Il y a plusieurs manières d’offusquer les liens :

  1. La première est de créer un objet de liens, objets que l’on chiffre ensuite vers son destinataire. Cette méthode, si elle est assez bonne en terme de performance de déchiffrement, nécessite cependant que tous les liens offusqués soient consultés en même temps que tout les liens normaux d’un quelconque objet, pour savoir si un lien secret ne le concerne pas spécifiquement. On obtient de fait un ou plusieurs objets de liens chiffrés attachés à son entité. L’inconvénient, c’est qu’il est impossible de transmettre un lien particulier à une autre entité sans devoir recréer un nouvel objet de liens chiffré.
  2. La seconde méthode est de faire du chiffrement de lien à la volée. C’est à dire qu’un lien a offusquer est chiffré et reste présent individuellement au milieu des autres liens. Cependant, ce lien va contenir un partie chiffrée, partie qui ne correspond donc pas à un objet réel, ce qui est en contradiction avec la forme actuelle des liens. L’avantage, les liens chiffrés voyagent naturellement avec les autres liens. L’inconvénient, le lien chiffré ne peut être rattaché qu’à un seul objet et à une entité. Le lien avant chiffrement fait référence à trois objets, on perd donc avec le lien chiffré la référence aux deux autres objets. Cela veut dire que le lien chiffré est valable si on consulte l’objet source, mais n’est plus reconnu si on consulte l’objet destination. Cet inconvénient risque de perturber la résolution inverse d’un arbre de mise à jour par exemple.
  3. La troisième méthode est d’exporter la partie chiffrée dans un objet en tant que tel. Cette méthode a l’avantage de profiter du mécanisme de chiffrement déjà implémenté pour les objets. Liens et objets sont transmis naturellement vers un destinataire du lien. Et on retrouve l’inconvénient de la deuxième méthode. En plus, on complexifie l’analyse des liens d’un objet puisqu’il faut aller consulter d’autres objets pendant le processus de lecture des liens, et donc d’autres liens…

La mise en place du chiffrement des liens va créer de fait une nouvelle version de nebule, la v1.2.

Auto déploiement répliqué d’un code

La librairie nebule de référence en php gère maintenant les liens de mise à jour d’objets conformément à la méthode décrite dans l’article sur la Résolution d’un graphe de relations de mise à jour.

Cette fonctionnalité qui paraît au premier abord peu utile tous les jours est en fait primordiale pour diffuser de façon sécurisée les mises à jours de logiciels. Le premier programme à en bénéficier est sylabe. La diffusion du code sous forme d’objet a déjà commencé : Gestion des versions de sylabe – mise en ligne

Ainsi, le code de sylabe va pouvoir être très facilement tenu à jour avec la toute dernière version. Mais cela va aussi grandement simplifier l’installation puisque le code de bootstrap va être capable d’aller automatiquement récupérer immédiatement la dernière version de sylabe avant de permettre son utilisation.

Nous arrivons dans le projet nebule à un point de singularité. Alors que jusque là, les fichiers mais aussi les entités (les utilisateurs) avaient été intégrés à nebule sous forme d’objets, le code de nebule restait lui en dehors des objets. Maintenant, le code de gestion des liens et objets devient lui aussi un objet géré par des liens comme tout objet.

Le code sera initialement signé et diffusé par l’entité bachue. Tout entité à jour deviendra à son tour point de redistribution du code.

Chiffrement et subdivision

Le chiffrement permet offusquer des données, c’est à dire de protéger celle-ci d’une diffusion inappropriée.

La subdivision consiste, à partir d’un objet unique, en la création de plusieurs objet dérivés plus petits. Ces petits objets sont des sous-ensembles de l’objet principal, c’est à dire des morceaux. Ce n’est pas encore implémenté aujourd’hui, mais le type de lien existe pour définir la relation de morcelage entre l’objet principal et les sous-objets.
La subdivision permet de découper un objet en bloc pour qu’il puisse être transmis par morceaux à la manière du P2P.
La subdivision peut aussi et simultanément être utilisée afin de constituer un index de certaines portions intéressantes. Cela peut être par exemple un index des mots dans un texte pour permettre une recherche accélérée sur des mots clés.

Cependant, la combinaison du chiffrement et de la subdivision pose un problème de confidentialité.

Que se passe-t-il si on décide de protéger un objet contenant du texte, c’est à dire le chiffrer, mais que l’on ne retire pas les liens de subdivision ?
Si ces liens de subdivision renvoient vers des parties d’un index des mots clés, alors il est possible de reconstituer les grandes idées du texte. Voir il est possible de reconstituer dans le pire des cas l’intégralité du texte déchiffré. On contourne ainsi la protection mise en place.

Il faut cependant noter que si un objet est protégé à posteriori, il a peut-être déjà été copié légitimement. Il pourrait en être de même de certaines parties marquées comme subdivisions.

Afin de minimiser ce problème de confidentialité, il y a plusieurs règles à appliquer :

  1. Ne jamais faire de liens de subdivision sur un objet protégé mais uniquement sur son dérivé chiffré.
  2. Si une protection est activée pour un objet existant, supprimer tous les liens de subdivision.
  3. Si l’objet est nouveau et doit être protégé, ne pas faire de liens de subdivision sur celui-ci mais uniquement sur son dérivé chiffré.

Lorsqu’il sera possible d’offusquer des liens, ces règles pourront être revues.

Echanges via http – suite

Suite du post Echanges via http.

Si la définition des échanges dépend plus de nebule que de sylabe, c’est une erreur de mélanger les deux.

En effet, nebule a bien vocation à définir les téléchargements de liens et d’objets, notamment via http. La confusion vient que si sylabe passe par ce même protocole http vers les mêmes serveurs, les deux ne doivent pas être mélangés dans leurs rôles. Le projet sylabe doit être vu comme une application cliente qui repose notamment sur des échanges nebule mais doit utiliser ses propres accès pour son fonctionnement. C’est donc le cas pour lire les objets dans le navigateur web, surtout si ceux-ci ont nécessités d’être déchiffrés.

Les échanges via nebule ne doivent à aucun moment permettre le téléchargement d’objets nécessitant préalablement un déchiffrement.

Donc le programme index.php ne se chargera pas de gérer les translations de requêtes http (.htaccess pour Apache). Si sylabe (ou tout autre programme) en a besoin, il doit de lui-même mettre en place tout ce qui est nécessaire à son bon fonctionnement.

Nettoyage des liens

Le nettoyage régulier des liens est quelque chose qui est connu depuis assez longtemps pour être indispensable. Si la quantité de lien que manipulent aujourd’hui les entités reste encore soutenable, nous ne sommes pas loin de gros problèmes de performances dans certains cas.
CF : Mémoire finie, Repérage chronologique.

Le nettoyage est la mise en pratique de l’oubli volontaire et maîtrisé des liens et objets.

Un premier nettoyage, assez facile à mettre en place par script notamment, est le nettoyage des liens. Suivre cette procédure :

  1. Copier tous les liens de tous les objets dans un emplacement temporaire unique. Chaque lien copié doit l’être une fois pour ne pas avoir de doublon. Il est préférable de faire une vérification des signatures des liens au moment de leur lecture. Chaque lien étant copié entre deux et trois fois en fonction du nombre d’objets concernés, la taille total de cet emplacement temporaire sera entre deux et trois fois moins volumineux que l’ensemble des liens des objets.
  2. Dans l’emplacement temporaire, trier les liens par date dans l’ordre chronologique. Ainsi, une fois remis en place, les liens seront déjà naturellement triés.
  3. Dans l’emplacement temporaire, supprimer les liens qui sont concernés par un lien de type x (suppression de lien). Garder le dernier lien de type x pour maintenir la propagation de la suppression du lien.
  4. Supprimer, ou mettre de côté, les liens de tous les objets. Ne garder que l’emplacement temporaire. Pendant ce lapse de temps, les objets restent disponibles mais sont inexploitables parce qu’ils ne seront pas accompagnés de leurs liens.
  5. Faire un import de chaque liens de l’emplacement temporaire, un par un et dans l’ordre. L’import va réattribuer les liens aux objets concernés, dans l’ordre.

Cette procédure ne tient pas compte des liens dans des objets, normalement chiffrés. Et ils ne doivent pas en tenir compte. Cela peut poser des problèmes résiduels de non suppression de liens parce que le lien de type x est non disponible au moment du nettoyage.

A noter qu’après le nettoyage, si des liens ont été marqués comme à supprimer, il doit rester le dernier lien de type x. Si ce n’était pas le cas, il pourrait y avoir des problèmes pour retransmettre la suppression de ces liens.

Tous les liens ne peuvent pas, et ne doivent pas disparaître en même temps que l’objet. Il faut en effet attendre que la suppression de l’objet, dictée par un lien de type d, soit effective partout. Sinon, cet objet va réapparaître et ses liens avec.

Pour nettoyer les objets, il manque la mise en place du système de pondération. Seule cette pondération associée à un seuil est capable de gérer l’oubli de certains objets parmi un grand volume d’objets.
La pondération sera pour plus tard.

Comment rester sécurisé face à la NSA

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

Confrontons donc maintenant le projet nebule et ces cinq points :

  1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
  2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
  3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
  4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
  5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html

Echanges via http

L’avancement de sylabe met en avant un manque de standardisation des échanges nebule via le protocole http. Cela impacte notamment directement le téléchargement et le suivi de liens u.

Il faut compléter la documentation de référence nebule v1.1 concernant les moyens et supports d’échange.

Comme la définition des échanges dépend plus de nebule que de sylabe, c’est naturellement le programme index.php qui se chargera de gérer les translations de requêtes http (.htaccess pour Apache).

Il en sera de même pour tout nouveau protocole d’échange lorsque le besoin s’en fera ressentir. Cela pourra être le cas par exemple pour le xmpp et le smtp

RSE ou RSE ?

En recherchant la définition de l’acronyme RSE, je tombe sur deux définitions… Problème assez récurrent en fait avec les acronymes puisque n’importe qui peut en inventer et les utiliser sur la place publique à son bénéfice.

D’un côté j’ai une belle page bien fournie sur Wikipédia et une page gouvernementale officielle parlant de Responsabilité Sociétale des Entreprises :
Responsabilit̩ Soci̩tale des Entreprises РWikip̩dia
Qu’est-ce-que la responsabilité sociétale des entreprises – Ministère du développement durable
On y parle donc de responsabilité des entreprises, de développement durable, de gestion de risques, des impacts environnementaux et sociaux, enjeux, investissements, outils, normes, médiatisation, aspects juridiques, etc…

De l’autre un article sur 01net.com qui surfe sur la vague des révélations sur PRISM, ce qui n’est pas un mal en soi :
Le RSE : un lanceur d’alerte en entreprise – 01net
On retrouve bien en fin d’article un paragraphe sur le RSE, l’environnement et les risques. Mais RSE, répété à l’envie tout au long de l’article, désigne ici Réseau Social d’Entreprise. En gros un simili Facebook restreint au périmètre de l’entreprise.
Mais n’y a-t-il pas déjà un terme pour cette fonctionnalité? Oui, c’est le groupe de travail (groupware). Ah oui, c’est vrai, le créneau sur ce nom est déjà bien plein. D’un autre côté, la RSE ne doit pas plaire à beaucoup de chef d’entreprises. Bref, Voila typiquement un article à visée commerciale…

Mais ce post n’est pas là pour critiquer l’article. Les acronymes posent un problème de gestion de leurs définitions. Celles-ci ont rarement une portée globale, elles n’ont souvent qu’une définition de portée locale ou régionale. C’est cette absence de centralisation qui, à priori, serait la source des conflits.

Comment vont se comporter les acronymes dans nebule?
Reprenons le cas de la RSE. En pratique, c’est l’objet cec7b8a511f6d30def09266e7595f1dd9a301b3ba868444d2b14236dccc127b1. Aujourd’hui, cet objet n’existe sur aucune machine supportant nebule, mais si il était créé ce serait avec cette empreinte (sha256).

Premièrement, cet objet peut être marqué par des liens de type subdivision s. Il est en effet possible avec ce type de lien de savoir qu’un texte, un article de presse par exemple, contient cet acronyme. Cela facilite la recherche.
Cet exemple d’acronyme est trop petit mais le principe reste valable, le même article de presse peut être téléchargé morceaux par morceaux par ses abonnés. C’est un fonctionnement de type P2P. Chaque morceau connu peut être téléchargé à des endroits différents, puis l’article de presse peut être reconstitué. En pratique, on accélère donc les échanges d’objets.

Ensuite, L’objet de l’acronyme peut aussi être marqué par des liens de type dérivation f. Ces liens peuvent renvoyer vers d’autres objets contenant la ou les définitions de l’acronyme.
C’est un intérêt pour résoudre les conflits autour des définitions d’acronymes. En effet, chaque lien est signé par une entité, donc on sait qui en est l’initiateur. Et comme toute entité gère individuellement ses propres relations de confiances, la définition d’un acronyme sera donc dépendante des entités à qui on fait confiance, mais aussi en fonction de leur niveaux de confiance relatifs.
Donc, si on a une forte confiance en l’état, ce sera la RSE. Si on a une grande confiance en l’auteur de l’article de 01net, alors ce sera le RSE. Si on est chef d’entreprise, il y a de fortes chances que ce soit la RSE de toute façon…

Individu, sociabilité, universalité

L’affaire PRISM révélée par Edward Snowden n’en finit pas de provoquer des secousses numériques autour de la NSA, des grosses sociétés américaines et de la vie privée des citoyens/sociétés.

On entend parler régulièrement de la possibilité de créer de multiples chemins de communications entre individus. Ici multiple est à comprendre dans le sens où chaque connexion passe par un certain nombre de serveurs différents et ce de façon anonyme pour les serveurs. Ceci dans le but de garantir l’anonymat de l’internaute.

Il existe TOR pour la navigation. Ce pourrait être le cas avec la messagerie (Caliop ?). Mais est-ce une solutions suffisante?
Le journal Lemonde a publié un article sur un internet décentralisé pour des usages centralisés (cf lien). Rien que le titre suffit à exprimer tout le paradoxe de notre utilisation de l’internet…

Un autre problème s’ajoute, l’anonymisation est aussi utilisée par des criminels. Tout en sachant que les criminels d’un pays/communauté sont parfois les héros d’un autre. Comment distinguer l’utilisation légitime, ce qui est bien ou pas? Vaste débat.
Un outil ayant uniquement une structure globale mélange les usages légitimes et réprouvés, quel qu’en soit leur acceptation. Un outil qui respecte une structuration régionale ou locale est plus à même de coller à l’acceptation de certains usages, ou à leur régulation. Il est aussi capable de suivre l’évolution des mÅ“urs et usages tout en permettant des échanges globaux.

Le projet nebule peut-il apporter quelque chose? Je pense que oui, quelque chose de nouveau surtout. Aujourd’hui, tous les efforts portent sur des tentatives de sécuriser les serveurs centraux, les relais intermédiaires, les chemins empruntés et les protocoles. Cette nouvelle chose que propose nebule est de penser directement au niveau de la donnée, de gérer sa confidentialité et ses échanges.

La structure locale de nebule est de taille variable. L’individu est la base. Il met en place naturellement des échanges dits sociaux proches jusqu’à une organisation de la taille d’un pays. Il est aussi capable d’exploiter de façon universelle des informations quelles qu’en soient leurs localisations.

Liens :
Lemonde РBitcoin, BitTorrent, TOR : un internet d̩centralis̩ pour des usages centralis̩s
http://fr.wikipedia.org/wiki/PRISM_%28programme_de_surveillance%29
http://fr.wikipedia.org/wiki/Tor_%28r%C3%A9seau%29
https://www.torproject.org/
http://www.caliop.net/

Quantification commune de la disponibilités des relais – suite 2

Suite à l’affaire PRISM et grâce à Edward Snowden, on redécouvre les joies du Time Pattern sur les paquets réseaux.

Cela à potentiellement une implication dans la façon dont on peut synchroniser des objets et liens depuis d’autres entités. C’était le sujet abordé dans les posts Quantification commune de la disponibilités des relais et suite.

La conclusion est qu’il faut deux modes. Un pour optimiser les temps de téléchargement, et un autre plus aléatoire pour améliorer l’anonymisation des téléchargement et casser le Time Pattern

Le weblog et la relation d’objets – 2

Suite de la réflexion sur le weblog et la relation d’objets.

La première expérience avec sylabe sur une arborescence d’objets liés montre qu’il faut privilégier les liens de type dérivation f dans cet usage. Le lien de type l permet avec un objet méta de déterminer la relation entre deux objets dans l’arborescence. Mais c’est déjà ce que fait le lien de type dérivation f sans objet méta. Et si l’emplacement de l’objet méta est utilisé, il n’est du coup pas possible de définir ce que l’on peut appeler un contexte. C’est à dire de définir que les deux objets sont dans une arborescence bien délimitée et non tout le temps liés.

Ensuite, des liens de type dérivation f peuvent être utilisés sans objet méta afin de définir un objet dérivé d’un autre de façon générale. La différence, c’est que sans objet méta, le lien n’est pas utilisé dans l’affichage d’une arborescence d’objets. Mais cela n’empêche pas qu’ils soient utilisés pour améliorer l’affichage de certains objets spécifiques dans la représentation de l’arborescence. Ainsi, une arborescence d’images de grandes tailles gagnera à voir chaque image remplacée une à une par une versions réduite. C’est plus adaptée à l’affichage d’un navigateur web par exemple. La version réduite de chaque image étant liée à l’image originale par un lien de dérivation f.

Cette façon de faire résout les cas de gestion d’un article dans plusieurs nœuds et de gestion d’un article à plusieurs endroits dans le même nœud.

Reste à définir le cas de la gestion d’un nœud sous un autre nœud.

Le weblog et la relation d’objets

La mise en application des objets et liens nebule dans sylabe montre qu’un aspect important de la relation entre les objets a été sous-estimé.

Prenons l’exemple d’un blog ou d’un fil de discussion sur FB (en autres). Un utilisateur publie un article, un texte en fait. A cet article, tous les utilisateurs (ou presque) peuvent répondre, c’est à dire attacher à l’article un nouvel article. Ce nouvel article est aussi un texte, mais il est subordonné à l’article initial.
On peut ainsi ajouter une infinité d’articles subordonnés à l’article initial ou subordonnés les uns aux autres.

Première remarque à priori. L’article initial, celui de plus haut niveau, a tout intérêt à être déclaré comme étant un nÅ“ud. Mais ça n’est pas obligatoire en fait.

Ensuite, le lien entre l’article initial et les articles qui lui répondent est un lien créant une hiérarchie. Les liens nebule de type l ou f peuvent répondre à ce besoin.

La réflexion est cependant incomplète. Il faut tenir compte de :
– la gestion d’un article dans plusieurs nÅ“uds ;
– la gestion d’un article à plusieurs endroits dans le même nÅ“ud ;
– la gestion d’un nÅ“ud sous un autre nÅ“ud.

A suivre…

Quantification commune de la disponibilit̩s des relais Рsuite

Suite au post sur la Quantification commune de la disponibilités des relais, je vais essayer de mettre en place une solution dans l’implémentation bash de référence.

Cette solution consistera, lors du téléchargement d’un objet, de vérifier quelle localisation contient l’objet (options spécifiques de wget) et de mesurer le temps de réponse instantané à cette requête.

Pour accélérer le téléchargement des liens sans remettre en question la vérification systématique de ceux-ci, je pense déjà à une solution. Mais elle implique des changements en profondeur du code dans ses parties téléchargement, génération et enregistrement des liens. Il faut aussi prévoir le cas où une entité ne serait pas capable de gérer cette amélioration…

En attendant de pouvoir travailler sur ces améliorations, je dois terminer l’implémentation complète du chiffrement.

Quantification commune de la disponibilités des relais

Les quelques entités robot que je teste sont maintenant tout à fait capable de synchroniser des liens et objets divers. Le problème est souvent de savoir ce que l’on veut synchroniser en fait.

Chaque robot essaye de télécharger un objet sur toutes les autres entités qu’il connaît. Ou plus exactement sur toutes les localisations qu’il connaît, même si ce n’est pas une entité connue. Le téléchargement est actuellement unitaire. L’objet téléchargé doit être complet, on ne prend pas un bout à un endroit et le reste ailleurs comme avec le P2P habituellement. Ce raffinement sera pour plus tard. Et l’ordre des localisations est toujours parcouru de la même façon, c’est à dire dans l’ordre des liens de ces localisations avec l’objet qui les référence.
Évidement, la vérification de l’intégrité des objets et la vérification des signatures des liens associés permet de ne pas se soucier de savoir sur quel entité relais l’objet est téléchargé.

Ce système est assez primaire mais il remplit parfaitement son rôle. Cependant, en terme de performance, on peut faire mieux…

Une des solutions peut être d’enregistrer systématiquement le débit moyen de téléchargement d’un objet sur une localisation particulière. Des statistiques vont commencer à s’accumuler avec le temps et le robot pourra ensuite privilégier certaines localisations en fonctions de leurs statistiques.
Si chaque mesure de débit moyen est lié à la localisation comme étant une statistique, l’ensemble des statistiques des entités peuvent se propager d’une entité à l’autre. Ainsi c’est l’ensemble des robots qui peuvent profiter des statistiques pour affiner le classement des localisations.
Il faut quand même ne pas tout prendre brute quoiqu’il arrive. Des statistiques anciennes n’ont que peu de valeur. De même, comment interpréter les statistiques d’une entité à l’autre bout du monde, et donc qui a des temps de latence différents ? Une moyenne non pondérée entre les statistiques de toutes les entités est-elle suffisante pour gommer des valeurs anormales de débit moyen ?

Gestion de programmes Рcr̩ation

Suite à la précédente réflexion sur la gestion des programmes, l’entité correspondante a été créée.

Cette entité s’appelle bachue, dérivé de Bachué. Son empreinte :

19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
http://bachue.nebule.org

bachue

Le lien et la subdivision d’objet

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 ?

Protocole d’échange HTTP

Tous les objets et liens sont échangeables via différents protocoles sous-jacent connus, en attendant un protocole en propre. Ces échanges peuvent utiliser par exemple la messagerie SMTP, XMPP, mais aussi le HTTP. C’est sur ce dernier que l’on va commencer.

Celui-ci nécessite un serveur web classique et un peu de programmation côté serveur.

Nous devons pouvoir permettre le téléchargement d’objets et de liens par n’importe quel utilisateur partout dans le monde. Les objets sont référencés naturellement par leurs empreintes. Il en est de même pour les liens d’un objets, c’est juste la façon de les traiter qui différera côté client.

Une première difficulté, c’est de restreindre simplement le téléchargement libre de la plupart des objets et des liens. Sauf si c’est une entité volontairement publique, seule une partie des objets et des liens sont relayés à tout le monde alors que la plupart ne le seront qu’avec les entités connues. Contrairement au chiffrement, ce verrouillage ne doit pas être considéré comme une sécurité pour gérer la confidentialité des données. Cela doit être vu comme une façon de réguler les échanges entre entités.

Le tag d’objet nebule/objet/public est créé pour désigner les objets accessibles sans identification. Pour les autres objets, cette identification préalable est obligatoire. La seule exception, c’est si c’est une entité volontairement publique comme un annuaire.

Comme l’échange d’objet peut potentiellement se faire sans échange (par exemple en SMTP), elle doit pouvoir être envoyée lors de la requête HTTP. Elle doit prouver l’identité du demandeur de façon forte et interdire le rejeu. Elle ne doit pas solliciter l’utilisation de la clé privé de l’entité serveur. Un relais d’objet ainsi tenir compte du tag pour gérer les objets qu’il héberge sans en être la source.

Les requêtes doivent pouvoir passer par un flux en clair, c’est à dire non encapsulé dans du TLS.

Une requête doit contenir :
Рentit̩ destination
Рtype demand̩, objet ou liens
– empreinte objet
Рentit̩ demandeuse
– signature

Par exemple : http://localisation.net/?o=HashObjet&s=HashEntitéDemandeuse-HashEntitéDestination-Signature

C’est un début de réflexion…
A compléter…

Fragmentation d’objets

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…

nous = toi + moi

Ce matin, en me connectant à Facebook sur l’ordinateur commun à nous, je me suis fait la réflexion que certaines choses étaient faites bizarrement. Je suis sur ma session Linux à moi mais dans Firefox, c’est toi Diana qui est connectée à FB…
L’ordinateur est multi-session, mais on ne voit simultanément qu’une seule session, soit moi soit toi. Si tu veux ouvrir ton Firefox avec ta connexion FB, tu dois ouvrir une autre session de l’ordinateur. Le problème est que l’on ne peut pas ouvrir facilement deux navigateur pour deux utilisateurs différents dans la même session, une session à nous.

Continuer la lecture de nous = toi + moi