Privacy policy¶

Last updated: 2026-08-28

papio runs on your computer. It has no hosted service, user account, telemetry, or analytics. This policy covers the papio application (daemon and CLI) and the papio browser extension.

Summary¶

papio does not collect your data or send it to OrgMentem.

The extension communicates with the local papio application through the browser's native-messaging interface. It does not contact OrgMentem or any other external service on its own, except when it asks a provider page to turn a link into a PDF URL.

The local application does contact third-party scholarly services to find papers. These requests include the identifier you ask papio to resolve, such as a DOI, PMID, arXiv ID, or title. Some services also receive your configured email address or API credentials. The table below lists every destination and the data it receives.

Requests to third-party services¶

Every destination below is contacted directly by the daemon on your computer. Each request carries the identifier being looked up. The “Data sent besides the lookup” column lists anything else sent.

Important details¶

Email address. The email setting is sent to services that require or accept it. Unpaywall and OpenAlex require an email address. Crossref and DOI lookup use it when configured. Leaving it empty prevents Unpaywall and OpenAlex lookups.

Retraction checks. Retraction checks send the DOIs of papers already in your library to Crossref. Disable them with [sources.retraction_watch] enabled = false.

Update checks. Update checks make an unauthenticated request to the public GitHub releases page. GitHub receives your IP address, as it would for any web request, but papio does not send your identifiers or usage information. Disable the check with updates.check = false.

Document delivery. Document delivery is disabled unless you configure it. When enabled, papio contacts only the institution's configured delivery service and sends the credentials and bibliographic details required by that service. It never uses a shared or papio-operated delivery service. See the configuration reference for the full field list.

Browser extension¶

• No OrgMentem data collection. The extension has no backend and does not send data to OrgMentem. It communicates with the local native-messaging host com.orgmentem.papio.
• No browser credentials leave the page. You enter institutional credentials and complete MFA or CAPTCHA in your browser. The extension never reads a password field, a cookie, or your browsing history, and it never stores or transmits a username or a session token. To tell whether your library session is live, the check it runs inside the configured library page does read that page's own visible affordances and its localStorage and sessionStorage entries, including whether a session token found there has expired and whether it carries an identity claim. Every value is discarded in the page: only the resulting signed in / signed out / unknown classification comes back, and nothing else is stored or sent.
• No background scraping, and scanning is explicit. Page scanning runs only when you click it, reads only the top frame of that one tab, and runs entirely inside the page: identifier detection is local JavaScript, not a network request. Your explicit click is the consent for that one scan; no separate site approval exists. Selection acts only on the papers you choose, with a maximum of 200 canonical keys per durable cohort, submitted in bounded chunks. It does not crawl, harvest, or auto-submit pages.
• Institution-session checks follow your local keep-warm mode. The default While papio has work mode checks the configured library resolver only while institutional papers are active. Always for current library keeps that resolver warm even when no paper currently needs it. Off stops automatic resolver checks. When a paper is waiting for sign-in, a completed HTTPS navigation on that paper's declared publisher host can schedule a check of the configured library resolver. This publisher-triggered path reads no publisher page content. The publisher page cannot set the popup's signed-in or signed-out verdict; that comes only from the configured library page. If papio's own resolver tab is still paused on an identity-provider page, the trigger leaves that page open and creates a muted background resolver tab for the check. The replacement surfaces only when the resolver itself says that sign-in is still required. A tracked papio tab returning from authentication can still provide the existing, same-origin release evidence for queued work, subject to current resolver access. Other hosts, queued-only work, missing institution bindings, and ambiguous institutions do not authorize this trigger. No new landing URL, page-derived publisher data, title, path, query, fragment, cookie, credential, or session token enters extension storage or a native message.
• What a scan sends to the local application. The scan itself sends nothing. When the selection workspace opens, the detected identifiers (each a doi, pmid, arxiv, or openalex kind and value) plus a structural count of visible records go to the local papio application so it can mark which papers you already own and which are eligible. When you submit, only the canonical keys of the rows you selected are acquired, along with the page's bare lowercase HTTPS origin and the detector name. The short citation label shown beside each row — up to 240 characters of the nearest citation-shaped container's visible text — is display-only and stays in the browser; it is never sent. No page text, path, query, fragment, page title, or credential leaves the browser for a scan.
• The host-page action acknowledgement is ephemeral and local. When a popup action succeeds and transient acknowledgements are set to show for all requests, the extension briefly draws a small chip in the page you acted on. It carries one of four fixed short phrases and nothing else — no identifier, title, URL, provider name, or job id — is not interactive, sends nothing anywhere, stores nothing, and removes itself after three seconds. It reads no page content and installs no watcher or content script.
• The loss toast prefers the page when all-sites access is active. When papio loses a tab it opened for a paper, it can offer to reopen that route. With all-sites access granted, "Show the lost-tab message in the page you are reading" is on by default and draws the message into the page in front of you. Turn it off to use the small papio window instead. Revoking all-sites access turns the in-page route off, and re-granting access does not restore an explicit opt-out. Both routes show the same fixed sentence, one button, and papio's own mark. They carry no identifier, title, URL, provider name, or job reference, disappear eight seconds after arriving, and commit nothing when they go. Neither appears while a papio surface holds focus.
• The in-page loss message reads nothing. The all-sites grant lets papio reach the current HTTPS page. The loss-toast setting selects the integrated route or the separate window. When papio draws the message, it adds one element and reads nothing from the page. No selector runs, no page text is collected, and nothing about the page is stored or sent. The message renders inside a shadow root, so the page's scripts and styles do not reach it. It removes itself before reporting your choice. It is never drawn into a page papio is driving, a non-HTTPS page, or a PDF. A withdrawn grant, blocked injection, or unsafe page always falls back to papio's own window.
• Focused-surface presence is minimal and local. The feature-gated surface_presence_v1 hint carries only an opaque per-instance id, the focused surface type (popup or inbox), a boolean focused value, and a timestamp. It goes to the local daemon only. It contains no URL, title, tab id, host, identifier, or page content.
• Page-bulk recovery is origin-bounded. The browser-local restart-safe cohort record stores only a bare lowercase HTTPS origin, a bounded detector identifier, and canonical keys (plus the recovery bookkeeping needed to replay chunks). It stores no path, query, fragment, page title, or bearer value.
• Ownership marks come from a local check, not the network. A page-bulk row's owned_with_pdf / owned_missing_pdf / ownership_unknown marks can come from your Zotero library through zotio, which the local application invokes as a local subprocess in local-only mode: the lookup answers from zotio's existing on-disk library mirror, and no network request is made for this check — in particular, papio never triggers a Zotero-account sync from a workspace scan. The mirror refreshes only through your own zotio activity (for example, when a paper is filed after acquisition), so a stale or failed check reports ownership_unknown honestly rather than a false "not owned."
• Normal browser session. The extension uses browser extension APIs and native messaging. It does not use WebDriver, CDP, or other browser-automation frameworks.

