On Thu, Nov 13, 2014 at 2:41 PM, Cathal Garvey <[1]cathalgarvey@cathalgarvey.me> wrote: Oh, for sure Moxie has a threat model that makes sense to him, but I dispute that it makes any sense in the real world. Google's certificate system is TOFU, so whatever certificate Google pushes to a users' device is what that device trusts updates from thenceforth. And, there's no obvious way for an Android user to verify a certificate *even if they were so inclined*. For my part, as an Android user with a knowledge of and interest in crypto, I have *never* checked a signed APK. Ever. So, if even the more technical end of Moxie's customer base don't check APK signatures, and if most people simply take what Google Play offers them, what's to stop Google pushing a malicious TextSecure? Nothing. Nothing, at all, ever. And all the machinations and air-gaps Moxie and co implement are meaningless, because the TOFU scheme makes Google the root of all trust on the Google Play market. This isn't accurate, in practice. In theory, Google could replace any certificate they want for first use. But they clearly don't do that for everyone (Moxie or someone would notice), and if they did it in a targeted way, it could only be on the first use. That's a threat vector, but only viable under both targeted and specific circumstances. So "what's to stop Google pushing a malicious TextSecure? Nothing. Nothing, at all, ever." isn't accurate -- you can trust that you're highly likely to get the real TS binary on first install, and then guarantee that you're getting a binary signed by the same person for updates. This is why Moxie uses TOFU for the TextSecure threat model itself. Yes, if someone MITMs you and your friend the first time you talk, you're compromised from then on, but in practice that's rare and difficult. If it were merely about certificates, Moxie would offer up-to-date APKs through his own website and F-Droid repository, allowing him to have utter control over timely updates without an intermediate trusted agent. He clearly doesn't think much of F-Droid's build process, especially that they don't keep the build and signing process fully offline. I think that was generally his principal objection there. There's a more general complaint he's raised as well, which covers the case of hosting the APK on his own site, which is that (in his opinion) the worst thing you can ask non-savvy users to do is check the box that says "Allow unknown sources". I'm pretty sympathetic to this point of view, for the general class of user. And it's the general class of user that Moxie's interested in making inroads on with TextSecure. Interestingly, I saw this malware alert today that addresses two of the issues here: [2]https://www.us-cert.gov/ncas/alerts/TA14-317A The malware only affects people who download it from an unknown source, *and* it's helped by the fact that apparently iOS does not enforce matching certificates on app upgrades with the same bundle identifier. Apple's depending on their App Store walled garden -- and the phone's lack of a built-in "allow unknown sources" option for security. In a sense, Google's allowing users to opt-in to the "unknown sources" option, even when it raises a user's security risk, forces Google to provide stronger security guarantees even for users who have that enabled. But of course, that only addresses replacement of an existing app. As you say, Android is TOFU for apps, so having "unknown sources" on means a user is vulnerable to new app malware. I feel like there's been a big mindset shift in the security community about controlled app update vectors. I know Google feels extremely strongly that auto-updating through a secure channel (with pinned keys) is the way to go with Chrome. Both in terms of ensuring that the app is only the one Google built and signed, and in the overall security benefit of not having people lag behind on older browsers for 10 years. I've really been enjoying (seriously) @SwiftOnSecurity on Twitter, and she had a really interesting post on what security means for the general class of people. It was very depressing, but also points to the direction we need to go: [3]http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jes sica But he doesn't, and when I asked I finally got an answer: It's because F-Droid doesn't offer metrics, debugging, and analytics. Essentially, he wants Google play so he can get silent feedback on what the Apps are doing in the wild. He's also expressed openness to a third-party replacement for this functionality. It's not impossible to do that, but a high quality open source replacement needs to be built first. Google Analytics has an Android SDK, but it is closed-source. This is the same issue as Google Cloud Messaging: the requirements are high, but an alternative is welcome. I do wonder how he's managing analytics on the CyanogenMod pre-install -- I'd guess CyanogenMod has their own analytics infrastructure he's piggy-backing on. I don't object to this as long as it's opt-in for users, but I do object that it's being presented as something (threat model) rather than developer convenience. I believe it's being presented as both a threat model, and a set of feature requirements. I wouldn't call needing device analytics just "convenience" -- for a large-scale Android app, it's essentially mandatory. I managed a smaller-scale, but modestly successful, Android app called "Congress" for 4+ years at my last job, and analytics were vital in fixing arcane bugs, identifying when legacy features could be dropped in favor of faster and more secure replacements, and overall feature planning. I love TextSecure, and I'm grateful to Moxie and co for creating it. It lets me layer security on a legacy platform that everyone uses in a way that's transparent and extremely user-friendly, while offering security granularity for those so inclined (cert checks). But the delivery is through an intermediary that are essentially a public-facing wing of the NSA, and they have total control over the trust/threat model for 95% of the user-base. So..I don't even. I think it's crucial to establish independence from Google to the greatest extent possible. "public-facing wing of the NSA" is IMO too strong, but even putting that aside, TOFU doesn't grant them "total control" over the trust/threat model for their user base. Certs and TOFU on Android is auditable, and that does put a leash on what Google is capable of doing without being caught. -- Eric On 13/11/14 17:51, Eric Mill wrote: Moxie's laid out very clear reasons for why he uses Google Play and discourages other people from building it. You may not agree with him, but he at least has what I think is a coherent security model that he's sticking to. Really great discussion on it here: [4]https://github.com/whispersystems/textsecure/issues/53 [5]https://github.com/whispersystems/textsecure/issues/127 Namely, he trusts apps signed with his signature (a process he manages using his own airgapped system) and that's it. *You* may not hinge your trust of the application on his signature, but he does, and he wants ideally every TextSecure install to have it. Both threads above are from before the CyanogenMod deal. To make that happen, Moxie's team built a secure self-update path for the app, which removed most of the barriers to requiring Google Play. The other main barrier is push delivery, which right now uses Google Cloud Messaging. High quality push delivery to a kabillion devices is very hard, and not easy to replace. However, Moxie has encouraged people to take advantage of the server's WebSockets support, and to build an option for that into the client if they want to remove the last barrier to Google support -- while warning that WebSockets delivery will not be nearly as good as GCM-based delivery. I was talking with a friend about this over the weekend, and I think that the push that's happening for fully reproducible builds -- where every build produces an identical binary with an identical hash -- would resolve some of the issues Moxie has. Then, Moxie can sign the hash of the binary, and others who build the source code or get binaries from other places can verify that hash. That still requires some tooling or verification UX, and for builds to be reproducible by other people than Moxie, but it could make a difference. -- Eric On Thu, Nov 13, 2014 at 6:12 AM, Cathal Garvey <[6]cathalgarvey@cathalgarvey.me > wrote: Nope, I haven't had to install Play for Textsecure at all, and I don't use or have a personal Google account. When it offers to set up data channel, just skip it, and TS reverts to encrypting over SMS instead. Redphone also has a "no google" mode where it announces incoming calls to other RP users with a simultaneous SMS, but I've found it to be very buggy in my builds; calls connect but no sound transmitted, etc. As far as "where to get it", here's a copy: [8]https://ngrok.com:61924/__owncloud/public.php?service=__files&t=_ _264659e23e8733b528386eaa6f52d5__ef <[9]https://ngrok.com:61924/owncloud/public.php?service=files&t=2646 59e23e8733b528386eaa6f52d5ef> Cert is self-signed: SHA1: 63:9B:E2:FA:D8:A9:66:DE:46:B7:__E4:C2:18:47:73:04:C0:12:FE:1F SHA256: CF:D2:82:0D:C8:65:CE:EB:2E:3F:__36:EC:DA:9E:82:4E:2E:BD:51:19:__6A:7 E:11:65:50:40:57:9E:B8:79:__8D:A2 This is an older build by now. Frankly I'm holding out for a JS build of Textsecure and I'll probably try FFOS, then. FDroid and Textsecure are my "killer apps" tying me to Android. I just wish Moxie would let them play nice together. On 12/11/14 23:13, Seth wrote: On Wed, 12 Nov 2014 14:29:04 -0800, <[10]bluelotus@openmailbox.org > wrote: Where can TextSecure be downloaded? Best workaround I've found so far if you want to download Google Play APKs on your computer and then transfer them to your phone manually is Raccoon: [12]http://www.onyxbits.de/raccoon Requires java along with a 'dummy' Google account, but gets the job done with the least amount of hassle. Unfortunately, it appears that TextSecure still requires the Google Services framework to be installed and running on the Android device. Haven't figured out yet how to do this manually this without installing Google Play. Also, FWIW, you can (or at least you used to be able to) manually remove a Google account from an Android phone without having to factory reset the device. [13]http://www.sleetherz.com/__android-news/how-to-change-__gmail-ac count-on-android-__market-without-factory-reset/__2511/ <[14]http://www.sleetherz.com/android-news/how-to-change-gmail-accou nt-on-android-market-without-factory-reset/2511/> -- [15]konklone.com <[16]https://konklone.com> | @konklone <[17]https://twitter.com/konklone> -- [18]konklone.com | [19]@konklone References 1. mailto:cathalgarvey@cathalgarvey.me 2. https://www.us-cert.gov/ncas/alerts/TA14-317A 3. http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jessica 4. https://github.com/whispersystems/textsecure/issues/53 5. https://github.com/whispersystems/textsecure/issues/127 6. mailto:cathalgarvey@cathalgarvey.me 7. mailto:cathalgarvey@cathalgarvey.me 8. https://ngrok.com:61924/__owncloud/public.php?service=__files&t=__264659e23e8733b528386eaa6f52d5__ef 9. https://ngrok.com:61924/owncloud/public.php?service=files&t=264659e23e8733b528386eaa6f52d5ef 10. mailto:bluelotus@openmailbox.org 11. mailto:bluelotus@openmailbox.org 12. http://www.onyxbits.de/raccoon 13. http://www.sleetherz.com/__android-news/how-to-change-__gmail-account-on-android-__market-without-factory-reset/__2511/ 14. http://www.sleetherz.com/android-news/how-to-change-gmail-account-on-android-market-without-factory-reset/2511/ 15. http://konklone.com/ 16. https://konklone.com/ 17. https://twitter.com/konklone 18. https://konklone.com/ 19. https://twitter.com/konklone