ProofForum is designed as a public scholarly repository. Information intentionally attached to an accepted paper, public profile, signed review or public comment may be indexed by search engines and copied by third parties.
1. Controller and contact
The operator of the ProofForum service at proofforum.org is responsible for the personal data processed through this deployment. Privacy and data-rights requests may be sent to proofforum@hotmail.com.
2. Data we may collect
- Account data: username, name, email, password hash, date of birth, account status, email-verification timestamps and password/security timestamps.
- Professional data: position, affiliation, city, country, ORCID, website, institutional-verification records, referee applications, expertise and assigned subject scopes.
- Scholarly repository data: PDF/LaTeX files, titles, abstracts, authorship text, structured author names/order/status, subjects, references, selected license, version history, generation provenance and AI-check attestations.
- Private submission-draft data: before final submission, you may save private draft PDF/LaTeX files and working submission metadata, including structured author details and coauthor email addresses you have entered. Drafts are associated with your account, are not public repository records, and may be deleted by you or consumed when you successfully submit the paper.
- Coauthor invitation and claim data: a submitter may provide an author invitation email address, affiliation and ORCID identifier after manually confirming that the email belongs to the named author. ProofForum stores invitation/claim status, security-token hashes and related timestamps/audit events so the named person can confirm, decline or claim authorship. The submitted coauthor email address is not intended for public display.
- Review and moderation data: reviews, comments, highlighted passages, referee status, moderation decisions, rejection reasons and audit history.
- Technical/security data: session identifiers, request timestamps, IP-derived information available to server logs, hashed IP/user-agent values where recorded, rate-limit data and security/error logs.
- Support data: information voluntarily supplied in support, privacy, copyright or security correspondence.
- Verification records: for a work hosted on an external repository (arXiv or Hexagon), the public metadata that the repository publishes, including the authors’ names and affiliations as listed and any ORCID iDs listed there; the account that requested each version; authorship claims, with the evidence notes their authors provide; decisions on those claims and hosting authorizations given by recognized authors; records of when the source repository was checked; and the declaration of a reviewer whose name matches a listed author that they are not that author.
3. Why we process data
We process data to create and secure accounts; verify email and institutional affiliation; receive, moderate, publish and preserve scholarly submissions; attribute reviews and comments; enforce subject-scoped permissions; prevent abuse and fraud; send transactional notices, including coauthor invitations and authorship-claim decisions; respond to support and rights requests; maintain repository integrity; diagnose failures; and meet legal obligations.
4. Legal bases where GDPR/EEA law applies
Depending on the processing activity, ProofForum may rely on performance of the service requested by the user, legitimate interests in operating a secure scholarly repository and preserving its integrity, compliance with legal obligations, and consent where consent is specifically requested. Where a legitimate-interest basis is used, it is balanced against the rights and interests of affected individuals.
Verification records. We process the verification-record data listed in section 2 to keep an accurate, attributable verification record of a published scholarly work, to prevent impersonation and conflicts of interest, and to handle rights and attribution requests. Where GDPR applies, the legal basis is the legitimate interest of ProofForum and its readers in a reliable, attributable public verification of scholarly works (Article 6(1)(f) GDPR). Author data is limited to what the source repository already publishes; naming the authors of a published work also respects their right to be recognized as its authors.
5. What becomes public
Accepted papers and their public metadata may include title, abstract, author text, submitter/uploader identity, subjects, selected license, version history, references, AI-check provenance and public review evidence. Public profiles may display username, public/legal name where configured, position, affiliation, city/country, ORCID, website, role and subject-scope badges. Certified reviews and public comments are intended to be attributable. Account email addresses, submitted coauthor invitation email addresses, dates of birth, password hashes, pending/rejected private files and internal security data are not intended for public display. Public paper metadata may show an author name and authorship-confirmation status without publishing the invitation mailbox.
Verification records. A published verification record shows the repository’s public metadata for that exact version; which ProofForum account requested it (requesting confers no authorship); which listed authors have been recognized as ProofForum accounts; and the public reviews, comments and judgments made on ProofForum. Claim evidence notes, pending claims and hosting authorizations are visible only to the people who decide on them and to administrators.
6. Managing Editors and internal access
Administrators may access account and moderation data needed to operate the service. Managing Editors may access paper versions and editorial information only for subjects assigned to them, including draft, submitted, published, rejected and withdrawn versions where needed for editorial work. Their role does not provide general access to user-management or unrelated account data.
7. Cookies and optional first-party analytics
ProofForum uses essential first-party cookies for authentication and security. If a user explicitly selects Stay signed in, ProofForum also creates a revocable persistent authentication token for up to 30 days; the cookie does not contain the password and the database stores only a hash of its secret component.
Visitors are offered a separate choice between Essential only and Accept analytics. If analytics are not accepted, optional analytics events and analytics cookies are not created. If analytics are accepted, ProofForum may keep first-party counters and dimensions for repository operation and product improvement, including page views, unique/first-time/returning browser counts, device category, browser family, operating platform, screen size, language, time zone, referral host, source/medium, UTM campaign data, search-engine/source information when actually exposed by the browser, and coarse country/region/city from hosting-network headers or, when those are unavailable, from a consent-gated IP lookup through ipapi.co. Audience/acquisition dimensions are recorded once at the start of a sliding 30-minute analytics session rather than on every page view.
With analytics consent, the browser receives a random first-party analytics identifier so unique browsers can be deduplicated across days. The raw random identifier remains in the browser; ProofForum stores only a keyed HMAC representation and per-day presence records, does not use that value as an account identifier, and removes visitor-deduplication records after about 400 days of inactivity. For signed-in consenting users, aggregate analytics may also include an age band derived from the date of birth already held for the account and the account's registered country. ProofForum does not infer or collect gender for analytics. Analytics storage does not contain the raw analytics identifier, IP address, full user-agent value or a probabilistic browser fingerprint. Exact organic search phrases are recorded only when they are genuinely supplied by a referral/campaign parameter; likely email/contact data, URLs/domains, IP addresses, dates, phone-like values and long numeric identifiers are filtered from stored site-search dimensions.
Independently of optional visitor analytics, requests to dynamic public repository surfaces may be counted in aggregate when their User-Agent identifies a recognized web crawler such as Googlebot or Bingbot. ProofForum stores only the crawler family and coarse surface for this operational count, without setting an analytics cookie and without retaining the request IP address or full User-Agent in the analytics tables. User-Agent identification can be spoofed, so these counts are estimates rather than verified search-engine reports.
No Google Analytics, advertising platform or external analytics account is used by this build. See the Cookie Policy for cookie names and how to change the preference.
8. Service providers and disclosures
Personal data may be processed by hosting, email, security or infrastructure providers as necessary to run the service. Data may also be disclosed when required by law, to investigate security or rights claims, or during a legitimate transfer of service operations subject to appropriate protections. ProofForum does not sell personal data to advertisers.
External repositories. To create and refresh verification records, ProofForum’s servers request public data from arXiv (export.arxiv.org and oaipmh.arxiv.org) and Hexagon (hexagonmath.org). These requests carry the identifier of the requested work and a ProofForum service identifier. They carry none of your account data, and your browser does not contact these repositories through ProofForum.
9. International transfers
Internet services and third-party infrastructure may process data in multiple jurisdictions. Where applicable law requires transfer safeguards, the operator will use an appropriate legal mechanism or provider arrangement.
10. Retention
Where an administrator consolidates duplicate accounts, ProofForum keeps a non-login source-account tombstone, merge audit record and verified login aliases as needed to preserve scholarly provenance, prevent identity reuse and route the former verified identity to the surviving account. Historical audit actors are not rewritten to pretend that the destination account originally performed the source account’s past actions. Authentication/reset/session credentials associated with the source account are revoked during consolidation.
Account and operational records are retained for as long as needed to provide the service, secure accounts, resolve disputes and comply with law. Published scholarly versions, public metadata, provenance and associated editorial history may be retained for the long-term integrity of the scholarly record. Security logs and rate-limit records should be kept only as long as reasonably necessary for security and diagnostics. Password-reset and verification tokens are time-limited and invalidated after use or replacement.
Verification records. Metadata snapshots, claims and the audit records of verification records are kept as part of the scholarly record and of the service’s security log, like other repository records. The short-lived copies of repository responses that ProofForum keeps to limit repeated requests expire after about ten minutes.
11. Security
ProofForum uses password hashing, email verification, session controls, CSRF protection, prepared database queries, access checks, upload validation, private file storage, rate limiting and other technical safeguards. No internet service can guarantee absolute security; users should use unique passwords and report suspected compromise promptly.
12. Your choices and rights
Depending on applicable law, you may have rights to access, correct, delete or restrict certain personal data; object to certain processing; request portability; or withdraw consent where processing is based on consent. Some requests may be limited where data must be retained for legal obligations, security, fraud prevention, rights claims or the integrity of an already-public scholarly record. Contact proofforum@hotmail.com to exercise a right.
Listed authors of external works. The names, affiliations and ORCID iDs of the authors of an external work come from the public metadata of arXiv or Hexagon, not from the authors themselves. ProofForum does not contact listed authors who have no account and does not use their data for any other purpose. A listed author can ask ProofForum for access to or correction of this data at proofforum@hotmail.com, and can also correct it at the source repository, whose metadata ProofForum reflects.
Right to object. You may object at any time, on grounds relating to your particular situation, to the processing of your data on a verification record. ProofForum then stops that processing unless compelling legitimate grounds, such as the attribution of a published work and the integrity of the public scholarly record, override your interests, rights and freedoms; where they do not, ProofForum restricts the data concerned. You may also lodge a complaint with a data protection supervisory authority, in particular in the EU Member State where you live or work or where you believe the infringement took place.
13. Children and age
ProofForum is intended for users who can lawfully use the service and enter into the applicable agreement. If local law requires parental or guardian consent, the user must obtain it before creating an account or submitting personal data.
14. Automated processing
ProofForum uses automated parsing, security scanning, reference extraction and status calculations. Automated checks may assist moderation but do not replace human mathematical judgment. Material editorial decisions remain attributable to administrators or authorized Managing Editors.
15. Changes to this policy
This policy may change to reflect new functionality, law or data practices. Material changes will be published with an updated effective date and additional notice or consent will be used where required.
16. Contact
Privacy, account-data or security questions: proofforum@hotmail.com.