Privacy policy

1. Who is the data controller

The controller responsible for the processing described here is:

• Legal entity: 2Dynamic Games sp. z o.o. (operator of the FreeSign service, trading as “Coder AI”)
• Registered address: ul. Wadowicka 7, 30-347 Kraków, Poland
• Contact email for privacy matters: support@coderai.dev
• Data Protection Officer: We do not currently consider FreeSign's processing to require one under GDPR Article 37. Data-protection inquiries are handled via the contact email above.

For operator and general contact details see the imprint.

2. What personal data we process

FreeSign is designed so the document you sign never reaches our infrastructure — the browser hashes the PDF locally and the Worker only ever receives hashes, never PDF bytes. The personal data we do process is the audit trail of the act of signing:

• Email address — used to deliver the one-time passcode (OTP) and to bind the signer's identity to the envelope. On FreeSign servers it is not stored in plaintext: after the OTP step we retain only a keyed hash (HMAC) of the address. The plaintext is held only transiently to send the email and compute the hash. The signed PDF itself is different: the OTP-verified email is written into the signer's certificate and signature evidence inside the PDF, so anyone you give the signed PDF to can see the signer identity it carries.
• Signer name — the legal name you type during the signing ceremony. It appears in the per-user signing certificate (Subject CN) and in the signing evidence.
• IP address, device and browser fingerprint, and coarse geolocation — captured from the request at signing time: the connecting IP and any proxy-chain headers, the user-agent and client-hint headers, and Cloudflare edge metadata (country, region, timezone, ASN, TLS parameters). FreeSign deliberately does not capture precise geolocation (no city, postal code, latitude or longitude).
• The audit-event chain — a hash-chained log of each step (envelope creation, OTP request, OTP verification, signing, sealing, finalisation). The forensic context above is folded into these audit events.

We do not process the contents of the PDF you sign — there is no upload route and no endpoint accepts PDF bytes.

3. Purposes and legal basis

We process the data above for the following purposes, on the following legal bases:

• Providing the e-signature service (delivering the OTP, verifying identity, producing the signed PDF and its evidence) — legal basis: performance of the service requested by you, GDPR Article 6(1)(b).
• Producing and retaining a tamper-evident record of the signing act (the audit chain, the embedded evidence, the timestamp and OpenTimestamps anchors) — legal basis: legitimate interest, GDPR Article 6(1)(f), and the necessity of the evidence for the establishment, exercise or defence of legal claims, GDPR Article 17(3)(e). A signed document is only meaningful if the proof of who signed it, when, and under what consent can be relied on later.
• Abuse prevention and rate limiting (per-IP and per-email counters, bot challenges) — legal basis: legitimate interest in keeping the service available and free of fraud, GDPR Article 6(1)(f).

4. Retention

Retention differs by the type of record:

• Signed and finalised envelopes, their embedded evidence, and the hash-chained audit trail are immutable evidence. They are retained for 10 years from the date the envelope is finalised — a period chosen to cover the validity lifetime of the signing certificate FreeSign issues and to exceed the general limitation period for civil claims under Polish law. Because the audit trail is a cryptographic hash chain, deleting a single row would break the integrity of every later row and destroy the evidential value of the record. Erasure of this immutable evidence is therefore realised by retention expiry — the whole record is purged once its retention period lapses — rather than by deleting individual rows on request.
• Draft envelopes that never reached a signed state (a PDF was hashed and an OTP perhaps requested, but the ceremony was abandoned) are pruned automatically by a daily job after they expire (typically within a few days).
• OTP challenges, rate-limit counters and session nonces are short-lived and deleted automatically by the daily job once they expire.

5. Recipients and processors

FreeSign relies on the following third parties, each acting as a processor or independent recipient for a narrow, defined purpose:

• Cloudflare — hosting (Workers runtime, D1 database) and CDN. Cloudflare processes TLS-terminated request data (headers and JSON bodies). It never receives PDF content, because no PDF is ever sent to FreeSign.
• Mailgun — delivery of OTP emails. Mailgun receives the recipient email address and the OTP code.
• RFC 3161 Timestamping Authority (a trusted external clock) — issues the trusted timestamp embedded in each seal. It receives only the SHA-256 hash of the signature value.
• OpenTimestamps public calendar pool — creates an independent timestamp proof. The calendars receive only a 32-byte hash.
• Google Cloud KMS — holds the FreeSign Certificate Authority private key in an HSM. It signs only certificate digests; it never receives the PDF, the signature, or any personal data.

Evidence embedded in the signed PDF. The signed PDF carries the signer-visible evidence: the signer's typed name, the OTP-verified email in plaintext, the envelope-scoped email HMAC, and the signing-act context needed to verify the ceremony. That plaintext email is inside the PDF you keep or share; FreeSign servers retain only the HMAC form after the OTP step. This distinction matters: distributing the signed PDF distributes the signer identity and embedded evidence with it, and that evidence cannot be recalled once the PDF has been shared.

Envelope ids and receipt endpoints. The envelope id is a lookup identifier for the signing event. Anyone who has the signed PDF can read the embedded evidence from the file; anyone who also knows the envelope id may use FreeSign's receipt/audit endpoints as an optional convenience or cross-check while the service is available. Treat envelope ids and receipt URLs as evidence-bearing identifiers, not as private account credentials. The receipt endpoints do not contain PDF bytes and are not required for the signed PDF to remain verifiable.

