Privacy

• Research Connect needs no email. Every user has an account, and it comes in two kinds. When an AI client connects, the sign-in page asks which. "Proceed with no login" makes a code account: it has an account code, and no email, no name and no password. "Create login or sign in" makes an email account. You can also sign up for an email account on the dashboard, with no AI client.
• Your research questions are not saved.
• Downloaded article text is not saved after it is returned to your AI client. The one exception is a long article: it is held in memory on our server, never on disk, for about three hours, so your AI client can read it in parts.
• We keep minimal security and debugging logs.
• Requests to our server pass through two services that log them. A Cloudflare Worker receives each request first and passes it on. Its log keeps the address asked for (with any part after a question mark) and your IP address. It keeps them for 3 to 7 days. That is set with the Worker, not in our server's setup. Google Cloud, which hosts our server, logs every request too: the time, the address asked for, the answer's status, and an IP address, which may be the Worker's rather than yours. Our setup does not set how long Google's log is kept. Its default is 30 days.
• Some of those addresses carry a short-lived link: a pairing link, an email check link, a download link for the browser extension, or a research-service sign-in link. A Connect link for a research service, in a reply to your AI client, carries the id of that service, so when you open it the logs keep that id next to your IP address. The key of a library's or a publisher's COUNTER access is in them too: the COUNTER rules put it in the address. It names a library or a publisher, not a reader. The extension keeps its own link out of those addresses. Older versions of it put the link in the address of their connection. Our server now refuses those connections without reading the link, but the logs still keep the address they sent.
• We keep usage records to see how the tools are used. A record says which tool was called, when, how long it took, and whether it worked. It names the AI client program, the attached institution, and the publisher connector that was used, with the connector tool when the call worked. It says how access was set up (no institution and no network, the network your browser is on, or an institution), which kind of account was in use (a code account or an email account), whether the call came with a sign-in from your AI client, and whether the browser extension was connected. A record is also kept when a conversation starts (with the version of the AI client program), when a rate limit is hit, when an institution is set, and when the browser extension is linked.
• For a requested article, a usage record keeps the publisher prefix of its DOI, how the request ended, and how many characters of text were delivered. It never holds the full DOI, the title, or the text. The shared record, below, holds the full DOI and the article's title, but never the text. The history of an email account holds the full DOI too, and shows the title the shared record has for it. A record can also hold a few settings of the call, such as the sign-in method asked for or the retrieval mode, counts of PubMed ids per outcome, the version of the browser extension, and, for a requested or checked article, whether it was open, entitled, maybe (the publisher can only confirm access after you sign in), not entitled or unknown, why it was unknown (a reason from a short fixed list, such as a publisher that is not supported or no answer from the service that checks access), and whether the answer for your institution and the answer for your network differed. For a requested article, a record also keeps which connector the fetch named (the display name of a connector, which may be one you added, as you typed it), and the next step the assistant was given. For a requested or checked article that was entitled, it also keeps who granted it (institution, network or both). Usage records never hold your questions or your IP address.
• The Insights page that administrators read shows counts only. A strip at its top gives the number of accounts, split by kind, how many have an institution or a linked browser extension, how many are new, and how many browser sessions and accounts were active lately. The table below it counts users, calls and articles by publisher, institution, AI client and a few other cuts, and, for an institution, how many accounts declared it. It names no account and lists none.
• The My insights card, on the Account Analytics page of your dashboard, shows counts from your own records only, nothing from anyone else's: your counters, and for an email account your history, cut by publisher, route, how a request ended, how access stood, the reason behind an unknown, AI tool or institution. It shows numbers and the names of publishers and institutions, never a DOI, a title or text.
• Each usage record carries scrambled keys in place of the ids of your session and your conversation, so records from one session can be counted together. A key cannot be turned back into the id, and no usage record holds your account, your name, your email or an IP address. There are three exceptions. The keys are made with a secret this service keeps, so an operator who holds both that secret and the database could recompute the key of an id they already know. For an email account, the history described below lines up with the usage records of the calls it holds, as that section says. And we keep exact times next to your browser session while it lasts: when it was opened and last used, when your conversations started and were last used, when your AI client signed in, when your browser last told us its IP address, when your institution was set, and when each publisher was last checked. Somebody with access to the database could line those times up with the time of a usage record, and so tie that record's keys to your browser session, and to your account. The account itself keeps the exact time it was made, for as long as the account lasts. A code account is made in the same request as its first browser session, so that time can line up with the first usage records of that session, and tie their keys to your account after the session is gone. Our security log also keeps, with your account, the moment of a few of your actions, and keeps it after the browser session has ended. One of them is noted at the same moment as a usage record: when you change your institution on your dashboard, a usage record notes that an institution was set. That ties the keys of that record, and of the records that share them, to your account. The others keep their exact time too, for example when an email account signs in, you change your email or password, clear your history, switch a research service on or off, start a sign-in to one on your dashboard or sign out of it, or add a connector of your own, remove it, or sign in to it or out of it in My connectors. The rows about a research service or a connector also keep which one it was, and for a switch whether it went on or off, and for a connector you add its name, until you delete your account.
• Usage records do not expire on their own. They are kept until an administrator deletes the old ones. Only super administrators can see them or delete them.
• Your IP address, attached institution, and questions are treated as personal data.
• When your browser talks to us (on the sign-in page, on your dashboard, or through the browser extension), we note the IP address it came from on your browser session. When we check whether you can read an article, we use it to ask whether the network you are on has access to it, and for that we send it to GetFTR, the entitlement service we ask. We also compare it with the address ranges that institutions publish in their own federation metadata, to suggest your institution to you and, when an article came through your network's own access, to name that institution in the shared record; the comparison is made here and the address is not sent anywhere for it. When it falls inside the ranges of the institution you set, we ask GetFTR once for both. It is not a way to sign in, and it is not a setting. It stops being used some hours after your browser last talked to us, and it is deleted with the browser session. We also keep the address a browser session was first made from, until that session is deleted. The address your AI client calls from is never used for this: it usually belongs to the AI provider. Your AI client can make us forget the noted address (the reset_session tool); it is noted again the next time your browser talks to us.
• To say what an article is and whether it was retracted, and to fetch its open text, our server asks other services about it. About the article it sends its DOI, and for NCBI also its PubMed Central ID and, when your AI client asks for a PubMed ID to be resolved, that PubMed ID, and nothing else: to Crossref and DataCite, for the title, authors, journal and retraction notices; to doi.org, only when Crossref has no record of it or does not answer, for where the article lives and for its metadata, and then doi.org passes the metadata request on to the registration agency that holds the DOI (for example DataCite, JaLC, mEDRA, Airiti or ISTIC), which then receives the DOI too; to NCBI, to find out whether the article is in PubMed Central, and then the PubMed Central ID of the article, to fetch its text, and, for a PubMed ID you ask to have resolved, that PubMed ID to its ID converter and its summary service; to OpenAlex, only for an open-access article that no free route delivered and only while that route is switched on, to ask whether it holds a text made from the open-access PDF of the article and, if it does, to download that text: it receives the DOI, then its own number for the article, and the key our service holds with it; and to the sites that hold the open full-text links Crossref lists for it, which are asked for the link, under the name ResearchConnectBot, and for their robots.txt. Our own contact address goes with some of these requests: the one we have set for Crossref goes to Crossref and, in the request for metadata, to doi.org and the registration agency, and the one we have set for NCBI goes to NCBI with the name of our service. The requests come from our server. Nothing of yours goes with them: no account and no address of yours. They are made the same way for an account with no institution.
• To stop abuse we count requests by IP address in our database. Those counts, with the address, are deleted after about two hours.
• Two cookies of ours recognise your browser. One names your browser session, and lasts up to 30 days. The other remembers your account in this browser for a year, so you can come back after the session has ended. For a code account that cookie is enough to continue. For an email account it only fills in the email, and the password is still asked, except that a browser session still alive can connect another AI client without it.
• A few short-lived cookies carry one step from page to page and then go: the wait for an email link (up to an hour), "Not now" on the extension step (24 hours), the sign-in of an AI tool that asked to connect, so you can pick it up after you close the tab (24 hours; it holds only that request: the identifier of the tool, the address it asked to be sent back to, a check code the tool made up for this request, the address of this server it wants to use, and its own reference, and nothing about you), and a download link on its way to the extension (15 minutes). Two more last until you close the browser: a research-service sign-in in progress, and a check that a form came from our own page. The dashboard keeps its own sign-in in your browser's storage, for up to 30 days, and we keep a hash of it until it expires or you log out.
• These expire automatically: the GetFTR entitlement cache, sessions, pairing codes, link tickets, and document and connector tokens.
• When you press Finish on the sign-in page, we make a one-time code for your AI client. The code works for one minute and once. We keep its record, which names your browser session and the request your AI client made, for a little over a day, even after it was used, so that one sign-in page cannot sign your AI client in twice. The record is deleted with the browser session.
• Feedback you choose to send us, through your AI client or the feedback page, is different. It does not expire on its own. We keep it until an administrator deletes it. A report holds your IP address, your institution when there is one, and your email only if you agreed to be contacted. A report from a code account is never linked to the account. It still holds your IP address, and any article DOI you put in it, as every report does. A report from an email account is linked to it only if you agreed to be contacted.
• You can log out of your dashboard at any time, and you can unlink the browser extension from its popup. Neither one deletes your account.
• An account holds what you gave it and what it needs to work. An email account holds your email, your name, and your password as a hash. A code account holds an account code and nothing that names you: the code is kept in two forms, scrambled with a secret key, so the account can be found from the code but the code cannot be read back from it, and encrypted, so it can be shown to you again. Both kinds hold your institution (the account keeps it on its own too, with no time of day, so a browser session opened after the others have ended starts with it), your research-service switches, the browser sessions, AI client sign-ins and extension links you made, the day after the account was last offered the browser extension, with no time of day, and the institutions we suggested to you, with the UTC day each was first and last suggested and, if you dismissed one, when. A research-service sign-in belongs to the account: every browser session of the account can use it, and signing out of the service ends it for all of them. A sign-in link to a research service, from your AI client or from My connectors, is not tied to your browser: whoever opens it and signs in at the service puts that sign-in in the account the link was made for. The address your dashboard's Connect opens can be turned into such a link too. So do not sign in at a research service through a link that somebody else sent you. Either kind can also hold connectors you added yourself, with their addresses and notes: they are kept as long as the account is, are used only for you, and are deleted with it, or moved to the email account in a merge. Each account may add only so many of them. Accounts are kept until their owner deletes them. Nothing deletes an account by itself. So a code account whose code is lost, in a browser whose cookies were cleared, stays with us, and nobody can reach it, short of an operator who holds both the secret this service keeps and the database: the encrypted form of the code is made with that secret, as the usage record keys above are.
• We suggest an institution to an account from four things: the network your browser is on (we compare the IP address we noted with the address ranges that institutions publish); the domain of an email account's address, which we compare with the domains that institutions publish in their own federation metadata; an article that really arrived through the institution your browser session holds; and, where the browser extension can read it, the institution a publisher's page says is giving you access, which we compare with the names institutions publish in their own federation metadata. A suggestion only suggests: nothing is set for you until you press Confirm. A few well-known free mail providers, such as gmail.com and outlook.com, are never looked up.
• For each publisher where your browser was asked to sign in, or delivered an article through your institution, the browser session keeps the publisher's name and website, which of the two happened, and when it was checked. After a request to sign in it also keeps the publisher's home page, so you can sign in there, never the address of an article. That record is replaced by the next answer for the same publisher, and deleted when you change or remove your institution, unlink the extension, or the browser session is deleted.
• When you ask for an article from a publisher that has no research service with us, or that your institution has no automated sign-in for, we count it for our administrators, by publisher: its name, website and DOI prefix, the kind of institution sign-in of the first such request, how the latest attempt went, how many times it was asked for, and the first and the latest day. It holds no article, no journal, no account, no institution and no time of day.
• Every email is checked before it is used. We send a link to the address, through our email provider. The link opens a page with one button, and the account is made, or the email is changed, only when you press it. The link works for one hour. A sign-up that is never confirmed makes no account, and its email, name and password are not stored in our database. Our server keeps the address in its memory, not in the database, for one minute, so that no second email goes to it within that minute.
• If you forget your password, you can ask for a reset link by email. We send it to the address on the account, through our email provider; the link works once and stops working after one hour. Changing or resetting your password signs you out everywhere else.

