SMS is like e-mail in the 80s: no authentication, no encryption, and everything can be snooped. In contrast, e-mail itself has gotten several upgrades that at least try to mitigate these flaws.
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.
I’ve run my own email server for five years now. It’s surprisingly approachable when done piecemeal. I broke it into several pieces.
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.
I run OpenSMTPD, mostly because of how simple it is to configure but also how its privilege separated design has reduced the impact of bugs when they happen. (See Qualys’s sometimes complimentary comments in their OpenSMTPD vulnerability writeups.)
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.
The idea of written communications is even older, let's get rid of that too :-).
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.
This is about interop. I'm not interested in iMessage. I do, however, want to be able to have group chats that don't suck and images that don't compress to death when I message friends with iPhones. Unsurprisingly, my friends with iPhones want the same thing when they message me.
Yep. I have two group family chats, one with everyone and one that leaves off the two people on Android. I’m sure that social groups where the percentages go the other way do the same thing.
Google refuses to open up the Android RCS API to third party developers. To me this seems like an attempt to lock in users into their own messaging app, unlike SMS which does support third party apps like Textra.
RCS does not consistently work unlike other OTT messaging platforms. Roaming on another network often breaks RCS, and even when both people are on their native networks, RCS will turn on and off during a conversation seemingly at random.
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).
In 2024, I want to start recommending a secure and open solution for real-time text&photo chats (person-to-person and group) for techies and non-techies alike. Something we can confidently recommend to friends, family, people we just started dating, etc., and they will be happy with it on the their phones, tablets, and desktops.
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.)
Signal totally lost my confidence with the Chinese IME debacle. 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. Then once enough white men repeated the complaint, they put the warning in. Prejudice is a security vulnerability if it makes you ignore vulnerability reports. Signal have demonstrated that they have this security vulnerability and as far as I can see they haven’t taken any steps to close it.
A summary, because it’s a bit spread out over a few places:
- 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.
It doesn't sound like a Signal's problem. When the user compromises the system, the whole system is compromised, not just Signal, and there are many ways to do it, not only keyboard, any spyware would do. IME is a system component, so it's the system vendor's problem that they neither provide nor recommend an IME.
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?
I can't tell if you're genuinely ignorant or purposefully misrepresenting nearly everything about the issue.
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:
I’ve had the best results converting normies with Telegram first and Signal as a second. while I do love the values of Matrix it’s still reallly rough. Matrix 2.0 seems to be changing a lot of that however.
I landed on Matrix a couple years ago. My requirements were:
- 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.)
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.
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.
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.
Wouldn't hurt to find new shorthand terms for different kinds of users.
"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.
This is just more Google trying to grab a service from carriers and Apple.
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.
I don’t know any mobile networks that charge for SMS. Maybe international SMS, but I cannot imagine that is a huge revenue source with ubiquitous data and free messaging apps.
I just grabbed the SMS part. There is an RCS part that makes the number come out over $50 B. Even "free text messages" or "unlimited text messages" result in revenue for the carriers.
The A2P SMS includes a lot of things beyond just what the carriers make.
I can't understand why any person would actually side with Apple with this issue. At it's core, Apple's refusal to integrate with RCS is an anti-consumer practice. They fear it will drive customers to purchase Android phones but that would most likely be an incredibly small amount of people. People buy iPhones for many reasons. The color of the messages isn't the main one.
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.)
If I were Tim Cook, Apple would implement RCS over my dead body. Google have been telling everybody that Apple are “using bullying as a way to sell products” as a part of Google’s RCS PR. That’s an incredibly sleazy road to go down. How are you supposed to collaborate with an organisation doing this? I think Apple should open up messaging more, but I also totally support Apple treating RCS in particular as untouchable toxic waste because of this. If Google genuinely valued interoperability and wanted Apple to coöperate instead of using this as something to attack Apple over, then they wouldn’t have burnt that bridge so thoroughly.
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.
I side with Apple, because I feel that they protect my privacy and security. Google is just trying to force Apple users onto a messaging service that is largely hosted on their servers and run by them so they can collect information about users and target us with ads.
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?
As a simple experiment I asked someone, "What is the greatest security and privacy threat to communication today?"
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".)
Today, every telecom company is also a OTT apps/services company with desires to become like big tech. So, your assertions about telecom companies as some sort of time frozen thing is not valid.
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.
> SMS Interception: Attackers can intercept SMS messages by exploiting vulnerabilities in mobile carrier networks. This can allow them to read the contents of SMS messages, including sensitive information such as two-factor authentication codes, passwords, and credit card numbers due to the lack of encryption offered by SMS.
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 ¿
A much more practical attack is to social-engineer/bribe the idiots who handle customer "support" into swapping the SIM to an attacker-controlled one. Significantly easier and cheaper than mobile protocol/infrastructure -level attacks.
I wish someone would create an encrypted-messaging-over-SMS protocol. Something simple: send a public key with the first (unencrypted) SMS and the receiving person's messaging app can use that key to reply with an encrypted SMS, first reply also containing his/her public key. No forward secrecy, but a lot better than nothing.
62 comments
[ 3.1 ms ] story [ 291 ms ] thread(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.
https://twitter.com/TextraSMS/status/1568128147044057088
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.)
[0] https://simplex.chat
- 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...
https://twitter.com/moxie/status/1351205613645258756
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:
https://matrix.org/blog/
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.
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.
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?
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.
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 ¿