It's good enough when I don't need a number to sign up at all. Unfortunately they're not there yet. So for now.. meh
Without that it's just a slightly more private WhatsApp.
In fact I wish we could move to another kind of identifier than a "phone number" for things like this. It's probably pretty region-dependent but personally I never use my phone to actually make phone calls or text. All my voice, video and messaging traffic to friends goes through apps, though the number is unfortunately still used as an identifier. Unfortunately, because if I let a number lapse I lose access to the whatsapp and telegram accounts related to it. This way it makes it hard having multiple accounts.
I'd prefer if mobile providers would just become a dumb data pipe the same as landline providers have already become. My Spanish provider still forces me to take a "landline" with my internet but I don't even have a phone connected to it.
Signal will not publicly admit that, but they are using phone numbers as a cheap anti-spam measure. If anyone can sign up with an email, you will have same spam problems as with email, and will need to implement some spam filtering, and so on.
It's harder to spam with phones. Although, as they now do in Burma, they can just kidnap a lot of people from China and India and keep them as slaves and make them send spam from phones. But anyway that's a different story
I feel like Signal has been up front for many years about why they use phone numbers, and I get incessant spam on other phone number platforms (most especially: phones) so I'm not sure that holds water.
They seem to actually confirm it themselves, which I didn't know.
> We use third-party services to send a registration code via SMS or voice call in order to verify that the person in possession of a given phone number actually intended to sign up for a Signal account. This is a critical step in helping to prevent spam accounts from signing up for the service and rendering it completely unusable—a non-trivial problem for any popular messaging app.
I'm sure they absolutely do use it as a spam signal. You use what you've got. But that's not why they use phone number identifiers, which is a design decision they and others have written ad nauseam about.
Even Twilio has a hard time with deliverability of SMS due to spam blaclisting by carriers. There’s a reason why SMS delivery is so expensive, and why alternatives like WhatsApp want in on the action.
Twilio runs into the exact same text deliverability issues in the USA that everyone is experiencing, there is no reason to pay them a premium when they have no ability to influence. Whether or not your text is caught by AT&T, Verizon, T-Mobile, or US Cellular's spam filtering.
Avoid sending SHAFT content and shortened URLs if you don't want to get your text messages. Black hold or banned. S.H.A.F.T. is an acronym that stands for Sex, Hate, Alcohol, Firearms, and Tobacco
Exactly, carriers have no way to know if a SMS comes from Twilio's legitimate or less legitimate clients, so they have to block everything. SMS is no longer the cash cow it used to be so tehy can't afford to spend lots of money on individual message moderation and have to adopt more crude blocking measures.
What if they allow non-phone-number-verified accounts to only place calls/texts to users only where the non-verified is already in that user's contacts?
That would prevent spam. The only people who would hear from the non-verified account is people who already took the effort to place the non-verified account username in their contacts.
(I've never used Signal and I have no idea what how it works.)
Burma/Myanmar is in a state of civil war, close to China and close to cheap Thai mobile internet access. Chinese started building fraud parks where they capture people and force them to serially scam people on fake bitcoin exchanges (it starts as online romance, turns to bitcoin scam). Mostly Chinese but also increasingly Europeans and Americans
nobody does anything because those fraud parks are tolerated by Burmese junta. They are on the border between Thailand and Burma
They probably require phone numbers to be able to comply with the three-letter government agencies requirements and their requests on specific people. Metadata is specifically available "for free" (who calls/messages whom when).
> Metadata is specifically available "for free" (who calls/messages whom when).
That's completely incorrect. Signal has only the following data (backed up by what they have provided when served warrants[1], and what internal FBI documents state about Signal[2]:
Date and time a user registered.
Last date of a user’s connectivity to the service.
Signal has released demands for information and what they provided in response to those demands. It's not a hard question, it's on their website. Don't let yourself be yet another conspiracy theorist.
There’s really nothing stopping someone from publishing an instrumented / modded binary to a mobile App Store unless there’s a user-verifiable build chain, even if it is open-source. Even if the backend IS e2ee, the UI can be extended to keylog / etc. The App Store provider can be in on it too.
DNS can be filtered to provide some degree of control and traffic inspection, but there’s always DNS over HTTPS, tunneling, and so on and so forth.
I’d be surprised if Signal was doing it, since getting caught at it would totally destroy their reputation, but I’d honestly be surprised if WhatsApp didn’t have at least a backdoor for it.
Unless you espcially meant by ”App Store”, by Apples App store, it is Apple to blame in that case because it is not possible due to the encryption of app binaries.
I wasn't speaking specifically about Signal nor about a particular storefront. I'm glad Signal has at least a reproducible build on one platform. That doesn't change my main point: "it's open source" is NOT a guarantor of this AT ALL without usable build verification.
Signal's vaunted double-ratchet encrypted groups have a severe weakness in the key exchange where the server can add itself as a participant.
Granted, this is pretty hard to solve when participants come online and offline at different times without having a trusted and always-online entity to handle the list of the current members (in the signal model, it's the server), but signal's still definitely not a silver bullet, even if people treat it like it is.
But if Signal gets pwned or captured, it can easily add itself into any group, or even add and remove instantly.
Wouldn't the group members at least be notified that someone joined the group? And the server would only have access to messages sent after that notification, right?
Do you evidence of that? Are you sure you aren’t confusing Signal and Matrix, which had that big? We would have heard about Signal after the Matrix bug if it also had it.
There's no clear solution for it from an encryption perspective without a big tradeoffs (like requiring all participants to be online at the same time).
Besides, the larger the group, the more likely that one of the nodes has been compromised anyway. Everything's a tradeoff -- don't depend on the security of a single solution if you're really trying to keep a secret; defense in depth.
You haven’t shown that this flaw is in Signal in addition to Matrix.
I heard about Matrix having that exact flaw, and if Signal had the same flaw, it would be big news. I remember Signal saying that they are not vulnerable.
> There's no clear solution for it from an encryption perspective without a big tradeoffs (like requiring all participants to be online at the same time).
I wonder if that's why Telegram's secret chats do in fact require users to be online at the same time for key exchange. I've used it before and I had to wait a while for the other party to come online.
That is also valid for 1:1 chats, not specific to groups. It says "if you don't check the key if the remote party via a secondary channel you are vulnerable to MITM attack of the server is owned"
Which is obvious, every single E2EE encryption tool which is centralised is susceptible to it, but I would wager that decentralised too, although maybe harder to realise.
The amount of problems remains stable, as a universal constant . Problems are neither solved nor created, only transformed. By switching from Telegram to Matrix, new problems arose. By switching from Matrix to Session, by switching to Signal, where we are now, fewer problems arose
Records of precisely who you talk to are being kept serverside because of that decision. Maybe that's totally fine for you! Most people have pretty unserious secure messaging threat models (I don't mean that as a value judgement).
The same is likely true of Signal, no? Traffic analysis on AWS' edge would tell you precisely who is talking to who, and user identities are tied to legal identities via phone numbers. Maybe Signal doesn't store this data serverside, but there are entities with both the capability and motivation to obtain it. I bet there are Signal XKEYSCORE selectors.
Signal or any surveillor surrounding their servers (with or without Signal's cooperation) almost certainly has enough timing/traffic-shape info to reconstruct who-to-who logs.
"Sealed sender" (and some of Signal's other tactics) just demonstrate: Signal's main & disclosed codepaths aren't stockpiling the canonical metadata via the same blatant & undenied mechanisms of other services. Sufficiently sophisticated outside attackers, or insider threats, can construct nearly-equivalent logs via other means. (And: Signal seems reluctant to make choices, like truly ditching phone numbers as account IDs, that could limit these 'shadow' leaks.)
1. Signal, where an attacker with granular access to AWS's global network logs could perform traffic analysis to match timings between sender and recipient IP addresses, which would work for some portion, and narrow things down for some other portion. The attacker would then need to combine that with data from mobile networks and other ISPs to link the sender/recipient IPs at a given timestamp with a subscriber.
2. Other messaging platforms, including Matrix, where they can just check the server's database to get a table of what user messaged what other user at a given time.
On Matrix, that assumes the attacker knows where the server is or that it even exists. Whereas on Signal it’s pretty obvious where the server is, given there’s only one logical server.
The only thing I find is that it's such a moving target. I was trying Element X last week which is now meant to be the new client to be. But I wasn't able to set up the encryption with my recovery key, there was only the online validation which I couldn't use because I was on the go and didn't have access to my desktop. It's supposed to be better but still lacks such basic things (also seems to still lack TOFU for my private server)
The same with the homeservers, there's synapse and dendrite is supposed to take over at some point but that point is forever far in the future. And then there's conduit, so which one is it? I understand this is a fully open multi-server multi-client platform but I kinda expect the "stock" ones to be clear in their strategy :)
The strategy doesn't really feel well thought out in that sense. I really like Matrix and am rooting for it but such things undermine my confidence in recommending it to others.
I'm sure the questions I ask are crystal clear to the matrix in-crowd but to me they're not. In that sense it feels a bit like recommmending arch Linux to a beginner, the first thing they have to do is choose a partition scheme, a network management stack, a desktop environment etc etc. This just doesn't work for those that aren't already deeply in the know :)
Matrix has a radically different threat model than Signal. They aren't replacements for each other. I think they'd be happy to tell you that if you asked them. I like Matrix too, but it's not going to save you from many of the decisions Signal made that you don't like; Matrix avoids those decisions by avoiding those issues.
Matrix itself is a big messy thing, much like the Web - this is both its power and a potential weakness.
Element X is indeed a fancy new client - but it hasn't hit a 1.0 yet. Think of it a lot like Firefox was pre-1.0; it's unrecognisably faster and better than the previous generation... but not all features are there yet. Meanwhile, there are loads of entirely unrelated independent excellent clients out there too; it's not just about Element v Element X.
> But I wasn't able to set up the encryption with my recovery key, there was only the online validation which I couldn't use because I was on the go and didn't have access to my desktop.
This bug is an accidental thinko however: it's placeholder UI which is about to be replaced by implementing login-via-scanning-QR-code (which is almost there), but obviously that also needs the ability to enter recovery keys too. Eitherway, it's being fixed: https://github.com/element-hq/element-x-ios/issues/2424
> also seems to still lack TOFU for my private server
Yup, sorry, TOFU for TLS isn't implemented yet in EX.
> The same with the homeservers, there's synapse and dendrite is supposed to take over at some point but that point is forever far in the future. And then there's conduit, so which one is it?
Synapse is a stable server where the core team is putting its effort currently. Dendrite is a 2nd gen server from the core team, but is beta and a) ended up being focused on P2P and embedded homeservers and experimental MSCs, b) is starved of resource atm due to funding pressure (c.f. https://www.youtube.com/watch?v=s5BrVVf0B1I&t=316s). Conduit is an independent server implementation in Rust, which is promising but beta.
It's like asking whether you should use Apache httpd or beta versions of nginx or lighttpd in the early days of the Web.
> The strategy doesn't really feel well thought out in that sense.
The strategy at Element (which employs most of the Matrix core team) is pretty clear right now:
1. Improve Synapse as the most mature and stable server implementation (and package it in Element Server Suite for those needing an enterprise Matrix distro: https://element.io/server-suite)
2. Finish implementing sufficient features in Element X that it can replace the old classic Element mobile apps asap - converging on a single Rust codebase, so that bugs & audits & new features can all land in one place.
3. Keep building Element Web/Desktop and Element Call.
...and that's it.
If it seems confusing, that's either because we're in the middle of the Element -> Element X shuffle... or because the nature of Matrix is that there's loads of other independent implementations running around too. But that's what makes it fun, too :)
Without that it's just a slightly more private WhatsApp.
In fact I wish we could move to another kind of identifier than a "phone number" for things like this. It's probably pretty region-dependent but personally I never use my phone to actually make phone calls or text. All my voice, video and messaging traffic to friends goes through apps, though the number is unfortunately still used as an identifier. Unfortunately, because if I let a number lapse I lose access to the whatsapp and telegram accounts related to it. This way it makes it hard having multiple accounts.
I'd prefer if mobile providers would just become a dumb data pipe the same as landline providers have already become. My Spanish provider still forces me to take a "landline" with my internet but I don't even have a phone connected to it.