← Snug

Privacy

Last updated 13 October 2026

Snug is a small tool for laying out your week. It is built to hold as little about you as it can and still work. There is no analytics, no advertising, no tracking pixel and no third party we sell anything to, because there is nothing to sell and no one to sell it to.

What Snug stores about you

Signed out, nothing leaves your browser. Signed in, Snug keeps:

• An account identifier from Auth0, which is how Snug recognises you between visits, and your email address if Auth0 supplies one.
• Your plan: the hobbies you typed, and where you put them on the week, month, quarter and year.
• A calendar connection, if you make one: which Google or Outlook calendar to write to, and an encrypted token that lets Snug write to it. The token is encrypted before it reaches the database, so a copy of the database alone cannot reach your calendar.
• A calendar link, if you make one for Apple Calendar or another calendar app: a private address that serves the weeks you sync. Snug keeps a one-way hash of it, to recognise it when your calendar app asks, and an encrypted copy, so it can show it to you again.
• A record of what Snug wrote: the identifiers of the calendar events it created, and a copy of each one as it was sent: its title, day and time. The identifiers are what let Snug remove its own events on the next sync and never touch anything you made yourself; the copy is what shows you a past week on the Your weeks page, since your plan will have changed since.
• Your reflections, if you write any: what you wrote about a past week. They are encrypted before they reach the database, the same way as the calendar token, and are never used for anything but showing them back to you.

That is the whole list. Snug does not read your existing calendar, does not store your contacts, and never sees your password. Signing in happens on Auth0, not here.

Google user data Snug accesses

Snug touches your Google account only if you connect a calendar, and only through the Google Calendar API. This is the complete list of Google user data it accesses, and what each piece is for:

• A Google OAuth refresh token and the short-lived access tokens it produces. Issued by Google when you connect. This is what lets Snug write next week’s plan without you being present.
• The identifier of one calendar in your account: either the calendar Snug created for itself, or the literal value primary if you asked Snug to write to your main calendar. Snug stores this so it writes to the same place every week.
• Calendar events Snug itself creates, and the event identifiers Google returns for them. Each event holds the name of a hobby you typed and the time you put it at. Snug keeps the identifiers so it can remove its own events on the next sync and never touch anything you made yourself.
• A calendar Snug creates, named “Snug”, if you chose a separate calendar rather than your main one.
• Your email address and a Google account identifier, but only if you choose Google as your sign-in method. Sign-in is handled by Auth0, which passes Snug the email address and identifier from whichever provider you used; if that provider is Google, those two fields originate from your Google account. Snug uses them to recognise you between visits and to reach you about your account.

That is all of it. Snug does not read the events already in your calendar, does not list your other calendars, and does not access your Google contacts, Gmail, Drive, photos, location or profile picture. It never sees your Google password. You type that at Google, not here.

Snug asks for the narrowest scope that does the job. If you let Snug keep its own calendar it requests calendar.app.created, which reaches only calendars Snug itself created, so everything else in your account is structurally invisible to it. If you ask Snug to write to your main calendar instead it requests calendar.events, because writing there is not otherwise possible. Snug requests no other Google scopes.

How Snug uses and shares it

Snug’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In plain terms: Snug uses your Google Calendar data only to write and tidy the plan you asked it to write. It is not used for advertising. It is not sold, and it is not transferred to anyone except Google itself and the service providers listed below that are needed to run the app. It is not used to train any model, human or otherwise, and no human at Snug reads it except in the narrow case where you ask for support and we cannot help without looking.

You can withdraw Snug’s access at any time with Disconnect in the sync panel, from your Google account permissions, or by deleting your Snug account. Disconnecting or deleting hands the token back to Google automatically, and Disconnect can also remove the events Snug wrote, if you ask it to.

Microsoft (Outlook) data Snug accesses

Snug touches your Microsoft account only if you connect Outlook, and only through Microsoft Graph’s calendar endpoints. It holds the same kinds of things as for Google, and uses them the same way: a refresh token and the short-lived access tokens it produces, encrypted the same way; the identifier of the one calendar it writes to (a calendar named “Snug” it creates, or your default calendar if you choose that); and the events it creates there, with the identifiers Outlook returns, so it can remove only its own events on the next sync.

Microsoft offers no permission as narrow as Google’s “only calendars this app made”, so Snug requests Calendars.ReadWrite (the narrowest that can write a calendar at all) and offline_access, so it can write next week without you being present. What Snug does with that access is unchanged by its breadth: it does not read the events already in your calendars, does not list or open your other calendars, and does not touch your mail, contacts, files or profile. It is used only to write and tidy the plan you asked it to write, never for advertising, never sold, and never used to train any model.

