Privacy Policy

1 · Who processes your data

CiteLink is the data controller under the Turkish Personal Data Protection Law (KVKK, Law No. 6698) and the EU General Data Protection Regulation. [TO BE COMPLETED: registered commercial title, registered address, MERSİS number] The service also operates under the business name Zeus Publishing; both names refer to the same operation and the same people.

The registration is in progress, so the line above is a name rather than a registry entry — we would rather mark that than invent it. It changes nothing about your rights: until the company is registered they run against the person operating the service, and every request reaching info@citelink.org is answered by the same people either way. Ask and you will be given the responsible person's name and address directly.

Reach us at info@citelink.org, which needs no account, or through the contact form, which is for signed-in members (section 3).

2 · The scholarly record — our largest processing activity

Policies like this one usually describe a contact form and stop. Ours cannot, because most of the personal data CiteLink processes is not data you gave us. It is the published scholarly record.

We index 32.3 million author profiles — a name, institutional affiliations, an ORCID where one exists, and a publication and citation history — alongside 101.7 million articles and 62,643 journals. It comes from OpenAlex under a CC0 public-domain dedication, and consists of facts already published in the literature.

Lawful basis. Legitimate interest (GDPR Art. 6(1)(f)) in maintaining a public, verifiable scholarly index, with the research provisions of Art. 89 and the corresponding KVKK grounds. We publish no special-category data, no private contact details, and nothing not already public.

If a record about you is wrong, see section 9.

3 · What you give us

Since 4 October 2026 the three forms are for members. An indexing application, a message through the contact form and a correction request are accepted only from a signed-in CiteLink account whose e-mail address a link we mailed to it has proven. An account is free. Registering asks for your name, your address and the kind of account, and for no password: it sends our activation mail (section 6), and you choose your password on the page its link opens. A link cannot practically be guessed instead: each carries a ten-digit code, and our server lets one internet address try about 1,450 codes in the day a link lasts, out of ten billion. Opening that link shows that whoever opened it can read the mailbox, and it makes the account theirs: when the link is opened, our database discards whatever password the registration was made with, and the person who opened it chooses the next one, which ends every other sign-in to the account. So if somebody else registered your address first and never activated it, they are left with nothing to sign in with. The address on anything you then send is your account’s: our database writes it in, together with which account sent it, whatever the page sends, so none of the three forms can be used to make us write to somebody else’s address. Your account can read back what it sent, and nothing anyone else sent; everyone with access to our editorial console — owners, administrators and read-only viewers — can read all of it. Accounts created before our activation mail was switched on were confirmed without one: such an account can use the forms once its holder has asked for a password reset on the sign-in page and opened the link we mail, because a reset link proves the address as the activation link does. Writing to info@citelink.org needs no account.

Our record of a proven address. For each account we keep one record of the address a link we mailed has proven: the address, when the link was opened, and whether it was the activation link or a password-reset link. Our database writes it itself when such a link is opened — or when one of our operators confirms an address by hand on our server — and nothing else writes it; it writes none while our sign-in service is set to confirm accounts without mailing them. Since 8 October 2026 an owner or administrator of our console can also approve an address that no link has proven, when they have verified it another way — for instance, you wrote to us from it; the record then says it was approved by an administrator, and we keep who approved it and the note they wrote on how they verified it. They can also have the activation or password-setting link mailed to you again; that mail is the one the site sends when you ask for it. Your account can read its own record; everyone with access to our editorial console can read all of them. A later link replaces it. Any change of the account’s address removes it, even one confirmed by the links we mail for that change: a password-reset link to the new address proves that address again. It is kept while the account exists, and deleted with it.

Applications sent before the forms needed an account came with no account, only the contact address typed into the form. Such an application can be linked to an account in the Publisher Panel, by its reference and a code. Any signed-in account whose own address a link we mailed has proven, as above, can ask for a code, and we e-mail it to the application’s contact address (section 6) — so only someone who reads that mailbox can link the application, whatever the account’s own address is. The code works for 30 minutes, for five tries, and only from the account that asked. For each code asked for we keep the account, the reference, when it was asked and until when it works, how many tries were made, whether and why it was closed, the address it was mailed to, and a fingerprint of the code (its SHA-256) to check a try against — never the code itself once the mail has gone. We keep the same record when the reference matches no application, or the code was not mailed, so that asking never tells anyone whether a reference exists. Everyone with access to our editorial console can read these records; a member cannot read them, not even their own. When an application is linked, its history in our console records which account linked it, and when. A linked application can be read from the account, like one the account sent itself.

About the editor-in-chief’s details. The application form requires the editor-in-chief’s name and affiliation, and offers a field for their ORCID ID. That is personal data about someone who is not filling the form. We use it only to check that the journal has an identifiable, reachable editor — one of the mandatory minimums in the evaluation criteria — and we do not publish it, sell it or use it to contact them for anything else. Since 4 October 2026 the result of that check, and what we wrote about how we made it, are recorded as item 7 of the application’s pre-check report (below), which the applicant reads and which cannot be changed once it has been released. Two things follow, and we would rather state them than leave them implied:

• If you submit an application, you are telling us you may share your editor-in-chief’s details with us. If you cannot, apply from an account registered at the journal’s official editorial address — the contact address of an application is now the address of the account it comes from — and write to us instead.
• An editor-in-chief named in an application has the same rights over that record as anyone else on this page — including asking us what we hold and asking us to correct or erase it. Write to info@citelink.org. One limit is not settled: a released pre-check report cannot be changed or deleted by any path the site uses, and while one exists its application cannot be deleted either (section 7). Whether a request to correct or erase reaches a released report is one of the open questions below.

