1. 24
  1. 14

    Easier way to eavesdrop on Signal users : ask Google to send them a modified apk and update it silently (which android can do for Google Play apps). Or update signal from signal’s own update mechanism.

    Those huge weak points only exist because of signal’s insistence on not allowing open source builds to be distributed.

    1. 10

      It’s worse yet than “if google uploaded a poison APK”

      Google’s keyboard “GBoard” communicates with the internet for various reasons. You don’t need to poison a fake APK - you can spy on the keyboard directly.

      And it has rudimentary ML capacity since it can and will correct words that you type previously.

      1. 1

        That’s why I use simple keyboard.

        1. 3

          Absolutely true that you can install different keyboards - however the defaults always retain a significant amount of power.

          And Signal’s messaging is poor here as well. They never mention anything about GBoard and its ability to spy on every character you type and substitute. Using Signal with defaults can get you taken for a black van ride, if you’re not careful.

          1. 6

            Isn’t the point of signal to make mass surveillance too expensive via rock solid E2E for the masses? You don’t get a van ride if someone isn’t already seriously invested in your messages since mass interception is too difficult using the above methods. Your phone could just as easily be attacked by any other software attack surface. E2E encryption doesn’t solve device/OS level security problems.

            1. 4

              Really. A black van ride. I mean your not wrong but this escalated pretty quickly to “Signal is responsible for my abduction by not communicating that the dangerous GBoard is Google’s default in smart phones.”

              1. 1

                It’s certainly the outlier, but has happened. And it primarily happens with whistleblowers and similar leak-to-news-agencies.

                And Naomi Wu (RealSexyCyborg) in China has reported similar with dissident friends who were black-bagged after talking about sensitive stuff on Signal.

                Doing usual sensitive stuff like sexting or getting passwords isn’t going to have any real ramifications. But if you involve reporters or dissidents, your phone wont protect you.

        2. 7

          Easier way to eavesdrop on Signal users : ask Google to send them a modified apk and update it silently (which android can do for Google Play apps).

          I think Google can’t do that, if Signal signs its app itself. (See android.com: Manage your own signing key) In this case Google could only give you a different app with the same name if it’s the initial installation of the app. But for updates this wouldn’t work. Also this would sooner or later be detected by the public since the signature can be compared manually after the fact.

          Also you can download the APK directly from Signal.org. This way you still have to trust Signal and its TLS CA. The APK updates itself from then on (as far as I know). While the underlying OS is still Android from Google or iOS from Apple, IMO it gets silly to focus on Signal in that regard.

          I’m happy that Signal exists and that it has the potential to appeal to the masses while providing the technical means to shield (legally acting) businesses from exploiting the chat data. Of course any improvement is welcome no the less.

          1. 3

            Who knows with Google, these days? They are known to force-install apps without notification or consent: https://news.ycombinator.com/item?id=27558500

            1. 3

              Who checks the signature of the app you’re running? It seems like it’d be pretty easy to have Android not check the signature on startup, if you’re considering Google acting against the user.

              1. 2

                If we go full paranoia: theoretically there is a possibility that the Google Play app installer service could secretly circumvent the whole “updates-with-same-certificate” model by e.g. replacing the cert in the package manager’s database, right? (Assuming Play has parts running as root which I think it did?)

                1. 2

                  Even on rooted devices, a changed certificate will cause the device to first uninstall (and remove all associated data) the existing app.

                  If we assume Google is going to be complicit in a surveillance measure in the future, they will have had to add a covert option for the OS to not do that in the past.

                  But if we assume Google to be complicit, all bets are off anyways and you should probably side-load Signal to begin with. And replace the phone OS with one you built yourself after auditing all of its Millions lines of code

              2. 3

                Or update signal from signal’s own update mechanism.

                That would require you to have Signal’s signing keys which I hope live in some HSM and which require manual physical interaction to make use of

                ask Google to send them a modified apk and update it silently

                This would work, but only for fresh installs. The system refuses to update an installed apk with one that’s signed by different keys.

                You can force the install, but it will first uninstall the existing application with all of its data

                1. 1

                  Those huge weak points only exist because of signal’s insistence on not allowing open source builds to be distributed.

                  Ironically, this insistence means that on Linux the only installation is via their third party apt repository rather than from an official distribution package source. It’s the exact opposite on Android, where the only installation is from Google, the “official” Android distribution package source. This is exactly the wrong way round to how I’d like it because in both cases more trusted sources are available.

                2. 5

                  Ignoring all the other problems the fact that the verification options are on purpose hidden in the UI is extremely harmful and I’ve been ranting about it for years. Instead they should make this a prominent feature and also make it easier to verify someone by using a trusted 3rd party that you both verified. On top of that the verification number is not a real hash - it is imperative to check the entire number and not just the beginning or the end of it as far as I can tell which obviously is a huge problem since personally I just checked the first couple of groups of numbers before I learned that they can stay the same. I think this is a serious problem as well.

                  1. 5

                    The reason some stay the same is because the safety numbers are just a concatenation of your hash and the other party’s, so the overall number is the same on both devices. That simplifies the UX because users have to do one comparison that works both ways instead of two that work one way. Clearly though the fact that you made this mistake means there’s more work needed to improve the UX.

                    I do think the QR code scanning helps a lot with that, if you can use it.

                    1. 2

                      Either way you can make this a single comparison for example by always appending a larger number to a smaller number before hashing them. This is not an argument.