Code accounts

• A code account has no email, no name and no password. Its account code is its key, and so is any browser that was signed in to the account: anyone at that browser can open its dashboard.
• We never link an article to a code account. No table holds a DOI, or the address of an article, next to a code account. Per publisher, the browser session keeps only the record described above: the publisher's name and website, whether you were asked to sign in or an article came through, and when; never an article's address. Of your reading, its dashboard shows counters only: per day, and per publisher per month. It also shows your institution, with a link to the home page of a publisher where you were asked to sign in. A publisher is named from the first part of the DOI, never from the article.
• That is not the same as holding nothing about you. The counters belong to an account whose browser sessions note an IP address, so we treat them as personal data. And on a quiet day, somebody with access to the database could line the counters up with the shared record below and work out an article by elimination. Counting each publisher by month, not by day, makes that harder. It does not make it impossible. And the other counters (how many articles, by which route, by which AI tool, how much text) are kept per day. Those per-day counts also say how many of the articles you asked for were open, entitled, maybe, not entitled or unknown, why an access check came back unknown (a reason from a short fixed list), how many access checks found that the answer for your institution and the answer for your network differed, how many times your AI tool was pointed to a research service to use, and how many times it was handed a link instead of the text. They are numbers of each, per day, with no article, title, text or IP address, and a day before we began to count them shows no figure. The per-publisher record of your browser session, described above, also keeps the exact second each publisher was last checked, while that session lasts. Lined up with the usage records and the shared record, that time can point at the article read at that moment, as the counters can on a quiet day. A code account that has connectors of its own also holds the names and addresses you typed for them. Those are yours: they stay until you remove them or delete the account.
• The account code never changes, and there is no button to replace it. If it leaks, there are three ways out, and they differ. Deleting the account ends everything made with the code: its browser sessions and the AI tools signed in on them. Adding an email retires the code, and merging the code account into an email account you already have deletes it, moving its counters, its research-service switches, the connectors it added and the notes it wrote, the institutions we suggested to it, and its browser sessions there. But both keep every browser already signed in with the code, a leaker's too, and the AI tools signed in on them.
• Adding an email turns a code account into an email account. Your counters carry over, and they carry over in a merge too. They last as long as the account: they are deleted only with it, or moved in a merge. Articles were never linked to your code account, so your list of articles starts on that day. Nor does your list lead to what the code account read: the usage records and the shared record keep that under other scrambled keys. The same is true when a code account is merged into an email account. One exception, about a second wide: a call the code account made just before the merge, and recorded just after it, lands in your list.

