And while they wait for RCS, they can just install Signal. Signal works and is funded by a non-profit who puts in more work to know as little as possible about you than any other company/org out there.
Used to but not anymore. Anything sent over Signal is guaranteed to be secure. SMS/RCS doesn’t provide any guarantees as SMS is not encrypted by default and RCS clients are all closed-source.
Oops, I did not add a “/s” because, I assumed both yours and the comment you had replied to were sarcasm. I missed the question mark on your comment. Phone calls are universal on every device supporting a compatible network (2G, LTE, 5G, etc).
You have to reinstall Signal after uninstalling play services. Then it detects that play services aren’t there and sets itself up to receive push notifications without it.
But to be on the safe side, I’d install Signal-FOSS instead which has no Google dependencies at all.
It doesn’t for me? I run it on Graphene without google play services. You just have to turn off battery optimization, but it’s very reasonable in its battery usage. I’ve been off battery for 18 hours, and am at 81% on my Pixel 8. Signal is at less than 1% of battery use, and it still will be in a few days when I’m ready to charge, unless I use it significantly on my phone. But I mostly use it from my laptop, and just get notifications on my phone, so probably not.
In contrast, K9 Mail is at around 3%, it’s running at battery optimized, and I haven’t opened it at all.
No, the solution is to rid ourselves of the Plain Old Telephone System, as well as IP-based internet, and move to something that doesn’t rely on a corporation to communicate, is secure for everyone, and is free and open source.
IP-based internet relies on so many corporations, organizations, governments, etc., to play nicely. They hoard IPv4 ranges and let you “rent” out blocks of IPs if you pay them enough. This is not free and open access to the internet.
In order to connect to the internet, you are required to pay an ISP. They then dictate how you can use your service. For some residential ISPs, you aren’t allowed to use certain ports, so you cant host your own services like email, websites, etc. You also have to monitor how much bandwidth you are using to make sure you don’t go over your “data cap”. This is why these centralized services are so big for things like email and web hosting. We’ll get more into data collection here in a bit.
IP-based internet is flawed in that it allows DDoS attacks to take out a server that might be limited on protection. There is no redundancy or self-healing properties built-in that will protect the little guy. You can always subscribe to services like CloudFlare, who will then Man-In-The-Middle your internet traffic. You then have to abide by their terms of service, which is not desirable (especially if new hostile leadership were to come in and take over the company). Also, unless you are paying multiple ISPs for redundant connections to the internet backbone, you are vulnerable to Sybil attacks on your network. If subscribed to a single ISP, and it has downtime, you will have downtime along with them.
Any data sent between one IP to another is not encrypted by default. You have to bolt-on entirely different protocols to have that capability. As a result of that, we ended up with a very splintered implementation of encrypting data-in-transit. There are thousands of messenger applications, transmissions protocols, certificate authorities, etc., that often aren’t compatible with others. They also individually have their own set of issues.
Data collection… Ads… Trackers. Oh my! The end user of most modern websites are connecting to multiple servers, even though they visited a single site. Those users are tracked as they hop website to website. Often, these companies keep a profile on anyone matching that fingerprint. You have no control over that data. If you turn off connections to those servers, the website can become unusable. You can’t seriously say this is the best we can do. Why not have a network that prevents you from being tracked?
RCS would be a good solution if the standards committee wasn’t so held back by not adding an official end to end encryption method. Probably telecoms not wanting to give up the data mining.
Settling for RCS means no E2EE. It’s also handing control over messaging back to carriers (or most likely, Google, because not many carriers have RCS servers) which is a step backwards.
For all of Apple’s many many faults, iMessage is a pretty good service once you pay the Apple tax to get in.
Doesn’t RCS support E2EE if properly implemented? I seem to recall reading that the spec for RCS supports this, but it’s just that carriers won’t enable it.
No, E2EE is not part of any RCS spec yet. Based on news articles, Apple is implementing RCS but will supposedly ask the governing standards bodies to add E2EE to the spec so they can implement it according to the official specifications.
Google has implemented their own E2EE on top of RCS (based on Signal’s messaging for one to one conversations, based on MLS for group chats), but they haven’t published any specifications for that. It shouldn’t be too hard to reverse engineer, but that shouldn’t be necessary for any open protocol.
Google has implemented their own E2EE on top of RCS (based on Signal’s messaging for one to one conversations, based on MLS for group chats), but they haven’t published any specifications for that.
Ahh, this must be what I was thinking of, then. Thanks for clarifying!
If you mean this link: that’s a high level description of the protocol, but it leaves out important details.
For example, Google uses MLS for group chats, but the document only mentions the Signal protocol. In other words, E2EE for group chats is broken even if you manage to implement the protocol exactly as they describe.
For example, they say the client “registers with the key server” and “uploads the public key parts”. What server is that? What protocol do we use? HTTPS POST? Do we use form/multipart? Do we encode the key in PEM or do we submit they bytes directly?
Another example: “Key material, digest, and some metadata are encrypted using the Signal session”. Whay do you mean “some”? What algorithm is used to generate the digest?
The document is a nice high level overview, but worthless if you want to implement their protocol. It basically says “we put signal, and send the signal messages over RCS, with out own key servers. Here’s how the Signal protocol works”. If, for example, Ubuntu Touch would like to implement this into their messenger, they’ll need to reverse engineer Google’s Messages app, guided by the description in their whitepaper.
It’s also handing control over messaging back to carriers
I don’t really see any issue in this, as RCS was meant as an upgrade of the SMS protocol. Moreover, as the smartphone market is now pretty much a duopoly between Google and Apple, and pretty much what is not Apple is Google, it was natural for Google to also come up with an alternative to iMessage of theirs. Because that’s what it is currently. I’m surprised Apple accepted to implement RCS after all because of this tbh.
Imo, both Google, Apple could have worked with the major carriers to implement a solution like this over GSM (and not requiring you to use mobile data). For me, that’s the advantage of the SMS over any IM app out there (including Matrix, XMPP etc.): you’re not required to turn on your data in order to use it. It’s just right there. For the current implementations of RCS/iMessage respectively, I don’t see any advantage over just using WhatsApp or Facebook Messenger for example.
Carriers wanted RCS because WhatsApp and iMessage were taking away their ability to charge by the text more than anything. I think they all dropped their subscription model by now, but no doubt they’ll start charging you when you use the more advanced features of RCS (i.e. uploading 500MB files).
Google did come up with an alternative: Google Talk, then Hangouts, then Allo, then Google Chat, and I think I missed one or two. Unfortunately, Google employees only get promoted by launching new products, so every chat team wants to launch something new, and that’s why every year Google launches a new messenger.
Nobody I know uses SMS because carriers here still charged by the SMS five years ago. MMS has been turned off entirely by the largest carriers around. Why would I pay 5 cents per message, or €3 extra for unlimited text, when I could just use the data plan I already have for free? Messages cost kilobytes of data, fractions of a cent.
As for the evolution of SMS: SMS was free at first, then relatively cheap, because it used empty space in the GSM standards allocated for basic message passing. Someone noticed that there was some leftover capacity and thought they may as well use it for a small feature. Then once people started using it, this stuff stayed in.
MMS (the part where you send anything more than 140 characters to a single phone number) is using your data connection. Well, it’s actually using a separate data connection, but it’s all packeted, like RCS is. That’s why SMS works when you have a single bar of reception, but MMS struggles.
As of LTE/4G, everything is packeted networking. Phone calls (over VoLTE) are no longer directly routed audio links, they’re voice (or video, but nobody seems to implement that part) streams over a network connection. VoWiFi (WiFi calling) is basically a VPN tunnel with two audio streams inside it. A true 4G successor of SMS would he RCS, except you’d need a separate APN that normal applications couldn’t use to reach an internal IP address that’s not accessible over the internet.
Like how MMS is entirely optional for carriers to provide, so is RCS. That’s why Google runs their own servers. For the majority of people, they need Google’s servers because their carrier doesn’t offer RCS services. They basically took a component intended to be run by carriers only and said “fuck it, we’re a carrier now”.
There can be advantages to RCS if your carrier has a server you can use, but if you’re using Google Jibe, there’s not much, really. In theory Google could expose an RCS API that would automatically enable E2EE (if available) to other apps, like how you can access RCS received messages through the same API you can use to read MMS messages on Android phones with Google’s messages app, but Google hasn’t implemented that in core Android yet. Knowing them, they probably don’t want to be locked down in their encryption system or protocol by making it part of the standard distributed to every phone manufacturer, but it’s hurting the effort to go beyond SMS.
iMessage has one advantage, which is that it can fall back to SMS when it can’t teach its servers. In theory any app could implement that. I’m not sure if iMessage does anything to encrypt its fallback SMS messages (it could) or use a chain of them to also send the necessary metadata to put the SMS messages into an iMessage conversation, but it’s always an option.
For Android users, Google Messages and soon RCS adds the ability to communicate with iMessage users without requiring iMessage users to install another app. In the silly bubble shaming countries, this is a major advantage. Outside those, everyone probably already has either WhatsApp, Line, or Vibe, or in China WeChat, so you can just use that. On the other hand, it RCS is no different than all the others and comes preinstalled on your phone, why not use it?
With the European DSA quickly approaching, there’s a good chance we’ll also gain some kind of cross messenger interoperability in the future. Google already uses the MLS standard for group messaging, which is part of an effort to standardise messaging protocols, and when MIMI gets finalised next year, perhaps large European gatekeeper apps like WhatsApp will become interoperable with RCS and other messaging apps. In a perfect world, you could just install the messaging app you prefer, or stick with the default one, and communicate with every other messenger app out there. Kind of like how iChat/MSN used to work, but as part of the standard.
I’ll do one better, I’ve been a beeper (not beeper mini) beta tester for a while, and I’ve had uninterrupted imessage access through their older method which never had a single outage!
I imagine though they have been using a method like spinning up virtual mac machines or matrix bridge to get it to work.
either way it is by far my favorite messaging app, I’m so damn tired of all these companies walling their messaging service into some enclosed garden while everyone I know decides that THEIR favorite app is the one everyone should be using.
Good. I can’t wait to stop hearing about this app and their stupid feud with Apple.
You don’t need iMessage. Your iFriends need RCS. Beeper is not the solution.
And while they wait for RCS, they can just install Signal. Signal works and is funded by a non-profit who puts in more work to know as little as possible about you than any other company/org out there.
Fair, let me buy a new phone to talk to one person instead.
fair. anyone who doesn’t want to install Signal can reach me via text/SMS or RCS. those are the options.
deleted
Can signal interact with SMS? I felt like I had issues with that when I used it a couple years ago. May have been me.
@rhythmisaprancer @ijeff @Chozo @KLISHDFSDF @sour
pretty sure they removed sms support
Too bad.
Used to but not anymore. Anything sent over Signal is guaranteed to be secure. SMS/RCS doesn’t provide any guarantees as SMS is not encrypted by default and RCS clients are all closed-source.
Like a telephone call?
Yeah, like a telephone call. But, not a telephone call.
Isn’t a telephone call supported on all phones? If it isn’t, then nothing is.
Oops, I did not add a “/s” because, I assumed both yours and the comment you had replied to were sarcasm. I missed the question mark on your comment. Phone calls are universal on every device supporting a compatible network (2G, LTE, 5G, etc).
Unfortunately Signal, unlike Telegram, breaks when I uninstall google play services.
You have to reinstall Signal after uninstalling play services. Then it detects that play services aren’t there and sets itself up to receive push notifications without it.
But to be on the safe side, I’d install Signal-FOSS instead which has no Google dependencies at all.
Thanks for this, today I learn
It doesn’t for me? I run it on Graphene without google play services. You just have to turn off battery optimization, but it’s very reasonable in its battery usage. I’ve been off battery for 18 hours, and am at 81% on my Pixel 8. Signal is at less than 1% of battery use, and it still will be in a few days when I’m ready to charge, unless I use it significantly on my phone. But I mostly use it from my laptop, and just get notifications on my phone, so probably not.
In contrast, K9 Mail is at around 3%, it’s running at battery optimized, and I haven’t opened it at all.
weird, works on my de-google’d OnePlus 6T running Android 13
get the signal apk from their website instead of downloading with aurora store
RCS is also not a solution
what is the solution then? iMessage become an open platform?
I think the FCC should create a new standard that doesn’t need googles servers.
No, the solution is to rid ourselves of the Plain Old Telephone System, as well as IP-based internet, and move to something that doesn’t rely on a corporation to communicate, is secure for everyone, and is free and open source.
(deleted)
IP-based internet relies on so many corporations, organizations, governments, etc., to play nicely. They hoard IPv4 ranges and let you “rent” out blocks of IPs if you pay them enough. This is not free and open access to the internet.
In order to connect to the internet, you are required to pay an ISP. They then dictate how you can use your service. For some residential ISPs, you aren’t allowed to use certain ports, so you cant host your own services like email, websites, etc. You also have to monitor how much bandwidth you are using to make sure you don’t go over your “data cap”. This is why these centralized services are so big for things like email and web hosting. We’ll get more into data collection here in a bit.
IP-based internet is flawed in that it allows DDoS attacks to take out a server that might be limited on protection. There is no redundancy or self-healing properties built-in that will protect the little guy. You can always subscribe to services like CloudFlare, who will then Man-In-The-Middle your internet traffic. You then have to abide by their terms of service, which is not desirable (especially if new hostile leadership were to come in and take over the company). Also, unless you are paying multiple ISPs for redundant connections to the internet backbone, you are vulnerable to Sybil attacks on your network. If subscribed to a single ISP, and it has downtime, you will have downtime along with them.
Any data sent between one IP to another is not encrypted by default. You have to bolt-on entirely different protocols to have that capability. As a result of that, we ended up with a very splintered implementation of encrypting data-in-transit. There are thousands of messenger applications, transmissions protocols, certificate authorities, etc., that often aren’t compatible with others. They also individually have their own set of issues.
Data collection… Ads… Trackers. Oh my! The end user of most modern websites are connecting to multiple servers, even though they visited a single site. Those users are tracked as they hop website to website. Often, these companies keep a profile on anyone matching that fingerprint. You have no control over that data. If you turn off connections to those servers, the website can become unusable. You can’t seriously say this is the best we can do. Why not have a network that prevents you from being tracked?
IP-based internet? What do you mean by that, how else are we supposed to provide unique addresses for every device on a network?
that’s probably very far in the future
someone is still gonna hold the power anyway
Wgar?
RCS would be a good solution if the standards committee wasn’t so held back by not adding an official end to end encryption method. Probably telecoms not wanting to give up the data mining.
so what? an merger between iMessage, RCS and mms?
We need a standard that’s recognized just like sms. It shouldn’t need any special server from some company
I can’t figure out a response to this
Settling for RCS means no E2EE. It’s also handing control over messaging back to carriers (or most likely, Google, because not many carriers have RCS servers) which is a step backwards.
For all of Apple’s many many faults, iMessage is a pretty good service once you pay the Apple tax to get in.
Doesn’t RCS support E2EE if properly implemented? I seem to recall reading that the spec for RCS supports this, but it’s just that carriers won’t enable it.
No, E2EE is not part of any RCS spec yet. Based on news articles, Apple is implementing RCS but will supposedly ask the governing standards bodies to add E2EE to the spec so they can implement it according to the official specifications.
Google has implemented their own E2EE on top of RCS (based on Signal’s messaging for one to one conversations, based on MLS for group chats), but they haven’t published any specifications for that. It shouldn’t be too hard to reverse engineer, but that shouldn’t be necessary for any open protocol.
Ahh, this must be what I was thinking of, then. Thanks for clarifying!
https://support.google.com/messages/answer/10262381?hl=en
E2EE White paper (technical specifications) is listed on this site (pdf)
If you mean this link: that’s a high level description of the protocol, but it leaves out important details.
For example, Google uses MLS for group chats, but the document only mentions the Signal protocol. In other words, E2EE for group chats is broken even if you manage to implement the protocol exactly as they describe.
For example, they say the client “registers with the key server” and “uploads the public key parts”. What server is that? What protocol do we use? HTTPS POST? Do we use form/multipart? Do we encode the key in PEM or do we submit they bytes directly?
Another example: “Key material, digest, and some metadata are encrypted using the Signal session”. Whay do you mean “some”? What algorithm is used to generate the digest?
The document is a nice high level overview, but worthless if you want to implement their protocol. It basically says “we put signal, and send the signal messages over RCS, with out own key servers. Here’s how the Signal protocol works”. If, for example, Ubuntu Touch would like to implement this into their messenger, they’ll need to reverse engineer Google’s Messages app, guided by the description in their whitepaper.
Thanks for this explanation!
I don’t really see any issue in this, as RCS was meant as an upgrade of the SMS protocol. Moreover, as the smartphone market is now pretty much a duopoly between Google and Apple, and pretty much what is not Apple is Google, it was natural for Google to also come up with an alternative to iMessage of theirs. Because that’s what it is currently. I’m surprised Apple accepted to implement RCS after all because of this tbh.
Imo, both Google, Apple could have worked with the major carriers to implement a solution like this over GSM (and not requiring you to use mobile data). For me, that’s the advantage of the SMS over any IM app out there (including Matrix, XMPP etc.): you’re not required to turn on your data in order to use it. It’s just right there. For the current implementations of RCS/iMessage respectively, I don’t see any advantage over just using WhatsApp or Facebook Messenger for example.
Carriers wanted RCS because WhatsApp and iMessage were taking away their ability to charge by the text more than anything. I think they all dropped their subscription model by now, but no doubt they’ll start charging you when you use the more advanced features of RCS (i.e. uploading 500MB files).
Google did come up with an alternative: Google Talk, then Hangouts, then Allo, then Google Chat, and I think I missed one or two. Unfortunately, Google employees only get promoted by launching new products, so every chat team wants to launch something new, and that’s why every year Google launches a new messenger.
Nobody I know uses SMS because carriers here still charged by the SMS five years ago. MMS has been turned off entirely by the largest carriers around. Why would I pay 5 cents per message, or €3 extra for unlimited text, when I could just use the data plan I already have for free? Messages cost kilobytes of data, fractions of a cent.
As for the evolution of SMS: SMS was free at first, then relatively cheap, because it used empty space in the GSM standards allocated for basic message passing. Someone noticed that there was some leftover capacity and thought they may as well use it for a small feature. Then once people started using it, this stuff stayed in.
MMS (the part where you send anything more than 140 characters to a single phone number) is using your data connection. Well, it’s actually using a separate data connection, but it’s all packeted, like RCS is. That’s why SMS works when you have a single bar of reception, but MMS struggles.
As of LTE/4G, everything is packeted networking. Phone calls (over VoLTE) are no longer directly routed audio links, they’re voice (or video, but nobody seems to implement that part) streams over a network connection. VoWiFi (WiFi calling) is basically a VPN tunnel with two audio streams inside it. A true 4G successor of SMS would he RCS, except you’d need a separate APN that normal applications couldn’t use to reach an internal IP address that’s not accessible over the internet.
Like how MMS is entirely optional for carriers to provide, so is RCS. That’s why Google runs their own servers. For the majority of people, they need Google’s servers because their carrier doesn’t offer RCS services. They basically took a component intended to be run by carriers only and said “fuck it, we’re a carrier now”.
There can be advantages to RCS if your carrier has a server you can use, but if you’re using Google Jibe, there’s not much, really. In theory Google could expose an RCS API that would automatically enable E2EE (if available) to other apps, like how you can access RCS received messages through the same API you can use to read MMS messages on Android phones with Google’s messages app, but Google hasn’t implemented that in core Android yet. Knowing them, they probably don’t want to be locked down in their encryption system or protocol by making it part of the standard distributed to every phone manufacturer, but it’s hurting the effort to go beyond SMS.
iMessage has one advantage, which is that it can fall back to SMS when it can’t teach its servers. In theory any app could implement that. I’m not sure if iMessage does anything to encrypt its fallback SMS messages (it could) or use a chain of them to also send the necessary metadata to put the SMS messages into an iMessage conversation, but it’s always an option.
For Android users, Google Messages and soon RCS adds the ability to communicate with iMessage users without requiring iMessage users to install another app. In the silly bubble shaming countries, this is a major advantage. Outside those, everyone probably already has either WhatsApp, Line, or Vibe, or in China WeChat, so you can just use that. On the other hand, it RCS is no different than all the others and comes preinstalled on your phone, why not use it?
With the European DSA quickly approaching, there’s a good chance we’ll also gain some kind of cross messenger interoperability in the future. Google already uses the MLS standard for group messaging, which is part of an effort to standardise messaging protocols, and when MIMI gets finalised next year, perhaps large European gatekeeper apps like WhatsApp will become interoperable with RCS and other messaging apps. In a perfect world, you could just install the messaging app you prefer, or stick with the default one, and communicate with every other messenger app out there. Kind of like how iChat/MSN used to work, but as part of the standard.
It is a really nice app though. I have never even used the iMessage feature.
I’ll do one better, I’ve been a beeper (not beeper mini) beta tester for a while, and I’ve had uninterrupted imessage access through their older method which never had a single outage!
I imagine though they have been using a method like spinning up virtual mac machines or matrix bridge to get it to work.
either way it is by far my favorite messaging app, I’m so damn tired of all these companies walling their messaging service into some enclosed garden while everyone I know decides that THEIR favorite app is the one everyone should be using.