Data protection notice

What data is processed, where it goes, and why.

This notice describes the data processing of the Psilocybin Research Publication Tracker. The app is designed as a self-contained PHP and SQLite research tool with local frontend assets, no third-party analytics scripts, no CDN JavaScript, no CDN CSS, and no tracking pixels in alert emails. Last updated: July 3, 2026.

This page is a technical and operational data protection notice for the application. It is written for transparency and legal review, but it does not replace advice from qualified counsel for a specific jurisdiction.

Controller And Contact

The publication tracker is operated for Psilocybin-Research.com by Dr. Christopher B. Germann. Data protection questions, access requests, correction requests, deletion requests, and objections can be sent through the contact details provided by the website operator. Alert emails use the configured sender address noreply@psilocybin-research.com.

If a separate legal notice or imprint is used for the wider website, that notice should be treated as the authoritative provider-identification document. This page describes the data processing of the publication tracker application itself.

Core App Use

When a visitor opens the tracker, the server receives normal HTTP request data required to deliver the page: IP address, request time, requested URL, HTTP method, response status, user agent, and referrer if the browser sends one. The application uses this data for secure delivery, abuse prevention, debugging, operational reliability, and server log analysis.

No third-party frontend analytics script is loaded by the app.
No CDN JavaScript, CSS, or web font is required for the interface.
Search and filter requests are processed on this server against the local SQLite database.
AJAX requests update result panels asynchronously; they are sent to this domain, not to external analytics providers.

Search, API, Export, And Widget Data

Search terms, filters, pagination settings, sort settings, export format choices, API parameters, and widget parameters are transmitted to this server when users submit forms, open API/export URLs, or use asynchronous result loading. These values are used to return matching publication metadata and are not sent to PubMed, Crossref, Europe PMC, OpenAlex, preprint servers, ClinicalTrials.gov, or frontend analytics services during normal visitor searches.

Public API, export, widget, and database-download endpoints expose public literature metadata only. They must not expose alert subscriptions, push subscriptions, admin tokens, encryption keys, operational secrets, or private runtime tables.

Email Alerts

Email alerts are optional. If a user creates an alert, the app stores the email address, selected substances, optional keyword, author, journal, topic, cited DOI, delivery frequency, confirmation state, active state, timestamps, and delivery records needed to prevent duplicate messages. Digests are sent only after double opt-in confirmation.

Purpose: confirm the requested alert, send matching publication digests, manage preferences, pause delivery, unsubscribe, and delete alert data.
Storage protection: email addresses, access tokens, and confirmation tokens are encrypted at rest. Blind indexes support lookup without keeping those lookup values in plaintext columns.
Email delivery: messages are sent through the server mail system using PHP mail configuration. The recipient email address necessarily leaves the app for email transport.
No email tracking pixel: alert and confirmation templates do not include tracking pixels.
Unsubscribe: each digest contains manage and unsubscribe links; one-click unsubscribe headers are included where supported by mail clients.
Deletion: the alert management page can delete the subscription and related delivery records for that alert token.

Email Alert Encryption Model

The alert system separates the values needed for delivery from the values needed for lookup. Sensitive alert fields are encrypted before storage, while blind indexes let the app find a subscription without searching plaintext email addresses or tokens.

1 User consent

Email address and selected research filters are submitted after the alert data-use notice is accepted.

2 PHP validation

The app normalizes alert frequency, substances, keywords, author, journal, topic, and cited DOI.

3 Encrypted storage

Email addresses, manage tokens, and confirmation tokens are stored as ciphertext plus blind-index lookup fields.

4 Double opt-in

No digest is sent until the confirmation link is opened. Ignored confirmation emails do not activate delivery.

5 Delivery and control

Digests use the server mail system, include no tracking pixel, and contain manage, unsubscribe, and delete options.

Plain email addresses are necessarily used at the moment of email transport. They are not exposed in public API, export, widget, health, or database-download endpoints.

Web Push And PWA Data

