Datenschutzerklärung

Space Booking ist ein Dienst für Terminvereinbarung. Ein Kunde verbindet seinen Kalender und veröffentlicht eine Buchungsseite; ein Gast sucht sich dort eine freie Zeit aus. Diese Seite erklärt, welche Daten dabei entstehen, wofür sie gebraucht werden und wie lange sie bleiben.

Das Wichtigste in fünf Sätzen

• Aus dem verbundenen Kalender speichern wir nur Anfang und Ende belegter Zeiträume — keine Titel, keine Orte, keine Teilnehmer, keine Beschreibungen.
• Die Buchungsseite lädt nichts von fremden Servern und setzt keine Cookies. Es gibt keine Analysedienste, keine Werbung und keine Wiedererkennungskennung.
• Von Gästen wird keine IP-Adresse protokolliert, keine Browserkennung und kein Referrer — weder in der Datenbank noch im Anwendungsprotokoll noch im Protokoll des vorgelagerten Webservers. Näheres in Abschnitt 8.
• Gäste werden je Kundenkonto geführt und nie kontenübergreifend zusammengelegt. Ein Profil über mehrere Kunden hinweg kann so gar nicht entstehen.
• Wir verkaufen keine Daten und geben sie nicht an Werbenetzwerke oder Datenhändler weiter.

1. Verantwortlicher

Pascal Reischl
Fockygasse 32/3
1120 Wien
Österreich

E-Mail: inbox@pascalreischl.com
Telefon: +436641486208
UID-Nummer: ATU75932859

Weitere Angaben zum Betreiber stehen im Impressum. Ein Datenschutzbeauftragter ist nicht bestellt; Anfragen zum Datenschutz gehen an die oben genannte Adresse.

2. Zwei Gruppen von Betroffenen

Space Booking verarbeitet Daten von zwei Gruppen von Menschen, und für die beiden gelten verschiedene Antworten. Diese Unterscheidung ist der Kern dieser Erklärung.

• Der Kunde

  Wer ein Konto bei Space Booking hat, seinen Kalender verbindet und eine Buchungsseite veröffentlicht. Er hat mit uns einen Vertrag. Für seine Daten sind wir Verantwortlicher im Sinne der DSGVO.

• Der Gast

  Wer über die Buchungsseite eines Kunden einen Termin bucht. Er hat mit uns keinen Vertrag und kennt uns oft gar nicht — die Buchungsseite trägt das Aussehen des Kunden, nicht unseres. Nach unserer Einschätzung ist der Kunde für die Daten seiner Gäste der Verantwortliche und Space Booking sein Auftragsverarbeiter.

  Diese Einordnung ist rechtlich noch nicht abschließend geprüft, und ein Auftragsverarbeitungsvertrag zwischen Space Booking und seinen Kunden ist noch nicht abgeschlossen. Wir schreiben das hin, statt es offen zu lassen: Ein Gast, der wissen will, an wen er sich wenden soll, kann sich an den Kunden wenden, dessen Buchungsseite er benutzt hat, oder an uns.

3. Daten des Kunden

• Konto und Anmeldung

  Was: E-Mail-Adresse, Name, Zeitzone, Sprache.
  Wozu: das Konto führen, den Kunden anmelden, ihn über Buchungen benachrichtigen, Termine in seiner Zeitzone berechnen.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertrag).
  Wie lange: bis das Konto gelöscht wird.

• Anmeldelinks

  Die Anmeldung läuft ohne Passwort über einen Link per E-Mail. Gespeichert wird nur der SHA-256-Abdruck des Links, nicht der Link selbst; er gilt 15 Minuten und lässt sich genau einmal verwenden.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.

