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

161–170 of 352 posts

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

#161

Post by KingMachiavelli »

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? (Joking partly).

For commercial apps the dynamic is a bit different since customer's can & do expect things to be fixed without any action on their part.

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

#162

Post by FroshKiller »

rob_c wrote: post #53

Controversially id like them to collate what is being tracked and by who on the cmdline, a bit of naming and shaming (if warranted) might go a long way to making the need for this mute. Having used crash analytics to fix a production tool in the wild I would say _all_ tracking is not bad. But projects really need to be a little more up front about it.

No thanks to the command line reporting for me, some scumbag would just turn that itself into another advertising vector.

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

#163

Post by fouric »

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's fine - you may not care about helping the developers of an open-source project improve their software and that's your personal choice. Similarly, you may want to manually install security patches, while I want them to be automatically installed so I have one less thing to worry about.

There may even be some crazy person that wants ads. I don't, but I'm not going to try to take away their freedom to choose them, which is what this proposal would do - an all-or-nothing switch for non-essential network access.

Give me granularity. There's no (user-facing) reason not to.

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

#164

Post by MereInterest »

TeMPOraL wrote: post #93
baliex wrote: post #86

Earlier quoted context omitted.

I agree wholeheartedly with the idea that it should be opt-in but both approaches are equally unenforceable. The inverse of what's suggested in the article would be: export DO_TRACK=0 Project owners that want to track you simply won't take any notice of these flags anyway.

I agree. The approach I'd like to see is, standardizing on some kind of DO_TRACK for convenience [0], and then doubling down on legal enforcement of opt-in telemetry. Project owners should be incentivized to seek consent, by threat of legal action from data protection authorities - and then, standardizing on some sort of DO_TRACK flag would be a no-brainer for them. As it is, letting the industry standardize on a DNT…

> Project owners should be incentivized to seek consent, by threat of legal action from data protection authorities

Definitely agreed, and I'd want to have some form of strict liability for data breaches, based on what kind of information has been leaked. Currently, a company holding data about me (e.g. name, email address, phone number, credit history) causes a large amount of risk to me, but themselves carry no risk in case of a data breach. They are the ones who can decide to collect less information, keep shorter retention policies, or restrict access to prevent a breach, but they have no incentives to do so.

Yes, this would be a complete up-ending of many business models, but if your business model relies on collecting data without collecting the associated risk, it's a business model that society shouldn't allow to exist.

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

#166

Post by catwell »

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

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

Note that whereas I do believe that crash reporting can indeed be considered legitimate interest, I wouldn't consider plain telemetry ("phone home without a technical good reason") to fall under that umbrella...

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

#167

Post by nlarew »

tjoff wrote: post #160
PragmaticPulp wrote: post #157

Earlier quoted context omitted.

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…

If that was the norm then people would opt in. But the trust is gone now, bad actors have ruined it for everyone. And the solution to that is not to enable it by default.

Most people have no idea what "the norm" or "telemetry" even is so I highly doubt this would affect opt-in rates at all.

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

#168

Post by holtalanm »

hnlmorg wrote: post #47
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…

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.

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

#169

Post by chairmanwow1 »

This website strikes me nothing more than an idea that someone seems to be passing off as a movement. I feel like the negative reactions of the devs of the FOSS projects who got PRs from this person aren't that surprising. To me this doesn't seem to add that much value and I would probably bounce it from my project as well.

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

#170

Post by adkadskhj »

tjoff wrote: post #160
PragmaticPulp wrote: post #157

Earlier quoted context omitted.

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…

If that was the norm then people would opt in. But the trust is gone now, bad actors have ruined it for everyone. And the solution to that is not to enable it by default.

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 satisfy my questions i need some sort of router-enabled monitoring of all telemetry specific traffic. So i can individually approve types of info... and that seems difficult. But the days of blanket allowances from me are long gone due to the bad actors.

Post reply on HN