Mot-clé - collecte de trace

Fil des billets - Fil des commentaires

samedi 7 mai 2011

Positionnement sur la nature et le statut de l'adresse IP

En lien avec mon positionnement sur la vie privée, je prend aussi position sur la nature et le statut de l'adresse IP.

Rappel sur l'IP

Une adresse IP est une série de chiffres et de lettres qui permet de contacter un dispositif informatique au travers d'un réseau, via une méthode de communication spécifique (protocole IP). Ainsi, tous les ordinateurs connectés à internet ne sont pas obligatoirement désignés par une adresse IP; ils le sont en revanche dans l'immense majorité des cas, mais pas de façon unique : un ordinateur a souvent plusieurs adresses IP qui permettent de le joindre et ces adresses peuvent changer [1].

Ce que (ne) dit (pas) la loi

Juridiquement, le statut de l'adresse IP est incertain : tantôt un juge la traite d'un manière, tantôt un autre la classe différemment. D'où un flou qui n'arrange personne en cas de dépôt de plainte [2].

Ainsi, pour la justice l'adresse IP est actuellement :

  • soit une donnée purement technique qui ne porte pas de valeur particulière et sert uniquement à l'interconnexion des équipements;
  • soit une information nominative qui permet d'identifier une personne derrière un ordinateur;
  • soit quelque chose entre les deux, une sorte de données technique qui peut devenir une fiche d'identité au travers d'un traitement adapté et en liaison avec d'autres données.

En résumé : il y a donc une grande incertitude sur le statut de l'adresse IP en France, ce qui ouvre la porte à toutes sortes de problèmes, mais aussi à des possibilités d'utilisation.

Networking 101 Networking 101

La question de savoir si l'adresse IP permet d'identifier (ou non !) la ou les personnes qui ont utilisé un ordinateur ordinateur est critique, car elle permet le traitement judiciaire : seule l'autorité légitime pour poursuivre l'enquête (police ou gendarmerie) pour obtenir du fournisseur d’accès l'identité de l'utilisateur

En effet, l'adresse IP est une série de chiffres et de lettres qui ne constitue en rien une donnée indirectement nominative relative à la personne dans la mesure où elle ne se rapporte qu'à une machine, et non à l'individu qui utilise l'ordinateur pour se livrer à une activité.

On a donc bien une différence entre l'identification d'une machine, et l'identification d'un humain. La mise en relation n'est pas automatique et doit être prouvée.

