# Privacy Policy

**Last updated:** June 2026.

## In plain words

0. *ZERO GENETIC DATA RETENTION*. We do NOT store your genetic data. Raw data is immediately deleted after in-memory processing. Processed data ("the report" datastructure) is deleted at session expiry or immediately when you click *Erase all data*.
1. *We will never share or sell your data* - not to advertisers, not to insurers, not to "lawful" requests. We physically cannot: we do not have it.
2. *No leaks to third parties, no metadata.* No analytics cookies (Google Analytics, Meta Pixel, etc.), no externally-hosted assets. And no ads.
3. The service is *anonymous* - it does not ask for your name / email / account. You upload your raw file every time.
4. All traffic is *encrypted*. Same encryption your bank uses. Same encryption militaries use.
5. *No conflict of interest.* We fund the platform out of our own pockets, build it on our own time, and answer to no investor, no acquirer, no agency.
6. *People & location.* Infrastructure runs on AWS in Frankfurt. All staff are physically based in the EU. **No data is transferred outside the European Economic Area.**
7. You can always instantly erase your data: click *Erase all data*.

---

## Who we are

The **data controller** is **GTCA23 SRL**, a private limited company registered in Romania (EUID: **ROONRC.J2026032062007**). We are based in the EU and processing happens entirely within the EU.

Our **Data Protection Officer** can be reached at [contact@codegen.eu](mailto:contact@codegen.eu).

## Legal basis: why we are allowed to touch your data at all

We process **two** small categories of data, each on a separate legal basis:

* **Your genotype file** - this is *genetic data*, a special category under GDPR Article 9. We process it **only** on the basis of your **explicit consent** (Article 9(2)(a)), recorded when you tick the consent box on the upload page. You can withdraw this consent at any time by clicking *Erase all data*. Withdrawal is instant and total. Withdrawing consent does not undo lawful processing that already happened - which, in our case, finished in seconds and left nothing behind.
* **Session and CSRF cookies** - necessary for the service to function. We rely on Article 6(1)(b) (performance of a contract you have with us) and the strictly-necessary-cookies exemption under the ePrivacy Directive. No analytics cookies, no advertising cookies, no consent banner needed.

We do **not** process your data for advertising, profiling, statistical analysis beyond a single anonymous distinct-user count, scientific research, or any secondary purpose. If we ever want to, we will ask first, separately, and explicitly - that is what GDPR requires and what we believe in.

**Providing the genotype file is a contractual requirement** in the sense that there is no service without it. If you do not want to upload, do not upload - there is no penalty, you simply do not receive a report.

## What we process, what we keep, for how long

| What | Retained for | Where |
|---|---|---|
| Your raw genotype file | **Seconds**, in RAM, while the report is built. Then erased. | Application memory only. Never written to disk. |
| Your report (in-memory data structure) | Until session expiry (~6 hours) or until you click *Erase all data*, whichever comes first. | Application memory + ephemeral session store. |
| **Cryptographic DNA hash** (version-tagged HMAC-SHA-256 over a noise-only SNP subset, signed by a key that never leaves a hardware security module in production) | For as long as we run the service. Used only to count distinct users and recognize returning paid users. Not reversible to genetic, health, or ancestry data. See the DNA Hash Architecture annex. | Encrypted database. Signing key held in AWS KMS (hardware-backed); in local development only, a server-side pepper stands in for it. |
| **Favorites you save** | Working copy cleared on exit / inactivity; an **encrypted** copy persists on your profile until you remove it or opt out at exit. For **Genes for Good** and **WeGene** uploads, favorites are **session-only** and are never persisted. | Sealed with **two private keys** - one **derived from your genome** (never stored) and one **of ours in a hardware KMS** - so we can't read them; decryption needs **both** your genome file **and** our key. Working copy lives only in the ephemeral report data. |
| **Comments you post** | Retained as anonymous community contributions (not removed on erasure). | Encrypted database, with **no link** to any user, hash, or identity. |
| Session and CSRF cookies | Session lifetime, typically ~6 hours. | Your browser. |
| Webserver logs | **< 1 day**, capped at 5 GB rolling. No PII recorded by design. | Cluster-local. |
| Payment metadata (transaction reference) | As required by EU/Romanian accounting law (typically 10 years). Stored by our Merchant of Record (Creem / Armitage Labs OÜ), not by us. | Creem systems in the EU/EEA (see Recipients section). We **intentionally break any link** between payment records and our user data, so the two datasets cannot be joined - even by an actor who compromised **both** codegen and the payment processor. |

