Console Do Not Track – Proposal for a standard environment variable • Hacker News Board

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

#261

Post by ccsnags » Tue, Jul 06, 2021, 5:18 PM UTC

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…

It sounds like there must be a standard of privacy for certain apps.

I work with UL a lot and they have lists of standards and specifications that help us meet the safety requirements of electronic devices. These standards are then used to meet the customers demand for a high level of safety. Customers in my field do not even consider products that don’t have UL. This strategy is good to better inform the consumer while standards are kept by an independent firm whose incentives are aligned to maintain their credibility.

I am not deep in the software field but I can imagine that groups like the EFF or similar orgs have a standard. The issue is that the consumers of these products don’t seem to care about this outside of the privacy advocate world.

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

#262

Post by jefftk » Tue, Jul 06, 2021, 5:20 PM UTC

542458 wrote: post #94

UncleMeat wrote: post #81

Earlier quoted context omitted.

DNT has already failed. It is long gone. A lot of people spent a ton of energy trying to make it work but it isn't going to succeed. Discussion around it now is not productive and should instead be focused on new initiatives. > I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches weren't tested very well. Treasure your flow state when you get it. This isn't…

I think there is useful discussion to be had as to why DNT failed. IMO it’s largely because people approached the problem from a purely tech-oriented standpoint and ignored any differing ideologies and incentives at play. An allegory to this project could be drawn.

From my perspective, a major issue with DNT was that it wasn't very clear to websites what a DNT request was asking for. The specification explicitly doesn't handle this: "This specification does not define requirements on what a recipient needs to do to comply with a user's expressed tracking preference" https://www.w3.org/TR/tracking-dnt/

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

#263

Post by renewiltord » Tue, Jul 06, 2021, 5:20 PM UTC

jagged-chisel wrote: post #185

> We will continue to support the opt out mechanism described here: ... You can, and ALSO support this new thing. Supporting one more env var if you already support one for this kind of functionality is easy and low risk.

Then fork and maintain the feature, dude. It's open source.

Everyone here wants someone else to do the work but they don't want to do any work.

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

#264

Post by sneak » Tue, Jul 06, 2021, 5:20 PM UTC

tsujp wrote: post #227

Would this have scope to be added to the XDG Desktop spec, at least on POSIX systems? Except of course, changed to opt-in: XDG_TELEMETRY_ON I'd never set it but at least it be an option for some.

Developers who ship spyware are even less likely to switch to an opt-in model than they are to support a unified system that makes it easy to opt-out.

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

#265

Post by sneak » Tue, Jul 06, 2021, 5:23 PM UTC

bruce343434 wrote: post #63

> Remember: in the right hands, an IP address is a physical location. Hmmmm, I doubt this. You'd need to be an insider at an (just the right) ISP or a government agency to turn it into an exact physical location.

Over a million people have a SECRET clearance in the USA.

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

#266

Post by ricardobeat » Tue, Jul 06, 2021, 5:24 PM UTC

Rygian wrote: post #65

ricardobeat wrote: post #51

Earlier quoted context omitted.

Why would a user ever opt-in to something that has zero immediate benefit? And for authors, that would be the same as permanently disabling tracking, nobody would adopt it. It’s the worst possible scenario. What we should work towards is privacy-conscious tracking, used sparingly only for monitoring critical pieces of the software and not all user actions. Flag/reject software that violates this. Then there is no nee…

Why would a developer be allowed to enable something that has zero immediate benefit for the user, yet erodes at the user's privacy? Privacy-conscious tracking begins with asking for permission to disclose my personal information (eg. my IP address), before anything ever goes on the wire.

That’s not what I meant by privacy conscious.

They don’t need your IP address to track usage or health metrics. Most of it can be collected anonymously. We should encourage software to simply not collect personal information at all.

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

#267

Post by sneak » Tue, Jul 06, 2021, 5:24 PM UTC

imiric wrote: post #127

WesolyKubeczek wrote: post #116

First, this is backwards. As many have pointed out, any and all telemetry should be opt-in, not opt-out, so the variable should be named YES_PLEASE_TRACK_THE_LIVING_SHIT_OUT_OF_ME, and if and only if is it equal to 1, should the data be collected. But what irks me more is this measly list of unsolicited PRs. Going over a list of projects where you are a nobody and inject yourself with your "improvements" there, with…

The thing is opt-in telemetry doesn't work. Few people will actively choose to enable it, even if they read the documentation and are aware of it. I think we should distinguish benign uses of telemetry from tracking that collects invasive details about the environment the app is running in. A popular CLI open source project I use has telemetry enabled by default. The authors are upfront about the data it collects and…

"Behaving ethically wouldn't work for us, so we decided to behave unethically" is not a legitimate viewpoint.

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

#268

Post by sneak » Tue, Jul 06, 2021, 5:25 PM UTC

fouric wrote: post #257

sneak wrote: post #29

Earlier quoted context omitted.

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?

Without obtaining advance consent? Yes, because that would be spyware.

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

#269

Post by jefftk » Tue, Jul 06, 2021, 5:27 PM UTC

kazinator wrote: post #243

> respect the following environment variable This is under-specified without giving a definition of environment variable. For the purpose of this choice, "environment variable" should have the broadest possible interpretation, referring to any relevant space that supports named configuration parameters: - UNIX or Windows environment variable - U-Boot or other boot loader variable. - Kernel parameter: e.g. ... root=/d…

Their proposal is for console apps, and gives the example "export DO_NOT_TRACK=1". They are talking about your first bullet, and not any of the others.

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

#270

Post by closeparen » Tue, Jul 06, 2021, 5:32 PM UTC

TeMPOraL wrote: post #207

015a wrote: post #180

Earlier quoted context omitted.

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

> 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. Devil is in the details. Unless you are very careful, even a basic crash report may leak PII (commonly, through careless logging). > Here's the problem: people…

The standard of "care and effort" in software engineering today begins with observability.

An error-handling branch without a counter on it will not get through code review. That an incident was detected through user reporting and not telemetry/alerting is a deeply embarrassing and career-limiting admission in a postmortem. That logs were insufficiently detailed to reproduce them problem will be a serious and high-priority defect for the team. Something like an entire app without any crash reporting is gross negligence on the part of the Senior VP on whose watch it happened.

I'm not really remarking whether this is good or bad, you're free to think this is a bad move, but from my perspective it is definitely the way the industry moved. Among my colleagues, releasing without a close eye on thorough telemetry is some childish cowboy amateur-hour shit.