Works for me a lot of the times with Telegram Saved messages(similar features to Signal). But some devices won't be my personal so no access to Signal or Telegram
Because of two things:
1. I needed to send text from phones to laptop(no easy qr code scanning)
2. Sometimes I need to share a few hundred lines of text
That is exactly the case, there is a server in the background responsible for maintaining sessions and setting up WebRTC connections(ICE handshakes), when all clients are connected - messages are sent p2p
Thank you! I'm genuinely surprised by a level of feedback I get in the comments, constructive, thoughtful and actionable! Would love to hear from you if there a use case you found for yourself.
I've built this as a small utility for myself, by sharing it I hope that feedback will help me to make sure I do not make unnecessary presumptions :)
What do you mean by transcript? If you mean the messages that were shared - the answer is no, server sees no messages at all as message exchange is peer to peer via WebRTC. As soon as session is over(eg. When all clients disconnect) - message history is lost for good. Brute force attacks are theoretically possible for sessions in progress(though hard due to alphanumeric 6 character PIN and server throttling), so I'll introduce "safe session" as suggested by some of the commenter by introducing "waiting rooms" so the newly connected clients have to be approved. I'd definitely leave the current workflow as is as its frictionless and works for some of my usecases(quick link or log sharing, etc)
There are middle boxes between the two peers, yes? Routers and such. They observe the encrypted messages. They can brute force the password, even after the session is over.
Even if you assume the PIN is uniformly random (you should not assume this), it is only log2((10+26)^6) ~ 31 bits of entropy. This does not satisfy standard notions of secure channel establishment.
tl;dr: One peer generates a self-signed certificate and sends the fingerprint of that over the signalling channel; the other connects to it as a "client".
The resulting DTLS keying material is subsequently used for SRTP encryption (for media) and SCTP over DTLS (for the data channel, which is presumably what's being used here).
Thank you for feedback! Theoretically it's possible, but it's not just digits, it's alphanumeric so the chance is very low. As another user suggested - I will add approval for new clients so it's not going to happen
Yea, don't get me wrong but bruteforcing is real and I am not sure if its quite secure even with alphanumerical. Again I can be wrong but I'd personally wager a little bit more focus on privacy while still keeping The convenience but of course there are trade offs and its hard to do it quite right.
Thank you! Device approval seems like a legit way to make it more secure. I also used messaging apps and notes and emails, but then my channels are full of temp messages and not all devices I use have those.
Thank you for the feedback and wormhole.app suggestion! As for QR code - it's already available after you've set up your session, but UI might not be as obvious so I'll work on it.
For PIN code - you might be right, though brute forcing PIN codes with 6 alphanumeric characters and throttling on signaling server might not be as easy as it seems.
Communication inside a sharing session is end-to-end encrypted as it uses WebRTC, and session will "expire" as soon as all clients are disconnected, because no data is stored on a server - it's all between connected clients
Thank you for your feedback! I do indeed have file transfer in the roadmap and was planning to launch with it(thus the leftover text, thank you for noticing), but file sharing over 100 Kb is still buggy, so it was disabled until better times. It's is buggy because no data goes through my server, it's all P2P using WebRTC(which e2e encrypted). As for open sourcing it - I will consider it as I do not plan to charge for this tool.