Once the retention period elapses the data is gone. We do not archive, back up to long-term storage, or otherwise resurrect retained data.

Concretely: raw data (the DNA file you voluntarily upload) is deleted after in-memory processing. The processed report is deleted at session expiry or when you click *Erase all data*. If either deletion fails, regular cron jobs check for and erase any data that escaped deletion (crashes, etc.). If that fails, at random intervals and on every deployment the entire software stack (containers, EC2 instances) is destroyed and a new stack with fresh instances is created, wiping any temporary remnants. Service logs do not contain PII because we don't write PII to logs in the first place, and the logs themselves are short-lived.

Because we don't store your genetic data, you have to upload your raw data every time you use this service.

## Favorites and comments

**Favorites** are tied to your anonymous DNA hash (the same hash that acts as your login), never to a name or identity. Your live favorites are part of the report data that is cleared on exit or after inactivity. So that they survive across visits, we also keep an **encrypted** copy sealed with **two private keys**: one **derived from your genome in memory at login** (its private half is never stored) and one **of ours, held in a hardware KMS**. This means **we cannot read your favorites** - decrypting them requires **both** your original genome file **and** our private key, on top of the encrypted database itself. Technical limit: anyone who can reproduce the same core genotypes (in practice, a holder of your genome file) *and* obtain our key could decrypt them, so this is as strong as your genome file and our key together, not "only you, ever." At exit you can untick *Keep FAVORITES encrypted* to delete that copy too; clicking *Erase all data* always removes everything tied to your hash.

For uploads from **Genes for Good** and **WeGene**, we **never persist favorites at all**. Because these files under-cover the core marker panel, no stable per-user key can be derived from them, so favorites for these providers live **only in your session** - they are cleared on exit or after inactivity and are never sealed or stored on your profile.

**Comments are fully anonymous.** A comment you post is stored with **no link to your hash, your account, or any identity** - not even the anonymous one. We cannot tell who wrote any comment, and neither can anyone else: they appear to other users with no author name and no profile. Because a comment is not tied to you, it is **not removed when you erase your data** - it remains as an anonymous contribution on that genotype. The demo genome is read-only for comments, so the shared pool stays clean.

## Anonymous service

We don't want to know who you are: no names, no email, no account, no username, no password.

You just have to upload the DNA data file every time. The data acts as both username and password. When you upload your DNA, the DNA hash is computed and we check against a filter whether we have seen this DNA before, and if so what type of user (free / paid) - without having to store usernames, passwords, genetic data, or any other PII.

If our entire codebase and database were dumped on the internet tomorrow, our users would still be safe. There is nothing in it: no names, no genetic data, no health data, no ethnicity. Not even a sophisticated state actor could reconstruct it - directly or by inference. We designed it that way.

## Who else touches the data

We share your data with **no one**. The only entities with technical proximity to it are:

* **Amazon Web Services EMEA SARL** (Frankfurt region, eu-central-1) - acts as our **data processor** for compute and storage. AWS does not access the data; it provides the metal. We have a Data Processing Agreement in place with standard GDPR clauses. **No data leaves the European Economic Area.**
* **Creem** - operated by **Armitage Labs OÜ** (an Estonian company, registry code 16977866), our **Merchant of Record** for payments (see Terms of Service §7). As Merchant of Record, Creem is the legal seller for the payment leg and handles card processing, invoicing, and the calculation, collection, and remittance of VAT. It sees the payment instrument and an opaque transaction reference; it does **not** see your DNA, your report, or any link between the payment and your genetic data. Creem processes personal data under the EU GDPR (2016/679) and is bound by its own privacy policy.