• Sitzungen

  Was: der SHA-256-Abdruck des Sitzungs-Cookies (nie der Wert selbst), Zeitpunkte, die gekürzte IP-Adresse (auf /24 bzw. /48, also ohne den Teil, der ein einzelnes Gerät benennt) und ein einzelnes Wort für den Browser — „Firefox“, „Chrome“, „Safari“, „Edge“ oder „andere“. Nicht die vollständige Browserkennung; die wäre ein Fingerabdruck.
  Wozu: angemeldet bleiben, „überall abmelden“ sofort wirksam machen, erkennbare Übernahmen eines Kontos nachvollziehen.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. b und lit. f DSGVO (berechtigtes Interesse an der Sicherheit der Konten).
  Wie lange: längstens 30 Tage, bei 14 Tagen ohne Nutzung früher; abgelaufene Zeilen werden 7 Tage später gelöscht.

• Was der Kunde selbst anlegt

  Verfügbarkeitsregeln, Urlaubszeiten, Buchungsseite, Terminarten samt Beschreibung und Ortsangabe. Das ist der Kern des Dienstes.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.
  Wie lange: bis der Kunde sie löscht oder das Konto endet.

4. Daten des Gastes

Ein Gast gibt seine Daten auf der Buchungsseite eines Kunden ein. Der Kunde legt fest, welche Felder eine Terminart verlangt.

Wer hier wofür einsteht. Nach der Einordnung in Abschnitt 2 ist bei Gastdaten der Kunde der Verantwortliche; Space Booking verarbeitet sie in seinem Auftrag. Die Rechtsgrundlage, die unten je Datenart steht, ist deshalb seine — nicht unsere. Genau eine Verarbeitung in diesem Abschnitt ist unsere eigene, und sie ist als solche gekennzeichnet: der Missbrauchsschutz, den wir für alle Buchungsseiten zugleich betreiben und über den ein einzelner Kunde nicht entscheidet.

• Die Buchung

  Was: E-Mail-Adresse; Name (sofern angegeben); Telefonnummer, wenn die Terminart danach fragt; Zeitzone und Sprache, die der Browser meldet; eine freiwillige Nachricht an den Gastgeber (höchstens 500 Zeichen); der gebuchte Zeitraum, die Terminart und eine Buchungsnummer.
  Wozu: den Termin zustande bringen, die Bestätigung mit der richtigen Uhrzeit verschicken, dem Gastgeber sagen, mit wem er sich trifft.
  Rechtsgrundlage des Kunden: Art. 6 Abs. 1 lit. b DSGVO (der Termin zwischen Gast und Gastgeber). Space Booking verarbeitet in seinem Auftrag.

• Absage und Verschiebung

  Sagt ein Gast ab, kann er freiwillig einen Grund angeben (höchstens 1000 Zeichen). Dieser Text steht in der Mail an den Gastgeber und bleibt bei der Buchung gespeichert.
  Rechtsgrundlage des Kunden: Art. 6 Abs. 1 lit. b DSGVO. Space Booking verarbeitet in seinem Auftrag.

• Der Link in der Bestätigungsmail

  Jede Bestätigungsmail enthält zwei Links: einen, um den Termin anzusehen, zu verschieben oder abzusagen, und einen für die Kalenderdatei (.ics). Gespeichert wird nur der SHA-256-Abdruck der Links, nie der Link selbst — ein Datenbankabzug ist damit kein Stapel funktionierender Absagelinks. Die Links laufen 24 Stunden nach dem Termin ab.
  Rechtsgrundlage des Kunden: Art. 6 Abs. 1 lit. b DSGVO. Space Booking verarbeitet in seinem Auftrag.

• Missbrauchsschutz (Verarbeitung von Space Booking selbst)

  Zu jeder Gastadresse wird zusätzlich ein HMAC gespeichert — ein Schlüsselabdruck, mit dem sich zwei Buchungen derselben Adresse zuordnen lassen, ohne die Adresse dafür erneut auszulesen. Außerdem begrenzen wir, wie viele Versuche aus einem Adressbereich in einer Stunde möglich sind; die dafür nötigen Zähler stehen nur im Arbeitsspeicher des Servers, nicht in der Datenbank, und sind nach einem Neustart weg.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO — unser berechtigtes Interesse daran, dass die Buchungsseiten unserer Kunden nicht mit erfundenen Terminen zugestellt werden. Diese eine Verarbeitung geschieht nicht im Auftrag eines Kunden, sondern für den Dienst als Ganzes; insoweit sind wir selbst Verantwortlicher.