What we write about an application: the pre-check report. In the technical pre-check we record, for each of the twelve items published in the evaluation criteria, a result — met, not met, or not checked — what we checked and where, and when. When the application leaves the pre-check, for expert evaluation or for a revision, those results are frozen into a numbered version of the report, with the date it was released, which of us released it, and a fingerprint of its text (a SHA-256) by which the applicant can check that the report they read is the one we released. A re-check after a revision freezes a new version and keeps the earlier ones. Beside each version we keep our internal notes on its items, as they stood at that moment: they are never part of the report, never shown to the applicant, and not covered by its fingerprint.

Who can read it. The latest version is read on the tracker in the Publisher Panel, with the application’s reference and its contact address together — signed in, the panel fills both in for you. Anybody else who holds both can read it too, which is why what we write there is meant to hold only what we checked on the journal’s own site and in public sources: a rule for whoever writes it, which the database cannot check. Everyone with access to our editorial console — owners, administrators and read-only viewers — reads every version, with its internal notes, there. The e-mail about the move out of the pre-check says where the report is, and how many of its items were met or need attention.

What we write about an application: the evaluation. In expert evaluation we score each criterion of the evaluation criteria with the evidence for the score, or mark it as not assessed, and write improvement items, a recommendation and our reasons for it. Some scores are proposed by our server from public sources (section 6); a person takes or changes each one. Beside each score we may keep an internal note, which is never shown to the applicant or to the board. The evaluation then goes to our advisory board: each member reads a dossier holding the journal’s title, ISSNs, publisher and website, the scores with their evidence, the improvement items, the recommendation and its reasons, and what the automatic checks flagged — never the application’s contact address or the editor-in-chief’s details. Before the members read it, our server writes a system review of the same dossier: a recommendation by fixed rules and, where it is switched on, a review written by an AI model (section 6); the board reads it as advice, and the applicant never sees it. Each member then fills in an evaluation form — accept, revision or reject, optional notes per group of criteria, a comment to the journal (needed for revision or reject) and a comment to the board — or declares a conflict of interest with its reason and steps aside. We keep each form and declaration with the member’s name as the board shows it; while a submission is open a member sees only the count of the others’ forms, and once it is closed the members see each other’s forms. The applicant reads the board’s comments to the journal, without names and in no particular order, and the count of forms; never a member’s name, comment to the board or declaration.

Members of the advisory board. For each member we keep the name the board shows, and — as the member or an owner writes them — a title, affiliation, country, expertise, ORCID ID, a short bio, the member’s role on the board and their term, with what they took part in. Owners and administrators of our console read it. A member is named on our public pages only if the member gives that consent themselves, in the board’s page, and can withdraw it there; no page names any member yet.

The evaluation report. When the decision is issued — an acceptance, a rejection, or a request for revision, by the board or directly by our editorial office with its reasons — the report — every criterion with its score and evidence, the totals over what could be assessed, the improvement items, our reasons, the count of the board’s forms, the board’s comments to the journal, and any note we write with the decision — is frozen with a fingerprint of its text, as the pre-check report is, and cannot be changed afterwards. It is read on the tracker in the Publisher Panel with the application’s reference and contact address together, and in our editorial console by everyone with access to it.

Two questions are open: whether a request to see the personal data we hold about you (KVKK Art. 11, GDPR Art. 15) reaches those internal notes; and how a request to correct or erase personal data (KVKK Art. 11, GDPR Arts. 16 and 17) is to be met when that data is in a report that cannot be changed once released — the editor-in-chief’s details above, or anything else we wrote there. Both are questions for a lawyer, not yet answered, and we will not write an answer here until one has given it. How long a report is kept is in section 7.

Applying, being evaluated, being listed and displaying the seal are free and always will be. We take no payment from a journal, or from its publisher, in connection with that journal: the one thing a journal can ever buy is a physical object ordered after its decision is already final, and a publisher buying a reader-side licence gets nothing in it about its own titles. The pricing page prints that boundary in full.

4 · What we do not do

Not aspirations — open the developer tools on any page and check:

• No third-party scripts unless you accept analytics. Until you press “Accept analytics” in the banner, no page loads JavaScript from another domain. If you accept, one does: Google Analytics, from www.googletagmanager.com (Analytics, below). If you decline, or never answer, nothing is loaded from another domain.
• No analytics without your consent. Since 9 October 2026 we use Google Analytics 4, and it is off until you accept it. Nothing else: no Matomo, no Plausible, no second analytics product, no advertising tag. Our own server counts exactly one thing, described directly below rather than left for you to find.
• No cookies unless you accept analytics. CiteLink itself sets none. If you accept, Google Analytics sets two (Analytics, below, and section 5).
• No advertising and no profiling by us. Google Analytics runs with Google Signals and ad personalisation switched off, and nothing it reports to us is used to advertise to anyone.
• We never sell or rent personal data, and never share it for anyone else’s marketing.

The one thing our own server counts. An article page now shows more than our own record holds — the full list of authors with their ORCID IDs where they have one, keywords, and the volume, issue and pages the article appeared on. The page asks our server for that, and our server answers from a cache it fills from Crossref and OpenAlex (section 6). When that answer arrives the page sends a second request, to a different address, whose only effect is to add one to a count of how many times that article page has been opened. Two requests, not one — the detail is fetched every time you open the page, the count is raised once a session — and the number itself is printed on the article page it counts, under the authors, as “N page opens”. The one thing that counter keeps is the one thing you can see.

