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.

  • hirihit640@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    4 days ago

    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.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      4 days ago

      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.

      • hirihit640@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 days ago

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

        • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
          link
          fedilink
          arrow-up
          2
          ·
          3 days ago

          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.

          • hirihit640@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            ·
            2 days ago

            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.

              • hirihit640@sh.itjust.works
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 day ago

                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.

                • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  1 day ago

                  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.

                  • hirihit640@sh.itjust.works
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    1 day ago

                    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