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

181–190 of 352 posts

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

#181

Post by atoav »

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 collect the data locally and only share it after a crash when the user agreed?

Why not add a splash screen on the program start up that informs your user of upcoming plans so they can intervene? Like "Hey we are planning to remove feature X to speed up the program, do you agree?"

And this is because actual usage metrics don't really translate to opinions. I have features in programs that I use maybe once every two years, but then I really need them. Then there are other features I use daily and I really hate them with a passion.

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

#182

Post by ConcernedCoder »

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'…

And I'll play the devil's devil's advocate:

For Support: Follow these steps:

Step 1 - opt-in to telemetry ( diagnostic ) data reporting

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

#183

Post by svachalek »

AlexandrB wrote: post #131
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'…

> For usage data, it allows developers to focus on features that matter and know which ones you can remove. I find tools that don't do this are generally more powerful because they allow for deep expertise and provide a ton of payoff if you put in the effort. E.g: Vim. 80%+ of users probably don't use macros. Hell, I use them <1% of the time. But I'm sure glad they're there when I need them.

20% of users is quite a lot. In most mature applications you can find a lot of painful code twisted around requirements for 0.1% of the users or less.

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

#186

Post by floatingatoll »

jefftk wrote: post #132
floatingatoll wrote: post #98

This seems dead on arrival, because Homebrew (as they reference on-page) by necessity contacts a wide array of remote addresses, giving away the user’s IP repeatedly as part of normal operation. That conflicts with redefining “track” to be different from the original meaning in the DNT header, to now extend to include any remote network connections at all - not just “do not compile a user profile from this network co…

If you look at the PR they sent to Homebrew, they defined it as an alias for their existing flags for turning off analytics. That doesn't look like an overreach to me? https://github.com/Homebrew/brew/pull/6745/commits/f255f63d4...

The overreach is in expanding the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising:

http://paranoia.dubfire.net/2011/01/history-of-do-not-track-...

Expanding that to mean “do not reveal the user’s IP address” is a significant expansion of the original meaning, having little to do with the protection against being individually tracked that the DNT header was designed for.

Asking Homebrew to disable analytics has nothing to do with targeted advertising opt-outs, but supports the ideological goal of the authors in promoting their new idea that revealing the existence of the user is “tracking”. That expansion exceeds the scope of the definition of “tracking” as used to reference targeted advertising and marketing, something that is not applicable to the Homebrew project’s existing flag in any way.

Attempting to promote their beliefs by aliasing those two concepts together - tracking protection against targeted advertising, versus disabling telemetry and auto update - is therefore overreach to me, especially when presented without this context to projects such as Homebrew and others in pull requests, and I think it will ultimately lead to their effort’s failure.

To me, this is all a direct consequence of their attempt to ride the coattails of the failed DNT effort by reusing its key phrase “do not track”. They should have used a different name. In a few seconds, I can think of a pretty great one that still acronyms to DNT, so clearly creativity wasn’t the obstacle here. Instead they chose to anchor to “Do Not Track” and it’s too late now to change that. We’ll see what happens.

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

#187

Post by pyr0hu »

argvargc wrote: post #112
pyr0hu wrote: post #76

Earlier quoted context omitted.

What? You want to single out developers and public shame them? Yeah, that would totally work out. /s

Any shame a person feels for their public contributions is their own.

But please explain how publicly calling out and potentially doxxing developers would help this issue? Do you really want to target single developers and unleash the fury of the HN crown on them?

If we talk about morality and ethics, I think this is worse than implementing tracking, isn't it?

I know you guys wants to change the world and I absolutely agree that there are too many tracking in the world, but FFS, let's just take a step back and think about YOUR actions and their consequences.

Not everyone has the luxury to quit a job if they don't agree with the morality of their work. I know we are talking about OSS, but lot of the developers are living on the donations and sponsorships or even got bought out by larger companies and to keep their jobs, they have to do said implementations.

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

#188

Post by ezconnect »

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…

I think the old crash report screen will be answer to the paranoid crowds now. App crash the stack trace windows appears with the data and a button to click to email the stack trace to the developers. That used to be the norm before privacy data became lucrative business.

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

#189

Post by pyr0hu »

tofuahdude wrote: post #176
sneak wrote: post #64

Earlier quoted context omitted.

Yes, contempt is an accurate assessment. Shipping nonconsensual spyware is unethical, and there are too many devs in our industry who are happy to behave unethically so long as their boss tells them to. Creating more social and reputational consequences for individual worker bees who make such commits on the job is also on my to-do list. Ultimately the opt out vars are token efforts by developers anyway. These projec…

> Creating more social and reputational consequences for individual worker bees who make such commits on the job is also on my to-do list. Wow. This is a terrible approach for a worthy problem. You want to make the options into "lose my livelihood via being fired or lose my livelihood via social and rep consequences"? That is awful.

I'm looking forward when I'll be cancelled because I left the default branch name as master on my public github repos.

No joke, in my mind this "solution" is on the same level as this monstrous cancelculture. You put a tracking in an OSS project that sends 2 anonym ID and maybe an IP address (which is easily spoofable anyway)? Time to cancel your career and your livelihood.

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

#190

Post by cbm-vic-20 »

svachalek wrote: post #183
AlexandrB wrote: post #131

Earlier quoted context omitted.

> For usage data, it allows developers to focus on features that matter and know which ones you can remove. I find tools that don't do this are generally more powerful because they allow for deep expertise and provide a ton of payoff if you put in the effort. E.g: Vim. 80%+ of users probably don't use macros. Hell, I use them <1% of the time. But I'm sure glad they're there when I need them.

20% of users is quite a lot. In most mature applications you can find a lot of painful code twisted around requirements for 0.1% of the users or less.

https://xkcd.com/1172/
Post reply on HN