That count is one whole number per article, and what little sits beside it is not about you. No IP address, no cookie, no browser or device details, no referrer, no identifier for you, and no row per visit — not stored and then ignored, but never created. The service that keeps the count reads no request header at all, so nothing about you reaches the code that holds the number: your address is not discarded there, it is never present. One thing does sit beside the number, and we would rather name it than have you find it — the moment that article was last opened by anybody, overwritten by the next open. It is one timestamp per article, not one per visit, and it says nothing about who was there — but it is a date, so it is written here and in section 7 instead of being left out of a sentence that would have read better without it. There is nothing in the counter that identifies a person, so there is nothing in it to link back to one, by us or by anybody who obtained it. It counts openings rather than people: the same reader returning tomorrow is counted again, and an automated crawler is counted exactly like a reader. Your browser sends the counting request once per article per browsing session rather than on every view, and the flag that remembers it did so lives in your browser and is thrown away when you close the tab (section 5).

One thing this does not undo, and we would rather write it than let you find it: both are ordinary requests to this site, so each reaches the server access log described in section 3, with the IP address that made it, kept 30 days like every other line in that log. The counter itself holds none of that, and the two are not joined — the log knows nothing about which article a count belongs to beyond the address that was asked for, and the counter knows nothing about who asked.

Analytics: Google Analytics 4, only if you accept it

Since 9 October 2026 this site can measure how it is used with Google Analytics 4. It runs only after you press “Accept analytics” in the banner at the bottom of the page. Until then — and if you press “Decline”, or never answer — no script is loaded from Google, no request goes to Google, and no cookie is set. Entering or reading the site is not consent; only the button is. It never runs on the two account pages, signing in and choosing a new password, whatever you chose, because their addresses can carry one-time sign-in codes and Google Analytics would send the address to Google.

• What it collects, if you accept. The pages you view and the page you arrived from; the events Google’s “enhanced measurement” records by default — scrolling to the end of a page, following a link that leaves this site, downloading a file, a search made on this site (including the words searched for), and starting or sending a form (not what you typed into it); your device type, operating system, browser, screen size and language; and an approximate location — country and city — which Google derives from your IP address. Google states that Google Analytics 4 does not log or store IP addresses. To recognise the same browser on a later visit it uses a random identifier kept in a cookie; it is not your name, your e-mail address or your CiteLink account, and we send Google none of those.
• The cookies. Two, set for .citelink.org: _ga, which holds that random identifier, and _ga_EN3FXV35FB, which keeps track of the current visit. Each lasts up to two years and is renewed on every visit. CiteLink itself sets no cookie.
• How long it is kept. Our Analytics property keeps event-level and user-level data for two months, Google’s default, which we have not changed; after that Google deletes it. Google’s aggregated reports — totals such as page views per day — are not deleted with it.
• Who processes it. Google, on our behalf. Google’s terms name Google Ireland Limited as the Google company for the European Economic Area and Switzerland, and Google LLC, in the United States, elsewhere. Data is transferred to Google LLC in the United States under Google’s data processing terms and the EU–US Data Privacy Framework, under which Google LLC is certified. What Article 9 of the KVKK asks of this transfer out of Türkiye is not yet settled, like the hosting question in section 6.
• What is switched off. Google Signals and ad personalisation are turned off in the tag itself, the advertising consent signals are sent as “denied”, and the property’s data-sharing settings were left off when it was created. No Google advertising product runs on this site.
• Our basis is your consent, and nothing else.
• Changing your mind. “Cookie settings”, at the foot of every page, opens the banner again. Pressing “Decline” there stops Google Analytics on that page at once, deletes the _ga and _ga_EN3FXV35FB cookies from your browser, and nothing is loaded from Google on any later page. It does not recall what was already sent before you withdrew: Google deletes that at the end of the two months above. Your answer is kept in your browser under cl-consent (section 5) for 12 months, after which the banner asks again; clearing your site data clears it too, and the banner returns.

5 · Storage in your browser

CiteLink itself sets no cookies; if you accept analytics, Google Analytics sets two, described in section 4. It uses eight first-party localStorage keys and one IndexedDB database, all functional. This list was wrong until 22 Aug 2026: it named three keys, described one of them incorrectly, and omitted the one key that holds personal data. It is published here precisely so it can be checked — open your developer tools and compare.

Clearing your browser site data removes all of it.

Two more, not in the table because neither outlives your visit. Since 19 September 2026 an article page writes a single flag to sessionStorage — a store your browser empties when you close the tab. Its name is cl-open- followed by the article’s own identifier, so one article you opened leaves cl-open-W3025807171 and nothing else, and its value is 1. It records that this opening has already been counted, so the same session does not count the same article twice — that is what keeps the number in section 4 a count of openings rather than of scrolling back. It does not hold back the bibliographic detail: that is fetched from our server every time you open the page, flag or no flag. It holds a marker and no personal data, it is never sent to us, and nothing reads it except the page itself.

And since 4 October 2026 the contact form keeps what you have typed into it — your name, organization and message, not the topic — under cl-contact-draft in the same store, so that it survives a trip to sign in and back. It is removed once the message has been sent, and otherwise goes when you close the tab; the draft itself is never sent to us.

6 · Who else touches it

Our database, authentication and API run on our own dedicated server in Berlin, Germany, hosted by IONOS: the database and API since 18 September 2026, sign-in since 3 October 2026. That is the physical location of every record our database holds, including applications, accounts and contact messages, and of the nightly backups of it (section 7). E-mail is the exception: it leaves this server, and where it goes is set out at the end of this section. Before then the database, sign-in and API ran on Supabase, in its ap-northeast-2 region — Amazon Web Services, Seoul, South Korea — and Supabase still holds the copy from before the move. Nothing on this site reads or writes that copy any more; it stays there, unused, until we delete it.

