Privacy Policy

Napper is a private assistant with a single user: Paul Bennett. It reads his own accounts, stores what it reads in his own infrastructure, and shows it to nobody else. This policy explains exactly what that means.

1. Who this applies to

Napper has exactly one user, Paul Bennett, and operates only on accounts he owns or has been granted access to. There is no sign-up, no account creation, no invitation mechanism, and no way for another person to connect their own accounts. If you are reading this because you are evaluating Napper for Google API access: it is a personal tool, not a service offered to the public.

Napper is operated by Paul Bennett as an individual. It is not a company and has no employees or contractors with access to its data.

2. What data Napper accesses

Google account data

With Paul's explicit authorisation, Napper accesses the following from his own Google accounts:

Napper requests the narrowest scope that accomplishes each purpose. It does not request permission to delete mail.

One of these scopes is broader than its purpose, and it is worth being precise about. Gmail has no permission that allows changing a message's labels but forbids sending, so gmail.modify — granted so that dismissing a message can archive it — also technically permits sending mail. The same is true of gmail.compose, which is granted for drafts.

Napper does not send mail, and the reason is not the permission. It is that no code capable of sending exists anywhere in the application: there is no send function, no wrapper around one, and none behind a feature flag or in a test. An automated check runs on every change and fails the build if such a call path appears. That check, not the scope, is the guarantee — and it is the same guarantee described in the commitments below.

Other data

Napper also reads, from accounts Paul owns:

• Accounting and CRM records from Zoho, read-only, for two organisations he is involved in.
• Commit metadata from GitHub repositories he works on, read-only, to attribute working time.
• Publicly available web pages and RSS feeds, for the research topics he tracks.

Data about other people

Mail and calendar entries necessarily contain information about the people Paul corresponds with — names, email addresses, and whatever they wrote to him. Napper processes that information only to produce Paul's own brief and drafts. It is never used to build profiles for sale, never shared with anyone, never used for advertising, and never used to contact anyone.

3. Google API Services User Data Policy

In particular, data obtained from Google APIs is used only to provide the features described on this site, is not transferred to any third party except as strictly necessary to operate the application (see section 5), is never used for advertising, and is never sold. No human other than Paul Bennett reads it, except where required by law.

4. Where data is stored

Data Napper reads is stored in a private PostgreSQL database hosted by Supabase in the United States (us-east-1), accessible only with credentials held by Paul. Processing runs on a private service hosted by Railway. The review dashboard is hosted on Vercel and requires authentication; it is not publicly accessible.

Credentials for connected accounts are held as environment variables in those hosting environments. They are never committed to source control.

5. Service providers

Napper relies on a small number of infrastructure providers. Each processes data only to provide its service, under its own terms:

• Supabase — database hosting.
• Railway — runs the background processing service.
• Vercel — hosts the dashboard and this website.
• Anthropic — message text is sent to the Claude API to classify it and to write summaries and draft replies. This is the only external processing of message content, and it exists because classification is the core function of the application.

No data is shared with any other party. Napper contains no analytics, no advertising, no tracking pixels, and no third-party scripts beyond the web fonts used on this page.

6. How long data is kept

Napper is an ongoing personal record, so data it has read is retained for as long as the application is in use. Corrections Paul makes to its classifications are retained deliberately and indefinitely, because they are what teaches it to sort his mail correctly.

Paul can delete any or all of it at any time, and the entire database is deleted if the application is decommissioned. Deleting data in Napper does not delete the original message in Gmail, and deleting a message in Gmail does not automatically remove a copy already stored in Napper.

7. What Napper never does

• It never sends email. No send function is implemented, and a build check fails if one is added. Two of the Google permissions it holds would technically allow sending; the absent code is what prevents it.
• It never deletes mail, calendar entries, or files.
• It never posts to any service on Paul's behalf.
• It never sells, rents, or shares data for advertising or marketing.
• It never grants any other person access to the data it holds.
• It takes no action that Paul has not explicitly approved.

8. Security

Access to the database requires credentials held only by Paul. The dashboard requires authentication. All connections to Google, Zoho, GitHub, Supabase, and Anthropic use HTTPS. Every action the application attempts — including every action it refuses to take — is recorded in an audit log.

No system is perfectly secure. If a breach affected data belonging to people who corresponded with Paul, he would notify those affected where he could reasonably identify and reach them.

9. Your rights

If you have corresponded with Paul and want to know what Napper holds about you, or want it removed, write to paul@cicerolearning.com and he will tell you, or delete it, as you prefer. Because Napper holds only his own mailboxes, this is a manual request handled by one person, not an automated portal.

10. Children

Napper is a private tool used by one adult. It is not directed at children and has no users other than its owner.

11. Changes to this policy

This policy forms part of the Napper terms and conditions.

If Napper's data handling changes — for example if it requests an additional Google permission — this policy is updated before that change takes effect, and the "last updated" date above changes with it.

12. Contact

Paul Bennett — paul@cicerolearning.com
About Napper · Terms & conditions · thepaulbennett.com