That is the complete list. We do not have an analytics provider, a CDN that touches user content, an ad network, a CRM, a customer-data platform, an email marketing tool, or any other third-party data destination.

**International transfers.** We do not transfer your data outside the European Economic Area. AWS Frankfurt is in the EEA, and our Merchant of Record, Creem (Armitage Labs OÜ), is established in Estonia, within the EEA.

## No leaks to third parties, no metadata

We don't use Google Analytics, Meta Pixel, or any analytics SDK. We don't embed Facebook/Google/LinkedIn/X/Instagram widgets. We don't load Google Fonts, remote JS, remote CSS, or remote images. Every byte this site serves comes from our own servers.

Anything else would leak your visit to a third party - for example, with Google Analytics enabled, Google would record that you (an authenticated Google user) visited `/topic/cancer`. We treat that as unacceptable, even at the cost of having zero usage metrics.

## Security of data processing and encryption

HTTPS protects traffic in transit. Once your upload reaches our servers it is processed in memory and erased. We do not promise the impossible: no system is unhackable. We promise instead to be a worthless target - see below. Email is a separate matter: anything you send us by email is not protected by the encryption built into the website until it reaches us.

We use client-side KMS keys instead of server-side (safer), all traffic is isolated in our cluster via private networks, all instances have encrypted disks and no SSH or external access. We audit our code before each deployment with AI code review and our codebase has explicit checks designed to prevent certain but not all risks. Access to the infrastructure is logged and audited with 2FA mandated.

That said, codegen.eu is NOT hack-proof - we are unlikely to withstand a state-sponsored attack. We assume that at some point we will get hacked and code accordingly. We made ourselves a zero-data-value target. You can hack us, you can subpoena us: all data was processed in memory and erased, service logs do not contain PII and are deleted, our software stack is destroyed, updated and re-deployed at random frequent intervals to wipe out potential complex implants and reduce vulnerabilities.

People & location: infrastructure runs on AWS in Frankfurt. All codegen.eu people are physically based in the EU. We are all privacy fanatics in our daily lives: we use VPNs, Tor, ZFS encrypted partitions, encrypted home directories, swaps disabled, hardened browsers, hardened phones, no Windows for dev or at home, no cloud storage. We are all senior+ engineers & scientists: ex-Amazon, ex-Microsoft, and ex-Meta.

## Cookies

We set two short-lived cookies: *csrftoken* and *sessionid*. Both are random tokens, both expire with your session (typically 6 hours), and neither is linked to your genetic data. They exist because HTTP is stateless and because we refuse to be CSRF-vulnerable. Both fall under the strictly-necessary-cookies exemption of the ePrivacy Directive, which is why we do not show a cookie banner.

## Automated processing and AI

Your report is generated by **Large Language Models** running over scientific literature and public databases. This is automated processing under GDPR. However:

* It is **not** "a decision based solely on automated processing… which produces legal effects concerning [you] or similarly significantly affects [you]" within the meaning of GDPR Article 22. The output is *informational text*, not a decision about you, your eligibility, your insurance, your employment, or anything else with legal or similar effect.
* We do not feed your genetic data into model training. The model is queried; it does not learn from you. After the query, your data is gone (see the retention table).
* **Pre-computing is offline and genome-free.** The heavy analysis is performed **offline, by our scientists, over public scientific literature and databases - never over user genetic data.** No LLM ever sees your genotype file, any part of it, or anything derived from it. Population distributions and polygenic scores are computed from **public datasets** (1000 Genomes, gnomAD, the GWAS Catalog, and similar), not from you.
* Where we use third-party model APIs, only **non-identifying** intermediate prompts (variant identifiers, literature excerpts) are transmitted - never your raw file, never the joint genotype string, never anything that ties to you.

See the Terms of Service for our candid warnings about LLM hallucination and the obligation to consult a qualified clinician before acting on anything you read.

## Children

This service is for adults. We do not knowingly accept, process, or retain data of anyone under **18 years of age**. The upload step requires you to confirm you are 18+. If you are a parent or legal guardian and believe a minor has used the service, write to [contact@codegen.eu](mailto:contact@codegen.eu) and we will erase any associated data. (Realistically, we already erased it - see the retention table - but we will confirm.)

