One thing that unique IDs are necessary for, is deduplication. Without a unique ID when talking to e.g. the update server, then their statistics (used to determine which updates should be e.g. CDN prioritized) will be heavily skewed in favor of anyone who has configured their system to poll the server more often.
(Yes, they can partially resolve this problem by looking at the request IPs—but, well, NAT. Sometimes even entire countries are behind a small set of IP addresses (https://en.wikipedia.org/wiki/Carrier-grade_NAT).
The ideal thing here would be for everyone to have a public IPv6 address, and then that address could be your "unique ID" without really uniquely identifying you or your device, but rather just uniquely identifying "a place to deliver updates to", like a mailing address uniquely identifies a place to deliver parcels to.
(This might not seem so relevant for updates, but a clearer example is in crashes. All OS vendors prioritize the issues in their issue-trackers by their prevalence among users, counted as the number of times a Crash Report has been [voluntarily] submitted that seems to be "about" that issue. Crash reports need to be deduplicated by installation to be useful for prioritization; a piece of software that happens to get into a super-edge-case crash loop and so crash a million times for one user, should not be prioritized over a piece of software that crashes once for a million users. Just the opposite, really.)
> hardware info
If we're talking about software updates, then this is part of the "inescapable metadata." Yes, the OS vendor can stuff each update full of all possible updates for all possible drivers released in the interrim—and that's a workable idea, if you're Linux. It's not workable in the Windows/macOS ecosystems, where "drivers" are third-party bloatware blobs that ship with their own GUI control panels et al. Such a monolithic update, covering all possible bloatware driver blobs, would be hundreds of GiB. It makes far more sense in Windows/macOS to just have the client retrieve the GPU/RAID/printer/camera/etc. drivers (and updates for said drivers) they need, as separate packages, from the server. And that separate retrieval essentially describes, piece by piece, your hardware profile.
> require them to keep logs
I never said it was (or should be) required; only that, if you're paranoid, you should have no reason to believe that they're not doing that, even without any client-side telemetry being pushed. A paranoid person would expect that even Linux distributions keep the access logs for their package servers (incl. gathering them from mirrors), and act accordingly.
One thing that unique IDs are necessary for, is deduplication. Without a unique ID when talking to e.g. the update server, then their statistics (used to determine which updates should be e.g. CDN prioritized) will be heavily skewed in favor of anyone who has configured their system to poll the server more often.
(Yes, they can partially resolve this problem by looking at the request IPs—but, well, NAT. Sometimes even entire countries are behind a small set of IP addresses (https://en.wikipedia.org/wiki/Carrier-grade_NAT).
The ideal thing here would be for everyone to have a public IPv6 address, and then that address could be your "unique ID" without really uniquely identifying you or your device, but rather just uniquely identifying "a place to deliver updates to", like a mailing address uniquely identifies a place to deliver parcels to.
(This might not seem so relevant for updates, but a clearer example is in crashes. All OS vendors prioritize the issues in their issue-trackers by their prevalence among users, counted as the number of times a Crash Report has been [voluntarily] submitted that seems to be "about" that issue. Crash reports need to be deduplicated by installation to be useful for prioritization; a piece of software that happens to get into a super-edge-case crash loop and so crash a million times for one user, should not be prioritized over a piece of software that crashes once for a million users. Just the opposite, really.)
> hardware info
If we're talking about software updates, then this is part of the "inescapable metadata." Yes, the OS vendor can stuff each update full of all possible updates for all possible drivers released in the interrim—and that's a workable idea, if you're Linux. It's not workable in the Windows/macOS ecosystems, where "drivers" are third-party bloatware blobs that ship with their own GUI control panels et al. Such a monolithic update, covering all possible bloatware driver blobs, would be hundreds of GiB. It makes far more sense in Windows/macOS to just have the client retrieve the GPU/RAID/printer/camera/etc. drivers (and updates for said drivers) they need, as separate packages, from the server. And that separate retrieval essentially describes, piece by piece, your hardware profile.
> require them to keep logs
I never said it was (or should be) required; only that, if you're paranoid, you should have no reason to believe that they're not doing that, even without any client-side telemetry being pushed. A paranoid person would expect that even Linux distributions keep the access logs for their package servers (incl. gathering them from mirrors), and act accordingly.