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.
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.
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.
https://crypto.stackexchange.com/questions/77319/triple-diff...
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.
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.
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
> 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.
From their blogpost
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.
[2] https://propertyofthepeople.org/document-detail/?doc-id=2111...
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.)
> Registration Fees: $6 million dollars per year.
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
They should also add crypto to the list.
google kk park, fraud factory.
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 are not even comparable. WhatsApp does not encrypt metadata at all, which is the most interesting information you can leak.
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.
https://signal.org/blog/reproducible-android/
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.
Look at the source code.
"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.)
That is precisely the, ahem, signal metadata.
Also on Matrix you can run your own server.
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.
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 :)
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
EDIT: looks like a fix landed on Friday: https://github.com/element-hq/element-x-ios/pull/2471
> 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 :)
https://privacy-checkup.info/en/recommendations/messenger
xx Messenger hasn't used phone numbers (it's optional) ever, but unfortunately although it still works it's no longer updated because development has been focused on a more modern approach which is desktop-only (https://alpha.speakeasy.tech/). Because of that xx Messenger still lacks other features such as group chats and file attachment support which exist but is unstable and limited in terms of attachment size.
Speakeasy supports DM & group chats, and Echoexx (https://echoexx.tech/) is DM only (currently in closed alpha testing; open alpha starts late this month). Both are browser-only for now and require WASM support. Speakeasy supports native (cMixx) device-independent crypto identity, Echoexx supports ENS (.eth) ID and will add support for native cMixx identity later.
Given that no feature-rich app with strong privacy will ever match features of low-privacy apps (if for no other reason, simply because secure & private alternatives cost a lot more to develop and therefore fund, while simultaneously removing ways to recoup those costs), people should simply use multiple apps for different purposes.
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.