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

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

#101

Post by gnud » Tue, Jul 06, 2021, 1:12 PM UTC

Anunayj wrote: post #24

cupofjoakim wrote: post #8

Earlier quoted context omitted.

This is a great point actually - but it probably depends on if the data is regarded as "personal data" or not. IP-addresses is considered sensitive which would mean that if they're saving that it is probably not ok. I'm not a lawyer though :)

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…

If you save IPs to use for fraud detection, then under the GDPR you can't use them for _ANYTHING_ else, and you need a sensible rule for how long you keep them.

Most of those checkboxes are not worth anything under GDPR, because people don't give a clear, informed consent when they have no chance of understanding what is being asked.

The law is not the problem. Lack of enforcement is.

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

#102

Post by xyst » Tue, Jul 06, 2021, 1:14 PM UTC

dpcx wrote: post #88

renewiltord wrote: post #61

Earlier quoted context omitted.

Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.

Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?

Probably the homebrew maintainers have hard coded usage of “HOMEBREW_NO_ANALYTICS”. The PR likely only fixes one instance. Lack of unit tests in PR support this hypothesis.

Could be wrong though and the maintainer simply needed a vague excuse to not merge it. Haven’t completed a deep dive. I couldn’t be bothered to compare repository at the time of PR 2 yrs ago on mobile.

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

#103

Post by finnthehuman » Tue, Jul 06, 2021, 1:15 PM UTC

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

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

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

#104

Post by genezeta » Tue, Jul 06, 2021, 1:15 PM UTC

beaconstudios wrote: post #92

account42 wrote: post #90

Earlier quoted context omitted.

You are not entitled to crash reports - that applies to open source developers just as to anyone else. If you wan't crash reports, have some kind of wizard or command to submit them and point to that when a crash happens, but you must always gather informed consent before submitting that data.

I like how games typically handle this; if the application crashes a dialog appears asking if you want to send a crash report, and often tells you what's included in said report.

Many Windows applications used to do that. Just search for "crash report dialog" images and you'll find many of them.

Firefox does it too. And it keeps a log of past crashes on about:crashes where you can decide which ones to submit.

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

#105

Post by soraminazuki » Tue, Jul 06, 2021, 1:15 PM UTC

noname120 wrote: post #15

cupofjoakim wrote: post #3

I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if other major players adopt it first. Cmon, it's such a minor change. Getting these PR's in means _you are_ a major player (atleast to some) and you might be able to drive change in a positive way. Why not jump on the opportunity?

This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...

From the link:

> I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others.

It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.

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

#106

Post by cardiffspaceman » Tue, Jul 06, 2021, 1:17 PM UTC

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

That certainly is the devil’s side. Unfortunately too many firms have affixed phony halos and then exfiltrated the People‘a personal data. Opt-in is the only way the People will be able to choose whom they trust.

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

#107

Post by TeMPOraL » Tue, Jul 06, 2021, 1:20 PM UTC

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

> Most people will shoot support e-mails at you which are more or less "app crashes". (...) If you collect crash reports, you have probably already fixed the problem.

Fair enough. Still, there are two separate steps here: collecting crash reports and sending them. What if the app asked if it can send the report, letting you optionally review it? Many programs today do that, I think it's an effective compromise. Additionally, the app could store some amount of past crash reports, and the places for the users to get the support e-mail (a form, a button, an address in a help file...) could request you to check for, or automatically call up, those past crash reports, and give the user choice to include them. The way I see it, the app should give users near-zero friction to opt-in, but still have them opt-in.

It won't solve the problem of bad support requests completely, but nothing ever does - random people will still write you with problems for which you have no data (e.g. network was down when crash occurred), or for which no data exists (because requester is a troll).

> For usage data, it allows developers to focus on features that matter and know which ones you can remove.

I accept this as an argument in favor, though personally, I don't consider it a strong one. I feel that "data-driven development" tends to create worse software, as companies end up optimizing for metrics they can measure, in lieu of actually checking things with real users, and thus tend to miss the forest for the trees.

Picking good metrics is hard, especially in terms of usage. The most powerful and useful features are often not the ones frequently used. Like, I may not use batch processing functionality very often, but when I do, it's critical, because it lets me do a couple day's worth of work in a couple minutes.

So, for me, can usage telemetry improve software? Shmaybe. Is it the only way? No, there are other effective - if less convenient - methods. Is the potential improvement worth sacrificing users' privacy? No.

> on iOS crash reports are opt-in, and only about 20-30% of users have them enabled. That is fine for huge programs or ones with little surface.

I feel the main reason this is a problem is because of the perverse incentives of app stores, where what you're really worried about is not crashes, but people giving you bad reviews because of them. Mobile space is tricky. But then, forcing everyone into opt-in telemetry doesn't alter the playing field in any way.

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

#108

Post by argvargc » Tue, Jul 06, 2021, 1:21 PM UTC

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…

> I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume.

I can't. That suggestion seems the product of desperate reach for an ad hominem attack.

There are clear, plausible and obvious reasons for the projects existence that require no seeking of hidden motive to understand or explain.

I'd agree OS-level integration for this stuff would be better, supposing OS manufacturers would also elect to include their own telemetry under such an umbrella.

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

#109

Post by arp242 » Tue, Jul 06, 2021, 1:21 PM UTC

xpressvideoz wrote: post #91

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…

Because I want the apps I use daily to improve? Of course I recognize I'm in the minority.

I think you're probably not. If you explain the details to random people on the street then I bet that a majority would probably be fine with it.

I don't even like to use the word "tracking" any more as it's lost all meaning. Not all "tracking" is identical: some is highly problematic, some is a little bit problematic, some is just fine. When you lose light of any and all nuance and difference then the conversation becomes pointless.

It's just that these topics attract people on horses so high they need spacesuits asserting all sort of things in the absolute that it appears you're in the minority.

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

#110

Post by gurchik » Tue, Jul 06, 2021, 1:23 PM UTC

ccsalvesen wrote: post #4

This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.

The person who suggested the same thing in the Homebrew PR was blocked:

> devlinzed - We shouldn't accept a future where spyware is the norm and rely on this environment variable. We know how that turned out with HTTP Do Not Track. As long as spyware is bundled with Homebrew, Homebrew shouldn't be used or recommended or normalized. The solution is for Homebrew to remove its spyware by having explicitly opt-in telemetry only.

> Homebrew blocked devlinzed on Nov 15, 2019