> Quoting Arnt Karlsen (a...@iaksess.no): > > > ..my /etc/cron.d/machine-id: > > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > > > # ..a new /etc/machine-id every minute... ;o) > > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > > >/dev/null 2>&1 > > _Very_ nice solution. I think I'll steal it whenever I finally need > /etc/machine-id .
For those who copied that into your crontab: Note that this will leak what timezone you are in to the bad guys (who seem to be the authors of chrome) assuming they have read this thread. And if your clock drifts by more than a few seconds, it might still identify you quite well. Arnt's improvement of adding fortune to md5sums input might be a good plan assuming fortune doesn't do a srand(time()); internally. But what really blows me away is that these ids exist on Debian to begin with. I had been under the assumption that free systems are built according to the needs and desires of their users, and few users go "what I really need in this day and age is less privacy". So instead of adding crontab rules to obfuscate the ids, I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Much has been written about Debian's Social Contract, but it seems to be ineffective against this type of spying, whether it involves falling back to 8.8.8.8 as name-server, or scattering machine ids all over the filesystem. I think Devuan has an opportunity to do better - going by the number of messages in this thread it is an issue which worries many people. A good starting point might be to update the "Tags:" package field, to include a "leaking::" category. So packages would not only described as being "implemented-in::c" but also as "leaking::host-id" or "leaking::clickstream". Then one could aim to have a "leak-free" build, like people try to have a "reproducible build"... regards marc _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
