41–50 of 87 posts
It's a slippery slope, first you want to know how many use your software, then you want to know what features they use, then you want to know other apps installed, then you want to know what web sites they visit and what they search for, and so forth.
Earlier 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…
JohnFen already said most of what I'd say about these examples, but I want to add one big thing:
The tracking the medical world does is controlled by law. Laws people take very, very seriously. It therefore can't be mixed with other data through being resold or in any other fashion to help form a more accurate picture of me.
That data re-use is part of why I want strong norms against data collection.
This 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...
> This_is_a_first_install
request the first time, then
> get_updates
in future, an so I'm glad to see the proposed solution is something vaguely similar.
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.
Or switch to a less commercialized distribution.
Ironically Fedora is "free" but it's only if you think the info they collect is worthless.
In short:
Add a new "countme" variable. This variable will: - Start as a "true" value, - Reset to a "false" value the first time the client successfully makes a request to Fedora mirror servers, and - Be reset to a "true" value after seven days.
This way, rather than filtering by unique IP addresses, we can count only the "true" requests, so we count each machine once — but no more than once.
This 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...
My first thought when I saw they just wanted to do counting was could you not doing something like send a > This_is_a_first_install request the first time, then > get_updates in future, an so I'm glad to see the proposed solution is something vaguely similar.
Options for "true" values
Rather than a simple boolean, we'd like the "countme" variable to act as an increment-counter. That is, it would be "1" the first week, "2" the second week, "3" the third week, and so on. This will let us sort out short-lived test or CI infrastructure machines and get a better picture of how systems are used over time, without tracking individual systems. Optionally, we could have a cap on the maximum value to mitigate risk of uniqueness for systems which have been running for a very long time (it may be that there are only a few systems running for exactly 327 weeks, for example). As the supported lifetime of a Fedora release is about 30 months, a logical cutoff would be around 60 weeks — the counter could go from "59" to "old".
>unique user ID (UUID) for each installed system that would be sent with DNF mirror-list requests. It explicitly calls out privacy concerns: "We don't want to track; just count." If Fedora server is compromised they can serve different packages to different users.
However, the packages need to be signed by Fedora for the package manager to accept them, so this has been considered a pretty weak excuse for an "attack" for a while now. "Getting access to code-signing keys allows you to attack the people consuming signed binaries"—wow, you don't say!
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…
And your need to run an OS on your computer is your problem, not theirs. What do you do if everyone on the sell side of the market uses telemetry? Just stop using computers?
It's a slippery slope, first you want to know how many use your software, then you want to know what features they use, then you want to know other apps installed, then you want to know what web sites they visit and what they search for, and so forth.
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…
I would think if it rotated on the first of each month, that would probably be sufficient... then you could get your counts for any given month (excluding first/last day) assuming most system check every week or two at least, and it would be pretty consistent.
If you have some number of users leaving, but a similar number incoming, then it would look like you have a consistent usage. Losing the info about lost users means you don't improve in retention.