## DNA is shared. So is the responsibility.

Even when we hold nothing, the act of uploading reveals information about your parents, siblings, children, and more distant relatives. Those people did not consent to your decision to use this service. By uploading, you confirm that:

* The DNA is yours, or you have the explicit consent of the person to whom it belongs.
* You understand that any insight you gain may also be true (or false in informative ways) for your relatives.
* You will not upload anyone else's DNA without their consent, and you will not upload the DNA of a minor unless you are their parent or legal guardian.

This is a hard constraint, not a polite suggestion.

## Your rights under GDPR

You have the following rights over personal data that relates to you. Most of them are easy to satisfy because **we do not have your data**.

* **Right of access** (Article 15) - write to [contact@codegen.eu](mailto:contact@codegen.eu). We will reply within 30 days. In almost all cases the honest answer will be: *we have no data about you. Your raw file was processed in memory and deleted. The hash we hold is not reversible to you.*
* **Right to rectification** (Article 16) - there is nothing for us to rectify because we do not hold your information. If anything in the policy is itself inaccurate, write to us and we will fix it.
* **Right to erasure / "right to be forgotten"** (Article 17) - click ***Erase all data***. Erasure is immediate. You may also request erasure by email.
* **Right to restriction of processing** (Article 18) - write to us.
* **Right to data portability** (Article 20) - the only "portable" data we hold is your report, while your session is active. You can save the page or print to PDF at any time.
* **Right to object** (Article 21) - write to us.
* **Right to withdraw consent** (Article 7(3)) - clicking *Erase all data* withdraws consent and deletes data simultaneously. Withdrawal does not affect the lawfulness of processing that took place before withdrawal.
* **Right to lodge a complaint with a supervisory authority** (Article 77) - you may complain to the data protection authority in the EU/EEA Member State where you live, where you work, or where the alleged infringement took place. A list of all EU/EEA authorities is at <https://edpb.europa.eu/about-edpb/about-edpb/members_en>.

We will not retaliate, penalize, or degrade service for any user who exercises any of these rights.

## US residents: your rights under state and federal law

This service is operated from the EU. If you are in the United States, the following also applies on top of the rights described above.

### California (CCPA / CPRA + GIPA)

Under the **California Consumer Privacy Act** as amended by the **California Privacy Rights Act**, genetic information is "sensitive personal information". You have:

* The right to **know** what personal information we have collected about you.
* The right to **delete** it. We already have nothing; *Erase all data* handles the rest.
* The right to **correct** inaccurate information.
* The right to **limit the use and disclosure** of sensitive personal information. We already limit ourselves to the single purpose of generating your report and counting distinct users. We do not sell or share sensitive personal information for cross-context behavioral advertising.
* The right to **non-discrimination** for exercising any of these rights.

Under the **California Genetic Information Privacy Act (GIPA)**, we obtain your **separate express consent** before processing genetic data, and we honor any revocation within 30 days. In our case, "honor within 30 days" is overkill - revocation via *Erase all data* is instant.

### Florida (Protecting DNA Privacy Act)

We collect, retain, and analyze your DNA **only** with your express informed consent, given at upload. We do not sell, transfer, or disclose your DNA sample or analysis results to any third party. The Florida statute carries criminal penalties for unauthorized collection, retention, analysis, sale, or transfer; we have designed the system specifically so that there is no path to the prohibited acts.

### Illinois (GIPA, 410 ILCS 513)

We do not disclose the results of any genetic test to any party.

### Other US states with genetic-privacy laws

Equivalent protections apply in **Arizona, Maryland, Montana, Nebraska, New Jersey, Tennessee, Texas, Utah, Virginia, Wyoming**, and others. Our baseline - express consent, zero retention of raw or processed genetic data beyond a single session, no third-party disclosure - meets or exceeds the substantive requirements of each.

### Federal: GINA and what it does *not* cover

