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

211–220 of 352 posts

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

#211

Post by TeMPOraL »

cbm-vic-20 wrote: post #191
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

How can users be incentivized to opt-in, particularly with a free-to-use application? I can see a case for ad-supported software, a developer could reduce or eliminate ads for that user in exchange for telemetry data...

Ask nicely. After all, you want them to do you a favor.

If you're less into respect and more into manipulation, offer them a meaningless trinket. A sticker on the app's home screen saying "I helped", or something.

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

#212

Post by notatoad »

Seirdy wrote: post #200
fouric wrote: post #163

I do not support this idea. The differences between the things they all group together under one umbrella is wild - ads, usage reporting, automatic updates, and crash reporting are all very different things and it's actively harmful to control all of them with a single switch. At the very least, there should be two different switches - "ads" and "everything else". If you don't want telemetry or crash reporting, that'…

Lots of people in the Free Software community think that programs should exist only to help the user, and should just do exactly what the user tells them to do and nothing else. I am one of those people. Showing ads, making network requests that aren't necessary to carry out the expected functionality, etc. all fall under violations of that principle. Some violations are worse than others, but I treat them the same w…

>it's on the developers of the software to make these settings granular and off-by-default.

why? privacy advocates in these discusssions always jump to this position and assume everybody is going to agree just because they've invoked the magic p-word. telemetry is useful, and most people don't really care enough to change the defaults one way or the other.

assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?

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

#213

Post by Nextgrid »

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.

Until you realize that most telemetry infrastructure is provided by ad companies (Google Analytics for example).

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

#214

Post by an_opabinia »

wongarsu wrote: post #16

"PRs and Status" is a very optimistic headline for a list of rejected pull requests. I like the idea, but the execution leaves a lot to be desired. I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. It's essentially a single person setting up a website, then submitting a bunch of untested pull requests to a bunch of projects. I imagine this would work much better if a…

> I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume.

It's one Homebrew dev.

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

#216

Post by cmsj »

argvargc wrote: post #108
wongarsu wrote: post #16

"PRs and Status" is a very optimistic headline for a list of rejected pull requests. I like the idea, but the execution leaves a lot to be desired. I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. It's essentially a single person setting up a website, then submitting a bunch of untested pull requests to a bunch of projects. I imagine this would work much better if a…

> I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. I can't. That suggestion seems the product of desperate reach for an ad hominem attack. There are clear, plausible and obvious reasons for the projects existence that require no seeking of hidden motive to understand or explain. I'd agree OS-level integration for this stuff would be better, supposing OS manufacturer…

Homebrew devs are small in number and high in stress. They tend to be very protective of their time and sanity.

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

#217

Post by [deleted] »

cmsj wrote: post #216
argvargc wrote: post #108

Earlier quoted context omitted.

> I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. I can't. That suggestion seems the product of desperate reach for an ad hominem attack. There are clear, plausible and obvious reasons for the projects existence that require no seeking of hidden motive to understand or explain. I'd agree OS-level integration for this stuff would be better, supposing OS manufacturer…

Homebrew devs are small in number and high in stress. They tend to be very protective of their time and sanity.

[deleted]

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

#218

Post by KMnO4 »

hnlmorg wrote: post #52
theden wrote: post #32

Bad-actors would ignore it wholesale anyway, so this at best gives one a false sense of privacy. It would probably be better _not_ to have it, since people won't be misguided into thinking they're not being tracked. An actual effective approach to privacy is to use a firewall to block all unwanted connections (allowlist only), and a DNS sinkhole like pi-hole. IMO we should get more on the more aggressive side when it…

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.

> If DO_NOT_TRACK suppresses the honest software

Ahh, my big issue is that I don’t mind tracking in genuinely honest software. Want to know how many people are still running your app on 32-bit machines and that’s it? Be my guest!

It does seem like DO_NOT_TRACK isn’t supporting honest software, though. I can’t enable it for Audacity and disable it for Homebrew, for example.

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

#219

Post by sss111 »

sneak wrote: post #43
forty wrote: post #41

The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)

Belt and suspenders: https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/ro...

thanks for making this!

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

#220

Post by jnky »

TeMPOraL wrote: post #93
baliex wrote: post #86

Earlier quoted context omitted.

I agree wholeheartedly with the idea that it should be opt-in but both approaches are equally unenforceable. The inverse of what's suggested in the article would be: export DO_TRACK=0 Project owners that want to track you simply won't take any notice of these flags anyway.

I agree. The approach I'd like to see is, standardizing on some kind of DO_TRACK for convenience [0], and then doubling down on legal enforcement of opt-in telemetry. Project owners should be incentivized to seek consent, by threat of legal action from data protection authorities - and then, standardizing on some sort of DO_TRACK flag would be a no-brainer for them. As it is, letting the industry standardize on a DNT…

> And while we're at it, standardizing on a browser-provided consent UI, instead of each site providing its own, with its own dark patterns. It's the same idea.

We've already been there and it was basically shelved because users were indifferent and companies wanted the data regardless.

https://en.wikipedia.org/wiki/P3P

Post reply on HN