Now that iOS and Android are approaching technical maturity, new updates to these operating systems no longer feel revolutionary. The new stuff we get every year is boiling down to smarter notification handling, under-the-hood upgrades, screen notch adaptations, and “borrowing†good ideas from one another. As Google prepares to take the wraps off its next big iteration, Android P, at Google I/O 2018, I have an idea for an alliterative theme: make it Android P for Privacy.
Fully agreed with Vlad Savov. Sadly, the lack of encryption in Google’s new chat feature doesn’t bode well.
Why don’t you think before going on a rant? Why don’t you read responses of people that obviously taken a few seconds to read, understand and reply?
If SMS is to be replaced with a new protocol better suitable to modern use then it is an SMS replacement.
An SMS replacement intended to be used globally, transparently. Without managing users, without managing passwords. Something that means an South African user can send a message to a Indian user and it just works.
HOW THE HELL WOULD A STANDARD LOW COMPLEXITY SMS++ SHOEHORN IN END-TO-END ENCRYPTION?
Do you understand how that works? That’s a rhetorical question – you obviously do not.
Megol,
PKI seems like a good start, where a user’s public key could be published and used globally for the purposes of SMS++ encryption. In order to reduce the risk of compromised directories, redundant directories under separate legal jurisdictions could decrease the dependence on any single actor(*).
Admittedly the telephone system is a lousy foundation to build on, I would strongly prefer a model where users are not dependent upon the telephone carriers to resolve their identity. Taking them out of the loop is technically feasible and would help improve security, but it may not be politically feasible given google’s goal of getting carriers on board. To me, this seems like the primary dilemma with regards to making SMS++ more secure.
* This is the problem with apple’s approach. End to end crypto is great, but so long as apple retains exclusive control of the directory, then apple technically dictates the security keys used to encrypt private messages. For better or worse, this means apple has a wiretapping capability. The way to fix this is to share the responsibility with other parties to maintain the authenticity of the PKI directory.
Edited 2018-05-08 18:46 UTC
Not sure how Apple’s messages works, but its possible to facilitate E2E encryption without having to introduce an all powerful eavesdropper. Signal works.
See the wiki on their protocol:
https://en.wikipedia.org/wiki/Signal_Protocol
Its the recommended solution right now for secure communication. I am not in need of a solution, nor could I convince anyone to communicate with me on the service, but thats what *should* be used on a technical level.
On a practical level? I’m kind of torn. I’d like law enforcement to be able to do its job. However, they themselves can’t always be trusted to do the right thing(tm) depending on the circumstance. So I don’t mind that not everything is encrypted. Its probably easier just to hack your unpatched android phone.
Bill Shooter of Bul,
I suppose it depends how much you value your right to privacy.
If you need wiretapping for law enforcement, then perhaps companies should implement crypto where wiretapping is auditable. The worst of the abuses are when wiretapping occurs AND there’s no accountability because the policy of authorities such as the NSA is simply to lie about it.
As is, individuals aren’t allowed to sue the government in court because the burden of proof is on us to prove we were wiretapped. There’s no way to sue the government for breaches of privacy that you can’t prove. However there are things that we could engineer into the system such that wiretapping would generate an audit record, which would constitute as proof of the wiretap. To exist in a robust way, such a system would have to span jurisdictions such that multiple parties are willing and able to keep the other sides in check.
Instead of chastising Thom, we need to open the discussion to the reasons why google’s solution does or does not fall short.
No,we don’t. Those like Thom need to told that the first step of any any form of “security” is using your brain first.
*YOU DO NOT DISCUSS ANY THING YOU MAY CONSIDER SENSITIVE VIA THESE KINDS OF APPS,PERIOD*.
Umm, we already have end-to-end encrypted SMS on Android: https://silence.im/
Licaon Kter,
That page is extremely lacking in details. But it appears to be an encryption app that uses SMS as a transport layer. It reminds me of PGP for email. The trouble with this model is that while it does secure the contents, it requires people to install a non standard messaging client, which is not something most people are interested in.
Reminds me of how the reporter who leaked the snowden documents thought the crypto was a bother when snowden tried to make contact with him. People just want to go about their lives without sacrificing accessibility and convenience. I think the lesson is that for crypto to be successful, it needs to be included/supported in the protocol by default, otherwise people will not bother.
It uses the same e2ee protocol that Signal or OMEMO (over XMPP in Conversations) does, but over SMS.
It’s not bothersome whatsoever, just toggle a switch and you’re encrypted (well, if the other party has Silence of course).
Edited 2018-05-11 22:39 UTC
Let me explain some thing about “Google”‘s messaging. It’s not Google. It’s not even new. I worked on that (including preparing some standards) a few years ago. Google simply embraced it finally, because before that, every vendor and telecom offered their own RCS implementations. On top of that, RCS is only an implementation of chat on plain old SIP protocol (the one for VoIP phone calls).
The idea of RCS is “a new SMS”, not “a new Telegram” or “Apple iMessages”, because in LTE networks there are no infrastructure for current SMS implementation (or traditional voice calls by the way, LTE is all about internet). It has some features not available in SMS like group chats or rich messages (in MMS they’re delivered in quite convoluted way), but many of them depends on operator-provided servers (while basic messaging is — or rather “should be” — P2P).
By the way, our “innovation” group worked on message encryption in RCS and even SMS, using quite “paranoid” scenario (the keys could be shared using NFC to avoid eavesdroping). But the telecoms weren’t interested. So, no surprise Google is not doing that too.
RCS is mainly an operator solution. They drive the standard, and a “reference implementation” is in fact a solution provided by some operator — and standards are mostly about confirming status quo. Google simply added it as a part of the stack, not even sure if they’ve written it, or get as a contribution from some telecom.
As for Apple, there are RCS clients for iOS too. We worked for clients on Symbian and Windows Phone too (both historical curiosities now), and even some desktop solution and session sharing between them. If all will go to LTE, Apple will need to provide their own RCS implementation (maybe inside iMessage) because it’s a GSMa standard.
jima,
How do you feel about google promoting the RCS chat service as is without crypto? It could become the standard protocol for the next couple decades. It could be too late already, but if google won’t push the issue, then it seems unlikely that anyone else with any influence will.