Lorsqu'on lis le Décret n°2011-219 du 25 février 2011 « relatif à la conservation et à la communication des données permettant d'identifier toute personne ayant contribué à la création d'un contenu mis en ligne », ce n'est pas plus clair pour autant : si les particuliers, associations et autres n'ont pas le statut juridique de « fournisseur d'accès à internet » (qui est soumis à une autorisation de l'ARCEP), ils n'ont pas non plus nécessairement le statut juridique d' « hébergeur » (les critères sont bordéliques). La loi n'apporte donc pas réponse aux questions posées.

Je comprend la loi comme disant entre les lignes que l'IP n'est pas juridiquement classée comme une donnée d'identification nominative, et n'est donc pas pas soumise à un encadrement spécifique pour les particuliers et associations.

Les logs, en pratique

Dans le cadre des services informatiques sur internet, il est habituel que ceux-ci conservent des enregistrements sur leurs activités et les dispositifs avec lesquels ils interagissent : ce sont les « logs ».

Techniquement, un log est juste une trace numérique que l'on défini comme on veut. Il n'y a donc pas un seul format de log, mais une multitude ayant des natures et contenus différents. Un même service peut conserver des enregistrements des interactions homme-machine et machine-machine sous plusieurs formes plus ou moins explicites. Pour parler de log, il faut donc bien le préciser.

Person Network Person Network

Le mot log ne doit pas être tabou de la discussion sur la vie privée en le classant immédiatement comme pratique intrusive; il est indispensable au bon fonctionnement du net, car le log constitue la mémoire de travail des services. Sans log, toute l'informatique navigue à vue.

Dans le cadre d'un log d'apache au format combiné, je comprend que le log est anonyme, vis à vis de la loi, car l'adresse IP n'est pas une donnée qui permet à elle seule d'identifier un individu.

Ce qui me laisse perplexe, c'est la double valeur que des gens prêtent à une adresse IP. Je constate les deux discours suivants :

  1. Dans les transferts par BitTorrent, on ne peut pas identifier l'utilisateur car une IP n'est pas une personne, c'est une simple information technique pour faire circuler les données; elle peut être falsifiée, détournée, contrefaite…
  2. Dans les logs de services web (ou autres tels que le courriel), on peut identifier l'utilisateur par son adresse IP, car c'est une information nominative.

D'où ma remarque : il faut être cohérent et se poser les questions suivantes :

  • supposément, qu'est-ce qui oblige à anonymer les logs d'un serveur web ?
  • supposément, qu'est-ce qui interdit de publier les logs, anonymés ou non, d'un serveur web ?
  • un particulier ou une association mettant en ligne un site web non-participatif (c'est à dire que les visiteurs ne peuvent pas contribuer à son contenu) sont-ils des « hébergeurs » au sens de la loi ?
  • quels sont les critères qui permettent de qualifier une donnée comme étant nominative ou qui permette de réaliser l'identification d'une personne ?

Réflexion dans le cadre du Parti Ꝓirate

Le Parti Ꝓirate (PꝒ) a pris position sur le fait que l'adresse IP n'est pas une donnée nominative qui permet d'identifier la personne qui télécharge via BitTorrent. Il me semble donc logique de conclure que l'adresse IP n'est pas, pour le Parti Ꝓirate, une donnée nominative qui permet d'identifier une personne se connectant à un service web.

Le fait est que, pour qu'il y ait publication, il faut auparavant qu'il y ait collecte.

Prenons le cas du PꝒ qui, très probablement (on va dire que oui si ce n'est pas le cas) conserve un log des transactions sur son serveur web.

Est-ce que je peux demander au PꝒ de consulter et supprimer de ce log toutes les informations personnelles qui me concerne ? Bien sur, c'est ce que la loi liberté et informatique de 1978 me garanti. En revanche, le PꝒ va très certainement me répondre « on veut bien, mais on ne peut pas : on n'a pas de données personnelles sur toi ».

Qu'à cela ne tienne, je demande alors au PꝒ de me dire tout ce qui concerne l'adresse IP de mon ordinateur (par exemple, 82.239.197.205). Et là, le PꝒ me répond « heu, qu'est-ce qui me prouve que c'est bien toi derrière cet ordinateur, et pas quelqu'un d'autre ? Et même si c'est le cas, vous n'êtes pas plusieurs dans ton foyer à utiliser cet ordinateur ? ». Godferdom ! Est-ce que le PꝒ refuserait de se plier à la loi ? Non, il ne fait que l'appliquer strictement, car la loi ne l'oblige pas de communiquer tout ou une parti des log de son serveur web.

Si la collecte d'adresse IP est obligatoire à différents niveaux pour plusieurs raisons, la publication de log anonyme de serveur web est donc bien un choix que l'on peut faire, ou pas.

Conclusion

À mon sens, cette mise à disposition d'informations est neutre sur l'usage : un individu peut s'en servir pour faire de la recherche scientifique (ce qui est légal), pour assurer de façon neutre le bon fonctionnement des systèmes informatique (c'est souhaitable), mais pas pour espionner une personne (c'est illégal). Le PꝒ n'endosse pas ici le rôle du législateur qui fait la loi, du juge qui l'arbitre, ou du policier qui la fait appliquer. Il se borne à faire ce qu'il veut, dans le cadre de cette loi.

De la même façon qu'on n'interdit pas la vente des couteaux en supermarché sous prétexte que quelqu'un pourrait faire quelque chose de mal avec, il ne faut pas, à mon sens, interdire a priori le partage des données sous prétexte que cela peut être dangereux.

T3 - L'anonymat T3 - L'anonymat

L'argument le plus courant pour refuser le partage des logs d'un serveur web est le droit à l'anonymat. L'adresse IP pouvant être utilisée (au même titre qu'un numéro de téléphone, une plaque d'immatriculation, etc) pour réaliser l'identification une personne, il faut alors la protéger. Je ne suis pas entièrement de cet avis.

S'il était vrai il y a encore dix ans qu'une adresse IP permettait de faire le lien entre une personne et un ordinateur d'une façon très fiable, ce n'est plus le cas de nos jours. Les pratiques (roaming, réseaux ouverts…) et technologies (NAT, IPv6, VPN) ont évoluées suffisamment pour aboutir à un découplage toujours croissant entre l'adresse IP (qui pointe vers un dispositif technique) et une personne se trouvant en bout de la chaîne de communication.

Il me semble dangereux de statuer sur la valeur nominative de l'adresse IP : cela entraîne des fausses identifications et donc des accusations portées à tord, et bride l'innovation en contraignant fortement la collecte et le travail sur des données. L'objectif final étant ici de forcer l'anonymat sur internet, je ne pense pas que ça soit la bonne méthode.

De plus, l'anonymat doit être un choix, garanti par la loi, et non une obligation. Prendre position en faveur d'un anonymat forcé, c'est pour moi vouloir maintenir une conception citadine de la vie privée datant des années 80. Les populations ont changées, les outils et les pratiques aussi, il ne faut donc pas imposer une stagnation législative qui empêche l'accompagnement de la vie.

À lire aussi

Notes

[1] cas de l'IPv6 qui permet d'affecter plusieurs adresses à la même interface

[2] CF les commentaires de Nicolas Herzog et la fiche Jurispédia sur l'adresse IP

vendredi 9 avril 2010

Première version du prototype de l'OGVIT

J'ai l'immense plaisir, l'honneur et la joie de vous annoncer qu'une première version de développement de l'OGVIT (Outil générique de Visualisation Interactive de Traces) tourne.

Oh, certes, c'est du brut de décoffrage et il manque encore plusieurs choses, mais la tuyauterie est en place (malgré un problème clairement identifié et contourné), et il est possible de charger une trace produite pour la consulter, et même la tripoter un petit peu.

On peut découvrir sur la capture d'écran :

  • en haut à gauche : le debug du KTBS; on voit les requêtes entrantes et sortantes
  • à droite du KTBS : le collecteur de traces faisant le lien entre weechat et le KTBS; on voit les données internes et le traitement
  • à droite du collecteur de traces : weechat-traces, le client IRC instrumenté pour produire des traces; on voir l'activité dans le chat
  • en bas à droite : le debug de l'OGVIT; on y voit sa détection de l'affichage d'éléments partiellement ou complètement superposés
  • en travers de tout : l'OGVIT qui affiche la trace de weechat; on voit l'axe du temps, les observés codés par couleur (bleu : frappe clavier; rouge moche : connexion)

Première démonstration de l'OGVIT

mercredi 16 décembre 2009

Avancement sur les outils de la trace

Hier est un jour à marquer d'un parpaing blanc : j'ai mis en place la première interconnexion de 3 outils différents qui manipulent des éléments de trace : le client IRC weechat, le préparateur de traces de weechat, et le ktbs. Plus précisément, la séquence réalisée est WeeChat → préparateur de trace → ktbs.

  • WeeChat : il s'agit du client IRC que j'ai instrumenté pour sortir des proto-observés représentant l'activité de l'utilisateur dans celui-ci.
  • préparateur de trace : un agent logiciel spécifique à WeeChat, développé par moi, en charge de :
    • construire des observés à partir des proto-observés
    • assurer l'interconnexion avec le SGBT
    • initialiser le SGBT pour permettre son utilisation (définition de l'utilisateur, du modèle, de la trace, etc)
  • ktbs : l'implémentation du SGBT réalisée par Pierre-Antoine

Ça n'a l'air de rien comme cela, mais tous ceux qui se sont concrètement frottés à la conception complète de modèles, à la création technique de traces, et au KTBS vous diront que c'est limite un exploit :)

Bon, maintenant pour être honnête, je dois dire aussi qu'il y a des warnings dans tous les sens, que ça crash aléatoirement et que c'est vraiment pas évident de tout faire tenir ensemble. Mais le résultat est qu'au final il est possible de demander au KTBS de recracher une trace qu'il a précédemment reçu.

Dans tous les cas, c'est encore loin d'être utilisable, même pour faire des petits essais. Le travail d'ingénierie à réaliser est LOURD, et le code pas réutilisable car spécifique à un outil. mais ça marche \o/

mardi 13 octobre 2009

Jouer avec un SGBT, c'est possible !

Il m'aura fallu un peu de temps, mais voici enfin deux scripts simples qui permettent de tester le KTBS de PA :

  • lancer_le_ktbs : démarre le KTBS en local
  • initialiser_le_ktbs : alimente le KTBS avec :
    • 1 utilisateur : alice
    • 1 modèle de trace : weechat
    • 1 trace : t01
    • 4 observés :
      1. joindre un canal
      2. envoyer un message
      3. recevoir un message
      4. quitter le canal

Avec ces scripts, il est possible de faire tourner un SGBT contenant des données afin d'interagir avec lui : demande d'observé, transformation, etc

Comment utiliser les scripts ? Facile.

-1) mettez en place un support IPv6 sur votre machine. Une adresse en fe80:* suffit

0) faites un checkout du KTBS : $ svn co https://svn.liris.cnrs.fr/sbt-dev/ktbs-rest-impl/trunk

1) ouvrez un terminal, et lancez le script lancer_le_ktbs avec comme argument le chemin vers bin/ktbs que vous venez de récupérer

Par exemple :

$ ./lancer_le_ktbs ../bin/ktbs 
=== Using IPV6
KTBS example at http://ip6-localhost:8001/

2) ouvrez un terminal, et lancez le script initialiser_le_ktbs. Admirez la sortie standard qui vous donne les valeurs de retour du KTBS (sauf celle de l'étape 2 qui est filtrée). Admirez également la sortie standard du KTBS qui vous indique les données reçues.

ip6-localhost - - [13/Oct/2009 16:26:51] "POST / HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:51] "POST /alice/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "PUT /alice/weechat/ HTTP/1.1" 200 386
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0
ip6-localhost - - [13/Oct/2009 16:26:52] "POST /alice/t01/ HTTP/1.1" 201 0

Pointez maintenant votre navigateur préféré sur l'interface web du KTBS (http://ip6-localhost:8001/alice/t01/@obsels) et admirez votre trace (ou plus exactement celle d'Alice) de WeeChat conforme au modèle spécifié.



