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

331–340 of 352 posts

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

#331

Post by pseudalopex »

fouric wrote: post #280
cmsj wrote: post #221

Earlier quoted context omitted.

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

> 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 There are two problems with this view. The first is that it's generally user-hostile. If you're meaning your software to be useful to users, then you need to see what your users' needs are, and how…

The problem with telemetry is it doesn't tell you what users' need are. It tells you what they do with their software. Not why. Not how they feel about it. Not what they wish it would do.

Thoughtful and rigorous design includes user research and testing.

In my experience it takes more discipline to use telemetry responsibly. I've seen equivalent data used to justify removing 1 feature and making another more prominent. It seems to go hand in hand with UI churn. And it seems to lead to dismissing user feedback.

Crash reports and event streams are different. But there's no reason not to ask consent anyway.

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

#332

Post by pseudalopex »

closeparen wrote: post #330
pseudalopex wrote: post #327

Earlier quoted context omitted.

The standard of care and effort in human interactions begins with consent.

You consent to a scope of work. If you want line item control over exactly how the work gets done, what tools the workman gets to bring, what creature comforts he is and isn’t allowed on the jobsite, that’s something you can negotiate. Like if you’re Amish or under some weird historic preservation regime or working near a delicate billion-dollar scientific instrument. Perhaps you really need carpentry done with hand…

Strained analogies aren't useful. Software that doesn't collect data or asks consent isn't even unusual.

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

#333

Post by pabs3 »

sneak wrote: post #57
alpaca128 wrote: post #50

Earlier quoted context omitted.

> It's a doomed concept. Indeed, because it assumes developers who are doing opt-out tracking will respect this voluntarily. I disagree with the poster above about Debian adopting this. They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo; in distros that already keep non-free software out of the standard repository this wouldn't be that much of a leap. This see…

> They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo Debian maintainers are amazing and they go one step further: they patch it out when they distribute it. They also patch out old version time bombs and all manner of other phone-home.

Not all of them, there are still tons of privacy issues in Debian:

https://wiki.debian.org/PrivacyIssues

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

#334

Post by pabs3 »

Dayshine wrote: post #284
account42 wrote: post #99

Earlier quoted context omitted.

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

tracker.debian.org is the internal site for Debian contributors, packages.debian.org is the site for Debian users.

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

#335

Post by pabs3 »

PragmaticPulp wrote: post #157
finnthehuman wrote: post #103

Earlier quoted context omitted.

>I'll play the devil's advocate. Your point is basically "surveillance data is useful". And, well, yes. There would be zero debate over surveillance if there were literally no desirable reasons to have it.

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…

Stack traces can include private user data too, I always review all of the data in a stack trace before filing bug reports.

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

#336

Post by [deleted] »

Seirdy wrote: post #292
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…

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

[deleted]

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

#337

Post by Anunayj »

mschuster91 wrote: post #38
Anunayj wrote: post #24

Earlier quoted context omitted.

Storing IPs by themselves are not against the GDPR, and you do not really require consent for storing them for legitimate reasons, (Think nginx access logs, or rate limits on API endpoints/ banning IPs abusing your service). [1] Pairing IP addresses with other potentially identifying information can also be a little bit of a legal gray area (Look at Fingerprint.js) if done for legitimate reasons (Like fraud detection…

> GDPR had a great potential, it's sad it was unable to do it's best. Given the massive backlash against the GDPR and "cookie walls" by newspaper publishers, it's doing a pretty good job. Can you imagine a company like Apple whipping app vendors into shape regarding data collection without GDPR pressure?

I agree GDPR did make a lot of good change. I don't mean to say GDPR was a waste. It was awesome. What i mean is, Some things (like Cookie banners) kinda defeat half it's purpose, and at times made browsing more annoying.

I'd love too see them do something about it. Amd i hope they do.

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

#338

Post by yoz-y »

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.

This may be a noble goal but then it may also lead to the program never being updated. If you need to do a major update (underlying system library no longer works, dependency is deprecated and has a security hole, a new direction requires overhaul of backend) you may need to prioritise what to keep and what to let go.

A problem I encountered was also localisation. Once you localise your program, adding any string is exponential work. In this case removing features can give you a lot of slack.

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

#340

Post by kasabali »

jordemort wrote: post #134

It’s disappointing, although not entirely surprising, how some projects met this idea with outright hostility. It’s an extremely simple idea. It seems obviously correct to me and I’m not sure what benefit any further effort at discussion or standardization would bring.

> I’m not sure what benefit any further effort at discussion or standardization would bring.

It'd allow them to come up with more bullshit excuses to not implement it, that's what.

Post reply on HN