Privacy Policy

Meet Buddy is used by hosts, who have accounts, and by invitees, who book a time and turn up. Almost every confusing question about a scheduling product comes from mixing the two up, so this document keeps them apart.

For hosts

We decide how the service handles account data — your login, your settings, the security around it — and we answer to you for it directly.

For invitees

The workspace you booked with decides what to ask you, what to do with your answers and whether to record the meeting. We hold that data on their behalf and act on their instructions. In data-protection language they are the controller and we are the processor.

The practical consequence: if you booked a meeting and want your data deleted, ask the workspace you booked with. They can do it themselves. We can help if they will not respond — see your rights.

Your account

Name, email address, a hashed password if you set one, your profile image if you have one, your timezone and when you last signed in. Passwords are stored as bcrypt hashes at a deliberately slow work factor; nobody here can read yours, including us.

Signing in with Google or Microsoft

We request your identity and email address, and nothing more. The record that link creates is used to recognise you at sign-in and is read by nothing else in the product. Signing in with Google does not connect your Google Calendar. That is a separate, separately-consented step, and no part of the code borrows one for the other.

Your scheduling setup

Workspaces you belong to and your role in each, event types, availability schedules, date overrides, booking rules.

Activity

An audit trail of consequential actions — who cancelled a booking, who changed an integration, who deleted a recording — with the time and the network address the request came from. It is what makes “who did this” answerable, and it is deliberately kept when the account that did it is gone.

Only what the booking needed, and it is the host’s form that decides most of it.

• Name and email address, and any guests you added.
• The time you chose, the timezone you were shown times in, and what the meeting was for.
• Your answers to the host’s questions. These are whatever they asked — we do not set the questions and we do not inspect the answers.
• The reason you gave if you cancelled or rescheduled, and whether you turned up.

There is no invitee account and no password. Rescheduling and cancelling work through a signed link in your confirmation email rather than by making you register, which means one fewer credential in the world and one more link worth not forwarding.

Audio and video are not stored unless somebody starts a recording. They pass through the media server between participants and are not written down.

Stored either way:

• Attendance. Who joined, when, for how long, and across how many reconnections.
• Chat.Messages sent in the room, kept against the meeting with the sender’s name alongside so a line still reads after that account is gone.
• The meeting record. Its code, when it ran, and which booking it belongs to.

When a recording is made, the file goes to the workspace’s own area of object storage and the workspace controls it. What that means legally, and everything Meet Buddy deliberately does not do — no transcription, no captions, no voice or face analysis — is on the recording and consent page.

Connecting Google Calendar or Microsoft 365 lets Meet Buddy avoid offering a slot you are already busy in, and write your confirmed bookings into your calendar. It is the most invasive-sounding thing in the product, so here is exactly what it takes.

What is stored

The start and end of your existing events, and whether each one counts as busy. That is what a free/busy check needs and it is all a conflict check uses.

What is not stored

Event titles are never written down. The field exists in the database for a future opt-in and the code that fills the cache explicitly asks the provider not to include them. Nor are attendees, locations, descriptions or attachments.

The token

The credential that lets us re-read your calendar in the background is encrypted at rest with a key derived from this deployment’s signing secret. Rotating that secret makes existing connections unreadable, which turns rotation into a reconnect rather than into a silent loss of conflict checking.

Disconnecting

Stops the syncing and forgets the token. Events we already wrote into your calendar stay there — they are your real appointments — and we lose the ability to update them. For Microsoft we cannot revoke the grant from our side; you remove it from your own account.

There are four, and none of them is for advertising or analytics. This application contains no third-party tracking code at all — no tag manager, no pixel, no session recorder.

Session

Set when you sign in, so the next request knows who you are. Lasts up to thirty days.

Active workspace

Remembers which workspace the console is showing. It is a preference and never an assertion — it is re-checked against your actual memberships on every read, so editing it gets you nothing.

Theme

Light or dark. Deliberately readable by the page itself, because it has to be applied before the first paint to avoid a flash. Kept a year.

Sign-in protection

