How to check that your file stays with you

This page describes what happens to your DNA test file during the analysis and how to check it yourself, without taking our word for it. You will need a computer and 5–10 minutes.

What happens to the file

The file you choose is read by your browser, on your computer or phone. Parsing the file, comparing it with the knowledge base and preparing the report all happen inside the open tab. Neither the file, nor any part of it, nor its name, nor the finished report is sent to the server. The report exists only on your screen until you save it.

The browser only downloads from the server: the analysis program (the engine), a session key and a “knowledge base slice” — the part of the database needed for your chip model. To do that it sends the server only service requests: the answer to a small computing task (a check that the request comes from a browser and not from a bulk-download program), the session number in a cookie and the name of the chip model (for example, “23andMe v5”), plus the ordinary headers any browser sends. The browser also sends three service requests about the completion of analysis steps — which step finished and how (“ok” or the kind of error), with no file data. The slice is the same for everyone with that chip and says nothing about you by itself.

The service is designed to work with the internet: a session key is issued for each analysis and is valid for 30 minutes. There is no standalone (offline) version.

How to check: every request the page makes in the Network tab

Every desktop browser has developer tools. Their Network tab shows each request the page sends to the internet: where to, with which method and how much data. If the file were sent to the server, the list would contain a POST or PUT request with a body the size of your file (usually 5–30 MB) — or, if the data were hidden in addresses, many requests with long, meaningless addresses.

Important: open the Network tab before you choose the file — the browser records requests only while the panel is open. If you opened it later, reload the page with the panel open and start again.

Chrome, Edge, Yandex Browser, Opera

1. Open the Geans analysis page.
2. Open the developer tools: press F12 or Ctrl+Shift+I (on a Mac, ⌘+⌥+I). From the Chrome menu: ⋮ → More tools → Developer tools; other browsers in this group name the menu items differently, but the keys are the same.
3. Select the Network tab.
4. If there is no Method column, right-click the table header and tick it.
5. Choose the file, press “Start analysis” and wait for the report.
6. Look through the list (Figure 2). Then type method:POST into the Filter box — the list should become empty (Figure 3). You can check method:PUT the same way.

Firefox

1. Open the Geans analysis page.
2. Press Ctrl+Shift+E (on a Mac, ⌘+⌥+E): the Network tab opens directly. Or press F12 and select Network.
3. The Method column is shown by default. “Transferred” is what came over the network, “Size” is the size of the response.
4. Choose the file, press “Start analysis” and wait for the report.
5. Look through the list. Type method:POST into the “Filter URLs” box — the list should become empty.

Safari (Mac)

1. Turn on the developer tools once: Safari → Settings → Advanced → tick “Show features for web developers” (in older versions, “Show Develop menu in menu bar”).
2. Open the Geans analysis page, then Develop → Show Web Inspector (⌘+⌥+I) and the Network tab.
3. If there is no Method column, right-click the table header and turn it on.
4. Choose the file, press “Start analysis” and wait for the report.
5. Sort the list by the Method column (click its header): every row should say GET.

On a phone, the Network tab can only be opened with the phone connected to a computer, so checking on a computer is easier. The page and the analysis program on the phone are the same.

What you will see

All requests use the GET method, which means the browser only receives data. Large sizes in the list are what is downloaded to you, not what is sent.

The session key request address (session?c=…&n=…) has two parameters: c is the task the server issued, n is the number your browser found while solving it. There is no data from the file in it; you can see this by opening the request (the Headers / Payload tabs).

The service request ping?step=…&code=… also has two parameters: step is the step (loaded — the file was checked, analyzed — the analysis finished, report — the report was shown) and code is how the step ended: ok or a short error name, for example e_net (“no connection”). The server accepts no other values. If the request does not get through, the analysis is not affected.

In the headers of the manifest.json and slice requests you will see the geans_s cookie — the session number, explained below in “What the server does learn”.

What must not be there

• requests with the POST, PUT or PATCH method on the analysis page. The only POST on the site is sending the feedback form from its own page, and only when you press “Send” yourself; its body is only what you typed into the form (as large as the text you typed, at most 24 KB);
• requests whose Payload or Request section contains the contents of your file;
• requests with long, meaningless addresses, especially many in a row: data can also be sent in the address. Only two Geans requests have parameters in their address — session?c=…&n=… and ping?step=…&code=… (see above);
• requests to other sites: the Domain column should show the Geans site everywhere. Firefox shows this column by default; in Chrome and Safari turn it on the same way as Method.

If you see any of these, please let us know: it is a bug and we want to know about it. Use the feedback form for this.

In addition: other sites are blocked

Together with the page, the server sends the browser a security rule (the Content-Security-Policy header). It forbids the page to load anything from, or connect to, any site other than Geans (connect-src 'self'), and to submit forms (form-action 'none'). The exception is the feedback form page: it may submit its form only to the Geans site (form-action 'self'). The browser itself enforces this rule. You can see it in the Network tab: click the first row (the page itself) → Headers → Response Headers.

The Network tab shows the requests of this page. Browser extensions run separately and are not covered by this check; if you are unsure about your extensions, open the page in a window without them (for example, a guest profile).

What the server does learn

The server does not receive the file contents, genotypes, the file name or the report. From the requests themselves it sees a little:

• Your connection address (IP) and the time of the requests — like any website. The Geans server program keeps the address in memory only to limit the number of analyses (no more than 3 per hour from one address) and does not write it to its log.
• The session number (the geans_s cookie). The server issues it together with the key; the browser attaches it to the requests for the table of contents and the knowledge base slice. It is a random number with an expiry time, signed by the server: it lets only someone who passed the browser check get a slice. The cookie lasts 30 minutes, is not available to the page's scripts (HttpOnly) and contains nothing about you.
• The chip model — from the name of the downloaded slice. It is the same for everyone with that chip.
• Whether the full slice was needed. If a second, full slice is downloaded after the model slice, the server knows that the file has at least one marker (DNA position) outside the chip's usual set — but not which one. If the full slice is downloaded straight away, the chip model was not recognised or the file uses the GRCh38 genome build (a newer DNA coordinate system that some services use for their files).
• How long the steps took on your device — from the gaps between requests (task → key → slice → second slice). They depend mainly on the device speed and on solving the check task, partly on the file size; the contents of the file cannot be recovered from them.
• How the analysis steps ended — from the ping requests: whether the file was checked, the analysis finished and the report shown, and if not, the kind of error.
• Ordinary details any browser sends — browser type and version, language.
• A feedback form message — only if you sent one: the text and the contact you gave. They are stored with the date of sending, without the address.

What goes into logs

• The Geans server program logs the time, the method, the request path without parameters and the response code. The path of a downloaded slice contains the chip model, so the log shows which slices were downloaded (including a second, full one) — without the address and without the cookie.
• The web server in front of it (nginx) is set up by the deployment checklist: its request log has no address, no browser type and no referring page. The address can get into the web server's error log when a connection fails: the format of that log cannot be configured.
• Logs kept by the hosting provider, network-attack protection and internet providers are outside our control.

Independent review

An independent audit is planned: an outside specialist will check that the file is not transferred, that the page does not contact other sites and that the server does not keep anything it should not. When the audit is done, a link to its report will appear here.

The audit scope is published: what exactly the auditor will check — which promises, by which methods, and how the auditor will make sure the server runs the same program that was reviewed.

The audit has not been carried out yet.