Private by design. Honest by default.
Last updated: November 2, 2026 · Private beta
Invitation content and response content are end-to-end encrypted in users' browsers before transmission. Neon Postgres and provider backups receive authenticated ciphertext, not display names, questions, settings, respondent names or answers. Z4SK is still not anonymous: random identifiers, timestamps, lifecycle state, question count, expiry policy, request paths and infrastructure metadata remain visible.
A complete invitation link can decrypt the invitation. Creators may add an optional reusable shared key as a branded QR or 12 Spanish BIP39 words. When enabled, both secrets are required and must be sent through different channels. Legacy 24-word keys remain valid. The displayed key ID is only an identifier.
Trust, but verify.
Running live checks against the active database…
Who can see what — audited access matrix
/founder access returns aggregate counts and first-party sponsor controls only. It has no route or key capable of returning invitation or answer plaintext or decryption keys.Invitation and response content are end-to-end encrypted in the audited build. The service is not anonymous. There is no “superadmin” decryption key. A leaked complete link can reveal a link-only invitation; a protected invitation additionally requires its optional shared key. A compromised browser, malicious future deployment or screenshot can reveal plaintext. The public audit page links the implementation, CI and live evidence.
Who controls the data
josejnet operates Z4SK as the data controller for this private-beta service. Vercel and Neon provide the application and database infrastructure described below. Privacy requests can be sent to josejcoy@gmail.com.
Exactly what we collect
Why we process it
Invitation and response data are processed to provide the service requested by the creator and recipient. Security records are used to prevent abuse and protect the service. Aggregate usage data supports legitimate product improvement, fraud prevention and commercial measurement without reading answer text. If a different legal basis is required in a launch market, the operator must update this notice before launch.
Private access and encryption
Creation generates random 256-bit link and content keys, a bearer token and an ECDH P-256 response pair in the creator browser. The creator may also generate or scan an optional reusable 128-bit shared key. HKDF-SHA-256 derives an AES-256 wrapping key from the link secret alone or, in protected mode, from link secret plus shared key; AES-256-GCM wraps the content key and encrypts the private payload. The API receives only the v2 envelope, token hash and minimal lifecycle fields. Only the link secret enters #invite=. The optional key remains local and is represented by a branded QR or 12 Spanish BIP39 words; legacy 256-bit/24-word keys remain compatible.
This protects private content if the database is disclosed. A complete link can decrypt a link-only invitation; protected mode requires both link and shared key. It does not protect against malware, extensions, screenshots, clipboard/camera compromise, a malicious browser or future application build. Secrets cannot be recovered from the server. The displayed key ID only identifies a key and cannot recover or unlock it. Reusing a shared key increases the impact of its compromise; rotate it when exposed.
Infrastructure, location and operational logs
The audited production deployment runs on Vercel Functions and uses the Vercel Marketplace Neon Postgres integration — not Cloudflare D1. The active Neon host is in AWS us-east-1 and requires TLS plus channel binding. Neon states that it also encrypts stored data with AES-256 and enforces TLS 1.2 or newer; these provider controls are additional to Z4SK's application-level ciphertext. See Neon security.
Vercel and Neon necessarily process operational metadata such as IP/network information, timestamps, status codes and request paths. A request path can contain the random invitation identifier. Z4SK application code does not log request bodies, bearer headers, private URL fragments or decrypted answers, and it installs no third-party analytics or advertising SDK. Production responses send a no-referrer policy, deny framing, restrict browser capabilities and restrict network/script origins with security headers.
Deletion and retention
- Creator cancellation: the creator can cancel before or after the recipient opens the questions. The active invitation, encrypted responses and abuse reports are deleted in one database transaction. Analytics cannot block the request and both current HMAC and legacy event-to-invitation identifiers are removed in that transaction.
- Recipient cancellation: after a successful submission, the browser creates a private cancellation link containing a separate high-entropy deletion secret. Only its hash is stored. The link remains usable after a reload or on another device and can permanently delete only that ciphertext; it cannot read the response.
- After reading: cancellation removes active server data and prevents later access through Z4SK, but no web service can erase content a person has already seen, remembered, copied, photographed or stored outside Z4SK. “Cancelled” must not be understood as remote erasure from another person's memory or device.
- View once: one Postgres statement locks the invitation and response, returns the single ciphertext and deletes the complete active invitation graph atomically. Concurrent reads cannot return the same response twice. The browser then decrypts the returned ciphertext and removes creator secrets from its state and URL.
- Expiry: creator and recipient access stops at the exact selected 12/24/48/72-hour deadline. Expired invitations cannot show questions, accept answers or expose responses. Rows can remain temporarily until the daily cleanup runs; any attempted access also triggers deletion. See Vercel Cron behavior.
- Rate limits: daily-rotating keyed counters older than 24 hours are removed by the same purge.
- Aggregate metrics: answer text, respondent names, reactions and email are never copied into metric tables. New question-completion pseudonyms use a server-keyed HMAC. Pre-migration aggregate fingerprints are not linked to an invitation or person but may remain for historical totals.
- Provider recovery: the configured Neon restore window is 0 hours. Recovery history may temporarily retain encrypted envelopes after active deletion; the private decryption key is not stored with them. The verified project value can be published through
NEON_RESTORE_WINDOW_HOURS. See Neon project restore settings.
What the founder can see
The founder dashboard shows generic created/opened/responded/share-unlocked counts and rates, active ciphertext totals, approximate country, source and library version. For new encrypted invitations it cannot segment by invitation language, pack, question text or question completion because those values never reach the server in plaintext. It controls one first-party sponsor placement and shows aggregate viewable impressions, clicks and CTR. There are no advertising SDKs, behavioral profiles, targeting pixels or individual click histories.
Sharing and sales
Z4SK does not sell private answer text or personal profiles. Data is disclosed to Vercel and Neon as hosting/database processors, when required by law, to protect people and the service, or during a company transaction subject to appropriate confidentiality and data-protection obligations. Sponsor packs do not currently receive individual data.
Your choices and rights
Creators can cancel an invitation before or after it is opened from their secret dashboard. Recipients can stop before submitting, report unsafe invitations, or keep and use the private cancellation link created after submission. Its secret proves control of that specific ciphertext without revealing answer text. Other privacy requests can be sent to josejcoy@gmail.com.
Children and sensitive content
No Filter mode is for adults aged 18+. Z4SK is not designed to collect children’s data, passwords, financial information, health records, identity documents or other highly sensitive information. Do not place such information in questions or answers.
Changes and launch readiness
Material policy changes will update the date and version shown by the privacy-proof endpoint. The live proof reports technical controls and infrastructure facts; the operator and contact disclosures above remain separate legal requirements.