Given the URL and list of different opt-outs I thought this was going to be a shell script to set all these for you.
In fact, I've just had an idea...
Do_not_track
11–20 of 179 posts
Re: Do_not_track
#12Also this, we disable it when building or deploying apps in DollarDeploy
export SEMGREP_SEND_METRICS=off export COLLECT_LEARNINGS_OPT_OUT=true export STORYBOOK_DISABLE_TELEMETRY=1 export NEXT_TELEMETRY_DISABLED=1 export SLS_TELEMETRY_DISABLED=1 export SLS_NOTIFICATIONS_MODE=off export DISABLE_OPENCOLLECTIVE=true export NPM_CONFIG_UPDATE_NOTIFIER=false
Re: Do_not_track
#13It'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 .
Better yet, don't allow such spyware crap on your computer.
Re: Do_not_track
#14He’s better off vibecoding an include.sh that sets all the known do not track env vars for you.
Re: Do_not_track
#15Default opt-in tracking should be illegal and enforced with such fines and prison sentences, that companies wouldn't even dare to have anything remotely capable of tracking in the runtime.
Unfortunately big corporations can always find away to make regulators see no problem.
Re: Do_not_track
#16I thought it would be a sh script to automatically set the flags for all known do not track env vars.
Re: Do_not_track
#17Honest 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?
Re: Do_not_track
#18Honest 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?
I would suggest that the default to enrolling people in supplying such information is the issue. In a world driven by surveillance capitalism, even "anonymous" data can be used for much broader purposes (think, for example, of when and where people are using tools geographically and at what times: you can start to track the behaviour of people in this way).
Users should never be opted in through usage alone of free or paid-for tooling to supply information that isn't part of the function of the tool. Where that is required for a service or product, you should opt-in explicitly, not implicitly.
Re: Do_not_track
#19This 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...
Re: Do_not_track
#20Honest 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?
I would suggest that the default to enrolling people in supplying such information is the issue. In a world driven by surveillance capitalism, even "anonymous" data can be used for much broader purposes (think, for example, of when and where people are using tools geographically and at what times: you can start to track the behaviour of people in this way). Users should never be opted in through usage alone of free o…
That's fair, thanks.