The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)
Console Do Not Track – Proposal for a standard environment variable
41–50 of 352 posts
Re: Console Do Not Track – Proposal for a standard environment variable
#42I doubt this will catch on. What's the incentive for the software companies to add it? I like the `source do-not-track.sh` idea better which defines a bunch of `WHATEVER_NO_TRACK := 1` variables. It could even modify config files for software that doesn't use environment variables. Or even better yet, just use a /etc/hosts file or a custom firewall.
[deleted]
Re: Console Do Not Track – Proposal for a standard environment variable
#43The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)
Belt and suspenders:
https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/ro...
Re: Console Do Not Track – Proposal for a standard environment variable
#44The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)
That's a good idea; it doesn't require buy in from the tool developers.
Re: Console Do Not Track – Proposal for a standard environment variable
#45I 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...
"You're not important. We might do this if you were someone who mattered."
Sad to see such, ah, well-socialized people in open in source projects.
Re: Console Do Not Track – Proposal for a standard environment variable
#46Earlier 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…
In the cases you list, you have other legal basis for processing than consent – i.e. legitimate interest – but that doesn't mean it's not personal data.
Indeed, IP-addresses are considered [0] personal data in some cases – which only really means that you need to follow the GDPR: have a legal basis for processing, do not process the data for reasons other than that for which you have a legal basis, delete it as soon as you no longer need it, implement protective measures, etc.
[0]: https://www.whitecase.com/publications/alert/court-confirms-...
Re: Console Do Not Track – Proposal for a standard environment variable
#47"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…
Sprinkling in the website URI into the source code of the PRs was definitely a bold move. I get the logic behind why it was done but one website does not constitute as a standard. If DO_NOT_TRACK were to be standardised then adding a URI to the published standard would have been more obviously intended as a constructive comment. But when the URI is a hobbyist's personal website, as well intended as it was probably meant to be, I can completely sympathise with why maintainers were sceptical about the sincerity of the PRs.
That all said, there has to be a path for unknowns to contribute good ideas back FOSS and I do think this is actually a pretty good idea that deserves to gain attention.
Re: Console Do Not Track – Proposal for a standard environment variable
#48Tracking should be opt-in, not opt-out. Period.
Re: Console Do Not Track – Proposal for a standard environment variable
#49Earlier quoted context omitted.
Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?
GDPR specifies what are valid reasons for collecting data, but as far as I know it does not require opt-in.
It does require an active choice/opt-in on the part of the data subject where your legal basis is consent.
It defines consent as “freely given, specific, informed and unambiguous” given by a “clear affirmative action.”
Pre-ticked boxes, for instance, are explicitly not allowed.
Re: Console Do Not Track – Proposal for a standard environment variable
#50"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…
Chicken and egg problem, naturally. I'd love it to gain more traction. It was an idea and I thought it would be better an idea and a website than just an idea. It was strange to see it get labeled as a marketing attempt during my attempts to gain some traction, considering I'm not selling a damn thing. I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches we…
> It's a doomed concept.
Indeed, because it assumes developers who are doing opt-out tracking will respect this voluntarily.
I disagree with the poster above about Debian adopting this. They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo; in distros that already keep non-free software out of the standard repository this wouldn't be that much of a leap. This seems necessary, as there's no sign that a "please don't track me?" flag will work better in the terminal than it does now in the browser.