Privacy

This page lists every piece of personal data OSCR holds or causes to be processed, read from its code rather than written from memory: what it is, why, where it lives, for how long, and how to exercise your rights — without an email address, since the registry has none. Last updated: 29 September 2026.

In short

• Reading the site needs no account, sets no cookie, and runs no analytics, advertising or third-party tracker.
• Signing in (ORCID, GitHub or Google) asks for no email address; the registry keeps your public handles, your roles and your requests — never a password or a provider's token.
• The records show authors as their papers publish them: names, ORCID iDs, affiliations. Never an email address or a telephone number.
• The operator does keep, privately, the contact details that papers publish for their authors — email addresses included — to cite the authors of the code and to reach an author about their own work. They are never shown, never published, never used for mass email, and an author signed in with their ORCID iD sees them and has them erased at once on your data and your rights (below).
• When you open a paper's Code ↔ Paper reader, your browser fetches the paper from Europe PMC or NCBI directly, and a file of code that OSCR does not copy from where its authors published it.

Who is responsible

The controller of the personal data described here, in the sense of the EU General Data Protection Regulation (GDPR), is the registry's sole operator. The operator's name and postal address are published on this page before the registry's public launch.

OSCR has no email address. To reach the operator about your data, see your rights.

Visiting the site

The site is hosted by Cloudflare, on its Workers platform. To deliver each page, Cloudflare's network necessarily processes your IP address, the address you ask for and what your browser sends with it (its user agent, its language). OSCR's own code keeps no log of visits: its pages are static files, and the few requests that run its code — the search, sign-in, requests, the pages of older papers, a missing page — are answered without writing who asked. Cloudflare processes that traffic under its own policy, for delivery and security; its responses may ask your browser to report network errors to Cloudflare. No other service sees your visit, except those your browser contacts on the pages listed below.

A search is sent to the site (the words, the filters) and answered from its database; it is not recorded with who searched. The DOI lookup runs in your browser, which fetches one of the site's files: the DOI you type is not sent anywhere else.

What your browser asks other services

• A paper's Code ↔ Paper reader: to show the paper, your browser fetches its full text from Europe PMC (EMBL-EBI, www.ebi.ac.uk), else from NCBI's copy of PubMed Central (eutils.ncbi.nlm.nih.gov), when the paper pane is shown. Those services receive your IP address and the paper's identifier, as when you read the paper on their sites. Hiding the paper pane before it loads avoids the request.
• A file of the authors' code shown from its source: OSCR's copies come from the site itself, but a file whose licence allows no copy is fetched by your browser from its host, at the verified commit — GitHub (raw.githubusercontent.com), GitLab.com (gitlab.com), Bitbucket (bitbucket.org), Codeberg (codeberg.org), Hugging Face (huggingface.co), Zenodo (zenodo.org), or Software Heritage (archive.softwareheritage.org) for the other forges. The host receives your IP address and the file's address (its repository, commit and path, or its fingerprint), as when you open the file there; no cookie and no page address are sent with the request. Only the file the reader shows is fetched: the one a paper's page opens on, or one you choose (the code policy).
• Signing in takes you to ORCID, GitHub or Google, which then know that you signed in to OSCR.
• Links you follow (doi.org, a publisher, a forge, Zenodo) lead to those sites; the site tells them nothing of where you came from (its referrer policy sends no address to other sites).

Every page's security policy forbids it to load anything from any other site than those named here.

Cookies and local storage

No cookie is set while you read. Signing in sets these, for this site only, over HTTPS only:

These are strictly necessary for a service you ask for: they need no consent banner, and the site has none. The reader also remembers, in your browser's local storage, three display choices — the paper pane hidden, long lines wrapped, the list of files open or closed. They stay on your device and are never sent.

Accounts

Stored in a Cloudflare D1 database (oscr_community), for each account: a random identifier; the name a provider gave (ORCID's public name, GitHub's name or login; Google gives none, and a name never holds an at sign); your ORCID iD and GitHub login once linked; when it was created. For each linked identity: the provider and its identifier for you (your ORCID iD; GitHub's account number; Google's opaque identifier). For each session: the SHA-256 of its cookie's identifier, when it began, expires and was last seen (to the hour), and a short description of the browser such as "Firefox on macOS" — never the full user agent, never an IP address. Your roles (verified author of a paper, maintainer of a repository), who granted them (the automatic checks, the moderator's rules or the operator) and when.

Never stored: an email address, a password, a provider's access token (used during the sign-in, or once for a maintainer check, then dropped). ORCID and Google are asked for the openid scope only; GitHub for no scope.

To recognize authors, the same database holds public facts from the papers: the ORCID iDs listed as a paper's authors, with the paper's identifier and title (paper_orcid), and the owners of its code repositories as their addresses name them (repo_owner, paper_repo).

