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

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

#281

Post by johannes1234321 » Tue, Jul 06, 2021, 5:51 PM UTC

vinkelhake wrote: post #273

johannes1234321 wrote: post #247

Earlier quoted context omitted.

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

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.

What you need is qualified metrics. Like asking your users what is important.

Also relevant is: Is there a maintenance cost or is that code that rarely needs attention and doesn't compete with important new work.

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

#282

Post by kstrauser » Tue, Jul 06, 2021, 6:00 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…

Yeah, this makes opting out my responsibility. If a company collects the names of all the files in my home directory, it's my fault for not setting some random variable correctly. Oh, and you did remember to also set it in your crontabs, right? If not, oopsie! You're gettin' spied on!

This proposal is terrible and comes at the problem from the exact wrong direction. If someone wants to come up with a "export GO_AHEAD_AND_SPY=yes" envvar that enables telemetry, fine.

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

#283

Post by throwaways885 » Tue, Jul 06, 2021, 6:03 PM UTC

ryandrake wrote: post #228

adkadskhj wrote: post #170

Earlier quoted context omitted.

I think this might be the winning argument. There may not be any meaningful reason for telemetry to outweigh the bad actors and damage they've done. For me, i'd love to enable telemetry for some of my more liked, FOSS apps - but even with those my question immediately arises "What are you sending?". Without someway to monitor, are they sending filenames? Are they sending file contents? How much is it? etcetc To satis…

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?

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

#284

Post by Dayshine » Tue, Jul 06, 2021, 6:05 PM UTC

account42 wrote: post #99

yunohn wrote: post #89

Earlier quoted context omitted.

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…

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

Sadly, this is in itself adding a large support burden.

I think distributions should be doing a much much much better job of informing their users how they should report issues.

tracker.debian.org seems to be almost impossible to find on google for example (If I search i3-wm debian it's not in the first 5 pages!).

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

#285

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

vinkelhake wrote: post #273

johannes1234321 wrote: post #247

Earlier quoted context omitted.

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

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 to end up having telemetry drive feature removal decisions, as in, "monthly report says feature X is used by less than 1% of users, therefore let's schedule its removal for the next sprint". The problem here is, telemetry alone will likely lead you astray. It's useful as a data source, not as the optimization function of product development.

2. If a feature you're worrying about has significant use, you most likely already know it without telemetry - all it takes is following on-line discussions mentioning your product (yes, someone might need to do it full-time). If removing the feature will have major impact on your maintenance budget, and non-telemetry sources don't flag this feature as being actively used, you can just axe it - revenue hit from lost userbase you've missed is unlikely to be big.

From this follows that the telemetry is most useful for deciding the fate of features that aren't used much, and don't cost much to maintain. At which point, I wonder, do you really have such low margins that you can't afford to carry the feature a while longer? I'm strongly biased here, because I'm going only by my personal experience - but I'm yet to see a software company[0] that doesn't have ridiculous amounts of slack. Between the complexity, management mess-ups, piles of technical debt and the nature of knowledge work being high-variance, having a feature slow your current development down by half[1] won't have much long-term impact.

--

The question thus is, are the gains from usage telemetry really worth the risk and potential ethical compromise? Would those gains be significantly lessened, if the telemetry was opt-in, and the company put more work into getting to know the users better? I suspect the answer is, respecting your users this way won't hurt you much, and may even benefit you in the long run.

--

[0] - Other than one outsourcing code farm I briefly worked in (my boss loaned me for a couple weeks to a friend, to help him meet a tight deadline), but these kind of companies don't make product decisions, they just close tickets as fast as possible.

[1] - And hopefully leading some devs notice the need for a refactoring, in order for that feature to not be a prolonged maintenance burden.

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

#286

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

WhyNotHugo wrote: post #152

You know what else expresses lack of consent? Lack of consent. It’s very sad how this “you consent unless otherwise stated” ideology keep growing and growing. “We’re not spying on you, it’s just that you never expressed not wanting to be spied upon”. Here’s a very educational video on how giving consent works: https://youtu.be/oQbei5JGiT8

I did not consent to being talked to by a stranger earlier today. I did not consent to any replies on this comment that might follow. I did not consent to the music from my neighbour this afternoon. I did not consent to being barked at by my other neighbour's dog yesterday. I did not consent to a list of things longer than I care to name.

It's all about expectations: consent for everything is unworkable.

Equating some basic telemetry to rape is idiotic and offensive.

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

#287

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

renewiltord wrote: post #248

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

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…

I know you're sarcastic, but it wouldn't be a bad outcome. Sure, the vendor would have to be particularly dumb in their usage of telemetry[0], but the result would be... software that is useful to you. All the professional features you need would be in there, with none of the glitter.

Of course, I would opt-in too, with the same mindset but different use cases, and the software would provide equally for both of us. Add in a few more people like us, and we'd end up with a quality tool, offering powerful and streamlined workflows. Those who don't like it would start using a competing product, and tailor it towards their needs. Everyone wins.

Reality of course is not that pretty, but at face value, it still beats software optimized to lowest common denominator, serving everyone a little bit, but sucking out the oxygen from the market, preventing powerful functionality from being available anywhere.

--

[0] - It's a mistake that's much easier to make when you're flooded with data from everyone, rather than having a small trickle of data from people who bothered to opt in.

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

#288

Post by tofuahdude » Tue, Jul 06, 2021, 6:20 PM UTC

sneak wrote: post #277

pyr0hu wrote: post #189

Earlier quoted context omitted.

I'm looking forward when I'll be cancelled because I left the default branch name as master on my public github repos. No joke, in my mind this "solution" is on the same level as this monstrous cancelculture. You put a tracking in an OSS project that sends 2 anonym ID and maybe an IP address (which is easily spoofable anyway)? Time to cancel your career and your livelihood.

Historically, there have always nearly always been negative consequences for doing things that infringe the rights of others. If someone else telling the truth about one's actions on their webpage is a threat, perhaps people should be more measured in the actions they undertake. What I'm describing is reporting, not cancellation.

Report the company then, not the "worker bee". You're pursuing evil in your current plan.

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

#289

Post by kstrauser » Tue, Jul 06, 2021, 6:20 PM UTC

aarchi wrote: post #67

sneak wrote: post #33

Earlier quoted context omitted.

The approach I use is Little Snitch. It's how I discovered most of these telemetry misfeatures in the first place.

I’ve tried Little Snitch, but was quickly annoyed at the high interaction required. Maybe I should give it another shot, especially since I use uMatrix on Firefox, which is a similar concept.

It's overwhelming for the first couple of days, as periodic jobs wake up and ask for permission to connect to the Internet. Once you're over that initial hump, it basically disappears until some new app wants to connect to something unexpected.

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

#290

Post by traverseda » Tue, Jul 06, 2021, 6:21 PM UTC

holtalanm wrote: post #168

hnlmorg wrote: post #47

Earlier quoted context omitted.

Sprinkling in the website URI into the source code of the PRs was definitely a bold move. I get the logic behind why it was done but one website does not constitute as a standard. If DO_NOT_TRACK were to be standardised then adding a URI to the published standard would have been more obviously intended as a constructive comment. But when the URI is a hobbyist's personal website, as well intended as it was probably me…

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 :/