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

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

#291

Post by TeMPOraL » Tue, Jul 06, 2021, 6:37 PM UTC

zomglings wrote: post #234

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…

The problem is a simple one. Most telemetry tools (Mixpanel, Sentry, etc.) don't give the developers who are adding them into their products the ability to quickly add respectful consent flows. This really needs to be a feature of the telemetry tools in the first place. Because, ultimately, most telemetry is being implemented by startup engineers who are burning the midnight oil to complete the telemetry JIRA ticket…

> now as a founder who is building a tool to collect telemetry in the most respectful manner possible.

Thank you for taking being respectful to users seriously.

I'd be very interested in learning how your consent flows look, and what other aspects of your product are driven by the goal to "collect telemetry in the most respectful manner possible". I couldn't see much on it on the landing page, so if you have a moment, could you provide additional information, either here or in private?

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

#292

Post by Seirdy » Tue, Jul 06, 2021, 6:42 PM UTC

notatoad wrote: post #212

Seirdy wrote: post #200

Earlier quoted context omitted.

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…

>it's on the developers of the software to make these settings granular and off-by-default. why? privacy advocates in these discusssions always jump to this position and assume everybody is going to agree just because they've invoked the magic p-word. telemetry is useful, and most people don't really care enough to change the defaults one way or the other. assuming that "because privacy" is not an argument that will…

> assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?

No, I can't. I think that ethical principles like respect for users' privacy are more important than collecting data to fix bugs/features. Shareholders may disagree, of course; this is where developer agency and collective bargaining can come in, but that's a longer discussion.

> telemetry is useful, and most people don't really care enough to change the defaults one way or the other.

This sentence is correct, but it isn't enough to justify making telemetry opt-out. I don't think this is a situation where the apathy of the majority can overrule the rights of the minority:

- People can't always choose to use or avoid software; they have schools, employers, an inability to make informed consent, etc. that can prevent them from using your software with consent to its terms.

- Privacy is often a need, not a want. People--including their future selves--are often at-risk, and need software to respect their vulnerability by default (as auditing all transmitted data for all software is beyond unrealistic).

- A person should not have to justify having privacy. Others should have to justify taking it. That's how rights like privacy work; privacy is something we have by default until it is infringed upon.

- Rights like privacy, speech, and information access without censorship (from books to newspapers to the Internet) aren't driven by will of the majority. They're driven by the fact that preserving them for the minority is necessary.

Users have lots of things that would be useful to developers, but that doesn't mean developers are entitled to them.

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

#293

Post by jefftk » Tue, Jul 06, 2021, 6:42 PM UTC

floatingatoll wrote: post #186

jefftk wrote: post #132

Earlier quoted context omitted.

If you look at the PR they sent to Homebrew, they defined it as an alias for their existing flags for turning off analytics. That doesn't look like an overreach to me? https://github.com/Homebrew/brew/pull/6745/commits/f255f63d4...

The overreach is in expanding the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising: http://paranoia.dubfire.net/2011/01/history-of-do-not-track-... Expanding that to mean “do not reveal the user’s IP address” is a significant expansion of the original meaning, having little to do with the protection against being individually tracked that the DNT header was d…

> the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising

It was a lot more amorphous than that. Some of the people behind DNT did have that particular meaning in mind, but others had different sets of things they wanted to prevent. There was enough disagreement on this point that they didn't manage to get consensus on anything more than "this specification does not define requirements on what a recipient needs to do to comply with a user's expressed tracking preference" -- https://www.w3.org/TR/tracking-dnt/

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

#294

Post by TeMPOraL » Tue, Jul 06, 2021, 6:45 PM UTC

kazinator wrote: post #238

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…

If the variable is widely implemented, then that provides the nice, single point of control that the users need. In the FOSS world, we typically have distros between the applications and the users. If the applications honor the variable, then that's all the control that is required. A distro can implement an opt-in model by defining the variable with a value of 1 in the base system, so that it's present right from bo…

It's not a big enough of a change for people to actually choose Linux distributions over it - those who know about the variable will set it themselves, those who don't will be stuck with a bad default.

My issue isn't with the point of control - it's with the default. Telemetry of all kinds should be opt-in. People shouldn't have to worry that they're constantly being watched. They shouldn't have to hope that every single telemetry stream is operated by competent and careful software engineers, guided by honest and law-abiding managers. You know how this industry works; it's a rare case where a data collection scheme doesn't overreach, accidentally ingest too much, leak data, or turn malicious and pass it to bad actors.

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

#295

Post by holtalanm » Tue, Jul 06, 2021, 6:46 PM UTC

maddyboo wrote: post #241

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…

are there documented cases of these cli tools abusing their telemetry? are they entirely used to pinpoint performance issues and bugs within the tools that implement this telemetry tracking?

if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.

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

#296

Post by holtalanm » Tue, Jul 06, 2021, 6:47 PM UTC

traverseda wrote: post #290

holtalanm wrote: post #168

Earlier quoted context omitted.

I liked the Gatsby comment/suggestion a lot better: a tool for automatically setting the do-not-track env flags for all different dev tools.

Because what I really want is a ton of different random bullshit enviroment variables next time I go to debug something :/

well, good luck getting buy-in from the cli tool devs, then? the other option requires absolutely zero buy-in from homebrew, gatsby, dotnet, or any other cli.

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

#297

Post by floatingatoll » Tue, Jul 06, 2021, 6:50 PM UTC

jefftk wrote: post #293

floatingatoll wrote: post #186

Earlier quoted context omitted.

The overreach is in expanding the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising: http://paranoia.dubfire.net/2011/01/history-of-do-not-track-... Expanding that to mean “do not reveal the user’s IP address” is a significant expansion of the original meaning, having little to do with the protection against being individually tracked that the DNT header was d…

> the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising It was a lot more amorphous than that. Some of the people behind DNT did have that particular meaning in mind, but others had different sets of things they wanted to prevent. There was enough disagreement on this point that they didn't manage to get consensus on anything more than "this specification does…

That seems like particularly poor quicksand to build a new "do not track" effort upon, yes; adding yet another interpretation worsens things and ties this new effort to a failed effort's legacy.

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

#298

Post by hyldmo » Tue, Jul 06, 2021, 6:54 PM UTC

TeMPOraL wrote: post #285

vinkelhake wrote: post #273

Earlier quoted context omitted.

Ah, so the question of whether to remove feature A or feature B is solved by simply not removing either. That's brilliant! I get that this might not be a popular sentiment, but resources are finite. If we have a situation where we can't maintain both features, which one do we focus on? Usage metrics can absolutely be beneficial there.

I don't think it's usually a problem of "remove either A or B", it's usually "should we remove A or invest work in making it compatible with changes ahead?". I see how usage telemetry can be useful in deciding whether or not it's worth it to keep supporting a feature, but I offer two counterbalancing points: 1. What people may be worried about - what I myself am worried about - is the methodology creep; it's too easy…

I'm a hundred percent certain that 1 is what Spotify does. It seems every release they remove or hide features that I use occasionally (e.g. clicking on the currently playing album picture to reveal the active playlist). It's extremely frustrating that since power users now are in a minority they are completely ignored. At the first release like this they basically said "This new version has a lot less features, but you can vote on which ones we will add back!". They added none of the ones that got votes, and eventually removed the feature voting system altogether.

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

#299

Post by david_allison » Tue, Jul 06, 2021, 6:54 PM UTC

throwaways885 wrote: post #283

ryandrake wrote: post #228

Earlier quoted context omitted.

Excellent point. As a user, here are my requirements if you want me to opt into your data collection scheme: 1. All exfiltration of data must be under my direct control, each time it happens. You can collect all the data you want in the background, but any time it is transmitted to the company, I must give consent and issue a command to do it (or click a button). 2. All data that is exfiltrated must be described in d…

I'm fairly sure Android crash reporting is all manually done, and even zips it up for you to inspect. But some of these are impossible, e.g. how do you localize a stack trace?

If you install an app via Google Play, crash reporting & some telemetry are silent and enabled by default. This is in addition to any crash reporting built into the app.

https://support.google.com/accounts/answer/6078260

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

#300

Post by zomglings » Tue, Jul 06, 2021, 6:56 PM UTC

TeMPOraL wrote: post #291

zomglings wrote: post #234

Earlier quoted context omitted.

The problem is a simple one. Most telemetry tools (Mixpanel, Sentry, etc.) don't give the developers who are adding them into their products the ability to quickly add respectful consent flows. This really needs to be a feature of the telemetry tools in the first place. Because, ultimately, most telemetry is being implemented by startup engineers who are burning the midnight oil to complete the telemetry JIRA ticket…

> now as a founder who is building a tool to collect telemetry in the most respectful manner possible. Thank you for taking being respectful to users seriously. I'd be very interested in learning how your consent flows look, and what other aspects of your product are driven by the goal to "collect telemetry in the most respectful manner possible". I couldn't see much on it on the landing page, so if you have a moment…

Happy to show you some code.

You cannot set up Bugout telemetry in your codebase without first defining your consent flow.

We have a library of consent mechanisms that you can chain together like lego blocks to build these flows. For example, our Python consent library is here: https://github.com/bugout-dev/humbug/blob/main/python/humbug...

Consent is calculated at the time that each reports are sent back. This means that your users can grant and revoke their consent on a per-report basis, which is the only respectful way to do things.

We are also building programs which will deidentify reports on the client side, before any data is even sent back to our servers. This work is still in the early stages, but here's v0.0.1 of the Python stack trace deidentifier: https://www.kaggle.com/simiotic/python-tracebacks-redactor/e...

Besides Python, we also support Javascript, Go, and we added Java support last week.

I would really love to hear any feedback you have.