• Wenn eine Mail nicht zugestellt werden kann

  Jede Mail läuft über eine Warteschlange. Scheitert die Zustellung endgültig, speichern wir die Fehlermeldung des Mailanbieters (auf 300 Zeichen gekürzt) bei dem Auftrag, der gescheitert ist, und zeigen sie dem Kunden in seinem Bereich an — sonst erfährt er nie, dass sein Gast keine Bestätigung bekommen hat. Solche Meldungen zitieren die Empfängeradresse häufig zurück („550 … does not exist <adresse@…>“); die Adresse steht dann in dieser Meldung. Ein automatischer Löschlauf für diese Warteschlange ist noch nicht gebaut.
  Rechtsgrundlage des Kunden: Art. 6 Abs. 1 lit. b DSGVO. Space Booking verarbeitet in seinem Auftrag.

Was von Gästen ausdrücklich nicht gespeichert wird

Keine vollständige IP-Adresse, keine Browserkennung, kein Referrer, keine Cookies, keine Wiedererkennungskennung irgendeiner Art. Der Dienst sendet auf allen Seiten Referrer-Policy: no-referrer, so dass beim Klick auf einen fremden Link auch die besuchte Adresse nicht mitwandert.

Gäste werden je Kundenkonto geführt. Bucht dieselbe Person bei zwei Space Booking-Kunden, entstehen zwei getrennte Datensätze; der eine Kunde erfährt nichts vom anderen.

Wie lange Gastdaten bleiben

Die Buchung selbst bleibt gespeichert, solange sie für Nachweis und Abrechnung des Kunden gebraucht wird. Ein automatischer Löschlauf ist noch nicht gebaut. Das System sieht eine Aufbewahrungsdauer je Kundenkonto vor, aber niemand führt sie heute aus — deshalb steht hier keine Frist, die wir nicht einhalten. Bis der Löschlauf existiert, löschen wir auf Anfrage von Hand (siehe Abschnitt 9), und beim Löschen wird der Freitext entfernt und die Buchungszeile von der Person gelöst, statt die Zeile zu vernichten.

Eine Grenze, die dazugehört: Das erreicht nur unsere Datenbank. Der Termin, den Space Booking in den Kalender des Kunden eingetragen hat, trägt den Namen des Gastes im Titel und in der Beschreibung seine freiwillige Nachricht sowie — bei einer Terminart, die danach fragt — seine Telefonnummer. Dieser Eintrag steht im Google-Konto des Kunden und in dessen Sicherungen; er liegt in seinem Verantwortungsbereich und wird von ihm entfernt. Erreicht uns eine Löschanfrage zuerst, leiten wir sie an ihn weiter und weisen ihn ausdrücklich auf diesen Eintrag hin.

5. Kalenderdaten

Dieser Abschnitt betrifft in erster Linie Kunden, die ihren Google-Kalender verbinden. Für Gäste ist ein Teil davon trotzdem wichtig: Was von einer Buchung im Kalender des Kunden landet, steht weiter unten unter „Was in den Kalender des Kunden geschrieben wird“.

Welche Google-Bereiche angefragt werden, und wofür

• openid, email, profile

  Damit wir wissen, welches Google-Konto verbunden wurde, und die Verbindung wiedererkennen, wenn derselbe Kunde sie später erneuert. Gespeichert werden daraus die Kontokennung, der Name und die E-Mail-Adresse des Google-Kontos; der Name und die Adresse werden bei jedem erneuten Verbinden aktualisiert. Mehr wird aus der Anmeldung nicht gelesen.

