Console Do Not Track – Proposal for a standard environment variable • Hacker News Board

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

#91

Post by xpressvideoz » Tue, Jul 06, 2021, 12:50 PM UTC

ricardobeat wrote: post #51

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 nee…

Because I want the apps I use daily to improve? Of course I recognize I'm in the minority.

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

#92

Post by beaconstudios » Tue, Jul 06, 2021, 12:52 PM UTC

account42 wrote: post #90

542458 wrote: post #83

Earlier quoted context omitted.

Because massive chunks of the population will never turn it on not due to ideological commitment, but simply due to no knowledge that it exists. Furthermore, if we define “tracking” as broadly as “any crash reports and any checking for updates” that effectively means these features will not work, and the open-source maintainers will have a much harder time tracking down bugs and encouraging people to update to less b…

You are not entitled to crash reports - that applies to open source developers just as to anyone else. If you wan't crash reports, have some kind of wizard or command to submit them and point to that when a crash happens, but you must always gather informed consent before submitting that data.

I like how games typically handle this; if the application crashes a dialog appears asking if you want to send a crash report, and often tells you what's included in said report.

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

#93

Post by TeMPOraL » Tue, Jul 06, 2021, 12:52 PM UTC

baliex wrote: post #86

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 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 opt-out is just making telemetry more established as a standard practice, making it harder to argue that it should, in fact, be opt-in.

The problems we have with tracking on the web are in big part because it was an established practice before appropriate legislation against it was drafted. In the CLI space, we have an opportunity to nip it in the bud, because it's not - as of yet - standard practice for console tools to silently spy on you.

--

[0] - 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.

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

#94

Post by 542458 » Tue, Jul 06, 2021, 12:52 PM UTC

UncleMeat wrote: post #81

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…

DNT has already failed. It is long gone. A lot of people spent a ton of energy trying to make it work but it isn't going to succeed. Discussion around it now is not productive and should instead be focused on new initiatives. > I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches weren't tested very well. Treasure your flow state when you get it. This isn't…

I think there is useful discussion to be had as to why DNT failed. IMO it’s largely because people approached the problem from a purely tech-oriented standpoint and ignored any differing ideologies and incentives at play. An allegory to this project could be drawn.

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

#95

Post by yoz-y » Tue, Jul 06, 2021, 12:55 PM UTC

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't collect any data in my app, but it also means that I fear removing any features that are slowing me down, because I have no idea about how people use it.

As for why sometimes this would be better as opt-out, well, on iOS crash reports are opt-in, and only about 20-30% of users have them enabled. That is fine for huge programs or ones with little surface.

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

#96

Post by megous » Tue, Jul 06, 2021, 12:55 PM UTC

chinathrow wrote: post #48

Tracking should be opt-in, not opt-out. Period.

Restrictive firewall (or unsharing to an empty network namespace) helps with non-malicious apps - no network access except for apps that may need it.

Anyway, tracking on Linux by normal userspace apps is just creepy. There's just too much access if you run these kinds of apps under your main user or let alone root, unlike browser based tracking that happens inside a limited sandbox.

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

#97

Post by elliekelly » Tue, Jul 06, 2021, 12:56 PM UTC

542458 wrote: post #83

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…

Because massive chunks of the population will never turn it on not due to ideological commitment, but simply due to no knowledge that it exists. Furthermore, if we define “tracking” as broadly as “any crash reports and any checking for updates” that effectively means these features will not work, and the open-source maintainers will have a much harder time tracking down bugs and encouraging people to update to less b…

> but simply due to no knowledge that it exists.

If it’s so important to the project the devs can ask users, educate them, and receive informed consent. There are plenty of ways a dev can force a user’s attention for a few minutes to hear their “pitch” and if the users still don’t want to opt in after hearing the reasons perhaps the reasons aren’t nearly as compelling as the devs believe them to be.

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

#98

Post by floatingatoll » Tue, Jul 06, 2021, 12:58 PM UTC

This seems dead on arrival, because Homebrew (as they reference on-page) by necessity contacts a wide array of remote addresses, giving away the user’s IP repeatedly as part of normal operation. That conflicts with redefining “track” to be different from the original meaning in the DNT header, to now extend to include any remote network connections at all - not just “do not compile a user profile from this network connection” but instead “do not divulge the existence of a user”.

If this had restrained itself to the definition of tracking used by the original failed DNT effort, I might think very highly of it, but attempting to shoehorn the more stringent “offline by default” viewpoint into the framing stolen from DNT makes this proposal unlikely to be widely adopted.

It’s really unfortunate that this good technical idea was combined with that overreach, as once the idea is rejected by others for going too far, any similar idea will likely be rejected without consideration. Oh well.

Tangentially, do all the adblock extension users realize that their IP address is constantly divulged by all the rules updates their extensions are running in the background? This proposal would, if fully implemented through the entire software stack, result in browsers launched on the user’s machine refusing to allow any background network connections, which would break all ad blockers as they depend critically on that behavior. I’m not convinced that users prioritize “don’t divulge my IP address” over “block ads”, which seems to be a conceptual nail in the coffin of overreach here.

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

#99

Post by account42 » Tue, Jul 06, 2021, 1:06 PM UTC

yunohn wrote: post #89

dralley wrote: post #72

Earlier quoted context omitted.

> They also patch out old version time bombs As an open source software developer, I do have some sympathy for the upstream devs here, and some frustration with distro maintainer policies. I'm not interested in getting a bunch of bug reports for issues that were fixed 4 years ago, or introduced because Debian maintainers "patched out" something they shouldn't have.

Exactly. Distro maintainers do not face the same issues that the upstream software developers do. Maintainers only make their job harder.

> Maintainers only make their job harder.

That's unnecessarily harsh. Distro maintainer's primary responsibility is making the Distro as a whole work together and sometimes that means choices that are not optimal for individual programs/libraries on their own. But packaging itself does already reduce the burden on upstream a lot by preempting any build-related support requests from users as well as many compatibility-related ones.

Sometimes upstreams interest is also not aligned with the user's interest (e.g. the topic of this thread) and there the distro will tend to choose the user's interests - that's a good thing.

As for time bombs specifically, those don't make much sense when the software is installed via a repository that has an update mechanism. Not wanting bug reports for old versions is no excuse for planned obsolence.

If you think a distro is increasing your support burden it is quite acceptable to tell users from that distro to use the distro's bug tracker.

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

#100

Post by arp242 » Tue, Jul 06, 2021, 1:09 PM UTC

dpcx wrote: post #88

renewiltord wrote: post #61

Earlier quoted context omitted.

Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.

Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?

The maintainer just stated it without further explanation. Searching for "HOMEBREW_NO_ANALYTICS" does reveal some other references[1], and it seems that there are some other places where this may need to be added such as "Library/Homebrew/env_config.rb", but I don't know anything about homebrew.

I do think it's very much a minimal-effort PR. It's hardly a PR at all: at the very least the tests and documentation should have been updated, and actually writing out some more rationale would help as well. I certainly wouldn't send a PR like this, at least not without the text "this is a proposal, and if accepted I will update the tests and documentation as well".

[1]: https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYT...