I’ve used Session messenger that’s recommended and it has two critical flaws:
Link preview leaks your IP when pasting links
The onion route can have the first and last hop before the destination be the same server IP.
After looking into the GitHub repo these problems have been raised quite some time ago, but the issues remain open:
In addition to this, all attachments that are sent are written to the disk if you’re in groups and everything in 1 on 1 conversations after accepting the first attachment. There’s no way to disable this either. Also the option to clear data doesn’t appear to shred it as far as I can tell.
I find other design decisions to be dubious but not as critical (i.e. the decision to remove PFS, and the logic behind their sybil resistance being that it’d be too expensive but would be budget rounding error for an APT targeting journalists) and just wanted to mention this too so everything is out there.
Has anyone else ran into these issues or have similar concerns?
I don’t use the desktop app all that much but I do find it massively annoying that the android app doesn’t work with bluetooth headphones for calls. Yes, calls are a beta feature… introduced in April 2022 (Hey, I just met you, and this is crazy: Calls beta release - Session Private Messenger). For me it demonstrates that their development is veeeerry slow even when it comes to basic functionality
This is the correct way to handle link previews, and matches the behavior of all secure messengers (except Matrix?) AFAIK.
You should disable link previews if you are concerned about this, but the reasoning is that if you are pasting a link you’ve presumably already visited the website you’re linking to, so it’s something you’ve previously established a connection to.
Session shouldn’t just emulate the behavior of the other messengers. Unlike most other messengers, Session routes its messages through its anonymization network. In that context, I consider generating link previews via clearnet connections to be a leak, and I wonder if Session users are aware that happens. Session shouldn’t presume that the user has already visited the website let alone visited it using a clearnet connection.
Personally I hate the link previews function for this reason, so I just disable it in all my messenger clients.
That modal could use some refinement, as it’s currently a bit vague about how your IP address might be exposed during the preview generation process.
The actual process for generating a link preview in Session is:
You type or paste a link into the Session client.
Your Session client connects directly to the website in the link to fetch the preview image and other metadata. This connection reveals the generating clients IP address to the web server.
You click send
When you send the message, the preview image is encrypted with a random ephemeral key and uploaded to a file server using onion routing (either the Session file server or the Session community depending on the conversation type).
Once the upload is completed the file server returns a unique link to the uploaded preview image.
The message is constructed with the encrypted image link, the decryption key, and the rest of the preview information. This is then sent to the recipient(s) using Session’s standard onion message routing.
On the receiving end, clients fetch the preview image from the file server using onion routing. All other data needed to display the preview is contained within the message itself, which is also retrieved using onion routing. This means only the sender’s IP is exposed during generation, never the recipient’s.
Onion Requests
I believe this issue has since been patched, although Session will soon move from onion requests to a full Lokinet integration which has more complex logic to prevent nodes run by the same operator or in the same subnet from being used in the same path.
Note: With full Lokinet integration Session clients should also be able to generate link previews using onion routing rather than connecting via the raw client IP, making link previews more private to generate.
When a client generates a link preview, it is not just the client’s IP address leaks to the link’s target web server but also the domain name from the DNS request and the data (content and metadata) sent/received between the client and the link’s target web server leaks to whoever monitors the network traffic. Am I correct to say that?
To be pedantic, the IP address leak happens at the time of generating a link preview, not when it is sent. A link preview generated but subsequently discarded without sending is still subject to leaks.
I think the modal could be phrased like shown down below, but probably could use improvement. However this ignores leaks that happen when sending and receiving link previews via Session servers (steps 4 to 6).
Generating link previews leaks metadata including your IP address and the link for which the preview is generated.
I’m no tech-savvy enough to be aware of these issues, but as someone who does use Session, and mostly on desktop, I have a lot of problems with their UX & UI. There are missing features that they could easily implement.
