• potatopotato@sh.itjust.works
      link
      fedilink
      arrow-up
      20
      arrow-down
      1
      ·
      6 months ago

      Intrinsically/semantically no but the expectation is that the texts are encrypted at rest and the keys are password and/or tpm+biometric protected. That’s just how this works at this point. Also that’s the government standard for literally everything from handheld devices to satellites (yes, actually).

      At this point one of the most likely threat vectors is someone just taking your shit. Things like border crossings, rubber stamped search warrants, cops raid your house because your roommate pissed them off, protests, needing to go home from work near a protest, on and on.

      • 9tr6gyp3@lemmy.world
        link
        fedilink
        arrow-up
        22
        arrow-down
        9
        ·
        edit-2
        6 months ago

        If your device is turned on and you are logged in, your data is no longer at rest.

        Signal data will be encrypted if your disk is also encrypted.

        If your device’s storage is not encrypted, and you don’t have any type of verified boot process, then thats on you, not Signal.

        • douglasg14b@lemmy.world
          link
          fedilink
          arrow-up
          11
          arrow-down
          5
          ·
          edit-2
          6 months ago

          That’s not how this works.

          If the stored data from signal is encrypted and the keys are not protected than that is the security risk that can be mitigated using common tools that every operating system provides.

          You’re defending signal from a point of ignorance. This is a textbook risk just waiting for a series of latent failures to allow leaks or access to your “private” messages.

          There are many ways attackers can dump files without actually having privileged access to write to or read from memory. However, that’s a moot point as neither you nor I are capable of enumerating all potential attack vectors and risks. So instead of waiting for a known failure to happen because you are personally “confident” in your level of technological omnipotence, we should instead not be so blatantly arrogant and fill the hole waiting to be used.


          Also this is a common problem with framework provided solutions:

          https://www.electronjs.org/docs/latest/api/safe-storage

          This is such a common problem that it has been abstracted into apis for most major desktop frameworks. And every major operating system provides a key ring like service for this purpose.

          Because this is a common hole in your security model.

          • 9tr6gyp3@lemmy.world
            link
            fedilink
            arrow-up
            6
            arrow-down
            9
            ·
            edit-2
            6 months ago

            Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

            • douglasg14b@lemmy.world
              link
              fedilink
              arrow-up
              3
              arrow-down
              1
              ·
              6 months ago

              Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

              Damn reading literacy has gone downhill these days.

              Please reread my post.

              But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

              1. OSs provide keyring features already
              2. The framework signal uses (electron) has a built in API for this EXACT NEED

              Cmon, you can do better than this, this is just embarrassing.

        • uis@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          6 months ago

          Signal data will be encrypted if your disk is also encrypted.

          True.

          and you don’t have any type of verified boot process

          How motherboard refusing to boot from another drive would protect anything?

            • uis@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              6 months ago

              Well, yes. By refusing to boot. It can’t prevent booting if motherboard is replaced.

              EDIT: s/do anything/prevent booting/

                  • 9tr6gyp3@lemmy.world
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    6 months ago

                    If the hardware signatures don’t match, it wont boot without giving a warning. If the TPM/Secure Enclave is replaced/removed/modified, it will not boot without giving a warning.

    • AlexWIWA@lemmy.ml
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      6 months ago

      Mfw end to end can be compromised at the end.

      That said, they should fix this anyway

    • uis@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      Indeed, End-to-End Encryption protects data between those ends, not ends themselves. If ends are compromised, no math will help you.