Booking and calendar privacy

This is the notice required by Article 13 of the EU and UK General Data Protection Regulation, covering the scheduler embedded on the contact page, the server behind it, and the calendar connected to it.

Last updated 12 August 2026.

Data not obtained from you is covered elsewhere. Personal data collected from public company registers is governed by Article 14. That notice is at data collection.

The controller

The controller for everything described on this page is Richport Media Inc., a Puerto Rico corporation.

  • Registered address1225 Ave Ponce De Leon, PH 2020, San Juan, PR 00907, United States.
  • Contact[email protected] — the address for access, correction, deletion, or any other request under this notice.
  • EU representative — Article 27None designated. There is no EU representative to write to; requests go to [email protected].
  • UK representative — Article 27None designated. The UK appointment is separate from the EU one and has not been made; requests go to [email protected].
  • Data protection officerNone appointed.

The scheduler

cal.richportmedia.ai is a self-hosted instance of Tymeslot, an open-source Elixir booking application, running on a server Richport Media Inc. rents and administers. No scheduling vendor holds a copy of the booking.

  • The machineA Hetzner Cloud CPX11 — two vCPU, 2 GB of memory — in Ashburn, Virginia, United States, deployed 12 August 2026. It runs the booking application and nothing else of ours. Booking data is stored there.
  • The counterpartyHetzner Online GmbH, Industriestrasse 25, D-91710 Gunzenhausen, Germany. The contracting company is German; the facility is American.
  • The path inCaddy terminates TLS with a certificate issued automatically by Let’s Encrypt and proxies to the application on 127.0.0.1. The application is published on loopback only. Inbound traffic is filtered twice — a Hetzner cloud firewall at the network edge and the host’s own ufw — both allowing only ports 22, 80 and 443. SSH is key-only with root login disabled; fail2ban and unattended security upgrades are enabled. The container image is pinned to an exact version.
  • Not behind CloudflareCloudflare answers DNS queries for the domain and proxies richportmedia.ai. It does not proxy this host: the record for cal.richportmedia.ai points straight at the server, so requests reach the machine directly and Cloudflare receives no booking traffic.
  • What is encrypted, and what is notStored connected-calendar credentials are encrypted at rest under a key held in the server’s environment. Booking records are not encrypted at rest. Your name, email address and corporation name sit in an ordinary PostgreSQL database on that machine, protected by the machine’s access controls and by TLS in transit.

What the form collects

There is one bookable meeting: a Consultation with the Managing Director, Richport Media, thirty minutes.

  • The meeting typeOne option, thirty minutes. It sets how much time the calendar holds.
  • The date and timeThe slot you pick, checked against live availability.
  • Your time zoneNot typed. Your browser reports it and the page displays it back. It is an approximate location signal, detected by your browser rather than derived from your IP address.
  • Corporation name — requiredThe server rejects an empty answer. It identifies the company to be discussed and allows an engagement to be declined before the call; the standing rules are on the limitations page.
  • Your name and email addressThe name is how the meeting and the calendar entry are addressed. The address is where the confirmation, the reminder, and the reschedule and cancel links are sent.
  • Anything else you typeIf a notes or additional-guest field is shown, whatever you put in it is stored with the booking and carried into the calendar entry.

Four further items are collected without being typed.

  • Your IP addressEvery web request carries one. Because the booking host is not proxied, it reaches our server directly.
  • Your browser’s user-agentAnd the ordinary request headers that come with it.
  • The page that framed the widgetThe embed script appends the parent page’s origin to the iframe address, so the booking server is told which page it is embedded in. The widget resizes itself by posting a message back to the parent page, with an origin check at both ends.
  • Cookies your browser already holdsIncluding two set by the marketing site rather than by the scheduler.
Whether you have to provide it. None of it is a statutory requirement, and there is no obligation to provide any of it. The meeting type, the slot, the corporation name, your name and your email address are what a booking consists of; leave any of them out and the booking cannot be completed. A call can also be arranged by writing to [email protected] without using the scheduler.

Lawful basis

Processing your booking rests on Article 6(1)(b) of the GDPR: steps taken at your request before entering into a contract. The processing consists of holding the slot, confirming it, reminding you about it, and letting you move or cancel it.

Keeping the server up and unabused — the firewalls, fail2ban, the ordinary operation of the machine — rests on Article 6(1)(f), the legitimate interest in a booking system that works and is not overrun. That is the only legitimate-interest processing on this surface, and the Article 21(1) objection right attaches to it.