• calendar.calendarlist.readonly

  Liest die Liste der Kalender des Kunden, damit er auswählen kann, welche seine Verfügbarkeit blockieren und in welchen der gebuchte Termin geschrieben wird. Gespeichert werden daraus Name, Kennung und Zeitzone jedes Kalenders.

• calendar.events

  Zwei Aufgaben in einem Bereich, weil Google ihn nicht feiner anbietet:

  Lesen. Space Booking fragt die Termine im betrachteten Zeitfenster ab, um daraus belegte Zeiten abzuleiten.

  Schreiben. Der gebuchte Termin wird in den vom Kunden gewählten Kalender eingetragen, bei einer Verschiebung aktualisiert und bei einer Absage ausgetragen. Angefasst werden ausschließlich die Termine, die Space Booking selbst erzeugt hat. Ohne diesen Bereich steht der Termin nur bei uns und nicht im Kalender des Kunden.

Warum keiner der schmaleren Bereiche reicht

Google bietet zum Kalender mehrere engere Berechtigungen an. Wir haben jede davon geprüft; hier steht, woran sie scheitert.

• calendar.freebusy, calendar.events.freebusy

  Liefern nur „belegt von … bis …“. Sie verraten nicht, ob ein Eintrag ganztägig ist, ob er als „frei“ markiert wurde und ob der Kunde die Einladung abgesagt hat. Ohne diese drei Merkmale würde ein abonnierter Feiertagskalender den Kunden an jedem Feiertag ganztägig unbuchbar machen — und zum Eintragen des gebuchten Termins taugen sie ohnehin nicht.

• calendar.events.readonly

  Deckt das Lesen ab, aber nicht den zweiten Teil der Aufgabe: Der gebuchte Termin muss in den Kalender eingetragen, beim Verschieben geändert und bei einer Absage wieder ausgetragen werden.

• calendar.events.owned

  Reicht fürs Schreiben, aber nicht fürs Lesen: Die Belegung eines Kunden entsteht auch aus abonnierten und geteilten Kalendern, die ihm nicht gehören — der Kalender des Teams, der der Familie, der der Praxis. Mit diesem Bereich wären genau diese Zeiten unsichtbar, und der Kunde würde dann doppelt gebucht.

• calendar.app.created

  Erlaubt nur einen eigenen, von der Anwendung angelegten Zweitkalender. Der gebuchte Termin soll aber in dem Kalender stehen, den der Kunde selbst gewählt hat — sonst sieht er ihn in seiner Hauptansicht nicht, und genau darum geht es beim Eintragen.

• Und in die andere Richtung: calendar.calendarlist.readonly

  Das ist bereits die engste Form. Space Booking fragt nicht calendar.calendarlist an (das dürfte die Kalenderliste auch ändern) und nicht calendar.readonly (das läse gleich alle Termine mit). Gelesen wird die Liste, geschrieben wird an ihr nichts.

Was aus gelesenen Terminen gespeichert wird — und was nicht

Aus jedem gelesenen Termin speichern wir Anfang und Ende, zwei Merkmale (ganztägig ja/nein, blockiert die Zeit ja/nein) und die Kennung, unter der Google den Termin führt — letztere nur, damit eine spätere Änderung dieselbe Zeile trifft statt eine zweite anzulegen.

Nicht gespeichert werden Titel, Beschreibungen, Orte, Teilnehmer, Anhänge oder Konferenzlinks. Aus einem Termin „Onkologie, Dr. Berger“ wird bei uns die Zeile „von 14:00 bis 15:00 belegt“. Was darin stand, steht in keiner Datenbank von Space Booking, in keinem Backup und in keiner Protokollzeile.

