Browser file sharing can be private and dependable, or it can be a polished page that sends a file to the wrong device. The padlock in the address bar confirms HTTPS between you and the website; it does not establish the receiving device’s identity. “P2P” describes a connection shape, not a complete security review.
You do not need to read protocol specifications to spot most problems. The following twelve checks are visible before, during, or after a small test transfer. They work as a user checklist and as a product review.
Before connecting: identify the person and device
- First contact requires approval. Discovery is not authorization. The receiving person should see a request and verify a recognizable device.
- Connection codes expire quickly. A six-digit code is convenient to type, but it must be single-use, attempt-limited, and short-lived.
- Devices have cryptographic identity. Trusted reconnect verifies a key, not only a changeable nickname or current IP address.
- Trust can be revoked. A lost phone or shared computer must be removable so it cannot reconnect automatically.
Local-network discovery only produces candidates. Two strangers in a café may share a public network exit; that should not make them trusted. Keeping discovery, request, and approval as separate steps preserves the boundary without making ordinary reconnects noisy.
During transfer: inspect route, control, and integrity
- The active route is visible. Direct and TURN relay are distinct instead of being hidden behind a generic “online” label.
- Relay access is controlled. TURN uses short-lived credentials, quotas, and concurrency limits rather than a public permanent password.
- Control actions have priority. Cancel, reject, and stop-reconnect messages do not wait behind a bulk data queue.
- Progress reflects peer acknowledgement. Local buffering is not counted as remote success, and a final digest is checked.
WebRTC encrypts its transport. A TURN relay should not receive readable payloads, but it still observes addresses, duration, and traffic volume. That metadata deserves limited retention and access. For especially sensitive material, an encrypted archive with a separately shared password adds protection independent of the transfer service.
After receiving: complete does not mean harmless
- Integrity has a visible result. The interface reports a SHA-256 or equivalent match, not merely that every numbered chunk arrived.
- Risky file types do not open automatically. Executables, scripts, and macro documents are saved for an explicit user decision.
- Partial data can be removed. Failed or cancelled chunks do not remain indefinitely, and there is a manual cleanup action.
- Logs exclude content. Error reports and analytics omit filenames, message text, clipboard values, connection codes, private keys, and full IP addresses.
Clipboard and screen capture need separate consent
A connected device should not automatically gain clipboard access or a view of the screen. Browsers generally require clipboard operations to follow a user action, and screen capture asks the user to choose a tab, window, or display. A product should preserve that mental boundary rather than treating connection approval as blanket permission.
Screen sharing needs a persistent visible indicator and a one-action stop. If the viewer refreshes or leaves, the sender should reconcile the viewing session promptly. Reconnecting the transport must never silently reacquire capture. Clipboard history can contain one-time codes, tokens, and passwords, so send only a deliberately chosen item and offer local clearing.
Analytics with useful boundaries
A team needs connection success rate, direct-versus-relay ratio, coarse speed ranges, and failure stages to improve a transfer. Use an event-field allowlist: event name, feature, outcome, coarse duration, byte-size bucket, and browser major version are usually enough. High-cardinality content fields increase both privacy risk and analytical noise.
Browser error collection should strip query strings, URL fragments, user input, and tokens embedded in stack messages. The service needs retention limits and access control. Security logs detect abuse; product analytics explain feature use. Their purposes differ, so they should not become one unrestricted data lake.
A two-minute trial
Start with a small, non-sensitive file. Check that the receiver approves, the route is visible, cancel reaches both sides promptly, and completion includes verification. Refresh one side to observe trusted recovery and ensure old tasks do not jump back to life. Finally, confirm that the trusted device can be removed.
uCopy separates first approval, trusted-device recovery, route state, transfer state, and feature permissions. Verify a device on the connection page, then choose file, clipboard, or screen actions inside the workspace. Security is not one padlock icon; it is the accumulated behavior at every boundary.