It seems there's nothing on Signal's blog as of yet, but the project's git repository was tagged with v7.0.0 yesterday and we can see from the commit history since the previously tagged version (v6.74.4) that there will be a setting to hide one's phone number [1], as well as disabling the previous default behavior of advertising that one is on Signal to all of their contacts already using it [2].
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 :)
Heh. I have the opposite problem. I'd like a way to have Signal auto-delete conversations and media from my device after a certain amount of time.
Yes, there are auto-delete options, but those apply to the group/chat as a whole, and other people in some of the groups I belong to want to keep their chat history. I'm not totally opposed to them doing so, but would like the option to just delete my copies.
(Signal uses more space on my iPhone than all my other apps combined, and I've had problems with upgrades being blocked because there wasn't enough space remaining to install them. Manually deleting hundreds of photos from individual groups to make room is such a pain in the ass.)
Large group chats should have an expiry of one week or so, maybe 4 weeks at the longest, otherwise it gets crazy. Unfortunately the best way to delete those old messages in your local chat is to delete the conversation and rejoin it.
Admins really should have a "purge all history older than X" option. They let you do it one by one manually, but it's basically impossible to automate, and doing it manually is super tedious.
But what good would that be? If the people in the group I'm currently in don't want to reduce the expiry time of the group we're currently in, why would they join my new group with a reduced expiry time? Even if the new group was exactly the same as the old group, without a setting that makes it less attractive, why would they join my new group when all the people they want to talk to are currently in the old group?
Am I missing something? How do you suppose that creating a new group would play out in a way that improves the situation?
Maybe it's a thing in your corner of the internet, but searching for some combination of "expiry", "flow" and "contamination" in mine only yields results about water treatment, drug manufacturing, or some other chemical laboratory process.
Even trying to think of synonyms for those words doesn't illuminate me in any way about how your previous comment might have any bearing on mine.
I want the ability to load chat history from a backup on desktop. It's obnoxious that a messaging app that bills itself as cross-platform will just permanently lose message history on a client if it's not opened for long enough or if your have to get a new device (or reinstall)
You can, just backup/restore ~/Library/Application Support/Signal (or windows equivalent), the encryption in stored in cleartext config.json next to the sqlitedb on desktop. https://vmois.dev/query-signal-desktop-messages-sqlite/
> Chat history I don’t know anyone that cares about it so maybe your expectations are just different there
The general expectation of, at a first approximation, absolutely anybody who has ever used WhatsApp, is that things do not disappear and get lost.
I don't mean us geeks, spies, enemies of the state, people chased by Mossad. I mean our grandmas and grandpas, our aunts and parents. I've seen enough tears over lost data and I don't see why this needs to happen.
For people (in other comments) who want to lose data: why not have a setting "do not backup my data, I do want to lose it if my phone dies"?
So you're looking for a feature where someone can hit a button and get a clear text export of all the encrypted chat history on the phone? You do understand why that feature doesn't exist right? Backup utilities are regularly abused by criminals and other bad actors to harvest private data.
If you want to record all of your chat history with someone and keep it around forever, Signal is not the right tool. Signal is for private communications, and I'm glad that people on the other side of conversations with me can't just export everything with a button press. That would be a massive violation of trust.
That's just wrong. You can export your chats in a secure format, signal android even let's you do it on a schedule. Combine with a hosted file server like nextcloud or google drive and you have automatic fully encrypted backups
What I'd like is an incremental backup feature in Signal android.
Currently you pay 2x the phone storage space to make a backup, and then with something like Syncthing you've got to do even more to not just be storing hundreds of gigs of mostly the same data.
Yeah same, I additionally do nightly rsync copies of my nextcloud to a second server in a data center and cleaning out all of the signal backups gets annoying after a while
>people on the other side of conversations with me can't just export everything with a button press.
Once any data is off your device and (decrypted) on someone else's, you must assume that they have full control over it, which includes backups. Anything else is poor privacy practice, security through obscurity.
In principle you're correct, but in practice, the lack of an export feature is enough to make sure that 99 out of 100 conversations don't get leaked to third parties. You don't know with perfect certainty which ones do get leaked anyway, but...
99 out of 100 conversations wouldn't be leaked to third parties even if there was an encrypted backup feature - which there is, is android. You're trading hostile inconvenience for basically zero benefit.
If anyone is curious I highly recommend exploring the desktop app implementation. So many of security guarantees that Signal ostensibly provides are gone in desktop environments where any app you have installed can read ~/Library/Application Support/Signal to and see all your contacts and messages in using the encryption key stored in cleartext in config.json.
Wow. Didn't know this. Signal's got a lot of user warnings when doing anything that breaks the security model. I don't remember Desktop giving a "Your chats are essentially unencrypted on this platform" warning.
If you can see a plaintext decoded message you should assume that it is system-readable if you don’t have some kind of guarantees about a memory-secure enclave. Use a secure system if you care about this.
Wrong forum for this question. I wanted universal chat, file transfer, and clipboard sharing across the big 3 desktop and big 2 mobile OSes without being tied to a universal, privacy-invading, primary key like a phone number. Using phone numbers for signup is only a couple degrees from using social security numbers for customer accounts in the 90's. Captchas and account expiry are some of the proper forms of abuse prevention that don't leap straight to privacy invasion with a not truly portable or anonymous unique identifier.
Or use a fork like Session, despite its (unsustainable?) crypto business model. Reliance on phone numbers creating trackable metadata was a critical and avoidable footgun resulting from copying WhatsApp too closely without leaning into privacy first.
I started getting “unknown” message requests on three unrelated phone numbers through my different signal accounts on Jan 24 2024. The contact info doesn't have a phone number, crypto scams.
I guess this is the result of the beta. See screenshot please.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
[1] https://github.com/signalapp/Signal-Android/commit/8797236b5... (PNP stands for "Phone Number Privacy")
[2] https://github.com/signalapp/Signal-Android/commit/6097e6c30...