privacy

1. who operates this tool

Atlas Email Briefing is built and operated by Matthew Krueger, working as studio / 26. it is a private tool and i am its sole operator. it is configured and operated only for my own business mailbox. it is not a public service: it has no public sign-up and no public user-facing authorisation flow.

2. what it is for

i run a photography and creative production business. Atlas Email Briefing reads my own Gmail mailbox on a schedule, identifies which recent messages are commercially relevant — enquiries, bookings, production logistics, client follow-ups — and prepares a written briefing and a set of reviewable proposals. i read that briefing and decide what to do. the tool takes no action on my behalf and sends nothing.

3. what Google account data is accessed

when a run happens, the tool reads the following from my Gmail mailbox and nothing else:

• message identifiers, thread identifiers and Gmail label identifiers
• message timestamps
• the short message snippet Gmail returns
• the header values From, To, Subject, Date, Reply-To and Authentication-Results
• the message body text (an html-only message is converted to plain text)
• attachment metadata only — filename, media type and size in bytes

attachment contents are never downloaded. spam and trash are excluded from every search. each run is bounded to a recent time window and to a fixed maximum number of messages, with a further cap on how many messages are read from any one conversation thread.

4. the permission requested

exactly one Google permission is requested: https://www.googleapis.com/auth/gmail.readonly. this is Gmail's read-only scope, and it is the only scope named anywhere in the source code. no Drive, Calendar, Contacts or profile scope is requested.

three Gmail methods are called: users.messages.list, users.messages.get and users.threads.get. all three are reads. no send, modify, batch-modify, trash, untrash, delete, insert, import, drafts or attachment-download method is called anywhere in the code, and the internal interface the tool depends on exposes no such method to call. it cannot send, reply to, modify, label, archive, mark as read, or delete a message.

5. how Gmail-derived information is used

all processing happens locally on my computer. classification and extraction are deterministic and rule-based — no AI model, no language model service and no third-party processor is involved. from the messages it reads, the tool produces:

• a written briefing for me to read
• structured proposals describing a possible piece of work: the subject line, message and thread identifiers, the people in the conversation (name, email address, and role or company where they declared one), extracted facts, noted gaps, and any commitment i appear to have made
• a local dashboard page summarising the same information
• suggested reply text for me to read and decide on — nothing is ever sent

the structured proposals are assembled field by field, and deliberately exclude raw message bodies, quoted reply history, full recipient lists, credentials and attachment content.

i should be plain about one thing: some extracted values are free text taken from the message itself. so a stored fact, a participant record or a subject line can contain a person's name, email address or other contact detail that appeared in the correspondence. the mailbox is identified in these files by an opaque key rather than by an email address, and the code rejects a key that is an email address or my own address — but i do not claim that my address, or a correspondent's, is removed from everything the tool writes.

6. where information and credentials are stored

everything the tool produces is written to the local filesystem of my own computer, inside the project directory:

• briefings, structured proposals and dashboard files are written under a generated output directory
• a small index file records only stable keys and generated identifiers, so that the same conversation keeps the same identifier between runs — it holds no message bodies, subjects, credentials or extracted facts
• the Google OAuth refresh token is written to a local secrets file with file permissions set to owner-read-and-write only

these directories are excluded from version control, so no message content and no credential is committed to the code repository. the Google client identifier and secret are read from a local environment file that is also excluded from version control. token and credential values are never printed or written to logs, and configuration error messages are written so that they do not echo the value.

7. transfers and sharing

as its operator: i do not sell this information, i do not use it for advertising or profiling, and i do not intentionally disclose it to another person. as a matter of what the code does: the Gmail briefing path provides no sharing, upload or external export mechanism for Gmail-derived information.

during authorisation and routine operation, the Gmail briefing path communicates with Google's OAuth services and the Gmail API. the Gmail-derived outputs of that path — the briefing, the structured proposals and the dashboard files — are written to local disk. the Gmail briefing path contains no call that transmits Gmail-derived information to Atlas, Notion, a database, an analytics service, a webhook, an upload service or another third party.

two of those local files carry the name of another system: the structured proposals are named for a separate Atlas project of mine, and one dashboard file is a copyable to-do list named for Notion. both are ordinary files written to local disk. the Gmail briefing path holds no Atlas client and no Notion client, and makes no call to either.

during the one-time authorisation step a short-lived web server runs on the loopback address 127.0.0.1 solely to receive the redirect back from Google. it is not reachable from outside the machine and it is shut down as soon as the code is received.

8. retention and deletion

i want to be accurate rather than reassuring here: the tool defines no retention period. there is no code that expires, prunes or automatically deletes anything it has written. the briefings, proposals and dashboard files it generates stay on my computer until i delete them myself, which i can do at any time by deleting the generated output and state directories. deleting them does not affect Gmail — nothing in the mailbox is ever changed or removed.

deleting the local token file removes this computer's stored credential, so a later run cannot authenticate until the tool is authorised again. it does not by itself withdraw the grant held at Google — see section 10.

9. security practices

the practices below are the ones actually implemented in the code. i make no claim of certification, external audit, or a guarantee of security.

• read-only access only, with no code path that can change the mailbox
• authorisation uses Google's installed-application flow with PKCE (S256) and a loopback redirect on an operating-system-assigned port
• the refresh token is stored with owner-only file permissions and is excluded from version control
• credentials are never printed, logged or included in generated output
• each run is bounded by time window and message count, so it reads no more than it needs
• generated information, credentials and tokens are stored under my own local operating-system account, and are excluded from version control

10. control, revocation and deletion requests

access is granted by the Google account owner and stays under that owner's control. there are two separate actions available, and they do not have the same effect:

• revoking access at https://myaccount.google.com/permissions withdraws the OAuth grant itself, at Google. once the grant is withdrawn, the stored credential no longer authorises access to the mailbox.
• deleting the local token file removes the stored credential from my computer, so a subsequent scheduled or manual run cannot authenticate unless the tool is authorised again. it does not, by itself, revoke the grant held at Google.

withdrawing the grant at Google is the action that ends the authorisation. deleting the local file only removes this computer's copy of the credential.

if you have corresponded with me by email and want to know whether your message was processed, or want the information derived from it deleted, write to matthewkruegerphoto@gmail.com and i will deal with it directly.

11. children

this tool is not directed to children and has no public sign-up. the only account it is configured to connect to is my own business mailbox.

12. changes to this policy

if what the tool accesses, produces, stores or shares changes, i update this page before the change takes effect and revise the effective date above.

13. contact

privacy questions and requests: matthewkruegerphoto@gmail.com