Die ehrliche Einschränkung dazu: Im Moment des Abrufs sieht der Dienst den vollständigen Termin, denn Google liefert ihn vollständig aus. Die Auswertung — etwa die Frage, ob der Titel eines ganztägigen Termins auf Urlaub hindeutet — läuft im Arbeitsspeicher, und gespeichert wird davon nur das Ergebnis: Die Zeit ist belegt, der Eintrag war ganztägig. Der Grund wird nicht mitgespeichert. Ein Ganztagstermin, der wegen seines Titels („Urlaub“, „Krank“) blockiert, ist in unserer Datenbank von einem Ganztagstermin, der aus jedem anderen Grund blockiert, nicht zu unterscheiden — sonst stünde in der Zeile mittelbar doch, was im Titel stand. Unsere Zusage lautet deshalb „wir speichern es nicht“, und nicht „wir sehen es nie“. Das Zweite wäre technisch falsch, und eine falsche Zusage ist schlimmer als eine schmalere.

Was in den Kalender des Kunden geschrieben wird

Der eingetragene Termin trägt den Namen der Terminart und den Namen des Gastes im Titel; in der Beschreibung stehen die Ortsangabe der Terminart, die freiwillige Nachricht des Gastes und die Buchungsnummer. Enthält die Terminart eine Telefonnummer des Gastes, steht auch sie dort.

Der Gast wird nicht als Teilnehmer eingetragen. Seine E-Mail-Adresse wandert dadurch nicht zu Google, und er bekommt keine zweite, anders formulierte Einladung von einem Anbieter, die wir weder geschrieben haben noch zurückziehen könnten. Die Einladung samt Kalenderdatei verschickt Space Booking selbst.

Zugriffstoken

Google gibt zwei Token aus: ein langlebiges, mit dem Space Booking sich immer wieder neuen Zugang holt, und ein kurzlebiges für den einzelnen Abruf. Beide liegen gemeinsam verschlüsselt in derselben Zeile der Datenbank (AES-256-GCM, Zeilenschlüssel aus einem Hauptschlüssel abgeleitet, gebunden an die Kennung genau dieser Zeile). Der Hauptschlüssel liegt nicht in der Datenbank, sondern als Datei auf dem Server, die nur der Dienst lesen darf; ein Datenbankabzug allein nützt niemandem.

Warum auch das kurzlebige: Es entsteht bei jedem Neustart des Dienstes sonst für jede Verbindung auf einen Schlag neu, und es wäre der einzige Wert, der ungeschützt herumläge statt unter demselben Schloss zu liegen wie das andere.

Die Grenze dieser Maßnahme gehört dazu: Sie schützt gegen einen gestohlenen Datenbankabzug, ein verlorenes Backup und eine ausgemusterte Festplatte. Sie schützt nicht gegen einen Angreifer, der den laufenden Server selbst übernimmt.

Verbindung trennen

Ein Kunde kann die Kalenderverbindung jederzeit im Bereich „Kalender“ seines Kontos trennen. Dann geschieht in dieser Reihenfolge: Space Booking widerruft die Berechtigung zuerst bei Google, und löscht anschließend die Verbindung samt beider Token, die Liste der Kalender, den Synchronisationsstand, alle daraus gespeicherten belegten Zeiten und den Vermerk darüber, welchen Termin Space Booking in welchen dieser Kalender eingetragen hat. Schlägt der Widerruf bei Google fehl, löschen wir trotzdem lokal und sagen es in der Antwort — dann bleibt der Eintrag unter „Drittanbieter-Zugriff“ im Google-Konto bestehen und sollte dort ebenfalls entfernt werden.

Was das Trennen nicht tut: Die Termine, die Space Booking bereits in den Kalender geschrieben hat, bleiben dort stehen. Ohne Berechtigung können wir sie nicht mehr anfassen — sie stehen im Kalender des Kunden und werden von ihm entfernt, wenn er sie nicht behalten will. Buchungen, die bereits zustande gekommen sind, bleiben ebenfalls bestehen; sie sind eine Vereinbarung zwischen dem Kunden und seinem Gast und hängen nicht am Kalender.

Die Berechtigung lässt sich außerdem jederzeit direkt bei Google zurücknehmen, unabhängig von Space Booking.

6. Google API Services User Data Policy

