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

121–130 of 352 posts

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

#121

Post by seemslegit »

easterncalculus wrote: post #115
sneak wrote: post #29

Earlier quoted context omitted.

That is another website on my to-do list: one that names and shames spyware developers who create these commits. Git blame writ large.

Negative punishment will not work for this, you would be going after the symptom instead of the problem. Don't make it harder for people that write these changes, make it harder for people to force others to. There will always be another developer, and there's no guarantee you'll know their identities. If you're looking to bring attention and make a statement at the potential expense of others that's one thing, but p…

Practically speaking, that's the only approach that can.

Although it's often hard to tell, most software developers aspire to being treated like professionals rather than specialized serfs, and part of being a professional is accepting responsibility for your work.

Of course it doesn't preclude holding their employers responsible as well.

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

#122

Post by TeMPOraL »

nxpnsv wrote: post #118
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…

OPT-IN is so much better for users. But if analytics is helpful, then probably opt in means you get no data, unless you keep bugging people asking people to opt in - which would be horrible too

> But if analytics is helpful, (...) [opt-in telemetry] would be horrible too

I don't question that analytics can be helpful. I do question the degree to which it is, relative to other methods of gaining the same insights (such as better QA, user panels, surveying people, etc.).

I also don't think it would be horrible too. Inconvenient, yes. But horrible? People used to ship working software before opt-out analytics became a thing.

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

#123

Post by TeMPOraL »

BurningFrog wrote: post #117
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…

> Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. This approach leads to fewer vendors.

How? And even if, would that be a bad thing?

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

#124

Post by zerkten »

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 wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR violation.

How would GDPR help with anonymous data? Say you have a CLI that sends back the frequency of usage for all top level commands daily. If the user doesn't log into the tool, or that information isn't sent then the developer would have IP address. If they discard that, how would it land under the remit of GDPR?

I'm curious because I think it's easy for small developers to try and jump on this bandwagon. The big companies will all have vetted their telemetry strategy with their legal teams and have compliance reviews in place, as well as people who will handle cleanup from data spills. Bob is less likely to have this for his popular CLI tool.

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

#126

Post by TeMPOraL »

amelius wrote: post #120
TeMPOraL wrote: post #107

Earlier quoted context omitted.

> Most people will shoot support e-mails at you which are more or less "app crashes". (...) If you collect crash reports, you have probably already fixed the problem. Fair enough. Still, there are two separate steps here: collecting crash reports and sending them. What if the app asked if it can send the report, letting you optionally review it? Many programs today do that, I think it's an effective compromise. Addit…

Or how about compensating the user when their software crashes? It's not such a strange thing given that they paid for the software. And if sending a crash report means receiving money, then more users will send them.

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 vendor would have to treat users with respect - which is pretty much anathema to the industry these days.

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

#127

Post by imiric »

WesolyKubeczek wrote: post #116

First, this is backwards. As many have pointed out, any and all telemetry should be opt-in, not opt-out, so the variable should be named YES_PLEASE_TRACK_THE_LIVING_SHIT_OUT_OF_ME, and if and only if is it equal to 1, should the data be collected. But what irks me more is this measly list of unsolicited PRs. Going over a list of projects where you are a nobody and inject yourself with your "improvements" there, with…

The thing is opt-in telemetry doesn't work. Few people will actively choose to enable it, even if they read the documentation and are aware of it.

I think we should distinguish benign uses of telemetry from tracking that collects invasive details about the environment the app is running in.

A popular CLI open source project I use has telemetry enabled by default. The authors are upfront about the data it collects and reference the source code for everyone to verify it. It collects generic things like the app version, operating system, CPU architecture, and a couple more datapoints about the app usage. The IP isn't logged, but is of course known at the time of submission.

This data is not sold or used for any nefarious purpose, but mostly to track which app versions and which features are most commonly used so that development efforts can be better planned. And there is of course a CLI flag and environment variable to disable it.

I'm perfectly fine with this level of telemetry, as long as the authors are open about what data is collected and how it's used. Making the app switch to opt-in would probably eliminate most submissions and would make it impossible to know how the app is used in the wild.

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

#128

Post by colejohnson66 »

TeMPOraL wrote: post #126
amelius wrote: post #120

Earlier quoted context omitted.

Or how about compensating the user when their software crashes? It's not such a strange thing given that they paid for the software. And if sending a crash report means receiving money, then more users will send them.

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.

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

#129

Post by ztcfegzgf »

all the pull-requests mentioned on that webpage are from 2019 and 2020 and all were rejected (well, technically the last one is still open, with a comment pointing to an another place where it was rejected). the "get involved" link points to a page that does not exist.

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

#130

Post by TeMPOraL »

zerkten wrote: post #124
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 wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR violation. How would GDPR help with anonymous data? Say you have a CLI that sends back the frequency of usage for all top level commands daily. If the user doesn't log into the tool, or that information isn't sent then the developer would have IP address. If they discard that, how would it land under the rem…

> Say you have a CLI that sends back the frequency of usage for all top level commands daily. If the user doesn't log into the tool, or that information isn't sent then the developer would have IP address. If they discard that, how would it land under the remit of GDPR?

I think it wouldn't, given proper handling of the IP address.

Where I'd expect your Bob to land in trouble is in mishandling crash reporting, in particular wrt. logging. It's very common for log files to accidentally acquire passwords or PII, or potentially other secrets protected by different laws. To be safe here, you'd have to ensure no user-provided data, or data derived from user input, ever enters the log files - which may include things like IP addresses and hostnames, names of files stored on the machine, etc.

Post reply on HN