Lots of people in the Free Software community think that programs should exist only to help the user, and should just do exactly what the user tells them to do and nothing else. I am one of those people. Showing ads, making network requests that aren't necessary to carry out the expected functionality, etc. all fall under violations of that principle. Some violations are worse than others, but I treat them the same way.
It's on the developers of the software to make these settings granular and off-by-default. If I want to help a developer, I'll go out of my way to do it and flip one of those switches if that's what it takes.
Personally, I don't think this goes far enough; I think programs should require explicit consent simply to connect to the network, and most should request permission to connect only to certain domains. But that's just me ;).
>it's on the developers of the software to make these settings granular and off-by-default.
why? privacy advocates in these discusssions always jump to this position and assume everybody is going to agree just because they've invoked the magic p-word. telemetry is useful, and most people don't really care enough to change the defaults one way or the other.
assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?
> assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?
No, I can't. I think that ethical principles like respect for users' privacy are more important than collecting data to fix bugs/features. Shareholders may disagree, of course; this is where developer agency and collective bargaining can come in, but that's a longer discussion.
> telemetry is useful, and most people don't really care enough to change the defaults one way or the other.
This sentence is correct, but it isn't enough to justify making telemetry opt-out. I don't think this is a situation where the apathy of the majority can overrule the rights of the minority:
- People can't always choose to use or avoid software; they have schools, employers, an inability to make informed consent, etc. that can prevent them from using your software with consent to its terms.
- Privacy is often a need, not a want. People--including their future selves--are often at-risk, and need software to respect their vulnerability by default (as auditing all transmitted data for all software is beyond unrealistic).
- A person should not have to justify having privacy. Others should have to justify taking it. That's how rights like privacy work; privacy is something we have by default until it is infringed upon.
- Rights like privacy, speech, and information access without censorship (from books to newspapers to the Internet) aren't driven by will of the majority. They're driven by the fact that preserving them for the minority is necessary.
Users have lots of things that would be useful to developers, but that doesn't mean developers are entitled to them.
I'm just going to point out that you accused privacy advocates of magical assertions, then did the same thing :)
(there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product)
* Figuring out which features are not being used, and being able to change things according. This also covers UI decisions - Oh. We added this new toolbar. Is anyone actually using it?
* Prioritizing localizations of a particular country / language.
* An actual positive feedback loop for products that don't generate revenue. Most open source project maintainers just receive bug reports, feature requests, and sometimes hate mail. Telemetry information which roughly shows that even though there are some people complaining loudly about the software, there are 50k other users happily using it, is very very motivating.
* Crash reporting / exceptions monitoring - Bugs are inevitable, and this gives so so much information. In my experience, very few users actually report bugs. Many might even just rate your app badly, and then ignore any attempts at following up. Especially cause they have deleted the app.
> there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product
There are two problems with this view.
The first is that it's generally user-hostile. If you're meaning your software to be useful to users, then you need to see what your users' needs are, and how they're actually using your software - not how you think they should be. There are people who design pieces of software that are meant to be opinionated, beautiful gems that are not meant to be used by others (which includes software that pays lip-service to users but is so user-hostile that it's effectively not for them anyway) - and telemetry, crash reports, auto-updates, and more generally a feedback loop from user to developer are not for them.
The second is that it requires a lot of discipline. Look at how user-hostile most applications (both open-source and proprietary) are anyway - do you really think that their developers are going to have the discipline to carefully engineer a good user experience? As an idealist, I wish that they did, but as a realist, I know that in most cases that will never happen, and so telemetry and crash reports (crashing is part of a bad user experience) will get you a slightly better piece of software than nothing at all.
The problem with telemetry is it doesn't tell you what users' need are. It tells you what they do with their software. Not why. Not how they feel about it. Not what they wish it would do.
Thoughtful and rigorous design includes user research and testing.
In my experience it takes more discipline to use telemetry responsibly. I've seen equivalent data used to justify removing 1 feature and making another more prominent. It seems to go hand in hand with UI churn. And it seems to lead to dismissing user feedback.
Crash reports and event streams are different. But there's no reason not to ask consent anyway.
as a developer, i find crash reports helpful when troubleshooting issues, and use device metrics like screen size to determine where to focus limited developer efforts. telemetry is useful because i use it. that's not a magical assertion.
It's not even about privacy, it's the basic ethical principle that you should ask for consent before doing something to me. It is a command line tool that I run on my machine, why should it be allowed to what I didn't ask it to in the first place?
Developers might think telemetry a good thing - then decent ones would care to convince the user that it's a good thing too. Some users will agree, some will not, but asking is just a basic act of respect and decency.
Right, but they specifically listed "automatic update phone-home" as something to be supressed too. As well as some other things that aren't ads; the proposal is about "telemetry" not just ads.
And the proponent of the standard got in an argument with homebrew about supporting the env variable. (Although not necessarily for suppressing automatic updates? Which might be a violation of the standard, to suggest you support it, but only support it incompletely?)
Perhaps the proposed standard needs some more consultation and fine-tuning (as is common with standards for a reason) before trying to strong-arm projects into adopting it.
The person you replied to didn't say that. And updating a package manager manually works fine. I consider forced updates and tracking different problems though.
The OP says that. That is the proposal in the OP that I thought we were discussing here, is why I was discussing it. The proposal in the OP for `DO_NOT_TRACK` does consider them part of the same problem all to be controlled by a `DO_NOT_TRACK` setting.
It may be that both you and I think that's not a great idea, or at least needs more fine-tuning as a proposed standard.
> This is a proposal for a single, standard environment variable that plainly and unambiguously expresses LACK OF CONSENT by a user of that software to any of the following:
> ad tracking
> usage reporting, anonymous or not
> automatic update phone-home
> crash reporting
> non-essential-to-functionality requests of any kind to the creator of the software or other tracking services
I thought we were discussing the comment you quoted and replied to. It has a different but similar suggestion. And Homebrew automatic updates aren't needed anyway.
I don't think fine tuning would help. People who think they're entitled to collect user data without consent don't want to make it easy to opt out.
You literally just said you considered them very different problems? But now you say you think they should both be handled per the OP with a single flag, and you're opposed to both of them on the same grounds -- doesn't sound like you do consider them very different problems?
This seems like one of those internet debates where what we're talking about keeps changing in pursuit of "winning" rather than enlightening.
It's on the developers of the software to make these settings granular and off-by-default. If I want to help a developer, I'll go out of my way to do it and flip one of those switches if that's what it takes.
Personally, I don't think this goes far enough; I think programs should require explicit consent simply to connect to the network, and most should request permission to connect only to certain domains. But that's just me ;).