I was taking a look at the Naomi Wu situation (A Chinese DIY tech youtuber who went missing after being watched by the government) and in one part they mentioned that she was concerned about her privacy, so started using Signal, but had a default chinese keyboard that had a keylogger and the police had looked into what she was talking on there.

I’m not sure if it was a mobile only thing, but it was mentioned that the keyboard app was used in like 70% por chinese smarthphones.

Now, I use AnySoftKey and refuse to use default keyboard apps, but how far can we reach on the keyboard security thing? Is typing on a computer or using a physical keyboard on a mobile device 100% safe? I think the keyboard issue is often overlooked and would like to know what recommendations your have? Or what should be known more?

  • ReversalHatchery@beehaw.org
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    On a standard computer, be it a desktop or laptop, it’s very hard to effectively avoid keylogging.

    I don’t say you 100% have a keylogger on your PC, that’s not my point.
    My point is that both on Windows, and on Linux systems that use the X11 window system instead of Wayland, any program can log your let presses with basically no effort.
    On windows this is somewhat restricted when a program opens a secure desktop (a temporary “desktop”, usually (always?) with a single window). This happens when you have to grant admin rights to a program, but other programs can request such a thing too, like the keepass password manager can be set to prompt for the password on a secure desktop. I don’t know if the X11 window system of Linux has a similar feature.

    But, as the other commenter said too, it depends on your threat model, because it can go a lot deeper than your choice of keyboard app.
    If you use the original system of your smartphone, the manufacturer may have hidden software in it that can log your key presses even without cooperation if your keyboard app.
    But if the modem - which is basically a different operating system that runs in parralel to the main one, but with the purpose of handling the connection with the cellular network, besides doing quite a few other things too - could get compromised, often it could be used to have open access to all the hardware that your main, android operating system uses. How is this on topic? This way intruders could observe where do you touch the touch screen, among a lot of other things.

    • nickwitha_k (he/him)@lemmy.sdf.org
      link
      fedilink
      arrow-up
      7
      ·
      10 months ago

      This is exactly why Wayland replacing X11 is a good thing. X11 was developed in an academic, on-prem LAN environment where such security wasn’t a big consideration in its architectural design and needs to be allowed to gracefully retire from mainline use.

      • jmp242@sopuli.xyz
        link
        fedilink
        arrow-up
        5
        ·
        10 months ago

        I really don’t see why you couldn’t attack wayland if you’re running code locally. Wayland is going to need keyboard hooks anyway to enable important productivity tools like anykey and clipboard managers.

        • nickwitha_k (he/him)@lemmy.sdf.org
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          10 months ago

          Absolutely. With local and physical access, attacks are very doable. Starting with a security-conscious architecture means that it’s easier to improve over time.

          ETA: The main point is that tech and use cases have evolved. This means that architecture of existing components needs to be re-evaluated for whether they are still a good way of accomplishing a task. In the case of X.org/X11, the architecture is more challenging to secure due to fundamental design. Wayland may not have full parity for remote use yet but, currently, security is generally a higher priority, so, its newer architecture that DOES consider security and sandboxing gives a better starting point in that area.

          I fully anticipate that Wayland will also be replaced in the future as tech and use evolves further (does it consider AR/XR? Man-Machine-Interfaces that might see adoption? etc.). Like biology, it’s the nature of tech to evolve and, since there isn’t a sign that bad actors will be absent in the future, Wayland’s architecture will likely end up being insufficient to secure against input logging attacks of the future.

      • drspod@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        10
        ·
        10 months ago

        This is a /c/Privacy thread about mobile keyboards, my guy.

        • ReversalHatchery@beehaw.org
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          10 months ago

          No, this thread is a general one, and I have mentioned Wayland. And they responded to me.
          The post may be more about mobile keyboards, but OP has also asked about what’s the case with computers, besides phones

    • argv_minus_one@beehaw.org
      link
      fedilink
      arrow-up
      3
      ·
      10 months ago

      My point is that both on Windows, and on Linux systems that use the X11 window system instead of Wayland, any program can log your let presses with basically no effort.

      On Wayland, they probably still can. Wayland’s core protocol doesn’t allow it, but extensions to enable things like global hotkeys can almost certainly be used for shenanigans.

      Also, if the keylogger is running under your user account, it can insert crafted .desktop files wrapping around your apps, ptrace your apps, you name it. Sandboxing as in Flatpak can stop this sort of thing, but if you run an app outside such a sandbox, and it’s malicious, game over.

      • ReversalHatchery@beehaw.org
        link
        fedilink
        arrow-up
        3
        ·
        10 months ago

        Wayland’s core protocol doesn’t allow it, but extensions to enable things like global hotkeys can almost certainly be used for shenanigans.

        But does it work without prompting the user?
        Also, I’m not too familiar with how it works, but afaik global hotkeys on KDE are implemented by the display server/compositor/whatever it’s called itself, and not sourced out to a different program.

        Also, if the keylogger is running under your user account, it can insert crafted .desktop files wrapping around your apps, ptrace your apps, you name it.

        Well, that’s an interesting point, I haven’t thought about that.

        • argv_minus_one@beehaw.org
          link
          fedilink
          arrow-up
          3
          ·
          10 months ago

          But does it work without prompting the user?
          Also, I’m not too familiar with how it works, but afaik global hotkeys on KDE are implemented by the display server/compositor/whatever it’s called itself, and not sourced out to a different program.

          Right, but they’re configured by an unprivileged program: the settings app. Presumably, a keylogger can pretend to be the settings app.

          • ReversalHatchery@beehaw.org
            link
            fedilink
            arrow-up
            2
            ·
            10 months ago

            Presumably, a keylogger can pretend to be the settings app.

            Couldn’t the display server check if the app is actually the settings app by looking at it’s executable’s location? Not sure how reliable that is, but if it is, it could check if it is coming from somewhere in /usr that is also not writable by the current user.

            • argv_minus_one@beehaw.org
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              10 months ago

              The display server has no way of verifying the process ID on the other end of the Unix-domain socket connection, and therefore cannot verify the executable image. It also cannot verify that the settings app hasn’t had any malicious code injected with ptrace, LD_PRELOAD, or the like, since the injected code can remove any traces of that before connecting to the display server.