11–20 of 87 posts
Provided that they figure out a way that absolutely nothing can be done with the information other than to say, "This non-identifiable machine reports that it uses Fedora," I'd be okay with that.
Any distro that phones home with a unique identifier is a distro I won't touch with a ten foot pole. I don't care what they claim they will or won't use that identifier for.
For example, sending a unique identifier is not the problem. Tracking people through a unique identifier is. So, depending on your goals, you can design a unique identifier system that does not allow tracking (or at least makes the tracking period so small as to be unuseful for purposes other than designed) as outlined in the article through changing the identifier on the client side weekly.
If all you want to do is get a good estimate of how many users use what types of configurations of your software (major and minor version), a UUID that rotates weeks on the client side is perfectly acceptable to use for those statistics to a fair degree of accuracy.
On the other end of the spectrum, people long ago started reducing their trackable footprint online, and the online tracking ecosystem just evolved to finding people through other, trickier methods, such as browser fingerprinting.
If Fedora server is compromised they can serve different packages to different users.
Just count the number of bug reports. That seems like a more useful metric anyway. If the users aren't complaining who cares. (about 75% serious)
If you want to count users, ask for permission during firstboot. If that's too much to ask, then I'll be in the market for a new OS. Maybe I'll finally go back to my first love: FreeBSD.
Wonderful. I guess I'll now have to find a way to regenerate this UUID or to spoof it every time Fedora tries to phone home. If you want to count users, ask for permission during firstboot. If that's too much to ask, then I'll be in the market for a new OS. Maybe I'll finally go back to my first love: FreeBSD.
No tracking, just simple numeric data for for purpose.
That seems to be what Poeterring's approach counts.
Just count the number of bug reports. That seems like a more useful metric anyway. If the users aren't complaining who cares. (about 75% serious)
It's not a consistent metric. You'll get both spikes around new releases and changes that reflect the automated reporting/ease of reporting changes.
Any distro that phones home with a unique identifier is a distro I won't touch with a ten foot pole. I don't care what they claim they will or won't use that identifier for.
Maxims that act on the symptom rather than the problem rarely help in the end, as the problem just evolves to support its needs through other means. For example, sending a unique identifier is not the problem. Tracking people through a unique identifier is. So, depending on your goals, you can design a unique identifier system that does not allow tracking (or at least makes the tracking period so small as to be unuse…
> you can design a unique identifier system that does not allow tracking
You can (sortof), but we run against that trust issue again. If I'm giving a unique identifier to someone, I have no way of knowing if their assertions about its use are accurate. Even if they are, there's no guarantee that won't change in the future.
> If all you want to do is get a good estimate of how many users use what types of configurations of your software (major and minor version)
You're talking about the perspective of the publisher. I'm talking about my perspective as a user. A company's "need" to collect metrics is their problem, not mine. If their solution results in more information disclosure than I'm comfortable with (and a unique identifier absolutely is), then I will avoid their software or block communications to their home base.
Earlier quoted context omitted.
Maxims that act on the symptom rather than the problem rarely help in the end, as the problem just evolves to support its needs through other means. For example, sending a unique identifier is not the problem. Tracking people through a unique identifier is. So, depending on your goals, you can design a unique identifier system that does not allow tracking (or at least makes the tracking period so small as to be unuse…
You're right in general, of course. But here's the reason for my hardline stance on that: history shows that trusting promises or assertions made about things like unique identifiers is unwise, and so I have to take a strong defensive stance. > you can design a unique identifier system that does not allow tracking You can (sortof), but we run against that trust issue again. If I'm giving a unique identifier to someon…
When it's couched in how to deliver software updated, it becomes your problem as well. That's a transaction, and they want to charge more for it now. You can decide it's too costly, as you indicate here, but it's not like they're giving nothing in return.
I think it's important to note the goals of those involved. In this case, it's the people that put together a free product for us to use and also supply free timely software updates looking for more information on who is using what so they can do a better job at delivering that free stuff to us.
And in this case, it's not adding tracking where it doesn't exist, it's making it better for the specific cases that are useful to them and that impact users the least (an accounting of software configurations). They already track through IP address, but that's inaccurate to a much larger degree for the information they want (but somewhat less so for the personal information you likely want to protect). Adding an additional system that allows better tracking of the useful information without increasing the personally identifying features of IP based tracking (which still exists) is laudable, in my eyes.