Email accounts

• For an email account we keep a history of the articles you ask for. For each one it holds the DOI, when you asked, how the request ended, how the article arrived, your institution and whether it was verified, the family of your AI client program, how much text arrived, and, for a long article, which part. Checks of whether you can read an article are not kept in it.
• Only you see your history, on your dashboard. No administrator screen shows it. It is still a list of what a named person asked for, and an operator with access to the database could read it there. Its articles and times also line up with the usage records and the shared record, so that operator could tie to you what those records hold of the same session while your history was on.
• You can clear your history at any time. You can also pause it with Incognito Mode: while it is paused, no article is written to your history. The counters, the shared record and the usage records carry on. But what they keep during a pause, or from before you cleared your history, carries other scrambled keys than what your history leads to, so it cannot be tied to you that way. One exception, as narrow as a single write to our database: a call made at the very moment a pause starts can keep the keys from before it.
• Clearing your history removes your list of articles for good, and with it the cuts of the My insights card that are built from that list. No total in any report anywhere else changes: your counters, the numbers on your dashboard, the cuts of My insights that are built from your counters, the shared record and the usage records all stay as they were. Requests you make afterwards are kept apart from the ones you cleared, under a new scrambled key, so a count of how many different people used the service sees you as a new person from then on.
• Your history lasts until you clear it or delete your account.
• An email account also has the counters a code account has.