Requests you send

Each request is a row linked to your account, in the same database, with a row that tells the operator's computer to look at it:

A submission

the DOI, one to five code links, your note, the site's checks, its status, the draft the harvester made, and the words of its decision.

An author claim or a maintainer claim

the paper or repository, your statement and optional link, or the evidence of the GitHub check (your GitHub login and number, and how the check succeeded), its status and the words of its decision.

A correction

the paper, your role, the changes, your note, its status and the version it made.

A validation

the paper, your ORCID iD, how it was proven (ORCID or ORCID's sandbox), the map's digest, its status, and the DOI and record it received.

A removal request

the paper, who you are (author, rights holder, named person, other), whether you are a verified author, what to remove, why, your justification, your evidence link, your confirmations, its status and the words of its decision (the rules' or the operator's).

A data-rights request

the right you asked for, your words, the ORCID iD of your account's ORCID identity and whether orcid.org or its sandbox proved it, its status, its legal deadline (one month), and the answer — for access, what is held, field by field, every email address masked (below).

Every free text loses any email address before it is stored, and the database refuses an at sign. Requests are decided by published rules, applied on the operator's computer (how requests are decided). That computer keeps, in its state file (data/community/state.db):

• Each request's state: its status and attempts, and, for a request that waits for the operator, what the operator needs to decide — its texts (note, statement, justification, evidence link) and your account's name, ORCID iD and GitHub login.
• The moderator's log: every decision on a removal request, a submission, a claim or a data-rights request, by the rules or by the operator — when, the request's number, your account's identifier, the paper (or the repository), the rule that decided and what it decided, with what the rule weighed: for a removal request, what it names, why, who you said you are, whether you are a verified author, the repositories you maintain, and a fingerprint of your justification (so that the same words sent again are recognized), never its text; for a submission, what proved each link or did not; for a claim, what verified it; for a data-rights request, the right and how many rows it touched, never their content. While a request waits, the file also notes since when and until when. Entries older than 12 months are deleted.

To decide a claim, the rules read the works of your public ORCID record, by your iD; to decide a submission, the web links of the public ORCID records of the paper's authors. And for an applied correction, the operator's computer keeps who made it (your ORCID iD or GitHub login) in the record's history — which the pages never show: they say "a verified author".

Authors in the published records

The records show the authors of each paper as the paper and its public metadata publish them: names in order, ORCID iDs, affiliations, institutions (with their ROR identifiers, from OpenAlex), and whether an author is the corresponding one. An author with an ORCID iD has a page listing their papers, tools and institutions. The same facts are in the search's database and the site's public files. Email addresses and telephone numbers are removed from everything published, and the site hides any email address written in the authors' code.

The scripts' copies in the open dataset are files as their authors published them under an open licence; the site hides email addresses when it shows them, but the dataset keeps each file's text as it is at the source. A validated tracing map deposited on Zenodo names the validating author and their ORCID iD, publicly and permanently: that is what a validation is for.

Authors' contact details, kept privately

Papers publish how to reach their authors. For the papers it reads, OSCR keeps, for each author, what the paper itself (its full text) and its Europe PMC record publish: given and family names, ORCID iD, email address, organization, postal address, affiliation, whether the author is the corresponding one — linked to the paper, its DOI, title, journal and date.

• Why: to cite the authors of the code correctly, and to reach an author about their own work — their tracing map, a correction, a removal.
• Never: shown on the site, published in any public output (the public exports drop the whole table), used for mass email, sold or shared.
• Where: in the database on the operator's computer, and in a private dataset on Hugging Face, OpenScientificCodeRegistry/Private, which is not public and which the operator alone manages; the software refuses to send it to a dataset that is not private.
• How long: as long as the paper is in the registry's database; erased on request. After an erasure or an objection, the registry keeps your ORCID iD, and a fingerprint (SHA-256) of each address found with it — never the address — on a list of people whose contact details it never collects again; the private copy on Hugging Face is published again without you at the next nightly publication, and its history rewritten so that no earlier version keeps you.
• Your rights: an author may see what is kept about them, have it corrected, have it erased, and object to it, on your data and your rights (how).

On the operator's computer

The harvester's database, on the operator's own computer, holds everything above that comes from papers — their public metadata, their authors, the contact details — along with the full texts it read (never published), the history of every record with who corrected it, the state of the requests it answered with the moderator's log (above), and the list of authors who asked not to be kept. Copies of the database that the operator makes by hand before a change of its structure stay on that computer's disks; an erasure does not edit them by itself, and the registry's software can apply the list of erasures to such a copy. Nothing listens on the network there: requests reach it only as rows the computer reads from the site's database.

The services involved

Each of these services receives the personal data in its row, and processes it under its own privacy policy, linked here (each address checked on 29 September 2026).

The harvester also reads, about papers and code, OpenAlex, Crossref, DataCite, doi.org, the Retraction Watch data, Software Heritage and the forges and archives the papers cite; the site asks doi.org and the cited forges whether a submitted DOI and links exist. They receive identifiers of papers and repositories, not data about visitors — except the hosts your browser fetches a file from, above.

How long

Purposes and legal bases

Delivering the site

Processing your requests to deliver pages and keep the service secure: the operator's legitimate interest in running the registry (GDPR, article 6(1)(f)).

Accounts and requests

Signing you in and answering what you ask — a submission, a correction, a validation, a claim, a removal: the service you request (article 6(1)(b)).

Authors in the published records

Showing who wrote a paper and its code, from what the paper and its public metadata publish: the legitimate interest of the registry and its readers in a public, citable record of research code (article 6(1)(f)).

Authors' contact details

Citing the authors of the code and reaching an author about their own work, from what the paper publishes: the operator's legitimate interest (article 6(1)(f)), balanced by keeping them private, never mass-emailing, and erasing them on request. This page is the information the GDPR requires when data is not obtained from the person (article 14).

Answering your data-rights requests

Access, erasure, objection, rectification, the deletion of your account, and the list of authors who asked not to be kept, which is what keeps their contact details from being collected again: the operator's legal obligation under the GDPR (article 6(1)(c), with articles 12 to 21).

Your rights, and how to use them

Under the GDPR you may ask for access to the data about you, its correction, its erasure, the restriction of its processing, and a copy of what you gave in a reusable form; and you may object to processing based on legitimate interests — in particular to the keeping of your contact details, which is then erased.

OSCR has no email address. Use your data and your rights, signed in: it shows what the site's database holds about your account (with a copy to download), and takes one request at a time. The registry's machine reads the requests every ten minutes or so, and answers by itself what it can prove:

Access

What your account holds, what the operator's computer keeps about it (the moderator's log, your requests' state, the corrections attributed to you), the papers whose metadata list your ORCID iD, and — signed in with your ORCID iD at orcid.org — each contact detail kept under that iD, field by field. Your email address is shown masked (its first and last characters, and its domain): the site never shows or stores an email address, and the paper named with it prints it in full, which is where the registry read it.

Erasure, objection

Signed in with your ORCID iD: the contact details kept under it are erased, and your iD goes on the list of people whose contact details are never collected again (above). The private copy on Hugging Face loses them at the next nightly publication, which rewrites its history. The two rights have the same effect here.

Deletion of your account

Your account's rows are deleted: the account, its sessions (you are signed out everywhere), its linked identities, its roles, its claims and every request it made. What stays, and why: the moderator's log, which names the account by its random number only, 12 months (the record of how each request was decided); the rows of the site's queue of requests, which hold a kind, a number, that random number and a time; what your requests changed in the public records (a correction stays a correction, and the records' history on the operator's computer names its author by the account's random number instead of an ORCID iD or a GitHub login); a validated map's record on Zenodo, public and permanent, as a DOI is. Cloudflare's point-in-time recovery of the database keeps its earlier states for 7 days.

