Security

Written for the personwho has to approve it.

What Timefindr requests, what it reads, what it stores and for how long, and how an administrator approves or removes it.

What is requested

Every grant is a standard OAuth 2.0 consent on Google's or Microsoft's own screen. Timefindr asks for the narrowest read-only calendar permission each provider offers, plus what it needs to confirm who consented and to keep the grant alive:

Google · calendar.freebusy

Free/busy intervals through the Calendar freeBusy endpoint. Event content is not available under this scope.

Google · calendar.settings.readonly

The calendar timezone setting, so times are shown in the right zone.

Google · userinfo.email

Confirms that the account that consented is the address the invitation went to.

Microsoft · Calendars.ReadBasic

Calendar events without body, attachments or extensions. Timefindr selects only start, end, all-day, show-as, cancelled and response status.

Microsoft · User.Read

Confirms that the account that consented is the address the invitation went to.

Microsoft · offline_access

Refreshes the read-only token without asking the person to sign in again.

What is read

On Google, Timefindr calls the freeBusy endpoint, which returns opaque busy intervals and nothing else. On Microsoft it calls calendarView with $select=start,end,isAllDay,showAs,isCancelled,responseStatus — never the subject, body, attendees, location or attachments. Reads happen only when the person who invited you runs a search, and only over the window being searched. Nothing is ever written to a calendar: the permission does not allow it.

What is stored

Per grant: the OAuth refresh and access tokens, the email address, the calendar's timezone and the working hours the inviter set. That is all. Calendar data is not stored — busy intervals are read at search time, used to compute open slots, and discarded. Tokens live in Google Cloud Firestore, encrypted at rest, and are readable only by the server; no token is ever sent to a browser or a mobile app. The activity log records that a search ran and who was included, not what was on anyone's calendar.

Who can see what

The person who invited you learns one thing: whether a given block of time is free or busy for you. They cannot see why. Nobody at Timefindr looks at calendars; the internal admin portal shows account and billing status and never exposes tokens or calendar data.

Withdrawing access

Revoke Timefindr from your Google Account permissions or from Microsoft “My apps”. The grant stops working within the hour, the contact is marked not authorized, and the tokens are deleted on the next sweep. The person who invited you can also remove you, which deletes the tokens immediately. Every invitation email carries an unsubscribe link that stops further emails.

For administrators

Microsoft 365: grant tenant-wide admin consent from the approval link on the IT request page, or in Entra ID under Enterprise applications → Consent and permissions. Each person still consents for their own calendar afterwards. Google Workspace: in the Admin console, Security → API controls → Manage third-party app access, add the client ID shown on the IT request page and mark it trusted. Organization-wide grants for companies that adopt Timefindr as a team use Calendars.ReadBasic.All on Microsoft and a domain-wide-delegated service account with the same two Google scopes; they are enabled only by the customer's administrator.

Infrastructure

The applications run on Vercel (United States). Data is stored in Google Cloud Firestore. Billing is handled by Stripe; card details never touch Timefindr. Email is sent through DreamHost SMTP over TLS. The formal documents are the privacy policy and terms of service.

Need something in writing for a review?

Ask us. We will answer a security questionnaire or sign a data processing agreement.

Get in touch