Short-lived cookies the sign-in flow uses to make sure a login form submission came from this site.

There is no cookie banner because there is nothing here to consent to beyond making the product work.

We do not sell personal data and we do not share it for advertising. Data reaches other companies in four ways, all of them operational:

• Infrastructure. The database, object storage, media server and mail provider this deployment runs on: [list of sub-processors].
• Calendar providers, when a host connects one — and only for that host’s own calendar.
• Wherever a workspace sends it. A workspace can point webhooks at its own systems and use the API. What leaves that way is their configuration and their responsibility.
• Legal obligation, where we are required to disclose something and are permitted to say so.

Meet Buddy has no automatic retention policy. Nothing expires on a timer. Bookings, meeting records, attendance, chat and recordings are kept until somebody deletes them or the workspace is deleted. We would rather say that than imply a schedule the software does not enforce.

Where an organisation has promised its own retention period — [recording retention period] — that promise is kept by a person today, not by the product.

Deleting a workspace

Deleting a workspace removes its records, and the removal of everything it stored is scheduled in the same database transaction as the deletion. That ordering is the point: the alternative leaves a window in which the rows are gone, nothing references the files, and a crash means nothing ever will — and those files are video of people’s faces. Backups age out on their own cycle afterwards.

Audit records deliberately outlive the accounts they name, with the name kept alongside so the entry still reads. An audit trail that disappears when somebody deletes their account is not an audit trail.

• Passwords are bcrypt hashes at a slow work factor. Reset links are 32 bytes of cryptographic randomness, work once, expire within the hour, and changing a password invalidates every other live reset link for that account.
• Every stored object’s path begins with its workspace’s identifier, and those paths are built by one shared helper rather than assembled by hand — so cross-workspace access is prevented by the shape of the storage, not by remembering to check.
• The media server’s API secret never reaches a browser. Join tokens are minted on the server from a role resolved on the server, so “participants may not share their screen” is enforced by the media server refusing, not by hiding a button.
• Reschedule, cancel and calendar-feed links are signed. Anyone holding one can use it, which is what makes them convenient and what makes them worth not forwarding.

Two limits worth stating

The per-member calendar feed link cannot be revoked individually. It expires after a year, and the only way to invalidate one sooner is to rotate this deployment’s signing secret, which signs everyone out and invalidates every other signed link. If you think yours has leaked, say so — an operator can rotate, and that is currently the whole remedy.

A deployment with no mail provider configured writes the full text of every email it would have sent into its own server log, including reset links and invitation tokens, and reports them as delivered. That fallback exists so the product runs on a developer machine. An operator running a real deployment without a mail provider is keeping working credentials in a log file.

No system is perfectly secure and we do not claim this one is. If you find a problem, tell us at [contact address for legal notices] before you tell anyone else, and we will not come after you for looking.

Depending on where you live you may have rights to see a copy of your data, correct it, delete it, restrict or object to what is done with it, and take it elsewhere. We do not charge for exercising them and we do not treat you differently for it.

If you have an account

Ask us at [contact address for privacy requests]. Much of it you can do yourself: an owner can delete a workspace and everything in it.

If you booked a meeting

Ask the workspace you booked with first. They decided what to collect and they can delete it. Their address is on the booking page and in your confirmation email.

If they do not respond

Come to us at [contact address for privacy requests]. We will pass it on, and where we can act ourselves we will. What we can do unilaterally to a customer’s records is limited — that is what being a processor means, and it is the same limit that stops a stranger deleting your bookings by writing to us.

You can also complain to your data-protection regulator. We would rather you told us first, but that is your call.

Meet Buddy is a business tool and accounts are not for children. We do not knowingly collect data from children through an account. A minor may well appear as an invitee on somebody’s booking page — a tutor, a clinic, a school — and where that happens the workspace is responsible for having whatever consent applies, which is the same split as everywhere else in this document.

When this policy changes materially we will say so through the product or by email before the change takes effect. The rule the code follows is that a clause describing behaviour and the module implementing it change in the same commit — so a stale sentence here is a bug, and you can report it as one to [contact address for legal notices].