The shared record: usage reports for publishers and institutions

• We keep a shared record of which articles AI clients checked, asked for, or received through Research Connect. It counts every user, with either kind of account.
• For each article and day it holds: the article (its DOI, and what Crossref says about it: title, journal or book, publisher, type and year), an institution in the cases the next point names, the family of your AI client program (Claude, ChatGPT, and so on, or Other), how the article arrived (for example through the browser extension), whether it was open, free to read, or needed a subscription, four counts -- how many times it was looked at, how many times the text was delivered, how many times it was refused, and how many times your access to it was checked -- and a scrambled key of your session, so one session is counted once. Your key changes when a pause of your history starts or ends, when you clear your history, and when your code account becomes an email account or is merged into one. Each row is one article, in one session, on one calendar day in UTC, delivered one way, and a report adds the rows up by month. It does not hold you, your account, or the time of day. The key cannot be turned back into your session, with the same three exceptions as the keys above: an operator who holds both the secret and the database, for an email account the history, and the exact times we keep next to your browser session. That is not the same as holding nothing about you. The key still stands for one session. The day, the publisher prefix and how the article arrived sit on an ordinary usage record as well, so on a quiet day somebody with access to the database could line the two records up; and in an institution where one person read on one day, that day's records are that person's.
• We share it as COUNTER usage reports with the institution's library and with the article's publisher. The record names your institution in two cases. The first is when your institution was verified, which means an article really arrived through your institution's sign-in. The second is when the article came through the network's own IP access and the institution's own published IP ranges hold your browser's address, no other institution's ranges do, and the institution is one that can be chosen at sign-in. An institution you only declared, or one a guess from your network's name would suggest, names nothing. A library only ever sees the records that name its own institution. With no institution named, no library sees the record. The article's publisher sees its own articles either way. A report can also be asked for split by AI client family, or by how the article arrived. In an institution where one person uses a different assistant program from everyone else, that split puts their month, with full DOIs, in rows of its own.
• It is not deleted with your account, because it does not point at your account. Nothing else deletes it either. It has no expiry, and there is no tool that removes it, so we keep it indefinitely: a COUNTER report is asked for by month, and a month can only be reported while its records are still there.

