Session Encrypted Messenger
getsession.org
getsession.org
Keybase -> Stellar
Session -> Oxen/Loki
Whatsapp -> Diem/Novi
Signal -> Mobilecoin [0]
There really is no defence of introducing this at all and it's sad that this is becoming a trend, looks like one has to look at Threema, Wire and possibly Element as our only hope.
[0] https://www.wired.com/story/signal-mobilecoin-payments-messa...
Any centralized service like Threema is vulnerable to a court order to log, at the very least, connection metadata.
It's a LOT more expensive for LE to launch a Sybil attack on Loki than to get some bootlicking judge to compel logging and/or silent client update.
But yeah, I totally agree that the crypto scam is long-term unsustainable and Session needs to find a way for the users of Session to have to pay for Loki network access to keep it running.
To the point above, the biggest weakness of Session, by far, is that its official packages are released and signed in Australia. There is no doubt in my mind that .AU will eventually come down hard and compel signing of compromised binary releases. They HAVE to distribute official release building and signing to multiple developers around the world, and soon.
Does it somehow reduce the effectiveness of Signal Messenger?
The argument against Signal here seems to rest on the weakest foundation. As I understand it, it's something like:
- This could be a get-rich cryptocurrency scheme. We don't have any evidence for it, but you can assume the worst.
- The project embarking on this scheme shows they don't have users' best interests at heart.
- If they don't have users' best interests at heart, how can I trust any of their other decisions?
This is not an argument I'd want to hang my hat on.
I prefer that I can at least see it being sustainable, and if its a P2P protocol it could be free, but if they paid the developers well I would feel even better for various reasons.
That's why tor is so massive, because anyone can support it. But that's also what makes tor vulnerable to sybil attacks. It's a catch 22.
Either way, my warnings bells go off when someone asks for thousands of dollars for crypto coins that have no real advantage like Monero.
Another question that comes up with Oxen is what happens if it's adopted. Because afaik each onion routing node is also calculating the blockchain. So the more transactions happen, the heavier these calculations get, right? So each onion routing node will require a lot of resources eventually, if this ever takes off.
If you want to run 1 node you can obtain the oxen pretty easily. If you want to obtain enough oxen to control 50% of the network you will need to buy more oxen than is in existence.
State growth is an issue all blockchains face, but there are ways of addressing it. If oxens blockchain gets to 200gb in 40 years though i dont think that is an unreasonable expectation to put on the people running nodes.
So it is an issue to combine those two features, onion routing and blockchain. Because onion routing only requires bandwidth donation.
So for Session, I am unfortunately also sceptical on them as well, I would say they are arguably worse since their project is embedded within cryptocurrencies and it won't be long until they force their Loki/Oxen coin in their apps.
I did, you just didn't like the answer.
Fully distributed (while current solutions are centralized or, at best, federated), no single entity to be attacked, no dependency on phone numbers, being blessed by a server, or strange coins.
The political view on cryptocurrency that causes you to label it as a bad thing means you blanket category something that adds a lot of features to session.
I think tors uptake in general was limited because the FBI was able to still to track people, and here the cryptocurrency element fights against exactly that.
* https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...
XMPP is better than anything else I have seen for this sort of thing in that it is federated and gives you a choice of servers. There is no single point of failure.
Here is what that looks like using Conversations on Android:
"Which XMPP app should I use"
To which I dismissed XMPP its own as a viable alternative to anything, there might be hope for Jami as long as it is not linked to anything cryptocurrency and the security is sound.
If that is the consequence for multiple fragmented clients then no thanks.
Nobody bothers with Signal and all these other fringe privacy apps or alternatives.
That is my point.
Don't project that laziness onto the entire populace, enabling others to feel comfortable that it's "too hard" to use Signal....that's awful.
Unfortunately WhatsApp has a lot more staying power and social inertia than you would ever realise, regardless of how large a social circle is, and your anecdote doesn't change that either.
Until Signal supports all or most of WhatsApp's features I don't see this changing.
[1] https://support.signal.org/hc/en-us/articles/360007059752-Ba...
1) I don't have the infrastructure or the time to self host at the moment, and almost none of my contacts have the ability.
2) My XMPP experience (using Conversations and a couple of free servers online) was inconsistent. No attachments were delivered, message storage was limited to the client side, and a few niggles in general.
3) Matrix.org tended to be slow and unreliable for me, definitely more so than Signal. And as mentioned, I can't self-host right now.
If I could, I would have moved them to an open network, but for the reasons I mentioned and others, it's just not at the same level of convenience or usability yet. I might be more tolerant of these issues for advocacy's sake, but my contacts certainly wouldn't be.
It's still relatively early days for the project (launched last year), but I guess my point is - if the things you listed are all that's holding you back from XMPP, try Snikket and give us some feedback :)
'What platform?"
Then:
Tell them.
The point is, there are far too many XMPP clients for which it is very unlikely that their friends are on and have interoperability features.
edit: they touch on it here: https://getsession.org/blog/on-the-recent-australian-surveil...
But AFAIK with the news laws nothing is stopping the feds from requesting them to upload a backdoored apk one of these days (if someone can shed more clarity on that, I'd be appreciative).
This check box is actually quite import; I laugh at anyone who promises that "they won't reveal identities, not even under a court order" when the court can just force them to ship a silent binary update that does whatever the heck the court wants.
It's not available at F-Droid. They have an F-Droid compatible repository that you can manually add to your F-Droid client where they ship binaries.
I also can't find any mention of reproducible builds on their website, and their builts seem to include proprietary binaries.
The issue [0] to publish the app on F-Droid is still open.
The ticket also mentions spyware like Crashlytics and Firebase analytics, which according to Exodus Privacy [0] have been removed in version 1.2.3 (good): https://reports.exodus-privacy.eu.org/en/reports/search/netw...
I understand why some apps need to distribute updates outside of f-droid.org repo because it's too slow to vet/build updates: for example Newpipe needs to update as quickly as Youtube breaks 3rd party clients, and F-Droid's update vetting process takes too much time for that. But i don't understand why an app like Session would setup their own repo and not try to push to f-droid.org repo without the Google trash. [1]
At least, they're not actively trying to shut down libre forks (with spyware removed) like Signal did to LibreSignal years ago, that's already a very good point for them!
[0] Exodus Privacy is pretty cool. It uses static analysis to find known trackers/malware in Android APKs, and is developed by a french non-profit. If you don't use only F-Droid apps, you should definitely use Exodus Privacy to know what kind of crapware you're setting up. (Spoiler alert: >90% of Google Play Store is malware).
[1] The argument in the ticket is about the notification system. Because some Android (and iOS!) phones have energy policies preventing most background connections (unless privileged like for Apple/Google notification servers). That is not a problem on a device you own (eg. Replicant/Lineage) but is definitely a problem on CrapDroids (like Samsung and Huawei i believe) and on all iPhones, and this produces a situation where users will miss notifications until phone goes out of sleep and will blame the app for that, while their OS is responsible for the loss. One of the many shameful consequences of letting evil corporations control our computing devices, that leads to further centralization of all network activities.
On F-Droid on the other hand, the recipe is open source and the build process is automated and reproducible. That means if your threat model requires it, you can setup your own F-Droid build server and only download from it and/or verify all checksums of packages published on f-droid.org repo. Outside the Android ecosystem, that's precisely what GNU/guix project is doing with the guix challenge command: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
EDIT: So apparently their tokens are used to form market-based Sybil resistance:
> This supply-demand effect is further reinforced by something called lock-up. If Oxen is staked to a Service Node, it can’t be moved or traded — meaning that the purchasable supply reduces as the number of Service Nodes increases. If a prospective attacker attempted to buy up a massive amount of Oxen (in order to stake a large number of nodes), the cost would ramp up as they purchased, making it extremely expensive to actually conduct a successful Sybil attack. [0]
I find their FAQ very unclear so far (haven't read the whitepaper yet), but from what i understand Session is free-to-use because the servers (Oxen Service Nodes) are remunerated by cryptocurrency speculation (lock-up) and block rewards. I find it worrying though, that the entire threat model relies on the financial cost to mount an attack... I hope like with Tor, many different circuits can be built in parallel.
[0] https://getsession.org/blog/how-session-protects-your-anonym...
Improvements identified include:
1) Encrypted messages should have a constant size (padded). Note that the Signal protocol used by Session currently uses variable length messages[2].
2) Encrypted messages should be sent as noise by clients through the onion network and back to themselves at random intervals frequent enough that messages to/from other parties are statistically indistinguishable to an eavesdropper from the noise generated.
3) Intermediate nodes in the onion network should hold and delay encrypted messages so they are adequately mixed before being sent forward. This makes it statistically difficult for an eavesdropper to match up a message entering a node and a message leaving a node. Ideally messages would be mixed across enough nodes of the onion network that to an eavesdropper, the full list of possible destinations is equal to the total number of clients on the network.
4) Proof of work should be replaced with a better technique for preventing degradation of service or spam attacks. The paper quite rightly identifies that proof of work would favour Eve who has setup a data center filled with custom ASICs solving proof of work problems, rather than favouring Alice or Bob with an energy efficient mobile phone SoC. CAPTCHAs are identified as a possible future solution to this class of attacks.
I doubt those improvements would have much application outside of labs and experiments though. Unless a significant part of the global economy surprisingly becomes dependent on a traffic analysis resistant anonymising protocol, it is too easy to just block such protocols similar to what China does with its Great Firewall.
[1] https://arxiv.org/pdf/2002.04609.pdf
[2] https://github.com/signalapp/libsignal-protocol-c/blob/maste...
- no self-hostable server option (of course they don't have a federated model so interoperability will not be easy even if they release the server source).
- the encryption protocol is non-standard, does not sync between devices, and is not enabled by default.
I would really love it if there is a client-side encryption app which uses established time-tested encryption protocol to encrypt and decrypt messages fully at client side and will just let me use something heavily feature-rich like Telegram for sending the messages.
Perhaps because Telegram's servers store and have access to the entire message history (except for secret chats, that are very limited in features compared with both Signal and WhatsApp), and this really helps a lot when synchronizing among devices and managing groups -- all at cost of security and privacy. They also can selectively remove groups, and recently did it, so there is not a theoretical problem anymore.
Remember: they have all the information and can use it for anything once they turn evil (I call it "being bitten by a radioactive Zuckerberg").
But I can't see it gaining too much main stream traction any time soon. Too me it feels like WhatsApp has hit the sweet spot for people who can't get themselfes to care about security and privacy.
But maybe we'll get there, as more and more users understand the need for security
1) there's no source code. Security via obscurity is not a feature for software (but it's a first line of defense for networks).
2) Olvid is distributed via malicious repos Apple AppStore and Google Play Store
3) Olvid is distributed with spyware: https://reports.exodus-privacy.eu.org/en/reports/io.olvid.me...
4) They insist on "French tech", which is an ultra nationalist startup-nation label which does not imply any form of security, but rather that they report to french intelligence services (DGSI/DGSE) not USA intelligence services
5) They claim on the website that they're the first messenger certified by ANSSI, which is true but misleading. ANSSI has previously certified other secure messaging components (such as PGP implementations), and has very likely been involved in approving (though not certifying for private use) the french government's fork of Element matrix client (Tchap) as the official secure messenger application of the French government.
All in all, it's just a french startup making claims to make money. Nothing to see there, unlike Session which has some actual source code and novel approaches to show off (despite my reluctance due to blockchain tech).
2) If you consider AppStore and PlayStore as malicious repos you can stop using Android or Apple phone i think ...
3) if you search "network.loki.messenger" app on exodus you can find "Loki Messenger" (old name of Session ) with two "spyware" inside too
4) & 5) ok but i trust the very skilled person behind this software (https://dblp.org/pid/f/MatthieuFiniasz.html) that worked 6 years on this project.
I think Session is just another textsecure implementation (https://en.wikipedia.org/wiki/TextSecure) that limit meta data nothing new under the sun.
I've heard that claim so many times, yet very few startups hold their promise to open the source code. Especially for something branded as a secure messenger, how to give it any credibility without being able to inspect/audit the source?
> you can stop using Android or Apple phone i think
I use deblobbed android without google services -> replicant.us
> you can find "Loki Messenger" (old name of Session ) with two "spyware" inside too
I pointed it out in another comment so i'm aware. However these trackers have been removed in the meantime, and Session is actually free software which you can build from source.
> i trust the very skilled person
Good to see they've got a competent cryptographer, however competent cryptographers does not necessarily make a successful and secure decentralized messenger. See also Wire who had serious crypto and promises to open source everything, but to my knowledge the server side was never released, and Wire more or less failed as yet-another encrypted centralized messenger like Signal. Or GNU/Net who also has some solid research and practical applications [0], yet didn't grow so much over the years.
> Session is just another textsecure implementation
In fact not. It's certainly a TextSecure fork, but the only TextSecure implementation left is silence.im, whose maintainer is an employee of La Quadrature du Net from what i understand. But being SMS-based, silence.im leaks a lot of metadata (unique identifiers + timestamps).
And contrary to other TextSecure forks (like Signal), Session does not rely on a centralized infrastructure or sketchy "secure enclaves". Like i said i'm very critical of relying on a blockchain at all, but i have to admit Session looks (from a quick look) like a serious project.
The wire server code is open source AFAIK [0]
> This repository contains the source code for the Wire server. It contains all libraries and services necessary to run Wire.
Do you have any news about the open federation they announced in 2017 when they open sourced the server code? [0]
[0] https://wireapp.medium.com/open-sourcing-wire-server-code-ef...
After all, they need a new communications solution for their next January 6th event after Parler handed over their comms and that sweet ultra secure alt-right phone turned out to be a rebranded budget set.
It’s like shooting fish in a barrel.
But I cannot see anything done further here, and not sure if this means all members of the session project are nazis.
[0] https://nitter.42l.fr/JefferysKee/status/1281585770252230658...
(To be clear, I don't support banning either)
It is, more or less, a decentralised signal with onion routing.
Edit: apparently they switched away from the signal protocol 2021. It is no longer signal-with-onion-routing. It has diverged significantly sice they forked.
HN discussion: https://news.ycombinator.com/item?id=25690036
Summary: forward secrecy and deniability are nice to have, but removing them makes significant UX improvements possible.
- Session does not require phone numbers, which is Signal's greatest and well-known weakness and has led to a lot of (police/stalker) harassment
- Session uses some form of onion routing, and the messages arriving while you're offline are stored for a certain amount of time (TTL) by "Oxen service nodes" ; no centralized server controlled by Amazon & other evil corps relying on Intel's SGX "secure enclaves" (yes, that is actually Signal's threat model lol)
- Session appears to be involved with the Oxen blockchain where you can pay for a global username to be registered to your public key; i don't know if there's recovery mechanisms if you loose you key/device, but i do know it took me only two clicks from homepage to reach talk of blockchain and tokens and that does not inspire me confidence
- Session claims loud and clear to be developed by a non-profit and to be user/UX-oriented, which is great! Signal's finances and decision making have never been very transparent, and interviews published here in the past year implied they needed more users in order to monetize the platform (how?)