Hacker News new | past | comments | ask | show | jobs | submit login
[flagged] Show HN: I built a website to share files and messages without any server (neighbor-share.vercel.app)
132 points by dkraj on May 5, 2024 | hide | past | favorite | 105 comments
NeighborHoodShare: It is a p2p files and messages sharing platform without involvement of any server. It has end-to-end encryption, ensuring your messages and files remain confidential.

These are some features: - Share photos, documents, videos, and more with ease, no matter the size. - Connect instantly with anyone for speedy and reliable file transfers, bypassing the need for centralized servers. - Get started in minutes with our intuitive interface designed for seamless communication. No registration. - Easily connect with others using QR codes, simplifying the sharing process further.

The inspiration behind NeighborHoodShare stemmed from a common dilemma: the reluctance to share personal contact details like phone numbers or email addresses when sharing photos or messages with strangers. With NeighborHoodShare, you can share content securely without compromising your privacy.

I would be happy to hear your feedback and suggestions for improving NeighborHoodShare.

I had written a blog on how p2p networking in browsers work: https://dikshantraj2001.medium.com/nat-stun-turn-and-ice-466...




You’ve done nothing but submit half a dozen random extensions in the 3 weeks that all collect different personal information on browsing history at a minimum. Your README’s look AI generated, and you’re a completely anonymous account. Additionally, your responses on how files are encrypted here is severely lacking.

All I can say is: There are a lot of red flags here.


Yes you are absolutely right. I had replied on other threads. Files are not encrypted. WebRTC provides encryption on all sessions


I looked around and couldn't find a description of the protocol by which two peers authenticate to each other/transfer files. Also, is the E2EE encryption referred to simply whatever is being used to encrypt the transport(DTLS/SRTP/etc)? or are you doing additional encryption/decryption of files?

Also I'm curious like others, does this only work if no nat traversal is required? or are you leveraging public stun/turn infrastructure?


WebRTC it is: https://webrtc.org/

Yes only the network layer encryption. No file encryption as it will cost client browsers a lot in case of encrypting and then decrypting that at other end.

I have written more about it here: https://dikshantraj2001.medium.com/nat-stun-turn-and-ice-466...

Currently, I am using the public STUN servers only. If the IPs are not reachable, it would show an error and won't work as setting up TURN server would mean same as a third party server saving in file and serving it over network


You can use https://npmjs.com/e2ee.js (disclaimer: I am the author) for basic end to end encryption in the browser (uses the webcrypto api). It supports encrypting and decrypting a web stream as well which you could use.


Ideally I would not have to trust the signalling server to ensure I'm transferring files to who I think I am[0]. Not as much of a knock against your project as a knock against webRTC in general.

[0]: https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks...


Has anyone considered a passphrase that splits into three words, where the middle server can decrypt one word and deliver a word and get a response then provide the whole phrase three words to prove it is the messenger that Bob sent?

Or something like that?


It's webrtc, no?


yes it is using webRTC. will open source the repo soon. BTW there are all information about it in different threads


> without involvement of any server

> bypassing the need for centralized servers

I don't follow this part... it's using a centralized server to serve the web app, which could easily serve JS code that steals confidential data right?


That is true, but unless you develop an application yourself, it is always coming from somewhere else.

Web apps are better than native apps from a security perspective. Browsers have fairly decent built-in debugging tools that you could use to verify that data isn't being uploaded to a 3rd party.

On the other hand, to do the same with a native application you would need to use a separate network protocol analyzer application.

Web apps also run in a sandbox that users tend to have fairly good knowledge about. For example, they generally cannot access any file on your device unless you grant permission. What are the limits of the iOS, OSX, Android or Windows application sandboxes? Can apps on those platforms access files without explicit permission? I think the vast majority of users wouldn't be able to tell you.


> Web apps are better than native apps from a security perspective.

This isn't true. Sure, they have less access to the host system, but verifying the integrity and authenticity of a web app is harder than that of a native app, where code signing is commonplace (not that code signing is a whole solution, but it's a great start). Extensions[0] exist to improve the situation but it's not yet broadly applicable.

A compromised web app doesn't have to upload your data to a 3rd party, it just has to (for example) encrypt with weak keys. You'd never notice that from the network logs alone.

And while I agree that debug tooling for the web is great, there's a lot of great stuff for native code too. Ignoring "expert" tools entirely, a more user-facing example is Little Snitch[1], which handles the "detect data being sent to 3rd parties" use case.

[0] https://engineering.fb.com/2022/03/10/security/code-verify/

[1] https://www.obdev.at/products/littlesnitch/index.html


