Two observations:<p>1. You should look into what other messengers do with sender/receiver pairs information. One very popular competing messenger logs pairs permanently, serverside, in order to make UI features work.<p>2. One of the least popular attributes of Signal (on Hacker News, at least) is its lack of federation and ability to interoperate with third-party clients. This feature is a pretty crystalline example of the kind of protocol change you can make when you control all the mainstream clients, and that would be an absolute nightmare for a protocol where you didn't.
Here's an idea, Signal, how about removing the requirement that everything be tied to phone numbers?<p>BBM back in the day worked great with their unique "PINs", that could be shared by QR code, and I could reject an "add" request.
I'm confused here. It seems the identities are trivially linkable via the IP address.<p>The Signal servers can't determine cryptographically that the message originates from Device A. But it is certainly from device A, because this isn't a peer to peer protocol.<p>It seems to me like what you'd need to make this work is some sort of intermediate layer, a bit like onion routing, that would have messages arrive at the Signal servers without basically giving everything away in the source IP field.<p>With general use of NAT there's a N-to-one mapping of identities to IP addresses, sure, but this seems to be technically true whilst in many cases completely erasing any benefit of this entirely.
I'm not sure I understand the feature. It protects the sender's identity <i>from their servers</i>, or <i>from the recipient</i>? What's the use case / threat model?<p>I think it prevents their servers from correlating my identity and my IP address etc., but since I want replies and I'm asking the server about replies, doesn't that operation tell the server what my identity is anyway?<p>(There are some comments here talking about anonymous messages, but that doesn't sound right since the phone number is apparently kept in the encrypted, inner envelope, and also how would you route replies if you didn't have an identity of some sort for the sender?)
This is an unexpected move, perhaps Briar, Matrix and other distributed platforms are putting more pressure on Signal to show forward progress on the serious metadata issue with Signal and most other centralized platforms?<p>Its been a rallying cry/common complaint by those who are technically inclined and privacy conscious for years now, surprised OWS would choose to give credit to the problem.
How does signal do media messages? All the time i'll open signal and see someone sent a picture but I have to download it. If signal doesn't store anything on it's own servers but ip and timestamp, where is this media message stored after it's sent but before I received? Am I just downloading it from the device that sent it to me? That would explain why it's so unreliable.
You can test out the sealed sender feature on the beta releases of Signal: <a href="https://support.signal.org/hc/en-us/articles/360007318471-How-do-I-join-Signal-s-beta-" rel="nofollow">https://support.signal.org/hc/en-us/articles/360007318471-Ho...</a>
How to fight spam if sender identity is not known? Currently I get at least a few marketing calls a week and don't know how to make them stop other than blocking the numbers.
Can the URL be changed to the Signal blog post at <a href="https://signal.org/blog/sealed-sender" rel="nofollow">https://signal.org/blog/sealed-sender</a>?