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

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

#141

Post by BowBun » Tue, Jul 06, 2021, 2:07 PM UTC

Agreed with many other posters here - the execution was messy and definitely lacked the calm and collected attitude I'm used to seeing when looking at new standards being discussed.

I was also unimpressed with the tone of the issues/PRs opened. As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. I definitely don't want to encourage ignoring issues and letting people get away with things, but in this context a change in attitude would have brought much more success IMO

Also I found it really weird that this has just bubbled up to the front page when the original PRs for this project were opened in 2019[1]. Why is this popping back up now?

[1] https://github.com/gatsbyjs/gatsby/pull/19528

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

#142

Post by GekkePrutser » Tue, Jul 06, 2021, 2:09 PM UTC

BurningFrog wrote: post #117

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…

> Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. This approach leads to fewer vendors.

Not if users get something in return. Like with the windows insider program. Opt in to get betas and provide automated feedback. If MS turned off telemetry for regular users they'd be doing a great job.

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

#143

Post by jeroenhd » Tue, Jul 06, 2021, 2:11 PM UTC

genezeta wrote: post #104

beaconstudios wrote: post #92

Earlier quoted context omitted.

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.

Many Windows applications used to do that. Just search for "crash report dialog" images and you'll find many of them. Firefox does it too. And it keeps a log of past crashes on about:crashes where you can decide which ones to submit.

Many versions of Android do the same (although the details may differ, that's the beauty and the curse of open source). After crashing a (on some devices, only after a few times), you get a popup that says something like " appears to stop unexpectedly, would you like to report this to the developer?"

If you click on the details button, you can see almost everything outside of pure hexdumps of RAM.

There's no need for automatic sample submission if you respect your users' privacy.

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

#144

Post by rkeene2 » Tue, Jul 06, 2021, 2:12 PM UTC

I've attempted to convince maintainers in the past to not do user-hostile things [0]. They seem to think they are entitled to a record of how I use their software on my own systems.

It's not clear to me why they would think this, but I think it is because you always get this if you offer software as a service and many people have been involved in working on these projects, despite the vast majority of software not being offered this way (indeed, 96% of IT is on-premises spend [1]). I think the people who have worked on these projects have carried this attitude of usage information is their information over to other domains, without realizing that they are different domains.

[0] https://github.com/matthewmueller/joy/issues/79 [1] https://siliconangle.com/2020/11/30/exclusive-aws-chief-andy...

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

#145

Post by [deleted] » Tue, Jul 06, 2021, 2:13 PM UTC

imiric wrote: post #127

WesolyKubeczek wrote: post #116

First, this is backwards. As many have pointed out, any and all telemetry should be opt-in, not opt-out, so the variable should be named YES_PLEASE_TRACK_THE_LIVING_SHIT_OUT_OF_ME, and if and only if is it equal to 1, should the data be collected. But what irks me more is this measly list of unsolicited PRs. Going over a list of projects where you are a nobody and inject yourself with your "improvements" there, with…

The thing is opt-in telemetry doesn't work. Few people will actively choose to enable it, even if they read the documentation and are aware of it. I think we should distinguish benign uses of telemetry from tracking that collects invasive details about the environment the app is running in. A popular CLI open source project I use has telemetry enabled by default. The authors are upfront about the data it collects and…

[deleted]

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

#146

Post by shikoba » Tue, Jul 06, 2021, 2:14 PM UTC

yoz-y wrote: post #95

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

> know which ones you can remove

I know the answer to that question. None. Never remove a feature.

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

#147

Post by smcameron » Tue, Jul 06, 2021, 2:15 PM UTC

On linux you can use network namespaces to deprive the program of access to the network (shouldn't be necessary, but this is the world we live in.)

    $ sudo ip netns add jail # create a new net namespace with no access
    $ sudo ip netns exec jail /bin/bash # launch a root shell in the new namespace
    # su - your-normal-username # become non-root
    $ ping google.com # see if network is accessible?
    ping: unknown host google.com
    $ ifconfig -a
    lo        Link encap:Local Loopback  
              LOOPBACK  MTU:65536  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1 
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

    $ audacity & # See if you can track me without a network audacity...
    [1] 4284
    $ _

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

#148

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

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.

> Phoning home with telemetry data does not by definition imply tracking.

As far as the user can know for sure, it does.

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

#149

Post by tfigment » Tue, Jul 06, 2021, 2:22 PM UTC

GekkePrutser wrote: post #140

yoz-y wrote: post #95

Earlier quoted context omitted.

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

If that were the case, why do Microsoft apps still crash so frequently

My experience is third party products/add-ins (specifically McAfee Enterprise Suite) cause most of the crashes I have with Office products. Most OS blue scrrens are non-microsoft hardware drivers.

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

#150

Post by jeroenhd » Tue, Jul 06, 2021, 2:27 PM UTC

trackerme wrote: post #87

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.

"Do not track" is a sensible default. Data sharing should always be opt-in, it's just good manners.

It's the disrespect of tracking agencies and web developers that killed the concept.