1) For ~everyone, the authenticity check for an app is simply whether it exists on an app store. I think the only time I ever checked the signature on software outside the app store is for my bitcoin wallet.

2) Legit trusted applications are already what siphons everyone’s content, not malware. At least in the browser there’s uBlock Origin and even a dev console.

Just some things to keep in mind when comparing the differences.


Right, and your device knows it came from the app store because of code signing.


You have to trust the original developers either way, but the distribution mechanism is much weaker for a web app. The server / hosting platform can be compromised, the code can change at any time and even depend on the client that's connecting, and there's no software signing providing non-repudiation.

Not saying native apps are universally better, but I do think their treat model tends to be a better match for encrypted messaging. This comment on Signal explained it well: https://community.signalusers.org/t/google-to-retire-chrome-...


The signature doesn't mean much on the mobile store though, Apple and Google could modify anything they want, resign it and push a new app.

With the web you have to trust the app developer and with mobile you have to trust the app developer plus Google or Apple on top of that.

Fdroid is maybe the only exception to that.


> With the web you have to trust the app developer

The linked comment goes into it, but you have to trust the web hosting platform, the CA ecosystem, etc. We're talking not just Apple/Google being able to attack you, but also China, and even some script kiddie with a Node.js exploit.

> with mobile you have to trust the app developer plus Google or Apple on top of that.

The OS/browser vendor can record what you're doing with a web app just as easily as a native app. Thankfully they have very strong incentives not to do so, and can usually be held accountable with code signatures (the non-repudiation part).


There's much much better transparency mechanisms on the CA system than Apple or Google though. While a CA attack is possible and does happen sometimes, the attacker pretty much burns the CA in the process.

For starters, there's not even automated reports of app signatures on mobile and no transparency authority at all.


With web you have to trust the developer on every visit of the website. With mobile you can pin the trust (with some effort) to a single point in time, big positive difference


I'm not aware of any major mobile platform which works like that though, maybe in theory it could be done but in practice it's all powers to the manufacturer which can modify or remove your apps at any time silently.

Unless maybe you are on some things like GrapheneOS and only install apps though fdroid, that's not really a mainstream configuration though.


How can they modify the app on your device silently?


They have system access and can push anything on your device. In the past you could have an actual developer signature on the play store but Google got rid of it, on iOS there's never been any support at all of this kind of security.

Fdroid supports that but you need a modified rom so that the play store cannot interfere with it in any way. To my knowledge, only GrapheneOS does that.


Your explanation confuses the store with the device .Yes, at the time of download from the store you trust two parties, but that's still only "a single point in time"


No it's anytime you use your device. The stores can push silent updates and change your apps or access anything at any point.

The only exception I'm aware of is GrapheneOS where that's not possible. Otherwise if you are using iOS or any other Android rom than GrapheneOS, you are vulnerable to that.


Do you have a source for the silent remote app install for iOS by Apple, only heard of a remote disabling (but not removal) of an app there?

Though even in that case the dev can't do that, so your trust is :

web: dev every time you load an app

native: dev once you install an app, OS vendor any time


You're extolling the virtues of web apps, but none of your points address the point that it requires centralized components. Which is an important point for something that advertises itself as P2P. Both to serve the application every time you open it and ICE servers for webrtc connection initialization every time you share a file.

A native p2p application needs to be downloaded or built once, from any place (say a git mirror) and bootstrap to its overlay network and then you're in.


Who is going to tell them. Your browser is a native app.


Didn't get the part of steals confidential data?

It can not do anything without your permissions. All websites are well scoped and run in their private environment in a web browser.


I mean the data people send through the app. You say:

> It is a p2p files and messages sharing platform without involvement of any server. It has end-to-end encryption, ensuring your messages and files remain confidential.

However the clients get the JS code from the web server. Since you control that server, you can change the code to disable the encryption, or send a copy of the messages somewhere else. You can even make the server give specific people / IPs one copy of the code and others a different copy.

Hence my point is there is a trusted centralized server involved.


Got you so you want to say that the place where I have hosted is a centralised place and yes you are right. But I won't do that ~~~


Sure “you” won’t do that. But who are you? What if “you” changes? “You” could be the CIA or a Nigerian scammer. Nobody knows. And it can change at any moment.


Ah yes, we should completely trust the anonymous person who registered to the site 23 days ago and has done nothing other than submit half a dozen chrome extensions to the site since then


How can this work without a a server? You surely need a third party to traverse NAT.


It's using WebRTC's P2P. It does require internet but the middleman is absent in file-sharing.