Die Verwendung der von Google-APIs empfangenen Informationen durch Space Booking und ihre Weitergabe an jede andere Anwendung hält die Google API Services User Data Policy einschließlich der Limited-Use-Anforderungen ein.

Im Wortlaut der Google-Vorgabe: Space Booking's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Konkret bedeutet das für diesen Dienst:

• Kalenderdaten werden ausschließlich für die Funktionen verwendet, die der Kunde auf der Oberfläche sieht: freie Zeiten berechnen und den gebuchten Termin eintragen.
• Sie werden nicht an Dritte übertragen, außer soweit es für diese Funktionen nötig ist, das Gesetz es verlangt oder der Kunde ausdrücklich zustimmt.
• Sie werden nicht für Werbung verwendet und nicht an Werbenetzwerke, Datenhändler oder Auskunfteien verkauft oder weitergegeben.
• Kein Mensch liest sie — außer der Kunde stimmt ausdrücklich zu (etwa bei einer Support-Anfrage zu einem konkreten Fehler), es ist aus Sicherheitsgründen oder rechtlich zwingend nötig. Der einzige Speicher, der überhaupt lesbar wäre, enthält Anfang und Ende, sonst nichts.
• Kalenderdaten werden nicht zum Training von KI-Modellen verwendet.

7. Empfänger und Auftragsverarbeiter

• Der Kunde, dessen Buchungsseite benutzt wurde

  Der erste Empfänger der Daten eines Gastes ist der Gastgeber selbst, und das ist keine Nebenbemerkung: Er bekommt eine Mail mit Name, Adresse, der freiwilligen Nachricht und — sofern die Terminart danach fragt — der Telefonnummer, und dieselben Angaben trägt Space Booking in seinen verbundenen Kalender ein. Genau dafür gibt ein Gast sie an. Nach der Einordnung in Abschnitt 2 ist der Kunde für diese Daten der Verantwortliche; er ist damit kein „Dritter“ im Sinne einer Weitergabe, sondern die Stelle, zu der die Buchung gehört.

• Hetzner Online GmbH

  Der Server steht in einem Rechenzentrum der Hetzner Online GmbH (Industriestraße 25, 91710 Gunzenhausen) am Standort Falkenstein in Deutschland. Dort liegen die Anwendung, die Datenbank und die Sicherungen; die Verarbeitung findet innerhalb der EU statt. Grundlage ist die Auftragsverarbeitungsvereinbarung nach Art. 28 DSGVO, die Hetzner für seine Kunden bereitstellt.
  Offen und hier ehrlich vermerkt: Ob diese Vereinbarung im Konto des Betreibers bereits angenommen ist, ist nicht belegt. Solange das nicht belegt ist, ist der Satz darüber eine Absicht und keine Tatsache — er wird bestätigt oder geändert, bevor ein fremder Nutzer den Dienst benutzt.

• Google — als Anbieter der Kalender-Schnittstelle

  Verbindet ein Kunde seinen Google-Kalender, tauscht Space Booking mit Google Daten aus: Wir lesen Termine und schreiben den gebuchten Termin zurück. Was dabei fließt, steht in Abschnitt 5. Der Kunde erteilt diese Berechtigung selbst auf Googles Zustimmungsbildschirm und kann sie dort jederzeit zurücknehmen.

• Google — als Mailversender

  Das gehört getrennt genannt, weil es auch Gäste betrifft, die nie etwas mit Google zu tun hatten: Der Mailversand von Space Booking läuft über ein Google-Workspace-Konto des Betreibers (smtp.gmail.com). Jede Bestätigungs-, Absage-, Verschiebungs- und Anmeldemail geht damit durch Googles Server — mit Empfängeradresse, Betreff, Inhalt und der angehängten Kalenderdatei. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO; ohne Mailversand gibt es keine Terminbestätigung.

Übermittlung in Drittländer

