sums it up well
Okay, but that brings me to my other point, which is that I don’t see how that is any different than what the changes in my proposal convey on a practical level.
I think we have come to conclusion that the proposal makes sense 
Them being on a separate page delineates the differences between them (recommending for private communication vs recommended for casual/non-critical communication).
Them being on a separate page also entitles them to having a different set of criteria which are much better suited to their strengths, rather than shoehorning in tools meant for public/non-critical discussions in a category whose criteria is the same as messengers meant for private communication.
ah i was not here yet, but this does make sense tbf.
The reason these were combined in the first place is because the distinctions between these products are very muddied. Most of them support public and private group chats, and they all support DMs.
Does that mean we don’t recommend Signal groups? Does that mean there are no scenarios where Matrix DMs make sense? etc.
My POV is that these tools all accomplish basically more or less the same function, which is why they are grouped together, and really the only issue we have here is varying levels of security, which is fixed by simply informing people about those varying levels of security. After we do that, we leave the determination between feature-sets as an exercise to the reader.
1 Like
okay actually this convinced me. I am with you @jonah. It does makes sense, I am actually in quite some communities on signal too. But I also see why people wouldn’t want that.
1 Like
What about if a Matrix/Discord competitor comes up that has equivalent security to Signal?
That’s fair. Good talk. 
1 Like
The proposal seems reasonable with me.
Status: In Progress → Done
Sorry to resurrect this one but there are some point re PFS that haven’t been touched on.
I was doing some digging on Session see here and they raised some great points about the PFS limitations of their protocol, which I think warrants a technical debate.
It seems like in session’s new protocol the PFS limitations are very niche and quite extreme circumstances would be required for the security limitations to come into effect.
If you believe their technical info on their protocol then you could describe it as APFS the A stands for almost 
To paraphrase them:
PFS becomes relevant when we assume the attacker has full device access, and thus the long term key, which is stored only on the device, is compromised.
In which case:
- “Reading all previous messages in the conversation by pulling plaintext message history directly from the device.”
- “Neither the Session Protocol nor the Signal protocol can prevent an attacker from this”
- Conservatively IMO over 90% of users keep their history and do not actively use self destructing messages or clear their history as they like to go back and reference messages. Even in the privacy community, how many dramas do we see filled with screenshots of chat history? Lots. See the recent GrapheneOS drama.
What about those remaining hardcore privacy nerds who use self destructing messages only? Surely Session should cater for them too for it to be recommended…
- “If the attacker has full device access and the user has disappearing messages turned on”
- “both the Session Protocol and the Signal protocol prevent the attacker from reading any previous messages”
Ohh okay then, so why isn’t it PFS?
- “If an attacker has both full device access and targeted network scraping capability, and the user has disappearing messages turned on”
- “the Signal protocol can protect users’ previous messages from being read, while the Session Protocol will not.”
They then go on to say the following which I won’t go into as this post is already way too long:
“There are ways for Session to limit the scope of this attack by limiting the data which an attacker can scrape, which will be discussed later”
Lastly before signing off let’s talk about how likely a targetted network attack is. To quote @keejef from Reddit who put it quite well.
"Service Nodes do have the ability to subvert the protocol and hold onto messages past their regular 4 day TTL.
So if we had a network attacker in Session who was roughly 10-20% of the network that passively stored all messages, and that same network attacker hacked into a users device and stole their long term keys, and the user had enabled disappearing messages then the attacker would be able to decrypt all past messages, even though there was a lack of message history on the device
Any broad network attack of this size would cost well into the multi millions of dollars (Staking 15,000 Oxen for hundreds of nodes) + the cost of specifically targeting the user to steal their devices long term keys."
So assuming you believe the above, we’ve established
- The flaws in Sessions Forward Secrecy are quite niche
- The likelihood of exploiting the flaws are quite low
Now if you factor in the advantages of Session such as anonymity at sign-up with no identifying info or metadata tied to your account, that the server code is open source and the fact that it’s decentralised with the benefits that brings then:
Does this niche use case really outweigh the other benefits that Session brings mentioned above? If you’re dealing with this sophisticated of an adversary, is Signal really ahead?
1 Like
This has all previously discussed extensively. I am not going to repeat the agreements.
It’s just insanely weird that session removed PFS while they could have easily kept it. There arguments for it sorry not sorry do not make any sense. They control the network.
Got a source for those ‘extensive discussions’? I just checked the Github for the old repo (apparently naming it gets my post flagged…), the new one for privacyguides, a few reviewers of private messengers I like and reddit but I’m yet to find anyone actually break this down.
They make the argument that with their limited sized team, reworking forward secrecy allowed them to introduce new functionality by streamlining the code. Haven’t done a pre and post comparison of the source code so can’t confirm they’re not making it up.
1 Like
I can’t see what exactly got flagged and why but just look at the privacytools repo archive and the github repo of this, even on this form. Its really a passed station man.
The giving up PFS for functionality is just BS. I can’t see any reason why this would be true and what would be the problem here. It just sounds like a lack of understanding of cryptography and how to apply it.