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 or through the contact form.

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 30.8 million author profiles — a name, institutional affiliations, an ORCID where one exists, and a publication and citation history — alongside 104.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

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. 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, put the journal’s official editorial e-mail in the contact field 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 erase it. Write to info@citelink.org.

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. No page loads JavaScript from another domain.
• No analytics. No Google Analytics, no Matomo, no Plausible, none at all. No analytics product of any kind, no third-party tag, nothing that follows you from one page to the next and nothing that builds a picture of a visit. Since 19 September 2026 there is exactly one thing we count, and it is described directly below rather than left for you to find.
• No tracking cookies — in fact no cookies whatsoever, see section 5.
• No advertising and no profiling.
• We never sell or rent personal data, and never share it for anyone else’s marketing.

The one thing we count. 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 we keep 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.

5 · Storage in your browser

CiteLink sets no cookies. It uses six 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.

One more, and it is not in the table because it does not outlive 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.

6 · Who else touches it

Our database, authentication and API run on Supabase, acting as our processor. The project sits in Supabase's ap-northeast-2 region — Amazon Web Services, Seoul, South Korea. That is the physical location of every record described on this page, including applications and contact messages.

This is a transfer outside Türkiye, so KVKK Art. 9 and GDPR Chapter V both apply — and the two have different answers:

• GDPR. The Republic of Korea holds an adequacy decision from the European Commission, so transferring EU personal data to a Korean recipient does not require separate safeguards.
• 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 Korea, 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.
  • The standard contract is the right route, and it is not signed. 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 waits on the registry details in §1; our processor contracts on the EU standard clauses, not on the Turkish text.

So: the transfer is running without an Article 9 safeguard in place, and we would rather write that down than imply otherwise. Two things follow. The database is due to move to a dedicated server in Berlin, Germany. That is still outside Türkiye, so the move does not close the Article 9 gap described above: the standard contract remains 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.

When the database moves, 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.

Neither organisation is our processor. They hold nothing on our behalf and follow no instruction of ours; we are a reader of two 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 sits, and that is answered above.

There is no other processor: no mailing platform, no CRM, no analytics vendor, no ad network. The two names above do not change that sentence, and it remains the one to hold us to.

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.
• 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.
• Accounts — until you delete the account.
• Scholarly records — while they remain part of the published record, refreshed from the source.
• Server access logs — 30 days, then deleted.
• 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.

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.

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. 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: 19 September 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.