Local storage¶

Browser storage. The extension stores its settings and temporary job and tab state in browser storage. This data stays in the browser so the extension can survive service-worker suspension and reconnect to the local application. For an active institutional job, browser storage can also retain the configured library resolver as one bare HTTPS origin. A pending session-recheck reason can survive service-worker suspension beside it. Neither value contains the publisher landing, an identity-provider address, a path, query, fragment, title, cookie, credential, or permission pattern.

The dedicated page_bulk_cohort_recovery_v1 browser-local record is limited to restart-safe replay data: a bare lowercase HTTPS origin, a detector identifier, and the ordered canonical keys, together with opaque cohort/chunk bookkeeping and timestamps. It never stores a path, query, fragment, page title, or bearer value.

Browser storage for page scanning. Page scanning requires an explicit click for each scan. The browser stores only the restart-safe page-bulk cohort record described above, with no path, query, fragment, page title, or bearer value.

Application storage. The local application stores papers, metadata, and job records in its data directory. Validated PDFs live in artifacts/. Downloaded candidates awaiting validation live in quarantine/. Papers go only to your own Zotero library if you enable that integration. Notification routing also keeps the notification_intents ledger in papio.db; its payloads are durable and may retain identifiers such as a retraction finding's DOI indefinitely. For a single-finding integrity notice, the DOI may also appear in the macOS Notification Center notification text, subject to your operating system's notification and lock-screen settings.

Diagnostic captures. Diagnostic captures are sanitized HTML from pages you choose to capture. They are stored in <data_dir>/captures/<host>/ and may still contain article text, account labels, or other page content. Captures are retained for 14 days and up to 10 per host by default; both limits are configurable in [captures]. Run papio adapter captures purge to remove every capture, or papio adapter captures purge --host <host> to remove captures for one host.

Bug reports. The data directory may also contain papio.db (request history, titles, identifiers, and notification-intent payloads), native-host.log (browser-session diagnostics, including URLs), a legacy adoptions/ directory on installs that predate the browser-download adoption root, and the update-cache*.json and retraction-cache.json files. Browser-downloaded files awaiting adoption now live in the adoption root itself (<your download folder>/papio by default). papio does not upload any of these. Review and minimize them before sharing a bug report; they describe what you have been reading.

Adapter evidence. Reaching a provider with no adapter can create a sanitized diagnostic capture, but papio never uploads it, opens a public issue, or sends telemetry. Review and minimize a capture before sharing it yourself. Sanitized HTML can still contain article text, account labels, or other page content.

Acquisition history and impact figures. The extension's figures — papers acquired, success rate, weekly acquisition trend, access-route breakdown, and human-handoff rate — are calculated locally from job records. They are displayed only to you and are never transmitted anywhere.

Permissions¶

Each browser permission is used to perform a requested download, read a page needed for that job, run an explicit one-shot scan of the current tab, check a configured library session while a paper is waiting for sign-in, or report a result to the local application. For example, nativeMessaging reaches the local daemon, downloads saves the requested PDF, activeTab permits the top-frame scan only after you click it, and host permissions allow the extension to read the relevant library and publisher pages. The extension store listing explains each permission in detail.

Third parties¶

papio does not sell your data or share it for advertising, credit decisions, or unrelated purposes.

The third-party scholarly services in the table receive the data listed there because they are needed to find or download the paper you requested. During browser handoff, your browser contacts your institution and the publisher directly. papio is not an intermediary for those requests.

Changes¶

If this policy changes, the “Last updated” date above will change. The current version will always be available at this URL.

Contact¶

Questions about privacy: open an issue at github.com/OrgMentem/papio.