Deleting your account

• You can delete your account at any time. A code account: from the unlink dialog of the browser extension, or from its dashboard. An email account: from its dashboard, with its password. Deleting works at once, and it is for good.
• What goes: the account itself, with its email, name, password and account code; its counters, its history, the day it was last offered the browser extension, the institution it remembers, the institutions we suggested to you and its dashboard sign-ins; every browser session of the account, and with each one its extension link, its AI client sign-ins and conversations, its research-service sign-ins, what that browser proved at publishers, the IP addresses we noted, and its pairing codes and link tickets; the request counters that name the account or one of its sessions; your own connectors, their notes, and your research-service switches; and the contact email and the IP address on every feedback report that was linked to the account.
• What stays is what names nobody. The shared record stays: it never pointed at you, and publishers and institutions rely on its counts. The usage records stay: they carry scrambled keys, and once your browser sessions are gone, no stored id leads to those keys. Audit lines stay as a security record. They hold the account id, what was done and when. What they said about you, such as the institution chosen or the name of a service you added, is cleared when you delete your account, apart from a line that a request of yours was still writing at that moment. Lines written under a code account that you merged into this account were written under the id of that code account, and keep what they said. A feedback report that was linked to your account stays, without the link, the contact email or the IP address. It keeps its text, the article, publisher, tool, error and research-service address you gave in it, its institution, and the time it was sent. Two small counters, of failed sign-ins and of password-reset requests, are not removed at once: they are kept under a hash of your email address, and the cleanup deletes them within about two hours.
• A feedback report that was never linked to your account cannot be found from it, so it stays as it is, with the IP address it was sent from, and any contact email typed into it. That is every report sent without agreeing to be contacted, and every report from a code account.

