Data protection notice
This notice describes the data processing of the Psilocybin Research Database. 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: 17 October 2026.
The research database 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 to christopher-germann@uni-wh.de.
The website imprint/legal notice provides the authoritative provider-identification information. This page describes the data processing activities of the Psilocybin Research Database application.
When a visitor opens the database, 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. Private research-task reports aggregate successful search, API and export responses from existing host logs. They retain no IP addresses, user agents, referrers, search text, reading lists or user identifiers; repeated and automated requests may still affect counts. These measures do not identify people or prove completed downloads. Private daily aggregate snapshots are retained for up to 90 days. No third-party browser analytics are installed. The public visitor-statistics page uses only aggregated log measures; it never displays IP addresses and excludes the two most frequent human-browser addresses before calculating its figures. From September 2026, the app also stores daily aggregate PWA installation and standalone-launch counts. Those counters contain no IP address, user agent, device identifier, or event-level timestamp.
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.
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.
Alert preferences can be broad or targeted. In targeted mode, users may configure specific search terms, research topics, authors, journals, substances, and cited DOI matches. These values are part of the email alert configuration and are used only to decide which newly imported publications should be included in the requested confirmation or digest emails. Digest emails show the current research filters and delivery frequency so recipients can see why the matching-publication email was sent.
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.
Email address and selected research filters are submitted after the alert data-use notice is accepted.
The app normalizes alert frequency, substances, search terms, author, journal, topic, and cited DOI.
Email addresses, manage tokens, and confirmation tokens are stored as ciphertext plus blind-index lookup fields.
No digest is sent until the confirmation link is opened. Ignored confirmation emails do not activate delivery.
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.
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, active state, selected delivery frequency, and selected research filters needed to send notifications about newly imported publications. Push endpoints and browser push keys are encrypted at rest where present.
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. The private runtime database can retain source-derived abstracts, descriptions, keywords, and importer payloads for ingestion, relevance screening, deduplication, classification, and source tracing. Public pages, APIs, exports, widgets, and database downloads do not redistribute that unverified source text. They expose a rights-sanitized metadata core containing bibliographic facts, source links, derived annotations, abstract-availability indicators, and allowlisted factual provenance.
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.
CC BY 4.0 applies only to rights held by the compiler in the selection and arrangement, normalization, original annotations, validation outputs, and documentation. Third-party bibliographic fields remain subject to applicable upstream rights and terms. An abstract being publicly readable or available through an API is not treated as permission to redistribute it.
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.
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.
If you choose Download in Offline library, public bibliographic metadata and reference DOI identifiers are kept in IndexedDB on this device. Cache Storage also retains the normal app pages, local images and scripts, public chart and trial-map data, world geometry, research network data, the sanitized SQLite download and reuse scripts. These support the normal interface, local record details, reading lists, saved searches, metadata filters, maps, research graphs and BibTeX, LaTeX, RIS, CSV and JSON exports. Search covers downloaded metadata; videos, video previews, external abstracts, full texts and server services require a connection. Videos and preview clips are excluded from the offline download. Offline saved searches use the same device-only workspace storage as saved online views; search text and reading-list contents are not sent by the offline library. When this app is open and connected it checks for catalogue changes and replaces the saved snapshot after a complete download. Remove offline copy deletes the catalogue and its offline app bundle and turns automatic updates off; your reading list and saved searches remain separate. The browser may remove site storage, including this copy, and controls whether persistent storage is granted.
Daily aggregate counters distinguish installation invitations, choices, browser install dialogs, installation signals, subsequent installed-mode launches and active browser-days. Device-local markers estimate browser profiles reached by each invitation strategy and reduce repeated reports. Reports include an allowlisted event category, UTC date, strategy version, broad platform category and whether installation was initiated through an invitation or manually. A random identifier for each event prevents duplicate counting during retries; it does not identify a person or device, and server-side receipt identifiers expire after eight days and are removed during daily maintenance. A local queue retries reports for up to seven days. No persistent device identifier, search text, reading list or cross-site identifier is transmitted. Counts describe observed events and estimated browser profiles, rather than exact installations or unique people; normal hosting request logs still apply. Private daily aggregate reports are retained for up to 90 days.
Saving records or searches stores record IDs and view links in this browser's local storage. The workspace does not create an account or synchronise across devices. Opening it requests current public metadata from this site's API, subject to the request logging described above. Exported backups stay under your control. Use Clear this workspace to remove saved records and views, or clear this site's browser storage.
data/ with web-deny rules for sensitive files.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.
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.
The database is a bibliographic discovery and monitoring tool. Source metadata can be incomplete or contain errors, source APIs can 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.
The site owner can authorise a private reporting application to read this site’s Google Search Console performance data. It uses read-only access to query, page, date, country and device reports to evaluate discoverability and improve research resources. Credentials and reports are kept in access-restricted storage and are not published, sold or used for advertising. This owner-only integration does not require visitors to sign in to Google or add browser tracking. The owner can revoke its access through Google Account permissions.
You can separately opt in to observed recruitment changes, registry-status changes, posted registry results and newly linked result references. These preferences remain attached to your confirmed email alert and can be changed or stopped through its management link. Existing alerts do not receive these additional notifications unless selected.
Registry snapshots retain allowlisted status and reference facts to detect changes. Delivery records associate an alert subscription with a change to prevent duplicate notifications. Publication and trial metadata are public research facts; email addresses and access tokens remain protected by the existing encryption and access controls. Changes observed before the selected preferences were enabled are excluded from these notifications.