72
Linux has /etc/machine-id and you forgot to setup your init daemon to periodically truncate and regenerate a new machine-id so you can be tracked via user telemetry analytics. (lemmy.ml)
submitted 4 months ago by to c/privacy@lemmy.ml
76 comments fedilink hide all child comments
 

Ultimately, the problem is much bigger than /etc/machine-id since there are dozens of hardware IDs on any PC that can be used by malicious telemetry to silently to uniquely identify and track you, and the only solution to this problem currently is to make sure you really trust any software you use.

Systemd, in particular, acts a lot like malware for Linux because if you try to reset your machine-id a long list of stuff that breaks in in it. You could make a cron script to reset /etc/machine-id every day, but machine-id is so deep in the stack that you'd also have to reboot to ensure it's updated.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 1 point 4 months ago (19 children)

The whole context here is that Linux philosophy and principles are being gutted by companies trying to make a buck off it. In my view, benefits of wide adoption need to be balanced with actually retaining the principles which make Linux a good platform.

Again, Linux has been around a long time before commercial interests started fucking with it. And I don't think chasing adoption for the sake of it is healthy. I'd rather it grows at its own pace. It's already a big enough community to make it sustainable indefinitely, there's absolutely no rush to gain market share here.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 19 child comments
    •
  • [–] 2 points 4 months ago* (18 children)

    I'm not sure if the principles have been gutted like you say. Fedora, for example, uses systemd, and is supported by the commercial RedHat. And yet it is well regarded in the Linux community, and has firmly stuck to open source and pro-privacy principles. They foster diversity too, like the Fedora Atomic and Universal Blue projects, which make it easy to fork distros and create new ones. Not to mention, Linus Torvalds uses Fedora.

    One could say that Linux is already growing at its own pace. There are some that wish it would move slower, some that wish it would move faster. systemd wasn't forced on distros. in fact Ubuntu fought it for years, since it was created by their competitor after all. Yet Ubuntu still adopted it in the end, so it must have been worth it.

    The way I see it, back in the day, Linux was too fragmented in some areas, and at the same time lacking isolation in others. Systemd standardized and addressed the fragmentation, while containers introduced isolation where needed. The lines are being re-drawn. But I don't think the principles of Linux were compromised that much.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] [S] 1 point 4 months ago (17 children)

    I'm not sure who regards RedHat well actually, they've always been doing shitty things like trying to charge for Fedora hence why people ended up forking it as CentOS. They're a poster child for the problems with Linux getting commercialized. Saying Linus uses something is just appeal to authority by the way.

    The problem, once again, is that a lot of the development is now driven by commercial companies like RedHat and Ubuntu that are in it to make money. So, in a way these things are actually pushed on the community because you either adopt them or it becomes increasingly difficult to run software on your distro.

    Fragmentation in init was a real problem, but it could've been solved much better by just creating a common standard for configurations while keeping the original modular design. Systemd approach is very heavy handed, and introduces a whole bunch of new problems which didn't exist. The fundamental Unix principle is having small programs that do a single thing well and that can be composed together. Systemd goes directly against this principle.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 17 child comments
    •
  • [–] 1 point 4 months ago (16 children)

    Saying Linus uses something is just appeal to authority by the way.

    I was giving Linus as an example of a member of the Linux community, and a particularly prominent one at that. There are many indicators that Fedora is well regarded, and that is just one of them.

    you either adopt them or it becomes increasingly difficult to run software on your distro.

    Arguably, systemd made it easier to run software on Linux. The standardization made it easier for devs to write software that worked across distros. Devs didn't have to fight fragmentation in the lower levels and could focus on building platforms on top like Flatpak, which in turn led to even more software and apps available on Linux. It's way easier to find and run software than a few years ago.

    I'm guessing what you were trying to say is that it's harder to find and run software on Linux that doesn't use systemd. That's fair. Just like it's hard to find apps nowadays that don't use web technology, and require something like Electron or Firefox to run. But if we think of systemd as a platform (though I think it's more complicated than that), does it go against the ideals of Linux?

    The fundamental Unix principle is having small programs that do a single thing well and that can be composed together

    First off, I know you didn't say this but I want to just clarify: software principles are different from community ideals. Software principles are a means to an end. And they are often broken. Modular design is hard to get right. Microservices often end up messier than the monolithic approach. Ultimately it's a balance. And strategy plays into this too. If monolithic design allows faster iteration, then even if it gets replaced with modular design later, you can use the lessons learned during those iterations to make the modular design.

    It's possible that someday Redhat tries to weaponize systemd and it ends up holding Linux back until we can replace it. But I doubt it. If you look at the recent backlash that Fedora and Firefox has gotten for AI, you can see that the Linux community is pretty vocal and active about their ideals.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] [S] 1 point 4 months ago* (15 children)

    I've already explained repeatedly how systemd goes against core Unix philosophy. Communities can form around all kinds of things, just because a community forms around bad idea that doesn't mean it should be automatically accepted. Linux did get modular design largely right, that's the whole problem here. Systemd throws the baby out with the bath water. Monolithic design was basically more convenient for companies trying to monetize the platform.

    Systemd has gotten plenty of backlash as well, I'm certainly not the only person who sees the problems with it. The problem is that it'll keep getting pushed by commercial interests. And the same thing will happen with AI incidentally.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 15 child comments
    •
  • [–] 1 point 4 months ago (14 children)

    I was agreeing with you. Systemd breaks unix philosophy. You know what else breaks unix philosophy? The Linux kernel. It's absolutely massive. If you want unix philosophy, switch to a microkernel.

    Also another commenter in this discussion pointed out that flatpak does not actually obfuscate machine-id. You can read the issue tracker here: https://github.com/flatpak/flatpak/issues/4311

    Basically comes down to a design decisions from 15+ years ago, in things that flatpak depends on. This is an open issue to this day. Would it have been better for flatpak to have delayed release until this was solved, possibly remaining unreleased to this day? Meanwhile everybody would have to use regular system packages, which not only have access to machine-id, but also the entire userspace, with zero sandboxing. I doubt that would be better.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] [S] 1 point 4 months ago (13 children)

    There are microkernels like minix and they work well, but that's a different animal because user space is where you actually do make changes much more commonly than in the kernel. Also, I don't really follow your argument regarding flatpack, it's like you're implying that containerized apps couldn't exist without using machine-id for some reason?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] 1 point 4 months ago (12 children)

    I'm saying that if flatpak tried to implemenet machine-id obfuscation before releasing, they might not have ever released. By constraining their scope, they were able to focus on their other goals and release, and a lot of Linux users including me, are glad they did so. You can think of systemd's machine-id situation in the same way

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] [S] 1 point 4 months ago (11 children)

    I'm saying flatpack didn't even have to use machine-id at all for anything it does. I don't know why you're so invested in the idea that this was somehow necessary and nothing better is possible.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 1 point 4 months ago (10 children)

    Perhaps ask in the github issue I linked earlier why machine-id is necessary at all. They may have their reasons. My guess is that it makes it easier for devs to port their applications to flatpak, namely legacy apps that depended on machine-id.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] [S] 1 point 4 months ago (9 children)

    It probably does, but I suspect they just didn't consider the problem in the first place rather than the issue being that not having a persistent id is somehow extraordinarily difficult.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 0 points 4 months ago (8 children)

    You could say the same about Linux itself and machine-id. Fingerprint resistance just wasn't in the project scope.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [S] 1 point 4 months ago (7 children)

    You could, but there was no machine-id on Linux originally and it was something that got added and arguably shouldn't have been. Again, I'm really struggling to understand why you're so invested in defending this decision. Like it's obviously a bad decision, it's not necessary, why is it so hard for you to just say that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 4 months ago (6 children)

    I feel like my argument is not that hard to follow. I'm saying that just because machine-id makes fingerprinting easier, doesn't make it a bad decision because it could still lead to a net positive. In the Linux kernel's case, it might have been a simple solution to other problems, at a time when fingerprinting was not a concern. In systemd's case, it might have made it easier to accomodate legacy systems that depended on machine-id. Same with flatpak.

    Linux, systemd, and flatpak are all fairly successful within their target markets. Clearly, you're going to need more evidence if you want to claim it's a bad decision.

    In fact even if your goal is privacy and fingerprint resistance, just switching to another init system is not a panacea. First off, as mentioned in the flatpak github issue linked earlier, there are tons of other markers aside from machine-id that can be used for fingerprinting. And if you're using a mainstream distro, your new init system is likely less supported, meaning more bugs, worse security, and potentially a net loss in privacy.

    Win the battle, lose the war. This is why I brought up compromise and strategy earlier.

    In the end, it's hard to say how individual decisions like machine-id, contribute to the net result. There are pros and cons to each decision. Maybe if there was a competitor that didn't use machine-id and pulled ahead due to that decision, but I'm not seeing one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] [S] 1 point 4 months ago (5 children)

    You have yet to explain what the net positive that machine-id brings to the table is. I'm eagerly waiting for you thesis.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 months ago (4 children)

    First off, your post wasn't about machine-id, it was about systemd using machine-id, yes? If you think machine-id is a mistake, blame Linux, not systemd. This is a shift from your original claim.

    Second, I've already explained my argument many times. Machine-id was likely a simple solution to a few problems Linux faced, and Linux was able to keep pace with competition and gain popularity. Same with systemd adopting machine-id. If they focused on fingerprint resistance, then other core features of modern Linux distros would have lagged behind, and I might not be using Linux today.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 1 point 3 months ago (3 children)

    Maybe go back and read through the thread because I very clearly and repeatedly explained myself. I'm not going to do it once again for you here. You've basically made this huge assumption that machine-id was somehow critical to adopt for which I'm not aware of any supporting evidence, nor have you bothered providing any rationale for. You just keep stating it as fact. Meanwhile, as I've explained, systemd makes the whole situation worse precisely by creating a monolithic structure which everything depends on, and which makes solving the problem more difficult now. I don't think there's any point continuing the discussion though because we just keep restating the same points here and I don't think any further understanding will be gained by anyone from continuing to do that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 3 months ago* (2 children)

    My evidence was small but should have been easy to understand:

    1. systemd uses machine-id 2 systemd adoption is high amongst distros

    You can argue correlation vs cause but I'd argue this is not zero evidence.

    You are on the other hand assuming that it would have been easy to avoid machine-id. Do you have evidence for this claim?

    Why should I have to provide evidence while you provide none

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 3 months ago (1 child)

    That's not evidence of anything, it's just a tautology stating that machine-id is indeed used, which has never been under any dispute throughout this discussion. What I provided was rationale for why machine-id is problematic, and why systemd makes the problem worse. You have not provided any rationale for why it's necessary aside from stating a tautological fact here. Again, nothing new has been added to the discussion in the process, but you insist on continuing it for reasons unknown. I'll just let you have the last word here since that's what you seem to be after.

    Have a good day.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 months ago

    it's just a tautology stating that machine-id is indeed used

    I stated two things, that machine-id is used and that adoption is high. You're ignoring the latter. Might be correlation or causation, but definitely not tautology.

    You have not provided any rationale for why it's necessary aside from stating a tautological fact here

    This is a gross misrepresentation of my words. I'm not saying it's necessary, I'm saying it contributed to the success of some of the most private distros that exist today. In other words a net positive. You provided zero evidence that it was a net negative, and demonstrated ignorance about the complexity of engineering.

    Either you keep misunderstanding my argument, or deliberately misrepresenting it to avoid admitting its merits. It's becoming clear which is true.

  • permalink
  • fedilink
  • source
  • parent