Debian will remove code that “calls home”
or tries to update software in a way that
bypasses the Debian packaging system.
Debian will remove code that “calls home”
or tries to update software in a way that
bypasses the Debian packaging system.
Debian indeed does this. In release FF has disabled telemetry: https://wiki.debian.org/Firefox
For example, when closing firefox on OpenSUSE Leap 15.6, "pingsender" is launched to collect telemetry:
It has been there for years. It is also on other distros.
Windows is activly hostile to anything privacy related.
Arch comes with the default of do it yourself. Lots of footguns, but not hostile OS behavior. Great difference to me.
When I read comments like yours "Arch is a minefield" "With Arch it is so easy to shoot yourself in the foot", I never know what this could be specifically. How could this look like? Can you give me something more concrete? I'm really eager to know what everyone is talking about.
Imagine me: I'd consider myself a Linux noob, although I probably aren't anymore. I use Arch Linux for about 3 years now as my daily driver. I'm not young anymore - I didn't grew up with computers - I don't have it in my blood. I don't have formal education in anything computer and have never worked in the field. During Covid I learnt Linux from the Arch wiki. Now I'm using it. I configured some things and can control my computer through the command line.
Everytime I read comments like yours, I get the shivers. Did I miss something integral? What do I not know about? Especially network stuff is a blind spot for me. I didn't touch network stuff beyond the default wiki pages.
All because Ableton cannot be bothered to support Linux :/ I understand that though, just sucks...
More color: I was happy running Arch on a 2012 vintage Dell Latitude (Intel, integrated graphics) for several years. I'm currently quite happy running Arch on a Lenovo Thinkpad T14s (gen2, AMD, integrated graphics).
Arch wiki does have many pages about arch-on-a-particular-model to help once you get a short list of models you're interested in, like this: https://wiki.archlinux.org/title/Lenovo_ThinkPad_T14s_(AMD)_...
Imagine me: I'd consider myself a Linux noob, although I probably aren't anymore. I use Arch Linux for about 3 years now as my daily driver. I'm not young anymore - I didn't grew up with computers - I don't have it in my blood. I don't have formal education in anything computer and have never worked in the field. During Covid I learnt Linux from the Arch wiki. Now I'm using it. I configured some things and can control my computer through the command line.
Everytime I read comments like yours, I get the shivers. Did I miss something integral? What do I not know about? Especially network stuff is a blind spot for me. I didn't touch network stuff beyond the default wiki pages.
When I read comments like yours "Arch is a minefield" "With Arch it is so easy to shoot yourself in the foot", I never know what this could be specifically. How could this look like? Can you give me something more concrete? I'm really eager to know what everyone is talking about.
Let's take a look at the xz incident, then at how fast rolling release distros get their packages in. That's part of the equation. Bottom line is: you're the first line of defense against potential malicious supply chain attacks. This is why Fedora is Red Hat's testing distro, why Debian has an unstable branch or why openSUSE Tumbleweed exists. Now, Arch isn't just a "testing distro", but it is, by design, more susceptible to these attacks. Thinking bleeding edge is more secure is a fallacy. It is but a consequence of assuming the source maintainers are on your side, which is usually the case, but not always. Or, assuming software is properly tested for bugs every release. If you are still doubting this, look at npm.
Furthermore, have you ever asked why you need to constantly update package signing keys? There is no central build server for Arch. Maintainers are building packages in whatever machine they are on, signing with whatever keys they have there and uploading the binary blobs. This isn't trustworthy. There is now a clean chroot process and all, but still, maintainers are still able to build the packages in their machine and upload it.
The other problem is not having any mandatory access control security policy by default (SELinux, AppArmor, etc...). You can, of course, install your own and go through the trouble of actually creating the security profiles yourself for the various packages on the system. This is in stark contrast with other distros, where not only they provide a security policy by default but their packages also ship with security profiles when needed to make sure it actually works (Fedora and openSUSE come to mind).
Finally, the AUR is cool and all, but my god are you at the mercy of whatever is put on there. Sure the PKGBUILD is super legible, but are you really checking where things are being pulled from? There is a layer of filtering being taken away here, you are the one doing your due diligence.
Now I'm sure different people have different takes on this, some might say that security policies are dumb and useless, others might prefer to be in the bleeding edge assuming the latest and greatest is safer. But take all the layers I have mentioned here, and how their non-existence on Arch could affect security. I hope to have drawn a clearer picture.
(Edit: I must say, I like Arch, I've used it a lot and when in a pinch is my go to. But I've come to appreciate how other distros approach security, and how they layer the process so they have more time to assess vulnerabilities. It is a balancing game, and I hope Arch improves on their processes, I really do.)
So I can add spotify or signal-desktop to NixOS via nixpkgs, and they won’t succeed at updating themselves. But they might try, which would be a violation of Debian’s guidelines.
It’s a tough line — I like modern, commercial software that depends on some service architecture. And I can be sure it will be sort of broken in 10-15 years because the company went bust or changed the terms of using their service. So I appreciate the principles upheld by less easily excited people who care about the long term health of the package system.
And yes, good point, this was indeed discussed when devbox enabled AI training by default. It somehow seems like there is more than one category of phoning home at play here, since it is obviously tolerated in other cases.
I wonder what debian’s process is for dealing with such maintainers.
I hope they make “no phone home” actual policy soon.
"This daily count of users is what keeps us working on the project, because otherwise we have feel like we are coding into a void."
Is that better or worse than phoning home to serve ads?
Also, if feels misleading to me to call fetching a motd phoning home. You know Ubuntu does this too right? That feels more worthy of outrage than this.
If someone tells me, this software phones home, and it's not transmitting anything other than a ping; kinda feels like they're lying to me about what it's actually doing.
I'm not upset by the author wanting a bit of human connection to the people who enjoy his software. I empathize with the desire to see people enjoy the stuff I've made. Is it a privacy risk? Perhaps, but it's not even on the top 1k that I see daily. There's more important windmills to tilt at.
But... if you really just wanna be outraged; I recently wrote a DNS server that I use as the default for my home system. Currently It prints every request made, you might wanna try something like that. If you're that upset about this, you're gonna be blown away by what else is going on you didn't even know about.... and that's just dns queries, it's not even the telemetry getting sent!
It is really hard to run netstat. Or tcpdump. /s
Just one possible example, among many others that have telemetry code into them.
Telemetry is perfectly acceptable as long as it is opt-in and does not contain personal data, and both apply to Go's telemetry, so there's no need for a fork.
Telemetry contains personal data by definition. It just varies how sensitive & how it's used. Also it's been shown repeatedly that 'anonymized' is shaky ground.
In that popcon example, I'd expect some Debian-run server to collect a minimum of data, aggregate, and Debian maintainers using it to decide where to focus effort w/ respect to integrating packages, keeping up with security updates, etc. Usually ok.
For commercial software, I'd expect telemetry to slurp whatever is legally allowed / stays under users' radar (take your pick ;), vendor keeping datapoints tied to unique IDs, and sell data on "groups of interest" to the highest bidder. Not ok.
Personal preference: eg. a crash report: "report" or "skip" (default = skip), with a checkbox for "don't ask again". That way it's no effort to provide vendor with helpful info, and just as easy to have it get out of users' way.
It's annoying the degree to which vendors keep ignoring the above (even for paying customers), given how simple it is.
No. Please look up the definition of "telemetry" and "personal data". The latter always refers to an identifiable person.
“Person” isn’t either, unless the software knows for sure it’s not being uses by a person.
If you have a nginx log and store IP addresses, then yes: that contains PII. So the solution is: don't store the IP addresses, and the problem is solved. Same goes for telemetry data: write a privacy policy saying you won't store any metadata regarding the transmission, and say what data you will transmit (even better: show exactly what you will transmit). Telemetry can be done in a secure, anonymous way. I wonder how people who dispute this even get any work done at all. By your definitions regarding PII, I don't see how you could transmit any data at all.
On the server side you would not. Your application would just do the work it was intended to do and would not dial out for anything. All resources would be hosted within the data-center.
On the workstation it is up to the corporate policy and if there is a known data-leak it would be blocked by the VPN/Firewalls and also on the corporate managed workstations by IT by setting application policies. Provided that telemetry is not coded in a way to be a blocking dependency this should not be a problem.
Oh and this is not my definition. This is the definition within literally thousands of B2B contracts in the financial sector. Things are still loosely enforced on workstations meaning that it is up to IT departments to lock things down. Some companies take this very seriously and some do not care.
Why it has to include PII by definition? I'd say DNF Counting (https://github.com/fedora-infra/mirrors-countme) should be considered "telemetry", yet it doesn't seem to collect any personal data, at least by what I understand telemetry and personal data to mean.
I'm guessing that you'd either have to be able to argue that DNF Counting isn't telemetry, or that it contains PII, but I don't see how you could do either.
I would argue that users can't inherently trust the average developer anymore. Ideas about telemetry, phoning home, conducting A/B tests and other experiments on users, and fundamentally, making the software do what the developer wants instead of what the user wants, have been thoroughly baked in to many, many developers over the last 20 or so years. This is why actually taking privacy seriously has become a selling point: It stands out because most developers don't.
If you take the next step: “do not use software from vendors you don’t trust,” you are severely limiting the amount of software you can use. Each user gets to decide for himself whether this is a feasible trade off.
popcon is least likely to be turned on by:
- organizations with any kind of sensible privacy policy (which includes almost everyone running more than a handful of machines)
- individuals concerned about privacy
popcon is most likely to be turned on by Debian developers, and people new to Debian who have just installed it for the first time.
And if they, or someone else, use this for RCE ? Asking for a friend. /s
This changed somewhat recently. Telemetry is enabled by default (I think as of Golang 1.23?)
I am only aware since I relatively recently ran into something similar to this on a fresh VM without internet egress: https://github.com/golang/go/issues/68976
https://github.com/golang/go/issues/68946
If golang doesn't fully address this I guess Debian really should at least change the default (of they haven't already).
I switched to devuan. It’s great, but it sucks that the community split over something so needlessly destructive.
Especially since I was novice at best before the systemd thing, and my Ubuntu dive involved trying to navigate all 3 of these pretty drastic changes at once (oh yea and throw containers on top of that).
I went into it with the expectation that it was going to piss me off, and boy did it easily exceeded that threshold.
Yes, I've disabled the update check. No, it doesn't solve the problem.
Most obvious example is Firefox. The Debian Project allows Firefox to update outside the packaging system, automatically, at the whim of Firefox.
And there's the inclusion of non-Free software in the base install, which is completely against the Debian Social Contract.
The Debian Project drastically changed when they decided to allow Ubuntu to dictate their release schedule.
What used to be a distro by sysadmins for sysadmins, and which prized stability over timeliness has been overtaken by Ubuntu and the Freedesktop.Org people. I've been running Debian since version 3, and I used to go _years_ between crashes. These days, the only way to avoid that is to 1) rip out all the Freedesktop.Org code (pulseaudio, udisks2, etc.), and 2) stick with Debian 9 or lower.
No, it's not. Stable ships ESR which has its update mechanism is disabled. Same for Testing/Unstable. It follows standard releases, but autoupdate is disabled.
Even Official Firefox Package for Debian from Mozilla has its auto-updates disabled and you get updates from the repository.
Only auto-updating version is the .tar.gz version which you extract to your home folder.
This is plain FUD.
Moreover:
Debian doesn't ship pulseaudio anymore. It's pipewire since forever. Many people didn't notice this, it was that smooth. Ubuntu's changes are not allowed to permeate without proper rigor (I follow debian-devel), and it's still released when it's ready. Ubuntu follows Debian Unstable, and Unstable suite is a rolling release, and they can snapshot it and start working on it whenever they want.
I'm using Debian since version 3 too, and I still reboot or tend my system only at kernel changes. It's way snappier w.r.t. Ubuntu with the same configuration for the same tasks, and is the Debian we all know and like (maybe sans systemd. I'll not open that can of worms).
It seems likely that you personally chose to install a flatpak or tar.gz version probably because you are running an older no longer supported version of Debian.
>These days, the only way to avoid that (crashes) is...
Running older unsupported versions with known never to be fixed security holes isn't good advice nor is ripping out the plumbing. Its almost never a great idea to start ripping out the floorboards to get at the pipes.
Pipewire seems pretty stable and if you really desire something more minimal it's better to start with something minimal than stripping something down.
Void is nice on this front for instance.