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

241–250 of 352 posts

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

#241

Post by maddyboo »

holtalanm wrote: post #172

my question here is: are we really concerned about console tools overreaching their telemetry? personally, I am not. I would love to know why others think this is some kind of huge issue, without a bunch of 'what-if' scenarios.

I am. The terminal is one of the few places I am not being tracked. It’s also a portal into my most private data and activity, so if there’s one place I don’t want to be tracked, it’s here.

I do not long for a future where the terminal ecosystem resembles the state of the greater internet with regards to privacy and tracking. We’ve collectively watched it happen to almost every other segment of technology in the past 20-odd years, so it’s not far fetched to believe it could happen here as well.

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

#242

Post by unfletch »

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)

I had the same thought, and pulled this together this morning: http://github.com/rfletcher/cli-privacy

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

#243

Post by kazinator »

> respect the following environment variable

This is under-specified without giving a definition of environment variable. For the purpose of this choice, "environment variable" should have the broadest possible interpretation, referring to any relevant space that supports named configuration parameters:

- UNIX or Windows environment variable

- U-Boot or other boot loader variable.

- Kernel parameter: e.g.

    ... root=/dev/sdb1 DO_NOT_TRACK=1 ...
- URL parameter:

    https://domain.example/foo/bar&param=24&DO_NOT_TRACK=1&...
Basically any configuration variable that is relevant in the specific context. Lower-level system software which executes before there are environment variables should not be off the hook.

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

#244

Post by jrochkind1 »

finnthehuman wrote: post #103
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'…

>I'll play the devil's advocate. Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

> Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

Well, not exactly. The original comment was that "surveillance data" is useful to the user and their installation. For instance in getting better response to your error report. Or, I'd say, in keeping your software patched and up to date (check for updates is included in the OP as suppressed by 'do not track', since it necessarily reveals IP address).

Even if none of these things that make it useful to the actual users were in effect... surveillance would still be happening because it lets the vendor monetize the users data.

Useful to whom and for what seems relevant, instead of just aggregating it all as "sure, it's useful in some way to someone or it wouldn't happen."

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

#245

Post by latexr »

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…

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

Clicking on your HN profile, I see “I am available for hire”. It was clear to me that’s what the maintainers were referring to: you marketing yourself, which you’d have been able to do with greater effectiveness as the originator of a feature adopted by popular open-source projects (had it worked).

Note I’m not claiming that’s what you did, I’m explaining what you found strange.

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

#246

Post by lojack »

PragmaticPulp wrote: post #157
finnthehuman wrote: post #103

Earlier quoted context omitted.

>I'll play the devil's advocate. Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

Calling it surveillance is misleading in most cases. The most recent crash reporting system I worked with was little more than a stack trace without any user data recorded at all. Not even IP addresses of the report. We didn’t care who was crashing and we didn’t collect any PII at all. It was a simple report about where in our code the crash occurred. It was very useful for fixing bugs. No surveillance or PII involve…

Does removing PII preclude data from being surveillance?

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

#247

Post by johannes1234321 »

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

> and know which ones you can remove.

No, you can't remove it. Even though I'm using it rarely it's existence might be the reason for me to use the tool at all, so that when I need it the feature is available.

This came about with audacity. There I have my set of standard filters I run all the time, even though they don't bring much benefit, they are there and nice. They will be on top of a usage statistics. Then there are filters I need for a special effect or to repair something really broken. Those I use ahrdly, but when, they make the difference.

Or when talking command line: `ls` without options I use a lot (Well actually a lie, i have some alias in my shell rc), sometimes I use `-a` or `-l`. This doesn't mean that maintainers should remove `-i` since once per year or so I need it to compare inodes with log entries or something and then it's important that flag exists.

You need qualified information about what features are important. Not unqualified statistics.

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

#248

Post by renewiltord »

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

Actually, this is why I want telemetry to be opt-in. I have a consistent policy of providing telemetry and I want the software to be biased to my needs. I want them to conclude that some feature used only by some privacy-conscious user is unused and should be axed because I want the software to be hyper-tailored to me.

I want the software to be streamlined, have no features except what I'll use, and for the community to be specifically people like me. I want other people to not use the software and use up dev bandwidth.

And I love it when telemetry biases the stats towards me. That way all devs will eventually be making software for people just like me.

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

#249

Post by sneak »

formerly_proven wrote: post #208
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…

From the Netlify PR: > 1. User runs a cli command with —telemetry-disable flag > 2. CLI sees the flag, and sends one telemetry request to note that it was disabled Wow. The first thing the "Hey, please don't send telemetry" flag does is send telemetry .

VSCode (and maybe Atom?) also send a telemetry event along the lines of USER_HAS_DISABLED_TELEMETRY.

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

#250

Post by jrochkind1 »

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…

> making network requests that aren't necessary to carry out the expected functionality

I think regularly updating the package formulae for homebrew is actually necessary to carry out the functionality most users expect from homebrew.

Post reply on HN