I can’t understand all of what’s mentioned here in that I’m not 100% sure of what I’m understanding is even right.
Folks who know more and are technically adept, please share your views and commentary on this for the teach savvy and the average person to understand it right and for a balanced take away.
I found this here:
I can’t comment on the technicalities, but he is basically saying Signal *could * retrace who you are talking to using traffic analysis of messages sending.
That’s really not news, and neither is it a reason not to trust Signal. It’s pretty mild. This means AWS could technically retrace which IPs are communicating with each other. This would instantaneously ruin their reputation as a cloud provider. Maybe LE could get access to AWS servers, but again this would likely be a card they use very sparcely.
This article, as far as I am concerned, is doing what we dutch call “kicking in an open door”. I don’t know anyone who believed that Signal couldn’t see who is messaging whom with ip analyses, thats rather obvious.
Sealed sender is just another layer they made to make it harder, not impossible. Signal was never going to be the end all be all of anonymous messengers., what it is however, is a very good tool that provides normal people an end to end encrypted open source messenger, hosted by a non profit whoes business model does not depend on collecting and selling your data. Sure a Briar or Simplex might be better, but youre 80 year old uncle jerry is never going to use those, and signal is already a hell of an improvement over whatsapp or god forbid, facebook messenger.
Is it still better though, with all the crypto and NFT stuff they’re getting into?
–
But otherwise I take it there’s nothing to “worry” or worry about and that this is mostly non news?
Currently, yes if you ask me.
And yes, this is mostly non news, just a person stating the obvious after looking at sealed sender implementation.
Signal can , with some effort, do an analyses of who is talking with whom. If anything, we should praise them that they are trying to innovate, even when the results are not perfect. But we have no reason to believe they are doing it right now, and its a big improvement over a lot of other big tech option which a lot of people currently use. Lets not do what the privacy and security community always does, and make perfect be the enemy of good.
I mean, even ISPs and governments can do analogous things even when folks use VPNs (hence we have DAITA from Mullvad as a mitigating feature).
But got it, thank you!
From a US legal perspective I think it’s important to also note that (at least so far) US courts have agreed that the government cannot force a company to put in “some effort.”
Signal can be required to turn over information they already collect. Many Signal protections like sealed sender are built around this and we see they are effective in the real world even if not technically 100% foolproof.
I think people forget that in the grand scheme of things the “problems” with most privacy tools are irrelevant when you take into account that most people are using things like Windows, WhatsApp, and Gmail.
So from what i get it they actually don’t know, but with significant effort might could get to know.
Also why are we discussing an article from 2023?
I… did not see the date until now. Sorry. I mean, I saw the date but not the year. It said Nov 20 and I presumed this was 3 days old.
Great (usable) security is better than perfect security that no one uses.
This is a privacy issue, not a security issue. There is also nothing preventing Signal from doing more to protect against malicious infrastructure, but they choose not to.
First place to look is in the public blog post about the feature from Signal themselves: Signal >> Blog >> Technology preview: Sealed sender for Signal in 2018 and carefully read what Signal has said about the implementation. Some quotes below:
…and the latest beta release includes changes designed to move Signal incrementally closer to the goal of hiding another piece of metadata: who is messaging whom.
On the opposite end of the spectrum, users who want to live on the edge can enable an optional setting that allows them to receive incoming “sealed sender” messages from non-contacts and people with whom they haven’t shared their profile…
These protocol changes are an incremental step, and we are continuing to work on improvements to Signal’s metadata resistance. In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development.
some recent additional context from a Signal developer:
Yes, one day the server could decide to no longer support sealed sender, and sends would go back to be unsealed, and the server would know who the sender is. There’s not a great way to prevent that with the current design…
This system was intended to be best-effort (and we do, indeed, do everything we can to bias ourselves towards sending sealed sender messages), but there’s no guarantee.
As has been mentioned, the limitations have also been explored outside Signal:
- Improving Signal's Sealed Sender - NDSS Symposium
- [2305.09799] Poster: No safety in numbers: traffic analysis of sealed-sender groups in Signal
- Reviewing Signal’s Cryptography, Finale - Dhole Moments
The balanced takeaway is that Sealed Sender is not a significant competitive advantage in the landscape of secure messengers, but it doesn’t necessarily hurt. It is rare for an encrypted messenger to have an explicit focus on sender and recipient anonymity. The author of the blog post seems to unintentionally confuse their friend’s position/understanding for Signal’s position on the matter which is clearly quite different.
I think it would be fair of you to substantiate this claim. I haven’t pored over the Signal forums or Signal forks’ community spaces in a very long time, but it is quite a thing to suggest they have no further plans to protect service users from infrastructure/service providers (including themselves) considering their work on SVR.
Can you elaborate how this would be affecting privacy?
Their shift in focus implies (if not proves) potential change in their priorities (product wise, ethics wise, quality wise, etc) to make and maintain an app they originally did. It no longer inspires confidence in me about them and the app for what it was meant to be.
That’s my rationale at-least and don’t think it is unreasonable by any metric.
The title of the article cited by OP is no surprise to me. No matter what metadata resistance Signal adds, being a centralized instant-messaging service, I’ve always thought Signal is capable of knowing (with some effort) which accounts talk with which accounts. For an instant-messaging service to be incapable, it must at least route communications in a decentralized manner.
The article argues sealed sender is effectively useless. I haven’t looked into the technical details but sealed sender provides only one-way (sender) anonymity, and all messages are acknowledged with delivery receipts thus compromising the anonymity. From the moment I first heard about sealed sender I thought it as a false sense of security, especially given all messages including delivery receipts have sender/receiver IP addresses.
In spite of this I still recommend Signal in most cases for instant messaging and internet communication in general.
However, abuse of delivery receipts to spy on Signal users, and that Signal apparently has ignored this vulnerability, is concerning. See this thread.
I see this phrase thrown around a lot. With few exceptions, privacy issues are also security issues. They should be treated as such.
Revenue.
They run in the red financially and will eventually exhaust the large donations they got from some wealthy privacy friendly patrons.
If they don’t get enough donations or find a long term funding stream they are at significant risk of becoming insolvent. The down side of popularity is that server infrastructure gets really expensive at scale.
You are correct that privacy requires security. Signal is already a very secure platform, though, so in this case, what is needed is improved privacy.
I meant the reverse, that privacy is required for security, but yes, privacy requires security 