Zwei der drei oben genannten Empfänger sind Google, und Google ist ein US-amerikanischer Konzern. Damit entsteht ein Drittlandbezug, und das betrifft nicht nur Kunden, die ihren Kalender selbst verbunden haben: Jede Bestätigungs-, Absage-, Verschiebungs- und Anmeldemail geht über smtp.gmail.com und trägt Empfängeradresse, Betreff, Inhalt und die angehängte Kalenderdatei durch Googles Server. Ein Gast, der mit Google nie etwas zu tun hatte, ist davon genauso betroffen.

Was ausdrücklich nicht stattfindet

Keine Analysedienste, kein Content-Delivery-Network, keine externen Schriftarten, keine eingebetteten Videos, keine Werbe- oder Social-Media-Bausteine. Die Buchungsseite lädt nichts von fremden Servern nach — sie benutzt die Schriften, die ohnehin auf dem Gerät des Besuchers liegen.

Das ist keine Absichtserklärung, sondern eine Eigenschaft des Systems: Der Dienst sendet auf jeder Seite eine Content-Security-Policy mit default-src 'none' und erlaubt Stile, Schriften, Bilder und Netzwerkaufrufe ausschließlich von der eigenen Adresse. Ein fremdes Skript oder eine fremde Schriftart würde vom Browser des Besuchers gar nicht erst geladen — auch dann nicht, wenn sie jemand versehentlich einbaute.

8. Cookies und Protokolle

• Cookies

  Es gibt genau ein Cookie, und nur im angemeldeten Bereich: die Sitzung des Kunden (__Host-spacebooking_session, nicht per Skript auslesbar, nur über HTTPS, längstens 30 Tage). Es ist technisch notwendig — ohne Sitzung keine Anmeldung — und braucht daher keine Einwilligung.

  Auf den öffentlichen Seiten — Startseite, Buchungsseite, Gastseite, dieser Text — wird kein Cookie gesetzt. Das ist im Programm erzwungen und nicht bloß vorgesehen: Ein öffentlicher Programmteil, der es doch versuchte, ließe den Testlauf scheitern.

• Anwendungsprotokoll

  Der Dienst protokolliert je Anfrage eine Zeile mit Anfragenummer, Kontokennung, Statuscode, Dauer und Fehlerklasse. Keine IP-Adresse, keine Gastadresse, keine Termininhalte, keine Anmeldelinks und keine Token. Auch kein Pfad: Protokolliert wird das Muster der Route (/b/{token}), nie die aufgerufene Adresse — sonst stünde der Gastlink in der Zeile.

  Ein Merkmal muss hier genannt werden, weil „keine Gastadresse“ sonst mehr verspricht, als es hält: Wo eine Zeile eine E-Mail-Adresse benennen müsste — beim Mailversand etwa — steht statt ihrer ein Schlüsselabdruck der Adresse, derselbe Gedanke wie beim Missbrauchsschutz in Abschnitt 4. Der Abdruck ist gleichbleibend, also lassen sich die Zeilen zu einer Person zusammenführen, ohne dass die Adresse irgendwo im Klartext stünde. Das ist pseudonym, nicht anonym, und wir sagen es lieber, als es zu verschweigen.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Betrieb und Fehlersuche).

• Webserver-Protokoll

  Der vorgelagerte Webserver schreibt für alle Wege, die ein Gast geht — Startseite, Buchungsseite, Gastseite, dieser Text, die Gast-Schnittstellen und die Programmdateien der Oberfläche — kein Zugriffsprotokoll. Dort wäre die Zeile eine Besucherstatistik über die Kunden unserer Kunden, und die führen wir nicht. Protokolliert werden der Anmeldeweg und die Schnittstellen des angemeldeten Bereichs; diese Zeilen enthalten die IP-Adresse des Kunden.
  Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Betrieb, Abwehr von Angriffen).
  Wie lange: 14 Tage. Die Protokolle werden täglich rotiert und nach vierzehn Tagen gelöscht; das ist auf dem Server eingerichtet und nachgeprüft, keine Absichtserklärung.

