Here's a link to the full "SAFEGUARD Digital Identity Protection Toolkit" created and distributed by Army Special Operations Command. It covers a LOT more than just Signal and is full of good advice.
Weakness in the linked devices security model. And so by extension, tools like "beeper"
If you don't link devices and check there are no linked devices your side of things is OK but you have no certainty in group chats or the other side one on one. So it's down to your own trust in the other party/parties.
This doesn't invalidate your point, but FYI, you can open your contact's info in the Signal app and see the number of linked devices they have. If someone is concerned enough about this, they could ask their contact to unlink all devices.
EDIT: I'm using a fork, which may be why I'm seeing it and others aren't. See below.
Given sufficient mutuality, you can have some assurance of e2e but your risk here is your own and the other ends OPSEC which is all the NSA guidance really can re-inforce: the more people and devices you bring into an exchange the less likely it is you really have secure communications.
I don't see it in the Android app either, and I find the original claim very hard to believe in the first place, since that would be a weird piece of information for Signal to reveal about a user.
Apologies for the mistake. I'm running a Signal fork called Molly[0]; the feature I mentioned seems to be unique to that fork, based on a search of the code.
However, it shows that the data is being provided to the client by the server, in some way. This is a guess, but it may be because sending clients have to encrypt with a key for each device.
However, I think there is a real possibility that the Signal code (of which the public appstore versions are NOT fully open-source) could be modified to save/transfer messages after they have been decrypted, basically circumventing the whole point of e2ee... which is why having control over the client code is essential.
I suggest either building Signal yourself, using only verified reproducible builds without any binary blobs, or switching to the Molly-FOSS fork.
It's not clear. The relevant text seems to imply that an attacker can link their own device to a target account via providing a malicious URL (vs. commandeering an already-legitimately-linked device, which I guess is what you're imagining). That sounds like a legitimate flaw. But there are no details.
No, bypass means to go around, not to break. So this is correct terminology. By adding devices into a chat, you get to see the plaintext messages, thus bypassing the protection provided by the end to end encryption.
Any application that does cross-device authentication is vulnerable to QRLJacking (this type of vulnerability) to some extent, the same way any application with username/password authentication is vulnerable to phishing.
https://www.soc.mil/IdM/publications/docs/general/Id_Privacy...