Mois : décembre 2012

nebule et la donnée massive

Juste un petit article en écho à celui sur le RDF. C’est surtout le moyen d’introduire sur le blog les catégories :

Ceux-ci sont inclus dans la catégorie des réflexions.

Ainsi le blog de nebule peut commencer à être référencé sur ces mots clés, notamment.

Silent Circle et la crypto pour tous

La revue lemonde.fr sort un article ce jour sur la startup américaine Silent Circle.

Le système repose sur du chiffrement et de l’offuscation de communications. Jusque là, rien de nouveau sous le soleil. C’est une autre façon de ré-implémenter des composants existants. L’intérêt est plutôt dans la façon d’implémenter l’ensemble qui le rend facile d’utilisation. Continuer la lecture de Silent Circle et la crypto pour tous

Liaison secr̬te Рsuite

La réflexion sur la possibilité d’insérer des liens dans des objets (cf Liaison secrète) pose quand même un problème.

Comment vont être utilisés dans la vraie vie les liens insérés dans l’objet ?

Il faut en effet voir comment vont être pris en compte ces liens. Seront-ils ajoutés par certaines entités aux liens des objets concernés ? Ce qui du coup leur fait perdre leur caractère confidentiel, et donc l’intérêt du chiffrement de l’objet contenant ces liens. Et si ils ne sont pas ajoutés au reste des liens des objets concernés, comment vont faire ces entités pour exploiter ces liens ?

Deux réponses sont possibles.

La première est de déchiffrer l’objet pour extraire les liens et les stocker temporairement dans un emplacement strictement privé… et faire en sorte de les traiter en même temps que les liens naturellement attachés aux objets, c’est à dire aux liens publics. Cela nécessite à chaque déverrouillage d’une entité que celle-ci déchiffre tous ces objets pour en récupérer les liens, et de les supprimer systématiquement à chaque verrouillage. C’est facile et réalisable avec peu d’objets de ce type. Mais seront-ils si peu nombreux ? C’est loin d’être évident. Donc ce n’est pas une solution.

L’autre solution est de permettre d’insérer dans les liens un nouveau lien qui ferait référence à un autre objet comme contenant des liens. Cet objet peut ensuite être reconnu comme contenant des liens et être exploité en même temps que les liens normaux, c’est à dire non chiffrés. cette solution semble plus réaliste et viable que la première. Cependant, elle nécessite la mise en place d’un mécanisme pour les traiter spécifiquement.

Ne faut-il pas créer un nouveau type de lien dédié à ce problème ?
En l’état, le problème peut être résolu plus tard sans remettre en cause toute l’architecture des liens de nebule.

Liaison secrète

Jusque là, je considère toujours les liens comme des informations si ce n’est publique, au moins sans grand besoin de protection rapprochée.

Les informations confidentielles, les données que l’on souhaite protéger, sont dans des objets chiffrés.

N’est-ce pas une erreur fondamentale?

Aujourd’hui, une tendance forte est en train de s’imposer, le big data.

Ce terme regroupe les données caractérisées par les 4 V :
РVolume : les donn̩es saturent les espaces de stockage classiques et n̩cessitent (ou imposent) un stockage r̩partit sur le r̩seau.
РVari̩t̩ : les donn̩es sont de nature h̩t̩rog̬nes et de sources diff̩rentes.
РV̩locit̩ : les donn̩es doivent ̻tre traitables (capture/stockage/analyse/partage) avant de devenir obsol̬tes.
– Variabilité : l’interprétation des données est variable en fonction du traitement demandé et en fonction du temps.

Par abus de langage (commercial), ce terme est souvent utilisé pour désigner l’exploitation des traces des utilisateurs (clients) de services web pour déterminer leur profil et leur proposer des produits ou des publicités ciblés. Ce n’est en fait qu’une utilisation des big data, mais loin d’être la seule. On peut considérer que nebule est une méthode de gestion de big data notamment.

Ce qu’il faut retenir ici, c’est que les données sont des cibles pour les commerciaux, mais aussi et surtout les liens entre ces données. Et ces mêmes liens et données peuvent intéresser de la même façon des états ou le grand banditisme, le terrorisme, le lobbing, etc…

