Live data from Hacker News

Do_not_track

donottrack.sh

21–30 of 179 posts

Re: Do_not_track

#21
post #4

It's probably easier to run your own DNS and blacklist the offending domains. There are good blacklists with millions of telemetry domains, e.g. https://github.com/hagezi/dns-blocklists .

That is the correct way of handling this.

Everyone proclaiming a "standard" is just adding to the long list of (unofficial) alternatives.

Re: Do_not_track

#23

This is set up for the same fate as DNT in browsers. Collecting all the "do not track" env vars into a single "do_not_track.env" file, however, may not be a bad idea...

Love it. This is an annoying problem and likely the actual solution than asking folks to use a universal one. I'll put something together as a starting point.

Re: Do_not_track

#24

This is set up for the same fate as DNT in browsers. Collecting all the "do not track" env vars into a single "do_not_track.env" file, however, may not be a bad idea...

Advertisers chose to ignore DNT because they claimed Microsoft making DNT enabled by default took agency away from the user. In reality, they probably weren't going to honor it anyway.

Re: Do_not_track

#25

This is set up for the same fate as DNT in browsers. Collecting all the "do not track" env vars into a single "do_not_track.env" file, however, may not be a bad idea...

https://toptout.me - exists and handles a lot of these problems, if not looking to create a new wheel.

Though if you just want a simple ENV var that handles this WHILE honoring the specification on this page: https://github.com/alloydwhitlock/do-not-track-cli

Re: Do_not_track

#26
post #10

Looks like a helpful honeypot! Any tool that will public announce support for this spec is a tool I know to avoid because it collects telemetry without explicit opt-in in the first place.

Most services are already collecting telemetry, them announcing support for it won't change that.

Re: Do_not_track

#28
post #17

Honest question, what's the problem with crash dumps that include no personal info? They just help make the software less buggy. I also don't see an issue with anonymized usage patterns (this feature was used X times this month, this one Y times, etc). Can someone expound on what they see as a problem?

> Honest question, what's the problem with crash dumps that include no personal info?

In addition to the other response: crash dumps are difficult to anonymize, both because useful crash dumps include something like a minidump (or some other small alternative to a core file), and because even without that, any random information from a backtrace may be sensitive (e.g. a URL).

There's nothing wrong with saving a crash dump and giving the user control of whether to submit a bug report.

Re: Do_not_track

#29
I’m morally opposed to the notion of optimizing the opt-out mechanism. I want a standardized opt-in mechanism, like:

  export ALLOW_TRACKING=telemetry,crash_dumps
and the absence of such a setting means “fuck off, don’t spy on me”. It’s not my responsibility to turn off apps wanting to track me. It’s their responsibility to get me to authorize their specific flavor of tracking.

Re: Do_not_track

#30
post #10

Looks like a helpful honeypot! Any tool that will public announce support for this spec is a tool I know to avoid because it collects telemetry without explicit opt-in in the first place.

Well, don't look too deep else you won't be using many modern tools.
Post reply on HN