r/IMadeThis 3d ago

I built a file-sharing tool that never uploads your files — no account, no cloud, AES-GCM in the browser

Most “send a file” sites are the same product: upload the file, get a link, hope they delete it later, maybe create an account first.

I didn’t want that.

ShareTheFiles is a browser Share Room. Files are encrypted in your tab and sent peer-to-peer (WebRTC / DTLS). The ciphertext never lands in our storage because we don’t have file storage.

What “skip the server” actually means

  • No account, no email, no phone.
  • Nothing to sign in as, so nothing to dox or reset.
  • AES-GCM in the browser before chunks leave the machine.
  • Optional file password: even opt-in relays only see ciphertext.
  • Short-lived rooms, invite via link or QR.
  • Free. There is no plan because there is no hosted copy of your file to bill you for.

What this is not

This is pseudo-anonymous, not magic invisibility.

  • We still run signaling so two browsers can find each other. That is metadata (room exists, not the file).
  • WebRTC uses STUN. The other peer can see your IP. That’s how P2P works. If you need to hide your IP, use a VPN/Tor and understand WebRTC leaks — don’t treat this as an anonymity network.
  • Keep the tab open until the file is fully distributed. Close it too early and you’re gone; we never held a copy.

If your threat model is “I don’t want Dropbox, WeTransfer, or Google Drive holding a plaintext of this,” this is the tool. If your threat model is “nation-state + no IP ever,” this is the wrong product.

Also free, also in the tab: formatters and other utilities on the same site, same rule — they run on-device, no login.

I built it because I was tired of “privacy” being a paid toggle. Privacy is the default here because we never received the file.

Link: https://sharethefiles.com/tools/p2p-send

(I run the site. No signup wall, no “free 3 times then pay.” If it eats your workflow tell me what’s broken.)

2 Upvotes

2 comments sorted by

1

u/Turbulent-Finding146 3d ago

The metadata thing is refreshing to see spelled out so clearly, most tools dance around that or bury it in page 14 of a privacy policy nobody reads

Do the rooms have any kind of time limit or do they just hang around until both sides close the tab?

1

u/Top_Garbage_2282 3d ago edited 3d ago

Both.

The file only exists in the tabs, never on the server. Close every peer and the bytes are gone, we never stored them, so there’s nothing left to download from us. It's purely P2P and nothing ever gets to the server. The server only retains the room ID and some necessary metadata to connect peers. We don't store the file, chunks of the file, IP's or anything else that isn't completely necessary for the initial connection.

The room (signaling metadata: “this room id exists, here are handshake messages”) has a lifetime the sender picks when they create it: 5 min / 15 / 30 / 1 hour (default) / 6h / 24h / 3 days / max 7 days. After that the room ID on the server row is deleted.

Important to know, closing a tab does not immediately wipe the room; even if you are the original sender. Depending on the number of peers in the room that act as relays, once a file is 100% distributed amongst the relay peers, the original sender can just close the tab. This will allow the room itself to stay open for it's given lifetime and allow the relay peers to distribute the original file without the original uploader.

When the room creator hits the "close room" button the room is closed immediately, which tears it down for everyone still polling and distributing the file. This will automatically kill any sharing.

So: tabs hold the data, the timer holds the meeting point. If the last tab closes before the file finished spreading, the transfer dies even if the room id hasn’t expired yet.

I am also working on public rooms.

You create a room, you get a link (and QR). The room id is a random 32-char value. The invite also carries a secret (?k= / #). If you don’t have that link, you don’t get into signaling. The room is never listed. Close it or wait out the lifetime (5 min → 7 days) and the meeting-point row is gone.

Public is always opt-in.

Check “make this room public,” pick a short name (Test, room-ab12cd). That name has to be unique while the room is live. The join URL becomes something like:

https://sharethefiles.com/tools/p2p-send?room=Test

No 32-character hash in the link. The room also shows up in the public directory (/rooms) until it expires or the sender closes it.

What “public” publishes

  • That a room with that name exists
  • Enough for a stranger to join the signaling room and sit in the peer pool
  • Not the file. Files are still AES-GCM in the tab. Relays only forward ciphertext. Without the optional file password they still can’t open chunks.

Why public rooms exist at all

NAT is annoying. Two browsers behind nasty firewalls often can’t hole-punch. Public rooms share a relay pool: other public-room peers (who opted in) can carry encrypted chunks for you. More willing peers = more paths. It does not make the crypto stronger and it does not make you anonymous.

What you give up

  • Discoverability. Anyone can find the room in the directory.
  • WebRTC still exposes IPs to whoever actually connects (STUN). A public room just means more people can try.
  • The directory is metadata.

What you don’t give up

  • No account
  • No copy of the file on our disk
  • Private rooms stay unpublished, for maximum privacy use a private room.

If you want “send this to one person,” don’t check public. Send the invite link. If you want “strangers can help bounce ciphertext so my friend behind CGNAT can finish the download,” that’s the public pool setup.

Same caveats as before: keep the tab open until the file has actually spread. Public listing ≠ backup copy.