6. Your rights

Subject to the conditions in the GDPR, you have the right to: access your personal data; rectify inaccurate data; erase data; restrict or object to processing; and data portability. Where erasure is requested, note the constraint described in section 4 — the immutable evidence record cannot have individual rows deleted without destroying its integrity, so the right to erasure over that record is satisfied through retention expiry rather than selective deletion. You also have the right to lodge a complaint with a supervisory authority — in Poland, the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO), ul. Stawki 2, 00-193 Warszawa.

To exercise any of these rights, contact support@coderai.dev. We will respond within the period required by law. You may need to provide enough information to identify the envelope(s) concerned.

7. Optional in-browser Document Intelligence (POC)

When the optional Document Intelligence feature is enabled on a deployment (server flag ENABLE_DOCUMENT_INTELLIGENCE=true; off in the production deployment at free-sign.com as of the date below), the signing page can run a local AI model in your browser to produce a structured summary of the uploaded PDF before you sign. The summary is informational only — treat it as a hint, not a verdict.

The PDF text itself is never sent anywhere — the model runs entirely on your device, in WebGPU, and the extracted text never leaves the browser tab. The MediaPipe Tasks GenAI runtime and the Gemma 4 E2B Instruct model weights (~2 GB on first download, then cached locally in your browser) are served from FreeSign’s own infrastructure — specifically the models.free-sign.com Cloudflare R2 bucket that FreeSign operates — rather than from a third-party CDN. There are no third-party network hosts contacted by this feature.

The model weights are cached in your browser after the first download, so subsequent runs do not repeat the multi-gigabyte fetch. You can clear that cache by clearing site data for free-sign.com in your browser settings.

If you do not want even FreeSign to see the model-fetch request, do not click the “Run analysis” pill on the AI-analysis card. The feature is opt-in: clicking the pill is what triggers the model fetch and the analysis. If you never click it, no Document Intelligence requests are made.

This section applies only when the flag is set on the deployment you are using. On the production free-sign.com deployment the feature is currently off and the card is not shown.

8. Scope of guarantees and nature of legal information

This privacy notice, and any other legal-flavoured material published on free-sign.com (the FAQ, the trust page, the imprint, the compare pages), is informational. It describes how FreeSign is built and how the GDPR/RODO framework applies to it as of the date below — it is not legal advice and cannot substitute for advice tailored to your specific facts and jurisdiction. Statutory provisions, case law and supervisory-authority guidance change over time; the text on this page may not reflect the most recent developments at the moment you read it. For high-stakes processing, or any uncertainty about the legal effect of a signed document in a specific proceeding, consult counsel qualified in the relevant jurisdiction.

What FreeSign actually guarantees is technical and cryptographic, not legal. The properties we stand behind are the ones described on the trust page and verifiable from a signed PDF using open-source tools: a PAdES-B-T (and, where applicable, PAdES-B-LT) signature; SignedAttributes covering the document ByteRange; an RFC 3161 trusted timestamp; an OpenTimestamps anchor; a leaf certificate issued under the published FreeSign Certificate Authority; and a hash-chained audit trail that can be re-derived from raw events. The further question — whether a signature meeting those properties will be admitted in a particular court for a particular document — is jurisdiction- and fact-specific. FreeSign is offered “as is” without warranty of fitness for any particular legal proceeding; the broader liability framing is in the imprint.

9. The signed document is self-sufficient evidence

Each PDF that completes the signing ceremony embeds, inside the file itself, the evidence a third party needs to verify the signature later: the leaf signing certificate (chained to the published FreeSign CA), the CMS SignedAttributes covering the document ByteRange, the RFC 3161 trusted timestamp, the OpenTimestamps anchor when embedded, and the embedded evidence JSON (CMS unsignedAttribute OID 1.3.6.1.4.1.65834.1.2) carrying the per-signer audit context. Verification does not require continued access to free-sign.com, to the FreeSign D1 database, or to the continued operation of 2Dynamic Games sp. z o.o. — the same signed PDF can be checked offline with our open-source verifier (github.com/free-sign/verifier) or with general-purpose tools such as openssl cms -verify, pyHanko and the ots CLI. The hosted page at /verify performs the same checks in the browser without sending the PDF anywhere.

The practical consequence for the evidentiary record: the signed PDF is the source of truth. Receipt and audit endpoints are optional convenience surfaces for retrieving or cross-checking evidence while FreeSign is online; they are not the legal or cryptographic source of truth and they are not a precondition for the signature’s verifiability. The 10-year retention of the server-side audit chain described in section 4 above is an additional, defence-in-depth copy of evidence already present in or derivable from the signed-document record, not a dependency in the evidentiary process. A party relying on a FreeSign signature should retain the signed PDF itself; doing so keeps the proof independent of FreeSign’s continued availability.

10. Changes to this notice

We may update this notice as the service evolves. The current version is always published at this URL; the date below reflects the last revision. Related material on the trust page, the imprint and the FAQ may be revised independently — if you are relying on a particular statement, check the dates on those pages too.

Last updated: 28 May 2026.