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

231–240 of 352 posts

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

#231

Post by justshowpost »

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.

Sorry, but if devs are requiring THAT tight connection with end users to MAINTAIN software, they are probably should stop and leave. Its impossible to figure out a new feature from the such reactive approach, and they would have to resort to more traditional way to interact with end users. Thus... making coverage analysis a totally redundant thing.

Tighter user connection is suitable for enterprise software, not for general deployment.

And why so much worries about removing working(!) features?

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

#232

Post by closeparen »

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.

The anti-tracking point in the era of Do-Not-Track was “building advertising profiles that follow people around the web is evil.” Software telemetry is neither a personal profile, nor for advertising, nor correlated across more than one surface. As such I think it’s a little bit of a stretch to put this in the same bucket as 3rd party JS adtech crap.

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

#233

Post by kazinator »

tjoff wrote: post #160
PragmaticPulp wrote: post #157

Earlier quoted context omitted.

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.

Analogy time: in the early days of the Internet, any IP address could send an e-mail by directly connecting to the mail change host listed for the domain of the To: address via SMTP. This was a good, nice thing.

Bad agents, spammers, ruined that. The trust is gone, and wow it's a terrible idea to accept SMTP connections from any random IP addresses.

Legitimate senders have to "opt in" to the SMTP sending system by getting a static IP of good repute, or else using a forwarding host which has those attributes.

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

#234

Post by zomglings »

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…

The problem is a simple one. Most telemetry tools (Mixpanel, Sentry, etc.) don't give the developers who are adding them into their products the ability to quickly add respectful consent flows.

This really needs to be a feature of the telemetry tools in the first place. Because, ultimately, most telemetry is being implemented by startup engineers who are burning the midnight oil to complete the telemetry JIRA ticket before going back to the long list of other stuff they have to implement.

I have experienced this from all three sides - as a software engineer implementing telemetry, as a product manager consuming telemetry, and now as a founder who is building a tool to collect telemetry in the most respectful manner possible.

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

#235

Post by ramtatatam »

I'm probably amateur but until today I did not know `aws cli` sends telemetry data... It's probably one of those "terms and conditions" that are way too long to read them, so I'm only half pissed because I did not read it.

Indeed, sending such data should be opt-in, NOT opt-out

From today on I will ensure each and every CLI I use plays fair game.

But actually what did I expect, since for Firefox telemetry data is on by default :/

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

#236

Post by ryandrake »

WhyNotHugo wrote: post #152

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

Silicon Valley software developers have a huge problem understanding consent. Look at most dialogs presented for things that companies want you to do:

Do you want to enable Feature X?

1. Yes

2. Ask me again later.

Somehow, "no" is just not in their vocabulary. Imagine if "Silicon Valley" was a guy asking a woman on a date, and the only options he understood were "yes" AND "ask again later".

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

#237

Post by rb12345 »

trackerme wrote: post #87

DO_NOT_TRACK is forever tainted by it's initial Microsoft introduction and the massive opposition of the tech community at the time to this idea. Apache webserver to this day strips the DNT header in it's default config. Accepting DNT would imply that the tech community was wrong on this one, and that will never happen. So it's dead without a name change.

No, the real reason is because it's trying to use an optional technical flag to enforce a social/political policy, and as such was doomed to failure from the start. If I recall correctly, the "tech community" was largely in favour of DNT, and anti-advertising in any case. The advertising industry, however, was not, so why bother implementing something that goes against their own interests?

The only workable solution to that problem in practice is legal/political: legislation and sufficient regulatory abilities to effect compliance (i.e. GDPR/PECR and the like). In the end, the US stuck with permit-all-by-default and largely don't care, the EU/UK went deny-tracking-by-default with penalties to back it up.

The reality is that this proposal will fail for much the same reasons: either you have an opt-in mindset from personal beliefs or legal requirements, in which case the global off-switch is worthless to you; or you're pro-tracking, in which case the incentives are to ignore the switch. Or you're Debian etc. and you remove the tracking code outright...

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

#238

Post by kazinator »

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…

If the variable is widely implemented, then that provides the nice, single point of control that the users need.

In the FOSS world, we typically have distros between the applications and the users. If the applications honor the variable, then that's all the control that is required. A distro can implement an opt-in model by defining the variable with a value of 1 in the base system, so that it's present right from boot.

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

#240

Post by BurningFrog »

TeMPOraL wrote: post #123
BurningFrog wrote: post #117

Earlier quoted context omitted.

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

Telemetry data is valuable. Vendors will get less of it, and so there will be less value in being a vendor.

Not sure why this is not obvious?

> would that be a bad thing?

Not saying it would be.

Post reply on HN