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

111–120 of 352 posts

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

#111

Post by wizzwizz4 »

soraminazuki wrote: post #105
noname120 wrote: post #15

Earlier quoted context omitted.

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

From the link: > I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others. It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.

To be fair, Debian has popularity-contest. (You have to install the package manually – or via a prompt in the installer; if you don't, you don't even have the tracking code on your system.)

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

#112

Post by argvargc »

pyr0hu wrote: post #76
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…

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.

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

#114

Post by hnlmorg »

theden wrote: post #74
hnlmorg wrote: post #52

Earlier quoted context omitted.

I don't see why both solutions can't co-exist. If DO_NOT_TRACK suppresses the honest software (of which should be the majority you have installed anyway) then you have fewer applications left to manage manually / less network noise to identify and black. Saying an imperfect solution is worthless is a little like throwing the baby out with the bath water.

I seriously doubt marketing and advertising departments will care about standards, if they would even notice. The industry can't even manage with web standards, imagine trying to get scummy tracking companies to comply. IMO it's not even an imperfect solution. I'd say performative, and past DNT efforts have failed, so why are trying this again? Maybe a tool that lets one easily report software for GDPR violations? Th…

> I seriously doubt marketing and advertising departments will care about standards, if they would even notice.

The _vast_ majority of applications this relates to are not going to have marketing and advertising departments. They're unlikely to have more than a handful of maintainers. Most are likely just someone's side project.

> The industry can't even manage with web standards, imagine trying to get scummy tracking companies to comply.

We're not talking about a new standard that's even remotely in the same league as web standards in terms of complexity and nor are we talking about getting every scummy company to comply. A lot of command line applications already have an opt out so all this is proposing is making that opt out option the same.

This isn't any different to other common environmental variables like http_proxy -- not every application supports it but enough does that it is still useful.

> IMO it's not even an imperfect solution. I'd say performative, and past DNT efforts have failed, so why are trying this again?

As of yet, no effort has been made with regards to DNT in this field. You're conflating running untrusted web applications, with running trusted (and often open source) applications locally on the command line. They're two very different fields and as said already DNT options already exist for the latter but with every application having their own preferred variable name. All this proposal is seeking to do is standardise that name.

> Maybe a tool that lets one easily report software for GDPR violations? That would have more teeth.

To reiterate my original comment: the existence of one doesn't prevent the existence of the other. Why pick when we can have both?

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

#115

Post by easterncalculus »

sneak wrote: post #29
seemslegit wrote: post #26

This is a losing proposition that will only lend credence to the inherently violent opt-out approach to data collection. Instead how about a do-not-hire-or-collaborate-with registry of the individual contributors participating in projects that employ those tactics and see how they like trying to opt out of it.

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 practically speaking this approach can't work.

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

#116

Post by WesolyKubeczek »

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 implication that if you don't accept the PR, you're somehow an enemy, is far from being a good way to advertise your cause. I remember Alex Gaynor spamming a lot of projects with PRs to amend the documentation to use gender-neutral language, and I remember Coralina Ehmke carpet-bombing projects into accepting codes of conduct. No matter how noble your ideas are, mass-harassing people into accepting them is a major dick move.

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

#117

Post by BurningFrog »

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.

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

#118

Post by nxpnsv »

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

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

#119

Post by amelius »

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.

Or users getting paid for their data.

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

#120

Post by amelius »

TeMPOraL wrote: post #107
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'…

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

Post reply on HN