SMS Security and Privacy Gaps
security.googleblog.com
security.googleblog.com
Note that my usage has only occured on Google's Jibe servers using Pixel phones. Samsung Messages and alternative RCS servers might perform differently.
- Google change their approach on messaging every year or two - Google's RCS implementation has them hosting rather than the carrier (against spec) - Google's RCS only just added E2EE for their group messages (or is that still beta? I can't find confirmation on that), and did not contain any E2EE or even confirmation they'd add it at launch - Speaking of which, where was Googles interest in RCS pre-2019? - RCS is phone number linked (as a carrier service probably should be), so how would compatibility with iCloud/Apple users work?
It seems like a bad decision for Apple and a regression for users who broadly have solved the issue themselves by using alternatives (WhatsApp, Signal, Facebook Messenger, Telegram, Matrix, etc).
I'm currently leaning towards recommending Matrix and whatever are the most easy-to-use apps at the time. Unless Element is giving off concerning signals, or something better comes along.
A serious IETF standard with much the same properties as Matrix would be nice.
(I haven't entirely ruled out Signal, as a stopgap measure, but the current proprietary-ness isn't something I want to recommend, and I really don't like that it can only be active on one mobile device at a time.)
One device at a time is a close second. (It sort of works on multiple devices though. It works on my phone, watch and ipad.)
- It’s extremely common for Chinese people to use third-party keyboards.
- If they do this, all security Signal provides is undermined.
- Signal tells people it’s a secure way of communicating. People in China believe this and use Signal without realising they aren’t secure.
- It’s fair to expect Signal – an organisation founded and run by Americans – to not be aware that Chinese people use their phones in a very different way to westerners.
- A Chinese woman has been telling them about this problem for years and asking for a warning to be put into Signal so that Chinese users are aware they can’t use Signal securely in this way.
- Signal conspicuously ignored her for a very long time. Things like Moxie blocking her on Twitter, misrepresenting the request as a “boiling the ocean” type request, saying she was just attention-seeking, saying that people should decompile keyboards to prove they are transmitting keystrokes, etc. Have you ever heard a security professional say that they need evidence that something is being actively exploited before they will do anything about it?
- Finally after a year of this, he replied to a man on Twitter saying “Totally, if this is the thing people want, that's np.” – as if this hasn’t been brought up over and over again by her to the point of him blocking her because she was annoying him too much.
- At this point people point out that this is what she has been asking for for years. So he apologises. To the men he’s talking to, not her.
- And just recently, it turns out insecure keyboard leaking is something that has been affecting hundreds of millions of Chinese users. So it was absolutely a real problem that Chinese Signal users needed to be aware of, and it was a major security fuckup that Signal delayed warning people for over a year.
Unsurprisingly, she’s less than polite when talking about Signal. And she’s a provocative person in general. But the fact remains that she was telling Signal about a real problem for a long time, and they were conspicuously ignoring it when it came from her but finally acted on the problem when she got a few white men to repeat the complaint for her. I get that she rubs some people up the wrong way, but if you’re a person from the west being told by a Chinese person that there’s something particular to their demographic that is wrecking your security, you should pay attention, not do everything you can to avoid them.
I don’t trust software to be secure if they disregard security issues because they don’t like who is reporting them, and nobody else should either.
Here are some links:
https://www.technologyreview.com/2023/08/21/1078207/sogou-ke...
https://twitter.com/RealSexyCyborg/status/119769534457579929...
https://twitter.com/RealSexyCyborg/status/135100660456555724...
https://community.signalusers.org/t/signal-should-warn-users...
It is. This was discussed at length in the Signal users community link I provided. I’m not going to repeat everything that was said over there. Do you have anything new to add that wasn’t covered there?
It's not a "security vulnerability" in Signal that the user can install a third party keyboard app that spies on them, even after the OS warns them against that risk, nor is it Signal's fault that keyboard apps are not required to respect the private-mode call/flag an app can use.
The only solution to close this hole would be for Signal to implement its own virtual keyboard, which would be a massive undertaking.
> They were told repeatedly for a year that Chinese Signal users were vulnerable and needed a warning in the app. They intentionally ignored the problem because the wrong type of person was reporting it.
Stop racebaiting - race had nothing to do with it.
Naomi Wu threw a profanity-laden, insult-filled temper tantrum because she was apparently the last person on the planet to get the "third party keyboards are insecure" memo, accused Signal of misleading marketing because she wildly misinterpreted it saying it guarantees users privacy, and was outraged the Signal app does not warn people using a non-stock keyboard that their privacy might be violated. She demanded they add a warning.
Signal said "not our responsibility to warn users about stuff they've installed" which is a reasonable take, especially since Android OS warns about security risks upon installation of a third party keyboard. Signal is not a vulnerability-scanning tool, it's a messaging app.
Moxinspike said he felt Naomi was making a huge scene about it to stir up shit on social media for attention, and I think he's right. Scroll through her twitter feed and you'll see she's like a Singapore version of Briana Wu; just one outrage-bait post after another...and lashing out at other developers, like the first page of her twitter feed; here's her abusively lashing out at the entire Mastodon dev community in a cryptic-passive-aggressive way:
https://twitter.com/RealSexyCyborg/status/158953417392850124...
The tweet making fun of the "struggles of e-thots" was particularly rich, too.
Do you want to try this reply again?
When E2EE is enabled they rolled their own crypto. Another red flag.
Telegram is owned by Russian nationals living in United Arab Emirates. Another red flag.
Don’t recommend Telegram.
- free
- open source
- decentralized
- good cross-platform support (linux, mac, windows, ios, android)
- multi-device synchronization
- offline message delivery
- group chats
- end-to-end encryption
- well-understood crypto ciphers & protocols
- mature enough for a reasonable expectation of security & privacy
- some way to protect metadata (e.g. self-hosting)
- anonymous signup
- easy enough for most computer users
- getting enough traction to seem (eventually) viable as a general-purpose contact channel
As far as I know, there is still no other service that satisfies all those needs.
It has some rough edges that are less important to me for now, but I think they're on the roadmap: Some bits of metadata, like (IIRC) reactions and avatar images, aren't e2e encrypted yet. Occasional encryption errors and notification failures, but I think those are solved in the beta client code (currently available in Element X) and at least some alternative clients.
I suggest introducing a few technical (or patient) friends to Matrix today, and bringing more people in once the new client code graduates from Element X into the main reference clients.
Here's where you can explore alternative clients: (I like Nheko's compact mode.)
https://matrix.org/ecosystem/clients/
Here's where you can read weekly progress reports:
The native group voice/video feature, currently in testing as Element Call, has a design that looks particularly interesting for its ability to scale beyond a few participants without requiring a large/expensive central media server.
https://element.io/blog/tag/voip/
They're actively working toward IETF MIMI and MLS support, which bodes well for future interoperability:
https://matrix.org/blog/2023/07/a-giant-leap-with-mls/
The project lead often answers questions here on HN when Matrix-related articles pop up. Searching his past comments (username Arathorn) is worthwhile if you want a deeper view into the project.
Matrix is definitely better, but we're quite a few steps away from the required UX for grandma.
Hell, even great grandmothers can breeze through that stuff [e]
[-1] http://magma.maths.usyd.edu.au/magma/
[e] https://research-repository.uwa.edu.au/en/persons/cheryl-pra...
However I think the generalisation is still fair. The experience of most Matrix clients and concepts is not great for those who do not have an IT background, or users who find technology difficult (correlated in this case with those who didn't grow up with it). The median boomer or older is likely to find it more difficult than a millenial.
"Grandma" has all sorts of positive connotations, but some discussions in HCI and product design have loaded it to mean not good at some things, when that's not necessarily even generally true. And I suppose the idea, casually propagated, could be a little insulting, or even professionally harmful to people.
Maybe a mental exercise to make this intuitive is to imagine a workplace meeting, and someone calling a colleague "grandma", while meaning pretty much what is meant here. They'd rightly get smacked across the room, figuratively, with a chance of literally.
maybe not HN readers, but this is actually a major factor for a huge number of ordinary people in the US, particularly teenagers and young people
On iOS, green is a warning that at least two things are true:
1) The other side is subject to blanket surveillance (which is probably true of RCS, assuming Google implemented the client/backup).
2) The other endpoint cannot handle images or videos correctly. Based on their track record with the last dozen communications platforms Google has built, this is probably also true for Android RCS implementations. For example, the other day, someone attempted to use gmail to send me a locally stored image, and instead it sent a URL back to some server somewhere. This is neither SMTP nor SMS’s fault. Presumably Google’s RCS client will eventually pull crap like that too. Hell, they try to do it with HTML (remember AMP)?
Note that, following this convention, Signal messages are correctly colored blue, even when sent to android.
(I know that apple does not dictate these colors. Just explaining what “green bubble” means to people that are used to android’s bullshit.)
There’s no commandment from heaven anointing RCS as The One True Messaging Protocol. That’s just Google PR that wants you to think that. Even if Apple were to support something other than iMessage and SMS, it doesn’t necessarily follow that this must be RCS.
Do I really need Google knowing when I'm typing a message or my location or all the other information they will surely be able to extract when they are running the messaging platform that all my messages are going over?
The beauty of the iPhone is paying for the service instead of having your data be the service and getting it for free. It's a big reason why people are switching to iPhone away from Android.
Does Google actually care about our security or privacy, or are they just trying to force us onto their platform?
True... But only if you can force a device to 2G. From the article:
> First it is noted that there are vulnerabilities in the security functions of 2G, which makes practical attacks possi-ble. It is, however, important to point out that the attacks are not restricted to 2G, but applies to all generations of mobile networks that have implemented a fallback solution to 2G. For example, an attacker can relatively easily perform a downgrade attack to change 5G service to 2G service, which makes the user vulnerable to the threat scenarios for 2G.
Many countries shut down their 2G networks years ago. I was baffled it took us so long in Australia. No idea what everyone else is doing. But regardless, for many users this is not a concern.
> SMS texting is both a large and weak link in the chain largely because texts between iPhones and Androids revert to SMS. > It’s a shame that a problem like texting security remains as prominent as it is, particularly when new protocols like RCS (https://www.gsma.com/futurenetworks/rcs/the-rcs-ecosystem/) are well-esta blished and would drastically improve security for everyone.
Ah ok, it's a thinly veiled attack against Apple from Google, the kings of interoperability ¿
The carriers make a lot of money on sms, and because it's table stakes for a phone, SMS remains the least common denominator in text messaging (it's like OG JavaScript, except without the good parts). Meanwhile, there are a plethora of over-the-top messaging apps that have accrued huge user bases addressing all the things RCS tries to and then some.
https://www.statista.com/statistics/736007/mobile-messaging-...
https://www.statista.com/statistics/1222773/worldwide-applic...
> In 2021, the global application-to-person (A2P) SMS market is anticipated to reach 45.93 billion U.S. dollars in revenue.
The A2P SMS includes a lot of things beyond just what the carriers make.
(Here cross link hundreds of posts how running your own email server is no longer practically possible)
It is possible to run your own e-mail server, the problem is how much of your life you want to dedicate to getting a static IP address off the major spam blocklists, troubleshooting myriad delivery issues, and generally keeping the whole thing running.
1. Switched from the GMail web interface and app to open source IMAP clients on phone and PC.
2. Switched away from gmail.com to my own domain, using Google as the provider. This was the hardest part, because I had to change my email address everywhere! It also meant setting up DMARC and SPF records for the domain.
3. Set up a VPS running an SMTP server in a MX configuration. At first I had the server relay over a VPN to a second machine in my house, but later I moved to port forwarding over the tunnel, so the VPS provider never sees the contents of my emails (as long as they’re encrypted). Of course, STARTTLS is subject to downgrade attacks, but this can be reduced somewhat with MTA-STS and DANE. And Google still saw my outgoing emails (but I receive way more private emails than I send, personally).
4. I wanted to remove the last vestige of Google, and also to hard-fail if the recipient doesn't support TLS, so I finally set up a sending SMTP server on my LAN, which routes outgoing mail through a VPN tunnel so it looks like it’s coming from the VPS instead of my home IP. The first few furtive emails I sent went straight to Google’s spam box, but the recipients marked them “not spam,” and I stopped having trouble with that. I can also send to Microsoft addresses. It’s reliable enough that I get replies whenever I expect them. Very rarely, it goes to spam, and I have to follow up with the recipient to mark it not spam—but this is very rare, and surprisingly, happens at about the frequency that it happened when I was using Google to send my mail. Really!
I took these steps months and sometimes years apart. Long enough to be 100% comfortable to move on to the next step, but I could just as easily have been satisfied and stopped at any point, and it would have been better than total dependence on the cloud. Overall maintenance effort is about inline with the other servers I run (DNS, HTTP, Minecraft).
Running your own mail is not for everybody, but “no longer practically possible” is a defeatist, demotivating overstatement.
It’s really important to use a distro that you understand well and are comfortable keeping secure and up to date. For me that’s OpenBSD; for you it might be something else.
For security reasons, I recommend keeping the server setups simple, minimal, and isolated as much as possible. I have three machines: the sending server, the receiving server, and the VPS.
The VPS is the only machine directly accessible from the Internet, so it is locked down as much as possible: it forwards incoming port 25 over a WireGuard tunnel to the receiving server, it forwards traffic from a second WireGuard tunnel (from the sending server) to the Internet, and that’s it. No other services, and all other incoming and outcoming ports are blocked with the firewall. The SPF settings in my DNS list only this VPS’s IP address as a trusted sender, and the MX settings point to the VPS too.
The receiving server runs on a Raspberry Pi. Since it’s almost directly accessible from the Internet over port 25, this one’s heavily locked down too. It’s firewalled from making Internet connections except those relevant to mail receipt (incoming port 25, reverse DNS lookup, DMARC lookups, etc.). It delivers to a Maildir.
The sending server is an Intel NUC actually running two VMs, only one of which is for sending. The second VM is the viewing VM. It periodically rsyncs new mails from the receiving server to a Maildir. I interface with the Maildir directly by logging in with SSH and using command-line tools like mblaze and notmuch. This machine also runs Dovecot as an IMAP server backed by the Maildir; the IMAP is used by my phone, Thunderbird, and my self-hosted webmail (Roundcube).
The other VM, the sending VM, is what I point my mail clients’ outgoing SMTP settings to. It listens for outgoing mails from my LAN (requiring TLS client certificates for authentication), and sends them to the destination server, but with the traffic routed through the VPS so it looks like they came from there rather than a residential connection.
What I described is what I ran for a while, but over time I’ve added additional complexity for the sake of higher uptime. That’s not really necessary, since downtime was already rare and SMTP handles outages of a few hours gracefully, but like the progressive steps in my previous comment, after several months I was comfortable with my setup and wanted to push it further. Now there are two VPSes from different providers (mitigating downtime at one datacenter and the risk of being tied to one VPS provider), port forwarding to two MXes on my LAN. I’m planning to get a second ISP at home, so a VPS can have an alternate path to its MX if one ISP is down.
Email has not stayed put. Most email is encrypted hop-to-hop, for example. It's not ideal for security, sure, but compare it to the alternatives. I can switch between email providers (because I own my domain name), and I can switch registrars. That provides many protections against lock-in.
The answer was not SMS. It was "Big Tech". There is a belief that these so-called "tech" companies want to collect data and analyse communications for commercial purposes in ways that telecom companies never did unless they were hit with a subpoena (and that's still not commercial use). Unlike telecoms, these companies have not had to operate under significant government regulation (including laws concering customer data), their original business model is surveillance-based advertising and they are unlikely to abandon it. (Telecom companies have obviously morphed somewhat in response to Big Tech's competition, arguably not in a good way. This evolutionary pressure toward surveillance for profit is a more subtle form of the threat posed by "Big Tech".)
Secondly, I would trust Google more than Apple or Meta to keep my data safe from technical hacks or leaking or selling it to third parties. And I understand they are going to use my data to power their ads business where they personalize and target ads to me on their own and 3rdparty properties.
Finally, we need to keep the regulatory oversight and pressures to move and keep them in line with increasing privacy and security expectations.