It is still on the HN new feed, if folks want to discuss technical details, but the reason I want to mention it here too is that key management is very hard in a case of resisting surveillance. The current PKI ideas place too much trust in third party certificate authorities (meaning the government can easily pull off man in the middle attacks with the help of network providers if they want, even without your keys), and because each negotiation occurs without context of past ones, there is no way to detect such behavior other than "the CA said watch out" or "this certificate isn't even plausible." Of course you can solve these by enforcing that everyone on your network uses th same local CA that you control but that breaks as soon as you want to talk to someone outside.
Building a PKI that can resist such efforts is not trivial and it involves challenging our assumptions. Until we do so however, we will run into all kinds of problem. I may be being paranoid, but it seems like this is a good time to be paranoid.
One of the things that SSH gets right is that it takes a diachronic approach to key validation. We should be building this in everywhere and alerting on key changes, while providing a way to ensure that keys can be safely and securely changed without having errors.
I remember the time, about 6 or 7 years ago when I've asked in front of the whole class to the associate professor of the security course, whether building a text messages encryption app would have been a good idea as project for the course. The answer was a smickering "only a drug dealer would be interested in such a thing".
oh man, that hurt... if I only knew a valid point against the "I've got nothing to hide" argument as I do now...
How about something like this for the grandparent's case:
"In some countries people can be persecuted for their religious beliefs, politics or sexuality. Their text messages could potentially reveal all of the above to the government and/or someone listening in on GSM traffic [1]. Those people could use an SMS encryption app to provide them with plausible deniability or, should their local law doesn't have that notion, at least help them avoid automatic keyword detection."
The problem seems to be, to me it's so obvious that it matters even if you have "nothing to hide", that whenever someone confronts me with that argument I'm a bit dumbfounded :)
Read these "Bugs, Caveats, Side Notes" published on the Onion Browser app's web site:
Major iOS SDK Limitation: Websites using HTML5 <video> tags will leak <video>-related DNS queries and data transfer outside of Tor. This includes YouTube, Vimeo, and any website using iOS-compatible HTML5 video. This is a behavior of the embedded QuickTime player and there is currently no known workaround. (h/t to josyw.)
iOS SDK Limitation: Javascript cannot be disabled in the `UIWebView`, so script-based detection may identify your device even if User-Agent Spoofing is enabled.
iOS SDK Limitation: Related to above, the HTML5 Geolocation API cannot be disabled. The browser will ask you for permission to access your location if a website asks for it via the HTML5 Geolocation API. If you allow this, then said website will (obviously) know your actual current location.
Sadly, TextSecure and RedPhone are distributed on the Google Play platform, so, if you don't want to tie a Google account to your phone or use Android without the proprietary Google applications, you're out of luck. (They are not included in the free and open source f-droid repository due to disagreements with the author.)
You should be able to find the apps on other sources, and the nice thing about Android (and the "old" Windows) is that you can still install apps from other sources. That's becoming less and less the case with other operating systems, though.
We don't distribute our apps on f-droid because we feel it's insecure, and because it doesn't provide the features we need to develop stable and secure software.
However, we are willing to distribute our apps outside of the Play Store, but we need the following things first:
* A built in crash reporting solution with a web interface that allows us to visualize crashes and sort by app version, device type, etc. This is essential for producing stable software.
* A built in statistics gathering solution with a web interface that allows us to visualize aggregate numbers on device type, android version, and carriers for our users. This has been crucial in shaping support and development direction.
* A built in auto-update solution. Fully automatic upgrades won't be possible outside of Play Store, but we at least need something that will annoy the hell out of users until they upgrade. This is necessary for ensuring that new security features and bug fixes can be propagated quickly.
* A build system that allows us to easily turn these features on and off for Play and non-Play builds. Gradle should make this easier.
If you're interested in seeing Open Whisper Systems apps distributed outside of the Play Store, we'd welcome your contributions.
Speaking as a developer who's app is both on Google Play and on f-droid, I somehow share your feeling about f-droid being "insecure"(x), but consider all of the other points very thin.
Crash reports and statistics are great, except if you explicitly want to NOT spy on your users.
Auto-updates are ok, but forced auto-updates take the user's autonomy away, and are only one step short of forced remote uninstalls (which are already documented with Google Play, so far only for malware).
A proper build system is great indeed, but has nothing to do with the distribution medium.
(x) f-droid security: by having f-droid build all the apps from source by default, and signing them with their own keys, two problems appear:
a) you can not switch easily between f-droid builds and maintainer builds
b) you as the user need to trust both the author and f-droid to not be evil, instead of just the author.
If they have an IMEI, camera, microphone, GPS, all the contents of your text messages, all your phone calls, all your mobile web browsing (this is the purpose of a cell carrier, no?) do you think it really matters if they have your Google account?
If you have an Android phone, I'd recommend getting an Open Source ROM (so you can verify it is secure) and removing as much proprietary software as possible. I'd also use Firefox as Chrome for Android isn't Open Source (even though Chromium, Blink, etc are).
This suggestion comes up a lot, and yet isn't practical. I can read and write code, like many, but haven't the time or inclination (and arguably skill) to "verify it is secure". I can however watch what an app sends over the wire, which applies as much to proprietary as it does to open source software.
How do you go about verifying an arbitrary app is secure?
You can trust that there are a lot more developer eyes on open source software than proprietary software. You personally may not be able to verify every piece of software you have, but if you run free/open software, you know it's theoretically possible to discover vulnerabilities, and that you'll find out eventually if those security holes are found. In the worst case, you can hire a security professional to personally audit a program that is particularly important to you or your business.
I realise that I'm risking being contrary, but my question is serious.
How would I know that an app has had lots of developer eyes on it or not? It's crazy difficult to uncover the latest known security posture of open source software.
Finding out eventually is the exact same risk I take when I use proprietary software. It requires my trust. And it's theoretically just as possible to discover vulnerabilities in closed-source software (Windows, for example).
You really trust a custom compiled version of Android from "1337haxor2" which has auto-update capabilities built in?
The easier way would be to monitor network traffic. If random encrypted information is uploaded, then block it, whether or not you have an "open source" rom.
Better yet, just get a Nexus device without the carrier apps pre-installed. Stock Android does not have a "upload all data to the NSA" feature built in, it would be easily discovered and would be the biggest news story of the decade.
Unless you are the NSA, then I wouldn't advise using a custom version of Android, you'd likely be much less secure than with a stock (and up to date) version.
Bitmessage is specially interesting because it's not only encrypted and private, it actually solves the problem of spam and offers 3 kinds of messaging under the same interface: email-like, broadcast messages ala Twitter and chan boards.
I think the real question should be is there possibly a back door on your mobile os of choice, because it won't matter what app you use if your os is already capable of capturing that data system wide.
A secure text messaging app I like and use is Threema (http://threema.ch/en/index.html). All servers are allegedly located in switzerland. The app uses public-private-key end-to-end encryption.
You can exchange keys locally via QR code and it is available for both Android and iOS.
You can still sync your phonebook in whatsapp style. It's a good compromise between being secure and being pragmatic to me.
However, it's not open source, so you still have to trust the app (and the OS) not to send out your private key.
If you're jailbroken (which you probably should consider if privacy is a concern), FirewallIP is the reason I still haven't switched to Android: http://yllier.webs.com/firewall.html
Can you expand on why one should jailbreak? Any other jailbroken app suggestions? I was under the impression that jailbreaking also opened you up to be hacked and made the phone less secure.
That's unfortunately the problem. We want to make secure software easier to use but we can't get past step 1 if people can't just buy it from the app store.
ChatSecure and IM+ both support OTR instant-messaging on the iphone, so depending on what you mean by "like that"... yes. ChatSecure is opensource too fwiw: https://github.com/chrisballinger/Off-the-Record-iOS
Claims that keys are stored locally and not sent to their network. Applications not open source, no way for anybody anywhere to verify such claims.
These are for paranoids, paranoids may not be able to read the source code and verify such things, but the fact the at least someone can certainly helps.
It is still on the HN new feed, if folks want to discuss technical details, but the reason I want to mention it here too is that key management is very hard in a case of resisting surveillance. The current PKI ideas place too much trust in third party certificate authorities (meaning the government can easily pull off man in the middle attacks with the help of network providers if they want, even without your keys), and because each negotiation occurs without context of past ones, there is no way to detect such behavior other than "the CA said watch out" or "this certificate isn't even plausible." Of course you can solve these by enforcing that everyone on your network uses th same local CA that you control but that breaks as soon as you want to talk to someone outside.
Building a PKI that can resist such efforts is not trivial and it involves challenging our assumptions. Until we do so however, we will run into all kinds of problem. I may be being paranoid, but it seems like this is a good time to be paranoid.
One of the things that SSH gets right is that it takes a diachronic approach to key validation. We should be building this in everywhere and alerting on key changes, while providing a way to ensure that keys can be safely and securely changed without having errors.