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

251–260 of 352 posts

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

#251

Post by renewiltord »

slackfan wrote: post #133
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'…

Let's not beat around the bush, data costs money. Personal data costs money. How much are you willing to pay me for my app usage data? Oh, nothing? Well then, buzz off.

Literally all the software in question is free. Yeah, you can both tell each other to buzz off and no one will be upset.

http://i.giphy.com/Qp45SP1P3PbbO.gif

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

#252

Post by zomglings »

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 point here - support emails do not help you identify problems that less invested users may be having with your product.

For example, I used to work developer relations on TensorFlow. We wanted to make the framework accessible to enterprise data scientists. The problem was that these users were not familiar with the tools that we commonly used to get feedback - GitHub issues, the mailing list, etc.

Most of them were using TensorFlow on Windows via Jupyter, which wasn't well-represented among the users that we had frequent contact with.

It was really hard to understand the universe of issues that prevented most of these users from getting beyond the "Getting Started" experiences. Ultimately, these users are better served by easier to use frameworks like PyTorch, but I think a big reason that TensorFlow couldn't adapt to their needs is that we didn't understand what their needs were.

Another big problem is that it takes a certain level of technical sophistication to know how to send maintainers a useful crash report. If you rely on this mechanism, you will have a very biased view of your potential user base.

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

#253

Post by sneak »

pyr0hu wrote: post #187
argvargc wrote: post #112

Earlier quoted context omitted.

Any shame a person feels for their public contributions is their own.

But please explain how publicly calling out and potentially doxxing developers would help this issue? Do you really want to target single developers and unleash the fury of the HN crown on them? If we talk about morality and ethics, I think this is worse than implementing tracking, isn't it? I know you guys wants to change the world and I absolutely agree that there are too many tracking in the world, but FFS, let's…

What I'm talking about doing is literally reporting on already public data.

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

#254

Post by vhanda »

cmsj wrote: post #221
notatoad wrote: post #212

Earlier quoted context omitted.

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

> telemetry is useful I'm just going to point out that you accused privacy advocates of magical assertions, then did the same thing :) (there is a point of view which says that you make good products through thoughtful and rigorous design, rather than pouring over databases of events to try and reverse engineer how people are actually using your product)

Some ways in which telemetry can be useful -

* Figuring out which features are not being used, and being able to change things according. This also covers UI decisions - Oh. We added this new toolbar. Is anyone actually using it?

* Prioritizing localizations of a particular country / language.

* An actual positive feedback loop for products that don't generate revenue. Most open source project maintainers just receive bug reports, feature requests, and sometimes hate mail. Telemetry information which roughly shows that even though there are some people complaining loudly about the software, there are 50k other users happily using it, is very very motivating.

* Crash reporting / exceptions monitoring - Bugs are inevitable, and this gives so so much information. In my experience, very few users actually report bugs. Many might even just rate your app badly, and then ignore any attempts at following up. Especially cause they have deleted the app.

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

#255

Post by zomglings »

In Bugout, we have implemented a global do not track environment variable:

export BUGGER_OFF=true

If you set this variable, any tools collecting usage and crash reports using Bugout will not phone home with those reports.

(You can also use BUGGER_OFF=yes, BUGGER_OFF=1, etc.)

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

#256

Post by sneak »

latexr wrote: post #245
sneak wrote: post #27

Earlier quoted context omitted.

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…

> which you’d be able to do with greater effectiveness as the originator of a feature adopted by popular open-source projects

I'm not sure that's true at all.

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

#257

Post by fouric »

sneak wrote: post #29
seemslegit wrote: post #26

This is a losing proposition that will only lend credence to the inherently violent opt-out approach to data collection. Instead how about a do-not-hire-or-collaborate-with registry of the individual contributors participating in projects that employ those tactics and see how they like trying to opt out of it.

That is another website on my to-do list: one that names and shames spyware developers who create these commits. Git blame writ large.

You want to shame developers for including "usage reporting", "automatic update[s]", and "crash reporting" in their software?

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

#258

Post by sneak »

Igelau wrote: post #197
BowBun wrote: post #141

Agreed with many other posters here - the execution was messy and definitely lacked the calm and collected attitude I'm used to seeing when looking at new standards being discussed. I was also unimpressed with the tone of the issues/PRs opened. As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people…

Someone probably went looking for telemetry opt-out stuff since the recent discussion of Audacity's telemetry and weird policy changes. Somehow they found this. Unfortunately, the way this guy conducted himself was terrible. His tone and behavior in the issues and insistence that it's a standard just because he made a webpage were really off-putting. I can see why no one was champing at the bit to endorse this.

Unfortunately, opt-outs are purely perfunctory, as these kinds of developers would prefer they not exist at all. I now believe there was little/no hope of getting this sort of thing adopted in any case.

They don't want to make it easier to opt out; the opt out only exists to deflect blame.

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

#259

Post by jefftk »

amelius wrote: post #119
BurningFrog wrote: post #117

Earlier quoted context omitted.

> Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. This approach leads to fewer vendors.

Or users getting paid for their data.

Are you imagining a world in which volunteer developers of open source CLI apps pay users for the privilege of receiving crash reports?

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

#260

Post by marcthe12 »

drran wrote: post #196
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…

In Linux, we use `abrt` for that, but user need to review and submit bug report with stack trace manually, so nobody complains about that. Yep, it's very useful.

I think that is red hat specific. I have seen it on fedora but not arch or gentoo.
Post reply on HN