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

271–280 of 352 posts

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

#271

Post by sneak »

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…

> 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 on bad behaviors.

The majority of "getting someone else to do something" in our society is done with negative "coercion" (for lack of a better term) than positive.

Most people go to work only because a policeman will come to their house and make them homeless at gunpoint if they don't.

The percentage used to be even higher, but excommunication doesn't carry the sting it once did.

Ultimately, the end result of all legislation and regulation of industry is the implied threat of negative consequences, up to and including state-sanctioned violence, for people who violate laws. Calling out bad behaviors is a common and traditional technique for getting new laws passed.

Shame and bad PR is a powerful tool. Last November I shamed Apple into dropping unencrypted OCSP. Perhaps one day I can shame developers into not spying on their users without consent.

Fact: the bad PR of shipping nonconsensual spyware is the only reason there is an opt-out lever at all. If we can amplify that, we can make it being enabled a default.

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

#272

Post by naikrovek »

yunohn wrote: post #84
naikrovek wrote: post #25

I'm sure everyone doing tracking of console programs is just chomping at the bit waiting for the creation of an easy-to-remember way for users to opt out... more useful would be something like this that lets users opt in or out of the various TYPES of tracking that are done. for example, I don't care about application usage telemetry. if you want to know that it's hard for me to remember a particular subcommand and a…

> "please donate, I'm not rich enough yet" Who do you feel entitled enough to judge someone’s humble request for a donation, despite them developing the free software that you use often enough to be annoyed by it?

if they wanted to be paid, would they not release as a product, instead of releasing as open source?

"hey I'm gonna give away my time and effort for free" is not how you get money. it's how you get geek cred or build up a resume or whatever. all fine, of course. do what you want.

if you want to charge for your code, charge for it and stop asking for donations every time I clone or build your stuff.

have a donation button somewhere so people CAN donate, of course. asking is very .. beggy and it drives me nuts, especially when it's from people who make $500k/yr at their day job.

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

#273

Post by vinkelhake »

johannes1234321 wrote: post #247
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'…

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

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

#274

Post by sneak »

sss111 wrote: post #219
sneak wrote: post #43

Earlier quoted context omitted.

Belt and suspenders: https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/ro...

thanks for making this!

You're welcome. I haven't updated it for Big Sur yet, hopefully that will happen this month.

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

#276

Post by sneak »

seemslegit wrote: post #121
easterncalculus wrote: post #115

Earlier quoted context omitted.

Negative punishment will not work for this, you would be going after the symptom instead of the problem. Don't make it harder for people that write these changes, make it harder for people to force others to. There will always be another developer, and there's no guarantee you'll know their identities. If you're looking to bring attention and make a statement at the potential expense of others that's one thing, but p…

Practically speaking, that's the only approach that can. Although it's often hard to tell, most software developers aspire to being treated like professionals rather than specialized serfs, and part of being a professional is accepting responsibility for your work. Of course it doesn't preclude holding their employers responsible as well.

Netlify deleted my issue comment naming the developer who put `force: true` in their cli (sending a telemetry event when disabling telemetry) even though his name is still available in `git blame` in their public repo.

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

#277

Post by sneak »

pyr0hu wrote: post #189
tofuahdude wrote: post #176

Earlier quoted context omitted.

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

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.

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

#278

Post by GekkePrutser »

tfigment wrote: post #149
GekkePrutser wrote: post #140

Earlier quoted context omitted.

If that were the case, why do Microsoft apps still crash so frequently

My experience is third party products/add-ins (specifically McAfee Enterprise Suite) cause most of the crashes I have with Office products. Most OS blue scrrens are non-microsoft hardware drivers.

I was mainly referring to their apps on Mac and Android.. They crash a LOT. Especially Teams for Mac and Outlook on Android. And both use lots and lots of telemetry. Lots and lots of traffic to hockeyapp.com (which is a MS telemetry platform) and various telemetry URLs at microsoft.com.

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

#279

Post by infogulch »

TeMPOraL wrote: post #224
Seirdy wrote: post #192

Earlier quoted context omitted.

How do users know if that's all the data that's submitted? Auditing every program to see exactly what gets sent (and repeating the process for every update) is way too much work; it's safer to just opt-out by default. Now that I think about it, it's safer to simply not use software that opts users into studies (like telemetry analysis) without informed consent.

> How do users know if that's all the data that's submitted? That's the thing, isn't it? They'll never know. They can't; it takes deep technical knowledge to even be able of conceptualize what data could be sent, and how it could be potentially misused. Which is to say, it's all a matter of trust. Shipping software with opt-out telemetry (or one you can't disable) isn't a good way to earn that trust.

Even with deep technical knowledge and severely pared down telemetry, PII embedded in side-channel like outlets could be missed. Think a simple stack trace with no data is PII-free? Probably. But are you sure that the stack of functions called doesn't depend on the bytes in your name?

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

#280

Post by fouric »

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)

> 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 they're actually using your software - not how you think they should be. There are people who design pieces of software that are meant to be opinionated, beautiful gems that are not meant to be used by others (which includes software that pays lip-service to users but is so user-hostile that it's effectively not for them anyway) - and telemetry, crash reports, auto-updates, and more generally a feedback loop from user to developer are not for them.

The second is that it requires a lot of discipline. Look at how user-hostile most applications (both open-source and proprietary) are anyway - do you really think that their developers are going to have the discipline to carefully engineer a good user experience? As an idealist, I wish that they did, but as a realist, I know that in most cases that will never happen, and so telemetry and crash reports (crashing is part of a bad user experience) will get you a slightly better piece of software than nothing at all.

Post reply on HN