Bad-actors would ignore it wholesale anyway, so this at best gives one a false sense of privacy. It would probably be better _not_ to have it, since people won't be misguided into thinking they're not being tracked.
An actual effective approach to privacy is to use a firewall to block all unwanted connections (allowlist only), and a DNS sinkhole like pi-hole.
IMO we should get more on the more aggressive side when it comes to mitigating tracking, and use tools that actually are a threat to the status quo. Tools like adnauseam[0] was blocked by Google[1] on their store because it actually worked—that says a lot more than a env var string they'll happily ignore.
I don't see why both solutions can't co-exist. If DO_NOT_TRACK suppresses the honest software (of which should be the majority you have installed anyway) then you have fewer applications left to manage manually / less network noise to identify and black.
Saying an imperfect solution is worthless is a little like throwing the baby out with the bath water.
I seriously doubt marketing and advertising departments will care about standards, if they would even notice. The industry can't even manage with web standards, imagine trying to get scummy tracking companies to comply.
IMO it's not even an imperfect solution. I'd say performative, and past DNT efforts have failed, so why are trying this again?
Maybe a tool that lets one easily report software for GDPR violations? That would have more teeth.
> I seriously doubt marketing and advertising departments will care about standards, if they would even notice.
The _vast_ majority of applications this relates to are not going to have marketing and advertising departments. They're unlikely to have more than a handful of maintainers. Most are likely just someone's side project.
> The industry can't even manage with web standards, imagine trying to get scummy tracking companies to comply.
We're not talking about a new standard that's even remotely in the same league as web standards in terms of complexity and nor are we talking about getting every scummy company to comply. A lot of command line applications already have an opt out so all this is proposing is making that opt out option the same.
This isn't any different to other common environmental variables like http_proxy -- not every application supports it but enough does that it is still useful.
> IMO it's not even an imperfect solution. I'd say performative, and past DNT efforts have failed, so why are trying this again?
As of yet, no effort has been made with regards to DNT in this field. You're conflating running untrusted web applications, with running trusted (and often open source) applications locally on the command line. They're two very different fields and as said already DNT options already exist for the latter but with every application having their own preferred variable name. All this proposal is seeking to do is standardise that name.
> Maybe a tool that lets one easily report software for GDPR violations? That would have more teeth.
To reiterate my original comment: the existence of one doesn't prevent the existence of the other. Why pick when we can have both?
Ahh, my big issue is that I don’t mind tracking in genuinely honest software. Want to know how many people are still running your app on 32-bit machines and that’s it? Be my guest!
It does seem like DO_NOT_TRACK isn’t supporting honest software, though. I can’t enable it for Audacity and disable it for Homebrew, for example.
Seriously, your concern is true for any software you run. You install software--say AWS CLI--on trust. But maybe it also installs a non-CLI keylogger, right? You'd have to do some serious investigation to know.
The point, I think, is to have a standard to make it easier on the user to select the option across multiple applications.
It should, imo, be opt in instead of opt-out (defaults to DO_NOT_TRACK=1).
I define a bad actor here as software that makes non-consensual network connections.
Agree on the software installs, and the risks attached. Modern OSes sandbox software wrt IO permissions, IMO we should be doing that sandboxing at the network level too.
Disagree with you on the opt-in. It should be neither, the software vendor should be the one asking permission, either explicitly or as a prompt on a firewall.
I’ve tried Little Snitch, but was quickly annoyed at the high interaction required. Maybe I should give it another shot, especially since I use uMatrix on Firefox, which is a similar concept.
It's overwhelming for the first couple of days, as periodic jobs wake up and ask for permission to connect to the Internet. Once you're over that initial hump, it basically disappears until some new app wants to connect to something unexpected.
An actual effective approach to privacy is to use a firewall to block all unwanted connections (allowlist only), and a DNS sinkhole like pi-hole.
IMO we should get more on the more aggressive side when it comes to mitigating tracking, and use tools that actually are a threat to the status quo. Tools like adnauseam[0] was blocked by Google[1] on their store because it actually worked—that says a lot more than a env var string they'll happily ignore.
0. https://adnauseam.io/
1. https://www.theregister.com/2017/01/05/adnauseam_expelled_fr...