L’horodatage des liens est important pour leur interprétation. C’est particulièrement vrai pour démêler les suppressions. L’horodatage est placé dans les liens, ce qui veut dire que ce n’est pas l’objet qui est daté mais son usage.
On traite ici la suite des articles Horodatage, suite, Gestion temporelle partielle, Transfert de liens et de confiance, et cela entrera dans l’Etude du temps.
Vis-à -vis de l’anonymisation des entités, et surtout des personnes derrières, la gestion du temps nécessaire à l’horodatage peut poser problèmes.
Le problème c’est la synchronisation sur une source unique. Utiliser deux ou trois source réduit le problème mais uniquement de façon linéaire. Cette source unique sera régulièrement consultée et donc verra la source des demandes, notamment d’un point de vu adresses sur le réseau. Mais qui dit demande de synchronisation de temps ne veut pas dire présentation de l’entité qui le demande. La corrélation peut être faite après coup en comparant les marques de synchronisation de temps d’une entité avec les logs de connexion. Le risque ici est de récupérer la localisation d’une entité. Pour beaucoup de personnes, la connexion à son système d’information se résume à son ordinateur à la maison, son téléphone/tablette et à son travail. Avec la connexion depuis le domicile, on peut casser assez facilement l’anonymisation.
L’utilisation de plusieurs moyens informatiques pas forcément synchronisés entre eux en terme de temps introduit des problèmes pour calculer un décalage de temps et une dérive éventuelle. Dans ce cas, la relation entre entité et localisation ou entre entité et individu est plus dure à obtenir, mais pas impossible.
On peut utiliser la même entité source de synchronisation de temps mais en passant par des relais. Il faut dans se cas récupérer les dernières marques de l’entité de gestion du temps et le rejouer. En passant par une entité intermédiaire, on casse la corrélation possible entre les connexions et les marques de temps. C’est au prix d’une moins grand précision dans le calcul du décalage de temps.
Si on utilise un système de synchronisation des machines, tel que NTP, les machines se synchronisent sur des références de temps cohérentes. Noyé dans la masse des connexions, les synchronisations d’une entité ne permettent pas de lever son anonymat. Malheureusement, cela ne fonctionne que si les machines sont en réseau. Tout au plus peut-on se contenter d’une synchronisation irrégulière et espacée dans le temps. Dans ce cas, l’absence de marques de temps d’une entité ne permettra pas de calculer son décalage, et donc on en sera réduit à supposer qu’elle est à peu près à l’heure.
Dans tous les cas, il est possible d’utiliser en même temps une synchronisation précise par NTP et un calcul de décalage de temps. Des machines synchronisées devraient avoir un décalage proche de 0. Pour ne pas affaiblir l’anonymat des utilisateurs, il est préférable d’avoir une synchronisation NTP et d’utiliser les marques de temps mais horodatées sur son heure propre. Les marques de temps seront récupérées aléatoires chez les entités connues.
La gestion du temps va générer un trafic propre tant en réseau qu’en terme d’objets et de liens. Il faudra prévoir un nettoyage fréquent et à court terme de ces objets et liens avant qu’ils ne saturent les échanges entre entités.
Enfin, cela n’a peut-être pas trop d’importance à première vue mais c’est quand même une entorse à l’anonymisation, générer des marques de temps régulières pour permettre les synchronisations ne peut se faire que lorsque l’entité est déverrouillée. C’est à dire que l’on a des marques de temps que quand on est connecté, ce qui trahi les heures de présence effective mais aussi fait office de marqueur de présence. La parade est de ne faire des marques synchronisation de temps que… de temps en temps. Cette parade se fait au prix d’une perte de précision dans le calcul du différentiel de temps, surtout avec des machines multiples.