D’un autre côté, il ne faut pas trop fantasmer non plus sur les gains générés. Une société ne doublera pas son chiffre d’affaire juste en se penchant sur ses bases clients.

Jusque où la non protection des liens peut être préjudiciable?
Je n’ai pas de réponse définitive aujourd’hui.

Il peut être apporté plusieurs réponses.

La première réponse est de décréter que les liens sont publics et à considérer comme tel. Et donc de prendre ses dispositions si cela peut poser problème. C’est un peu extrêmement laxiste.

L’autre extrême, c’est de considérer par défaut les liens comme confidentiels, et donc de les chiffrer. Cela entraîne directement une forte augmentation de la puissance de calcul nécessaire à la manipulation de ces liens. De plus, cela limite grandement les possibilités de diffusion ou rediffusion de ces liens, ce qui est le but à atteindre.

Cette deuxième réponse me paraît un peu schizophrène. Elle perturbe par défaut les échanges entre entités. Il me semble que toute communication vers l’extérieur d’une entité implique implicitement une prise de risque. Ce risque doit être mesuré et assumé.

Une troisième réponse est possible entre ces deux extrêmes. Il est possible de commencer par restreindre par défaut la consultation des objets et liens associés aux seules entités que l’on connaît, que l’on a validé. C’est faisable lors des requêtes en imposant une signature de l’entité demandeuse sur sa requête, et en implémentant un mécanisme anti-rejeux des requêtes. Ainsi les objets chiffrés ne sont déchiffrables que par les entités disposant de la clé, et les liens ne sont visibles que des entités que l’on connaît. Il faut accepter qu’une entité que l’on connaît diffuse nos liens à d’autres entités y compris des entités que l’on a pas validé.

Et pour les liens à cacher à tout prix, on peut les placer dans un objet dédié, objet que l’on chiffrera dans la foulé. Pour cela, un type d’objet est créé : nebule/objet/liens

Liens :
– http://fr.wikipedia.org/wiki/Big_data
– Big data et concept des 4 V

Evenement unique multiple

Je fais une erreur depuis quelques temps dans les scripts. Le concept de base est bon mais l’implémentation est mauvaise.

En effet, lors de l’ajout d’un lien à un objet, si celui-ci existe déjà, il n’est pas ajouté. C’est un doublon.

Mais j’implémentais la vérification d’unicité du lien sur les champs Action, HashSource, HashDestination et HashMeta. Ce qui signifie que tout lien précédent disposant de ces quatre champs invalide le nouveau lien. Pourtant ce n’est pas tout à fait le même, même si il lie exactement les mêmes objets dans le même ordre et avec la même action. Ce lien peut être fait par une autre entité, rien de grave, quoique ça dépend du sens. Mais il peut être aussi généré avec une autre date, ce qui à une signification particulière = c’est le même lien volontairement refait plus tard…

L’exemple qui permet simplement de valider cette réflexion sur la multiplicité de ces liens, c’est la possible désactivation de lien.
Soit un lien L. Il peut y avoir un lien intermédiaire X (de type x) dans le temps qui invalide la première instance du lien L. Et on peut recevoir un deuxième lien L’ identique dans l’action demandé sur les même objets, et ce sans forcément avoir reçu le lien intermédiaire X de désactivation. Si l’on ne tient pas compte de la date, cela entraîne une désactivation du lien L’ à posteriori alors qu’il avait été volontairement refait après…

Une autre raison, si on se place sur un comportement plus sociale, on peut avoir répondu plusieurs fois la même chose à quelqu’un… mais à des moments différents.

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…

Horodatage ISO 8601

L’un des problèmes actuels avec les liens, c’est que le caractère tiret « – » est utilisé comme séparateur. Hors, il est aussi utilisé par le format d’horodatage universel tel que définit dans la norme ISO 8601. Celle-ci utilise aussi le caractère spécial deux-points « : ».

Il faut donc modifier le séparateur de champs du registre des liens. Le protocole des liens nebule passe en version v1.1 avec un nouveau séparateur de champs.

Toutes les expérimentations en cours vont progressivement migrer…

RDF

Fort des premières réflexions et expériences, il est maintenant possible pour moi de regarder ce qui se fait déjà. On trouve sur Wikipedia des articles intéressants sur le web sémantique, le Web 3.0, les métadonnées, le web des données et l’Internet des objets.

