Privacy Policy

What xRead is

xRead helps you extract, verify, summarize, and discuss academic references. The Word add-in loads UI from our servers into Word’s task pane. The Chrome extension opens a side panel and, on sites that match the URL patterns declared in its manifest (for example common LMS, university and research domains, selected publishers, Google Scholar, Microsoft 365 document hosts, and xread.io), loads a bundled content script so that when you run a command it can read text from the active page (for example a selection or extracted body text). Local PDFs opened as file:// are supported only if you enable file access for the extension in Chrome. We do not upload full documents automatically. Data is sent to our API when you take an action that requires processing (for example running citation tools, chat, grading, or sync).

Chrome extension — what we do not do

xRead is not a remote-control or “full browser access” product. The extension cannot operate outside Chrome’s permission model, does not silently read every site you visit, and does not collect your browsing history for profiling. Content scripts run only on the declared host patterns in the published manifest—not on the open-ended public web.

• User-initiated use: Requests to xread.io carry text or metadata when you use the toolbar, context menu, in-panel actions, or the optional full-tab PDF reader—not as continuous background monitoring of pages.
• Side panel, tabs, and scripting: These Chrome APIs let xRead open its UI in the side panel, keep the panel aligned with the tab you are working in, and inject the on-page bridge when you invoke a feature. They do not grant xRead unlimited control over Chrome, other extensions, or your device.
• Storage (including “unlimited” storage where declared): Used for sign-in state, UI preferences, short-lived handoff of PDF data between extension surfaces, and similar client data needed for features—not to exfiltrate unrelated third-party site content.

Data you send to xRead

Depending on the feature you use, requests to our servers may include:

• Text excerpts from your document or web page (including selections, reference sections, or passages you paste).
• Structured citation lists, rubric text or uploaded rubric files, and grading-related fields you submit.
• Chat messages, optional conversation history your client sends, and sometimes an image URL you ask us to consider.
• Authentication tokens when you are signed in (see “Account data”).

Traffic is sent over HTTPS. Our backend may forward portions of that content to AI providers (today primarily Google Gemini) and to scholarly or search APIs such as OpenAlex, Semantic Scholar, and where configured SerpAPI, solely to fulfill the feature you invoked.

Account data we store

If you create an account, we store typical account records in our database, including:

• Your email address, a password hash (not your plain password), and session / refresh-token material for secure login.
• Optional institutional association if your organization provisions xRead.
• Saved references (“library”): citation strings and related metadata you save to your account.
• Grading calibration: when you correct AI-suggested scores, we may store rubric titles, scores, rationales, optional short document snippets you supplied as context, and related feedback so we can improve alignment for your account.
• Rubrics you upload or create: titles, criteria, and any file content you attach may be stored so you can reuse them.
• Persona and “skills” markdown you configure for Lux / grading, and structured activity events (for example timeline or assistant events) tied to your user id for product features and diagnostics.

The Chrome extension stores your session token in browser local storage so you stay signed in; Word uses the same account system through the hosted task pane.

Chat and “ephemeral” processing

Chat and similar endpoints process the payload you send to return an answer. We do not advertise a separate long-term “chat transcript” product in our database schema; treat chat content as sensitive and avoid pasting legally restricted or highly personal data. Standard server and cloud operational logs may exist for security and reliability and can briefly include request metadata.

Shared literature cache

To reduce duplicate external API calls, we maintain aggregated public scholarly metadata and derived summaries keyed by citation identifiers (for example DOI or normalized title). This cache does not need to retain your full manuscript; it stores reference-level enrichment that may be reused across users.

Local storage on your device

Clients may cache results (for example summaries or UI state) in local storage, IndexedDB, or Office’s host environment so the product feels responsive. Third-party integration keys you choose to store (for example a reference-manager API key) stay on your device unless you explicitly configure otherwise.

Support form

When you use support.html, your name, email, subject, and message are posted to our /api/support endpoint over HTTPS so our team can reply. Handle support messages like email: do not include secrets or full unpublished work unless you accept that we may need to read it to help you.

Retention and deletion

We retain account-linked data while your account exists and as needed for legal or security obligations. To request deletion or export of personal data, email support@xread.io from your registered address where possible.

Third-party services

• AI and search providers (for example Google, Semantic Scholar, OpenAlex, SerpAPI) act as sub-processors when we call them on your behalf. Review their policies for how they handle API traffic.
• We do not sell your personal information to advertisers. We use data to run and improve xRead.

Contact

Questions about this policy: support@xread.io.