Whether keeping the database on that server in Berlin is a transfer outside Türkiye under KVKK Art. 9 — and, if it is, to whom — is not yet settled. It is a question for a lawyer, together with whether IONOS is our processor (“What each publishes”, below). What Article 9 would ask of us if it is a transfer is set out below, and the GDPR position separately:

• GDPR — not yet settled. The database now sits in the EU, in Germany. We, the controller, are in Türkiye (§1). Whether reaching the database from Türkiye needs a safeguard of its own under Chapter V is a question for a lawyer, and we will not write an answer here until one has given it. Before the move the database was in the Republic of Korea, which holds an adequacy decision from the European Commission. Our e-mail raises a second question, and it is open too: it passes through mail servers registered to IONOS Inc. in the United States (the end of this section). Neither IONOS Inc. nor any other IONOS company is on the U.S. Data Privacy Framework List — the list of American organisations to which the European Commission’s 2023 adequacy decision for the United States applies — as an active or an inactive participant, when we searched it on 3 October 2026. Whether sending and receiving our mail that way is a transfer under Chapter V, and what it would require of us if it is, is for the same lawyer.
• KVKK — and this one is not settled. Article 9 was replaced in full by Law No. 7499 (Official Gazette 12 March 2024, No. 32487), in force since 1 June 2024. It offers an adequacy decision, four appropriate safeguards, or a set of exceptional grounds. As things stand:
  • Adequacy — none exists. Not for Germany or any other EU state, not for anywhere: the Authority states that no determination has yet been made for any country, sector or international organisation.
  • Binding corporate rules — not open to us. They require a group of undertakings in common economic activity. We are one operator.
  • Explicit consent — not open to us either, and we will not ask for it. The exceptional grounds in Art. 9(6) apply only to transfers that are incidental — one-off, not continuous, outside the ordinary course of business. Hosting this database is all three of the opposite things.
  • If IONOS is our processor, the standard contract is the route — and it is not signed. Whether it is one is itself not yet settled (see below); if it is, the controller-to-processor module published by the Board on 10 July 2024 is the instrument that fits, and filing it with the Authority within five business days is what makes it effective. It needs two signatures, ours and our hosting provider’s, and has neither. Ours waits on the registry details in §1. What we have with IONOS today are the standard online terms that came with our orders; they are not the Turkish text, and which IONOS company they are with is not yet settled either (below).

So: no Article 9 safeguard is in place, and we would rather write that down than imply otherwise. Two things follow. The database has moved to a dedicated server in Berlin, Germany. That is still outside Türkiye, so the move did not settle the Article 9 question: whether keeping the database there is a transfer, and to whom, is not yet settled (above), and if it is one and IONOS is our processor, the standard contract is the route, now with the new hosting provider, and it is not yet signed. And no journal has been evaluated and no application accepted to date, so the personal data in the database today is chiefly the author records described in §2, not a body of applicant records. Our e-mail is a separate question: it passes through IONOS mail servers registered in the United States (the end of this section); whether that is an Article 9 transfer is not yet settled either, and if it is, nothing signed covers it.

When the copy at Supabase is deleted, this section changes with it, and the change is dated in the history at the foot of this page.

Two sources our server reads from, and your browser does not. An article page shows more than our own record holds — the full author list with ORCID IDs, keywords, volume, issue and pages. That detail comes from Crossref, looked up by the article’s DOI, and from OpenAlex, looked up by its work identifier. We fetch it; you do not. Our own server asks, from its own network address, stores the answer and serves it to the page. Your browser never connects to either organisation, no request of yours is passed on to them, and nothing about you — your address, your browser, the fact that a person is reading at all — travels with ours. What travels is an article identifier that is already public.

Two honest qualifications, because “we fetch it” is doing real work in that sentence. The first time an article is asked for, our request does follow somebody opening that page, so what the other end could observe is that our server asked about one article at one moment — not who asked, not from where, and not that a reader rather than a crawler was behind it. After that the answer is served from our own cache and no request goes out at all, until the stored copy is more than 90 days old (section 7) and the next person to open that page sets off one more fetch. And what comes back is personal data: authors’ names, and their ORCID IDs where they have one. It joins the published scholarly record described in section 2, on the same footing and the same lawful basis, because it is the same kind of already-published fact.

When we evaluate a journal, our server also reads about it. For an application under evaluation our server looks the journal up by its ISSN at Crossref, at the Directory of Open Access Journals and at OpenAlex, and opens the journal’s website and the policy pages named in the application, to measure what those sources and pages show. What it sends is the ISSN and the journal’s own addresses, from its own network address; it reads nothing of the application’s contact address or the editor-in-chief’s details, and sends nothing about anyone. What it finds is a proposal: a person on our side decides every score.

An AI review of the board’s dossier, when it is asked for. The AI review is optional: it is asked for, submission by submission, by one of our administrators — for complex cases — and only where we have installed a key for it. Then our server sends the advisory board’s dossier (section 3) to Anthropic, in the United States, whose Claude model writes a review the board reads as advice. The dossier holds the journal’s title, ISSNs, publisher and website, the scores with their evidence, the improvement items and our reasons — no contact address and no editor-in-chief’s details, though evidence written by our evaluators can name what is on a journal’s own pages. Unlike the sources above, Anthropic processes what we send on our behalf, under its commercial terms; whether that makes it our processor, and what the transfer to the United States requires under KVKK and the GDPR, are open questions for our lawyer, like the others in this section. No decision is made by the model: the board decides, and an administrator issues the decision.

