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

131–140 of 352 posts

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

#131

Post by AlexandrB »

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

> 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.

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

#132

Post by jefftk »

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...

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

#133

Post by slackfan »

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

Let's not beat around the bush, data costs money. Personal data costs money.

How much are you willing to pay me for my app usage data? Oh, nothing? Well then, buzz off.

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

#134

Post by jordemort »

It’s disappointing, although not entirely surprising, how some projects met this idea with outright hostility. It’s an extremely simple idea. It seems obviously correct to me and I’m not sure what benefit any further effort at discussion or standardization would bring.

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

#135

Post by jefftk »

naikrovek wrote: post #25

I'm sure everyone doing tracking of console programs is just chomping at the bit waiting for the creation of an easy-to-remember way for users to opt out... more useful would be something like this that lets users opt in or out of the various TYPES of tracking that are done. for example, I don't care about application usage telemetry. if you want to know that it's hard for me to remember a particular subcommand and a…

> if you want to show me "we're hiring" horsepoo, well you can go away. opt out. same for "please donate, I'm not rich enough yet" messages.

Neither of those require network requests, so it seems to me that they're a completely different sort of thing than this effort intends to address?

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

#136

Post by TeMPOraL »

colejohnson66 wrote: post #128
TeMPOraL wrote: post #126

Earlier quoted context omitted.

This would be tricky - the nature of software means some people would try to keep crashing their programs on purpose, sending repetitive crash reports, in order to make money. Developers would now have to deal with a flood of spam in their crash reports. I think the only way crash reporting can work, outside of support contracts, is as a favor by the user to the vendor. But, to maximize the amount of such favors, the…

Valid concern, but bug bounties are a thing; It’s up to the developer to decide if the bug is worthy of a payout. Maybe make it so that if it crashes, and they provide a useful log (or steps), then you pay out.

From what I know, bug bounties already have a spam problem. I definitely saw some devs in my circles complaining about people repeatedly sending garbage submissions in hopes of getting a payout.

What bug bounties also have is a big barrier to entry. You generally need to be at least marginally competent in software development, and do plenty of leg work, to make money with them. Turning regular crash reports into bug bounties removes that barrier, amplifying the spam problem.

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

#137

Post by helsinkiandrew »

From the pull requests submitted so far, I'd say this is dead in the water unless Debian or Redhat or someone with more clout start using it.

https://consoledonottrack.com/#prs-and-status

Perhaps a more pragmatic solution would be a notrack package (probably just a shell script) that could be executed from your .profile and sets the app specific variables?

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

#138

Post by vultour »

noname120 wrote: post #15
cupofjoakim wrote: post #3

I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if other major players adopt it first. Cmon, it's such a minor change. Getting these PR's in means _you are_ a major player (atleast to some) and you might be able to drive change in a positive way. Why not jump on the opportunity?

This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...

The best part of that discussion is how one Homebrew maintainer says "I'd like to see package managers implement this first", and when someone from Arch goes "we don't track at all" the big chief comes in and says "Run your package manager how you want/need and we'll do the same.".

The guy also seems quite rude for someone with "Rude people blocker" in his bio.

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

#139

Post by londons_explore »

Does anyone else here run a commercial service with do-not-track functionality?

I have observed that users who enable do-not-track raise more support tickets and generate substantially less revenue than those who do not.

To the extent that those users are a net negative to my service. Even counting referrals of users who do enable tracking, even with generous assumptions about the metrics I can't see due to lack of data.

My tracking doesn't involve ads - this is pure analytics for reporting dashboards, crash analysis, etc.

Are my findings unusual?

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

#140

Post by GekkePrutser »

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

If that were the case, why do Microsoft apps still crash so frequently
Post reply on HN