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.

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

    Systemd was designed long after a lot of these security practices and problems with tracking were well understood. There’s very little excuse for it doing a lot of the things it does. Systemd is literally re-architecting how Linux was meant to work originally, and for the worse. I get the impression you’re not actually familiar with the history of Linux or Unix philosophy in general.

    Having to put everything into containers is really just a work around bad architecture that keeps being pushed in the Linux world. Containers are useful, and probably the only way to actually keep apps from having too much access to the system at this point, but I don’t see why bad architecture should be accepted and then have to be worked around.

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

      I get the impression you’re not actually familiar with the history of Linux or Unix philosophy in general.

      I’ve read enough mailing lists and issue trackers to know that they are far more complex than they look on the surface, so I definitely won’t claim authority about them.

      Take this one that I found recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

      It’s a bug report about Firefox’s favicon cache. They started looking into it, but found out that if they fix this bug, it creates fingerprinting risk, so they have to address that as well. And so the issue gets stuck in limbo for like 10 years, and is still open till today.

      Regarding systemd, it had to be built on top of the existing architecture, and more importantly, had to appeal to the Linux community to be adopted, so it couldn’t change too much. I assume they have their reasons for depending on machine-id. It might not even be a direct dependency. Maybe it allowed easier adoption by the big players.

      I don’t know, and honestly, I don’t really care about digging into every single fingerprinting vector (of which there are probably tons more), when I can just use containers. And while using containers might feel like a hack or workaround, if we look at Flatpak, it seems like containers are becoming the framework for app isolation on Linux, similar to what already exists on Android. So it may very well become the official solution to privacy and security on Linux.

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

        My point is that systemd did not have to be built at all. It’s an abomination that goes directly against the original philosophy of Linux creating a monolithic monstrosity to replace individual and composable programs that used to be the way init works. Now, everything is tied to it and it’s become like a cancer in a linux system that’s inoperable. The whole system-id problem is just one example of why this is a terrible design.

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

          Well I’m not here to argue about systemd in general, that’s a far larger topic. All I’ll say is that from my experience, systemd felt cleaner than the competitors at the time and created a lot of conventions and standards that are taken for granted today.

          For example, to bring this back to the original topic, another commenter in this thread mentioned that systemd provides an API for generating randomized machine-ids that flatpak utilizes.

          Though flatpak is gaining more dependency on systemd, and I don’t think that coupling is necessary, so I’ve been keeping an eye out in that space.

          Edit: researching a bit more on the topic, there’s some interesting comments here about how systemd is not as monolithic as people think

          flatpak is not depending on systemd as a whole, they’re depending on a new component called systemd-appd…it is an API + a spec, just like what you’re asking for. But it’s implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.

          [systemd] not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.

          systemd-appd will likely depend on some but not all of the rest of the systemd system.

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

            My view is that systemd was a mistake and I disagree with it on a philosophical level. I see stuff like machine-id getting baked in as a direct extension of this philosophy.

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

              Many software decisions are more about strategy than philosophy. Compromising on ideals and principles to gain adoption. As mentioned before, I would not be surprised if dependence on machine-id was simply strategy.

              Systemd might be replaced in future. But currently it’s used in all major distros. It’s design and ideas will probably inspire whatever replaces it. If they had spent their time clinging to philosophy and ideals rather than making compromises, then they might have never left the ground.

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

                I’m not sure what was supposed to be leaving ground in your mind to be honest, or whose strategy you’re talking about. Linux used to be a community driven effort rather than some company trying to gain growth. Why is gaining adoption so important all of a sudden when Linux has been around for ages without mass adoption, and it’s been doing just fine. Seems like part of the issue is actually commercialization because a lot of the decisions are driven by distros that are backed by companies who do want to make profit off the platform.

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

                  Well one reason why adoption matters is network effects. Increased Linux popularity, means that more developers will develop for Linux. At a broader level it means that the ideology and principles of the Linux community, like software freedom and privacy, can produce quality results and products for the masses. That brings more power for the Linux community, and more adoption of their principles.

                  On the flipside, if the base Linux experience is mediocre, then nobody will bother developing apps and extensions for it.

                  If you are completely happy with Linux the way it is now, then that adoption probably doesn’t mean a lot. But I personally think there’s a ton more that can be done in the Linux and privacy world

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

                    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.

        • strawberry_enjoyer42@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          4
          ·
          2 days ago

          After reading through this whole comment thread, reading this was the last straw. I’ve been planning my exodus for a while.

          Soon, I shall say “I use Artix, btw”.

        • eldavi@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 days ago

          My point is that systemd did not have to be built at all. It’s an abomination that goes directly against the original philosophy of Linux creating a monolithic monstrosity to replace individual and composable programs that used to be the way init works. Now, everything is tied to it and it’s become like a cancer in a linux system that’s inoperable.

          amen and try sharing this view on c/linux or c/privacy. lol

          i struggle to understand why both communities are such fervent systemd and proton supporters when other similar communities on other lemmy instances aren’t.

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

            Yeah, I have a hard time understanding the justification for systemd. The only real argument I’ve seen is that it standardizes the process, but that could’ve been done as a spec where you define a common config format, lifecycle, etc., and then keep the actual utilities decoupled from each other, but behaving in a uniform way.