“Also usability and battery drain on devices is getting better but you cannot use it as an instant messager yet.”
I have had no issues with battery tbh. Meta chat apps consume more battery tbh
What’s sketchy about the background?
Out of all the messengers, I would trust Briar and Session the most. One uses Tor and the other uses something like Tor. Other messengers like Signal are a huge target. I think services that are somewhat well known but aren’t super popular are the most secure, simply because when a service gets bigger, the chances of it becoming shit increase exponentially. This is just my intuition of course, not basing this on any evidence.
1 Like
What you’re saying is theoretically true, but also more popular projects are more likely to be reviewed/auidted and more likely for the community to find bugs, etc.
True, which is why I think it needs to be of a certain level of popularity, enough that it gets the attention of researchers and experts, but still below the radar. The perfect example is Tuta. They’re overshadowed by Proton. Tuta’s transparency report in contrast with Proton’s shows exactly what I mean. You can probably apply Price’s law here.
2 Likes
Session when it started was a project of Loki Network. Loki Network back then was accused, based on many presentations, of being run by extreme right people or group.
Don’t know the situation now cause i just stopped following the project when all this fuzz happened.
EDIT: Here some sources i was able to dig, for anyone curious: https://archive.is/5HF6q
EDIT2: Same more recent discussion on mastodon:
https://infosec.exchange/@WPalant/104489144670580454
Sure but just goes back to the part of supporting forward secrecy. Something that session removed cuz they believe it is not necessary. I don’t think there is a need for these additional options any more.
Almost a year ago, Oxen announced a transition from OXEN (their privacy token) to an Ethereum-based token named SENT, citing OXEN’s branding and inflation issues, isolation from and lack of interoperability with web3, issues with OXEN being a privacy coin, etc. To my knowledge, OXEN has been funding the anonymity network, and it is also used for purchasing of memorable Session names. I don’t know the current status of the transition, nor if the token change itself has/would directly harm Session’s protection of its users, but no doubt the annuncement would have triggered some people to abandon Session, and I don’t think most OXEN holders would want to migrate to SENT.
If the token change degrades Session’s userbase or anonymity network, that would be a concern for the safety of Session users. However, how does Session’s safety and effectiveness compare to that of other messaging software?
I had a read of their protocol explainer and technical details for references to forward secrecy.
On the surface I see merit to their adoption of simpler key management in the context of a decentralised network and multiple devices, but this unfortunately came with abandonment of forward secrecy and deniability, and I’m not convinced that’s acceptable or unavoidable.
Before the Session Protocol was deployed, messages managed over multiple devices went out of sync. In their Session Protocol, Oxen opted to simplify key management, citing impracticality of implementing complex key exchange processes over a decentralised network and multiple devices. Further, Oxen assumed that the only method that long-term keys are compromised is by “full physical device access” therefore so would all messages. They also claim (probably truthfully) the disappearing messages feature is rarely used. However, I don’t think the key compromise assumption is true when side-channel attacks, coercion etc are also possible. Abandoning forward secrecy based on their assumptions is a mistake.
Oxen cited unlimited account creation as an alternative to forward secrecy. However, this puts all the burden on the users to create a fresh Session account and share their Session ID to all their contacts on a frequent basis. Most people will not do this.
Forward secrecy is not the only casualty. This change also affects message deniability. My understanding is prior to the Session Protocol, like the Signal Protocol maybe, messages were verified with a MAC (message authentication code) that doesn’t act as a cryptographic proof that a message was signed by someone. Anyone who could verify a message’s MAC could also have created the message. With the Session Protocol, seems like all messages are irrevocably signed by the sender. However, putting things in perspective, Oxen claimed that courts have upheld messages submitted as evidence even when there is no cryptographic proof.
Oxen proposed adding the ability for users to edit messages that are stored on their own devices as a replacement for loss of cryptographic deniability, and additionally this would provide plausible deniability beyond just erasure of cryptographic proof. However, it has been almost 4 years since they proposed it but to my knowledge they have not yet implemented it.
Overall, I think it’s ok to keep listing Session for now, but warn the user about its issues, and remove Session if the migration to SENT compromises Session.
We already do so. Unfortunately it isn’t available anymore as Elon Musk kicked me of Twitter lol but I had lengthy discussions about this all with the CTO of session a few years back. We came to the conclusion of agreeing to disagree that their measurements are to be trusted to be sufficient for lacking forward secrecy. I do not agree that the network (largely controlled by them) removes this need. The fact that they first had forwarded secrecy and then just removed it is beyond me and unacceptable.
1 Like
We have Cwtch, Briar, SimpleX and Signal. I think PFS should be a minimum requirement.
4 Likes
Isn’t it on X or you cannot access it? If the later i can try to find those conversations, do you remember any detail?
I was banned from Twitter so no you can’t find it.
Session breaks post-compromise security, forward secrecy and repudiation.
1 Like
I agree PFS is desirable. However, putting things in perspective, metadata resistance is also not minimum requirement. Signal and Matrix are in the list of recommendations but don’t provide adequately protect metadata against network surveillance. Matrix isn’t E2EE by default, though it’s exempt because it’s quite different to other instant messsaging. There are some features that instant messaging tools are widely considered essential, like E2EE. Beyond that, people have different preferences, different threat models and different operating systems and devices; and a strict set of minimum requirements would cause exclusion of some suitable tools. Some people need PFS more than metadata resistance, other people need metadata resistance more than PFS. If there are enough tools that satisfy both then it makes sense to require both.
I like the idea of SimpleX, but I’m not yet convinced of its metadata resistance. Their website compares SimpleX to Signal, XMPP, Matrix and P2P but not Cwtch or Session 
, so I can’t even compare at a glance. I’ll have to look into it deeper.
1 Like
Cwtch seems to have better metadata protection than SimpleX, search for Cwtch on Privacy guides discussions, and see my last post there
Are you referring to that thread where Cwtch was talking about SimpleX? It’s just her word against his. They just need to sit down and talk it out.
2 Likes
I don’t think they are completely random statements without reasons. Cwtch seems to make some arguments, although they are not in such depth
You can’t protect your recovery phrase (seeds phrase) with a PIN or password.