Privacy

Effective September 25, 2026. Last updated September 25, 2026.

Recent change (September 25, 2026): nothing about what Booklister does has changed, but this page now describes it more completely. It names two services it left out: GitHub, which hosts the site and logs visitor IP addresses for security, and placehold.co, which serves the gray placeholder images on empty title slots. It names Tavily, the web search service the Magic button uses on the branded instances that have it. It also corrects how staying signed in works on branded instances (no cookie is involved) and notes that the Booklister Helper extension's two settings travel with your browser's sync if you have it on.

Booklister is a free tool for making printable library booklists. It's a side project run by one person, and it collects as little about you as I could get away with while still making the tool work. This page explains what happens with your data.

The short version

If you're using the public tool at booklister.org, nothing about your work leaves your browser. There are no accounts, no sign-in, and no server that stores your booklists. Your drafts live in your browser's local storage and go away when you clear site data. The public site does count page views through a cookieless analytics service, described in the Analytics section below; it can tell me that a page was visited, not who visited it.

If you're using a branded library instance at a subdomain like libraryname.booklister.org, you sign in with an email and password, and that sign-in information is stored in Firebase (a Google service). Your actual booklist work still stays in your browser, and the analytics described below don't run on branded instances at all.

If you've also installed the Booklister Helper browser extension, the extension doesn't send anything to me or to any server I control. It only runs on BiblioCommons library catalog pages, makes the same network calls the catalog page itself already makes, and writes the captured row straight to your clipboard.

What stays on your device

