Back

About this app

Like everyone else, I used to just drag-and-drop files into Slack, Discord, WhatsApp, WeTransfer, Gmail or whatever.

Most of the time, I do this just to move a file from one device to another, or send some drafts to my peers. Usually, the file does not need to be hosted for an extended period of time.

This site is an attempt to simplify this workflow and improve privacy, by sending files directly (in almost all cases) to the peer, instead of relying on a third-party to host files indefinitely.

Usage

Click on the big arrow or drag-and-drop a file into the box. You will get a unique URL that you can share or copy by clicking on it. There is also a button to show a QR code to quickly open it on a mobile device.

As long as this tab is open, everyone with access to this link will start to download the file directly from your computer. If both of you are in the same local network (for example you are both connected to the same wifi), the data transfer happens entirely locally. Only coordination metadata needs to be transfered over the internet.

You can cancel sharing the file immediately by closing the tab.

Security

This is a serverless open-source project, hosted on Netlify. It uses WebRTC to send files. Metadata (the signaling server) is shared using Pusher Channels. It uses the open-access STUN and TURN servers provided by PeerJS, but has its own signaling implementation.

File and client ids are generated using the browsers crypto.randomUUID() API. Everyone knowing those UUIDs (or anyone able to guess them) can hijack a sender, or receive files illegitimately. A new pair of ids is generated every time the page is accessed, or every time a new file is selected.

In general all of the listed third-parties might receive your IP address. Depending on the structure of your network, intermediate IP addresses may also be shared. This might also apply to your real IP address if you are behind a proxy or VPN.

    Communication is assumed to be encrypted by the browser using HTTPS and DTLS; no further client-side encryption is attempted. Messages over the signaling server are encrypted only using HTTPS; Pusher may read and/or store their contents, although they promise not to.

    Is it always P2P?

    tl;dr: Most of the time, yes. Only if all else fails, encrypted data is sent through PeerJS's open TURN server. They are unable to read the contents of the file.

    WebRTC uses real peer-to-peer connections whenever the browsers can find a working pair of connection parameters (compatible protocols, encryption standards, IP addresses). In general, this is possible in most configurations, but might fail whenever you add layers of networking that obfuscate your IP or block the direct connections. Examples of this include:

    • Symmetric NATs (most common in mobile networks)
    • External Firewalls
    • Public open wifi (like in airports or hotels)
    • VPNs

    If no possible direct route can be found from one browser to the other, a fallback to so-called TURN servers is in place. TURN servers act as simple proxy; both clients can connect to the TURN server, which will then forward all traffic between those two. This works because almost all networks allow requests to servers on port 80 and 443 (which are usually used for normal web traffic). This app uses the open TURN server provided by PeerJS, another great library for doing WebRTC stuff!

    During my tests, Chrome as the sender connected to LAN seems to expose IPv6 addresses most often, which tend to work reliably, even if the peer is in a different network behind a NAT (like a phone). If both devices are on the same network, peer-to-peer connections worked reliably.

    Giving websites permission to use the microphone also relaxes security features around exposed IP's and WebRTC, increasing the chances of a working peer-to-peer connection. The microphone will never actually be used by this app, and no sound data will ever be recorded.

    You can check using the button above which IP addresses will be exposed. Note that the browser might cache, so a reload might be required. Revoking permissions is not possible fully, please check your browser how to do that.

    For Firefox, you can also enable the media.peerconnection.ice.no_host flag in about:config if you know what you are doing.

    Who this?

    This app was made with ☕, 💦 and 💜 by joshua
    If you really like what you see, you can Buy me more ☕, or get in touch!