Poftim
Start a connection

Security architecture

What is protected—and what is not

Poftim creates an authenticated, temporary connection between two browsers. File contents and metadata are encrypted before entering the WebRTC transport. The service has not yet had an independent security audit, so this page documents the design and its limits rather than presenting an audit badge.

Summary

The short version

  • File contentsEncrypted end to end
  • File names, types and declared sizesEncrypted
  • Session keysDerived on the devices
  • Peer authenticationQR secret + matching phrase
  • Direct transportPreferred when available
  • Relay transportEncrypted and not stored
  • Independent assessmentNot completed

Threat model

The boundary of the promise

Designed to protect against

A signalling server or relay reading or changing file contents; a passive network observer reading transferred files; replayed or reordered encrypted frames; and a third device joining an already-claimed session.

Outside the protection

A compromised device, browser, extension or page; a recipient who saves or redistributes a file; traffic analysis; unsafe files accepted from another person; and denial-of-service or availability failures.

The matching phrase helps detect a connection that does not derive the same session keys. Compare it on both screens before continuing.

Pairing and keys

Fresh keys for every connection

Pairing secret
32 random bytes created by the host browser and carried in the QR URL fragment. The fragment is not included in the normal HTTP request.
Signalling
The secret derives an AES-256-GCM key that seals SDP, ICE candidates and ephemeral public keys before the signalling server forwards them.
Key agreement
Fresh ECDH P-256 key pairs establish a shared secret. HKDF-SHA-256 derives separate host-to-guest and guest-to-host keys.
Human check
Both devices derive the same short phrase from the session keys. A mismatch means the connection must be abandoned.
Key lifetime
The pairing secret is cleared after key agreement. Session keys remain in browser memory for the temporary connection.
Protocol
QRCABLE/1. Changes that affect interoperability require a protocol-version update.

File protection

Encrypted before transport

AES-256-GCM seals every control message and file chunk with a monotonic counter. The receiver rejects repeated frames, enforces file-chunk order and verifies an end-to-end SHA-256 digest before reporting a file as received.

Metadata
Names, MIME types, declared sizes, modification times and file digests travel inside encrypted control frames.
Transport
An ordered WebRTC data channel adds DTLS protection beneath the application-level encryption.
Storage
The signalling service never carries file chunks. A TURN relay forwards encrypted packets and is not used as file storage.
Risky files
The receiving interface warns for common executable and active-content extensions. It does not scan files for malware.

Visible metadata

Encryption does not hide the connection itself

  • File contentsNot received in readable form
  • File names and typesEncrypted
  • Encryption keysNot sent to the server
  • Opaque session identifier and roleSeen by signalling
  • IP addressesProcessed by connection infrastructure
  • Connection timing and approximate volumeObservable
  • Transfer historyNot created by the application

Direct peers may learn each other’s network address. “Hide my network address” forces TURN relay transport so the peer does not receive a direct route, but the relay infrastructure still processes both addresses.

Important limitation

The browser must trust the delivered page

The QR fragment is not sent in the HTTP request, but JavaScript running on the page can read it. A compromised deployment, browser or extension could read pairing material, session keys or plaintext files.

The deployed page uses a restrictive Content Security Policy, no third-party scripts, no advertising or analytics code, same-origin resources, HTTPS with HSTS, framing protection and a no-referrer policy. These controls reduce exposure; they do not remove the need to trust the code delivered by poftim.app.

Sessions and infrastructure

Short-lived and deliberately sparse

Unscanned code
The in-memory signalling session expires after five minutes.
Connected idle session
The server-side idle deadline is fifteen minutes and is refreshed by active signalling.
One-time join
Only the first guest can claim a session. Closing the host invalidates its QR code.
Server state
Opaque session IDs, roles, connection state and expiry are held in memory. File metadata and contents are not stored there.
Web access logs
Query strings are excluded and IP addresses are truncated before being written to the configured access log.
Third parties
No third-party scripts, analytics, advertisements or account providers run in the application page.

Browser compatibility

Current browsers, with practical differences

Poftim requires WebRTC data channels, Web Crypto support for ECDH P-256, HKDF and AES-GCM, JavaScript modules and Blob downloads.

It is designed for current Safari on iPhone and macOS, current Chromium browsers on Android, Windows, macOS and Linux, and current Firefox. Large-file saving, background suspension and memory behaviour differ between platforms.

A formal version-by-version browser and maximum-file test matrix has not yet been completed. Until it is, keep both pages open and screens awake, and avoid treating a particular maximum size as guaranteed.

Assessment and disclosure

Evidence, not badges

No independent security assessment has been completed or claimed. When one exists, this page will identify the assessor, date, scope, findings and remediation status.

If you find a vulnerability, read the vulnerability disclosure policy and use the security report form.

Start a connection