Booklister autosaves your work in progress (the titles you've added, your styling choices, the current state of the tool) to your browser's IndexedDB storage. This never leaves your computer. It's there so you don't lose work if you reload the page.

The tool also keeps a few small preferences in your browser's local storage: whether Folio the cat is shown, a count of your visits and the date of the last one (so Folio can say "welcome back"), your choice on the auto-draft toggle, and whether you've already seen a couple of one-time messages. These never leave your browser either.

You can clear it by clicking the Reset button in the tool, by using the delete buttons on individual uploads, or by clearing site data for booklister.org in your browser settings.

The tool can also save your work as a .booklist file via the Save button. That file is downloaded to your computer; I never see it.

What gets sent to external services when you use the tool

A few actions in the tool reach out to external services on your behalf. These only happen when you do something specific:

• Searching for titles. Running a search sends your query to the Open Library API, which returns title metadata and cover images. Open Library is an Internet Archive project, and their privacy policy governs how they handle search queries.
• Loading the tool itself. The site is hosted on GitHub Pages, so GitHub serves every page and file, and GitHub logs visitors' IP addresses for security purposes under its own privacy statement. I don't see those logs. Booklister also loads fonts, icons, and a few JavaScript libraries from public content delivery networks (Google Fonts, cdnjs, gstatic), and the gray placeholder images shown where a title has no cover yet come from placehold.co. These services will see your IP address and browser as part of delivering those files. None of them are used for analytics or tracking by me; the one thing on the site that does count visits is described under Analytics below.
• Pasting cover links. If a spreadsheet you paste into Quick Add includes links to cover images, your browser loads each image from wherever that link points, and that site sees the request. Covers captured by the Booklister Helper extension are embedded in the paste itself, so they don't trigger any request.
• Drafting a description with the Magic button. This feature is not part of the free public tool at booklister.org, so nothing described in this bullet ever happens there. It exists only on branded library instances that have asked for the feature and that I've approved for it, and it's off by default even there. Asking is not a guarantee: I decide case by case whether to enable it, I expect to say yes only rarely, and I can turn it off again at any time (see the Terms for the full gating policy). When a staff member clicks the wand icon on a title, the title and author of that title are sent to a Google Apps Script endpoint I operate, which sends them to Tavily, a web search service, to gather information about the title. The title, the author, and what Tavily found then go to a third-party large-language-model service, which drafts a short description from that material. If the staff member shift-clicked the wand and pasted a summary (or the instance is configured in source-text mode), the pasted text is also sent, the drafter condenses it, and no web search is run: Tavily is never contacted. The request also includes a few drafter tuning knobs (target word count, temperature, retry counts) from the tool's configuration; those values aren't tied to the staff member or the library. Nothing else about the title, the booklist, the library, or the staff member is sent. Those providers see only what the Apps Script forwards.

Analytics

The public site at booklister.org uses Cloudflare Web Analytics to count page views. I added it because I had genuinely no idea whether anyone was using this thing, and I'd rather know that than guess. It is the only analytics on the site.

What it records, per page view:

• The page you loaded and the referring page, if any (so I can tell whether people arrive from a search engine, a library newsletter, or a link somewhere).
• Your browser, operating system, and device type, at the level of "Firefox on Windows, desktop."
• The country you're in. Not your city, not your address, not your IP.
• How long the page took to load.

What it does not do:

• No cookies. It sets none, and it writes nothing to your browser's local storage.
• No fingerprinting and no visitor ID. It doesn't build a device fingerprint or assign you an identifier, which means it can't tell that today's visit and last week's visit came from the same person.
• No cross-site tracking. It has no way to see anything you do on any other website, and it isn't used to build an advertising profile.
• No IP address stored. Cloudflare uses your IP in the moment to work out which country the visit came from, then discards it. It isn't retained, it isn't shown to me, and I have no way to retrieve it.
• Nothing about your booklist. The titles you add, the text you type, the images you upload, and the files you export are not visible to the analytics and never leave your browser. That part of this policy hasn't changed.

I see aggregate numbers only: how many views a page got, roughly where visitors were, what browsers they used. There is no screen anywhere that shows me an individual person's activity, because the data to build one is never collected.

It doesn't run on branded library instances. The analytics script checks the domain before it loads anything, and it only runs on booklister.org. On a library subdomain like libraryname.booklister.org it does nothing at all, and no request to Cloudflare is ever made. Library staff sessions are not counted, not measured, and not visible to me in any form.

If you'd rather not be counted. Many content blockers already block the analytics script, and blocking it breaks nothing: every feature of the tool works exactly the same without it. You don't need to tell me, and I have no way to know you did it.

What branded library instances store on Firebase

If you're signing into a branded library instance (like libraryname.booklister.org), here's what ends up in Firebase:

• Your account. An email address (as the login identifier) and your password. Firebase Authentication handles the password, which means I never see it in plain text; it's hashed before it's stored.
• Your membership. A small record linking your account to the library you have access to, whether your role is 'staff' or 'admin', and a copy of your email address so the admin console can show who each record belongs to. That role determines what you can do within your library through the admin console.
• The library's configuration. The library's display name, the path to its logo image, and a few settings for the Magic button (whether it's on, and how it behaves). This is per-library, not per-user.

I don't store anything else about you in Firebase. No booklist content, no search history, no usage analytics, no telemetry. The booklist work you do on a branded instance still stays in your browser, same as the public tool. As noted under Analytics, the page-view counter on the public site is switched off entirely on branded instances, so nothing about your library's day-to-day use of the tool is measured anywhere.

Booklister Helper browser extension

The Booklister Helper is a separate, optional browser extension you can install from the Chrome Web Store, Firefox Add-ons, or Microsoft Edge Add-ons. It runs only on BiblioCommons library catalog pages. When you click it on a catalog page, it copies the title, author, call number, and cover image to your clipboard so you can paste them into Booklister. That is the entire extent of what it does.

I do not log, capture, or otherwise observe what you capture, when you capture it, or that you used the extension at all. Nothing about your use of the extension is sent to me, to Booklister, or to any server I operate. The extension stores two small settings (your preferred branch, if you typed one, and whether list-building mode is on) using your browser's extension storage. If you're signed in to your browser with sync turned on, your browser can carry those two settings to your other signed-in devices through its own sync service (your Google account in Chrome, for example, or your Mozilla account in Firefox when add-on sync is on). While list-building mode is on, the rows you've captured are kept on your computer only. None of it is sent to me.

Data retention

While your library has an active Booklister instance, your account, membership, and library config are retained. When a staff member is removed from a library, their membership record is deleted immediately, which removes their access. Their Firebase Auth account (which no longer has permission to read any library data after the membership is removed) is cleaned up during a periodic audit, or sooner on request. When a library ends its Booklister relationship, all associated data is deleted within one business day of confirmation.

Who has access to this data

Administrative access to the Booklister Firebase project is tightly restricted, currently to me alone as the project's operator. I use that access to create new library instances, to onboard new library staff, and to help diagnose problems when something goes wrong. I don't browse or export user data for any other purpose. If that ever changes, for example if I add a second administrator, I'll update this page to reflect it.

Library admins at each library (typically one staff member per library) can see the list of user IDs and email addresses for other staff at their library, because they manage the roster. They can't see any other library's data and they can't see your booklist content. Library admins also cannot modify any other library's data and cannot elevate other staff to admin status. Actions like creating new libraries or changing someone's role to admin require the project operator.

Google, as the operator of Firebase, has access to the underlying data the same way any cloud provider does. Their own privacy and security practices apply.

Cookies and tracking

Booklister doesn't set tracking cookies and doesn't build a profile of your activity. The page-view counter described under Analytics is cookieless: it stores nothing in your browser, assigns you no identifier, and can't recognize a returning visitor. On branded instances, Firebase Authentication keeps a sign-in token in your browser's local storage so you stay signed in across page reloads; it doesn't set a cookie. Apart from that token, your draft, and the small preferences listed under "What stays on your device," Booklister keeps nothing in your browser. No Google Analytics, no Facebook pixel, no advertising network, and no cross-site tracking of any kind.

Booklister does not embed advertising pixels or other tracking technologies that would allow third parties to collect personally identifiable information about your activity across websites or online services over time. The one analytics script on the site is limited to counting page views on booklister.org, collects no personally identifiable information, and has no visibility into anything you do on any other website.

Do Not Track

Your browser may send a Do Not Track (DNT) signal when you visit websites. Booklister doesn't change its behavior in response to that signal, and I want to be straightforward about why rather than imply otherwise: the page-view counter described under Analytics runs the same way whether or not DNT is set, because Cloudflare Web Analytics doesn't read the signal.

What DNT is meant to protect against is the thing that isn't happening here. There are no tracking cookies to refuse, no identifier tying your visits together, and no profile of your activity being built, with or without the signal. If you'd still rather not be counted, a content blocker will stop the script and nothing in the tool will break; see the last paragraph of the Analytics section.

What you can do

• Stop using the tool. Nothing happens to your local draft. It stays on your device until you clear it.
• Review what's on file. If you have a branded-instance account and want to know exactly what Booklister has stored about you, email me via the Contact page and I'll tell you.
• Audit your library's staff roster. If you're a library admin, you can see the full list of staff at your library at any time by signing in to the admin console. This is the authoritative list of who has access to your instance.
• Correct information. If the email or other information associated with your account is wrong, email me from the Contact page and I'll fix it manually.
• Export your work. Use the Save button in the tool to download a .booklist file of your current session.
• Delete your account. If you have a branded-instance account and want it removed, email me from the Contact page. I'll delete your Firebase Auth account and any memberships linked to it. This is a manual process; there's no self-service account deletion button in the tool yet.
• Request full library instance removal. If a library wants to end its Booklister relationship entirely, the library's point of contact should email me from the Contact page. I'll delete the library's Firestore configuration, remove all staff memberships tied to that library, and purge the library's branding assets from the project. Like account deletion, this is a manual process I handle personally; there's no self-service button in the tool.
• Ask me anything. If something here is unclear, email me from the Contact page.

Changes to this page

If I add another data-collection feature (error reporting, anything like that), I'll update this page and revise the "Effective" and "Last updated" dates at the top, the same way I did when the page-view counter was added. Material changes get a visible note on this page for at least one month after the update.

Applicable law

Booklister is operated by a private individual in the United States. It's a small project, not an institutional service. If you're accessing it from a jurisdiction with specific data protection requirements (EU, California, and others) and you have concerns about how that applies here, email me from the Contact page and I'll do my best to address them.

Booklister is operated from California. The California Consumer Privacy Act (CCPA) is written for for-profit businesses above certain size thresholds, and a free, one-person project doesn't fit that description, but I honor the rights it describes anyway. The free public tool at booklister.org holds no accounts and stores none of your work on any server. The only data I receive from it is the aggregate, cookieless page-view counting described under Analytics, which is not tied to an identifier, not tied to you, and not capable of being traced back to an individual, so there is no personal information for me to look up, correct, or delete on the public tool. Personal information collection only happens on branded library instances, and even then it is limited to staff email addresses and Firebase user IDs. You can request access, correction, or deletion of that information by emailing me from the Contact page, and I'll respond within a reasonable timeframe. Booklister does not sell or share personal information, and never has.