by AICONOMY AG · events.aico.swiss
This policy covers Event Calendar, the calendar publishing service at events.aico.swiss, operated by AICONOMY AG. It describes what the service collects, why, how long it keeps it, and — in section 3 — specifically what it does with Google user data.
AICONOMY AG, Sägewiesenstrasse 10, CH-9325 Roggwil, Switzerland. VAT / UID CHE-466.130.799, registered in the commercial register of the Canton of Thurgau, legally represented by Müller Mathias, Administrator. Contact: office@aico.swiss.
TODO(vlad) Two details of that entry need aligning. The Impressum at aico.swiss/de/impressum currently publishes a different street (Mühleweg 4) and writes the company name in lower case; the details above are the confirmed ones, and the two published sources should be made to agree, because a privacy page that contradicts the group Impressum is exactly what a reviewer or a supervisory authority notices. And “Administrator” is most likely the English rendering of Verwaltungsrat: the commercial register states the exact role and the signing authority (sole or collective), and that wording should replace it here.
TODO(vlad) AICONOMY AG has not published a data protection officer or a dedicated privacy address, and has not stated a representative in the EU (GDPR Art. 27) or in Switzerland. If any of those exist, name them here; if a supervisory authority should be named as the route for complaints, name that too.
Two roles matter throughout this page. The organizer — the club, school or association that publishes a calendar — decides what to publish and who to contact, and is the controller of the subscriber records belonging to their calendars. AICONOMY AG runs the service on their behalf and is the controller for the operation of the platform itself. Event Calendar is also available inside the AICO platform; the platform-level policy is at aico.swiss/de/datenschutz (German).
Reading a calendar page, using an add-to-calendar link and subscribing a calendar app to a feed require no account and no sign-up. The public part of this service sets no cookies at all — not for analytics, not for preferences, not for anything. There is no advertising network, no tag manager and no third-party analytics script anywhere on these pages.
A subscriber can, entirely optionally, connect their own Google account so that a calendar's upcoming fixtures are written into their personal Google Calendar and kept correct automatically. This section describes that feature exactly. If you never connect a Google account, none of it applies to you.
Nothing connects a Google account except the account holder's own action on Google's consent screen. Organizers and administrators have no way to initiate it for someone else.
Event Calendar requests exactly three OAuth scopes:
openid and email — so that we can show you
which account you connected (“connected as you@example.com”). We read
the e-mail claim out of the ID token and store nothing else from it.https://www.googleapis.com/auth/calendar.events — permission
to manage events on your calendar. We request this and no broader scope:
a read-only scope cannot write the fixtures in, and the wider
calendar scope would also grant management of your calendar
list and settings, which this feature does not need.
The authorization request uses access_type=offline and
prompt=consent, which is what causes Google to issue a
refresh token. Without one, the sync would stop working
about an hour after you connected.
| Access and refresh tokens | Stored encrypted at rest in our database (application-level authenticated encryption; the ciphertext is what the database row holds). They are excluded from every API response, log line and background-job payload, and are never written to a log or an error report. |
|---|---|
| Token expiry | The moment the current access token stops working, so we can refresh it before the next write instead of failing. |
| Account e-mail address | The address of the Google account you connected, shown back to you and to the organizer so a connection can be recognised. Display only — it grants nothing. |
| Target calendar id | Which of your calendars to write into, if not the default one. |
| Event-id mapping | One row per mirrored fixture holding the id Google gave that event, a fingerprint (hash) of the content we last wrote, and when. This is what lets us update or remove exactly the events we created and nothing else, and what stops a retry from creating a duplicate in your calendar. |
| Sync cursor and health | When the connection last synced successfully, how many
consecutive runs have failed, and a short failure classification
(for example invalid_grant). The classification is a
fixed word from our own list — never a copy of Google's response
body. |
The organizer whose calendar you connected can see that a connection exists, the account e-mail, its status and when it last synced, so that they can help you if it breaks. They cannot see your tokens and cannot see your calendar.
Event Calendar's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
Concretely, and without exception:
No third party receives Google user data from us. The tokens live in our own database on our own servers, and the only party we talk to with them is Google.
You can end the connection from either side, at any time:
Disconnecting from Event Calendar stops the syncing immediately: from that
moment nothing of ours writes to your calendar again. The tidying up that
follows runs in the background, in this order — we
attempt to delete the events we had created in your
calendar, we ask Google to revoke the token at
https://oauth2.googleapis.com/revoke, and then we delete the
connection record, and the stored tokens cease to exist with
it. That normally happens within seconds; a repair pass runs every
hour and picks up anything a failed or lost background run missed, so in
practice it is complete well inside two hours.
Three honest caveats.
The same feature exists for Microsoft (Outlook.com and Microsoft 365)
accounts, on the scopes
openid email offline_access https://graph.microsoft.com/Calendars.ReadWrite,
and everything in sections 3.2 to 3.5 applies identically. Microsoft
provides no token-revocation endpoint, so on disconnect we delete the
mirrored events and destroy the stored tokens, and you can additionally
remove the app's access in your Microsoft account privacy settings.
If you ask a calendar to notify you, we store your e-mail address, your name if the form asked for one, a random confirmation token, when the confirmation mail was sent, and when you confirmed.
E-mail is delivered by Resend, which necessarily receives your address and the content of the message.
Phone alerts are opt-in on top of a confirmed e-mail subscription and take two separate proofs: a signed link sent to your mailbox, and a six-digit code we send to the number itself. Until you enter that code correctly, the number is not stored in our database at all — it sits in a short-lived cache entry, alongside a hash of the code, for fifteen minutes.
If you enable browser notifications we store the push endpoint your browser issues, its two encryption keys, and your browser's user-agent string (so you can tell your devices apart when revoking one). The endpoint belongs to your browser vendor's push service — Google, Mozilla or Apple, depending on the browser — and delivering a notification means contacting it. Revoking the permission in your browser ends this.
Organizers get a small amount of aggregate information about their own calendars. It is built to be useful without identifying anybody, and it is worth being precise about how.
When someone clicks an add-to-calendar link we record the calendar, which event, which service was chosen, the timestamp, and where the click came from: the referring URL and the address of the page the button was embedded on, with any query string stripped off. No IP address, no user agent, no cookie and no device identifier is recorded for a click, so these records cannot be joined into a profile of a person.
A calendar app that has subscribed to a feed fetches it periodically. We count those fetches per calendar per day, and we estimate how many distinct clients are behind them. That estimate is produced by hashing the requesting IP address together with the client's user-agent string and adding the hash to a probabilistic cardinality sketch — a structure that can answer “roughly how many distinct values have I seen” and that cannot be enumerated, reversed or asked whether a particular value is present. No IP address is stored. The daily figures expire from our cache after 35 days.
The “followers” number an organizer sees is therefore an approximation with a typical error of about 0.8%, and it is a count of calendar clients rather than of identifiable people. One person with a phone and a laptop counts twice; a household behind one address with identical software may count once. It is not, and cannot be turned into, a list of who is subscribed.
We keep counters of request volume and cache behaviour per route for running the service. They contain no personal data of any kind.
For every message we send we keep a delivery record: the recipient address or phone number as it was at send time, which channel and provider, the status (queued, sent, delivered, bounced, complained, failed) and the provider's own reason text where there was a failure. This is what lets an organizer see that a reminder actually arrived, and what lets us honour a bounce or a complaint. Message content is not stored.
Organizers have accounts, and those are cookie-based sessions — a session
cookie and a CSRF cookie on the dashboard, set only after signing in, and
never on the public pages. We record the session's IP address and user agent
for security, and we keep an append-only audit log of changes made in the
dashboard, which includes the acting user's e-mail, IP address and user
agent. Subscribers' contact details are not written into it in a usable
form: an e-mail address is masked (j***@club.example) — both a
subscriber's own address and the address of a connected Google or Microsoft
account — a phone number is reduced to a hint
(+41•••67), and a browser push registration or a
confirmation link is replaced entirely by [redacted]. A
subscriber's name is kept, so that a record of a deletion still means
something to the organizer reading it.
| Hosting | Hetzner Online GmbH, in its Falkenstein datacentre, Germany. The servers and the database that hold subscriber records are there, managed through Laravel Forge. |
|---|---|
| Resend | Sending e-mail, and reporting bounces and complaints back to us. United States. |
| Twilio | Sending WhatsApp and SMS messages, where a phone number has been verified. United States. |
| Only where you connected a Google account (section 3). | |
| Microsoft | Only where you connected a Microsoft account (section 3.6). |
| Browser push services | Google, Mozilla or Apple, only where you enabled browser notifications. |
| AICONOMY AG / AICO | Where Event Calendar is used as part of the AICO platform. |
So although we are a Swiss company, the data is stored in Germany, inside the EU and the EEA — not in Switzerland. Sending you an e-mail means the address and the message reach Resend, and sending a WhatsApp or SMS alert means the number and the message reach Twilio; both are United States companies, so those messages leave the EEA.
We use no advertising network, no third-party web analytics, no tag manager and no third-party error-tracking service.
TODO(vlad) The transfers to Resend and Twilio are stated as facts above and no legal basis for them is claimed here, because none has been confirmed. State the mechanism each transfer relies on and reference the data processing agreements with Resend, Twilio and Hetzner once they are signed — an unconfirmed basis asserted here would be worse than this gap.
You can ask for access to your data, its correction, its erasure, a copy of it, or object to its processing. In practice:
All traffic is served over TLS. Calendar-sync tokens are encrypted at rest and excluded from logs, API responses and job payloads. The public surface of the service reads through a database account that has no permission to write anything. Access to production is limited to the people who operate the service.
Event Calendar is not directed at children and we do not knowingly collect data from them. Where a club publishes a junior team's fixtures, the subscriber is normally a parent or guardian, and it is the organizer's responsibility to obtain consent where one is required.
We update this policy when the service changes. The date at the foot of the page says when it last changed, and the Google section is reviewed against the code whenever the calendar-sync feature is modified.
AICONOMY AG, Sägewiesenstrasse 10, CH-9325 Roggwil, Switzerland — office@aico.swiss. See also our terms of service and the AICO platform privacy policy.