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

51–60 of 352 posts

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

#51

Post by ricardobeat »

ccsalvesen wrote: post #4

This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.

Why would a user ever opt-in to something that has zero immediate benefit? And for authors, that would be the same as permanently disabling tracking, nobody would adopt it. It’s the worst possible scenario.

What we should work towards is privacy-conscious tracking, used sparingly only for monitoring critical pieces of the software and not all user actions. Flag/reject software that violates this. Then there is no need to opt-out for privacy concerns.

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

#52

Post by hnlmorg »

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.

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

#53

Post by rob_c »

Controversially id like them to collate what is being tracked and by who on the cmdline, a bit of naming and shaming (if warranted) might go a long way to making the need for this mute.

Having used crash analytics to fix a production tool in the wild I would say _all_ tracking is not bad. But projects really need to be a little more up front about it.

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

#54

Post by jonnycomputer »

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…

Then don't install software by bad actors. /s

Seriously, your concern is true for any software you run. You install software--say AWS CLI--on trust. But maybe it also installs a non-CLI keylogger, right? You'd have to do some serious investigation to know.

The point, I think, is to have a standard to make it easier on the user to select the option across multiple applications.

It should, imo, be opt in instead of opt-out (defaults to DO_NOT_TRACK=1).

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

#55

Post by CJefferson »

This seems poorly specified to me.

For example, it claims one of the banned things is 'automatic update phone-home'. However, for brew they are only trying to disable analyitics, brew will still "phone home checking for updates", and there is no way to disable that (at present).

Personally, I'd want to see something more fine-grained. Personally I want automatic updates (at least notifications that one is available), I can't imagine using a package manager that didn't provide that.

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

#56

Post by Y-bar »

enumjorge wrote: post #18
bouke wrote: post #5

Earlier quoted context omitted.

Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?

GDPR specifies what are valid reasons for collecting data, but as far as I know it does not require opt-in.

GDPR requires explicit opt-in for each type of data collection/processing which is not essential for the execution of the service: https://gdpr.eu/recital-32-conditions-for-consent/

> Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. [...]

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

#57

Post by sneak »

alpaca128 wrote: post #50
sneak wrote: post #27

Earlier quoted context omitted.

Chicken and egg problem, naturally. I'd love it to gain more traction. It was an idea and I thought it would be better an idea and a website than just an idea. It was strange to see it get labeled as a marketing attempt during my attempts to gain some traction, considering I'm not selling a damn thing. I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches we…

> It's a doomed concept. Indeed, because it assumes developers who are doing opt-out tracking will respect this voluntarily. I disagree with the poster above about Debian adopting this. They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo; in distros that already keep non-free software out of the standard repository this wouldn't be that much of a leap. This see…

> They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo

Debian maintainers are amazing and they go one step further: they patch it out when they distribute it. They also patch out old version time bombs and all manner of other phone-home.

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

#58

Post by jonnycomputer »

orra wrote: post #44
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)

That's a good idea; it doesn't require buy in from the tool developers.

But buy in is worth it. Consider the related issue of every damn app not respecting a users home directory and polluting it with every file. But that's a problem the XDG Base Directory Specification was designed to solve. And things are better now, though you often have to explicitly set the XDG variables to get some applications to respect the standard. But just having a standard pulls people and organizations in to follow it.

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

#59

Post by sdflhasjd »

tomtomtom777 wrote: post #34

It's a good idea but it seems to me the name will hurt adoption. Phoning home with telemetry data does not by definition imply tracking. Yet a project implementing DO_NOT_TRACK is essentially saying that without it, it is tracking users. This isn't particularly attractive for a project that already has some OPT_OUT_TELEMETRY option.

I think this is closer to the real reason why so many of the maintainers were so combative about it.

Too many of the reasons given by project maintainers seemed like irrelevant, roundabout ways of just saying "No, I don't like it"

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

#60

Post by jonnycomputer »

vortico wrote: post #37

I doubt this will catch on. What's the incentive for the software companies to add it? I like the `source do-not-track.sh` idea better which defines a bunch of `WHATEVER_NO_TRACK := 1` variables. It could even modify config files for software that doesn't use environment variables. Or even better yet, just use a /etc/hosts file or a custom firewall.

What is the incentive for adopting the XDG Base Directory Specification?
Post reply on HN