Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Console Do Not Track – Proposal for a standard environment variable

consoledonottrack.com

Post reply on HN
Print view View original

151–160 of 352 posts

Re: Console Do Not Track – Proposal for a standard environment variable

#151

Post by rlpb »

dralley wrote: post #72
sneak wrote: post #57

Earlier quoted context omitted.

> They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo Debian maintainers are amazing and they go one step further: they patch it out when they distribute it. They also patch out old version time bombs and all manner of other phone-home.

> They also patch out old version time bombs As an open source software developer, I do have some sympathy for the upstream devs here, and some frustration with distro maintainer policies. I'm not interested in getting a bunch of bug reports for issues that were fixed 4 years ago, or introduced because Debian maintainers "patched out" something they shouldn't have.

As a Debian Developer, I don't share your view. Debian users want a unified release cadence. That's why they're using Debian. For example, they specifically don't want random packages to update, changing behaviour, because upstream bundled feature changes with bugfixes.

I understand that upstreams might get frustrated that their bugfixes haven't made it to stable distribution releases, but it's important to understand that expecting otherwise (except with manual, per-fix intervention) is generally against the principle of having a stable distribution release in the first place, and exactly why users are choosing to use stable distribution releases.

> Debian maintainers "patched out" something they shouldn't have

Debian sets its own policy about what is and isn't acceptable, in order to give users consistent behaviour across all packages. Again: Debian users want this consistency; users who don't want this use other distributions (like Arch for example, which aims for the opposite). An example is this topic: Debian maintainers generally patch out telemetry-by-default.

> I'm not interested in getting a bunch of bug reports for issues that were fixed 4 years ago, or introduced because Debian maintainers "patched out" something they shouldn't have.

I agree with this part. Distribution users should be reporting bugs to their distribution bug trackers in the first instance, and only sending reports upstream in cases that the bugs are confirmed to be relevant to upstream.

Re: Console Do Not Track – Proposal for a standard environment variable

#152

Post by WhyNotHugo »

You know what else expresses lack of consent?

Lack of consent.

It’s very sad how this “you consent unless otherwise stated” ideology keep growing and growing.

“We’re not spying on you, it’s just that you never expressed not wanting to be spied upon”.

Here’s a very educational video on how giving consent works: https://youtu.be/oQbei5JGiT8

Re: Console Do Not Track – Proposal for a standard environment variable

#153

Post by barbazoo »

I'm not sure "do not track" would even be the right terminology here. We want to prevent apps from calling home or calling some telemetry or error reporting endpoint, sure. But is that "tracking" in the same sense as we're being tracked from website to website? I'm not aware of any malicious use of that data yet so we might not want to throw them in the same group as google and other advertisers and user data aggregators.

How about "enable telemetry" to also make it opt in rather than opt out?

Re: Console Do Not Track – Proposal for a standard environment variable

#154

Post by WhyNotHugo »

yoz-y wrote: post #95
TeMPOraL wrote: post #66

Sure. But I have a question: why ? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR viola…

I'll play the devil's advocate. Most people will shoot support e-mails at you which are more or less "app crashes". If you have not already encountered the problem you have to walk them through tedious debugging process. If you collect crash reports, you have probably already fixed the problem. For usage data, it allows developers to focus on features that matter and know which ones you can remove. For example I don'…

Sure, and I can spy on girls I like just so I can learn how to offer them a better experience when they meet me.

Having good intents does not justify skipping consent. The “opt-out” mentality is a very slippery slope, since you’re already stating that consent does not need to be explicit (hint: it’s not consent if not given explicitly AND freely).

Re: Console Do Not Track – Proposal for a standard environment variable

#155

Post by marcosdumay »

beaconstudios wrote: post #92
account42 wrote: post #90

Earlier quoted context omitted.

You are not entitled to crash reports - that applies to open source developers just as to anyone else. If you wan't crash reports, have some kind of wizard or command to submit them and point to that when a crash happens, but you must always gather informed consent before submitting that data.

I like how games typically handle this; if the application crashes a dialog appears asking if you want to send a crash report, and often tells you what's included in said report.

On a more CLI oriented design, take a look at Debian's report-bug program. It's completely transparent, and still gathers enough information that most times a one-line description of the bug is enough for anybody to understand everything that happened on your system.

Re: Console Do Not Track – Proposal for a standard environment variable

#156

Post by fauigerzigerk »

yoz-y wrote: post #95
TeMPOraL wrote: post #66

Sure. But I have a question: why ? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR viola…

I'll play the devil's advocate. Most people will shoot support e-mails at you which are more or less "app crashes". If you have not already encountered the problem you have to walk them through tedious debugging process. If you collect crash reports, you have probably already fixed the problem. For usage data, it allows developers to focus on features that matter and know which ones you can remove. For example I don'…

Why not do local logging by default (opt-out), and ask users to upload their logs if and when they want you to diagnose some problem?

Re: Console Do Not Track – Proposal for a standard environment variable

#157

Post by PragmaticPulp »

finnthehuman wrote: post #103
yoz-y wrote: post #95

Earlier quoted context omitted.

I'll play the devil's advocate. Most people will shoot support e-mails at you which are more or less "app crashes". If you have not already encountered the problem you have to walk them through tedious debugging process. If you collect crash reports, you have probably already fixed the problem. For usage data, it allows developers to focus on features that matter and know which ones you can remove. For example I don'…

>I'll play the devil's advocate. Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

Calling it surveillance is misleading in most cases.

The most recent crash reporting system I worked with was little more than a stack trace without any user data recorded at all. Not even IP addresses of the report.

We didn’t care who was crashing and we didn’t collect any PII at all. It was a simple report about where in our code the crash occurred.

It was very useful for fixing bugs. No surveillance or PII involved.

Re: Console Do Not Track – Proposal for a standard environment variable

#158

Post by cestith »

This is a great idea, but I want it to go one step further. Some projects I do want to send some telemetry. It would help if there was a standard way to name environment variables or config entries across projects so I can predict what I need to change for each one without digging through docs. Perhaps a per-account dotfile that lists projects with 0, 1, or 2 depending on no data, limited subset / anonymous only data, or full data.

Re: Console Do Not Track – Proposal for a standard environment variable

#159

Post by nkingsy »

Surveil everything. Homogenize culture.

Individuality is a myth. If we want to survive on this planet we need to be ground down into uniformity.

Global governance is a pipe dream, but cultural smoothing and pervasive surveillance is inevitable.

Look what the alternative has done to us and embrace it.

Re: Console Do Not Track – Proposal for a standard environment variable

#160

Post by tjoff »

PragmaticPulp wrote: post #157
finnthehuman wrote: post #103

Earlier quoted context omitted.

>I'll play the devil's advocate. Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

Calling it surveillance is misleading in most cases. The most recent crash reporting system I worked with was little more than a stack trace without any user data recorded at all. Not even IP addresses of the report. We didn’t care who was crashing and we didn’t collect any PII at all. It was a simple report about where in our code the crash occurred. It was very useful for fixing bugs. No surveillance or PII involve…

If that was the norm then people would opt in. But the trust is gone now, bad actors have ruined it for everyone. And the solution to that is not to enable it by default.
Post reply on HN