Security, privacy and accessibility
The boring page. Written to be forwarded.
You hold your clients' tax file numbers. Somebody in your firm — a partner, an auditor, a client's IT person — is going to ask what a scheduler can see. This page exists so the answer is a link rather than a meeting.
Where it lives
In Australia, and encrypted.
The database and all backups are hosted in Australia, on encrypted storage, and nothing is replicated to another region. If that ever changes we will tell every practice before it happens, not in a changelog afterwards.
One copy does leave, and it is the copy you asked for: the appointment we write into your staff member's Google or Microsoft calendar lives wherever their tenant lives. That is the calendar they already work in, under your firm's own agreement with Google or Microsoft, and it carries the client's name and the time — the same entry your staff member would have typed.
On top of that, three things are encrypted a second time in the application with AES-256-GCM, under a key held separately from the database: your staff's calendar refresh tokens, and every client email address and mobile number. Somebody holding a copy of the database alone has none of the three. Client names are held in the clear inside it, because matching a returning client is done on them.
Everything in transit is TLS. The booking widget makes no request to any origin except ours, which is what lets it survive a strict content security policy on your website.
We never take a payment from your client, so there is no card number in our system to lose. That is a security decision as much as a commercial one.
Calendar access
Exactly what we ask your staff for.
These are the literal permission strings shown on the Google and Microsoft consent screens. We would rather print them than paraphrase them.
.../auth/calendar.calendarlist.readonly
.../auth/calendar.freebusy
.../auth/calendar.events
offline_access
Calendars.ReadWrite
Microsoft has a second way in, and it is broader
Nine accountants each completing an OAuth flow is nine chances for one of them not to. So a Microsoft 365 firm can instead have an IT administrator consent once, for the whole tenant, after which we reach each staff member's calendar with an application permission rather than with a token that person handed us individually.
Be clear-eyed about what that grants. At the Microsoft end it is Calendars.ReadWrite across every mailbox in the tenant, not only the people you put on the booking page. We read the calendars of the staff you have made bookable and we store only the row printed below — but the permission itself is tenant-wide, and an administrator signing it off should be told that here rather than infer it from a consent dialog.
The per-staff route above is always available instead, and it is the right one for a firm whose administrator would rather not. Google has no equivalent: Google is per-person, always.
What we use them for
- Reading free/busy across every calendar a staff member connects
- Creating, moving and cancelling the appointments booked through us
- Telling a "free"-marked event apart from one that should block a slot
- Recognising the events we created ourselves, so we never double-count them
- Holding a sync token, so we are told about changes instead of polling all day
What we never access
- Email — no mailbox scope is requested on either provider
- Contacts, address books or directories
- Drive, OneDrive, SharePoint or any file at all
- On the per-staff route, any calendar that staff member did not connect
- The title, attendees, body or location of any event — read, then discarded
The broad one, and why we ask for it
calendar.events and Calendars.ReadWrite are the two that matter, and they are genuinely broad — they permit reading and writing events in that person's calendar. We are not going to pretend otherwise.
We ask for them because free/busy alone cannot run a booking product: it cannot tell us whether an event is marked "free", cannot tell us which events are ours, and gives us no sync token. What we do with that access is the list above — and what we keep from it is the list below.
What we keep from it
For every event we read from a staff calendar, the row we store contains a time range, which calendar it came from, the provider's event identifier, whether it was marked busy or free, and whether we created it.
There is no column for the title. None for the attendees, the body, the location or the conferencing link. Your staff member's 2:00pm titled "Reference check — Sarah" is, to us, a busy interval from 14:00 to 15:00.
transparency busy
is_own_booking false
external_event_id opaque provider id
calendar_id which of their calendars
connection_id which connection
staff_id whose diary
fetched_at when we last looked
title — no column
attendees — no column
body, location — no column
Access is revocable at the source. A staff member can withdraw ours from their own Google or Microsoft account security page without asking us, and the next call we make fails; a tenant-wide consent is withdrawn the same way, by the administrator who gave it. Ask us and we will remove the connection at our end as well. Either way the appointments that already exist stay where they are — those are your clients' appointments, not ours to withdraw.
Privacy
Your clients are yours.
We are a processor acting on your instructions. Your clients' details are your records, held for you. We do not market to them, we do not sell or share the data, and we will never contact one of your clients about anything other than the appointment they booked with you.
Client-facing messages are written in your firm's voice, not ours. "We" means your practice. Our name appears exactly once in a booking flow — an 11px attribution line at the foot of the page — and never inside a sentence your client reads.
If you leave, ask and we will send you everything we hold and delete your practice within 30 days. Backups age out within a further 35. Both are done by a person when you ask rather than by a button in the admin, which is why the row opposite says on request and not self-service.
Nothing on this site or in the booking widget loads a third-party script, an analytics tag, a webfont or an embedded map. There is no cookie banner here because there is nothing to consent to.
One sub-processor. AWS, Sydney.
Hosting and outbound email, and that is the entire list for your clients' data. Your practice's subscription is billed by Stripe — your card goes to Stripe directly and never touches our servers, and your clients never pay anything through us at all. Nothing joins either list without every practice being told first.
Accessibility
Your clients skew older. This is not a compliance exercise.
WCAG 2.2 AA on all text and all interactive states, in both colour schemes, on any accent colour a practice gives us — enforced in the token layer rather than checked afterwards.
Focus is always visible, using a two-tone ring — inner ring in the surface colour, outer in maximum contrast — so one of the two boundaries always clears 3:1 no matter what is underneath it. The practice's accent is deliberately never used for the focus ring, because it is the one colour we cannot predict.
The whole time grid is one stop on the tab key rather than forty: arrow keys move between times, Home and End jump to the ends. Touch targets are at least 44px tall everywhere, and 44px wide except for the day cells in the month calendar on the narrowest phones, where seven columns across a 320px screen leave 38px each. 16px is the floor for anything a client reads.
Colour is never the only signal. Every status carries a word as well as a colour, and every invalid field gains a thicker border, an icon and a sentence explaining what to do.
Accessibility, in practice
Help text is readable, and tied to the field it explains.
Tab through this. The focus ring is two-tone — inner ring in the surface colour, outer at maximum contrast — so one of the two boundaries always clears 3:1 whatever sits behind it.
When it goes wrong
What you will get from us.
If we have an incident that affects your practice's data, you hear from us directly, in plain words, with what happened, what it touched, what we have done and what you need to do. Not a status page you have to remember to check.
If a booking fails at our end, your client is told so and told what to do next, rather than shown a code. Nothing has been charged, because we never take a payment from your client at all. Keep your office number in your practice settings: an older client who hits an error picks up the phone, and that is the number they will use.
Security reports go to security@crazyduck.com.au. We will acknowledge inside one business day, we will not threaten you, and we will credit you if you want the credit.
Who runs it
Behind Crazy Duck.
Crazy Duck is built and operated in Melbourne by OneHQ, an Australian company that makes practice-management software for accounting firms. Scheduling for accountants is not a market we discovered — it is the industry we already work in, which is why the catalogue arrives knowing what a BAS review is.
We are a small team, and we would rather say so than have you infer it. It is also why this page answers questions directly instead of pointing at a badge: you can read exactly what we hold, and the person who replies to hello@crazyduck.com.au works on the product.
No SOC 2 badge yet, and we will not pretend otherwise. What we offer instead is specific written answers — which is more than a badge tells you anyway.