Primary browser requests a pairing
The server creates a random pairing identifier and an authorization value for the primary side. The server stores pairing identifiers and timestamps so the primary can resume during the configured lifetime.
Technical trust and limits
How IcyZip Works
A concrete account of what the browser generates, what crosses the service, what remains local, what metadata the server can still see, how recovery behaves, and which paths are actually covered by automated tests.
- No key in the link.Current QR/open links carry a pairing id, not the private or derived text key.
- Browser encryption.Current clients derive separate text and file keys and encrypt before transport.
- Metadata remains.E2EE protects payload content, not every operational fact around a session.
Pairing lifecycle
From first QR code to a connected pair
The service coordinates two browser endpoints. Pairing identity, cryptographic key agreement, content encryption, reconnect state, and user-visible recovery are separate layers.
QR code carries the public location
The current link is shaped like https://icyzip.com/?i=<pairId>. It does not contain the live-text secret, private ECDH key, derived AES key, current text, or file bytes.
Second browser opens the pair
The service connects the secondary browser to the waiting primary. Both sides exchange browser-generated public key data through the same WebSocket protocol or the text-only HTTP fallback.
Browsers derive matching secrets
Each side keeps its private key local, imports the peer public key, derives shared ECDH bits, and produces purpose-specific encryption keys. The service forwards public material but does not receive either private key.
Payloads are encrypted before transport
Live text becomes an authenticated encrypted envelope before a text command is sent. File bytes become encrypted binary frames before leaving the sender. The paired browser authenticates and decrypts them.
Reconnect or recover visibly
A resumable tab can reconnect to the same pair. If the server-side pair is gone, IcyZip removes the stale identity, preserves the local draft, creates a fresh pair, and tells the user to scan the fresh QR code.
Cryptography in current product browsers
P-256 ECDH, HKDF-SHA-256, and AES-GCM
The implementation uses the browser WebCrypto API. This section names the actual construction so the phrase end-to-end encryption has a checkable technical meaning.
Temporary browser keypairs
Each browser generates a P-256 ECDH keypair for the pairing. Public JWK data crosses the service. The private key remains browser-side and is exported only into that tab's local sessionStorage state for reload/reconnect continuity.
Shared secret and text key
After importing the peer public key, each browser derives 256 shared ECDH bits. HKDF-SHA-256 uses the pair id as salt and the purpose string icyzip/text/ecdh/v2 to derive a 256-bit AES-GCM text key.
Separate file purpose
File transfer uses the same browser ECDH relationship only through a distinct HKDF context, icyzip/file/ecdh/v1. Each file chunk gets a fresh 96-bit nonce and an AES-GCM frame shaped as nonce, ciphertext, and authentication tag. Text and file keys are therefore purpose-separated.
Audit boundary: this construction is implemented and regression-tested, but IcyZip is not independently audited and does not claim formal verification. Wrong-key and deliberately corrupted-envelope browser cases remain a separately tracked coverage improvement.
Server visibility
What the server can still see
Encryption protects payload contents from passive relay inspection. It does not make the coordination service disappear, and it does not hide every fact required to connect and route the pair.
Pairing and connection facts
The server can still see pairing identifiers, primary authorization state, connection and reconnect timing, message direction, encrypted envelope sizes, WebSocket or fallback activity, public ECDH key data, browser/device class, and IP-derived country where configured.
File-offer metadata
Current file control messages expose filename, MIME/type hint, plaintext size, encrypted wire size, chunk sizing, transfer identifiers, and timing. The file bytes are encrypted, but this metadata is not yet moved into a peer-only encrypted offer.
Aggregate operations data
The service maintains aggregate counters for page requests, connections, pairings, file outcomes, broad client classes, countries, and privacy-safe diagnostic reason codes. Marked automated tests are stored separately from real counters.
Claims IcyZip does not make
IcyZip is not anonymous, serverless, zero-metadata, a public file host, a permanent share-link service, or a replacement for an independently audited secure messenger. Users should evaluate whether the remaining metadata fits their situation.
Storage and retention
Server pairing state, tab-local drafts, and received files
Where data lives matters as much as what crosses the wire.
Server pairing state
The server persists pairing identifiers, primary authorization values, creation time, and update time so a browser can resume. The configured lifetime is currently 30 days; cleanup removes expired pair records.
Tab-local browser state
A tab may retain the current text draft and exported local keypair in sessionStorage. That state is scoped to the browser tab/session and can survive reload, but the draft may be plaintext at rest on the device.
Received file bytes
The receiver creates a browser Blob and a local download action after successful decryption. The IcyZip server does not turn the received bytes into a persistent download object. The saved file and browser download history remain on the receiving device.
Connection recovery
Wake, network return, unavailable pairs, and explicit disconnect
Recovery behavior distinguishes an accidental transport interruption from a user intentionally ending the pair.
Stale transport after sleep
Visibility and online events prompt the client to evaluate the current WebSocket. A connecting socket that no longer makes progress is replaced. The client reconnects rather than leaving Android indefinitely at Connecting.
Unavailable server-side pair
The client drops the stale pair identity and obsolete pair key, preserves the tab draft, creates a new primary pair, removes the dead ?i= from the URL, renders a fresh QR code, and shows an explicit rescan instruction.
Built-in scanner boundary
The camera scanner accepts root pairing links from the current app origin, https://icyzip.com, staging, and controlled HTTPS IcyZip subdomains. It rejects HTTP, foreign lookalikes, credentials, wrong paths, and custom ports, and stops the camera track before navigation.
Intentional disconnect
The Disconnect action destroys the pairing relationship. It does not silently reconnect to the same pair. A new session starts with a new pairing and new browser key agreement.
Automated coverage
What current gates prove—and what they do not
Test coverage is evidence about exercised paths, not a guarantee for every browser version, extension, network, or operating-system policy.
| Area | Automated evidence | Current gap or qualification |
|---|---|---|
| Protocol and pairing | JSON commands, stable upgrades, cleanup, reconnect, disconnect, persistence, expiry, HTTP text fallback, and rejection of the retired colon protocol. | Production expiry uses the real 30-day configuration; the automated expiry test uses a short local TTL. |
| Chromium browser flows | Real QR pairing, two-browser text, action buttons, fullscreen, reload, multi-pair isolation, recovery, scanner fallbacks, network dampers, and encrypted file transfer with byte equality. | Extensions, enterprise policies, and every Chromium release are not enumerated. |
| Android behavior | Android Chrome emulation covers QR starts, paste focus, viewport behavior, sleep/visibility recovery, unavailable-pair fresh QR, scanner success/denial/unsupported paths, and forward progress. | Emulation is not the same as a physical-device lab across vendors and Android WebViews. |
| Firefox | A dedicated GeckoDriver action-matrix path covers browser actions in staging/production when run, and general source/protocol behavior is shared. | The full file/scanner matrix is not repeated in every Firefox release. |
| Safari and iOS | The implementation uses standard WebCrypto, file picker, link, and download mechanisms with visible fallbacks for scanner/clipboard limitations. | Safari/iOS is not currently part of the automated Linux gate; compatibility wording must remain qualified. |
| Cryptographic transport | Tests prove browser keypair exchange, no secret in the link, encrypted text envelopes, encrypted file frames, received-byte equality, keypair recovery, and text progress after reconnect. | Dedicated wrong-key, malformed-envelope, and nonce/ciphertext corruption browser regressions remain open, and there is no independent audit. |
Use decision
When the current boundary is a good fit
IcyZip is designed for short, active handoffs between two browser views you control. It is strongest when both devices are present, both tabs can stay online, and avoiding account/app/cloud-folder setup matters.
Good fit
Short text, links, codes, one selected file, a nearby phone and computer, temporary paired use, and users who understand that routing metadata remains.
Choose another tool when
You need offline pickup, permanent public links, folders, large batches, resumable multi-gigabyte transfer, organizational identity/access controls, verified anonymity, or independently audited high-assurance messaging.
FAQ
Technical trust questions
These answers state the current boundary. They are intentionally narrower than generic claims such as anonymous, serverless, or zero-knowledge.
Is IcyZip independently security audited?
No. The current implementation has automated protocol, browser, encryption-frame, reconnect, and transfer tests, but this page does not claim an independent security audit or formal verification.
Does the QR code contain the text encryption key?
No. Current pairing links contain a pairing identifier only. Each browser generates a temporary P-256 ECDH keypair and exchanges public key data through the service.
Does end-to-end encryption hide all metadata?
No. The service still processes connection, timing, sizes, pairing activity, public key data, and file-offer metadata such as filename and type hint.
What survives a reload?
A tab can retain its pairing keypair and current text draft in sessionStorage so reload and reconnect can continue. This is local browser state, not server-side content storage, and the draft may be plaintext at rest in that tab.