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

301–310 of 352 posts

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

#301

Post by renewiltord »

TeMPOraL wrote: post #287
renewiltord wrote: post #248

Earlier quoted context omitted.

Actually, this is why I want telemetry to be opt-in. I have a consistent policy of providing telemetry and I want the software to be biased to my needs. I want them to conclude that some feature used only by some privacy-conscious user is unused and should be axed because I want the software to be hyper-tailored to me. I want the software to be streamlined, have no features except what I'll use, and for the community…

I know you're sarcastic, but it wouldn't be a bad outcome. Sure, the vendor would have to be particularly dumb in their usage of telemetry[0], but the result would be... software that is useful to you. All the professional features you need would be in there, with none of the glitter. Of course, I would opt-in too, with the same mindset but different use cases, and the software would provide equally for both of us. A…

I am actually not being sarcastic. It is a life goal for me to have most policy organized to serve me or people like me (along whatever genetic/social/cultural/economic grouping is most likely to benefit me). i.e. I encourage communities not like me to refuse participation in medical research, forcing participants to be in my ethnic group; I encourage stringent data sharing norms and a culture of fear around what is done with health data in socio-economic and ethnic groups that are not mine; I encourage organizations to have strict opt-in requirements, in general, which I have no problem meeting, so that tools are built to be best used by me and adequate for others.

My dream is that everything is above the adequacy threshold for everyone else so that they don't build their own equivalent tool but that everything is also past my pleasantness threshold. I think the most effective means of doing this is to focus existing products into being past my pleasantness threshold while ignoring others since high switching costs keep most people on the same path they were before, and because things like medical research they don't really get to re-optimize.

I understand that this sounds sarcastic, but it is not.

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

#302

Post by TeMPOraL »

renewiltord wrote: post #301
TeMPOraL wrote: post #287

Earlier quoted context omitted.

I know you're sarcastic, but it wouldn't be a bad outcome. Sure, the vendor would have to be particularly dumb in their usage of telemetry[0], but the result would be... software that is useful to you. All the professional features you need would be in there, with none of the glitter. Of course, I would opt-in too, with the same mindset but different use cases, and the software would provide equally for both of us. A…

I am actually not being sarcastic. It is a life goal for me to have most policy organized to serve me or people like me (along whatever genetic/social/cultural/economic grouping is most likely to benefit me). i.e. I encourage communities not like me to refuse participation in medical research, forcing participants to be in my ethnic group; I encourage stringent data sharing norms and a culture of fear around what is…

Well... then I apologize for assuming. I'm not sure how such philosophy sits with me, I need to think about it more. One thing for sure, what you say makes you the model of an ideal free market participant :).

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

#303

Post by LocalH »

jeofken wrote: post #177
WhyNotHugo wrote: post #154

Earlier quoted context omitted.

Sure, and I can spy on girls I like just so I can learn how to offer them a better experience when they meet me. Having good intents does not justify skipping consent. The “opt-out” mentality is a very slippery slope, since you’re already stating that consent does not need to be explicit (hint: it’s not consent if not given explicitly AND freely).

The similie fails since software tracking in programs you run are agreed to by you when you accepted the license agreement. Yet another reason to prefer free as in freedom software, which can be forked.

I don’t think the simile fails for that reason. “Informed consent” is generally accepted as the standard, and it’s arguable that click-through EULAs are not in any way “informed consent” for the average person.

To bring the original simile full circle, let’s say a person signs a contract with another person, and then that person forces themselves on them. I doubt the presence of a clause in the contract saying “I agree to have sex with X” would absolve them of guilt.

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

#304

Post by 1vuio0pswjnm7 »

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 you want me to test your app(lication), pay me." - so-called "power user"

What many of today's software authors want/expect is free testing.

"To me, this seems to not just be admitting defeat, it's ensuring defeat right from the start."

While I do not use any of the example programs the mentioned, it seems like these environmental variables would be appropriate if the user wants to toggle between tracking and no tracking. However, for users who would never want to enable tracking, "no tracking" should be a compile-time option. It would not suprise me if that is not even possible with these programs. How is the user supposed to verify that "Do Not Track" is being honoured.

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

#305

Post by sneak »

tofuahdude wrote: post #288
sneak wrote: post #277

Earlier quoted context omitted.

Historically, there have always nearly always been negative consequences for doing things that infringe the rights of others. If someone else telling the truth about one's actions on their webpage is a threat, perhaps people should be more measured in the actions they undertake. What I'm describing is reporting, not cancellation.

Report the company then, not the "worker bee". You're pursuing evil in your current plan.

Companies are fictional abstractions and cannot write code.

Humans are the ones responsible for their actions.

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

#306

Post by jefftk »

floatingatoll wrote: post #297
jefftk wrote: post #293

Earlier quoted context omitted.

> the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising It was a lot more amorphous than that. Some of the people behind DNT did have that particular meaning in mind, but others had different sets of things they wanted to prevent. There was enough disagreement on this point that they didn't manage to get consensus on anything more than "this specification does…

That seems like particularly poor quicksand to build a new "do not track" effort upon, yes; adding yet another interpretation worsens things and ties this new effort to a failed effort's legacy.

Not disagreeing!

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

#307

Post by fouric »

sneak wrote: post #268
fouric wrote: post #257

Earlier quoted context omitted.

You want to shame developers for including "usage reporting", "automatic update[s]", and "crash reporting" in their software?

Without obtaining advance consent? Yes, because that would be spyware.

I completely disagree with your definition of spyware. A crash report, absent any PII, is not spyware to me, and does not require my advance consent to be sent.

You're entitled to your own definition, of course, but I hope that for the good of society as a whole, you and people with your tyrannical/authoritarian attitude toward issues that can (usually) be resolved civilly with never hold positions of power.

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

#308

Post by nofunsir »

fomine3 wrote: post #198
tjoff wrote: post #160

Earlier quoted context omitted.

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.

For ad industry, trust is gone now. But for telemetry? I think most people don't much care.

They don’t care because they don’t know.

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

#309

Post by nxpnsv »

TeMPOraL wrote: post #122
nxpnsv wrote: post #118

Earlier quoted context omitted.

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…

What I meant would be horrible experience - CLI apps halting and asking on every execution much like websites do with news letters, cookie banners, or paywalls.

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

#310

Post by indymike »

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…

>Why should we opt out of the telemetry?

Let's imagine the ls command with telemetry. What happens when you make an error like this?

  $ ls all-the-pr0n
  ls: cannot access 'all-the-pr0n': No such file or directory
Um, what did I just tell the ls vendor? Who are they sharing that data with?

> Telemetry should always be opt-in

Opt in needs to be very precise and spell out exactly what is being shipped. For a lot of command line tools, telemetry is going to create more problems than it is worth.

> I wonder how much of existing telemetry already crosses the "informed consent" requirement threshold.

This is the question we all have to wonder about.

Post reply on HN