Security guide
What “direct and encrypted” does—and does not—mean
ADrop is designed to keep file content off its application server. That reduces one important exposure, but it does not make every device, filename, browser extension, or network trustworthy. A useful security claim needs boundaries.
Short threat model
- Protected in transit: file bytes on the WebRTC data channel.
- Visible for coordination: device and file metadata needed to discover, approve, and connect.
- Controlled by the receiver: whether to accept and where the output is stored.
- Outside ADrop's control: malware, hostile browser extensions, compromised endpoints, and handling after download.
The application server is not the file path
The sender reads a local file in chunks and writes those chunks to a WebRTC data channel. ADrop's Node service does not expose an upload endpoint for file content, and the WebRTC configuration does not include an ADrop TURN relay. If the browsers cannot establish a peer connection, the transfer fails instead of changing to server-carried file traffic.
The signaling server is still necessary. It forwards device presence, transfer invitations, WebRTC session descriptions, and connectivity candidates. Infrastructure in front of the service also handles normal web requests. “No cloud upload” should therefore be read narrowly and accurately: file contents are not stored or relayed by the ADrop application server.
Transport encryption protects the channel
WebRTC data channels use DTLS to encrypt data between the negotiated endpoints. A passive observer on Wi-Fi should not see the file bytes in plaintext. HTTPS and secure WebSocket transport also protect page delivery and signaling on their network paths.
Transport encryption does not make a malicious file safe, encrypt the saved file at rest, or rescue a compromised sender or receiver. Once accepted, the file is available to the receiving browser and later to software that opens it. Use operating-system malware protections and do not open unexpected executables or documents with active content.
Metadata exists before the file channel
The receiver needs enough information to make a choice, so the invitation includes file names, media types, sizes, and optional folder-relative paths. Signaling also uses random device IDs, user-visible device names, device category, visibility setting, and trusted-device identifiers. Network services necessarily observe connection information such as IP address and timing.
A sensitive filename can reveal information even when its contents stay encrypted. Rename it before sending if that disclosure matters. Do not use a person's full legal name, phone number, or another secret as the device display name.
Discovery is convenience, not identity verification
Same-network discovery is based on the network view available to the server. It cannot prove physical proximity or ownership. Random device IDs reduce casual collisions but are not human-verified identities. Before accepting, compare the visible device name and expected file list with the person sending through a separate, trusted conversation.
A previously connected device is a local convenience relationship, not a certificate-backed identity. If a shared computer changes hands, clear ADrop site data and review browser profiles.
Visibility choices change exposure
| Setting | Who can find the device | When to use it |
|---|---|---|
| Same network | Eligible active devices sharing the apparent network group. | Normal use on a network you understand. |
| Previous devices | Devices whose IDs were stored after prior approval. | Reduce unsolicited discovery while keeping known peers convenient. |
| Hidden | No automatic discovery or new ID lookup. | When not transferring, or on a broad shared network. |
Browser storage has a lifecycle
The browser stores the local device identity, name, language, visibility choice, and trusted IDs. A live receiving session may use browser-managed private storage for partial data. ADrop removes stale transfer workspace when a new client session initializes, but browser-level retention and eviction are ultimately controlled by the browser. Clearing site data removes the local ADrop preferences and identity.
Advertisements are separate from selected files
If advertising is enabled on a publisher-content page, the ad provider can process ordinary web and advertising data according to consent and its own policies. The file picker returns selected file objects to ADrop's page logic; the ad component is not passed those objects, chunks, filenames, transfer records, or peer connection. Static guides, Help, About, and Privacy pages contain no ad placements.
A safe operating checklist
- Open the expected HTTPS origin and avoid lookalike domains.
- Confirm the receiver through another channel before choosing private files.
- Review filenames and sizes before accepting.
- Keep both operating systems and browsers current.
- Open received files only when you trust their source and expected type.
- Use Hidden visibility afterward and clear site data on a shared device.
For the formal description of data handling and advertising, read the Privacy notice. This guide explains security reasoning; it does not replace that notice.