Rich Communication Services: Nobody uses it, nobody wants it, but analysts reckon it's on the verge of a breakthrough Rich Communication Services (RCS) was initially pitched as the inevitable successor to SMS, offering enhanced multimedia functionality and other fun stuff, like read receipts. But despite over a decade's worth of work, it's still very much a non-entity in the messaging space, with Juniper Research forecasting that just 16 per …
WhatsApp = no way
WeChat = even piglet wouldn't use it
Facebook... Messenger = hahahahaha! oh you were serious?
> At that point, an overhaul of SMS looked sensible. But in 2020, it feels a bit outdated. The industry has moved on.
The industry may have moved on but there is still a need for a modern messaging app that doesn't give all your data to Apple, Google, Facebook or the Chinese government. RCS is still very much needed.
Except RCS offers basically none of those benefits. Encryption: no. Centralization: yes. It's a little decentralized because you can go through your mobile company and skip others if your recipient is also on that provider, but it's still using a relatively small set of centralized servers, and given the number of times people have demonstrated successful attacks on those servers, it's likely not private.
You want decentralized, encrypted, text communication with support for rich content, images, etc? Good news. We have that. It's called email with PGP. You can use WiFi or cellular to do that. RCS is no more secure than SMS and likely less useful or secure than most centralized chat apps.
Oh, is that so. So what I'm hearing is they added end-to-end encryption. In a build that isn't the suggested one. On two carriers in America. Who have partnered with Google to get it. Twelve years after the initial protocol was started.
Given that we've had completely functional, auditable, few-restrictions end-to-end encryption on Signal for six years and completely functional, auditable, no-restrictions, decentralized end-to-end encryption on email for at least twenty, you'll forgive me if I find the introduction of the feature in a limited beta version of a protocol that's only available for a third of one country's mobile market on specific hardware only unimpressive.
It's a start. It's only limited now, because it's a dogfood version. The next update to the stable app, will have encryption. As far as carriers go, T-Mobile is the bravest of the bunch, and others may follow. Tried signal, didn't like it at all(caching monster). The performance wasn't good, compared to messages, and crashed alot.
Signal is, quite simply put, the second iteration each of Mr Acton's and Mr Benham's successful money-making trick, as the most cursory look at public records will reveal.
It is another start-up with completely vacuous claims about "security" and sporting an "open source" label because it looks fashionable, not that you can really do anything with their code apart from look at some version of it.
They are good at hype and that's why they're successful, but their product is exactly the same as Whatsapp in every substantial aspect.
Benham also did a chat at 36C3 about how great the centralised model is, etc. etc. It did not exactly go down well with the audience (it was really daft to try to sell that argument to a bunch of German IT people). The talk was at the conference website for a short while until Benham asked for it to be taken down, but can still be found on Peertube.
So TLDR: stay well clear of that signal thing.
Um...not really. The centralized model argument is the only good one you've made. The security of the protocol itself has been verified repeatedly, and the data available to a potentially malicious Signal server is known. We have access to the code and we can take chunks of it, including their protocol, if it suits us.
The centralization argument is a good one--we shouldn't rely on Signal's servers because they could be compromised or removed. That's a valid concern. However, the comparison here has been between Signal and RCS. RCS is also centralized. Now I can hear the arguments already--Signal runs the only servers, whereas RCS is run by multiple mobile companies. The problem being that you need your mobile company's servers to send or receive RCS messages, and you also need your recipient's provider's servers to be operational. That's two single points of failure or interference. In addition, it restricts you to using one communication mechanism to send RCS messages--no sending one over WiFi unless your mobile provider supports it, and even if they do, it takes exactly the same path after leaving your local network. Neither are decentralized.
A decentralized communication system with end-to-end encryption would be nice. The one I've used before is encrypted email, which does offer that but has some usability problems. We can use a few other options or design a new one. RCS is not it.
In addition, RCS places a lot more requirements on hardware and mobile provider support. If I have any network connection, I can send an email with encrypted contents. If I have any verifiable mobile connection at setup time and any connection later, I can send a Signal message. If I have any mobile connection on any provider worldwide, I can send an insecure SMS message. If I have a specific set of phones running on one of two providers in the U.S., I can send an RCS message. That means that, if I go to a different country and get a local number, I can still send email, SMS, and Signal, but RCS is not an option no matter what I like--I just have to wait for someone there to implement it and hope they do so with the encryption enabled, because I can neither verify what their code looks like nor bypass them.
want this to be the messaging to end all messaging unless there was some way that they could slurp the data? They won't be doing this out of the kindness of their heart that's for sure.
So...
RCS is still very much NOT needed.
There fixed it for you.
It just depends who you think is the lesser of all evils (perm one from Apple, Chinese Government, Google or Facebook) in you choice.
TBH, NONE of the above tickles my fancy.
I've pretty much lost hope we'd ever have a truly global messaging standard. For a while XMPP was aiming for it, but it lost itself in a pick'n'mix assortment of options/add-ons/extensions. That doesn't mean it hasn't been successful behind the scenes, Initial Facebook chat, Whatsapp, Google Chat/hangouts (whatever the flavour at the time) used it, and even interoperated with third party clients. For a while at least. The GSMA has been gagging for a "social"/"messaging" platform for ages to make operators feel non-dumb-pipe. Remember Wired Village (from the days of WAP)?
I pinned my hopes on Signal Protocol being the newer, better XMPP and, again, while it's been successful in underpinning Signal Messenger, Facebook Messenger and WhatsApp, it still hasn't broken the vertical silos/walled gardens of commercial interest. Google's "generous" offer of RCS at least brought some federation across operators, but totally missed the boat on being properly secured and end-to-end encrypted. Something to which operators and governments are still rabidly allergic.
Messaging platforms definitely seem to have a generational clique brand aspect to them, i.e. there are the hot, hip and happening ones and the ones your parents or work/college/institution use. None of those make it easy to have work/life/social splits with the same interface. And people rush where the latest emojis, stickers and such are, cf. the swing onto Telegram and TikTok. I'm sure there's little reason the latter cannot use stock, standard back end protocols, besides the walled garden. In the new cloudy world, perhaps what we need is messaging-as-a-service so anyone can spin up their own, add their own special sauce interface bits to the client, but at least have common, at least technically interoperable back ends. We have the protocols.
XMPP has many diverse use cases and different extensions cater to them. You can think of it as a common base over which many different application-specific miniprotocols are built.
For common use cases, compliance suites are published regularly as XEPs (such as XEP-0423) which establish a common baseline. There is also an open source tester to go with it: https://compliance.conversations.im/.
One advantage of the extension model is functionality is pretty well encapsulated, making it quite enjoyable to develop XMPP based solutions (which I have done).
I assume the mobile service providers would only be interested if they can charge separately for RCS, as they do with MMS.
If it's simply counted as data and efficient, the existing apps such as Telegram, Signal, WhatsApp etc could use it as a common layer in the way XML was touted as being the solution to business data exchange.
and other fun stuff, like read receipts.
You mean like what governments don't issue .... which is recognised both implicitly and explicitly by certain auteurs as there being no reason not to proceed?
That is a Huge Vulnerability in Governments Easily Exploited for Beta Employment and Enjoyment in Virtual Engagement of Human Resources and Global Assets by A.N.Others.
there is a single protocol.
It's called the internet. And it enables a rich and diverse OTT market.
don't you think that the mobile network operators have already lost?
They have spent far too long plotting to stop the inevitable. Trying to maximise their investment in their stupid Mobile Networ Architectures.
That is Internet and edge processing.
There may be many things said against it, but something like this IS desperately needed. The reason SMS has been such a success is that for decades every mobile device has supported it. You don't need to create an account, download an app, or buy a certain overpriced brand of phone - it's just there, and you know that essentially anyone with a mobile number can receive it.
Like it or not, RCS has come closer than anything else so far to achieving this, and there definitely appears to be some gain in momentum recently. Apple supporting RCS would be the next biggest step, IMO... I'd hope that they could look at Blackberry and see the future for iMessage.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
