Don't just trust us.
Inspect the design.
Z4SK publishes its source code, cryptographic protocol, limits and live database-control evidence so third parties can examine what the product does—and what it cannot promise.
Production commit: f9d5c8613630 ↗
A complete invitation link can decrypt. Creators may add a reusable 128-bit key as a branded QR or 12 Spanish BIP39 words. When enabled, the link and key are both required and must travel through different channels. Legacy 24-word keys remain valid. The key ID only identifies a key; it cannot recover or unlock it.
El enlace completo es el primer secreto; la llave extra es opcional. Si se activa, hacen falta ambos y deben enviarse por canales distintos. Las llaves nuevas usan un QR con marca o 12 palabras; el ID solo identifica la llave.
Private content is encrypted before the server sees it.
Generates link and content keys, an access token and ECDH response pair. HKDF derives the wrapping key from the link secret and, when selected, a generated or scanned optional shared key. AES-256-GCM wraps the content key and encrypts the invitation.
Receive a v2 authenticated envelope, token hash, question count, expiry, timestamps and lifecycle state. They never store link secret, shared key, content key or response private key.
Uses the complete link directly or, for protected invitations, reads the shared-key QR from the camera or Photos or enters 12 words. Decryption and response encryption happen locally.
Encrypted does not mean invisible or anonymous.
Encrypted content
- Creator and recipient display names
- Title, questions, locale and level
- Invitation feature settings
- Response public key
- Respondent name, answers and reactions
Server-visible metadata
- Random invitation ID and ciphertext envelopes
- Question count and view-once policy
- Creation, opening, response and expiry times
- Open/closed lifecycle state
- Request paths, approximate country and infrastructure metadata
Clear trust boundaries, without security theatre.
A complete link is sufficient unless the creator enabled the optional shared key; in that mode both secrets are required.
Reusing one shared key increases the impact if matching links are also exposed.
A compromised browser, extension, device, clipboard, camera pipeline or screenshot can expose plaintext.
A malicious future deployment could capture inputs; public source is not remote attestation.
Deletion cannot erase content another person already saw, copied or photographed.
The live proof is a Z4SK self-audit, not an independent certification.
Follow the evidence from browser to database.
Trust, but verify.
Running live checks against the active database…
Auditable no significa infalible.
Los nombres, preguntas, ajustes y la clave pública de respuestas se cifran en el navegador del creador con AES-256-GCM. Las respuestas se cifran en el navegador del destinatario mediante ECDH P-256, HKDF-SHA-256 y AES-256-GCM. El servidor conserva texto cifrado y metadatos mínimos para aplicar caducidad, lectura única y protección contra abusos.
Los secretos viven en fragmentos de URL que el navegador no envía en la petición HTTP normal. Aun así, pueden filtrarse por acciones del usuario, el portapapeles, sincronización, mensajería o capturas. El código público, la evidencia en vivo y los análisis externos automatizados mejoran la inspección; no sustituyen un pentest humano ni una certificación.
Leer la auditoría externa automatizada ↗