The browser extension

• The browser extension fetches nothing until it is linked to your account. Our extension links only after a step from you in the extension: a click on its prompt, which says which account (for an account that only a download link names, its kind and, for a code account, the day it was made, never an email address), an account code you type into its popup, or a pairing code from your AI client that you confirm. In Firefox every install of an extension gets its own random address, so Research Connect cannot tell our extension from another one: a Firefox extension you installed yourself, with permission to use our site, can link itself to the account this browser is signed in to without a step from you. It then learns the account (the email address of an email account), receives the article requests of that account and can answer them with text of its own; for a code account it can also read the account code, open the dashboard and delete the account; for an email account it can pause and resume tracking with Incognito Mode. It can also end the link of our extension in that browser: an unlink applies to the whole browser session, so when we tried such an add-on and it unlinked itself, the connection of our extension was closed too and stayed closed until our extension was linked again. In Chrome only an extension whose id is on our list can link by the cookies of this browser, a download link or an account code; a pairing code from your AI client works from any program that holds it. There is one exception: when you install the extension from a Research Connect download link, on our pages or in a reply to your AI client, in this same browser, and the download link and this browser's own cookies name the same account, it links at once, shows you which account, and offers "Undo". A reply to your AI client that missed the full text of an article because no browser extension is linked to your account can carry such a download link, at most once in ten days per account. Your AI client's provider sees it as part of the reply. When the link carries a handoff, it works once, for at most 15 minutes, and in any other browser it links only after a click on the extension's prompt. That prompt does not show the email address of an email account that only the link names: it says the account comes from a download link. You can unlink it at any time from the extension popup, which deletes the link on the server as well. If Research Connect cannot be reached at that moment, the extension forgets the link anyway, and the link on our side ends when it expires, 30 days after the extension last used it.
• Anyone who holds a download link can use it: opened in their own browser, it lets them link that browser to the account with one click on the extension's prompt. From then on the extension in that browser can receive the account's article requests, and its popup shows the account: for an email account its address, and for a code account its account code, its dashboard, which opens with no password, and the deletion of the account; for an email account the popup can also pause the history. A program that opens the link before you do, such as a link preview, can use it up, because opening it is what spends it. The page then shows as the plain download page, and the next reply that missed full text, after the ten days, carries a new link.
• Before it is linked, each time you open its popup, and when you press "Link this browser" on one of our pages, the extension asks Research Connect which account this browser belongs to. The browser attaches Research Connect's own cookies to that request, as it does for any page of ours. They are our cookies only, never a publisher's, and the extension cannot read them. The account code you type, and the confirm of a link offer (the call that makes the link), are sent the same way. A pairing code is sent on its own, with no cookie. When a browser that is linked already links again, that confirm also carries the old link, so that we can remove it. A confirm links the extension to a browser session of your account. If this browser has no live session in that account, the confirm opens a new one, notes this browser's IP address on it, and may set our two cookies for it, but never over cookies that name another account. Its other calls to us, such as the check-in, carry no cookie of ours. Once it is linked, they carry the link. The connection it keeps open is not the same in every browser. It carries the link in a header of its opening request, never in its address. Chrome attaches none of our cookies to that opening request. Firefox may attach all three of them (the one that names your browser session, the one that remembers your account, and the one that checks that a form came from our own page); in our test of Firefox it did. The server reads no cookie on that request, so in Firefox they are sent and ignored.
• On Research Connect's own pages, the extension marks the page with three facts: that it is installed, whether it is linked to the account the page is for, and its version. That is how those pages know not to offer it to you again.
• When your AI client asks for an article that no open route can deliver, the extension opens that one article address in a browser linked to your account (and, when the publisher's article page loads its text from a second address on the same website, as ScienceDirect's does, that address too), using the accounts your browser is already signed in to, and sends the article text to Research Connect, which hands it to your AI client. For a publisher where your institution has a direct sign-in address, it can then open one page of the publisher's website that shows whether you are signed in and, unless that shows you are not, the direct sign-in address, which can reuse a sign-in you already have at your institution. Both addresses it opens are fixed by Research Connect for that publisher, are https addresses on a public host, and, where we know the publisher's domains, stay on them. It only ever reads pages: it submits no forms, types no password, buys nothing, and never bypasses a paywall or a sign-in page. A page that turns out to be a sign-in page, a paywall notice, a page for a different article, or a page that could not be confirmed as the complete article, is discarded, not delivered. If more than one browser is linked to your account, the request can go to the extension in any of them.
• What leaves your browser is the extracted article text, the scheme and host of the address the request ended at (never the path or query, which can carry sign-in tokens), the HTTP status, a label saying whether the page looked like an article, a sign-in page, a paywall, a page for a different article, a page that could not be confirmed as the complete article, or could not be told at all, and the extension version. The label can also say that the page was a robot check. For a page for a different article, it also says whether a sign-in page stood in the way. It also sends whether the page was redirected on the way, the type the website gave the page (its content type), the size in bytes of the text it extracted, and, when the fetch failed, a short error word saying why, such as an address that was not safe to open, a page that was not text, a page that was too large, or a network error. Your passwords and cookies never leave: the browser attaches them to the request itself, and the extension cannot read them.
• To prove a page really is the article you asked for, not just something that looks like one, the extension also sends: the version of the page rules it checked the page with, which publisher's website layout it recognized (or none), the ids of the checks that found the full text, that found the article withheld, or that could not run, whether the page's own DOI matched the one requested, what DOIs the page itself declared, which of the page's own tags carried the DOI, and the number of characters of text it extracted.
• The extension itself keeps a few things in your browser's extension storage, on your device: the link (its token, its id and when it expires), the Research Connect server address the link was made with (a setting), the account's label (for an email account the email, for a code account the words "your code account"), a tag that tells accounts apart, the kind of account, the day it was made, whether the server has refused the link, how often to check in, and, until the browser restarts or the extension is updated, a note that Research Connect refused this version of the extension. Unlinking removes the link, the account details and the check-in interval, and leaves the server address and that note. Choosing a different server address in its options also removes the link and that note. It keeps no article text, no page address and no list of what was fetched.
• Research Connect keeps the link (a hashed token that belongs to one browser session of your account, the extension version, whether it is connected, and timestamps) until it expires or you unlink. The extension's fetches are not tallied. Research Connect's own fetches from a publisher's website, made by our server and not by the extension, are counted by the domain of the address fetched: domain names, counts, and the first and the latest day, never content. Article text is held in the server's memory only long enough to hand it to your AI client, at most a few hours when a document is too large to pass in one piece, and is never written to disk or a database. Linking itself uses one-time tickets, kept only as a hash, each good for one use and for fifteen minutes at most.
• While it is linked, the extension keeps a connection to Research Connect and checks in every few minutes. Each of those tells us the IP address your browser is on now. That is the IP address the first part of this page describes.
• Usage records note that a fetch went through the extension and how it ended. They hold no page text and no address.
• The shared record notes that an article arrived through the extension, and so does the history of an email account. The article's DOI comes from your AI client's request, never from the page. The DOIs the page itself declares are checked against it and reported back to your AI client; they are not stored.
• Everything the extension sends travels over encrypted connections (HTTPS and WSS).
• The Research Connect browser extension's use of information received from your browser complies with the Chrome Web Store User Data Policy, including the Limited Use requirements. That information is used only to deliver the article to the AI client you connected. It is not sold, not used for advertising, and not used for any purpose unrelated to that.