> Quoting Arnt Karlsen (arnt@???):
>
> > ..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