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

171–180 of 352 posts

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

#171

Post by arsome »

shikoba wrote: post #146
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'…

> know which ones you can remove I know the answer to that question. None. Never remove a feature.

Yeah, I understand this becomes necessary to minimize maintenance effort on rarely used features,but it feels like even more often it's used to turn useful applications into barren wastelands. Firefox, perhaps the best example, is a fraction of what it used to be.

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

#173

Post by crazygringo »

KingMachiavelli wrote: post #161

People say that crash reports & telemetry are useful for developers. But I imagine that they also create a lot of work for developers they would not otherwise have. If a user cannot be bothered to open a ticket themselves or at least opt-in to telemetry to demonstrate the issue, then is it really an issue that developer's should fix? If a app crashes in the woods and no one bother's to report it then is it a bug? (Jo…

A lot of bugs are hard to reproduce, occur only on certain OS's, etc.

In these cases, filing a ticket is often pretty useless. What's needed are widespread stats to determine severity, frequency, correlations, etc.

In fact, I'd say the Venn diagram of bugs that can be meaningfully reported in a ticket, versus those best detected through crash reports, is pretty small. So you need both.

Why do you think developers shouldn't fix crashes? Shouldn't developers themselves decide what they want to fix?

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

#174

Post by yosito »

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

If we held tech companies to the same standards we hold for interpersonal relationships, most tech companies would be in prison.

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

#175

Post by X6S1x6Okd1st »

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…

It totally depends on your personal views on what victory or defeat would mean in this space.

Not everyone shares your views

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

#176

Post by tofuahdude »

sneak wrote: post #64
enumjorge wrote: post #62

Earlier quoted context omitted.

Can’t say I’m surprised that putting one day’s of work into getting the industry to adopt a proposed standard you came up with yourself didn’t really work out. Based on your other comments you also seem to have some level of contempt for some of the projects that you were trying to influence. Those probably didn’t help your cause.

Yes, contempt is an accurate assessment. Shipping nonconsensual spyware is unethical, and there are too many devs in our industry who are happy to behave unethically so long as their boss tells them to. Creating more social and reputational consequences for individual worker bees who make such commits on the job is also on my to-do list. Ultimately the opt out vars are token efforts by developers anyway. These projec…

> Creating more social and reputational consequences for individual worker bees who make such commits on the job is also on my to-do list.

Wow. This is a terrible approach for a worthy problem. You want to make the options into "lose my livelihood via being fired or lose my livelihood via social and rep consequences"? That is awful.

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

#177

Post by jeofken »

WhyNotHugo wrote: post #154
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'…

Sure, and I can spy on girls I like just so I can learn how to offer them a better experience when they meet me. Having good intents does not justify skipping consent. The “opt-out” mentality is a very slippery slope, since you’re already stating that consent does not need to be explicit (hint: it’s not consent if not given explicitly AND freely).

The similie fails since software tracking in programs you run are agreed to by you when you accepted the license agreement.

Yet another reason to prefer free as in freedom software, which can be forked.

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

#178

Post by BiteCode_dev »

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

One should not simplify the work of a group people at the price of the entire community.

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

#179

Post by jcynix »

catwell wrote: post #166
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'…

(disclaimer: IANAL) You have basically just given a justification that crash reporting can be conducted based on legitimate interest instead of consent, and as such does not require opt-in. Many people mistakenly believe consent is the only possible justification for data processing under GDPR, whereas there are actually 6 possibilities, and you can ask a lawyer which one can apply for a given data processing flow. N…

Not everyone is using a flatrate and thus both crash reporting and telemetry might cost the sender some money (or calculate against their hugh speed quota). Some people seem to expect that data transfers are always free ...

That's one reason (besides privacy) why I have Netguard running as a firewall on our Android phones and set to block traffic by default for each app, unless the app's creator convincingly explains why their app should be allowed to access the net.

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

#180

Post by 015a »

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 don't believe its unreasonable for it to be opt-out. Building software is very hard, and even something as inane as "automatically report crashes to the developers so we can fix them quicker" or "tell us how many users are on each version so we can estimate the blast radius of some backward-incompatible change" would be categorized as tracking.

Here's the problem: people are idiots. You can manage or visit any Github issues page for a major project for ten minutes and recognize that even our industry is not immune from this. People also, overwhelmingly, use the defaults. When presented with the option to turn on tracking, most people won't, despite the fact that for most developers, its a legitimate good which benefits the user over the long-term.

You can say "well, if people want to be idiots, that's their right". Idiocy never remains in isolation. If they refuse to update the app, then update Windows and it stops working, Users don't throw their hands up and say "oh well that's my bad". They don't complain to Microsoft. They complain to AppDevs. That becomes a ticket, which is written far-too-often from the perspective of anger and hate. Its triaged by, usually, overworked volunteers.

Telemetry is not all bad. There is no "ensuring defeat" right from the start, as if its some war. Most developers just want to deliver a working project; telemetry enables that. Giving users the ability to opt-out, maybe even fine-grained control over what kinds of telemetry is sent, is fantastic.

Post reply on HN