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…
Fedora, UUIDs, and user tracking
31–40 of 87 posts
Re: Fedora, UUIDs, and user tracking
#32Re: Fedora, UUIDs, and user tracking
#33Any 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.
> Poettering came up with a scheme that alleviated most of the problems that were identified. He proposed that a "countme" flag simply be added to a single mirror-list query each week. The sum of all such queries over a week's time should provide an accurate estimate of the number of Fedora systems. That way, UUIDs need not be stored, which removes much of the concern—data that is not stored cannot be misused.
Re: Fedora, UUIDs, and user tracking
#34I'm not sure what they want to count. It definitely isn't users, as they ignore multiple users per system. It seems to be something like "currently active and online machines". But then you should not ignore machines that will not be updated. Maybe they mean "machines that follow the weekly update schedule this week"? That seems to be what Poeterring's approach counts.
As far as I know, the desire is to get better numbers on how much the parts of Fedora are being used. There is always more work to do than there are folks to do all of it; having better numbers on how much different bits are being used helps us make better decisions on what to focus on.
Granted, I'm not Matt but I've heard him talk about similar things and have run into the issue myself - "Is anyone even using this? Is it worth putting this level of effort into this particular thing?"
EDIT: Phrasing of the last sentence
Re: Fedora, UUIDs, and user tracking
#35Earlier quoted context omitted.
If you are opposed to tracking, then a company being aboveboard about it doesn't resolve the issue anyway.
You speak of "tracking" as if it's all the same thing. Every sale you make at a store is tracked, and for good reason to both the customer and the store (how else do you allow returns). Every time you visit a doctor, they add the info regarding your visit to a log. That's tracking. Tracking itself is not bad. Tracking individuals and personal information about them while they are trying to remain anonymous or have no…
True, and that's bad of me. I'm speaking in shorthand.
> Every sale you make at a store is tracked
But the store does not track me if I don't use a card. Returns are handled through the receipt that they give me during the transaction. That's a kind of tracking, but tracking the transaction itself, not me.
> Every time you visit a doctor, they add the info regarding your visit to a log. That's tracking. Tracking itself is not bad.
Indeed, and here's where I'll try to introduce the shades of gray I left out. I consent to the doctor tracking me to that extent (but I would object strongly if the doctor started keeping track of my whereabouts or what I was doing). The doctor even gives me a consent form affirming that. If I'm not OK with the tracking, I don't see that doctor. Software is no different in this sense.
I oppose tracking that I don't give affirmative consent for. In the case of Red Hat's purpose, I will not give such consent, as the cost/benefit ratio is not sufficiently weighted to the "benefit" side.
> is just FUD and an indicator or how broken human communication fundamentally is.
It's not FUD, as I'm not claiming that Red Hat is intending to do anything nefarious. And I don't see this as a human communication problem.
Speaking personally, this is a reaction to the trend in software and online to engage in massive amounts of user tracking and data collection, both disclosed and undisclosed, that has resulted in real harm (both intentional and unintentional).
Once bitten, twice shy and all of that. This is a problem that comes from real misbehavior of software companies, not from poor communications.
Re: Fedora, UUIDs, and user tracking
#36Any 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.
Later on in the article they describe a revised solution that doesn't do that: > Poettering came up with a scheme that alleviated most of the problems that were identified. He proposed that a "countme" flag simply be added to a single mirror-list query each week. The sum of all such queries over a week's time should provide an accurate estimate of the number of Fedora systems. That way, UUIDs need not be stored, whic…
Re: Fedora, UUIDs, and user tracking
#37If it's totally anonymous there's nothing stopping someone trolling the statistics.
True but we're already in that boat with the way that we gather statistics from mirror hits. I have a hard time seeing how a method like the one proposed would be any more vulnerable to tampering.
EDIT: spelling
Re: Fedora, UUIDs, and user tracking
#38Just 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)
The same problem arises though as you can't track senders - there's no way of knowing how many reports were produced by a single machine.
Re: Fedora, UUIDs, and user tracking
#39Re: Fedora, UUIDs, and user tracking
#40This post describes a bad way to track users, but the real utility of this post is in the email that describes a way to count Fedora users without tracking them: https://lwn.net/ml/fedora-devel/20190108152239.GA24118@garde...
That actually sounds more reasonable, although it does run tiny risk of being trivial to mess with if a malicious client wanted to skew numbers. But I don't think it's possible to defend against that without being horribly invasive, privacy perspective. I must say, it feels odd to support a Poettering proposal, but this actually does look like a good solution.
Is that not also the case with the UUID solution? Generating the UUIDs in virtual machines, or just replacing the UUIDs in the requests, doesn't seem out of the question