Ben Cotton wrote:
systems, but a quick thing we can do is implement a per-system UUID
(unique identifier) and count that instead of IP addresses.
Please no! This is an inherent privacy violation. I hate software doing this
and I always opt out of it. I find it especially worrying that Free Software
is now doing this more and more often, this used to be something only
privacy-violating proprietary software would do.
=== The problem ===
* A. Currently, we can only count Fedora OS use by observing IP
addresses. This is subject to undercounting due to NAT — and to
overcounting due to short DHCP leases and laptops moving between work
or school and home or coffee shop.
You will never be able to reliably count all Fedora installations. Any UUID
you introduce can be opted out of, bypassed, etc. Installations using local
mirrors for updates will never send you a UUID to begin with. All numbers
will always be estimates, no matter how deeply you invade our privacy in an
attempt to get a supposedly better count.
I also don't see why it is so important to have an absolute count of Fedora
users. IMHO, data like the relative download frequency of the different
Fedora deliverables is much more interesting (though you have to keep in
mind that the download count does not necessarily reflect the true user
preferences because deliverables that you advertise more prominently will
necessarily get downloaded more often than those hidden behind several
clicks from the download page).
=== Constraints ===
* The Fedora community cares about privacy and is adverse to tracking
measures. We don't want to track; just count.
But sending a UUID inherently also allows to track the machine. There is no
way for the user to be sure that the UUID will not be used to track them.
Even if the software on the Fedora infrastructure is completely open and
audited, there might still be some proxy in the middle, some mirror
operator, etc. abusing the UUID for tracking purposes. And besides, the user
would in all cases have to trust that Fedora really runs the published code
and only the published code on the infrastructure servers.
The only reliable way to ensure that users will not be tracked by a UUID is
to not send a UUID to begin with!
* For this reason, we don’t want to use any identifier like
/etc/machine-id which may be used for other purposes.
I don't think using an identifier different from /etc/machine-id will really
help all that much. Whatever identifier you use can be abused for tracking.
* And, also for that reason, there needs to be a relatively easy way
Such a tracking feature must be opt-in, not opt-out! See also the EU GDPR.
But I think that such a privacy invasion is incompatible with the Fedora
project's goals to begin with, even if it is opt-in.
* This needs to work with Yum/DNF, MicroDNF, PackageKit, Cockpit,
rpm-ostree, GNOME Software, Muon, Apper, and software update
mechanisms used in other spins.
Apper is no longer shipped in Fedora. The KDE Spin uses plasma-pk-updates as
its official updater, but Discover and Dnfdragora (which are both shipped
for different purposes) can also be used to update the system.
But if you require an explicit opt out in more than one place (e.g., once
for DNF and once for PackageKit), that makes this feature all the more
dangerous and scary.
* We need to be able to distinguish between short-lived instances
(like temporary containers or test machines) and actual installations.
And how would you accomplish that? Other than an "I am a test installation"
checkbox in the installer, I don't see at all how it could be done.
=== Non-Goals ===
* We don’t want to track users, just count systems.
Again, there is no way you can guarantee that. We would have to take your
word for it. This is not acceptable.
=== Other Elements ===
* We may also want each report to contain a boolean flag showing
whether the system has been in use for at least 24 hours to help
separately categorize test and other throw-away instances.
So this is even more data that you would be collecting behind the user's
The installation would also only end up recognized as permanent after the 24
hours pass. And who says a test installation cannot last more than 24 hours?
I think it can last at least a week, but that also means that it would take
a whole week until you can reasonably assume that an installation is
Without being able to magically predict the future and without asking the
user, I don't think you can ever be able to make this distinction reliably.