Rectification, and what an account without an ORCID iD asks

A name, a GitHub login or a Google account proves nothing about who wrote a paper, so the registry cannot tell by itself which contact details are yours: such a request, and every rectification, waits for the operator.

The operator answers within one month, as the GDPR requires (article 12(3)), and the page shows the date. There is no human moderator on duty at the moment, but a request about your data is never closed unanswered: it stays open, at the top of the operator's list, until it is answered. The same holds for a removal request made for personal data — about what a record publishes — that the rules cannot decide: it waits for the operator, never closed after 30 days as other requests are. A refusal says why. You may also complain to the data protection authority of the country where you live or work.

Where the data is

The site's databases were created in Cloudflare's Western Europe location, and its pages are delivered by Cloudflare's network. The harvester's database is on the operator's computer. Several of the services named above are run by organisations outside the European Economic Area, and receive the data listed in their row when you use them or when the operator publishes; each says in its privacy policy, linked above, where it processes personal data and how it protects the data it receives from the European Union.

Security

• Sessions: random identifiers, stored hashed; cookies for this site only, over HTTPS only, and not sent with other sites' requests; every change requires a token bound to your session, from this site's own pages.
• No provider token is kept; GitHub is never asked for a permission.
• Every page forbids framing and loads nothing from other sites than those it needs; every connection is HTTPS.
• Secrets live in Cloudflare's secret store and the operator's keychain, never in the code.

To report a vulnerability, use GitHub's private security advisories.

Changes to this page

This page changes when the registry does. Its history is public in the project's source (the page's history). Last updated: 29 September 2026.