Microsoft does not offer apps a way to hand back a single connection, so Disconnect in the sync panel deletes Snug’s copy of the token and stops all access from Snug’s side. To remove Snug from your account’s list as well, use your Microsoft account’s app permissions (or My Apps for a work or school account).

Who else is involved

Snug is a small app standing on other people’s services:

• Auth0 (Okta): handles signing in. They see your email address and when you sign in.
• Neon: hosts the database your plan lives in.
• Vercel: hosts the site and runs its server code. They process request logs, including IP addresses.
• Google: only if you connect a calendar, and only then, as described above.
• Microsoft: only if you connect Outlook, and only then, as described above.
• Apple, or whichever calendar app you subscribe with: only if you make a calendar link. Your calendar app, and for iCloud calendars Apple’s servers, fetch the link from time to time and so receive the titles, days and times of the weeks you synced. Snug sends them nothing else and receives nothing back.
• Google Fonts: three typefaces load from Google’s servers on every page, which means Google receives your IP address as part of that request.
• PartyKit: only on the community garden page, which keeps its shared state on a server we do not run. The garden holds no names and no text: you can place a plant and water one, and nothing else.

How sensitive data is protected

The most sensitive things Snug holds are your Google refresh token (a standing key to a calendar) and anything you write in a reflection, so both get specific protection rather than general good intentions. The points below are described for the token; reflections are encrypted with the same cipher and key, are likewise never logged, and are decrypted only to be shown to you:

• Encrypted in transit. Every connection to Snug, and every call Snug makes to Google, runs over HTTPS with TLS. There is no plaintext path.
• Encrypted before storage, by the application. The refresh token is encrypted with AES-256-GCM, an authenticated cipher, so tampering is detected and not merely undecryptable, before it is ever sent to the database. Each token gets its own random 96-bit nonce. The 256-bit key lives in the server’s secret configuration, never in the database and never in the source code, so a copy of the database alone cannot reach anyone’s calendar.
• Encrypted at rest underneath that. The database is hosted by Neon, which encrypts stored data at rest, and reached only over TLS. Application-layer encryption sits on top of that, not instead of it.
• Never written to logs. Tokens are not logged, not included in error reports, and never sent to the browser. The token is decrypted in memory only for the moment a sync needs it, and no access token is stored at all.
• Access is checked on every request. Every API call must carry a valid Auth0-issued token, verified against Auth0’s published signing keys, and each request can reach only the rows belonging to that account. There is no shared or ambient access to other people’s data.
• The connect flow is signed. The OAuth state carrying who began the flow is signed with HMAC-SHA256, compared in constant time, and expires, so a calendar cannot be attached to someone else’s account by a forged redirect.
• Least privilege. Snug holds the narrowest Google scope that does the job, as described above, and keeps one credential rather than many.
• Handed back on deletion. Deleting your account revokes the token with Google and removes the encrypted copy, so access ends rather than merely going unused.

Server secrets (the encryption key, database credentials and Google client secret) are held as encrypted environment variables at Vercel, available only to the running server code and to the one person who administers the project.

No system is perfect, and Snug is a small one. If you find a weakness in it, please email the address at the bottom of this page rather than anyone else, and it will be taken seriously.

Your calendar link

A calendar link is how Apple Calendar and other calendar apps subscribe to Snug without a password, and like any subscription link it is a key: anyone who has it can see the titles, days and times of the weeks you have synced, and nothing else: not your plan, not your reflections, not your account. It is 256 random bits, so it cannot be guessed, only shared. Snug stores only a SHA-256 hash of it, to look it up, and a copy encrypted the same way as the calendar token, to show it back to you. Making a new link in the sync panel stops the old one working at once, and turning it off stops it altogether.

How long it is kept

Your plan, your calendar connection and calendar link, the record of your synced weeks and your reflections are kept until you delete them or delete your account. Clearing a reflection deletes it. Nothing is archived afterwards and there is no backup copy kept for later. Deletion is deletion.

Deleting your data

The account menu in the app has Delete my account. It removes your plan, your synced weeks and reflections, your calendar connection and calendar link, and the account record itself, immediately and for good, and it revokes Snug’s access to your Google calendar on the way out. Calendar events Snug already wrote stay in your calendar; they are yours, and you can delete them there.

You can also email snug.planner@gmail.com and ask for a copy of what Snug holds about you, or for it to be deleted, and that will be done.

Children

Snug is not aimed at children and is not designed for them. Please do not use it if you are under 16. Nothing here knowingly collects anything from a child, and if you believe a child has an account, email the address above and it will be removed.

Changes

If this policy changes in a way that affects what Snug does with your data, the date at the top of this page changes with it.

Contact

snug.planner@gmail.com.