How do we know that it’s end-to-end encrypted and that it’s peer-to-peer (without examine the network traffic)? The source doesn’t seem to be available (I presume this is not open source) and there doesn’t seem to be a self hosting option. This brings me to my next question: what is the business model here?
Your page says “Share text and images instantly and securely across all your devices”, but I don’t see a way to send images. Is that on the roadmap or is the inclusion of images in this description a mistake?
Transferring data across devices on different platforms (like photos from an event, for example) is not easy if one wants to avoid messaging apps. Firefox Send and similar services hosted by generous people for others to use have different limits to manage costs and handle abuse. If this service offers transferring images and videos and the concerns about encryption and privacy are addressed, it could be very useful.
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.
This is very nice and simple. A few areas for improvement, in my opinion: the URL should be easy to copy, paste, or type into another device. I'd suggest designing the route like pindsend.app/pin/CODEHERE. Also, for some reason, copying and pasting the URL didn't seem to work in its current form. I would also consider implementing a QR code to allow quick scanning and redirection on another device, especially a phone, see Wormhole's implementation for reference [1]. Regarding security, the PIN looks quite short; I'd suggest increasing its complexity or length and automatically expiring sessions after a few minutes of inactivity. Additionally, definitely consider implementing end-to-end encryption if you haven’t already.
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
I am actually quite surprised and frankly concerned about the fact that wormhole.app constantly is considered as the wormhole protocol which, it frankly with its confusing name isn't.
It isn't the wormhole protocol. I am on mobile at the moment but someone can definitely link websites which are genuinely using the wormhole protocol as I was involved in the scene of learning about such protocols and the alikes of crocs and there was atleast one open source website based wormhole app.
Also,I may be wrong,I usually am but if you are suggesting the pin to be long and e2ee, then isn't that just pure wormhole, doesn't wormhole protocol also do the same?
Also, i may be wrong again but by p2p / webrtc. I was already imagining encryption. Isn't that the case with webrtc given I have considered it "secure"
There is chitchatter which can be self hosted with ease as a static app and I am pretty sure that one can reconfigure it to better suit the purpose of this app.
Cheers! Hope you can edit out the mistake. Appreciate it.
i often use the 'me' channel in slack, but not every device has that. similarly, between myself on apple devices, I might use 'notes' - which is fine (and long lasting) but I like this approach.
i do share the other stated concern about security. offering '5 minute sessions' and/or a way to 'approve' another device connecting would alleviate some concerns about a random unknown connection happening.
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.
This looks interesting. What I don't understand is: how was it implemented without a server relay. I am no expert in WebRTC (or P2P for that matter) but I always assumed that there needs to be a central location for users to exchange their addresses and only then a P2P connection can be established. This must be the case here as well right? Or am I mistaken?
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
If the server stores the transcript of a session, can it brute force the PIN later on?
Magic Wormhole (https://github.com/magic-wormhole/magic-wormhole) avoids this by using a password authenticated key exchange (PAKE) protocol. If you don’t use a PAKE, you get trivial brute force attacks from anyone with a transcript.
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).
WebRTC is end-to-end encrypted by default and only requires a tamper-proof, but not confidential, signaling channel for that encryption to be secure, so retroactive, or even ongoing passive, signalling server compromises are not a concern.
- I'd clean up less relevant bits as much as possible. The subtitle for example says "Share text and images instantly and securely across all your devices". I'd s/and\ images// and s/across\ all\ your devices//.
- There is a strong use case for sharing just text. I'd encourage you to focus this app on just that. If tempted to add file/image/whatever sharing, I'd break that out into something separate.
- The copy functionality for each text string shared is great.
- Why not make the qr code visible by default?
- Let your audience decide how they want to use string sharing functionality. Don't presume on their behalf. What if two technicians on either side of a theatre want to use this to share secret streaming strings? You'd want to make sure your messaging is welcoming to them too.
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 :)
If you're just sharing text, why do you need a website and a pin? Why not just encode it into a QR code and scan it, which most phones nowadays support? For files/photos a website makes sense because you can't send a 2MB file over qr code, but the text use case just isn't there.
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
I don't see mentioning of e2e encryption, that would be nice but I love the webrtc usage here!
Shameless plug: I built small file sharing tool with encryption in browser and added a "tunnel" feature to make it easier for sharing between personal devices : https://www.relaysecret.com/tunnel/
The aes256 key is derived from hashing the tunnel name but never sent back to backend as it is behind anchor tag and the tunnel name is derived from substring of this hash. It is quite fun to use and share files. The file never lives more than 10 days (bucket lifecycle) but user can reduce this to delete upon download and the code can easily be reviewed (back end is a single lambda function to generate signed url):)
Looks interesting, but I don't really understand how it works. I open the website, type a message, then I see my own message. I scan the QR code with my phone, then I also see a message window on my phone where I can type messages. Now both my laptop and phone can type messages, but the phone only sees the phone ones and the laptop only sees the laptop ones. Yet, somehow they are in the same session (since the phone scanned the QR code from the laptop). What am I doing wrong here? How do I send a message from one device to the other after connecting them in the same session?
This doesn't seem like something I'd market as secure. Couldn't someone randomly join your session through entering a random 6 digits? Seems like it would need to expire, have owners approve new connections, etc.
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.
I have a lot of suggestions and I would love to get into touch with ya on some suggestions as I have unplugged my computer for quite some time now and am solely on mobile at the moment.
Maybe on signal perhaps?
Now there are a lot of suggestions I can give.
Firstly, there is piping server through which I sent my brother some link using hello and he curled it and it felt so cool. I love piping server.
Secondly, wormhole protocol as I mentioned in other post.
There is also iroh.computer which is coming to wasm as well.
Theoretically, if one had to ask me the most private way though. My truest bet would be tor and onion routes though its a shame that additional software has to be configured for it. But if you don't mind a computer hosting texts "live" ie no middleman store the text (I am of course assuming webrtc works the same way)
Of course, there are a lot of fancy stuff but a big problem with them is that they have a huge link for better privacy I suppose.
One can use a link shortener. Wouldve recommended dub.sh earlier but I am seeing quite some limitations in it and the free tier to me personally the last time I checked if I remember correctly, was very slow but its still nice and can be used.
I reckon if one wanted collaboration of text, one could also use proton docs + dub.sh to a similar experience to your website except its more collaborative given proton can now support accountless edits in some sense(of course, I forgot its real name but it was in their blog post, I wish to create a github issues like stuff but using it but like in the web but maybe after some time, wish proton had better dev support.
Great idea. If I may ask Btw whats the tech stack and what services are you using to host it and do you intend to make money(unlikely I presume), what's your take on it
Cheers man. I have seen the world ignore people when they build something. I don't know but I want to say from the bottom of my heart that I think you made a meaningful change to world I suppose in its own manner. Of course, i watched the princess bride so I feel quite poetic at the moment but one must imagine you happy.
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
How do you set up the initial connection? A six digit alphanumeric code isn't long enough to include WebRTC connectivity setup data, so I assume a server is involved for at least that part?
Also, a small nit: The code is alphanumeric and also to be shared with the recipient, so it's arguably neither personal, nor is it a number ;)
Good job, it solved a problem you had and might be useful for others. I'd love to learn more about webrtc without getting a phd, are there any resources for dumb programmers that would get me up and running in a short amount of time?
I’m always interested in such solutions.
How do we know that it’s end-to-end encrypted and that it’s peer-to-peer (without examine the network traffic)? The source doesn’t seem to be available (I presume this is not open source) and there doesn’t seem to be a self hosting option. This brings me to my next question: what is the business model here?
Your page says “Share text and images instantly and securely across all your devices”, but I don’t see a way to send images. Is that on the roadmap or is the inclusion of images in this description a mistake?
Transferring data across devices on different platforms (like photos from an event, for example) is not easy if one wants to avoid messaging apps. Firefox Send and similar services hosted by generous people for others to use have different limits to manage costs and handle abuse. If this service offers transferring images and videos and the concerns about encryption and privacy are addressed, it could be very useful.
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.
This is very nice and simple. A few areas for improvement, in my opinion: the URL should be easy to copy, paste, or type into another device. I'd suggest designing the route like pindsend.app/pin/CODEHERE. Also, for some reason, copying and pasting the URL didn't seem to work in its current form. I would also consider implementing a QR code to allow quick scanning and redirection on another device, especially a phone, see Wormhole's implementation for reference [1]. Regarding security, the PIN looks quite short; I'd suggest increasing its complexity or length and automatically expiring sessions after a few minutes of inactivity. Additionally, definitely consider implementing end-to-end encryption if you haven’t already.
[1] https://wormhole.app
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
You indeed have already a QR code, my bad for not seeing it in the first place!
I am actually quite surprised and frankly concerned about the fact that wormhole.app constantly is considered as the wormhole protocol which, it frankly with its confusing name isn't.
It isn't the wormhole protocol. I am on mobile at the moment but someone can definitely link websites which are genuinely using the wormhole protocol as I was involved in the scene of learning about such protocols and the alikes of crocs and there was atleast one open source website based wormhole app.
Also,I may be wrong,I usually am but if you are suggesting the pin to be long and e2ee, then isn't that just pure wormhole, doesn't wormhole protocol also do the same?
Also, i may be wrong again but by p2p / webrtc. I was already imagining encryption. Isn't that the case with webrtc given I have considered it "secure"
There is chitchatter which can be self hosted with ease as a static app and I am pretty sure that one can reconfigure it to better suit the purpose of this app.
Cheers! Hope you can edit out the mistake. Appreciate it.
neat implementation!
i often use the 'me' channel in slack, but not every device has that. similarly, between myself on apple devices, I might use 'notes' - which is fine (and long lasting) but I like this approach.
i do share the other stated concern about security. offering '5 minute sessions' and/or a way to 'approve' another device connecting would alleviate some concerns about a random unknown connection happening.
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.
This looks interesting. What I don't understand is: how was it implemented without a server relay. I am no expert in WebRTC (or P2P for that matter) but I always assumed that there needs to be a central location for users to exchange their addresses and only then a P2P connection can be established. This must be the case here as well right? Or am I mistaken?
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
If the server stores the transcript of a session, can it brute force the PIN later on?
Magic Wormhole (https://github.com/magic-wormhole/magic-wormhole) avoids this by using a password authenticated key exchange (PAKE) protocol. If you don’t use a PAKE, you get trivial brute force attacks from anyone with a transcript.
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.
The pin would just be for coordination, not encryption.
Ah ok. How is the encryption key, if there is one, established then?
I think they just use the encryption and key exchange that WebRTC has cooked in https://datatracker.ietf.org/doc/html/rfc5764
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).
You're right, thank you for answering!
WebRTC is end-to-end encrypted by default and only requires a tamper-proof, but not confidential, signaling channel for that encryption to be secure, so retroactive, or even ongoing passive, signalling server compromises are not a concern.
Some feedback:
- Superb domain name.
- I'd clean up less relevant bits as much as possible. The subtitle for example says "Share text and images instantly and securely across all your devices". I'd s/and\ images// and s/across\ all\ your devices//.
- There is a strong use case for sharing just text. I'd encourage you to focus this app on just that. If tempted to add file/image/whatever sharing, I'd break that out into something separate.
- Shortening the url would be an expression of focus. Think https://pinsend.app/sessioncode .
- The copy functionality for each text string shared is great.
- Why not make the qr code visible by default?
- Let your audience decide how they want to use string sharing functionality. Don't presume on their behalf. What if two technicians on either side of a theatre want to use this to share secret streaming strings? You'd want to make sure your messaging is welcoming to them too.
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 :)
If you're just sharing text, why do you need a website and a pin? Why not just encode it into a QR code and scan it, which most phones nowadays support? For files/photos a website makes sense because you can't send a 2MB file over qr code, but the text use case just isn't there.
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
I don't see mentioning of e2e encryption, that would be nice but I love the webrtc usage here!
Shameless plug: I built small file sharing tool with encryption in browser and added a "tunnel" feature to make it easier for sharing between personal devices : https://www.relaysecret.com/tunnel/
The aes256 key is derived from hashing the tunnel name but never sent back to backend as it is behind anchor tag and the tunnel name is derived from substring of this hash. It is quite fun to use and share files. The file never lives more than 10 days (bucket lifecycle) but user can reduce this to delete upon download and the code can easily be reviewed (back end is a single lambda function to generate signed url):)
WebRTC connections are inherently end-to-end encrypted.
They use a self-signed certificate for DTLS-SRTP, and the fingerprint of that is sent over the signalling channel.
How are you managing the initial ICE offer/response negotiation without a relay server?
I do have server relay to setup webrtc connection and maintain session ids until those active.
upd: No relay for messages, messages are sent p2p
Even for messages, you may need a TURN server depending on the NAT configuration of the clients.
Apparently this is something I need to research as some people have problems using pinsend behind the NAT
Looks interesting, but I don't really understand how it works. I open the website, type a message, then I see my own message. I scan the QR code with my phone, then I also see a message window on my phone where I can type messages. Now both my laptop and phone can type messages, but the phone only sees the phone ones and the laptop only sees the laptop ones. Yet, somehow they are in the same session (since the phone scanned the QR code from the laptop). What am I doing wrong here? How do I send a message from one device to the other after connecting them in the same session?
This doesn't seem like something I'd market as secure. Couldn't someone randomly join your session through entering a random 6 digits? Seems like it would need to expire, have owners approve new connections, etc.
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
36^6 is 2,176,782,336, only a hair over 31 bits of entropy.
Unless you have some sort of throttling implemented, that's not really a lot and could probably be brute forced.
Throttling :)
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.
Hope you figure it out though!
Good point, thank you
Great job.
I have a lot of suggestions and I would love to get into touch with ya on some suggestions as I have unplugged my computer for quite some time now and am solely on mobile at the moment.
Maybe on signal perhaps?
Now there are a lot of suggestions I can give.
Firstly, there is piping server through which I sent my brother some link using hello and he curled it and it felt so cool. I love piping server.
Secondly, wormhole protocol as I mentioned in other post.
There is also iroh.computer which is coming to wasm as well.
Theoretically, if one had to ask me the most private way though. My truest bet would be tor and onion routes though its a shame that additional software has to be configured for it. But if you don't mind a computer hosting texts "live" ie no middleman store the text (I am of course assuming webrtc works the same way)
Of course, there are a lot of fancy stuff but a big problem with them is that they have a huge link for better privacy I suppose.
One can use a link shortener. Wouldve recommended dub.sh earlier but I am seeing quite some limitations in it and the free tier to me personally the last time I checked if I remember correctly, was very slow but its still nice and can be used.
I reckon if one wanted collaboration of text, one could also use proton docs + dub.sh to a similar experience to your website except its more collaborative given proton can now support accountless edits in some sense(of course, I forgot its real name but it was in their blog post, I wish to create a github issues like stuff but using it but like in the web but maybe after some time, wish proton had better dev support.
Great idea. If I may ask Btw whats the tech stack and what services are you using to host it and do you intend to make money(unlikely I presume), what's your take on it
Cheers man. I have seen the world ignore people when they build something. I don't know but I want to say from the bottom of my heart that I think you made a meaningful change to world I suppose in its own manner. Of course, i watched the princess bride so I feel quite poetic at the moment but one must imagine you happy.
This is a cool idea!
I solved it for myself using Signal, it has a "Note to Self" feature and you can access it with Signal mobile and desktop. It's also E2E encrypted. https://support.signal.org/hc/en-us/articles/360043272451-No...
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
Nice!
How do you set up the initial connection? A six digit alphanumeric code isn't long enough to include WebRTC connectivity setup data, so I assume a server is involved for at least that part?
Also, a small nit: The code is alphanumeric and also to be shared with the recipient, so it's arguably neither personal, nor is it a number ;)
Good job, it solved a problem you had and might be useful for others. I'd love to learn more about webrtc without getting a phd, are there any resources for dumb programmers that would get me up and running in a short amount of time?