Cancellation and portability. The remedy for a booking you no longer want is to cancel it, not to object to it; the cancel link is in every confirmation. Because the basis is contract and the processing is automated, the Article 20 portability right engages here. It does not engage for the register-sourced records described on the data collection page.

Google Calendar

The instance is configured with a Google Calendar connection on our side of the booking. You are not asked to authorise anything with Google, no calendar of yours is read, and nothing is written to any account of yours.

  • What it readsThe Managing Director’s own calendar, to establish which slots are free.
  • What it writesThe confirmed meeting, as a calendar entry. An entry written into Google Calendar means Google LLC, in the United States, holds a copy of the meeting time and of the details carried into it — your name, your email address and the corporation name.
  • How the credentials are heldThe OAuth tokens that let our server talk to Google are stored encrypted in the database, under a key that lives in the server’s environment and never in source control. That key encrypts credentials. It does not encrypt your booking record.
  • Booking without the calendarTo keep the meeting out of the connected calendar, email [email protected] instead of using the scheduler.
The call itself. Thirty minutes, and unrecorded — that commitment is on the trust page. Any video link in the calendar invitation is generated automatically by Google Calendar and can be replaced with your own.

Confirmation and reminder email

Mail the scheduler sends goes out through Google’s SMTP servers: the booking application signs in with a Google account on our own domain, so Google LLC handles the content of every confirmation and reminder. The MX records for richportmedia.ai point at Proton, so mail addressed to us is delivered to and stored by Proton AG in Switzerland.

Booking mail is sent from an address on richportmedia.ai. Replies to it are delivered to Proton. Its contents are fixed.

  • WhoThe parties to the meeting, by name.
  • WhatThe meeting type and its length.
  • WhenDate, time, and the time zone it is stated in.
  • WhereHow to join — the link or the dial-in, when one is set.
  • How to change itThe reschedule link and the cancel link.
  • Who sent itRichport Media Inc., and the sending address.
And nothing else — no survey, no case study, no offer under the signature. In BGH VI ZR 225/17 the German Federal Court of Justice held that a satisfaction survey attached to an otherwise transactional email is advertising, and that advertising requires prior consent. Booking email carries the meeting details and nothing else.

There is no marketing opt-in on the booking form. Booking a call does not add you to any list, and no marketing is sent on the strength of a booking. Any change to that would require a separate, unbundled, unticked consent, given before anything was sent and withdrawable at any time under Article 7(3) without affecting what had already gone out.

Cookies

The booking page loads no analytics and no advertising script, and every asset it serves comes from the booking host itself. Three cookies reach it: one set by the booking application, two set on richportmedia.ai.

  • _tymeslot_keySet by the booking application on the first page load, before you interact with anything. A session cookie: path /, Secure, HttpOnly, SameSite=Lax, no expiry. It carries a CSRF token and a language preference and nothing else. It is strictly necessary and is not consented to.
  • _ga and _ga_J5QWW3XMFWGoogle Analytics cookies. They are not set by the booking page. They are set on richportmedia.ai and scoped to the whole domain, so your browser sends them to cal.richportmedia.ai as well. The booking server therefore receives your Google Analytics client identifier in the same request as an identified booking. The two are not joined. Whether these cookies exist at all depends on the choice made at the consent banner on richportmedia.ai — the detail is on the cookies page.

The booking application ships a default content-security policy naming Stripe and Google font origins among permitted sources. Nothing on the booking page loads from any of them; every asset is first-party. Stripe is not a processor and receives no data.

Recipients and transfers

These are the parties that receive booking data or run the infrastructure it sits on.

  • Hetzner Online GmbHGerman company, Ashburn facility. Runs the machine underneath the booking application.
  • Google LLCUnited States, on two legs: the calendar entry, through the connection described above; and the confirmation and reminder mail, submitted through Google’s SMTP servers, so Google handles its contents.
  • Proton AGSwitzerland. Receives and stores mail sent to our published address, including anything you write back to us about a booking.
  • Internet Security Research Group — Let’s EncryptUnited States. Issues the TLS certificate automatically. It sees a hostname, not a booking.
  • Not CloudflareRuns the domain’s DNS. It does not carry booking traffic and is not a recipient of booking data.
  • No scheduling vendorNo third-party scheduling company receives booking data.