Vous pouvez maintenant travailler avec le KTBS.

mercredi 23 septembre 2009

Interconnexion application flash ↔ KTBS

Bonne nouvelle, les interconnexions sont en train de se mettre en place entre le KTBS et différents prototypes. Par contre, il reste du boulot.

Enfin bon, ça commence à tourner, c'est le principal. Voici un extrait de code en ActionScript montrant comment faire un aller-retour entre une application Flash et le KTBS. Notez la création simple de la liaison pour le service web via le HTTPService(). En revanche, ne me demandez pas (encore) comment on fait si la connexion timeout, saute, se bouche ou autre. Il est également possible d'utiliser directement des sockets, ce qui est pratique pour affiner les choses à la main.

Sérieusement, ce langage est immonde. Ça a la lourdeur du javascript, et la grammaire a été conçue par un polonais shooté à la vodka : ça ressemble presque à un langage normal, sauf quand ils se sont amusé à permuter l'ordre des éléments sans aucune raison valable (genre variable:type ← franchement, faut être malade pour inventer ça...). C'est supposé être un langage de haut niveau, userfriendly et tout, mais on se tape les contraintes héritées des années 70 (marqueur de fin de ligne, typage fort, etc). Et surtout ils ont tout pété entre les versions 2 et 3 du langage. Sans compter que le compilateur (en java) a le dynamisme d'une vache salers explosée au Lexomil.