Crossref, the Directory of Open Access Journals and OpenAlex are not our processors. They hold nothing on our behalf and follow no instruction of ours; we are a reader of their public interfaces, and we name them here because this is where you come to find out who else is involved. Because we send them nothing about you, no transfer of your data to either arises — the transfer question in this section is about where our database and our e-mail sit, and that is answered in the rest of this section.

Who holds or carries personal data for us, then: IONOS — the server in Berlin, the mail servers the e-mail below goes through, and our mailboxes — and Supabase, in Seoul, our processor for as long as it holds the copy from before the move.

Which IONOS — not yet settled. IONOS is a group whose companies contract separately: among them IONOS SE, of Montabaur, Germany, under German law, with the customers of ionos.de, and IONOS Inc., a Delaware company based in Pennsylvania, United States, under Pennsylvania law, with the customers of ionos.com. We have not yet confirmed from the contract itself which one ours is with. What we can check from outside points to IONOS Inc.: the server was ordered from our US account in IONOS’s control panel and priced in US dollars; our domain’s mail records name IONOS’s ionos.com mail servers and its US sender list (_spf-us.ionos.com); those mail servers, and an unused network address in the same account, are registered to IONOS Inc.; and the server we send mail through presents a certificate issued to IONOS Inc. What points the other way is the network: the Berlin server’s own address is in a German network range that the RIPE registry lists as held by Strato GmbH and describes as IONOS SE — which says who runs the network there, not who signed with us. Until the contract itself settles it, this paragraph says so rather than choosing the likelier answer; when it does, the change is dated at the foot of this page.

What each publishes. IONOS SE’s terms on ionos.de attach a data processing agreement under Article 28 GDPR. They say it applies, in so far as IONOS SE acts as the customer’s processor, as part of the terms for the products the customer has booked, even where an order does not mention it; the agreement also says it begins when the customer concludes it. We have no record of a separate step concluding it. Whether it binds us is not yet settled, and it matters only if our contract is with IONOS SE. IONOS Inc. publishes no data processing agreement in its terms on ionos.com, which are governed by Pennsylvania law and say that the personal information a customer gives it is transferred to and kept in the United States and other countries. Its terms for servers say it has no administrative access to a dedicated server, and also that to resolve a technical incident it may access the physical server remotely, and so may have access to what is on it. Whether a host placed like that is our processor in the legal sense — the word the KVKK and GDPR points above turn on — is a question for a lawyer, not yet answered, and this page does not assume the answer either way.

Since 9 October 2026 there is one more, and only for visitors who accept it: Google, for Google Analytics (section 4), which receives nothing from a visitor who declines or does not answer. Beyond that there is nobody else: no mailing platform, no CRM, no other analytics vendor, no ad network. The names above do not change that sentence, and it remains the one to hold us to. Nor does the e-mail. Everything this site sends goes out from our own sending mailbox at IONOS, through IONOS’s mail server, each kind written from a fixed template in the site’s own look — except that if our sign-in service cannot fetch one of its templates from this site the first time it needs it after starting, it sends that kind of mail in its own plain wording until a later attempt succeeds. Nothing in any of it is fetched from anywhere when it is opened — the one image some of it carries, our mark, travels inside the message — so we cannot tell whether, when or where a mail was read. Since 9 October 2026 it is of six kinds:

• Application notices. When an owner or administrator moves an application into the technical pre-check, into expert evaluation, or back for revision — and only then — a notice is queued for the application’s contact address, and our server sends it. That address only: never the editor-in-chief’s, and none at all if the address is not a well-formed one. For an application sent from an account the contact address is the address of that account (section 3); for one sent before the forms needed an account, it is the address typed into the form. The notice carries the journal’s title as it was entered, the application’s reference, the contact address itself and any message we write to you; a notice about a move out of the pre-check also says that the pre-check report is on the tracker, and how many of its items were met or need attention. No notice is about acceptance or rejection: the notices cover the three stages above and nothing else (a decision has its own mail, the fifth kind below; a code to link an application to an account, the sixth, goes to the contact address only when a member asks for one). Submitting an application is not one of them — what that sends is the receipt described next. The subject and text of each notice sent are kept in our database with the application it belongs to (section 7).
• Receipts, and notices to us. When a member sends one of our three forms — an indexing application, a message through the contact form, or a correction request — our database queues two mails in the same step that saves it: a receipt to the member’s account address, and a notice to our own mailbox, info@citelink.org, so that a person reads what arrived. The receipt says what arrived and what happens next: for an application, its journal’s title and its reference; for a message, its topic and its opening words, at most 200 characters; for a correction request, its type and the journal. The notice to us carries the account’s address and what was sent: for an application, its reference and journal title, with a link into our console; for a message, the name, organization and topic given and the whole text; for a correction request, its type, the journal, its catalogue identifier, the evidence link and the whole text. One account is sent at most ten receipts an hour: past that, what it sends is still saved, but no receipt goes, one notice tells us the limit was reached, and nothing more is mailed about that account’s submissions until fewer than ten receipts have gone to it in the past hour. The subject and text of each receipt and notice sent are kept in our database with what it is about (section 7).
• Account messages from our own sign-in service, about an account and sent to its address. An activation link when an account is created: our welcome mail. Registering asks for no password: the activation link opens the page where you choose one. A new account cannot sign in until its address has been confirmed by a link we mailed to it, and the activation link can be sent again from the sign-up page. A link to choose a new password, when one is asked for on the sign-in page or in our editorial console. A link to confirm a change of the account’s e-mail address, sent to both the old and the new address: no page offers that change, but the service makes it for a signed-in account that asks it directly. Each of these links works once, within 24 hours. And four security notices, which carry no one-time link — only a link to the page where a password reset is asked for, and our own address: that the account’s password was changed — choosing the first one after activating counts, so a new member receives this notice too; that its e-mail address was changed, sent to the old address; and that a sign-in verification method was added to it or removed from it. The last two are switched on but should not go today: no account has a verification method, and adding one is switched off. A notice the service cannot send at the moment of the change is not sent later. Sign-in links, one-time sign-in codes and the re-authentication code the service could otherwise mail are switched off, and our web server refuses the requests that would ask for them.
• Invitations to our editorial console. When an owner of CiteLink invites someone to the console, the owner may have the invitation mailed to the invited address. It names the role offered, carries the invitation’s one-time link, and does not say who sent it. At most one an hour goes to an address, and an invitation withdrawn or reissued before the mail goes out is not mailed. Its subject and text are kept in our database (section 7).
• The evaluation’s mails. When an evaluation is submitted to our advisory board, each active member is mailed at their account address with the application’s reference, the journal’s title and the evaluator’s recommendation, and sent to the board’s page to read the dossier; the dossier itself is never mailed. When a decision is issued after the board has voted, the application’s contact address — and no other — is mailed the outcome, where the full evaluation report is, any note we write with it, and how to appeal. No decision can be issued, and so none of these goes, until the criterion thresholds have been published. The subject and text of each are kept in our database (section 7).
• Codes to link an application. When a signed-in member whose address a link we mailed has proven asks, in the Publisher Panel, to link an application that belongs to no account, a code is mailed to that application’s contact address — the address given in the application, and no other. The mail carries the code, the application’s reference and journal title, and nothing about who asked; the code works for 30 minutes, for five tries, and only from the account that asked. At most three such mails go to one application in an hour, and six in a day. Until the mail goes, the code waits with it in our outbox; once it has gone, or could not be sent, the code is removed, and the copy of the mail we keep shows it blanked. What we keep to check a code against is its SHA-256 fingerprint. The subject and text are kept in our database (section 7).