9. Rechte der Betroffenen

Nach der DSGVO haben Kunden wie Gäste das Recht auf

• Auskunft über die gespeicherten Daten (Art. 15),
• Berichtigung unrichtiger Daten (Art. 16),
• Löschung (Art. 17),
• Einschränkung der Verarbeitung (Art. 18),
• Datenübertragbarkeit (Art. 20),
• Widerspruch gegen Verarbeitungen, die auf berechtigtem Interesse beruhen (Art. 21) — das betrifft hier den Missbrauchsschutz und die Protokolle.

Wie sie ausgeübt werden — für Kunden

Mit einer E-Mail an inbox@pascalreischl.com. Wir antworten unverzüglich, spätestens innerhalb eines Monats; bei besonders aufwendigen Anfragen kann sich diese Frist um bis zu zwei weitere Monate verlängern, worüber wir dann innerhalb des ersten Monats informieren (Art. 12 Abs. 3 DSGVO).

Wie sie ausgeübt werden — für Gäste

Hier ist der Weg ein anderer, und das folgt zwingend aus der Einordnung in Abschnitt 2: Verantwortlicher für die Daten eines Gastes ist der Gastgeber, dessen Buchungsseite benutzt wurde. Anfragen gehen deshalb an ihn — seine Kontaktangaben stehen in der Bestätigungsmail und im Impressum, auf das seine Buchungsseite verlinkt.

Erreicht uns die Anfrage zuerst, lassen wir sie nicht liegen: Wir leiten sie unverzüglich an ihn weiter, sagen dem Anfragenden Bescheid und unterstützen den Gastgeber dabei, sie zu beantworten. Was wir nicht tun, ist die Buchung eines Kunden ohne dessen Wissen zu löschen oder Auskunft über sie zu erteilen — ein Auftragsverarbeiter darf das ohne Weisung nicht, und ein Termin, von dem eine Seite plötzlich nichts mehr weiß, ist für beide Seiten schlechter als eine Anfrage, die einen Tag länger braucht.

Es gibt für all das noch keinen Knopf im Konto. Auskunft und Löschung sind als Funktion vorgesehen, aber nicht gebaut, und wir versprechen hier keine Schaltfläche, die es nicht gibt: Heute macht das ein Mensch von Hand. Bitte nennen Sie in der Anfrage die E-Mail-Adresse, mit der gebucht oder angemeldet wurde, und — falls vorhanden — die Buchungsnummer aus der Bestätigungsmail.

Eine Einschränkung, die wir vorab nennen: Ein bevorstehender Termin wird nicht gelöscht, solange er stattfinden soll. Die Daten sind für genau den Zweck, für den sie angegeben wurden, noch notwendig — die Löschpflicht nach Art. 17 Abs. 1 lit. a DSGVO greift erst danach. Wer den Termin nicht wahrnehmen will, sagt ihn über den Link in der Bestätigungsmail ab; die Löschung ist dann sofort möglich.

10. Beschwerderecht

Wer meint, dass die Verarbeitung seiner Daten gegen die DSGVO verstößt, kann sich bei einer Aufsichtsbehörde beschweren. In Österreich ist das die

Österreichische Datenschutzbehörde
Barichgasse 40–42
1030 Wien
Österreich
Telefon: +43 1 52 152-0
E-Mail: dsb@dsb.gv.at
www.dsb.gv.at

11. In English, for the Google OAuth review

Dieser Abschnitt wiederholt auf Englisch, was oben ausführlich auf Deutsch steht. Er ist für die Überprüfung durch Google gedacht; maßgeblich für Betroffene ist der deutsche Text.

12. Stand und Änderungen

Stand: 26. August 2026. Diese Erklärung beschreibt den Dienst in seinem heutigen Ausbau. Kommen Funktionen dazu, die neue Daten verarbeiten, wird sie vorher geändert — und das Datum in dieser Zeile ändert sich mit.