Dernier détail : sur le papier, l'eventListener fonctionne, mais en pratique il ne me donne rien; je soupçonne fortement un tripatouillage interne des données, genre « bouge pas, je vais te mettre ça en forme et nettoyer ce qui ne sert pas ». Ben tiens...

// l'objet décrivant le SGBT
private var _sgbt :HTTPService;


/*
 * constructeur de KTBS
 */
public function SGBT() :void {
// création d'un service web sur le KTBS de PA
	_sgbt = new HTTPService();
	_sgbt.url = "http://ip6-localhost:8001/";
	_sgbt.method = "GET";
	_sgbt.contentType = "application/rdf+xml";
// reniflage de la réponse du KTBS, avec appel à reponse() en lui passant les données retournées
	_sgbt.addEventListener(ResultEvent.RESULT, reponse);
	_sgbt.send();
}


/*
 * traite les données reçues du KTBS
 * retourne : rien
 * mesData est l'événement provenant du listener sur requête du KTBS
*/
public function reponse(mesData :ResultEvent) :void {
	_sgbt.removeEventListener(ResultEvent.RESULT, reponse);
// trace() est une primitive de déboguage écrivant sur la sortie standard
	trace(mesData.result.toString());
}

lundi 7 septembre 2009

Génération automatique du modèle de trace d'une application instrumentée

