Google's Rollout of RCS Chat for all Android Users in the US Begins Today (theverge.com) 84
Google is announcing that today, a year and a half after it first unveiled RCS chat as Android's primary texting platform, it is actually making RCS chat Android's primary texting platform. That's because it is rolling out availability to any Android user in the US who wants to use it, starting today. From a report: RCS stands for "rich communication services," and it's the successor to SMS. Like other texting services, it supports read receipts, typing indicators, improved group chats, and high-quality images. Unlike several texting apps, like iMessage or Signal, it does not offer end-to-end encryption as an option. RCS is based on your phone number, so when you are texting with somebody who also has it, it should just turn on automatically in your chat. To get RCS, you simply need to use Android Messages as your default texting app on your Android phone. Many Android phones do that already by default, but Samsung users will need to head to the Google Play Store to download it and then switch to it as their default. Further reading: The Four Major Carriers Finally Agree To Replace SMS With a New RCS Standard.
No blue bubbles? (Score:1)
No blue bubbles?
NO SALE.
Does lack of security even matter... (Score:2)
I'm not sure the lack of security will matter at all to the general populace, who just wants a messaging system that works well.
We'll see how it fares, it seems like Google has done about everything it could have to try and get people to adopt and use it (from carrier to phone maker support).
Re: (Score:1, Flamebait)
Anyone who trusts that a closed source/system is encrypting end to end isn't too bright. Yes, that includes iMessage. The idea that people still believe that iMessage is end-to-end encrypted is shocking to me. When will people learn?
Re: (Score:1, Insightful)
It is funny that I keep getting modded down when I point out that no one has ANY IDEA what a closed source/system is doing. What possible argument would refute anything I am saying? It comes down to "trust Apple".
Re: (Score:1)
Re: (Score:1, Insightful)
You can write anything you want in your "documentation". I mean how naive are you people? If the government/whoever wants your iMessages you don't think Apple will hand them over? Wow. I thought we were beyond this level of naivete, but I guess not.
Re: (Score:2, Troll)
Paranoia is no replacement for facts.
Every little "wanna be famous for a minute" idiot out there who had proof would have been yelling it from the tree tops by now if Apple had lied. But all I hear is conspiracy theories and crickets
Re: (Score:2)
Implementation (Score:2)
Apple can't hand anything over, they do not have the encryption keys...
IFF their actual implementation matches the documentation.
They could be telling everyone that they implement proper end-2-end encryption, but forget to mention that there's a built-int leak channel/back-door/whatever.
Though in *that* case they couldn't successfully manage to avoid being forced by a court to hand out information.
Though in *this later case*, "Parallel construction" could be invoked : Apple only pretends they don't have the key publicly. In secret, they have the encryption keys because they se
Re: (Score:2)
Think of it this way, if there was a Steak Restaurant that said it only sold the best US prime beef and was found out to be selling dog meat from China how long do you think it would last.
So no, your wild speculation is worthless because it based entirely on paranoid delusions with no basis in fact.
OR, as we are in conspiracy mode, you are being paid to shill anti Apple rhetoric
Re: (Score:2)
Actually, as current politics show, the restaurant just has to deny it and their fan base will believe them over some elite scientist who is probably on the payroll of some opposing restaurant.
Re: (Score:2)
It doesn't matter, they'll cancel it within 3 months anyways.
Re: (Score:1, Offtopic)
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
Oh man, you're hilarious. You probably even believe that.
You misspelled Signal! (Score:1)
WhatsCrap IS the fat/lazy American edition!
Re: (Score:2)
In other words, if I have one app, and you have another, can we chat, or do we need to arm wrestle to see who looses and has to install another chat app on the phone to talk with each other?
What happens when you have 3-4 chat apps on your phone a
Carrier has to support it too. (Score:3)
As of this writing, my carrier (Cricket, owned by AT&T) apparently does not support it.
Re: (Score:2)
Re: (Score:2)
Google is just making it possible to turn on now.
Well, there's nothing visible in Messages, on my Nokia 6.1, that suggests I can bypass that message. Perhaps there's an update to Messages that is being rolled out slowly, and I haven't got it yet.
Re:Carrier has to support it too. (Score:5, Informative)
Ah, buried in comments from TFA:
Re:Carrier has to support it too. (Score:4)
Article claims they do (Score:3)
Carrier doesn't have to support it. That's the whole point
The "whole point" is to replace SMS.
The article claims that RCS will only be used if the carrier both sides are on supports it.
You might be thinking of other Google messaging platforms that are more like WhatsApp, which indeed do not need carrier support.
Re:Article claims they do (Score:4)
I don't see anywhere in the article where it says both carriers need to support it. In fact, I see the opposite being claimed.
Re: (Score:2)
As I wrote elsewhere in this thread:
So, the version of Messages currently on my Nokia is as yet unaware of Google's noble intention to do an end-run around my carrier's slowpokeness. I shall wait.
Why not end-to-end encryption? (Score:5, Interesting)
Apple has shown, through iMessage, that it doesn't have to be hard for the end user... heck, the user doesn't even have to think about it. I'm not sure most users even know what the blue bubble (iMessage) and the green bubble (SMS) mean, other than "green means not an iPhone user".
Google has a lot of bright boys and girls working for them who could figure this out - it's hard to see this as anything but a deliberate choice.
Re:Why not end-to-end encryption? (Score:5, Informative)
Apple does key escrow, so it's only e2e in the most strict sense. There's not always a MitM but there could be at any time and you'd never know.
Some will bleat "lawful intercept" but ask the Uyghurs about that.
Re: (Score:2)
I would, but I'm not sure how to pronounce "Uyghurs" so I'll refrain from asking.
Re: (Score:2)
It's just another example of Google offering the freedom of choice while Apple offers only a walled garden. Does iMessage even give you the option of not encrypting your messages? I don't think so. So the implementation of RCS for Android offers users a clear choice, in case they don't want to be trapped in Apple's secure walled garden with all its privacy and stuff.
Re: (Score:2)
Oh, VERY well played sir!
Re: (Score:3)
Apple has shown, through iMessage, that it doesn't have to be hard for the end user... heck, the user doesn't even have to think about it. I'm not sure most users even know what the blue bubble (iMessage) and the green bubble (SMS) mean, other than "green means not an iPhone user".
Google has a lot of bright boys and girls working for them who could figure this out - it's hard to see this as anything but a deliberate choice.
I explained the issues/challenges here: https://tech.slashdot.org/comm... [slashdot.org]
(For context: I am a "bright boy" working at Google, who has been doing crypto security for pretty much the entirety of my 30-year career. I don't work on messaging, though, and don't know much about RCS. My post just describes the cryptographic realities and explains why iMessage can do this but RCS can't, without being something different from what it is.)
Re: (Score:3)
I guess I don’t really grasp the validity of that as an argument, though. Sure, with iMessage there could theoretically be an MITM introduced if the escrow server gets compromised or in cases of a legal government demand. But unencrypted messages definitely can be intercepted at any number of points in transit, so it’s not as if there’s some advantage to that over the iMessage/Signal encryption model.
iMessage and Signal may not be perfect, but they do raise the bar significantly. As the sa
Re: (Score:2)
Or in cases on non-legal government demand, or if Apple decides it wants to. You must be insane if you really think iMessages are secure. You literally have no idea what the iMessage program or the backend infrastructure is doing. You are simply trusting Apple.
Re: (Score:2)
Well you know sms is not secure, so you don't use it for secure communications. Works fine for messages like "pick up some milk on the way home"
Re: (Score:2)
I guess I don’t really grasp the validity of that as an argument, though. Sure, with iMessage there could theoretically be an MITM introduced if the escrow server gets compromised or in cases of a legal government demand. But unencrypted messages definitely can be intercepted at any number of points in transit, so it’s not as if there’s some advantage to that over the iMessage/Signal encryption model.
iMessage and Signal may not be perfect, but they do raise the bar significantly. As the saying goes, don’t let the perfect be the enemy of the good.
You missed my point and instead focused on a distracting aside (which, in hindsight, I really should have omitted). The distracting aside was that systems with a central trusted third party acting as an introducer can be MITMed by that introducer. But my point was that RCS doesn't have a central trusted third party to act as an introducer, any more than SMTP does. Lacking that, there's no way to do the key exchange unless you want to use a CA-based PKI, an even more complicated web of trust, out-of-band k
Re: (Score:2)
Form your earlier post:
"Keep in mind that the lack of end-to-end encryption isn't because Google or the other companies working on RCS don't think it's important, it's because in the open RCS model (unlike the walled-garden models of iMessage or Signal), there's no central authority to do the key management."
So why not do key exchanges via NFC or swapping usb sticks without any certificates other than physical offline authentication between users? Make that an option on top of the walled garden for people t
Re:Why not end-to-end encryption? (Score:5, Insightful)
Many reasons. SMS for example is very resilient. There are many stories about natural disasters where cellphone signal wouldn't work but SMS would because the amount of data needed is very little and the signal travels over long distances well.
Something like iMessage or WhatsApp uses significantly more data and requires a 3g/4g/5g connection to make use of. It's also specific to a provider where SMS is open to all for use with no middle man. RCS I believe is pitched the same way and is supposed to be the spiritual successor to SMS which is a little long in the teeth.
Re: (Score:1)
No End to End Encryption? No thanks (Score:2)
End to end encryption (Score:5, Interesting)
Keep in mind that the lack of end-to-end encryption isn't because Google or the other companies working on RCS don't think it's important, it's because in the open RCS model (unlike the walled-garden models of iMessage or Signal), there's no central authority to do the key management. In order to establish and end-to-end encrypted channel, you need to authenticate the exchange of public keys for the two endpoints. In centrally-controlled systems, this is easy -- though there's a large caveat. It's easy because both endpoints trust the central server and have its public key, so they can both establish an authenticated secure channel with that server, which simply gives them the public key and contact address for the other party. After that, the the two endpoints can us a standard protocol to establish a secure, authenticated channel between them without help from anyone else.
The caveat is that the trust that both sides are placing in the central server is very deep. The server could easily MITM their connection and read everything.
There are ways around having to have a central server. Out-of-band comparison of public key fingerprints, the way SSH and PGP do, works fine but it's impractical at scale for non-technical users -- and they'd never do it out of band. Public key certificates work to bind an identity to a public key, but then you have to have some identity registrar (or set of them), which everyone must trust. Conceivably, the carriers could play that role for RCS, but for whatever reason they don't want to -- and how much would people trust them if they did?
Another alternative for RCS is that Google could run the central server. This doesn't require any additional trust in Google for users who are using the Google app (since if Google wanted the contents of your messages it could have the app upload them), but having any single central authority goes against the notion that this is an open, decentralized standard.
It is, of course, possible for to layer encryption on top of RCS, the same way Apple has layered it on top of SMS for iMessage. And that may happen (I don't know one way or the other). But if Android Messages does that, like iMessage it will be an app that supports two, disjoint protocols and works to make them appear as one -- most of the time. There will always be corner cases that are tricky to handle, like when an iOS user migrates their phone number to an Android phone and iMessage on other iOS devices can't deliver messages to the new phone for a while.
Re: (Score:1)
I don't think iMessage "layers encryption on top" of SMS. SMS sent in iMessage aren't encrypted at all.
Re: (Score:2)
I don't think iMessage "layers encryption on top" of SMS. SMS sent in iMessage aren't encrypted at all.
Fair. iMessage the app uses the secure protocol opportunistically. If it can use the encrypted, centrally-controlled, iOS-only protocol, it does so. If it can't, it uses the unencrypted, decentralized, standard protocol. So to users it looks like they're just texting, but when they're texting to other iOS users they get more features, including encryption.
Re: (Score:1)
Correct. Except you aren't really getting "encryption". You are getting whatever Apple claims, because you have no way to inspect the system. There is a huge difference between "encryption" and "what a massive corporation claims is encryption".
Re: (Score:2)
Correct. Except you aren't really getting "encryption". You are getting whatever Apple claims, because you have no way to inspect the system. There is a huge difference between "encryption" and "what a massive corporation claims is encryption".
I don't know anything about the internals of iMessage encryption. I do know that Apple has plenty of competent cryptographers and cryptographic engineers on staff, and that it would be a PR mess for them someone dug into the details and found the encryption to be weak, so they have both the capability and the motivation to do it right.
On balance, I strongly suspect that iMessage uses good crypto, and uses it correctly, and that the iMessage servers are not MITMing the messages. This isn't because I have
Re: (Score:2)
What I don't get, if there is no encryption, what mechanism is there to check if a message has not been altered in transit, or to protect against bogus sources. Already here in the US, robocalls with fake caller ID is out of control, and no company who can actually do something actually cares to. We don't need another protocol that is easily jacked by the bad guys and is an another compromise vector.
I would say Signal did it right. I've used it since the TextSecure days, and it works quite well. Wish mo
Re: (Score:2)
What I don't get, if there is no encryption, what mechanism is there to check if a message has not been altered in transit, or to protect against bogus sources.
The carriers do the transport, routing and provide the indication of origin, so it's all on them.
Already here in the US, robocalls with fake caller ID is out of control, and no company who can actually do something actually cares to. We don't need another protocol that is easily jacked by the bad guys and is an another compromise vector.
Yes, the carriers have sucked at this in the past and they'll almost certainly continue sucking in the future. RCS is a feature upgrade for SMS. Its goal isn't to fix the security problems of SMS.
I would say Signal did it right.
Signal is good. But Signal, or any system like it, could not replace SMS, because the Signal model requires a central trusted third party that doesn't exist in the SMS/RCS model, just as it doesn't exist in the SMTP
Re: (Score:2)
Keep in mind that the lack of end-to-end encryption isn't because Google or the other companies working on RCS don't think it's important, it's because in the open RCS model (unlike the walled-garden models of iMessage or Signal), there's no central authority to do the key management.
There are ways around having to have a central server. Out-of-band comparison of public key fingerprints, the way SSH and PGP do, works fine but it's impractical at scale for non-technical users -- and they'd never do it out of band.
I doubt anyone believes this. There is a long history of excuses (and outright sabotage) for why every single ubiquitous form of mass communication between people on earth remains completely insecure.
Non-technical users are able to create trust relationships between their phones and other Bluetooth devices yet somehow when it comes to text messaging on mobile phones all of the sudden even low security solutions such as pairing codes and one time leaps of faith are deemed beyond the capabilities of consumer
Re: (Score:2)
Google is incapable of even imagining anything but completely centralized solutions to problems (in which they are the benevolent and ever-trusted central authority). Even on the topic of encryption alone, they completely ignored DANE and other decentralized solutions for ones like certificate transparency where they stay in control of everything.
Re: (Score:2)
Google is incapable of even imagining anything but completely centralized solutions to problems (in which they are the benevolent and ever-trusted central authority).
That's particularly funny to me, since I spend a huge amount of my time designing decentralized solutions that explicitly exclude Google.
Even on the topic of encryption alone, they completely ignored DANE and other decentralized solutions for ones like certificate transparency where they stay in control of everything.
Google's problem with DANE is the execution, not the concept. Too much of it is still built on 1024-bit RSA keys. And Google doesn't "control" certificate transparency, though we did design, build and host it for the whole world to use, for free. The reason for building certificate transparency was to solve a real problem in a way that would work. It was the brainchild
Re: (Score:2)
If you can propose an effective key exchange system that doesn't require a centralized server, please publish it and become famous. Oh, and then let's use it for SMTP.
Re: (Score:2)
While key exchange might be hard to do without a central authority, it would still be nice to have an option to exchange keys out-of-band, or through one of many 3rd party registrars trusted by both parties. I wouldn't trust Google to handle the key
Re: (Score:2)
Holy cow, talk about perfect being the enemy of the good. Frustrates me to no end.
We don't need a trusted authority for certificates. Just be opportunistic and warn if the key changes like ssh does. Give tools like Signal or Whatsapp or Threema do to just scan a qrcode to verify the key for users that care about doing so. Have a little icon saying "unverified" like those apps do does until you scan the code.
ssh would never gotten off the ground if it needed a registrar for host keys.
1998's technology -- TODAY (Score:5, Insightful)
ICQ, AIM, MSN, Y!M, ... all well underway before the turn of the millennium, some already had typing notification and smileys by then. A decade before that a subset of those features were offered by other protocols were like Zephyr and IRC.
I question our short term memory when we put much stock in what new incompatible industry standard is announced or what big tech company's new proprietary client can do that is not a whole lot different than before. Something like XMPP could easily be extended to run over HTTP/2 and use JSON instead of XML, and it would suddenly seem very modern and Web 2.0 (or are we up to 3.0, I forget)
The real failure is that old protocols don't capture advertising revenue or sell new phones. We're not operating in a consumer-oriented industry. We don't produce products that provide a better value to consumers, we produce products that provide a better value to our own business and make up the gap with good marketing.
Re: (Score:3)
The reason this matters is because of what it's designed to replace. SMS was designed with assumptions that are no longer true or necessary and has a lot of unnecessary limitations, and yet it's what a lot of people use because either (a) it's the default or (b) it's tied to phone numbers, which is often convenient. RCS is designed to replace that system
Re: (Score:1)
SMS is not being replaced with a new protocol. RCS doesn't replace it, it is yet another IM protocol that runs over IP. You'll consume data on your phone plan, not SMS or "minutes". And you'll cease getting messages on RCS when your signal is too weak for IP traffic to be effective.
Because it runs over an IP network, RCS is essentially no better than other IM systems that have been with us for decades. I'm sure there already is an XKCD comic about this.
Re: (Score:2)
I'm sure there already is an XKCD comic about this.
Of course there is [xkcd.com].
Re: (Score:3)
Re: (Score:2)
Personally, I use SMS because it does what it needs to do and it's universal. But hey, that's just me.
Re: (Score:2)
ICQ, AIM, MSN, Y!M, ... all well underway before the turn of the millennium, some already had typing notification and smileys by then.
Though those were all singe-vendor proprietary technologies, unlike the standardized, decentralized RCS.
The real failure is that old protocols don't capture advertising revenue or sell new phones.
Neither does RCS.
You misspelled XMPP. (Score:2)
Or e-mail. Or IRC. Or $somethingEvenIAmTooYoungFor.
Did you somehow just return from your colon behind the moon, or something?
colonY! I meant colonY!! (Score:2)
Although I appreciate the implication of the typo. :)
Re: (Score:2)
> Neither does RCS.
Well, it seems like Google will reconfigure everybody's phones to use RCS instead of SMS, effectively hijacking and routing all messages through their own servers.
These are the same people who brag that they know everything about you since your first contact with the Internet.
I may be wrong but given their core business I have trust issues here.
Re: (Score:2)
Well, it seems like Google will reconfigure everybody's phones to use RCS instead of SMS, effectively hijacking and routing all messages through their own servers.
RCS messages, like SMS messages, go through carrier systems, not through Google servers.
These are the same people who brag that they know everything about you since your first contact with the Internet.
Cite?
Well, e-mail already could do it. (Score:2)
And frankly, I see no reason you can't just shove packets to an open TCP port directly. E.g. using netcat.
* Typing indicators are just text messages with special rendering treatment. As are images, audio, etc. E-mail or HTTP headers with MIME types are perfectly fine to trigger that.
* Presence changes could be handled by a small filter that changes lines in a file.
* File transfer is trivial, since everything is a file already, including normal messages.
* Encryption is just piping through a properly set up
RCS? (Score:2)
Wait, I use RCS to manage configurations on my linux servers. I'm currently using it to manage my general website projects but I'm moving things to git instead.
[John]
Apple (Score:2)
I clearly remember Apple announcing that iMessage was going to be "open source" or whatever, what happened to that?
What will a dumbphone user see? (Score:2)
Or even just a iDumbuserphone.
And why do we need this, when there already is XMPP. A federated protocol thst is used without federation in pretty much all modern messenger. Just use that one as the default, and have networks that provided SMS forwarding provide a federated server. Duh.
Then we could even use normal XMPP desktop clients to "text" somebody.
Re: (Score:1)
Corporations that rely on data collection to make money do not embrace open protocols for their data collection products.
I'll wait ... (Score:2)
Google's Rollout of RCS Chat ...
It's all Data, send it over IP (Score:1)
Google Voice (Score:2)
So, no reason to quit Signal then (Score:1)
"All Android Users..." (Score:2)
All Android Users... except for Google Voice users. We're still being treated like red-headed step-children.
Only 55 operators support it - WORLDWIDE (Score:2)
What's this crap, seriously? I don't care about the whole discussion that they don't need to run their own servers or whatever, you need to have an operator that supports this "RCS Universal Profile". This is the first "messaging" solution where not only there's nobody I know but I can't even use it for tests with myself, even if I have the second phone and SIM (as the second operator doesn't supports it). And it seems that they're rolling out since forever (2016?) and there's no clear plan even how/when it