The federal **Genetic Information Nondiscrimination Act (GINA)** prohibits health insurers and employers (15+ employees) from discriminating against you based on genetic information. **GINA does not cover** life insurance, long-term care insurance, disability insurance, the military, schools, mortgages, or housing. If you share your report voluntarily with any of those entities, you are outside GINA's protection. We strongly recommend you do not share it with anyone other than a qualified clinician bound by medical confidentiality.

### HIPAA does not apply

We are **not** a HIPAA Covered Entity or Business Associate. We are a research and information service, not a healthcare provider, health plan, or clearinghouse. The HIPAA Privacy Rule does not govern our processing of your data. This is not a loophole - it means HIPAA-derived rights (such as the right to a Notice of Privacy Practices) do not apply, and instead the GDPR and state-law rights described elsewhere in this policy apply, which in most respects are stricter than HIPAA.

## If we are breached

We have engineered the system to be a worthless target. But "worthless" is not "impossible". If a personal data breach occurs:

* We will notify the **competent supervisory authority** **within 72 hours** of becoming aware of it, as required by GDPR Article 33.
* Where the breach is likely to result in a high risk to your rights and freedoms, we will notify affected users **without undue delay**, as required by Article 34. Because we do not have your contact details, "notification" in our case means a prominent, time-stamped notice on the front page of [codegen.eu](https://codegen.eu) describing what happened, what data was affected, and what (if anything) you should do.
* We will publish a post-mortem.

We also maintain a **warrant canary** at the bottom of this policy. If it disappears, assume the worst and act accordingly.

## Changes to this policy

We may update this policy. Material changes will be flagged at the top of this page and on relevant pages of the site, with the "Last updated" date adjusted. If a change materially expands what we do with your data - we hope it never will - we will ask for **fresh consent** rather than assume your previous consent covers the new processing. Continued use after a non-material change constitutes acceptance of the revised text.

----------------------------


# ANNEX

# How We Protect Your Privacy: DNA Hash Architecture (our user quasi-id)

TLDR: A version-tagged, keyed hash (HMAC-SHA-256) over uninformative genetic noise. It cannot be reversed into your DNA; it can only be *matched* by a party who already holds both our signing key and your genome file.

## What We Compute and Why It Is Not Sensitive

*The noise:*

Your raw genotyping file contains hundreds of thousands of SNPs, many of which encode medically actionable variants, disease predispositions, ancestry composition, and pharmacogenomic traits. **We never use any of that in DNA hashing.** Instead, we apply a multi-stage selection pipeline that deliberately discards everything of biological significance.

**SNP selection is designed to be medically and ethnically uninformative.** The core subset is restricted exclusively to autosomal SNPs with high minor allele frequency across all five continental superpopulations (African, American, East Asian, European, South Asian). SNPs with significant between-population frequency divergence - the very markers that encode ethnic ancestry - are actively penalized and excluded. SNPs in or near the MHC/HLA complex, immunoglobulin loci, T-cell receptor loci, centromeric and telomeric regions, and any region associated with structural variation are entirely excluded. The result is a set of genomic positions that are maximally *boring*: common, stable, population-neutral markers that carry negligible ancestry, disease, or pharmacogenomic signal.

Furthermore, LD pruning (r² < 0.2 within 500 kb windows) ensures that no two selected SNPs are statistically correlated - the subset carries less joint information than its size implies.

## How the Hash Is Constructed

*The cryptography:*

From the selected SNPs, only the biallelic genotype call at each position is extracted. Each call is canonicalized to a strand-orientation-invariant form (lexicographic minimum of the allele pair and its reverse complement), so the representation is provider-agnostic. No chromosome coordinates, no reference alleles, no metadata - only the minimal symbolic call. These calls are concatenated in a deterministic sorted order into a compact string.

The resulting string is tagged with a **scheme version** (`c2` for the current core-panel identity) and reduced with **SHA-256** to a fixed-length seed. That seed is then signed, under a dedicated `genome-identity` domain separator, with **HMAC-SHA-256**. In production the HMAC is computed inside **AWS KMS**: the signing key is generated in - and never leaves - a hardware security module (HSM); our server asks KMS to sign and only ever receives the result. In local development a server-side **pepper** stands in for the KMS key and is never stored alongside the hash or the user's data. The final identifier is the scheme tag followed by the MAC, e.g. `c2-…`.

**Low-coverage providers.** A few genotyping files (currently Genes for Good and WeGene) do not cover enough of the core marker panel to yield a stable core identity. For these, the same HMAC-SHA-256 construction is applied to the **whole uploaded file** under a separate scheme tag (`f1`), producing an `f1-…` identifier. This is unique to that exact file but carries no cross-provider or cross-reformat determinism - and because no stable per-user key can be derived from such a file, favorites for these providers are session-only and are never sealed or persisted.

## Why This Cannot Be Reversed Into Genotype Data

The identifier is a **keyed message authentication code (HMAC-SHA-256)**, not a plain digest. SHA-256 and HMAC are one-way functions: there is no algorithm that inverts them, even with unbounded compute. Because the signing key lives inside a hardware security module (or, in local development, is a pepper never co-located with the database), an attacker who obtains the full hash database cannot recompute or brute-force candidate inputs without also compromising the signing key. Even then, the space of possible genotype strings is astronomical, and the underlying markers are population-neutral and medically uninformative - so recovery would reveal nothing sensitive. **The hash cannot be reverse-engineered into genotype data.**

**Technical limit.** This is *matching*-resistant, not *absolutely* irreversible. Anyone who holds the **live signing key** *and* a **candidate genome file** can recompute the identifier for that candidate and test it against a stored value - that is exactly how we recognize a returning user at login. So the identifier is only as private as the signing key and your genome file together: it cannot be turned back into your DNA, but it *can* be matched to a genome by a party who already possesses both. We do not claim "only you, ever" - we claim it encodes no genetic, health, or ancestry information and cannot be reversed into any.

## Protection in Case of a Breach

Should the hash database be exfiltrated:

- **No genotype data is recoverable.** The hash is a fixed-length digest with no structural relationship to the input.
- **No medical information is exposed.** Even the underlying input - the genotype string - was constructed from population-neutral, medically uninformative markers.
- **No ethnic or ancestry information is exposed.** Selection criteria explicitly removed all ancestry-informative markers.
- **The data has zero commercial value.** The hash cannot be sold to insurers, pharmaceutical data brokers, or ancestry services because it encodes no trait, disease, or population signal. It is commercially inert random crypto noise.
- **The signing key renders the hash non-transferable.** A hash computed under our KMS signing key (or, in local development, our pepper) is incomparable to any hash computed elsewhere, defeating cross-database correlation attacks.


## Cross-Provider Interoperability

The pipeline handles raw data from 23andMe, AncestryDNA, MyHeritage, FamilyTreeDNA, and LivingDNA. All major chip versions (Illumina OmniExpress, GSA, HumanHap550, HumanOmni1, etc.) are represented in the core subset selection, ensuring the same SNPs are genotyped regardless of which consumer platform the user employed. Strand orientation differences between providers are resolved by canonicalization. Split-allele formats (AncestryDNA) and unified genotype columns (23andMe) are both parsed. The output hash is therefore identical for the same individual regardless of which provider's file is submitted.

Genes for Good and WeGene are the deliberate exception: their files under-cover this shared panel, so they fall back to the full-file (`f1`) scheme described above. Their identity is unique to the exact file uploaded and is intentionally **not** recognized across providers or across reformatted re-uploads.

## Plausible Deniability

Because the subset is intentionally small and missing calls are replaced with a neutral sentinel, the system tolerates a defined level of per-individual variation. This means that no exact cryptographic uniqueness is guaranteed for every individual: a small number of distinct individuals may produce the same hash. This is an engineered property. It means **no hash can be unambiguously attributed to a single individual in a legal or forensic context** - a user can always plausibly claim that the hash matches another individual, because by design it might. This provides meaningful plausible deniability without meaningfully degrading the practical utility of the hash for its intended purpose.

* *Canary:* we have never received a subpoena, court order, or any other legal request so far. **Our policy: when in doubt, delete everything.**