L’ensemble est chapeauté par le web sémantique et sa pile (Semantic Web Stack). On parle aussi de Web 3.0 bien que ce terme semble être un terme commercial fourre-tout comme le fut le Web 2.0.

Le point centrale semble être le Resource Description Framework (RDF). Ce n’est pas un format de données ou protocole d’échange, mais plutôt un guide de fonctionnement des relations entre différentes URI. Différents protocoles se chargent de décrire les implémentations pratiques. Le XML via RDF/XML est un format d’échange de ces relations, tout comme N3, Turtle, RDFa ou FOAF. Le XML et l’URI sont marqués comme des références, c’est l’héritage du W3C.

Semantic Web Stack
Semantic Web Stack, la pile du web sémantique (source Wikipedia)

Tout ça c’est bien beau, avec plein de schémas, de liens entre les articles, de termes pompeux, d’explications vagues… mais à quoi ça sert?
Ah rien en fait! Non, quand même pas :-)
On trouve surtout des informations plus intéressantes et intelligibles sur les sites de référence des différents protocoles.

Continuer la lecture de RDF

Empilement de liens

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.

Identification/authentification sur l’internet des objets

Un interview de R.Haladjian revient sur l’Internet des objets.

L’internet des objets, c’est en gros la capacité d’interagir à distance avec des objets de notre environnement, et à ces objets de communiquer sur le réseau de façon autonome.

Une des remarques concerne la connectivité en IPv6. Ils sont revenus à IPv4 parce que « par exemple une prise électrique disposait d’un serveur et n’importe qui ayant obtenu l’adresse de cette prise électrique pouvait la pinger pour l’allumer et l’éteindre à distance. Il fallait donc mettre un pare-feu pour empêcher l’accès… Donc finalement il est plus intéressant de rester en IPV4 avec un DHCP qui distribue des adresses« .
Il est étonnant que l’on revienne à une solution dont on sait pertinemment qu’elle ne supportera pas la mise à l’échelle (de l’internet, et donc du monde) des objets connectés sur le réseau (internet). On se contente d’une vision de ces objets à courte distance, en gros de l’ordre de grandeur de la maison.
Ce recul est je pense une mauvaise réponse à un problème mal posé. Le problème concerne l’identification de qui peut dans l’exemple allumer/éteindre la lampe. Si il n’y a pas d’identification, c’est normal que tout le monde puisse le faire, une adresse IP n’est pas à considérer comme un secret même en IPv6. Mais mettre en place une identification/authentification forte sur les méthodes actuelles est fastidieux pour un grand nombre d’objets. Le problème est d’ailleurs déjà un problème commun sur les ordinateurs résidentiels. Donc parce que l’on ne sait pas mettre en place une identification correcte, on bride l’ensemble du système.
Je n’ai pas regardé comment est faite l’identification/authentification sur leurs objets. Mais cette remarque m’incite à penser qu’elle n’est pas innovante, et donc pas à la hauteur. Et, en regardant du côté de nebule, le problème semble du coup beaucoup plus facile à résoudre…

Il y a un autre aspect de l’internet des objets, c’est la gestion des objets physiques inertes d’un point de vue numérique. Ils sont reconnus par un identifiant unique, mais ils n’interagissent pas. C’est l’exemple du code barre sur les articles à vendre d’un magasin, ou la puce RFID qui les remplacera, ou la plaque d’immatriculation d’une voiture. La vision primaire de l’internet des objets avec des étiquettes collées partout me semble ubuesque : le monde deviendrait une poubelle recouverte d’étiquettes en tout genre que plus personne ne regarderait…
Pour nebule, ces identifiants numériques, quel qu’en soit leur forme ou norme, sont encodés dans des objets avant de pouvoir être liés et donc gérés. On peut même penser qu’ils seront attaché virtuellement à des positions géographiques.

Liens :
– http://mobile.clubic.com/technologies-d-avenir/actualite-528965-leweb-12-haladjian-pere-nabaztag-internet-objets.html
– http://fr.wikipedia.org/wiki/Internet_des_objets
– http://fr.wikipedia.org/wiki/Web_3.0