Le problème

Maintenir la conception du modèle de trace d'une application de la conception de l'application n'a pour moi pas de sens : on perd du temps à passer de l'un à l'autre, on s'embrouille et c'est une approche préhistorique (ou du moins datant du COBOL :)

On pourrait se dire que disposer d'un modèle de l'application ne présente pas nécessairement un intérêt quand on cherche à obtenir une trace des interactions d'un utilisateur, mais pour moi c'est sauter une étape.

En effet, depuis de nombreux mois plusieurs personnes de l'équipe SILEX travaillent sur des modèles d'interactions. Au delà des problèmes concrets lié à l'expression de modèles conformes au métamodèle, il se pourrait qu'une des choses qui nous freine soit de vouloir réaliser tout de suite un grand pas : on ne sait pas décrire le comportement d'une application, alors qu'on veut décrire le comportement de l'utilisateur dans cette application.

La solution (possible ?)

Plus j'y pense, et plus je me dis que la solution passe peut-être par une génération automatique des modèles de l'application. Le principe serait alors de générer le(s) modèle(s) de l'application à la compilation, sur le même principe que la documentation des API tel javadoc ou doxygen.

On peut songer à quelque chose de similaire au javadoc : avec des marqueurs bien placés dans le code, on génère à la compilation des modèles correspondant à des éléments d'interface.

Du coup, on permet au développeur de structurer les modèles de l'application, tout en permettant à l'utilisateur de concevoir des modèles supplémentaire.

Conceptuellement

idée clé : les API sont un modèle de l'application orienté développeur; le modèle de trace d'interactions est un modèle de l'application orienté utilisateur.

Cette approche serait utilisée, a priori, uniquement pour les applications instrumentées directement dans le code. Éventuellement, peut-être aussi pour les enrichissements d'application à base de plugins, mais il faudrait que j'y réfléchisse.

En pratique

Pour réaliser la génération de modèle d'application, ces questions pratiques se posent : sur quelles fonctions placer les marqueurs de génération d'observés ? Callback/méthode associés aux widgets ? D'une façon générale, très probablement sur les fonctions les plus proches de l'utilisateur, donc au niveau des E/S. L'idée est de ne pas ajouter de code, juste des commentaires contenant les marqueurs.

On commence par définir globalement les propriété communes : références au métamodèle, à l'extension temporelle, etc. On peut songer par exemple à un mécanisme de macro ou de variables (je l'appellerais ici « en-tête 1 »