What comes back: a reply to any of them, and anything written to an address of ours — info@citelink.org, or apps@citelink.org and api@citelink.org, which our contact page also gives — is received by IONOS’s mail servers into our mailboxes there, and read from them.

Where the mail is. The servers our mail is sent through (smtp.ionos.com) and received by (mx00.ionos.com and mx01.ionos.com) have network addresses registered to IONOS Inc., in Philadelphia, United States, and the sending server presents a certificate issued to IONOS Inc., Pennsylvania. Measured from our server in Berlin on 3 October 2026, they answer in 121 to 131 milliseconds, where IONOS’s German mail servers answer in 12. From that difference we infer — it is an inference from a measurement, not something IONOS has told us — that the servers our mail passes through are not in Germany; the measurement does not say where they are. So every mail described above passes through them — a notice with a contact address and a journal’s title in it, a receipt, a notice to us with a member’s address and what they wrote — and a message to us is received by them. Where IONOS then keeps the contents of our mailbox is not documented anywhere we have found and cannot be measured from outside, and we do not guess it here.

7 · How long we keep it

• Applications and evaluation records — while the journal is listed, and for five years afterwards, so a decision can still be explained or appealed. Five years matches the period over which an evaluation could plausibly be contested; after it, the record is deleted rather than archived. Nothing carries that deletion out yet: no scheduled job deletes an application, and one whose pre-check report has been released cannot be deleted by any path the site uses (next item). The purge that will end the five years has still to be written; until it is, applications are kept.
• Pre-check reports (section 3) — every released version, with the internal notes kept beside it, for as long as its application is kept. A released version is frozen: no page, no console action and no database function the site uses can change or delete it, and while one exists its application cannot be deleted either. Removing them when the five years above are over will take a deliberate step by the database’s owner, setting that protection aside, and that step has not been written. The working results an application collects during the pre-check, before a version is frozen, are deleted with the application.
• Evaluations and evaluation reports (section 3) — the scores, notes, improvement items, board dossiers and votes, and every released report, for as long as the application is kept. A released report is frozen like a pre-check report, and while an evaluation exists its application cannot be deleted; the same deliberate step will be needed at the end of the five years. A board member’s name as the board shows it is kept while they sit on the board and with each vote they cast.
• Copies of the application notices we send (section 6) — the address, subject and text of each, and any delivery error, kept with the application they belong to and for as long as it is kept (above). When the application is deleted they are deleted with it: the database does that itself, not a person remembering to. An application whose pre-check report has been released cannot be deleted, so for now neither can they.
• Copies of receipts, and of our notices about what members send (section 6) — the address, subject and text of each, and any delivery error, kept with the application, message or request it is about, for as long as that is kept, and deleted with it by the database itself.
• Copies of invitations to our editorial console — the invited address, the role, the link and the text. They belong to no other record, so nothing deletes them along with anything else, and no period has been set for them yet.
• Codes asked for to link an application, and copies of the mails that carried them (section 3, section 6) — the record of each request is deleted with the account that asked, or with the application it names; the copy of the mail — the address, subject and text, with the code blanked out — is kept with the application, for as long as it is kept, and deleted with it by the database itself. No shorter period has been set.
• Contact messages and correction requests — until the matter closes, then one year, so a follow-up can be read against what was said the first time. After that year the message is deleted. Here too nothing carries that deletion out yet: no scheduled job deletes them.
• Our mailboxes at IONOS — what is written to info@citelink.org, apps@citelink.org or api@citelink.org, and replies to what we send. No period has been set for deleting that mail yet; when one is, it is written here. Copies of what we send to you are not filed in them. Our notices about what members send are a different matter: they are addressed to info@citelink.org, so each arrives there, with the member’s address and what they sent, and stays as long as that mailbox keeps it.
• Accounts — until the account is deleted; no page offers that yet, so ask us at info@citelink.org. An account whose activation link is never opened stays unconfirmed — it cannot sign in or use a form — and nothing deletes it yet: no period has been set for it. Deleting an account does not delete what was sent from it: applications, messages, requests and the copies of mail about them keep the periods given for them here, without the link to the account.
• Our sign-in service’s own log — besides the account itself, the service keeps a record of account events, such as sign-ins, password-reset requests and password changes, each with its time, since it was installed on 3 October 2026 (an inference from the install date: we have not counted the log itself). No period has been set for deleting it yet. The service’s published source code says each entry also holds the account’s identifier and e-mail address and the network address the request came from; we have not yet read the log on our server to confirm it. The service also writes each request it answers, with the network address it came from, and each account event, with the account’s e-mail address and the browser’s identification string, to the server’s system log. No period has been chosen for that log either. On disk, the operating system’s default rotation deletes it after about five weeks; a second copy, in the server’s memory, is kept until the server restarts or that copy reaches its size limit.
• Scholarly records — while they remain part of the published record, refreshed from the source.
• Server access logs — 30 days, then deleted. The server’s error log is kept the same 30 days. Besides errors, it holds the IP address of each request refused by one of our rate limits — on the application tracker, and on registering, sending the activation link again and asking for a password reset. To count against those limits the server holds each client’s address in its memory, and nowhere else, while it counts.
• Cached bibliographic detail from Crossref and OpenAlex — kept alongside the scholarly records above and fetched again from the source once the stored copy is more than 90 days old, which is the figure the service runs with today. Whether 90 is the right number is still open, and it is open in writing rather than in somebody’s head: the reasoning, and the measurement that would settle it, are recorded in our decision ledger as item 61a. Nothing in this cache is about a reader.
• The per-article open count — one whole number per article, and the time that article was last opened by anybody, for as long as the article is listed. Neither is a record of a visit: the number is raised, the timestamp is overwritten, and nothing accumulates. There are no per-visit rows to expire, which is why no period is given; section 4 says what is in it and what is not.
• Google Analytics data, only if you accepted it (section 4) — held by Google, not by us: event-level and user-level data for two months, then deleted by Google; its two cookies in your browser for up to two years from your last visit, or until you decline in “Cookie settings”, which deletes them. Your answer to the banner is kept in your browser for 12 months.
• Backups — every night our server copies its database, with everything above that lives in it (applications, the copies of notices, accounts and the sign-in service’s log among it), to a second disk in the same machine in Berlin. It keeps the newest seven nightly copies and one from each of the last five weeks, and deletes the rest, so a record deleted from the database is gone from the backups within about five weeks — as long as the nightly backups keep finishing: the five weeks are the last five that hold a finished backup, and a night that fails deletes nothing. A copy left unfinished by an interrupted run is kept until we remove it by hand. The backups are not copied off that machine.

