Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

>[...] non-technical users to get Signal from a source that is substantially less secure than the Google Play App Store.

F-Droid has signed apps.

>[...] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.

Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?). It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.

View on HN

> F-Droid has signed apps.

If I'm remembering the discussion correctly [0], at the time that Moxie felt that distribution by F-Droid was entirely unsuitable because of -among other things- their insecure code signing key handling practices. Remember that Moxie's target audience is everyone, not just technical users. I elaborate on this point in a couple of my other comments in the sub-threads.

> Google is a known collaborator with three letter agencies...

People say this. I contrast it with the fact that Google now configures its US datacenters (and the links between them) as if they were sited in hostile nations such as China. Switching from the "friendly nation" configuration to the "hostile nation" configuration was a crash project after the Snowden revelations. The project was not cheap. The situation on the ground is -always- more nuanced than can be expressed in a soundbite.

> It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.

* Can you point to a reliable, credible source that has analysed Google Play Services and determined that they are spyware, by any reasonable definition?

* As I mentioned in other comments in this thread, Moxie is not opposed to either distribution in non-Google App Stores, nor is he opposed to replacing the use of GCM (AFAIK, the only part of GPS that Signal uses) with Websockets. However, any replacement must be at least as secure and functional as what it replaces. Check my other comments in the subthreads for more information.

[0] And I may not be, it's goddamn late.

> Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?)

The SSL diagram indicates not Google's participation; it shows that NSA was wiretapping their datacenters without their knowledge. PRISM indicates Google collaboration, though.

But see, the presence of Google Play in your phone does not magically allow Google or NSA to listen to Signal conversations.

The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.

>The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.

I'm not sure how familiar you are with Google Play Services, but it's designed to do exactly this. It's what Google came up with when they got fed up with OEMs failing to distribute newer versions of their things to end users. It can silently install updates and has access to almost every permission on your phone, and cannot be removed.

> I'm not sure how familiar you are with Google Play Services, but it's designed to [permit Google to silently update any application on the phone].

Unless Google also deactivates signature verification for the originally-not-signed-by-Google app that it pushes to the target's phone, the design of both Android and the Android Market make this impossible. You can't silently update an app signed with one key with an app signed with a different key.

If -however- you're talking about Google installing software that snoops on the conversation between the Signal software and Signal servers, then -in that case- Google gets nothing that any other adversary that has access to at least one node between those two points gets... namely, undecryptable cyphertext.

If you're trying to make the stronger claim that Google inserts special code (that they don't include in AOSP) that they use to read the unencrypted data of interest from RAM and transmit to their servers, then I reply:

"All modern computers -including Apple devices- suffer from this class of problem. You have to trust everyone who wrote kernelspace code loaded into your system, the OS authors, the people who put the boards in your computer into their housing, and the folks who made the boards and chips to begin with. This is a hard problem. Frankly, Google's solution to this problem is just about the best consumer-level solution in the industry, and keeps getting better as time goes on."

Ugh. Sorry, "Google gets nothing that ... gets" should read: "Google gets nothing that ... wouldn't also get". <---This is why you shouldn't comment while dead tired! :(

Reply on news.ycombinator.com