A comprehensive analysis of messaging platforms, inspecting them both individually and in contrast to one another. The most ambitious crossover, if you will, with an infinite amount of writing time (help me).
In order for the ease of navigation, I've divided messengers into rough (emphasis on rough) categories. "common-sense" on exists because of the "common"; the exposure. I don't speak Filipino, my native language, fluently because I've spent more time on English, the language good at in comparison, but also in general. But I can infer translations from experience. Giving me an advantage of, say, a European, someone who's never heard the language. Same goes for the tech world. The following groups are made from my best understanding of a person who lacks common-sense in this field. As I am incapable of really knowing what that's like anymore. Curse of knowledge.
Session claims to be
designed and built for people who want absolute privacy and freedom from any form of surveillance.¹
But does does hold up? Time to begin the surgery, starting with...
On the other hand, the Oxen Network serves, hand-in-hand with Onion requests, to decentralize Session. On start-up, Session clients map 3-hop path, randomly selecting 3 nodes from the service list (hence 3-hop). Using the provided node's IP address, storage server port and X25519 key, clients create an onion, encrypting each layer with their respective node's key. The onion then undergoes the following process:
Upon receipt, the client encrypts the message with the final destination's X25519 key.
Even though Session is incapable of sending metadata (true to their slogan,²), they can still be obliged by the Australian government, via the Assitance and Access bill 2018 (AAA18), to reveal technical information, and/or other countries. I suggest you read their response to the bill for more information.
As of 15/06/2021 we have received 0 requests from 0 jurisdictions.³
Session utilizes The Oxen Service Node Network, based on the Oxen blockchain, in turn based on CryptoNote. The blockchain is used by Session in an attempt to alleviate the problem of
Sybil attacks from unknown parties attempting to run large sections of of the public routing network, which could be used to de-anonymise users.⁴
A Sybil attack is essentially when you flood a service with pseudoanonymous accounts, making democracy your puppet. Ergo, manipulating a blockchain. Controlling the narrative.
Session prevents this by creating a barrier of entry, 15,00 $OXEN staked, to integrate your node to the network. Naturally, the value of $OXEN rises as it is purchased, due to supply and demand, making blitzing significant percentages of the network impractical to attackers. The staking system also binds you to your stake, painting a big red "KICK ME" sign on attacker's asses. Once identified, either trust in the network drops, causing their stake to decline, or the stake is locked/destroyed by the network, in every outcome the attacker's budget plummets. They've effectively created a method of vetting each and every single member of the network.
Keep in mind, this happening is highly unlikely. Even if it does, they won't be able to break encryption as that doesn't give them the keys. Sybil attacks, are incredibly large-scale and require a lot of resources. In contrast, Session's targets, messages and who's sending them, are scant and there are far betters ways of hitting them. Finding ways to exploit vulnerabilities takes less time, less energy, thus leads to worthwhile capital for the attackers.
Another thing to take note of, there is no audit published for Session's implementation of End to End (E2) Encryption. The Signal protocol, as a whole, has been audited⁵ (as of writing this, September 7, 2021) once, which Session previously used.
Since Session’s first release, we’ve used the Signal protocol to provide end-to-end-encryption (E2EE)⁶
Unlike most messaging services (lookin at you Signal⁷ ), Session requires no phone number or email to create an account. Which is great, it makes it very simple, fast and painless. Even though, from what I can tell, this wasn't done for ease of use, I respect the decision a lot. I'm a little tired of services asking for phone numbers, more so because I don't have one. However, adding a contact is the opposite. You have the choice of using either Session IDs, which are long, randomly generated strings or scanning a QR code, which is equally as difficult. But you can't really blame Session, their goal was to make things private and secure, and for that, sacrifices had to be made. Should they take a less detrimental approach to this? That's up for you to decide.
The design of the mobile client is a refreshing sip amidst the drought of uninspired UI design. It makes some definitive choices, which I like. I think it's much better to have a stylistic vision executed poorly, than have none at all done with mediocrity.
On desktop, it's a whole other story. It's very Mac-like, let's not start a debate on if Macs look good, but it's strangely not well done? In comparison to, well basically any community Mac theme, it's pretty bad. Fonts have bad resolutions, I guess? I don't know what the technical term is, but when you zoom in on them a little bit they get blurry. Buttons seem to lack outlines when highlighted, scrollbars are a much darker color and the padding is ridiculously wonky and variable. Over all, it's a hot mess.
This image was taken in the desktop client on September 9, 2021.
The clients are just plain laggy too, they feel laggy, they look laggy, and it sucks that there seems to be no native application on desktop, just AppImages. Which I suppose are better than Snaps or Flats. Wait... What was that? Oh no-- it's the fanboys! I was just joking they're, the best packaging system ever I swe--
Anyway, something odd Confusion discovered was that even though Session displays messages as sending for as long as 13 seconds, when the messages are sent, the recipient will have to wait before they get the message. This might be the cast of bad UI design; loading bars and the like aren't mathematical, just rough approximations so the dev's could've ended this one too early, or messages really do function like this, where both ends need significant amounts of time to parse messages. Factoring in encryption and onion requests, the later would make sense, but there's no real way to tell that I know of.
The 6 MB file limit. Oh the 6 MB file limit. Look, I understand the logic "this is a messenger, not anything else", same logic they applied to calls by the way, but don't you think that people would, you know, like to send files a little larger than 6 MB? If you're not going to give people something practical, then do include it at all. Commit to being only a messenger, tell people where they can do other everyday things. Tell people about Jitsi, if they want to call, tell people about Nextcloud if they want to send files. You're not mature for doing something for a good reason, then abandoning the other work that good reason requires halfway.
Oh boy are people gonna be skipping here. I think Session is a really great project, on the technical side it is executed marvelously. In other usage, it fails spectacularly, but I admire it wasn't really trying to succeed in this scope. Thus, I wouldn't really recommend it for everyday use. What I would recommend it for is very specific cases where you require the utmost security and privacy.
Coming in soon(?)
1. Session, "Send Messages, Not Metadata.," Accessed September 5, 2021.
2. Session, "Send Messages, Not Metadata.."
3. OPTF, "Transparency Report," Accessed September 5, 2021.
4. Session, "Oxen Docs: Network Infrastructure," no. 1 (2021): 2.
6. Session, "Session Protocol: Technical implementation details," Accessed September 7, 2021.
7. Signal, "Register a phone number," Accessed September 6, 2021.
Licensed under EUPL 1.2.