En fait, c'est un plus compliqué que cela. Par exemple, il semble que Chrome envoie une forme hashée du sytem-id à ses serveurs, et c'est ce que recommande la page man :

This ID uniquely identifies the host. It should be considered  "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

Alors effectivement, du hash, on ne peut pas remonter au machine-id directement, mais l'application elle sait que c'est bien la même machine. Je suppose que le GDID windows est transmis de la même façon.

Donc si on sait que la machine qui a transmis le hash utilisait telle adresse IP, et qu'au même moment cette même adresse IP a été utilisée pour se connecter à un serveur de commande, et cela à plusieurs reprises, on peut bien faire le lien entre ces différentes connexions et les attribuer à la même machine.

Et bien sûr si on connait le machine-id, parce que l'on a saisi la machine par exemple, et que l'on applique le même hash, on peut savoir s'il correspond.

Si Chrome le fait, on peut penser que d'autres applications peuvent le faire aussi. En tout cas, Chrome aussi est sous le Patriot Act, comme RedHat par exemple aussi.

Voir par exemple :
https://linuxfr.org/users/freem/journaux/systemd-identifiant-unique-world-readable

La comparaison avec /etc/machine-id est intéressante, mais ...
Sous Linux, le machine-id est avant tout un identifiant local. La doc systemd précise même qu’il doit être considéré comme confidentiel et ne pas être transmis directement sur le réseau. Une application est censée en dériver un identifiant qui lui est propre.

Dans la plainte, le plus notable n’est donc pas seulement l’existence d’un identifiant persistant sous Windows. Ce sont les données que Microsoft semble pouvoir lui associer : URL consultées, horaires et adresses IP utilisées.

Dans un environnement Microsoft 365 chez Vernam que j’ai administré, j’avais déjà constaté que plusieurs services pouvaient corréler durablement un poste via différents identifiants même lorsque l’adresse IP changeait.

Bonjour, j'ai un soucis (encore) avec la Livebox 5 et l'IPv6, e fait j'utilise le NAT66 sur opnsense (merci le /64 unique et le routa
 délégué par la box et son routage bugué...) : en fait pour laisser OPNsense gérer les ports de mes sites et mon NTP public auto hébergés : je demande a la Livebox d'ouvrir une plage énorme gere 3-60000 UDP et TCP vers l'IP du routeur qui va lui ouvrir les ports mais peu importe : si les appareils (du moins mes LXC proxmox ou mon OPNsense, surtout OPNsense ducoup) restent allumés mais que la box reboote ou se retrouve éteinte et rallumé, eh bah mes sites et mon NTP deviennent inaccesibles aux autres, mais mon routeur à encore accés à internet, en fait, la je crois que la Livebox est "amnésique" et oublie l'IP du routeur, et dans ce cas, le routeur accéde a internet, mais internet ne voit pas le routeyr à cause de la box, et si je dis "les LXC à la nox" comme si y'avait pas OPNsense, c'est car je vais surement installer un serveur Proxmox chez un copain, qui est chez Orange aussi je crois et 'a pas de routeur tiers comme OPNsense et il y aura des sites hébergés et peut être d'autres choses... Donc chez moi pour le moment le bricolage pas top est de désactiver l'IPv6 quelques temps (quelques minutes ou secondes) et le remettre et là la box le reconnaît à nouveau et ça repasse...

Sauf que déja, c'est du bricolage pas top, et ensuite, comme j'ai dit je vais installer un serveur Proxmox chez un copain, qui lui aura la Livebox en tant que routeur.

Donc petit soucis : j'ai pas forcément que ça à faire de vérifier et "réparer" (en désactivant réactivant l'IPv6) les sites qui perdent de l'IPv6 à cause d'un firmware de box (si ça vient de là) 

Merci et bonne journée / bonne soirée

Voir mes captures d'écran ci dessous.

Leon.

Histoire de, testé rapidement sur un raspberry pi 5 en ethernet sur mon réseau:



Je suppose que sur une plus grosse machine, cela ne devrait pas beaucoup plus s'améliorer de toute façons, à part peut être grater les 0.50/0.25ms  bien que, il est uniquement en 1gb, je verrais sur une machine en 10gbps à l'occasion...

Bonjour,
est ce toujours d'actualité ?