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

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

#81

Post by UncleMeat » Tue, Jul 06, 2021, 12:37 PM UTC

sneak wrote: post #27

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…

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 really an excuse. Imagine how somebody on the other side of a broken PR sees this? This 100% reads as "I don't care about your project enough to do the work and instead am doing this solely for my personal satisfaction".

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

#82

Post by beatcracker » Tue, Jul 06, 2021, 12:38 PM UTC

pleone wrote: post #71

Nice try, but kinda difficult to make it works with pr system. What about this https://github.com/beatcracker/toptout ? You can opt-out from just one place.

Author here, feel free to ask me anything.

Btw, currently I have a huge backlog of telemetry to add, so I wouldn't mind some help. If anyone interested, have a look at the GitHub issues in this repo. The repo itself contains all docs and examples to get you started.

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

#83

Post by 542458 » Tue, Jul 06, 2021, 12:40 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…

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 buggy or more secure versions of their software.

Why not simply fork or choose not to install code you don’t like, rather than forcing your beliefs about what does or does not constitute acceptable code on the developers?

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

#84

Post by yunohn » Tue, Jul 06, 2021, 12:41 PM UTC

naikrovek wrote: post #25

I'm sure everyone doing tracking of console programs is just chomping at the bit waiting for the creation of an easy-to-remember way for users to opt out... more useful would be something like this that lets users opt in or out of the various TYPES of tracking that are done. for example, I don't care about application usage telemetry. if you want to know that it's hard for me to remember a particular subcommand and a…

> "please donate, I'm not rich enough yet"

Who do you feel entitled enough to judge someone’s humble request for a donation, despite them developing the free software that you use often enough to be annoyed by it?

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

#85

Post by heurisko » Tue, Jul 06, 2021, 12:42 PM UTC

I think this is an OK idea.

But I think it would have been better to post on mailing lists and contact people to get "buy in" rather than just opening up PRs.

I also find the "respect" wording of the PRs a little presumptuous and probably caused some push-back.

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

#86

Post by baliex » Tue, Jul 06, 2021, 12:43 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 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.

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

#87

Post by trackerme » Tue, Jul 06, 2021, 12:45 PM UTC

DO_NOT_TRACK is forever tainted by it's initial Microsoft introduction and the massive opposition of the tech community at the time to this idea. Apache webserver to this day strips the DNT header in it's default config.

Accepting DNT would imply that the tech community was wrong on this one, and that will never happen.

So it's dead without a name change.

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

#88

Post by dpcx » Tue, Jul 06, 2021, 12:46 PM UTC

renewiltord wrote: post #61

chrisseaton wrote: post #21

Earlier quoted context omitted.

Have you got the time, expertise, and network to maintain Homebrew?

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?

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

#89

Post by yunohn » Tue, Jul 06, 2021, 12:47 PM UTC

dralley wrote: post #72

sneak wrote: post #57

Earlier quoted context omitted.

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

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

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

#90

Post by account42 » Tue, Jul 06, 2021, 12:47 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…

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.