=define "en-tête 1"
@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .

Puis, dans le code de l'application on insère les marqueurs pour la génération du modèle

/*
 * =include "en-tête 1"
 * =type presseTouche
 * =description "décrit la frappe d'une touche dans la zone de saisie"
 * =string "versionDeWeeChat"
 * =string "monPseudo"
 * =string "nomDuCanal"
 */ 
LaFonctionGérantLesFrappesClavierDeLutilisateur(...) {
	...
}

Et là, c'est le drame car il faut exprimer des choses comme comme le fragment ci-dessous.

>:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;%%%
	xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
]

Mais l'idée reste la même : pour moi, les informations permettant la génération du modèle doivent être notées sous forme réduite, juste à côté du code, et sans gêner les développeurs.

Le modèle généré :

@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .


mod:presseTouche a :ObserType .


mod:versionDeWeeChat a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:monPseudo a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:nomDuCanal a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
		owl:onDatatype xsd:string ;
		xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
	] 
.

mod:nomDuServeur a :Attribute ;
	rdfs:label "Nom du Serveur"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(IPv4|IPv6|hostname)"
	]
.

mod:typeDeTampon a :Attribute ;
	rdfs:label "Type de tampon"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-2]"
	]
.

mod:caractère a :Attribute ;
	rdfs:label "Caractère frappé"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(\*?|STRING)"
	]
.

mod:zoneDeSaisieAvantCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie avant la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:zoneDeSaisieAprèsCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie après la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:drapeauAway a :Attribute ;
	rdfs:label "Status de présence"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(0|1)"
	] ## ?? vérifier dans la spec de OWL 2
.

mod:contenuDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Contenu de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:contenuDuMasqueDeCouleurDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Masque de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:positionDuCurseurDansLaZoneDeSaisie a :Attribute ;
	rdfs:label "Position du curseur dans la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-9]*"
	]
.

lundi 8 juin 2009

Diigo : un outil de web social

Diigo est un outil d'enrichissement partagé du web.

Ses principales fonctionnalités sont :

  • la gestion de bookmarks en collections (comme Reddit)
  • la gestion de groupes d'utilisateurs (comme Reddit)
  • le partage de bookmarks entre utilisateurs et groupes (comme Reddit)
  • le marquage par tags de bookmarks (comme Reddit)

Jusqu'ici, que du très classique me direz-vous. Là où Diigo devient intéressant, c'est avec ses possibilités d'enrichissement du contenu.

Il est ainsi possible d'annoter une page web, de la même façon qu'on annoterait un PDF. Ces annotations peuvent être privées ou partagées. Des outils permettent de trouver rapidement toutes les annotations partagées au sein d'un groupe et de les consulter, autorisant ainsi une lecture collective asynchrone de ressources web.

Les annotations sont attachées à des éléments précis d'une page web (zone de texte, par exemple) pour créer une forte contextualisation.

Annotations dans Diigo

Lors de la navigation web, il est possible de filtrer les annotations existant pour une page afin de ne visualiser que celles provenant de personnes ou de groupe précis.

Filtrage des annotations dans Diigo

Également, Diigo permet des commenter des pages et sites web. À la différence des annotations, ces commentaires sont globaux et approprié à la mise en place de discussions simples.

Commentaires dans Diigo

En revanche, Diigo ne permet que de « plusser » des bookmarks afin de leur attribuer une note globale, là où d'autres outils (comme Reddit) ont plus de possibilités.

Une des fonctionnalités de Diigo est très intéressante pour SILEX : il est possible de s'abonner aux flux RSS de presque tous les éléments existants : activité des membres d'un groupe, annotations liées à une page, commentaires, mot-clé, etc. Ce qui veut dire qu'en mettant en place un préparateur de trace RSS→observé on a la possibilité d'alimenter le SGBT, et donc d'avoir un traçage d'une activité collective tournant autour des bookmarks.

Ah oui, et aussi : Diigo pourrait permettre à SILEX de partager simplement des trouvailles sur le web ;)