On transfers — Article 13(1)(f).

Richport Media Inc. is a Puerto Rico corporation, and Puerto Rico is United States territory. If you are in the EU or the UK, booking a call transfers your details to the United States. No adequacy decision covers that transfer. We hold no EU–US Data Privacy Framework certification and do not claim one. Two onward legs land in the United States as well, both with Google: the calendar entry, and the confirmation mail. Our contractual counterparty for the server is Hetzner Online GmbH, a German company, so that disclosure is a disclosure to a German entity; the onward leg from Hetzner’s German entity to its United States facility is Hetzner’s transfer, not ours. Proton AG is in Switzerland, which the European Commission recognises as providing an adequate level of protection. Processor terms and transfer clauses with these providers have not been concluded, and none are named here.

Retention

Article 13(2)(a) requires a retention period, or the criteria used to set one. No fixed period has been set. The criteria applied in practice are below.

  • Booking recordsYour name, email address, corporation name, the meeting time and anything typed into a notes field sit in the PostgreSQL database on the Ashburn server. There is no automated deletion schedule and no fixed period. A record is kept while there is a reason to hold it — the meeting, and the correspondence around it — and is deleted when you ask.
  • BackupsA job at 03:00 each night writes a compressed database dump and an archive of the uploads volume to the same server, and deletes anything older than fourteen days. A deleted record therefore persists in the backups for up to fourteen days. The backups sit on the same disk as the server and cover a broken database, not a lost machine.
  • The calendar entryAn entry written into Google Calendar lives under Google’s retention, and deleting the booking on our side does not by itself reach it. When you ask us to delete a booking we delete the calendar entry too.
  • Mail about a bookingA confirmation or a reminder also exists as a message: in your inbox, in the Google account it was sent from, and at Proton if you replied. There is no mailbox retention rule, so that mail sits there until it is deleted by hand.
  • Connected-calendar credentialsHeld encrypted for as long as the calendar connection exists. Disconnecting the calendar removes them.
  • LogsThe reverse proxy is configured without a log directive, so it writes no HTTP access log; its service messages go to the system journal. The application container keeps its log output in a rolling buffer capped at three files of ten megabytes, oldest overwritten first. That is a size limit. No log retention period is set.

Your rights

Exercising these rights costs nothing (Article 12(5)). An answer is owed within one month, extendable by two further months for a complex request under Article 12(3), with notice that the extension has been taken.

  • Access — Article 15A copy of the booking record we hold about you. Article 15(1)(g) also entitles you to know where the data came from; for a booking, the source is you, typing it.
  • Rectification — Article 16A misspelled name or the wrong company name, corrected.
  • Erasure — Article 17The booking record deleted, and the calendar entry with it. Backups carrying it roll off within fourteen days.
  • Restriction — Article 18The record kept but not acted on, while something about it is contested.
  • Portability — Article 20Your booking data back in a structured, machine-readable form. This right engages here, because the basis is contract and the processing is automated.
  • Objection — Article 21(1)Applies to the processing run on legitimate interests, which here is the security and operation of the server. The booking itself rests on Article 6(1)(b), so the remedy for a booking you no longer want is the cancel link.
  • Complaint — Article 77You can complain to the supervisory authority in the EU or UK country where you live or work, or where you think something went wrong, without asking us first.
How to exercise any of them. Write to [email protected]. A request from the address used to book is answered directly. A request from any other address requires confirmation from the booking address first; identity is verified before a booking record is disclosed.
Objection to direct marketing — Article 21(2). No marketing is sent off the back of a booking. If you did receive unsolicited marketing email from us, the right to object to direct marketing is absolute and unconditional, and there is no balancing test. That route is set out on the data collection page.

Automated decision-making, and changes

The booking flow determines availability only: free slots read from a calendar against the meeting rules we set. It produces no decision with legal or similarly significant effects, so the Article 22 right does not arise here. Booking data is not scored, ranked or profiled.

The date at the top of this page changes when the practice described here changes. Puerto Rico’s Act 39-2012 attaches a penalty to publishing a privacy policy that does not correspond to actual practice.

The rest of the legal pages: the privacy policy covers the site as a whole; cookies covers the consent banner and every script the marketing site loads; data collection covers contacts sourced from public registers and the Article 14 notice owed to them; disclosures covers paid-article labelling; terms covers the site itself.