How ProxForm is GDPR-proof

Architecture guarantees

These are the structural properties of ProxForm. They hold by construction, not by policy — there is no setting you can toggle to break them.

• No data at rest on our infrastructure. Nothing patient-related is stored on any ProxForm server, because there is no ProxForm server. Article 32 risk assessment: trivial.
• No controller-side storage by default. If the clinician chooses to save a copy locally, that local copy is their responsibility under their own legal basis — like a paper file in their cabinet.
• No processor relationship. ProxForm never receives patient data, so there is no controller→processor flow to formalize. No DPA needed under Article 28.
• No third-party processors involved. No analytics provider, no email relay, no logging service, no CDN that sees patient data. No Article 30 record-of-processing for transit.
• End-to-end encryption. The handshake metadata is encrypted with AES-256-GCM using a key derived from the shared passphrase. The data channel itself runs over DTLS 1.3.
• Two-channel out-of-band sharing. The invitation link travels through one channel (email), the passphrase through a different channel (SMS, phone). Compromising one channel is not enough to read the form.
• Session verification (SAS). Both sides see a short verification code derived from session nonces. Reading it aloud defeats a person-in-the-middle who somehow obtained both channels.
• No accounts. No registration, no login, no identifier ProxForm could associate with a clinician or patient.
• No cookies in the app or on the patient path. The ProxForm app (form builder, portal, dashboard) and the patient form page set zero cookies and load zero analytics. The only place anything is counted is the public marketing landing page (see next point) — and never the pages that carry patient data.
• Landing-page analytics are opt-in. The public landing page (/) offers Google Analytics purely to count visits, and it does not load until the visitor explicitly clicks Accept on a consent banner. Decline and nothing loads, ever. This analytics never runs on the app or the patient page — those collect nothing regardless of the choice.
• Auditable. Every line of crypto and protocol code runs in your browser. Open DevTools, inspect it, verify it. No obfuscation, no minification of the security-critical code.
• No hidden network traffic. The only outbound network call ProxForm makes is the WebRTC STUN probe to gather a NAT-reflexive candidate. No telemetry, no error reports, no usage pings.

Cryptography & transport detail

• Key derivation. PBKDF2 with SHA-256, 100,000 iterations, derives a 256-bit key from the shared passphrase. A fresh random salt is generated per session.
• Handshake encryption. AES-256-GCM with a fresh 96-bit IV encrypts the SDP offer and answer carried in the URL fragment. The fragment never leaves the browser to a server — it's only visible to the two peers.
• Compression. Payloads are compressed before encryption to reduce link size — compression is for length, not for confidentiality.
• Data-channel transport. WebRTC data channel over DTLS 1.3 (browser default), with SCTP framing. Both peers verify each other's DTLS fingerprints, which are themselves authenticated via the encrypted SDP exchange.
• Session verification (SAS). Each side generates a random nonce, exchanges it in the first data-channel message, then hashes both nonces together. The short hex code displayed on both screens must match — if they don't, abort.
• No long-term keys. Every session uses a fresh passphrase, fresh salt, fresh IVs, fresh nonces. Nothing is reused across sessions.

Local-device storage scope

ProxForm uses browser storage only on the user's own device, never on any server.

• IndexedDB on the clinician's device. Form definitions (drafts and saved forms) and received submissions live in IndexedDB scoped to the clinician's browser. Clearing browser data removes them.
• IndexedDB on the patient's device. A partially-filled answer set is saved as a draft so the patient can refresh without losing input. The draft is cleared automatically on successful submission.
• localStorage. Theme preference (proxform_theme), the shield-timeout and ticket-counter preferences, and — on the public landing page only — your analytics consent choice (proxform_ga_consent: granted or denied). No patient data, no tracking IDs, nothing that leaves the device except the Google Analytics ping you explicitly opted into on the landing page.
• No cross-origin storage. Browser storage is sandboxed to the ProxForm origin — no other site can read it.
• Persistence request. ProxForm asks the browser to mark its storage as persistent so drafts aren't evicted under disk pressure. The browser may grant or deny this; either way, nothing leaves the device.

What ProxForm does not do

• No upload of patient data anywhere. Answers are not POSTed to any backend — there is no backend to POST to.
• No email integration. ProxForm cannot email a completed form on the clinician's behalf. That would require a server-side SMTP relay, which we do not run.
• No cloud sync. Forms and submissions do not sync across devices through ProxForm. Export the JSON yourself if you need a portable copy.
• No accounts, no SSO. No identity provider is involved.
• No analytics or telemetry in the app or on the patient path. The builder, portal, dashboard, and the patient form page run no Google Analytics, no Sentry, no PostHog, no pixel — nothing. The only analytics anywhere is consent-gated Google Analytics on the public marketing landing page, which never sees the app or any patient data.
• No third-party fonts or scripts. No Google Fonts, no CDN-hosted JavaScript. Everything is served from the ProxForm origin.
• No CAPTCHA. No reCAPTCHA or hCaptcha — those load third-party JavaScript and collect signals.

GDPR article mapping

• Article 5 (Principles). Data minimisation is enforced by architecture — only the fields the clinician adds are collected, and no copy is retained by ProxForm.
• Article 25 (Data protection by design and by default). Privacy is the default and the only mode. There is no "less private" setting.
• Article 28 (Processor). No processor relationship exists between the clinician and ProxForm — no DPA required.
• Article 30 (Records of processing). No third-party processors to enumerate for transit. The clinician's local storage of received submissions is their own controller record, kept under their own existing processes.
• Article 32 (Security of processing). Encryption in transit (AES-256-GCM + DTLS 1.3), no data at rest on third-party systems, session integrity verification (SAS), no shared infrastructure to compromise.
• Article 33–34 (Breach notification). ProxForm has nothing to breach — no servers, no databases, no logs containing patient data. A breach of ProxForm infrastructure cannot expose patient submissions.
• Articles 44–49 (International transfers). Patient data does not transfer across any border via ProxForm — it travels directly between two browsers chosen by the participants.

What ProxForm is not

• Not a HIPAA-marketed solution. The same zero-data-at-rest architecture is favourable under HIPAA, but we do not market ProxForm as a HIPAA-compliant product. HIPAA has its own requirements (BAAs, audit logs) that are out of scope for v1.
• Not a long-term storage system. Submissions live on the clinician's own device. Exporting to JSON (or printing to PDF) is the supported way to keep a durable record under the clinician's own retention policy.
• Not a substitute for legal advice. ProxForm removes most of the technical risk surface, but you remain the data controller for whatever you collect and keep. Check with your DPO.