WebRTC's P2P does require servers; and sometimes even a middleman (TURN). OP wrote about it in https://dikshantraj2001.medium.com/nat-stun-turn-and-ice-466...


Glad you liked it :)


If at least one party is behind NAT, it's a dead end. I wouldn't trust anyone who makes a false claim it's possible.


Please Google udp hole punching


In order to do hole punching you need a centralised STUN server.


We need a STUN server to traverse NAT and get IP addresses but it does not use server to store or share the file. Only ice candidates are gathered, discovered and a handshake is facilitated by a STUN server. If that is not possible it shows error.


There have been plenty trusted battle tested open source implementations of WebRTC-based p2p transfer.

Why would I use this one instead of them?


Could you please name these implementations?


https://file.pizza/

https://github.com/kern/filepizza

Is one. But I've seen more.


Just a few that are both open source and have the hosted public versions available:

https://github.com/RobinLinus/snapdrop

https://github.com/jchorl/sendfiles

https://github.com/szimek/sharedrop


Here is the source code:

https://github.com/dikshantrajput/neighborHoodShare


No offense, but why would people use this without associated source code for anyone to scrutinize? Why keep it private? WebRTC based tools like this exist so it’s only a red flag IMO to keep it private.


Had open sourced it. You can check it at: https://github.com/dikshantrajput/neighborHoodShare


Obligatory callout to the excellent server-free CLI file transfer tool magic wormhole which is open source and battle tested


> This program uses two servers

> the mailbox server, and the transit relay.

The dream of the P2P internet died with NAT.


I hoped that it would relive with IPv6 but apparently this will not happen while I'm alive.


There's a website... but no server?

Language sure is weird...


"Share files and messages without server"


TURN and P2P are incompatible things.


OP reply says they use STUN, not TURN.


Looks good but any plans to make it open source?

Similar open source solutions exist like:

- https://pairdrop.net/

- https://wormhole.app/

- https://www.snapdrop.net/

How does this compare?


The "wormhole" you linked is closed-source, perhaps you meant this one, which is open-source (and iirc came first, but presumably has a smaller SEO budget)

https://webwormhole.io/

https://github.com/saljam/webwormhole


https://www.sharedrop.io/ as well. It's open sourced, too.


This doesn’t seem to work on iOS Safari.


I've been hosting my own pairdrop for a year now, very easy and quick to share a file between my smartphone and laptop without digging out a usb cable.


I've got another one on the topic of self-hosted file sharing:

- FileBrowser (https://filebrowser.org/features)

- Syncthing (https://syncthing.net/)

Run both as Docker containers on a server at home. Syncthing keeps the files on your PC, Mac, and BSD systems in sync, and FileBrowser can point to the sync share and supply a convenient web UI for phones, etc. It works for me, it's kind of like a local Dropbox.


Syncthing does not need a server to work over the LAN, and I think you can set it to only use peer discovery over a LAN. You can disable pubic servers, but data sent through them is encrypted anyway.

Syncthing + KDE connect does a lot.

The only issues I have had is that I cannot ensure that both are always running on android.


Oh for sure, Syncthing absolutely works peer to peer. But I find it useful to have a central always-online hub for clients to sync to.

For example, imagine you save a file on your laptop then put it to sleep. You turn on your desktop and the file isn't there because the laptop is now asleep. Having a central 24/7 Syncthing server allows the share to always be available.


Funnily enough, the only issue I have with kde connect is I can't get it to not run on Android; always starts in background somehow.


I use KDE Connect for that. Have you given it a try?


Thank you for introducing me to this! Life transferring files and holding presentations will be a lot easier from now on


No, I did try the Gnome equivalent a long time ago but these days I use a more minimal setup. So I'd prefer a CLI tool.


I like the wormhole-william[0] Go implementation of "Magic Wormhole" protocol on the CLI. There's a couple of compatible Android apps[1][2] in the F-Droid store and Rydmport[3] for your GUI loving friends.

[0](https://github.com/psanford/wormhole-william)

[1](https://f-droid.org/en/packages/com.pavelsof.wormhole/)

[2](https://f-droid.org/en/packages/com.leastauthority.destiny/)

[3](https://github.com/Jacalz/rymdport)


KDEConnect can be used from the CLI :)

  kdeconnect-cli --share [url|path/to/file] --device [device_id]


I really want to like kdeconnect because when it does work, it works well, but in my experience it just has way too many bugs and seems to randomly stop working for unknown reasons.


What is the Gnome equivalent? If you mean GSconnect, that's an implementation of kde connect. I think kde connect has some CLI tools, but they're not super ergonomic.

For CLI stuff, I usually just run the python http server or woof and make a QR code with the URL.


What about sharing from your phone to your laptop?


KDE Connect allows you to send individual files both ways and also to browse files on your phone from your computer. It is also capable of sharing the clipboard and open link from one device to another, as well as controlling input (mouse and keyboard) from another device.


Yeah I know but we were talking about CLI alternatives and the person said they used a quick python http webserver, but that doesn't work the other way.


Personally, I use pairdrop for that. Though, if I'm limited to CLI, woof has an upload option (-U) allowing me to select a file from the phone. Don't know of an easy way to do that from the builtin http.server.


kde connect runs on laptops and phones?

https://kdeconnect.kde.org/download.html


I use Telegram for that. Also good for taking notes or reminders for yourself without having to use a separate app.


Are messages to self even safe on Telegram?

Secret chats don’t work between the desktop client and the app, so I would suspect that, like the rest of the messages, everything is saved on telegram’s servers in the clear.

Or am I missing something?


Telegram has cloud encryption via MTProto 2.0. The servers use a distributed key generation mechanism.


Telegram is not end to end encrypted, and thus not suitable for such uses due to insecurity.


Telegram has cloud encryption via MTProto 2.0. The servers use a distributed key generation mechanism.


Cloud encryption is just HTTPs + encryption at rest (only claimed, not verified).

They hold the keys, irrespective of how many proprietary protocols they wrap over the message.

A great product tho! I used saved messages extensively!


> Cloud encryption is just HTTPs + encryption at rest

Not just plain-old HTTPs. MTProto 2.0 is a whole encryption algorithm for Cloud chats: https://core.telegram.org/mtproto/AJiEAwIYFoAsBGJBjZwYoQIwFM...


In the end, they hold the keys irrespective of how many algorithms they wrap on top.

I do not feel it is any different from Google Chat, Twitter DMs, etc. They do have a lot of censorship resistant and anti-MITM attack features in between, but they hold the keys by default

I use it for convenience and amazing features, not for security!


Same here! I use Telegram Saved Messages a lot! It's fast and very convenient.

Telegram doesn't support markdown though, that's why I decided to build writedown.app


Signal, too. I have 3 profiles set up that are basically 'notes to self'.


Non-open source - https://file.pizza/


It is though? https://github.com/kern/filepizza


Oh, my bad!


Yes will make it open source in future. Just need to clean the code a little bit and make few more changes.


What about the second question?


Sorry I missed it. but can you elaborate on compare please


What makes it different? (I'd personally like to know the details of how the cryptography works)


In terms of differentiation, I have not explored much solutions available out there so can not comment much on that. About the encryption part, WebRTC communications over browsers are encrypted using Datagram Transport Layer Security (DTLS). All WebRTC sessions are encrypted.

You can found more in depth details in this article: https://telnyx.com/resources/webrtc-encryption-and-security

And sorry for not replying I was not on the platform lately


I don't think DTLS alone would be considered end-to-end encryption. For E2E the application layer has to be responsible for encryption and decryption.

Are you employing E2E on the client side? Encryption during transit shouldn't be claimed as E2E. Please correct me if I'm wrong.


also https://github.com/schollz/croc


A bit off-topic, but since I was looking at doing a side project with a P2P feature, would appreciate if I could pick your brain for a bit: don't you still need to run the STUN and TURN servers? Can you run those using Vercel's serverless functions?


look at https://peerjs.com that this the project is using.


This looks like an implementation of STUN - there are no miracles, if two machines are behind NATs someone need to broker the connection.


Hmm thanks, so that says:

> To broker connections, PeerJS connects to a PeerServer. Note that no peer-to-peer data goes through the server; The server acts only as a connection broker.

> If you don't want to run your own PeerServer, we offer a free cloud-hosted version of PeerServer.

So I suppose there's still a server, but it's shared and run by two folks based on donations: https://peerjs.com/peerserver


Without data going through the server it should be pretty cheap to host, right?


That is why there are public STUN servers available by google that any one can use: stun.l.google.com:19302 stun1.l.google.com:19302 stun2.l.google.com:19302 stun3.l.google.com:19302 stun4.l.google.com:19302


I used peerjs years ago (2013~). It was a whole lot of pain back then... I assume things have gotten better, but damn was it painful! I ended up forking and fixing/maintaining my own fork because it was too slow to get things fixed in master.


A STUN server is required for discoverability and if still ICE candidates are not found or a negotiation can not take place, I just shows an error for now. About vercel I am not sure need to check whether it provides or not


I'm curious about the effectiveness of your other app, NoFap, a browser extension. You might need something a bit less easy to control to make it useful. Just my two cents.


Can you please elaborate




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: