Note: This is not so much about privacy issues created by Debian, but a list of still-extant privacy issues in upstream programs as packaged by Debian; i.e. those issues not already patched out by the Debian maintainers.
Also, some of them seem to be things to logically expect, IMO, like remmina having clipboard data shared between the endpoints. All fine as long as they are not hidden, and perhaps can be turned off.
This is a common misconception. IP addresses are only considered PII if you are in the position of being able to decode them to an identity. An anonymous version checking service obviously does not count.
Playing devils advocate here, but one interpretation of the law is that if any script that obtains the IP addresses could reverse it to an identity, then you are in violation.
Sure, and "one interpretation" of the sky is that it is purple. Or instead of making random interpretations up, we could look at actual cases like Breyer v. Germany, and see how the laws are interpreted in real life.
And I could interpret your text as Klingon. But that's not reasonable. My interpretation above was reasonable.
An IP address alone may not reveal who had visited a site.
However, Internet Service Providers have additional data that can link IP addresses to individual people. Although it's unlikely that the two data sets will ever be matched up, it is possible. So IP addresses must be treated as personal data.
Again, as I have said multiple times in this thread existing EU case law has made it clear IPs are only PII if and ONLY if you are able to do the conversion yourself (or give it to someone who can). Storing IPs in your web server logs is for an anonymous version checker is totally ok (as long as you aren't an ISP or someone who can do the conversion).
You can make up your own interpretations of the law as much as you want, but in real life the interpretation from the CJEU (for US readers like me, the EU's equivalent of the Supreme Court) is the one that matters.
You could store the IPs in logs until the heat death of the universe and it would be fine, as long as you aren't able to translate it to an indentity (or give it to someone who can). The point of my comment is that an IP is only considered PII when possessed by someone who can do the conversion.
It would be illegal specifically if you _collected and stored_ the IP address information from the phone home requests to process in some form later.
If you simply process the web request, and don't store the IP address then there it no issue.
If you do end up storing IP address in a log somewhere, then simply having the logs deleted in a documented and reasonable timeframe will be enough.
"Documented and reasonable timeframe" is intentionally vague since business requirements are varied, but if you can justify whatever you come up with, then there is no issue.
Simply do not hold onto user data for longer that what is required for the purposes of the user request. That's it.
It's not "outright illegal", AFAIK. If you can point me to a place that definitely says it is illegal (or not) I'd really appreciate it!
From what I've learned about EU regulations, ANY time you have technology that serves an EU citizen there is the potential for you to be sued over potential violations of the intentionally overreaching and vague privacy laws. The EU is so incredibly hostile to small business and FOSS.
>The EU is so incredibly hostile to small business and FOSS.
It's not EU being hostile, but rather US being incredibly lax(to put it mildly) about privacy issues, so that we even consider these violations a norm.
No, the "small guy" should not be entitled to violate privacy and rights of EU citizens (or any people, for that matter), just because US doesn't grant same protections.
Not a leap. The conversation jumped to the broader conversation of GDPR and PII a few comments up.
Running a service that might serve an EU citizen quickly escalates to involving lawyers and performing risk analysis in relation to being sued in a court across the ocean.
>Running a service that might serve an EU citizen quickly escalates to involving lawyers and performing risk analysis in relation to being sued in a court across the ocean.
Running any service where you are not sure of legal requirements might require consulting a lawyer first, how is it unique to GDPR? And in order to be on the radar for GDPR violations as a small business you REALLY need to do something seriously wrong.
I've always believed GDPR was a regulation that crossed borders. Meaning it applies to any EU citizen, no matter where they are located, which is what made this unique (being that it's not my countries laws). But:
> The GDPR applies to:
>
> a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.
So now I'm wondering if an IP address reverse-geo lookup to block IPs in the EU is the easy way out for many online services, presuming that this doesn't cause compliance issues for EU users using a VPN.
"Processing shall be lawful only if and to the extent that at least one of the following applies: [..] processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data"
Reasonable abuse protection clearly falls under that, as has been fairly clearly stated even in the GDPR itself: https://gdpr-info.eu/recitals/no-49/
All of the legal definitions of "PII" leave out a ton that is actually personally-identifying information. Just have personal standards that exceed all of the laws. No problem.
Like attempting to protect a service against abuse? Do that and be 100% confident your aren't in violation and post an easy step-by-step tutorial on how to do it.
Just some questions off the top of my head, that I, a FOSS developer have, and can not say with absolutely certainty that an EU court won't have problems with.
How long can the IP kept around for? And in what form? If it lands in a database, does it need to be encrypted at rest? Can it just be hashed? Salted, too? Do I need to rotate the salt? This limits the ability to protect the service though. Are the tools in my stack logging something somewhere else I don't know about? Could I get in trouble if it is? Cloudflare forwards IP-derived data to me, like the city of IP may be in, do I have to be concerned with that as well? Do I have to tell users upfront that I use Cloudflare and it derives data? I'm guessing I have to fully understand what CLoudflare does with this data. It eventually hits my Digital Ocean droplet, what does it log?, are there separate logs I can access from them outside my droplet? Certainly they have logs, too, what do I do about that? If I just require all users to explicitly agree to some form of data collection this probably goes away. Oh wait, now I have to manage obvious PII and ensure Right to be Forgotten can be exercised in a timely fashion, I've just made the whole thing more difficult for myself.
There is a cost, and it affect the small honest devs the most.
I'm not saying what GDPR is attempting to do is a bad thing, I'm just saying that it is not easy to comply like everyone keeps saying.
How can you say the questions aren't in good faith and then link to a popular Stack Exchange question and argument about some of them? Developers do need to ask these questions.
You have to be sure that you or anyone else in your chain can't link an IP to a specific person without explicit consent (and thus compliant with the rest of the regulation).
You can have cloudflare giving you IP/location pairs as long as cloudflare doesn't know who that person is.
You can keep your own logs of IP/person. You have to keep it safe, and inform somewhere in a policy that you are doing that. If the logs are kept abroad or cloud, then you need consent (and comply with the rest of the regulation).
It's all made to avoid companies tracking using across boundaries, selling data and having all that PII unwarranted for the next "We take your data and security very seriously" blog post about a leak.
It's easier not to keep any PII around. IPs? you can have as many as you want as long it can't be used to identify a person (without consent).
What if it's in an free open source project, and can be disabled? The point is to minimize the issues people open due to running old versions of the software.
I assume you're asking because you do collect it. It depends on your users and what level of privacy you claim. From some it's expected, others would result in uninstall. ToR phoning home on the users' open network will have a different reaction than Firefox, even if it's essentially the same browser.
I personally don't want my software making any connections unprompted except if that is its primary purpose.
Updates for OSS is also often installed via a package manager so additional checks are less useful and generally unwanted. That leaves non-package distribution (e.g. Windows or portable binaries) - I think best would be to either ask during installation or ask once if the local clock is quite a bit past the release date of the current version.
Of course different people will have different opions on this.
This is Debian we're talking about. If you package something for inclusion in Debian, you're supposed to update it with APT, not some home-baked updater that phones its own mama and displays its own notification.
If you want to push updates faster than Debian stable does, the proper way to do it is to provide a third-party APT repository. Then I can decide to disclose my IP to a mirror of my choice, using a proxy of my choice, that can be configured globally in /etc/apt.
Depends how hardcore you are about privacy and the claims the tool makes about privacy. Those who claim to collect none are held to a higher standard than others. Even if it's just version number it does leak usage, location and so on. It can have valid uses, but can also be cleverly abused.
But the upstream didn't package it, Debian forked it and added/changed build scripts to do so. It's on them to remove the update checks if they want to change the distribution mechanism.
True; the easiest solution is probably to have upstream add an option to ./configure to compile it out. FreeBSD, Red Hat, etc, etc. would also appreciate that.
Yes, but there's no requirement they do so. They might (depending on the project) accept such a patch, but catering to forks of their project is rarely any OSS maintainer's top priority. Major distro forks can be important, but if someone built their own update checking mechanism they probably don't care too much about other installation methods.
Well, adding the option would significantly decrease the set of patches that the distributions need to apply, which would decrease erroneous bug reports, etc.
A distribution-provided package doesn't really need to be a fork unless upstream isn't playing nicely with the rest of the OSS ecosystem.
I don't get it either. It feels like two separate things are confused .
1) "Privacy": I.e. the fear of PII being transmitted or used by a third party
2) "Control": I.e. the fear that the system does something that I didn't ask it for.
They are (quite weakly) linked, but they aren't the same things. I'd avoid even discussing them in the same breath for this reason. Saying that checking for updates is a privacy violation just means that everything is lumped together which is a fantastic outcome for software that is actually violating peoples privacy. "Everyone else does it".
I do not think that privacy is restricted to PII. For me, computer privacy is as simple as 'any information about what i do with computer that need not leak outside should not leak outside'.
PII leakages are just considered more severe than general information leakages, so there is a legislation to handle them.
So checking for updates without sending any identifier counts, since it transmits the fact you did in fact run the application, and it's not strictly necessary.
I can see the point but it seems hard to draw the line for every single feature at the precise point of "does a network connection". For some programs there is quite a grayscale of what's "necessary" (i.e. needed) and what isn't.
I agree that in some cases there is a grayscale because what is an important behavior for some users may be unnecessary for others. For example, i could accept that incremental search using Google when text is entered to address bar in a browser could be considered both useful feature and privacy violation depends on user expectations.
But i also think there are some clear lines, like if a tool is not expected to use network at all, it should not use it. If a tool is expected to communicate just with explicitly specified hosts, it should not communicate with third-parties, ...
yes, it leaks the information that you use the application (at all), at what times and so on, at a (potentially) individual level.
But I'm not sure what the remedy is for some applications auto updates might be unexpected or even unwanted, but for other applications it would feel pretty bad to not have them and have them enabled by default. That's the user's expectation - not the expectation of privacy for their IP. I think user expectations should be in focus, but it's not always easy to guess. Saying "put the lid on everything and let the user actively enable anything, check for updates etc" also isn't very user friendly.
I think software updating itself is sort of a windows mentality.
Most other operating systems (linux, macos, ios, etc) update through an os-wide mechanism.
Debian already has apt and that downloads a list of package names and versions from each repo and what is on the system is generally hidden. If the user asks to install a package, then the user has opted-in to download and install that package/dependencies. Also the packages can come from a variety of caches and mirrors.
> I think software updating itself is sort of a windows mentality.
Yes it's definitely a mentality of "the apps are separate from the OS" at least, which is basically every OS except Linux/Unixes with central package managers. Even on a Debian or Ubuntu system, I'd be using dozens of non-packaged applications though (Be they locally compiled from github, or flatpacks or whatever).
> Saying that checking for updates is a privacy violation just means that everything is lumped together
Your IP address is considered PII. Hell with a timestamp you can easily track the behavior of people. When do they work, when are they asleep, which holidays do they observe, when are they on vacation, ... . You can get really creepy with a tiny amount of actual information and some statistical analysis.
For platforms where the program is sandboxed and permissions have to be declared, I would frown at the software requesting network access just to check for updates. For example, mobile apps and programs in Flatpaks.
Why? In a world where the vast majority of computers are internet connected. This is just how software is constructed nowadays. Especially web development which is ahead of the ancient development practises common in libre software. Just open your network tab and see how many requests it makes without asking you.
No. My computer having an internet connection is not an automatic invitation for anyone's software to use it.
Just because a lot of software sucks doesn't mean it's acceptable or we should lie down and give up. We should work on improving OS capability/permissions models so that apps can't do this by default.
In the absence of better protections, I absolutely audit which processes make connections from my machine and uninstall those that make unwanted connections that can't easily be uninstalled (with a small number of unfortunate exceptions where the need to use certain software outweighs the desire to maintain a reasonable system).
This doesn't mean no connections ever, it means no conections users don't ask for and no connections that don't provide value to the user. It certainly means no phoning home or stats/crash data connection without explicit opt-in.
Debian is quite an opinionated project and they take matters like these very seriously. Pages like these don't exist to judge packages, they're merely there to make people who do care aware of any risks they might not have heard of, and help them exercise control over their machine if they consider these "risks" not to be worth it.
I doubt anyone will really care about version checks, unless that's the only reason your tool needs internet access at all. Maybe if you make it an opt-out rather than an opt-in feature (or don't prompt the user at all), I'd be annoyed by that (but I know others aren't).
They're completely unnecessary in packaged Debian software because the Debian people will provide newer versions of your application for their users, so a flag to opt out would be nice. Using this data in a useful way, like adding a message like "new version available" would be confusing, because there is no new version available when you run the system update tool!
Personally I'd say it should be possible to disable version checks through build flags if you intend to package software through official repositories.
If you intend to do distribution and updates yourself I don't think you should be forced to alter your code if people decide to add your software to their distribution. The burden of removing confusion and making their version stick to their ideals should be on them. It would be nice to cooperate, but I don't think you can be blamed for someone else's redistribution.
I used to be able to check out my `ntpd` config file and see where my system was getting it's time. Now on Bookworm I cannot find it. I suppose that's some Systemd service but I have not easily determined which one.
My point was going to be that I don't ever recall seeing a mention of this WRT privacy and Debian (or any other distro) collecting statistics on usage. The Debian installs that used `ntpd` used to default to a pool of Debian NTP servers. It seems to me that would provide a way of determining how many installs were active, at least the ones using the default server. In my case I changed them to use my pfSense firewall which got time from somewhere else.
This 'privacy leak' is probably on the order of the information revealed by APT queries.
I'd have to do a little more digging to determine where Bookworm is getting time by default.
It'll use either the server you (or your distro) configures in the config, the NTP server provisioned by your network configuration, or the fallback servers in the source code.
Debian ships systemd with a config file that has their servers pre-filled, but commented out, free for you to use. The systemd source says they use the Google NTP pool by default as a hard coded fallback, though Debian may have altered that.
I think the Debian project assumes that you're okay with communicating to Debian in some fashions if you choose to use their software. After all, if you run their code at the highest privilege, you're already putting a lot of trust in them.
> The Debian installs that used `ntpd` used to default to a pool of Debian NTP servers.
I think they are not technically Debian NTP servers, they are from a general public pool of NTP servers. But when such pool is used by vendors, there is a requirement to use separate subdomain: https://www.ntppool.org/en/vendors.html
> The Debian installs that used `ntpd` used to default to a pool of Debian NTP servers. It seems to me that would provide a way of determining how many installs were active, at least the ones using the default server
It would not be legal for Debian to do this without your informed consent.
> File format writing software leaks this into files
It is always so annoying, I don't want my files to have my user name in some meta fields. (text editors, image viewers, pdf viewers, literally if a file can contain my user name, all the software put it there by default. Maybe music files are the only exceptions.)
I have since forever. If you want my real name from my computer, you need to comb it until you find .pdfs of old bills or forms, maybe an old graphic of a business card design. It's not going to be in an API call (coming from inside the house) to your servers.
I have OpenSnitch[0] installed on Ubuntu, and when I launch the Calculator app it alerts me that Calculator tries to phone home to `imf.org` apparently for currency conversion purposes. I really don't want the International Monetary Fund in my calculator app.
- users and makers of dev tools are grouchy tech people like us. I think it's more than likely that tools for us and by us will implement stuff we want.
- most of this stuff is open source, so we can add it ourselves
But, that said I share your cynicism. When I learned about AWS_CLI_TELEMETRY (or whatever it is) I was like, "sigh, it begins".
90 comments
[ 2.8 ms ] story [ 167 ms ] threadAn IP address alone may not reveal who had visited a site. However, Internet Service Providers have additional data that can link IP addresses to individual people. Although it's unlikely that the two data sets will ever be matched up, it is possible. So IP addresses must be treated as personal data.
You can make up your own interpretations of the law as much as you want, but in real life the interpretation from the CJEU (for US readers like me, the EU's equivalent of the Supreme Court) is the one that matters.
But as others already said: if you don’t store the IP (eg in logs) it should be fine.
It would be illegal specifically if you _collected and stored_ the IP address information from the phone home requests to process in some form later.
If you simply process the web request, and don't store the IP address then there it no issue.
If you do end up storing IP address in a log somewhere, then simply having the logs deleted in a documented and reasonable timeframe will be enough.
"Documented and reasonable timeframe" is intentionally vague since business requirements are varied, but if you can justify whatever you come up with, then there is no issue.
Simply do not hold onto user data for longer that what is required for the purposes of the user request. That's it.
From what I've learned about EU regulations, ANY time you have technology that serves an EU citizen there is the potential for you to be sued over potential violations of the intentionally overreaching and vague privacy laws. The EU is so incredibly hostile to small business and FOSS.
It's not EU being hostile, but rather US being incredibly lax(to put it mildly) about privacy issues, so that we even consider these violations a norm.
Running a service that might serve an EU citizen quickly escalates to involving lawyers and performing risk analysis in relation to being sued in a court across the ocean.
Running any service where you are not sure of legal requirements might require consulting a lawyer first, how is it unique to GDPR? And in order to be on the radar for GDPR violations as a small business you REALLY need to do something seriously wrong.
I've always believed GDPR was a regulation that crossed borders. Meaning it applies to any EU citizen, no matter where they are located, which is what made this unique (being that it's not my countries laws). But:
> The GDPR applies to: > > a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.
from https://commission.europa.eu/law/law-topic/data-protection/r...
So now I'm wondering if an IP address reverse-geo lookup to block IPs in the EU is the easy way out for many online services, presuming that this doesn't cause compliance issues for EU users using a VPN.
"Processing shall be lawful only if and to the extent that at least one of the following applies: [..] processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data"
Reasonable abuse protection clearly falls under that, as has been fairly clearly stated even in the GDPR itself: https://gdpr-info.eu/recitals/no-49/
How long can the IP kept around for? And in what form? If it lands in a database, does it need to be encrypted at rest? Can it just be hashed? Salted, too? Do I need to rotate the salt? This limits the ability to protect the service though. Are the tools in my stack logging something somewhere else I don't know about? Could I get in trouble if it is? Cloudflare forwards IP-derived data to me, like the city of IP may be in, do I have to be concerned with that as well? Do I have to tell users upfront that I use Cloudflare and it derives data? I'm guessing I have to fully understand what CLoudflare does with this data. It eventually hits my Digital Ocean droplet, what does it log?, are there separate logs I can access from them outside my droplet? Certainly they have logs, too, what do I do about that? If I just require all users to explicitly agree to some form of data collection this probably goes away. Oh wait, now I have to manage obvious PII and ensure Right to be Forgotten can be exercised in a timely fashion, I've just made the whole thing more difficult for myself.
There is a cost, and it affect the small honest devs the most.
I'm not saying what GDPR is attempting to do is a bad thing, I'm just saying that it is not easy to comply like everyone keeps saying.
You have to be sure that you or anyone else in your chain can't link an IP to a specific person without explicit consent (and thus compliant with the rest of the regulation).
You can have cloudflare giving you IP/location pairs as long as cloudflare doesn't know who that person is.
You can keep your own logs of IP/person. You have to keep it safe, and inform somewhere in a policy that you are doing that. If the logs are kept abroad or cloud, then you need consent (and comply with the rest of the regulation).
It's all made to avoid companies tracking using across boundaries, selling data and having all that PII unwarranted for the next "We take your data and security very seriously" blog post about a leak.
It's easier not to keep any PII around. IPs? you can have as many as you want as long it can't be used to identify a person (without consent).
PS: here is a checklist => https://gdpr.eu/checklist/
Updates for OSS is also often installed via a package manager so additional checks are less useful and generally unwanted. That leaves non-package distribution (e.g. Windows or portable binaries) - I think best would be to either ask during installation or ask once if the local clock is quite a bit past the release date of the current version.
Of course different people will have different opions on this.
If you want to push updates faster than Debian stable does, the proper way to do it is to provide a third-party APT repository. Then I can decide to disclose my IP to a mirror of my choice, using a proxy of my choice, that can be configured globally in /etc/apt.
A distribution-provided package doesn't really need to be a fork unless upstream isn't playing nicely with the rest of the OSS ecosystem.
1) "Privacy": I.e. the fear of PII being transmitted or used by a third party
2) "Control": I.e. the fear that the system does something that I didn't ask it for.
They are (quite weakly) linked, but they aren't the same things. I'd avoid even discussing them in the same breath for this reason. Saying that checking for updates is a privacy violation just means that everything is lumped together which is a fantastic outcome for software that is actually violating peoples privacy. "Everyone else does it".
PII leakages are just considered more severe than general information leakages, so there is a legislation to handle them.
I can see the point but it seems hard to draw the line for every single feature at the precise point of "does a network connection". For some programs there is quite a grayscale of what's "necessary" (i.e. needed) and what isn't.
But i also think there are some clear lines, like if a tool is not expected to use network at all, it should not use it. If a tool is expected to communicate just with explicitly specified hosts, it should not communicate with third-parties, ...
Most other operating systems (linux, macos, ios, etc) update through an os-wide mechanism.
Debian already has apt and that downloads a list of package names and versions from each repo and what is on the system is generally hidden. If the user asks to install a package, then the user has opted-in to download and install that package/dependencies. Also the packages can come from a variety of caches and mirrors.
Yes it's definitely a mentality of "the apps are separate from the OS" at least, which is basically every OS except Linux/Unixes with central package managers. Even on a Debian or Ubuntu system, I'd be using dozens of non-packaged applications though (Be they locally compiled from github, or flatpacks or whatever).
Your IP address is considered PII. Hell with a timestamp you can easily track the behavior of people. When do they work, when are they asleep, which holidays do they observe, when are they on vacation, ... . You can get really creepy with a tiny amount of actual information and some statistical analysis.
Software should not make outgoing connections or accept incoming connections unless requested by the user.
modern websites are a cancer that we really quite could do without
The proof is in the pudding. You claim nobody wants these things yet there are billions of people using these kinds of sites.
Just because a lot of software sucks doesn't mean it's acceptable or we should lie down and give up. We should work on improving OS capability/permissions models so that apps can't do this by default.
In the absence of better protections, I absolutely audit which processes make connections from my machine and uninstall those that make unwanted connections that can't easily be uninstalled (with a small number of unfortunate exceptions where the need to use certain software outweighs the desire to maintain a reasonable system).
This doesn't mean no connections ever, it means no conections users don't ask for and no connections that don't provide value to the user. It certainly means no phoning home or stats/crash data connection without explicit opt-in.
I doubt anyone will really care about version checks, unless that's the only reason your tool needs internet access at all. Maybe if you make it an opt-out rather than an opt-in feature (or don't prompt the user at all), I'd be annoyed by that (but I know others aren't).
They're completely unnecessary in packaged Debian software because the Debian people will provide newer versions of your application for their users, so a flag to opt out would be nice. Using this data in a useful way, like adding a message like "new version available" would be confusing, because there is no new version available when you run the system update tool!
Personally I'd say it should be possible to disable version checks through build flags if you intend to package software through official repositories.
If you intend to do distribution and updates yourself I don't think you should be forced to alter your code if people decide to add your software to their distribution. The burden of removing confusion and making their version stick to their ideals should be on them. It would be nice to cooperate, but I don't think you can be blamed for someone else's redistribution.
My point was going to be that I don't ever recall seeing a mention of this WRT privacy and Debian (or any other distro) collecting statistics on usage. The Debian installs that used `ntpd` used to default to a pool of Debian NTP servers. It seems to me that would provide a way of determining how many installs were active, at least the ones using the default server. In my case I changed them to use my pfSense firewall which got time from somewhere else.
This 'privacy leak' is probably on the order of the information revealed by APT queries.
I'd have to do a little more digging to determine where Bookworm is getting time by default.
You can change this in /etc/systemd/timesyncd.conf
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
I suppose according to the other reply these are not operated by Debian but include their their name.
It'll use either the server you (or your distro) configures in the config, the NTP server provisioned by your network configuration, or the fallback servers in the source code.
Debian ships systemd with a config file that has their servers pre-filled, but commented out, free for you to use. The systemd source says they use the Google NTP pool by default as a hard coded fallback, though Debian may have altered that.
I think the Debian project assumes that you're okay with communicating to Debian in some fashions if you choose to use their software. After all, if you run their code at the highest privilege, you're already putting a lot of trust in them.
I think they are not technically Debian NTP servers, they are from a general public pool of NTP servers. But when such pool is used by vendors, there is a requirement to use separate subdomain: https://www.ntppool.org/en/vendors.html
It would not be legal for Debian to do this without your informed consent.
It is always so annoying, I don't want my files to have my user name in some meta fields. (text editors, image viewers, pdf viewers, literally if a file can contain my user name, all the software put it there by default. Maybe music files are the only exceptions.)
Although ubuntu is based on debian, it is significantly worse with respect to privacy and respect for the user.
[0] https://github.com/evilsocket/opensnitch
[0]: https://consoledonottrack.com/
- users and makers of dev tools are grouchy tech people like us. I think it's more than likely that tools for us and by us will implement stuff we want.
- most of this stuff is open source, so we can add it ourselves
But, that said I share your cynicism. When I learned about AWS_CLI_TELEMETRY (or whatever it is) I was like, "sigh, it begins".