WolfP2P
Transfer reportsMy Settings

Security

For:All usersNo technical knowledge required.

The WolfP2P browser clients stream file bytes over an encrypted browser-to-browser WebRTC data channel. The coordination server helps those clients become connected browser peers and processes coordination data, but it does not receive, store, or relay file bytes or file metadata.

That design reduces intermediary file handling, but it does not remove every trust decision. The sender must share the invitation with the intended person, both endpoints must be trustworthy, and the transfer must fit WolfP2P's live direct-connection model.

For a practical workflow that applies these boundaries, see Share a Sensitive File Privately.

Security controls and boundaries

Encrypted in transit
The browsers use a DTLS-protected WebRTC data channel. Network intermediaries cannot read the file bytes or change them without detection while they cross that channel.
No intermediary file copy
File bytes and file metadata move from the sender's browser client to the receiver's over the direct channel. WolfP2P's coordination server does not become a storage or relay destination for either category.
Browser-mediated local access
WolfP2P can read or write only after a person deliberately selects a source or destination and the browser grants the required access. Selecting one location does not grant general disk access.
Transfer verification
The encrypted channel protects traffic in transit. WolfP2P also uses local verification when deciding whether destination content can be reused during supported recovery. Neither mechanism proves who created a file or whether it is safe to open.

Understand each boundary

Security details

Encrypted transfer

Understand the WebRTC and DTLS protection, how it compares with familiar secure transports, and what remains outside the encrypted channel.

What the server sees

Review the coordination, signaling, progress, operational, and optional analytics information involved in a transfer.

Browser file and folder access

See what source and destination selections authorize, what remains inaccessible, and why the browser may ask again.

No intermediary copy

Consider how avoiding another stored file copy changes exposure without making either endpoint inherently trustworthy.

Trust, identity, and file integrity

The encrypted channel authenticates the cryptographic endpoints participating in that connection; it does not establish the real-world identity of the person using the other browser. Anyone who obtains a valid invitation while a seat is open may attempt to join. Share the invitation privately, confirm the intended recipient through a trusted channel for sensitive material, and replace an invitation that may have been exposed.

Transport integrity, destination verification, and file authenticity are different properties. DTLS detects modification while bytes cross the data channel. WolfP2P can use SHA-256 evidence locally to verify reusable destination content during supported recovery. It does not digitally sign the file, establish who created it, scan it for malware, or make a compromised endpoint safe. Read Transfer Reliability and Recovery for the recovery model.

The coordination server remains part of the connection's trust model because it relays WebRTC setup information and WolfP2P does not currently provide an independent, out-of-band fingerprint comparison. The complete personal-data inventory, purposes, and retention rules belong in the Privacy Notice.

Does this security model fit?

Choose for the required controls

WolfP2P fits when

  • Two known participants can remain online for a supervised transfer.
  • Avoiding an intermediary server copy is important.
  • A privately shared invitation and separate recipient confirmation provide enough identity assurance.
  • Both endpoints and browsers are trusted and updated.

Use a managed system when

  • Authenticated organizational identities, audit records, malware inspection, retention rules, data-loss-prevention controls, or administrator-enforced policy are required.
  • The receiver must retrieve the files after the sender goes offline.
  • A restrictive network prevents a direct WebRTC connection; WolfP2P does not use a TURN file relay as a fallback.
  • The files require a durable repository, backup, public distribution, or access by several recipients.

Report a security vulnerability

If you discover a potential weakness, read the Vulnerability Disclosure Policy before testing or reporting it. It defines the authorized scope, reporting instructions, prohibited testing, response targets, and coordinated-disclosure process.

For service incidents and resolved security events, review the current and previous Security Notices.