PWA installation is handled by the browser. If a user enables Web Push, the app stores the browser push endpoint, public key, auth secret, content encoding, optional user-agent information, timestamps, and active state needed to send notifications about newly imported publications. Push endpoints and browser push keys are encrypted at rest where present.

Web Push delivery uses the browser vendor's push service associated with the subscription endpoint.
Push payloads are encrypted for the browser subscription and signed with VAPID keys.
The service worker caches local app-shell assets and uses network-first requests for runtime data.
Users can revoke push permission in their browser or operating-system notification settings.

Publication Data Sources And Provenance

The database contains publication and registry metadata from public bibliographic and research-data services. The active source stack is PubMed, Crossref, Europe PMC, OpenAlex, medRxiv, bioRxiv, PsyArXiv, and ClinicalTrials.gov. Imported records keep source labels, source URLs, DOI, PubMed ID where available, publication status, timestamps, raw importer metadata, topics, substances, study type, journal, authors, abstracts, keywords, and links back to the original source where available.

PubMed / NCBI E-utilities: biomedical citation metadata and PubMed identifiers.
Crossref: DOI metadata, journal/publisher metadata, dates, and reference metadata where available.
Europe PMC: biomedical literature metadata, preprint coverage, publication-status signals, and PubMed/PMC-linked records.
OpenAlex: broad scholarly metadata, author display names, ORCID/OpenAlex author IDs, citation counts, topics, DOI/PMID enrichment, and dedupe support.
medRxiv and bioRxiv: date-window preprint metadata for recent/custom preprint updates.
PsyArXiv / OSF: psychology preprint metadata where available.
ClinicalTrials.gov API v2: clinical trial registry records, stored as clinical trial records rather than published papers.

Source APIs receive server-side bibliographic queries, source-specific search terms, date windows, identifiers, and configured contact metadata when required or appropriate for responsible API use. Normal visitor search terms are not forwarded to these source APIs.

Automated Updates

Production updates are performed server-side by cron. The regular job runs php bin/update.php --daily at 03:20 server time, which corresponds to 01:20 UTC during Central European Summer Time. The job imports a bounded recent date window, deduplicates by DOI, PubMed ID, and normalized title, updates existing records, classifies topics and study types, writes heartbeat files, and records public-safe update status.

Admin-only commands can run backfills, custom date windows, source-specific imports, reclassification, targeted PubMed ID imports, alert sending, push sending, and SQLite backups.
Visitor-triggered public refresh is bounded to a recent seven-day window and protected by a lock and cooldown.
Runtime logs are JSON lines with redaction for token, password, secret, and key-like fields.

Cookies And Local Browser Storage

The app does not require advertising cookies or cross-site tracking cookies. JavaScript may use local browser storage for interface preferences such as sidebar collapse state and results panel state. The service worker and Cache Storage may store static local app assets for offline fallback and faster repeat visits.

Security Measures

HTTPS protects browser traffic on the live site.
Runtime data is kept under data/ with web-deny rules for sensitive files.
Sensitive alert and push fields are encrypted at rest where present.
Admin actions are protected by server-side token checks and should use POST.
Generated public health output is designed not to expose secrets, traces, or private runtime data.

Retention

Publication metadata is retained as part of the public research index unless corrected, deduplicated, hidden as a false positive, or removed during maintenance. Alert data is retained while the alert exists and can be deleted from the secure manage link. Operational logs, heartbeat files, update logs, and backups are retained for reliability, auditing, debugging, and recovery according to server maintenance practice.

User Rights

Depending on applicable law, users may have rights to access, correction, deletion, restriction, objection, portability, and complaint to a supervisory authority. For alert subscriptions, the fastest self-service route is the secure manage link in confirmation and digest emails, which supports updating preferences, pausing, unsubscribing, and deleting alert data.

Important Limits

The tracker is a bibliographic discovery and monitoring tool. Source metadata may be incomplete or wrong, source APIs may change, and deterministic classification is a navigation aid rather than a scientific conclusion. Users should verify records at the DOI, publisher, PubMed, registry, or source database before relying on them for citation, clinical interpretation, reporting, or policy work.