8 · Your rights

Under KVKK Art. 11 and GDPR Chapter III you may ask whether we hold data about you, ask for a copy, have it corrected or erased, object to or restrict processing, and — where processing rests on consent or a contract — receive it in portable form.

Write to info@citelink.org. We reply within 30 days. You may also complain to the Turkish Personal Data Protection Authority, or in the EU/EEA to your local supervisory authority.

One question about what such a request reaches is open: whether it extends to our internal notes on a pre-check (section 3).

9 · Correcting an author record

Author records are built by automated disambiguation and are wrong more often than anyone would like: work attributed to the wrong person, one researcher split across two profiles, an affiliation years out of date. It is the error we are most exposed to, and we would rather hear about it.

Use the contact form and choose Data correction — the form needs a free account whose address a link we mailed to it has proven (the activation link, or a password-reset link) — or write to info@citelink.org, which needs none. Where the record originates in OpenAlex we pass the correction upstream as well, because fixing it there fixes it for everyone.

10 · Changes

If this policy changes materially we will say so here with the date. We will not apply a narrower policy retroactively to data already collected.

Last updated: 9 October 2026 · draft, not yet in force.

History — 22 August 2026: §1 names CiteLink as the data controller, with Zeus Publishing as its business name; §3 lists the editor-in-chief’s details; §5 storage list corrected; §6 hosting location (Seoul) and KVKK position written out; §7 retention periods fixed. 5 September 2026: §3 payment sentence bounded — no payment is taken from a journal, or from its publisher, in connection with that journal. 16 September 2026: §6 corrected — the database is due to move to Berlin, Germany, not to Türkiye; the Article 9 gap stays open. 17 September 2026: §3 and §7 add server access logs — IP address and request details, kept 30 days, then deleted. 19 September 2026: §4 keeps “no analytics” and says what else is now true — each article page open is counted, one whole number per article with no IP address, cookie, user agent or per-visit record attached, raised by a second request of its own and printed on the page it counts; §5 names the session-storage flag that keeps the counting to once an article a session; §6 adds Crossref and OpenAlex as two sources our server reads from, never the reader’s browser; §7 adds the cached bibliographic detail, kept 90 days, and the counter with the one timestamp that sits beside it. 3 October 2026: §6 corrected — the database and API run on our own server in Berlin, Germany, hosted by IONOS, since 18 September 2026, and sign-in since 3 October 2026; Supabase in Seoul keeps the copy from before the move, unused, until it is deleted; an application’s contact address is e-mailed, through IONOS’s mail server, when the application moves to a new review stage; the GDPR position is no longer the Korean adequacy decision but an open question about access from Türkiye, and is written as open; IONOS and Supabase are listed as our two processors. Later on 3 October 2026: the notice at the top names the controller as §1 does — CiteLink, with Zeus Publishing as its business name — and also says where the database, its backups and our e-mail are, and what is still open about IONOS; §6 no longer calls IONOS our processor, and says instead that whether it is one is an open question, that which IONOS company our contract is with is not yet settled, what points each way, and what each company publishes; the KVKK standard-contract point no longer describes Supabase’s contract; §6 names the kinds of e-mail the site sends — application notices, and only on a move into the three stages it names, and account messages from our sign-in service — and says the mail servers are registered to IONOS Inc. in the United States, that they are not in Germany (an inference from measured response times, and labelled as one), and that where our mailbox is kept is not known; the GDPR point and the KVKK conclusion add the e-mail as an open question, and the GDPR point that no IONOS company is on the Data Privacy Framework List; §7 adds the copies of sent notices, our mailboxes, the sign-in service’s log and the backups. 4 October 2026: §6 no longer says that keeping the database on our server in Berlin is a transfer under KVKK Article 9 — whether it is, and to whom, is written as not yet settled, like the e-mail — and gives the standard contract as the route only if IONOS is our processor; it gives IONOS SE’s processing agreement’s own terms for when it applies, and leaves open whether it binds us; it describes the Berlin server’s network range as the RIPE registry lists it; it names the account mails it had left out — the change-of-address link also sent to the old address, and a one-time code any signed-in account can ask for — and says that asking for a sign-in link for an address with no account creates the account and mails it; it names apps@ and api@citelink.org beside info@, in §7 too; and it no longer names a server our mail is read from, because how we read it is not on record. §7 labels the start of the sign-in service’s log as an inference, says what an entry holds according to the service’s source code, and adds the server’s system log, to which that service also writes; and the five weeks of backups now say they hold only while the nightly backups keep finishing. Later on 4 October 2026: the three forms — an indexing application, a contact message, a correction request — take submissions only from a signed-in account whose e-mail address a link we mailed to it has proven (the activation link, or a password-reset link); §3 says so, says that registering asks for no password and that the person who opens the activation link chooses it, which leaves an earlier registration of the same address with nothing to sign in with, what opening that link shows and what guessing it would take, that accounts made before the activation mail can use the forms after a password reset, what our record of a proven address holds, who can read it, what removes it and how long it is kept, that the address on what you send is then your account’s, that everyone with access to our editorial console — read-only viewers too — can read what members send, and how an application sent before the forms needed an account can be linked to an account; it adds the copies of the mail we send, and describes the pre-check report — what it records, who can read it, the internal notes kept beside it, and the open questions whether a request to see, correct or erase your data reaches them; §5 adds the return-page key the sign-up page keeps and the contact form’s draft kept for the tab, says what the sign-in key holds, and that signing out clears the saved lists; §6 names four kinds of e-mail where it named two — receipts to members with notices to us, and invitations to our console, are new — and says that registering sends an activation link, that you choose your password on the page it opens, and that choosing it sends the password notice; that four security notices are switched on, that sign-in links and one-time codes are switched off, when a mail can go out in our sign-in service’s own wording instead of ours, and that nothing in our e-mail is fetched when it is opened; §7 says that no scheduled job yet deletes applications, contact messages or correction requests, that a released pre-check report cannot be changed or deleted and keeps its application with it, how long the new copies are kept, what happens to an account never activated and to what an account sent when it is deleted, and that the error log keeps the address of a request one of our rate limits refused; §1 and §9 say the contact form needs an account and info@citelink.org does not; §8 points to the open question; and §3 gives the basis of the record of a proven address as not yet settled. 8 October 2026: §3 describes the evaluation — the scores with their evidence, the internal notes kept beside them, the advisory board’s dossier, what it holds and leaves out, the members’ votes and who sees them — and the evaluation report frozen when the decision is issued and read on the tracker; §6 adds that, for an application under evaluation, our server looks the journal up by ISSN at Crossref, the Directory of Open Access Journals and OpenAlex and opens the pages named in the application, sending nothing about anyone, and names a fifth kind of e-mail — to board members when an evaluation is submitted, and to the applicant when a decision is issued; §7 adds evaluations and evaluation reports. Later the same day: §3 says that the board reads a system review before its forms — by fixed rules, and by an AI model where switched on — that each member fills in an evaluation form (accept, revision or reject) or declares a conflict of interest, that the journal reads the board’s comments to it without names, that a revision request releases a report too, and what we keep about board members, who is named publicly only with their own consent; §6 adds Anthropic, to which the board’s dossier is sent for the AI review when an administrator asks for one (it is optional), with the questions that raises left open; the system’s review is advice only and never counts towards a decision; and our editorial office can decide directly, without the board, giving its reasons in the report. 9 October 2026: §3 says that an application sent before the forms needed an account is linked to an account by a code mailed to the application’s contact address, from any account whose own address is proven, what we keep of each code asked for and who can read it; §6 names a sixth kind of e-mail, that code; §7 says how long the records of codes and the copies of their mails are kept. Later on 9 October 2026: the site can measure its use with Google Analytics 4, which runs only after a visitor presses “Accept analytics” and never on the two account pages; §4 no longer says there is no analytics, no third-party script and no cookie, says instead what is true with and without that consent, and describes what Google Analytics collects, its two cookies, how long Google keeps the data, who processes it and where, what is switched off, and how to withdraw with “Cookie settings”; §5 adds the key that remembers the answer for 12 months and says CiteLink itself still sets no cookie; §6 names Google, only for visitors who accept; §7 adds how long the analytics data, its cookies and the answer are kept.