Datenschutzerklärung

1. Kurzfassung

Alles in dieser Erklärung ist gegen den Quelltext der Anwendung geprüft. Wenn du dazu eine Auskunft brauchst, wende dich über die Kontaktdaten in Ziffer 2 an uns.

BrickDb ist ein Angebot der ThreeB IT GmbH, ohne Werbeanzeigen. Diese Erklärung beschreibt, welche Daten tatsächlich verarbeitet werden — nicht, was üblicherweise in solchen Texten steht.

• Für die Reichweitenmessung mit Google Analytics wird deine Einwilligung eingeholt. Ohne sie findet sie nicht statt: es wird kein Skript geladen, keine Kennung gesetzt und nichts an Google gesendet. Näheres in Ziffer 10.
• Ohne deine Einwilligung wird beim Aufruf einer Seite keine Verbindung zu einem Drittanbieter aufgebaut. Auch Schriftarten liegen auf dem eigenen Server.
• Fotos sind nur für dich und für die Mitglieder sichtbar, denen du in einer geteilten Sammlung die privaten Angaben eingeräumt hast; auf der öffentlichen Seite einer Sammlung erscheinen sie nicht. Näheres in Ziffer 8.2. Eingebettete Metadaten — darunter GPS-Koordinaten — werden bei der Verarbeitung entfernt.
• Auf dem Endgerät wird nichts gespeichert, woran du wiedererkannt werden könntest, bevor du eine Einstellung aktiv ausgewählt, dich angemeldet oder eingewilligt hast. Was der Browser rein technisch für die Sicherheit der Formulare braucht und was deine Anmeldung trägt, steht vollständig in Ziffer 6.1; was die App auf dem Gerät ablegt, steht in Ziffer 6.5. Deine Entscheidung über die Reichweitenmessung kannst du am Ende jeder Seite jederzeit ändern.

2. Verantwortlicher

Verantwortlicher im Sinne des Art. 4 Nr. 7 DSGVO ist:

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Deutschland
Telefon: +49 (5451) 893922-0
E-Mail: hallo@brickdb.de

Vertreten durch die Geschäftsführer Thimo Buchheister und Thorsten Brügge.

Ein Datenschutzbeauftragter ist nicht bestellt.

3. Aufruf der Website

Beim Aufruf von www.brickdb.de oder einer der weiteren Adressen, unter denen BrickDb erreichbar ist (www.brickdb.at, www.brickdb.ch, www.brickdb.dk, www.brickdb.nl, www.brickdb.be, www.brickdb.fr, www.brickdb.it, www.brickdb.lu, www.brickdb.es, www.brickdb.co.uk, www.brickdb.us, www.brickdb.com.mx, www.brickdb.eu, www.brickdb.net), verarbeitet der Webserver die Daten, die ein Browser technisch übermitteln muss, damit eine Seite ausgeliefert werden kann: IP-Adresse, Datum und Uhrzeit der Anfrage, die angeforderte Adresse, übertragene Datenmenge und Statuscode, die Browser- und Betriebssystemkennung (User-Agent) sowie die vom Browser gesendete Sprachpräferenz (Accept-Language).

Diese Daten fallen bei jeder Verbindung im Internet notwendigerweise an. Sie werden verarbeitet, um die Seite auszuliefern, die technische Funktionsfähigkeit sicherzustellen und Angriffe abzuwehren.

Eine weitere, eng begrenzte Verwendung findet die Sprachpräferenz: Die darin enthaltene Regionsangabe (zum Beispiel DE aus de-DE) wird während der Beantwortung der Anfrage gelesen, um ein Land vorauszuwählen: auf der Eventliste und für die Preise auf den Seiten von Sets und Minifiguren, also welche Preise von Shops gezeigt werden, welcher Amazon-Shop verlinkt ist und in welcher Währung Preise angezeigt werden. Bist du angemeldet und hast in deinem Profil ein Land hinterlegt (Ziffer 7.2), wird stattdessen dieses Land verwendet. Ein Land, das du auf der Seite selbst ausgewählt und gespeichert hast (Ziffer 6.1, bd-country), geht beidem vor. Die Regionsangabe wird nicht gespeichert, nicht mit anderen Daten zusammengeführt und nicht weitergegeben; das gewählte Land steht sichtbar auf der Seite — auf der Eventliste auch in der Adresszeile — und lässt sich dort mit einem Klick aufheben.

Auf den Adressen, die einem Land zugeordnet sind (zum Beispiel www.brickdb.de oder www.brickdb.fr), ergibt sich das Land aus der Adresse selbst. Auf www.brickdb.net und www.brickdb.eu, die keinem einzelnen Land zugeordnet sind, kommt eine weitere Angabe hinzu: Das vorgeschaltete Verteilnetz (Azure Front Door, ein Dienst des in Ziffer 4 genannten Auftragsverarbeiters Microsoft) leitet dort am Netzrand aus der IP-Adresse der Anfrage ein Länderkürzel aus zwei Buchstaben ab (zum Beispiel SE) und gibt es der Anwendung mit. Es dient demselben Zweck wie die Regionsangabe: ein Land für Preise und Events vorauszuwählen. Die Anwendung erhält dabei nichts außer diesem Kürzel, insbesondere keinen genaueren Standort; das Kürzel wird weder gespeichert noch protokolliert noch mit anderen Daten zusammengeführt. Ein Geolokalisierungsdienst eines Dritten wird nicht eingesetzt; die IP-Adresse wird zu diesem Zweck niemandem offengelegt, der sie nicht ohnehin verarbeitet, um die Seite auszuliefern. Rechtsgrundlage dafür ist Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse besteht darin, dir Preise und Events für dein eigenes Land zu zeigen, ohne dich vorher danach zu fragen. Du kannst das jederzeit übersteuern, indem du auf der Seite selbst ein Land auswählst (Ziffer 6.1, bd-country).

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse besteht im technisch fehlerfreien und sicheren Betrieb des Angebots.

Speicherdauer: Die Anwendung selbst führt kein Zugriffsprotokoll. Auf Ebene der Infrastruktur anfallende Protokolle werden nur so lange aufbewahrt, wie es für die Betriebssicherheit erforderlich ist, längstens 30 Tage, sofern sie nicht zur Aufklärung eines konkreten Sicherheitsvorfalls benötigt werden.

4. Hosting

Das Angebot wird auf Microsoft Azure betrieben, Anbieterin ist die Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irland. Als Verarbeitungsort ist die Azure-Region Germany West Central (Frankfurt am Main) gewählt; Datenbank und Dateiablage liegen damit in Deutschland.

Microsoft ist insoweit Auftragsverarbeiter nach Art. 28 DSGVO auf Grundlage des Microsoft Products and Services Data Protection Addendum.

Anfragen an BrickDb laufen über das Verteilnetz Azure Front Door von Microsoft. Es nimmt die Verbindung an einem Standort in deiner Nähe entgegen — der außerhalb Deutschlands und außerhalb der EU und des EWR liegen kann — und leitet sie weiter; die Anwendung und alle gespeicherten Daten bleiben in Germany West Central (Frankfurt am Main). Auch das geschieht im Rahmen der Auftragsverarbeitung auf Grundlage des Microsoft Products and Services Data Protection Addendum; soweit damit eine Übermittlung in ein Drittland verbunden ist, gilt dafür, was der folgende Absatz unter „Drittlandsübermittlung“ zu Microsoft sagt.

Drittlandsübermittlung: Ein Zugriff aus Drittländern lässt sich im Rahmen von Support- und Wartungsvorgängen nicht vollständig ausschließen. Microsoft stützt solche Übermittlungen auf die Standardvertragsklauseln der EU-Kommission und ist zusätzlich unter dem EU-US Data Privacy Framework zertifiziert.

5. Schriftarten und externe Inhalte

Die verwendeten Schriftarten werden vom eigenen Server ausgeliefert. Es werden keine Schriftarten von Servern Dritter — insbesondere nicht von Google Fonts — nachgeladen. Es sind keine Karten, Videos, Social-Media-Plug-ins oder sonstigen eingebetteten Inhalte Dritter vorhanden.

Ohne deine Einwilligung wird beim Aufruf einer Seite keine Verbindung zu einem Drittanbieter aufgebaut und keine IP-Adresse an einen Dritten übermittelt.

Die einzige Ausnahme ist die Reichweitenmessung nach Ziffer 10, und sie ist keine Einschränkung dieses Satzes, sondern seine Bedingung: das Skript von Google wird erst geladen, nachdem du im Einwilligungsbanner zugestimmt hast. Solange du nicht zugestimmt oder abgelehnt hast, wird nichts von Google geladen — auch keine als „cookielos" bezeichnete Vorabmeldung.

6. Speicherung auf dem Endgerät

BrickDb setzt keine Cookies zu Marketing- oder Werbezwecken. Gespeichert wird ausschließlich, was eine bewusst getroffene Einstellung festhält, was die Sicherheit der Formulare verlangt, was deine Anmeldung trägt, wenn du dich anmeldest — und, wenn du der Reichweitenmessung nach Ziffer 10 zugestimmt hast, die dort beschriebenen Analyse-Cookies. Vor deiner Zustimmung wird keines der Analyse-Cookies gesetzt.

6.1 Was gespeichert wird

Die ersten fünf Einträge enthalten ausschließlich den zuletzt ausgewählten Wert. Sie enthalten keine Kennnummer und nichts, woraus sich eine Person oder ein Gerät wiedererkennen ließe. Alle fünf sind Erstanbieter-Speicher; kein Dritter hat Zugriff darauf. Jeder von ihnen gilt nur für die Adresse, auf der er gesetzt wurde: Eine Auswahl auf www.brickdb.de wird auf www.brickdb.fr nicht gelesen. bd-country entsteht, wenn du ein Land auswählst und speicherst, bd-market-hint, wenn du den Hinweis schließt, dass es für dein Land eine eigene Adresse gibt — er sorgt allein dafür, dass dir dieser Hinweis nicht bei jedem Seitenaufruf erneut gezeigt wird. bd-analytics-consent ist zusätzlich als HttpOnly gesetzt, weil kein Skript im Browser ihn lesen muss: ob die Reichweitenmessung läuft, entscheidet der Server, bevor die Seite entsteht.

Der sechste Eintrag wird vom eingesetzten Webframework auf jeder Seite gesetzt, die ein Formular enthält — also auch auf der Seite, auf der das Einwilligungsbanner steht. Er schützt diese Formulare davor, von einer fremden Seite aus abgeschickt zu werden (Cross-Site Request Forgery), enthält keine Angabe über dich, ist HttpOnly und SameSite=Strict und endet mit der Sitzung. Beim Einwilligungsbanner ist er der Grund, aus dem niemand von außen eine Zustimmung in deinem Namen auslösen kann.

Die beiden folgenden Einträge entstehen erst, wenn du dich anmeldest. bd.auth hält deine Anmeldesitzung; sein Inhalt ist verschlüsselt, er ist HttpOnly und Secure und wird nur an diese Seite gesendet (SameSite=Lax). Er verlängert sich nicht von selbst: Die Sitzung endet mit der Gültigkeit der Anmeldung und nicht erst, wenn du aufhörst zu klicken. Beim Abmelden wird er entfernt. Die beiden Handshake-Cookies setzt das Framework nur für die Dauer eines einzelnen Anmeldevorgangs; sie binden die Rückkehr von der Anmeldeseite an genau den Vorgang, den du begonnen hast, und werden danach wieder entfernt.

Der letzte Eintrag sind die Analyse-Cookies aus Ziffer 10. Sie werden ausschließlich nach deiner Einwilligung gesetzt und enthalten eine zufällige Kennung, mit der wiederkehrende Aufrufe desselben Browsers erkannt werden.

6.2 Warum für alle Einträge außer den Analyse-Cookies keine Einwilligung erforderlich ist

Maßgeblich ist § 25 TDDDG. Dieser erfasst jede Speicherung von Informationen auf dem Endgerät und jeden Zugriff darauf — also nicht nur Cookies, sondern ausdrücklich auch Local Storage. Nach § 25 Abs. 2 Nr. 2 TDDDG ist eine Einwilligung entbehrlich, wenn die Speicherung unbedingt erforderlich ist, damit ein vom Nutzer ausdrücklich gewünschter Dienst bereitgestellt werden kann.

Das ist hier der Fall, und zwar aus Gründen, die sich am Verhalten der Anwendung überprüfen lassen:

• Vor einer aktiven Auswahl wird nichts gespeichert. Das bloße Aufrufen der Seite schreibt keinen Eintrag. Ein Eintrag entsteht ausschließlich dann, wenn die Umschalter für Darstellung oder Sprache bedient werden, wenn du ein Land auswählst und speicherst oder wenn du den Hinweis auf eine andere Länderadresse schließt.
• Die Rückkehr zur Voreinstellung löscht den Eintrag wieder. Wird „System" gewählt, wird der zugehörige Eintrag entfernt statt überschrieben.
• Gespeichert wird genau die Einstellung, die ausdrücklich gewünscht wurde, und sonst nichts.
• Für bd-analytics-consent gilt dasselbe aus einem eigenen Grund: er hält die Entscheidung fest, die du gerade getroffen hast. Ohne ihn müsste die Frage auf jeder Seite erneut gestellt werden — auch demjenigen, der eben erst abgelehnt hat.
• Das Antiforgery-Cookie ist der klarste Fall der drei: ohne es lässt sich ein Formular auf dieser Seite nicht mehr gegen Missbrauch von außen absichern, und das betrifft auch die Schaltfläche, mit der du der Reichweitenmessung zustimmst oder sie ablehnst. Es wird nicht gespeichert, weil etwas gemessen werden soll, sondern damit deine eigene Eingabe die ist, die zählt.
• Für die drei Anmelde-Cookies gilt es am deutlichsten: Ohne sie lässt sich eine Anmeldung weder durchführen noch aufrechterhalten. Wer sich anmeldet, verlangt genau den Dienst, den sie erbringen, und sie entstehen erst in dem Moment, in dem er verlangt wird — wer sich nicht anmeldet, bekommt keines davon.

Eine Einstellung, die auf ausdrückliche Anforderung hin gemerkt wird, ist damit für die Erbringung des angeforderten Dienstes unbedingt erforderlich; für die Sicherheit der Formulare und für die Anmeldung gilt das ohnehin. Für diese Einträge wird deshalb keine Einwilligung eingeholt.

Widerspruch und Löschung: Die Einträge für Darstellung und Sprache lassen sich jederzeit entfernen, indem im Umschalter wieder „System" gewählt oder die Browserdaten gelöscht werden. Die Seite funktioniert ohne sie unverändert; sie erscheint dann in der Darstellung und Sprache, die Betriebssystem beziehungsweise Browser vorgeben. Die Einträge für das Land und für den geschlossenen Hinweis entfernst du, indem du die Browserdaten löschst; ohne sie wird das Land wieder so vorausgewählt, wie Ziffer 3 es beschreibt.

6.3 Analyse-Cookies — nur nach Einwilligung

Für die Cookies der Reichweitenmessung gilt § 25 Abs. 2 Nr. 2 TDDDG nicht: eine Reichweitenmessung ist für den von dir angeforderten Dienst nicht erforderlich, die Seite funktioniert ohne sie vollständig. Sie fallen damit unter § 25 Abs. 1 TDDDG und werden erst gesetzt, nachdem du im Einwilligungsbanner zugestimmt hast. Das Banner erscheint auf der ersten Seite, die du aufrufst, und bietet Zustimmen und Ablehnen als zwei gleich große Schaltflächen nebeneinander an — beides ist ein einziger Klick.

6.4 Technisch notwendige Verbindungsdaten

Die Bedienoberfläche wird serverseitig gerendert und hält während der Nutzung eine WebSocket-Verbindung zum Server. Der zugehörige Sitzungszustand liegt ausschließlich im Arbeitsspeicher des Servers, wird nicht auf dem Endgerät gespeichert und endet mit dem Schließen der Seite.

6.5 In der App

Die BrickDb-App für Mobilgeräte und Computer zeigt dieselben Seiten an, legt aber nichts in einem Browserspeicher ab. Die Einstellungen für Darstellung und Sprache liegen dort im Einstellungsspeicher des Betriebssystems und enthalten wie in Ziffer 6.1 nur den zuletzt gewählten Wert.

Meldest du dich in der App an, wird deine Sitzung im geschützten Speicher des Geräts abgelegt — im Schlüsselbund unter iOS und macOS, im Keystore-gesicherten Speicher unter Android. Abgelegt werden vier Dinge: das Zugriffstoken, das Erneuerungstoken, der Ablaufzeitpunkt und die Angabe, über welchen Weg du dich angemeldet hast.

Hinzu kommt das Identitätstoken, und das ist das einzige dieser Elemente, das Angaben zu deiner Person enthält. Es wird bei der Anmeldung von Auth0 ausgestellt und dort abgelegt, weil die App aus ihm liest, wen sie vor sich hat. Es enthält die Kennung deines Kontos beim Identitätsdienstleister, deinen Namen und deine E-Mail-Adresse, die Angabe, ob die Adresse bestätigt ist, sowie einen technischen Einmalwert aus dem Anmeldevorgang. Diese Angaben liegen damit auf dem Gerät, auch wenn sie nach Ziffer 7.1 nicht in unsere Datenbank übernommen werden. Ein Passwort ist nicht darunter, weil die App keines entgegennimmt (Ziffer 7.1).

Alle fünf Elemente werden bei der Abmeldung entfernt. Eine Kopie deiner Sammlung wird auf dem Gerät nicht vorgehalten, und es werden keine Änderungen für eine spätere Übertragung zwischengespeichert.

7. Nutzerkonto

7.1 Anmeldung

BrickDb lässt sich ohne Konto nutzen: Katalog, Suche und Scanner stehen ohne Anmeldung offen. Ein Konto brauchst du erst, um eine eigene Sammlung zu führen.

Die Anmeldung erfolgt über den Identitätsdienstleister Auth0 (Okta, Inc.), über einen Mandanten in der Europäischen Union. Angeboten werden drei Wege: ein Konto mit E-Mail-Adresse und Passwort, die Anmeldung mit einem bestehenden Google-Konto oder die Anmeldung mit deinem Apple Account („Mit Apple anmelden“). Welchen du wählst, entscheidest du. Das gilt für die Website und für die App gleichermaßen.

Das Anmeldeformular ist eine Seite von Auth0, nicht von BrickDb. Ein Passwort wird auf keiner Seite von BrickDb eingegeben, entgegengenommen oder weitergereicht; auch eine Passwortänderung findet bei Auth0 statt. Wer sich über Google oder Apple anmeldet, hat bei Auth0 gar kein Passwort — die Zugangsdaten liegen dann bei Google bzw. Apple, und BrickDb sieht sie ebenso wenig. Bei „Mit Apple anmelden“ kannst du außerdem wählen, deine E-Mail-Adresse zu verbergen: BrickDb erhält dann eine Adresse des Weiterleitungsdienstes von Apple (endend auf @privaterelay.appleid.com), über die Apple unsere E-Mails an dich weiterleitet.

Was BrickDb dabei erhält. Nach einer erfolgreichen Anmeldung übergibt Auth0 die Angaben, die angefordert wurden: eine pseudonyme Kennung deines Kontos, die bei der Anmeldung hinterlegten Profilangaben und deine E-Mail-Adresse. Gespeichert wird davon nichts außer der pseudonymen Kennung und dem Zeitpunkt, zu dem der Datensatz angelegt wurde — das ist der vollständige Inhalt unseres eigenen Kontodatensatzes. Name, Profil und E-Mail-Adresse bleiben bei Auth0 und werden dort gelesen, wenn sie gebraucht werden (Ziffer 7.2); in unsere Datenbank werden sie nicht übernommen.

Zwei-Faktor-Authentifizierung wird angeboten und nie verlangt. Wer möchte, kann eine Authenticator-App (TOTP), einen Geräteschlüssel wie Face ID, Touch ID oder Windows Hello, einen Hardware-Sicherheitsschlüssel und Wiederherstellungscodes hinterlegen. Ohne eine solche Einrichtung wird niemand danach gefragt. Codes per SMS oder per E-Mail werden bewusst nicht angeboten.

Was Auth0 dabei verarbeitet. Auth0 verarbeitet die Anmeldedaten selbst sowie die technischen Daten jedes Anmeldevorgangs — Zeitpunkt, IP-Adresse sowie Browser- und Gerätekennung — um die Anmeldung durchzuführen und missbräuchliche Anmeldeversuche zu erkennen. Bei der Neuanlage eines Kontos und bei jeder Passwortänderung prüft Auth0 zusätzlich, ob das gewählte Passwort in einer bekannt gewordenen Datenpanne aufgetaucht ist, und lehnt es in diesem Fall ab. Bei einer gewöhnlichen Anmeldung findet diese Prüfung nicht statt.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO — ohne Konto lassen sich die Sammlungsfunktionen nicht erbringen. Für die Erkennung missbräuchlicher Anmeldeversuche und die Prüfung auf bekannt gewordene Passwörter Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse besteht in der Sicherheit der Konten. Auth0 ist insoweit Auftragsverarbeiter nach Art. 28 DSGVO.

Drittlandsübermittlung: Der Mandant liegt in der Europäischen Union, und dort findet die Anmeldung statt. Vertragspartnerin ist jedoch die Okta, Inc. (Auth0) mit Sitz in den Vereinigten Staaten, sodass sich ein Zugriff von dort — etwa im Rahmen von Support und Wartung — nicht ausschließen lässt. Okta stützt solche Übermittlungen auf die Standardvertragsklauseln der EU-Kommission, die dem Auftragsverarbeitungsvertrag vom 15. Dezember 2023 als eigene Dokumente beigefügt sind.

Speicherdauer: Der Kontodatensatz besteht, bis du dein Konto löschst. Die Löschung auf der Kontoseite löscht auch das Konto bei Auth0 und damit die dort hinterlegten Angaben (Ziffer 14).

7.2 Profil: Name, Über-mich-Text, Land und optionale Anschrift

Du kannst einen Vornamen, einen Nachnamen, einen kurzen Text über dich, dein Land, eine unserer Avatar-Zeichnungen und — optional — eine vollständige Postanschrift hinterlegen.

Nichts davon wird bei BrickDb gespeichert. Diese Angaben liegen beim Identitätsdienstleister Auth0 bei deinem Anmeldekonto; BrickDb liest und schreibt sie dort, statt eine Kopie zu halten: unser eigener Kontodatensatz enthält nichts außer einer pseudonymen Kennung und dem Zeitpunkt seiner Anlage. Wenn du dein Konto nach Abschnitt 14 löschst, wird das Auth0-Konto gelöscht und mit ihm dieses Profil.

Jede Angabe ist freiwillig. Nichts davon ist erforderlich, nichts ist Voraussetzung für die Nutzung von BrickDb, und es wird dir keine Funktion vorenthalten, wenn du ein Feld leer lässt. Du kannst jede Angabe jederzeit ändern oder löschen.

Warum insbesondere nach der Anschrift gefragt wird. Zwei Zwecke, beide hier genannt, bevor das Feld angeboten wird, und nicht erst danach:

• Versicherungsbewertung. BrickDb wird eine Bewertung einer Sammlung zu Versicherungszwecken anbieten. Eine solche Bewertung ist an den Ort gebunden, an dem die Sammlung aufbewahrt wird; ein Versicherer akzeptiert sie ohne diese Angabe nicht.
• Ein geplanter Marktplatz mit BrickDb als Treuhänder. BrickDb beabsichtigt, einen Marktplatz anzubieten, auf dem BrickDb als Treuhänder zwischen Käufer und Verkäufer auftritt. Die Postanschrift einer Partei ist das, was ein solches Geschäft zurechenbar und einen Streitfall klärbar macht.

Beide Angebote bestehen noch nicht. Die Anschrift wird für nichts anderes verwendet: nicht für Werbung, nicht für Profilbildung, nicht für irgendeine Form von Scoring, und sie wird nicht an Dritte weitergegeben.

Dein Land wird außerdem verwendet, um ein Land vorauszuwählen — auf der Eventliste und für die Preise auf den Seiten von Sets und Minifiguren, vor der in Ziffer 3 beschriebenen Sprachpräferenz des Browsers. Es wird dafür beim Aufruf einer solchen Seite bei Auth0 gelesen, von BrickDb dafür nicht gespeichert und nicht weitergegeben, und die Auswahl lässt sich auf der Seite mit einem Klick aufheben.

Land und Sprache, die du auf der Seite auswählst. Wenn du angemeldet ein Land und eine Sprache für die Seite auswählst und speicherst, wird beides zusätzlich zu den Einträgen im Browser (Ziffer 6.1) bei deinem Anmeldekonto bei Auth0 abgelegt, damit die Auswahl auch auf einem anderen Gerät und unter einer anderen Adresse von BrickDb gilt. BrickDb hält auch davon keine eigene Kopie. Bist du nicht angemeldet, bleibt die Auswahl allein im Browser.

Rechtsgrundlage: für Vorname, Nachname, Über-mich-Text, Land und die gewählte Sprache Art. 6 Abs. 1 lit. b DSGVO — die Verarbeitung gehört zur angeforderten Leistung. Für die Anschrift Art. 6 Abs. 1 lit. a DSGVO — Einwilligung, erteilt durch das Ausfüllen des Feldes und jederzeit widerrufbar durch dessen Löschen. Der Widerruf berührt dein Konto im Übrigen nicht und lässt die Rechtmäßigkeit der bis dahin erfolgten Verarbeitung unberührt.

Das Profil ist in der Kopie deiner Daten nach Abschnitt 14 enthalten und wird nach demselben Abschnitt mit deinem Konto gelöscht.

7.3 E-Mail-Versand

BrickDb versendet E-Mails nur, wenn es dafür einen konkreten Anlass gibt: die Bestätigung deiner E-Mail-Adresse und das Zurücksetzen deines Passworts, eine Einladung zu einer Sammlung, wenn dich jemand dazu einlädt (Ziffer 8.1a), eine Einladung, dein Passwort zu wählen, wenn die Administration ein Konto für dich anlegt (Ziffer 8.9), unsere Antwort auf eine Supportanfrage sowie eine Meldung an unser eigenes Postfach, wenn jemand eine solche einreicht — diese letzte richtet sich an uns und nicht an dich, enthält aber das, was die anfragende Person geschrieben hat (Ziffer 8.7 behandelt beide) —, eine Meldung an unser eigenes Postfach, wenn jemand einen Inhalt meldet, und die Begründung an dich, wenn einer Meldung über einen Inhalt stattgegeben wird, den du veröffentlicht hast (beides Ziffer 8.8). Es gibt keinen Newsletter und keine Werbe-E-Mails.

Versanddienstleister ist die Twilio Inc. („SendGrid“), 101 Spear Street, 5th Floor, San Francisco, CA 94105, USA. SendGrid erhält dafür die Empfängeradresse, einen Anzeigenamen, soweit einer vorhanden ist, den Betreff und den vollständigen Inhalt der Nachricht sowie die technischen Zustelldaten (Zeitpunkt, Zustellstatus, Antwort des empfangenden Mailservers). Deine E-Mail-Adresse wird damit an einen Dritten weitergegeben, und zwar als Erstes — noch bevor irgendetwas anderes mit ihr geschieht. Deshalb steht das hier und nicht erst unter Ziffer 12.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO — die Bestätigung einer Adresse, das Zurücksetzen eines Passworts und die Zustellung einer Einladung gehören zur angeforderten Leistung. SendGrid ist insoweit Auftragsverarbeiter nach Art. 28 DSGVO auf Grundlage des Twilio Data Protection Addendum.

Drittlandsübermittlung: Der Versand läuft über die globale Infrastruktur von SendGrid; die Verarbeitung findet damit in den Vereinigten Staaten statt und nicht, wie das Hosting nach Ziffer 4, in Deutschland. Twilio stützt solche Übermittlungen auf die Standardvertragsklauseln der EU-Kommission und ist zusätzlich unter dem EU-US Data Privacy Framework zertifiziert.

Öffnungs- und Klickmessung: bei Konto-E-Mails ja, bei unseren eigenen nein. E-Mails zu deinem Konto — Bestätigung der Adresse, Passwort zurücksetzen — werden von SendGrid vor dem Versand um ein unsichtbares Bild ergänzt, und ihre Links werden über SendGrid umgeleitet. Zeigt dein E-Mail-Programm eine solche Nachricht an, lädt es dieses Bild und übermittelt dabei Zeitpunkt und IP-Adresse an SendGrid; dasselbe geschieht beim Anklicken eines Links. Bei SendGrid entsteht daraus die Information, ob und wann eine solche Nachricht geöffnet wurde. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO — unser berechtigtes Interesse daran, dass Konto-E-Mails ankommen und nicht im Spam-Ordner landen. Du kannst dem nach Art. 21 DSGVO über die Kontaktdaten in Ziffer 2 widersprechen, und du kannst das Nachladen von Bildern in deinem E-Mail-Programm abschalten — dann findet die Öffnungsmessung nicht statt.

E-Mails, die BrickDb selbst versendet, enthalten weder ein solches Bild noch umgeleitete Links — heute sind das die Einladungen zu einer Sammlung, die beiden Supportmails nach Ziffer 8.7, unsere Antwort auf eine Anfrage und die Meldung, die sie uns schickt, sowie die beiden Mails zu Meldungen nach Ziffer 8.8. Keine von ihnen fordert beim Öffnen von einem Server irgendetwas an; jeder Versand schaltet beide Messungen bei SendGrid ausdrücklich ab.

Speicherdauer: BrickDb legt keine Kopie einer versendeten Nachricht an. Beim Versanddienstleister bleiben die Zustelldaten für einen kurzen, von dessen Tarif abhängigen Zeitraum in dessen Aktivitätsprotokoll abrufbar.

Stand dieser Fassung: Diese Ziffer beschreibt den Versandweg, wie er derzeit besteht. Bis die oben genannte Meldung zu einer Supportanfrage hinzukam, hieß es hier „wie er seit dem 10. September 2026 besteht“.

8. Sammlungsdaten und Fotos

Die folgenden Angaben beschreiben die Verarbeitung, die mit einem Konto nach Ziffer 7 stattfindet.

8.1 Sammlungsdaten

Gespeichert wird, was selbst eingetragen wird: Setnummer, Bezeichnung, Zustandsangaben, Notizen, Anschaffungsdatum, gezahlter Preis, Hinweise zum Verkäufer sowie die Zeitpunkte der Erstellung und der letzten Änderung. Diese Angaben sind mit einer pseudonymen Kennnummer verknüpft.

Auf dieselbe Weise gespeichert wird, was du zu den übrigen Bereichen einträgst: einzelne Minifiguren und lose Teile mit denselben Angaben, Exemplare von Magazinausgaben und Büchern mit ihrer Zustandsnote, dem Zustand einer beiliegenden Polybag, deinen Anmerkungen zum Zustand, wie und wann du sie erworben hast, dem gezahlten Preis, dem Hinweis zum Verkäufer und deinen Notizen, Sammlungen mit ihrem Namen, ihrer Beschreibung, ihrer Sichtbarkeit nach Ziffer 8.1a und ihren Mitgliedern samt deren Rolle, Einladungen, die du ausgesprochen hast, samt der dafür angegebenen E-Mail-Adresse, Signaturen, die du zu einem Exemplar erfasst, deine Merkliste, deine Beiträge zur Auflösung von Tütencodes und Verpackungsbarcodes, und die Stapelverarbeitungen von Verpackungsfotos, die du anstößt.

Exemplare von Magazinausgaben und Büchern liegen in keiner Sammlung; nur du siehst sie.

Lagerorte. Du kannst festhalten, wo deine Sachen aufbewahrt werden: Räume, Orte in einem Raum und Fächer an einem Ort, jeweils mit dem Namen, den du vergibst, ihrer Ebene und ihrer Position in deiner Liste, und zu jedem Exemplar — Sets, Minifiguren, lose Teile, Magazinausgaben und Bücher —, an welchem Ort es liegt. Deine Lagerorte gehören dir, nicht einer Sammlung: Nur du kannst sie anlegen, ändern oder zuweisen. Wo ein Exemplar in einer geteilten Sammlung liegt, sehen — nur lesend — die Mitglieder, deren Rolle in dieser Sammlung Eigentümer oder Bearbeiter ist; Mitglieder mit der Rolle Lesend oder Versicherung sehen es nie, und eine veröffentlichte Sammlung zeigt es nie (Ziffer 8.1a). Löschst du dein Konto (Ziffer 14), werden deine Lagerorte gelöscht, und zuvor wird der Ort bei jedem Exemplar entfernt, das ihn nannte — auch bei einem Exemplar, das in einer mit anderen geteilten Sammlung bleibt.

Freitextfelder werden nicht ausgewertet. Es wird gebeten, dort keine besonderen Kategorien personenbezogener Daten im Sinne des Art. 9 DSGVO einzutragen.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO — die Verarbeitung ist zur Erbringung des angeforderten Dienstes erforderlich.

8.1a Wer eine Sammlung sehen kann

Jedes Exemplar, das dir gehört, liegt in einer Sammlung, und eine Sammlung hat eine von drei Einstellungen, die du wählst und jederzeit ändern kannst: privat (nur ihre Mitglieder sehen sie — die Vorgabe für eine neue Sammlung), alle mit dem Link oder alle, auch Suchmaschinen.

Eine öffentlich gestellte Sammlung zeigt ihren Namen und ihre Beschreibung, die Setnummern, die Setnamen, wie viele Exemplare du von jedem hast und in welchem Zustand sie sind — und sonst nichts. Keine Fotos, keine Notizen, keine Schlagworte, keine selbst vergebenen Namen, keine Aufbewahrungsorte, keine gezahlten Preise, keine Wertschätzungen, keine Erwerbsdaten und nichts über die Verkäuferseite. Sie nennt weder dich noch ein anderes Mitglied und sagt auch nicht, wie viele Personen dabei sind. Diese Felder werden auf jener Seite nicht etwa ausgeblendet — sie werden gar nicht erst dorthin übertragen.

Ein Link ist kein Passwort. Eine Sammlung mit der Einstellung „alle mit dem Link“ wird an jede Person ausgeliefert, die diese Adresse aufruft — ob du sie ihr gegeben hast oder nicht. Diese Einstellung bittet Suchmaschinen zusätzlich, die Seite nicht aufzunehmen; daran halten sie sich in der Regel und sind dazu nicht verpflichtet. Eine Sammlung wieder auf privat zu stellen beendet die Auslieferung sofort, holt aber keine Kopie zurück, die jemand — oder eine Suchmaschine — bereits genommen hat.

Eine mit namentlichen Mitgliedern geteilte Sammlung ist etwas anderes als eine öffentliche: Was ein Mitglied sieht, hängt von der Rolle ab, die du vergeben hast. Lesend sieht genau das, was auch die öffentliche Seite zeigt. Bearbeiter sehen alles, einschließlich der oben aufgezählten Felder. Versicherung sieht die Sets, ihren Zustand und Bewertungszahlen, sonst nichts.

Eine öffentliche Sammlung kann gemeldet werden. Ihre Seite trägt das Meldeformular aus Ziffer 8.8, das jede Person benutzen kann, die die Seite sehen kann. Gibt die Administration einer Meldung dazu statt, wird die Sammlung wieder auf privat gestellt; gelöscht wird nichts, und du kannst sie wieder veröffentlichen.

Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO — du willigst ein, indem du die Einstellung wählst, und widerrufst, indem du sie zurücksetzt.

8.2 Fotos

Hochgeladene Fotos werden dir und den Mitgliedern der Sammlung angezeigt, deren Rolle die privaten Angaben umfasst — das sind Eigentümer und Bearbeiter nach Ziffer 8.1a. Liegt das Exemplar in einer Sammlung, in der sonst niemand ist, sieht das Foto nur, wer es hochgeladen hat. Auf der öffentlichen Seite einer Sammlung erscheinen Fotos nicht, und ebenso wenig sehen sie Mitglieder mit der Rolle Leser oder Versicherung. Fotos werden nicht veröffentlicht, nicht an Dritte weitergegeben und nicht zum Trainieren von Modellen verwendet.

Metadaten werden entfernt. Beim Hochladen wird jedes Bild neu kodiert: die im Bild vermerkte Ausrichtung wird fest in die Bilddaten übernommen und anschließend das gesamte Metadatenprofil entfernt — EXIF, IPTC und XMP, und damit insbesondere GPS-Koordinaten, Aufnahmezeitpunkt und Gerätekennungen. Gespeichert wird nur das bereinigte Bild; die ursprünglich übertragene Datei wird nicht aufbewahrt.

Der ursprüngliche Dateiname wird nicht übernommen. Jede Datei erhält eine zufällig erzeugte Kennung; aus dem Speicherpfad lässt sich nichts über die hochladende Person oder die Herkunft der Datei ableiten.

Verkleinerte Fassungen. Für die Darstellung werden bei Bedarf verkleinerte Fassungen eines Fotos erzeugt und zwischengespeichert. Sie enthalten dieselben — bereits von Metadaten bereinigten — Bilddaten, unterliegen denselben Zugriffsbeschränkungen und werden gemeinsam mit dem Foto gelöscht.

Bilder in einem Format, das sich nicht neu kodieren lässt — dazu zählt HEIC/HEIF, das Standardformat neuerer iPhones — werden abgelehnt statt gespeichert. Die Fehlermeldung nennt die akzeptierten Formate (JPEG, PNG, WebP, GIF). Es wird also nichts abgelegt, das nicht zuvor bereinigt wurde.

Zu jedem Foto werden gespeichert: die zufällige Dateikennung, eine selbst vergebene Bildunterschrift, die Sortierung und der Zeitpunkt des Hochladens.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.

8.3 Avatarbild

Du kannst ein eigenes Bild als Avatar hochladen oder eine der von BrickDb bereitgestellten Zeichnungen verwenden. Die bereitgestellten Zeichnungen sind unsere eigenen Grafiken und keine personenbezogenen Daten; ein hochgeladenes Bild ist es.

Ein hochgeladener Avatar durchläuft dieselbe Bereinigung wie jedes andere Foto: Die Ausrichtung wird in die Bilddaten übernommen und das gesamte Metadatenprofil — EXIF, IPTC und XMP und damit insbesondere GPS-Koordinaten, Aufnahmezeitpunkt und Gerätekennungen — wird entfernt. Anschließend wird das Bild auf sein mittleres Quadrat zugeschnitten, auf 256 × 256 Pixel verkleinert und als WebP neu kodiert. Gespeichert wird nur dieses Bild; die übertragene Datei wird nicht aufbewahrt, und ein Bild, das sich nicht neu kodieren lässt, wird abgelehnt statt gespeichert.

Wer ihn sehen kann. Ein Avatar wird gespeichert, damit er neben deinem Namen angezeigt werden kann. BrickDb hat derzeit keine Ansicht, in der eine Person das Profil einer anderen sieht — heute siehst also nur du deinen eigenen. Sobald sich das ändert, wird dieser Abschnitt das ausdrücklich sagen: Ein Avatar ist dafür gedacht, für andere sichtbar zu sein, und genau deshalb steht er hier getrennt von 8.2.

Pro Konto wird genau ein Avatar gespeichert; ein weiterer Upload ersetzt ihn. Er ist in der Kopie deiner Daten nach Abschnitt 14 enthalten und wird gelöscht, wenn du dein Konto nach Abschnitt 14 löschst.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.

8.4 Veranstaltungsvorschläge

Bei der Einreichung einer Veranstaltung speichern wir Titel, optionale Beschreibung, Veranstaltungsort, Land und Zeitplan. Bei einer ganztägigen Veranstaltung sind dies das Startdatum sowie das nicht eingeschlossene Enddatum. Bei einer Veranstaltung mit Uhrzeit sind dies Beginn- und Endzeitpunkte sowie die Zeitzone des Veranstaltungsorts. Hinzu kommen der optionale Anmeldebeginn, Quell-URL, die Verknüpfung zum Konto und der Einreichungszeitpunkt. Wir speichern außerdem den Moderationsstatus, den Zeitpunkt einer Moderationsentscheidung und einen internen Benachrichtigungsauftrag für die Prüfwarteschlange. Dieser Auftrag versendet keine E-Mail.

Die Administration prüft Vorschläge manuell. Ausstehende und abgelehnte Vorschläge sind nicht öffentlich. Nach der Genehmigung sind die Veranstaltungsangaben und die Quell-URL öffentlich sichtbar; die Kontoidentität wird nicht veröffentlicht. Bitte reiche nur Veranstaltungsangaben ein, die du veröffentlichen darfst, ohne persönliche Kontaktdaten oder private Informationen über dich oder andere.

Einreichung und Moderation erbringen den angeforderten Dienst (Art. 6 Abs. 1 lit. b DSGVO). Der Erhalt des genehmigten öffentlichen Kalenders dient unserem und dem berechtigten Interesse anderer Besucher an verlässlichen Veranstaltungsinformationen (Art. 6 Abs. 1 lit. f DSGVO). Gegen eine Verarbeitung auf Grundlage berechtigter Interessen kannst du über die Kontaktdaten in Ziffer 2 Widerspruch einlegen. Der Datenexport nach Art. 15 DSGVO auf der Kontoseite enthält die eigenen Veranstaltungsvorschläge in jedem Moderationsstatus.

Bei der Kontolöschung werden ausstehende und abgelehnte Vorschläge samt ihren Benachrichtigungsaufträgen gelöscht. Genehmigte Veranstaltungen bleiben öffentlich erhalten; die Verknüpfung zur einreichenden Person wird anonymisiert: Ein neuer Zufallswert ersetzt sie, ohne Konto oder Zuordnung zurück zur Person. Die genehmigten Angaben bleiben für andere Besucher im Kalender; für diesen anonymisierten Datensatz besteht keine feste Ablauffrist. Für Sicherungskopien gilt Ziffer 13. Die weiteren Rechte aus Ziffer 14 bleiben bestehen.

8.5 Setnummer aus einem Foto lesen

Wenn du ausdrücklich ein Foto einer Verkaufsverpackung zum Lesen der Setnummer einreichst, überträgt BrickDb höchstens 8 MB vom Browser an die eigenen Web- und API-Server. Der API-Server reicht das Foto unverändert an einen dritten eigenen Server weiter, den Lesedienst (die Container-App „brickdb-ocr“). Er läuft in derselben Azure-Umgebung und derselben Region (Germany West Central, Frankfurt am Main) wie die übrigen Server nach Ziffer 4, ist nur aus dieser Umgebung heraus erreichbar und hat keinen Zugriff auf Datenbank oder Dateiablage. Wie Web- und API-Server hält auch der Lesedienst das Bild ausschließlich im Arbeitsspeicher; er gibt dem API-Server nur die darauf gelesenen möglichen Setnummern zurück, und sein Protokolleintrag hält nur fest, wie die Anfrage ausging (etwa gelesen oder abgewiesen) und wie lange sie dauerte, nichts über das Foto. Auf keinem der drei Server wird das Bild gespeichert, protokolliert oder zum Trainieren von Modellen verwendet; es wird nicht an Dritte übermittelt und nach Ende der Anfrage verworfen. Alle drei Server betreiben wir selbst auf Microsoft Azure; Microsoft ist dabei Auftragsverarbeiter nach Ziffer 4. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO — die Verarbeitung erbringt die von dir angeforderte Leseleistung.

Damit diese rechenintensive Funktion verfügbar bleibt, erlaubt jeder Serverprozess sechs Anfragen pro ursprünglicher IP-Adresse innerhalb einer gleitenden Minute. Diese Grenze prüfen sowohl der Webserver als auch der API-Server, weil der API-Server auch direkt erreichbar ist. Jeder Serverprozess zählt für sich, und von jedem Server können mehrere Prozesse gleichzeitig laufen; die Grenze gilt deshalb je Prozess und nicht als eine Gesamtzahl für ganz BrickDb. Damit der API-Server bei einer Anfrage über den Webserver deine Adresse zählt und nicht die des Webservers, übergibt der Webserver ihm deine Adresse zusammen mit der Anfrage; der Lesedienst erhält sie nicht. Auf beiden Servern wird die Adresse — bei IPv6 nur ihr Netzanteil — nur als Schlüssel im Arbeitsspeicher des jeweiligen Serverprozesses gehalten; sie wird weder protokolliert, dauerhaft gespeichert noch an Dritte weitergegeben. Nach einer Minute beeinflusst sie keine Entscheidung mehr und wird entfernt, wenn diese Adresse erneut anfragt oder die anfragegesteuerte Bereinigung Platz benötigt. Jeder Serverprozess hält höchstens 1.024 Adressschlüssel; solange alle Plätze noch aktiv sind, wird eine neue Adresse abgewiesen, statt eine davon zu verdrängen. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse ist die technisch sichere, verlässliche und faire Verfügbarkeit des Dienstes.

8.6 Vorschlag zum Zustand einer Verpackung aus einem Foto

Getrennt vom Lesen der Setnummer kannst du für ein Foto einer Verkaufsverpackung ausdrücklich einen Vorschlag anfordern, in welchem sichtbaren Zustand der Karton ist. Nur wenn du diese Bewertung angefordert und die Anfrage bestätigt hast, überträgt BrickDb das Foto von seinem eigenen API-Server an den Dienst Azure OpenAI der Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irland, als Auftragsverarbeiterin nach Art. 28 DSGVO. Vorher wird das Bild neu kodiert, von allen Metadaten befreit und auf höchstens 1.024 Pixel Kantenlänge verkleinert. Die Verbindung wird vom Server aufgebaut, nicht von deinem Browser; der Aufruf einer Seite löst sie nie aus.

Die Verarbeitung findet in der EU-Datenzone von Azure statt, also innerhalb der EU; die Bereitstellung ist in der Region Germany West Central angelegt, die Verarbeitung kann in jedem EU-Mitgliedstaat erfolgen. Nach Angaben von Microsoft werden Eingaben und Ausgaben nicht zum Trainieren der Modelle verwendet und nicht an die Anbieter der Modelle weitergegeben. Standard-Missbrauchsüberwachung: Microsoft prüft Eingaben automatisiert auf missbräuchliche Nutzung. Eine Eingabe, die dabei beanstandet wird, kann Microsoft als Stichprobe aufbewahren und durch autorisierte Mitarbeitende von Microsoft im EWR prüfen lassen; Microsoft nennt dafür keine feste Höchstdauer. Darüber hinaus behält der Dienst das Foto nicht.

BrickDb selbst bleibt zustandslos: das Foto und das Ergebnis werden bei BrickDb nicht gespeichert, nicht protokolliert und nicht zum Trainieren von Modellen verwendet; beides wird mit Ende der Anfrage verworfen. Das Ergebnis ist ein experimenteller, nicht kalibrierter Vorschlag allein zum sichtbaren Zustand der Verpackung — es gibt keine gemessene Trefferquote, es sagt nichts über Inhalt, Versiegelung oder Vollständigkeit aus, es trägt nichts in deine Sammlung ein, und du übernimmst oder ersetzt es ausdrücklich selbst. Bitte fotografiere nur die Verpackung: keine Personen, Anschriften oder anderen personenbezogenen Angaben, und nur Bilder, die du einreichen darfst.

Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO — deine Einwilligung, die du mit jeder einzelnen Anfrage erteilst. Sie ist freiwillig; ohne sie wird kein Foto übertragen und die Zustandsfrage bleibt eine Angabe, die du selbst machst. Für die Zukunft widerrufst du sie, indem du keine weitere Bewertung anforderst. Sie ist keine Einwilligung in ein Training; ein späteres, gesondert widerrufbares Opt-in wäre eine eigene Erklärung.

8.7 Supportanfragen

Auf der Supportseite gibt es ein Formular für Supportanfragen, und du kannst es ohne Konto und ohne Anmeldung benutzen. Es fragt nach einer E-Mail-Adresse für die Antwort, einem Betreff und deiner Nachricht; ein Name ist freiwillig. Nach der Sprache fragt es nicht — sie ergibt sich aus der Sprache, in der die Seite angezeigt wurde, damit die Antwort in der Sprache erfolgt, in der du gefragt hast. Wenn du uns stattdessen an die Adresse in Ziffer 2 schreibst, erreichst du uns genauso gut, es entsteht daraus aber kein Vorgang; diese Nachricht ist dann schlicht eine E-Mail in unserem Postfach.

Was du absendest, speichern wir als Vorgang mit einer Vorgangsnummer: die E-Mail-Adresse für die Antwort, den freiwilligen Namen, die Sprache, in der du geschrieben hast, den Betreff, den Text deiner Anfrage, den Bearbeitungsstand, den Eingangsweg sowie die Zeitpunkte von Eingang und Abschluss.

Kein Vorgang ist in dieser Version mit einem Nutzerkonto verknüpft — auch keiner, den du angemeldet abschickst. Die Route, die das Formular entgegennimmt, steht allen offen und stellt überhaupt keine Anmeldung fest, sodass das dafür vorgesehene Feld leer bleibt. Was daraus für deine Rechte folgt, steht unten im Absatz zur Löschung. Zu einem Vorgang gehört außerdem ein Feld für einen Zugriffsschlüssel zu einer Statusseite, und auch ein solcher Schlüssel wird in dieser Version nicht ausgegeben, sodass auch dieses Feld leer bleibt. Würde einer ausgegeben, würde davon nur die Prüfsumme gespeichert, nie der Schlüssel selbst.

Jemand erfährt sofort davon. Ein Vorgang, den du einreichst, wird uns per E-Mail an unser eigenes Postfach gemeldet, damit er nicht unbemerkt liegen bleibt. Diese Meldung enthält die Vorgangsnummer, die von dir angegebene Adresse und den Namen, deinen Betreff und den vollständigen Text deiner Nachricht. Versendet wird sie über den in Ziffer 7.3 genannten Maildienstleister, sodass diese Angaben in den Vereinigten Staaten auf der dort beschriebenen Grundlage verarbeitet werden. Anders als die Konto-E-Mails in jener Ziffer enthält sie kein unsichtbares Bild und keine umgeleiteten Links. Was du selbst zu sehen bekommst, ist die Vorgangsnummer auf der Seite, sobald das Formular abgeschickt ist; unsere Antwort an dich ist eine eigene E-Mail, unten unter „Wie wir antworten“.

Schutz vor Masseneinsendungen. Damit das Formular nicht dazu benutzt werden kann, uns zu überschwemmen, erlaubt BrickDb fünf Einsendungen je Internetanschluss in einer gleitenden Viertelstunde. Dafür hält es eine verkürzte Form deiner IP-Adresse als Schlüssel im Arbeitsspeicher eines Webprozesses — bei IPv6 nur den Netzanteil, bei IPv4 die Adresse. Sie wird nicht protokolliert, nicht in den Vorgang geschrieben, nicht in der Datenbank gespeichert und nicht weitergegeben, und nach Ablauf der Viertelstunde beeinflusst sie keine Entscheidung mehr. Es werden höchstens 1.024 solcher Schlüssel gehalten; sind alle Plätze belegt, wird ein neuer abgewiesen, statt einen bestehenden zu verdrängen. Ein Captcha gibt es nicht, und es wird dafür nichts von Dritten nachgeladen. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse ist die technisch einwandfreie, sichere und faire Verfügbarkeit des Angebots.

Rechtsgrundlage: Bearbeitung und Beantwortung deiner Anfrage (Art. 6 Abs. 1 lit. b DSGVO, soweit sie dein Nutzungsverhältnis betrifft, sonst Art. 6 Abs. 1 lit. f DSGVO — unser berechtigtes Interesse daran, Anfragen zu diesem Angebot beantworten zu können). Gegen eine Verarbeitung auf Grundlage berechtigter Interessen kannst du über die Kontaktdaten in Ziffer 2 Widerspruch einlegen.

Speicherdauer: Ein abgeschlossener Vorgang wird 24 Monate nach seinem Abschluss gelöscht. Die Frist läuft ab dem Abschluss, nicht ab dem Eingang — ein Vorgang, auf den du noch wartest, wird nicht gelöscht, wie alt er auch ist. Die Löschung erfolgt im Rahmen einer turnusmäßigen Bereinigung und damit gegebenenfalls einige Tage nach Fristablauf, nie davor. Für Sicherungskopien gilt Ziffer 13.

Bei der Kontolöschung nach Art. 17 DSGVO werden durch das Löschen deines Kontos auf der Kontoseite alle Vorgänge anonymisiert, die mit deinem Konto verknüpft sind: E-Mail-Adresse, Name und diese Verknüpfung werden entfernt und der Zugriffsschlüssel wird ungültig, während der Vorgang selbst anonymisiert statt gelöscht wird, weil Betreff, Text und unsere Antworten unser eigener Nachweis eines Gesprächs sind, an dem auch wir beteiligt waren. Da in dieser Version kein Vorgang eine solche Verknüpfung trägt, greift dieser Schritt praktisch ins Leere: Eine Supportanfrage ist weder im Datenexport nach Art. 15 DSGVO noch in der Kontolöschung auf der Kontoseite enthalten — unabhängig davon, ob du beim Absenden angemeldet warst. Die Aufstellung dessen, was der Export nicht enthält, nennt Supportanfragen aus genau diesem Grund.

Deine Rechte aus Ziffer 14 bestehen unverändert, und so nimmst du sie für einen Vorgang wahr: Wende dich über die Kontaktdaten in Ziffer 2 an uns und nenne die Vorgangsnummer oder die verwendete Adresse. Eines solltest du dabei wissen — das Entfernen von Feldern anonymisiert keinen Freitext. Wenn du in der Anfrage selbst deinen Namen, eine Bestellnummer oder andere Angaben über dich geschrieben hast, stehen diese weiterhin im Text. Sag uns Bescheid, wenn das so ist; wir schwärzen oder löschen den betreffenden Vorgang dann von Hand.

Interne Notizen: Während ein Vorgang bearbeitet wird, schreiben wir uns außerdem Notizen dazu — was versucht wurde, was wir gefunden haben, auf welchen Bearbeitungsstand wir den Vorgang gesetzt haben und wer das war. Diese Notizen sind unsere und nicht deine: Sie hängen an der Person, die sie geschrieben hat, sie werden nie Teil einer Antwort an dich, und sie sind deshalb weder in deinem Datenexport nach Art. 15 DSGVO noch werden sie bei deiner Kontolöschung anonymisiert. Gelöscht werden sie zusammen mit dem Vorgang, zur selben Frist. Wenn du wissen möchtest, ob eine Notiz dich namentlich nennt, schreib uns über die Kontaktdaten in Ziffer 2 und nenne die Vorgangsnummer.

Wie wir antworten: Wir antworten per E-Mail an die Adresse, die du angegeben hast, und in der Sprache, in der du geschrieben hast. Diese Antwort zitiert deinen Betreff und deine Nachricht noch einmal, damit du den Vorgang wiederfindest — beim Absenden bekommst du keine Kopie davon. Unsere Antwort enthält keinen Link und kein Tracking: Es wird nichts nachgeladen, und ob du sie öffnest, erfahren wir nicht. Wenn danach noch etwas offen ist, antworte einfach auf diese E-Mail und lass die Vorgangsnummer im Betreff stehen.

Mails an die Support-Adresse: Mails an support@brickdb.net — auch eine Antwort auf eine unserer Antworten, die dorthin gehen soll — werden zu einem Vorgang. Unser Mail-Dienstleister (Ziffer 7.3) nimmt sie für die Subdomain support.brickdb.net in unserem Auftrag entgegen und übergibt sie an BrickDb; sie werden daher auf der dort beschriebenen Grundlage in den USA verarbeitet. Trägt der Betreff die Nummer eines offenen Vorgangs, kommt die Mail von dessen eigener Adresse und hat die Domain des Absenders sie signiert oder zugelassen (DKIM oder SPF, beim Empfang geprüft), wird sie diesem Vorgang hinzugefügt; jede andere Mail eröffnet einen neuen, und der Vorgang vermerkt, ob sich der Absender so bestätigen ließ. Gespeichert werden Adresse und Name des Absenders, der Betreff, die Sprache, die die Mail angibt, und ihr Text — nie ihre Anhänge: Ein Anhang wird nirgends gespeichert, der Vorgang vermerkt nur, wie viele es waren. Eine Mail, die unsere Spamprüfung als Spam einstuft, die von einer unserer eigenen Adressen kommt oder die eintrifft, nachdem in der letzten Stunde schon fünf Mails vom selben Absender (oder sechzig insgesamt) angenommen wurden, wird kein Vorgang; damit eine echte Anfrage, die so hängen bleibt, trotzdem gefunden und beantwortet werden kann, halten wir kurz fest, wann sie kam, warum sie abgelehnt wurde, die Adresse des Absenders und den Betreff — nie den Text —, und zwar für 30 Tage. Rechtsgrundlage, Speicherdauer und deine Rechte sind im Übrigen die des Formulars oben.

Stand dieser Fassung: Das Formular für Supportanfragen auf /support ist in Betrieb, und die oben beschriebene Antwort per E-Mail ebenfalls. Du erreichst uns weiterhin auch über die Kontaktdaten in Ziffer 2 und im Impressum — das ist der Weg, wenn das Formular deine Anfrage aus irgendeinem Grund nicht annimmt.

8.8 Meldungen zu Inhalten

Zu jeder Veranstaltung auf der Veranstaltungsseite gehört ein Meldeformular, ebenso zur Seite jeder veröffentlichten Sammlung (Ziffer 8.1a), und du kannst es ohne Konto und ohne Anmeldung benutzen — worum es bei einer Meldung geht, kann auch sehen, wer nicht angemeldet ist, sodass eine Hürde davor genau die Person aussperren würde, für die es das Formular gibt. Gefragt wird nach einem Grund aus einer festen Liste, einer freiwilligen Beschreibung dessen, was nicht stimmt, und einer freiwilligen E-Mail-Adresse. Nur bei einem einzigen Grund — „Etwas anderes“ — ist die Beschreibung Pflicht, weil eine Meldung, deren ganzer Inhalt dieses Wort ist, erst gelesen werden müsste, bevor sie einsortiert werden kann. Nach der Sprache fragt es nicht — sie ergibt sich aus der Sprache, in der die Seite angezeigt wurde.

Was du absendest, speichern wir als Meldung mit einer eigenen Referenz, die aussieht wie BDR-000042: um welche Art von Inhalt es geht und dessen eigenen Schlüssel, den von dir gewählten Grund, deine Beschreibung, falls du eine geschrieben hast, die E-Mail-Adresse, falls du eine angegeben hast, die Sprache, in der du geschrieben hast, den Bearbeitungsstand sowie die Zeitpunkte von Eingang und Entscheidung. Eine Beschreibung darf höchstens 2.000 Zeichen lang sein, eine Adresse höchstens 254; alles Längere wird unter Nennung des Feldes abgewiesen, statt gekürzt gespeichert zu werden.

Keine Meldung ist mit einem Nutzerkonto verknüpft — auch keine, die du angemeldet abschickst. Die Route, die das Formular entgegennimmt, steht allen offen und stellt überhaupt keine Anmeldung fest, und ein Feld für eine solche Verknüpfung gibt es nicht: BrickDb weiß bewusst nicht, welche Meldung von dir war. Was daraus für deine Rechte folgt, steht unten im Absatz zu Export und Löschung. Es gibt außerdem keine Statusseite zu einer Meldung und keinen Zugriffsschlüssel dafür, also wird auch nichts dergleichen gespeichert.

Jemand erfährt sofort davon. Eine Meldung, die du abschickst, wird uns per E-Mail an unser eigenes Postfach gemeldet, damit sie nicht unbemerkt liegen bleibt. Diese Meldung enthält die Referenz, die Art des Inhalts, den Grund, den Schlüssel des gemeldeten Inhalts und den vollständigen Text deiner Beschreibung. Sie enthält keine Adresse von dir: Die Nachricht geht an uns, und deine Adresse bleibt in der Warteschlange, wo nur eine Administratorin sie sehen kann. Versendet wird sie über den in Ziffer 7.3 genannten Maildienstleister, sodass diese Angaben in den Vereinigten Staaten auf der dort beschriebenen Grundlage verarbeitet werden; wie die Supportmeldung enthält sie kein unsichtbares Bild und keine umgeleiteten Links. Was du selbst zu sehen bekommst, ist die Referenz auf der Seite, sobald das Formular abgeschickt ist.

Schutz vor Masseneinsendungen. Damit das Formular nicht dazu benutzt werden kann, uns zu überschwemmen, erlaubt BrickDb vier Meldungen je Internetanschluss in gleitenden zehn Minuten. Dafür hält es eine verkürzte Form deiner IP-Adresse als Schlüssel im Arbeitsspeicher eines Webprozesses — bei IPv6 nur den Netzanteil, bei IPv4 die Adresse. Sie wird nicht protokolliert, nicht in die Meldung geschrieben, nicht in der Datenbank gespeichert und nicht weitergegeben, und nach Ablauf der zehn Minuten beeinflusst sie keine Entscheidung mehr. Es werden höchstens 1.024 solcher Schlüssel gehalten; sind alle Plätze belegt, wird ein neuer abgewiesen, statt einen bestehenden zu verdrängen. Ein Captcha gibt es nicht, und es wird dafür nichts von Dritten nachgeladen. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse ist die technisch einwandfreie, sichere und faire Verfügbarkeit des Angebots.

Wer eine Meldung liest, und was die Entscheidung bewirkt. Eine Meldung landet in einer Warteschlange unter /admin/reports, die nur eine Administratorin öffnen kann; eine Seite, auf der sie sonst jemand nachschlagen könnte, gibt es nicht — auch nicht über die Referenz. Entweder wird die Meldung zurückgewiesen oder ihr wird stattgegeben, und wird ihr stattgegeben, wird der gemeldete Inhalt entfernt: Eine Veranstaltung, gegen die eine Meldung durchdringt, verschwindet aus dem öffentlichen Kalender. Eine veröffentlichte Sammlung, gegen die eine Meldung durchdringt, wird wieder auf privat gestellt: Von da an sehen sie nur noch ihre Mitglieder, gelöscht wird nichts davon, und wer sie besitzt, kann sie wieder veröffentlichen — eine wieder veröffentlichte Sammlung kann erneut gemeldet werden. Wir handeln gegen den Inhalt, nicht gegen die Person, die ihn eingestellt hat.

Eine Entscheidung über etwas, das eine Person veröffentlicht hat, wird auch bei ihr festgehalten. Gibt die Administration einer Meldung zu einer Sammlung oder zu einer von einem Mitglied eingereichten Veranstaltung statt oder weist sie sie zurück, wird die Entscheidung im Audit-Protokoll aus Ziffer 8.9 festgehalten, und zwar beim Konto der Person, die den Inhalt veröffentlicht hat: um welche Meldung es ging, welche Art von Inhalt und dessen Schlüssel, und wie sich der Stand der Meldung bewegt hat. Die meldende Person wird in diesem Eintrag nicht genannt, und die Notizen der Moderation gehören nicht dazu.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse ist es, die von BrickDb veröffentlichten Inhalte von rechtswidrigem und anstößigem Material freizuhalten, einen Einwand überhaupt entgegennehmen zu können — auch von jemandem ohne Konto — und hinterher belegen zu können, wie eine Beschwerde bearbeitet wurde. Betrifft eine Meldung Inhalte, gegen die wir einschreiten müssen, dient ihre Bearbeitung zugleich der Erfüllung einer rechtlichen Verpflichtung (Art. 6 Abs. 1 lit. c DSGVO). Gegen eine Verarbeitung auf Grundlage berechtigter Interessen kannst du über die Kontaktdaten in Ziffer 2 Widerspruch einlegen.

Wird einer Meldung stattgegeben, bekommt die Person, die den Inhalt veröffentlicht hat, von uns eine Begründung per E-Mail. Das gilt für eine veröffentlichte Sammlung und für eine von einem Mitglied eingereichte Veranstaltung; bei einer Veranstaltung, die wir aus einem fremden Kalender übernommen haben, gibt es niemanden, dem wir schreiben könnten. Die Nachricht nennt die Referenz der Meldung, um welchen Inhalt es geht (seine Art und seinen Titel oder Namen), was wir getan haben und wie lange das gilt, den Grund, unter dem die Meldung eingereicht wurde, die Ziffer unserer Nutzungsbedingungen, nach der wir entschieden haben, den Hinweis, dass keine automatisierten Mittel eingesetzt wurden, und wie du widersprechen kannst — per Antwort auf die E-Mail oder über das Supportformular unter Angabe der Referenz. Wer die Meldung abgeschickt hat, steht nicht darin, ebenso wenig deren Beschreibung oder die Notizen der Moderation.

Für den Versand fragen wir im Moment der Entscheidung deine E-Mail-Adresse und die Sprache, die bei deinem Konto hinterlegt ist, bei Auth0 ab (Ziffer 7.1). Die Adresse wird dafür nur verwendet und bei uns nicht gespeichert; an der Meldung halten wir lediglich fest, ob die Begründung verschickt werden konnte und wann — oder warum nicht, etwa weil keine Adresse hinterlegt ist. Versendet wird sie über den in Ziffer 7.3 genannten Maildienstleister, sodass diese Angaben in den Vereinigten Staaten auf der dort beschriebenen Grundlage verarbeitet werden; sie enthält kein unsichtbares Bild und keine umgeleiteten Links. Wird eine Sammlung auf privat gestellt, ist die geänderte Einstellung außerdem auf der Sammlungsseite zu sehen. Rechtsgrundlage: Art. 6 Abs. 1 lit. c DSGVO in Verbindung mit Art. 17 der Verordnung (EU) 2022/2065 (Gesetz über digitale Dienste), soweit wir zu einer solchen Begründung verpflichtet sind, und im Übrigen Art. 6 Abs. 1 lit. f DSGVO — das berechtigte Interesse ist, dir zu sagen, was mit deinem Inhalt geschehen ist und warum, und dir einen Weg zu geben, der Entscheidung zu widersprechen.

Speicherdauer: Eine entschiedene Meldung wird 24 Monate nach der Entscheidung gelöscht. Die Frist läuft ab der Entscheidung, nicht ab dem Eingang — eine Meldung, über die noch niemand entschieden hat, wird nicht gelöscht, wie alt sie auch ist, denn sie ist ein Einwand, auf den noch eine Antwort aussteht. Die Löschung erfolgt im Rahmen einer turnusmäßigen Bereinigung und damit gegebenenfalls einige Tage nach Fristablauf, nie davor. Für Sicherungskopien gilt Ziffer 13.

Weder der Datenexport nach Art. 15 DSGVO noch die Kontolöschung erreicht eine Meldung, und das ist eine Grenze und keine Entscheidung gegen dich. Weil keine Meldung einem Konto zugeordnet ist, lässt sich gar nicht fragen, welche Meldungen von einer bestimmten Person stammen — eine Meldung ist deshalb weder im Datenexport nach Art. 15 DSGVO noch in der Kontolöschung auf der Kontoseite enthalten, unabhängig davon, ob du beim Absenden angemeldet warst, und das Löschen deines Kontos löscht sie nicht mit. Dasselbe gilt, wenn jemand etwas gemeldet hat, das du eingestellt hast: Diese Meldung benennt den Inhalt, nie dein Konto, und ist damit auch nicht in deinem Export — die Entscheidung darüber schon, sobald die Administration ihr stattgegeben oder sie zurückgewiesen hat, als Eintrag im Audit-Protokoll nach Ziffer 8.9. Die Aufstellung dessen, was der Export nicht enthält, nennt beide Fälle aus genau diesem Grund. Was du tatsächlich tun kannst: Wende dich über die Kontaktdaten in Ziffer 2 an uns und nenne die Referenz. Damit finden wir die Meldung von Hand, können dir sagen, was sie enthält, sie berichtigen oder die Adresse und den Text, den du geschrieben hast, entfernen.

Das Entfernen von Feldern anonymisiert keinen Freitext. Wenn du in der Beschreibung deinen Namen, eine Anschrift oder andere Angaben über dich geschrieben hast, stehen diese weiterhin im Text. Sag uns Bescheid, wenn das so ist; wir schwärzen oder löschen die betreffende Meldung dann von Hand.

Interne Notizen: Während eine Meldung bearbeitet wird, schreiben wir uns außerdem Notizen dazu — was wir gefunden haben, auf welchen Bearbeitungsstand wir die Meldung gesetzt haben und wer das war. Diese Notizen sind unsere und nicht deine: Sie hängen an der Person, die sie geschrieben hat, sie gehen weder an dich noch an die Person, deren Inhalt gemeldet wurde, und sie sind deshalb weder in deinem Datenexport nach Art. 15 DSGVO noch über eine Kontolöschung erreichbar. Gelöscht werden sie zusammen mit der Meldung, zur selben Frist. Wenn du wissen möchtest, ob eine Notiz dich namentlich nennt, schreib uns über die Kontaktdaten in Ziffer 2.

Von uns aus schreiben wir nicht zurück. Aus einer Meldung entsteht kein Schriftwechsel: Es gibt keine Bestätigungsmail, keine Statusseite und keine Nachricht, wenn entschieden wurde. Die Adresse ist dafür da, dass sich jemand bei dir melden kann, falls die Meldung ohne eine Rückfrage nicht bearbeitet werden kann, und sie wird für nichts anderes verwendet. Was du bekommst, ist sofort die Referenz auf der Seite.

Stand dieser Fassung: Das Meldeformular auf /events und auf der Seite jeder veröffentlichten Sammlung ist in Betrieb, die Warteschlange dahinter ebenfalls. Wenn es deine Meldung aus irgendeinem Grund nicht annimmt, erreichst du uns genauso gut über die Kontaktdaten in Ziffer 2 und im Impressum — eine so gesendete Nachricht ist dann schlicht eine E-Mail in unserem Postfach und erzeugt keine Meldung.

8.9 Verwaltung von Nutzerkonten

Administratorinnen und Administratoren von BrickDb können Nutzerkonten in einem Bereich unter /admin/users betreuen, den nur sie öffnen können: die Liste der Konten sehen, ein Konto ansehen, seinen Namen, seine E-Mail-Adresse, sein Profil oder seine Rollen ändern, einen Passwort-Reset schicken, die Bestätigungsmail erneut schicken, eine E-Mail-Adresse als bestätigt markieren, es sperren oder entsperren oder es über dieselbe Löschung entfernen, die in Ziffer 14 beschrieben ist. Die Kontodaten dort werden live bei Auth0 gelesen (Ziffer 7.1 und 7.2) und nicht in die Datenbank von BrickDb kopiert. Dasselbe gilt für den Anmeldeverlauf eines Kontos: Er wird bei Auth0 gelesen, wenn eine Administratorin oder ein Administrator ihn öffnet, und nur so lange aufbewahrt, wie Auth0 selbst ihn aufbewahrt.

Was die Administration über ein Konto sieht. Die Seite eines Kontos zeigt, was Auth0 dazu speichert – seine Kennung, die E-Mail-Adresse und ob sie bestätigt ist, die damit verknüpften Anmeldemethoden, wann es angelegt, zuletzt geändert und zuletzt angemeldet wurde, wie oft es sich angemeldet hat, ob es gesperrt ist, welche Arten der Mehr-Faktor-Authentifizierung eingerichtet sind (nur die Art, nie ein Geheimnis oder eine Telefonnummer) und seine Rollen – sowie das Profil, das du ausgefüllt hast (Namen, Land, den Text über dich, den gewählten Avatar und die Sprache deiner E-Mails, aber nicht deine Postanschrift). Aus der eigenen Datenbank von BrickDb zeigt sie nur Anzahlen: wie viele Sammlungen du besitzt und wie vielen du beigetreten bist, wie viele Exemplare du hinzugefügt hast, wie viele Tütencodes, Set-Barcodes und Events du beigetragen hast, wie viele deiner Supportanfragen offen sind und wie viele Inhaltsmeldungen mit deiner E-Mail-Adresse eingereicht wurden – nie deren Inhalt.

Der Anmeldeverlauf zeigt zu jedem Ereignis, das Auth0 für das Konto festgehalten hat, wann es war, was es war (eine Anmeldung oder eine fehlgeschlagene, eine Registrierung, eine Abmeldung, eine Änderung von Passwort oder E-Mail-Adresse, eine E-Mail-Bestätigung, ein Schritt der Mehr-Faktor-Authentifizierung, ein von Auth0 blockierter Versuch oder ein Passwort aus einem Datenleck), über welche Anmeldemethode und welche Anwendung von BrickDb es lief, das Land und die Stadt, die Auth0 aus der IP-Adresse abgeleitet hat, sowie Browser und Betriebssystem mit ihrer Hauptversion. Die IP-Adresse selbst wird nicht angezeigt, ebenso wenig der Freitext, den Auth0 einem Ereignis beifügt. Die Administration sieht ihn sich an, um Konten sicher zu halten – um Anmeldungen zu erkennen, die nicht von dir waren, oder einen Angriff auf dein Passwort – und um dir zu helfen, wenn du uns zu deinem Konto fragst.

Niemand in der Administration sieht, wählt oder tippt jemals ein Passwort. Ein Konto, das dort angelegt wird, bekommt ein zufälliges Passwort, das niemand sieht, und du erhältst von BrickDb eine Einladungsmail (versandt wie in Ziffer 7.3 beschrieben) mit einem Link, der sieben Tage gilt und sich einmal verwenden lässt, um dein eigenes Passwort zu wählen. Ein Passwort-Reset ist die eigene Mail von Auth0 mit derselben Art Link. Weder das Passwort noch der Link werden von BrickDb gespeichert oder protokolliert.

Jede Aktion der Administration wird in einem Audit-Protokoll festgehalten, und zwar bevor sie läuft, damit auch eine fehlgeschlagene festgehalten ist: wann sie stattfand, wer sie ausgeführt hat, was sie war, welches Konto sie betraf (seine Auth0-Kennung sowie die E-Mail-Adresse und der Name, die es in dem Moment hatte), welchen Grund die Person angegeben hat, welche Felder sich mit welchen Werten vorher und nachher geändert haben und ob sie geklappt hat. Ein Passwort, ein Reset-Link oder ein Token wird nie festgehalten. Nur die Administration kann das Protokoll unter /admin/audit lesen, und es hat keine Funktion, die einen Eintrag ändert oder löscht.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Unser berechtigtes Interesse ist es, Konten und den Dienst sicher zu halten, dir zu helfen, wenn dein Konto Hilfe braucht, und hinterher zeigen zu können, was mit einem Konto geschehen ist, durch wen und warum – die Rechenschaft, die Art. 5 Abs. 2 DSGVO von uns verlangt. Das gilt für die Daten der Administration im Protokoll genauso wie für deine. Du kannst über die Kontaktdaten in Ziffer 2 widersprechen.

Speicherdauer: Ein Eintrag im Audit-Protokoll wird 24 Monate nach der Aktion gelöscht, im Rahmen der regelmäßigen Bereinigung, also möglicherweise ein paar Tage später und nie früher. Für Sicherungskopien gilt Ziffer 13.

Wenn du dein Konto löschst, bleiben die Einträge dazu erhalten, nennen dich aber nicht mehr. Die Kontokennung wird durch ein zufälliges Pseudonym ersetzt, und die E-Mail-Adresse, der Name und alle geänderten Werte werden entfernt; wer gehandelt hat, was getan wurde und wann, bleibt, denn genau dafür ist der Eintrag da. Den Grund, den die Administration notiert hat, behalten wir ebenfalls; er kann dich im Text erwähnen – sag uns Bescheid, dann schwärzen wir ihn. Wenn du selbst zur Administration gehörst und dein Konto löschst, bleiben die Einträge über deine Aktionen unverändert.

Die Administration löscht ein Konto nur über dieselbe Löschung (Ziffer 14), Schritt für Schritt, und erst nachdem sie die E-Mail-Adresse des Kontos eingetippt und einen Grund angegeben hat, den das Audit-Log behält. Das tun wir zum Beispiel, wenn du uns bittest, ein Konto zu löschen, in das du dich nicht mehr anmelden kannst. Wenn du vorher eine Kopie deiner Daten haben möchtest, lade deinen Export nach Art. 15 DSGVO auf der Kontoseite herunter, bevor du uns schreibst – danach gibt es nichts mehr zu exportieren. Das eigene Konto kann die Administration auf diesem Weg nicht löschen; dafür gibt es wie für alle die Kontoseite.

Die Administration kann deinen Export nach Art. 15 DSGVO auch für dich herunterladen – zum Beispiel, wenn du uns bittest, ihn dir zu schicken, weil du dich nicht anmelden kannst. Es ist dasselbe Archiv, das dir die Kontoseite gibt, auf dieselbe Weise erstellt, und die Administration kann es nur herunterladen, nachdem sie einen Grund angegeben hat. Jeder Download wird im Audit-Log festgehalten wie jede andere Aktion der Administration: wer ihn heruntergeladen hat, wann und warum. Das Archiv geht direkt an den Browser der Administration; BrickDb behält keine Kopie davon und schreibt es in kein Log.

Dein Export nach Art. 15 DSGVO auf der Kontoseite enthält die Einträge zu deinem Konto (unter „adminAuditEntries“) – wann, was, der Grund und was sich geändert hat –, aber nicht, wer aus der Administration es war, denn das sind die Daten dieser Person und nicht deine. Schreib uns über die Kontaktdaten in Ziffer 2, wenn du es wissen möchtest.

Stand dieser Fassung: Die Nutzerliste mit ihrer Suche, die Seite eines einzelnen Kontos, sein Anmeldeverlauf, jede oben genannte Aktion und das Audit-Protokoll sind in Betrieb.

9. Externe Datenquellen

BrickDb zeigt Katalog- und Preisdaten aus fremden Quellen, insbesondere Rebrickable und BrickLink. Diese Daten werden ausschließlich serverseitig abgerufen und in den eigenen Bestand übernommen. Der Browser baut zu keinem Zeitpunkt eine Verbindung zu diesen Anbietern auf.

An diese Anbieter werden keine personenbezogenen Daten übermittelt — weder IP-Adresse noch Kennnummer, noch die Information, wonach gesucht wurde oder was jemand besitzt. Abfragen erfolgen nach eigenem Zeitplan und nicht als Weiterreichung einer Nutzeranfrage.

10. Reichweitenmessung mit Google Analytics

BrickDb zählt mit Google Analytics 4, wie oft Seiten aufgerufen werden und welche Bereiche genutzt werden. Das geschieht ausschließlich mit deiner Einwilligung. Solange du nicht zugestimmt hast, wird kein Skript von Google geladen, keine Kennung gesetzt und nichts an Google gesendet — auch keine als „cookielos" bezeichnete Vorabmeldung. Der erweiterte Einwilligungsmodus von Google („Consent Mode v2 advanced"), bei dem das Skript sofort lädt und bereits vor der Einwilligung Daten überträgt, wird bewusst nicht eingesetzt.

Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO — deine Einwilligung — und § 25 Abs. 1 TDDDG für das Speichern und Auslesen der Informationen auf deinem Endgerät.

Empfängerin und Auftragsverarbeiterin: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irland. Grundlage sind die Auftragsverarbeitungsbedingungen von Google (Google Ads Data Processing Terms), denen für die Rechtsordnung Deutschland zugestimmt wurde.

Was verarbeitet wird: die aufgerufene Seite und ihr Titel, die Verweisquelle, ein ungefährer Standort auf Länder- und Regionsebene, Gerätetyp, Browser, Betriebssystem, Bildschirmgröße und Sprache, Datum und Uhrzeit sowie eine zufällige Kennung in den Cookies nach Ziffer 6.1, mit der wiederkehrende Aufrufe desselben Browsers erkannt werden. Zusätzlich sind die von Google „optimierte Analysen" genannten automatischen Ereignisse aktiv: Scrolltiefe, die Suche auf dieser Website, Dateidownloads, Videointeraktionen und Klicks auf Links zu anderen Websites — also auch auf die Partnerlinks nach Ziffer 10.1. Deine IP-Adresse wird von Google zur Ableitung des ungefähren Standorts verwendet und nach Angaben von Google dabei weder protokolliert noch gespeichert.

Was nicht stattfindet: Die Funktionen „Google-Signale" und „personalisierte Werbung" sind im Seitenquelltext ausdrücklich abgeschaltet (allow_google_signals und allow_ad_personalization_signals stehen beide auf false), und die Freigabe an „Google-Produkte und -Dienste" ist in der Property deaktiviert. Es werden keine Werbe- oder Zielgruppenlisten gebildet, keine Daten für Werbezwecke an Google weitergegeben und keine geräteübergreifenden Profile erstellt. Eine automatisierte Entscheidungsfindung einschließlich Profiling nach Art. 22 DSGVO findet nicht statt. In die Seite sind keine weiteren Analysedienste, keine Werbenetzwerke und keine sozialen Plug-ins eingebunden, und auch kein Skript eines Fehlerberichtsdienstes: der Browser lädt von einem solchen Dienst nichts und sendet ihm nichts. Die Fehlerdiagnose, die BrickDb tatsächlich einsetzt, läuft auf dem Server und — in der App — auf dem Gerät selbst; sie ist in Ziffer 11 beschrieben.

Drittlandsübermittlung: Vertragspartnerin ist Google Ireland Limited; eine Übermittlung an Google LLC in den Vereinigten Staaten lässt sich nicht ausschließen. Google LLC ist unter dem EU-US Data Privacy Framework zertifiziert, für das die EU-Kommission am 10. Juli 2023 einen Angemessenheitsbeschluss gefasst hat; ergänzend gelten die Standardvertragsklauseln aus Googles Auftragsverarbeitungsbedingungen.

Speicherdauer: Ereignis- und nutzerbezogene Daten werden in der Google-Analytics-Property bis zu 14 Monate ab deiner letzten Interaktion aufbewahrt und danach von Google gelöscht. Die Frist läuft ab dem letzten und nicht ab dem ersten Besuch, weil in der Property die Option „Bei neuer Aktivität zurücksetzen" aktiv ist: jeder weitere Besuch startet die 14 Monate neu. Wer regelmäßig wiederkommt, dessen Daten werden also nicht gelöscht, solange er wiederkommt. Betroffen sind die Daten, die einzelnen Ereignissen und Kennungen zugeordnet sind. Die zusammengefassten Standardberichte — etwa „wie viele Seitenaufrufe hatte der September" — sind von dieser Einstellung nicht erfasst und bleiben bei Google darüber hinaus verfügbar. Das Einwilligungs-Cookie auf deinem Gerät läuft nach 182 Tagen ab; danach wird die Frage erneut gestellt.

Widerruf: Am Ende jeder Seite steht der Bereich „Reichweitenmessung" mit einer Schaltfläche, die deine Entscheidung umkehrt — ein Klick, genauso wie das Zustimmen einer war (Art. 7 Abs. 3 DSGVO). Der Widerruf wirkt sofort: das Skript wird nicht mehr geladen, und die von Google gesetzten Cookies (_ga und _ga_…) werden mit derselben Anfrage gelöscht. Die Rechtmäßigkeit der bis zum Widerruf erfolgten Verarbeitung bleibt unberührt. Bereits an Google übermittelte Daten kannst du zusätzlich über die unter Ziffer 14 genannten Rechte geltend machen.

Was das für die Zahlen bedeutet: Gezählt wird nur, wer zugestimmt hat. Die Zahlen sind deshalb unvollständig und liegen unter der tatsächlichen Nutzung. Das ist die beabsichtigte Folge der Entscheidung, nichts ohne Einwilligung zu laden.

10.1 Partnerlinks (Affiliate-Links)

BrickDb nimmt an Partnerprogrammen teil; entsprechende Links sind unmittelbar mit „Werbung" gekennzeichnet. Das ändert an den Aussagen oben nichts: es wird kein Werbenetzwerk in die Seite eingebunden, kein Skript und kein Zählpixel eines Partnernetzwerks geladen und keine Kennung gesetzt. Beim bloßen Aufruf einer Seite geschieht in dieser Hinsicht nichts.

Erst wenn eine Person einen solchen Link anklickt, ruft ihr Browser die Adresse des Händlers bzw. des Partnernetzwerks auf. Das ist ein selbst veranlasster Seitenwechsel, für den die verlinkte Stelle datenschutzrechtlich verantwortlich ist. Die Adresse enthält eine Kennung, aus der der Händler erkennt, dass der Besuch von BrickDb kam; sie ist in der Adresszeile sichtbar. BrickDb erfährt dabei nicht, wer geklickt hat: das Partnernetzwerk stellt ausschließlich zusammengefasste Abrechnungsdaten bereit, keine personenbezogenen Angaben zu einzelnen Klicks.

Awin. Die Links zu Händlern, deren Preise BrickDb aus einem Produktdatenfeed von Awin übernimmt, laufen über das Partnernetzwerk Awin (AWIN AG, Berlin). BrickDb gibt einen solchen Link unverändert so aus, wie er im Feed steht: er enthält die Publisher-Kennung von BrickDb, die Kennung des Händlers und das Ziel beim Händler und nichts über dich – keine Kontokennung und keine von BrickDb vergebene Klick- oder Besucherkennung. Klickst du ihn an, ruft dein Browser zuerst eine Adresse von Awin auf (awin1.com) und wird von dort zum Händler weitergeleitet. Dabei kann Awin Informationen direkt bei dir erheben und auf seiner eigenen Domain Cookies in deinem Browser setzen oder auslesen, um einen späteren Kauf diesem Klick zuzuordnen, nach Awins eigener Datenschutzerklärung. BrickDb setzt dafür kein Cookie, zeichnet den Klick nicht auf dem eigenen Server auf und übermittelt selbst keine Daten über dich an Awin.

Rakuten Advertising. Die Links zu Onlineshops, die LEGO selbst betreibt und deren Preise BrickDb aus einem Produktdatenfeed von Rakuten Advertising übernimmt, laufen über das Partnernetzwerk Rakuten Advertising, ebenso der Link zur LEGO-Geschenkkarte bei Giftcards.com, den eine Set-Seite Besuchern in den USA anbietet. Verantwortlich ist die Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, USA, nach eigener Angabe auch für Besucher aus dem Vereinigten Königreich und dem Europäischen Wirtschaftsraum. Für die Zwecke ihrer Datenschutzerklärung nennt Rakuten Advertising als Niederlassung in der EU die Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, Frankreich, und im Vereinigten Königreich die Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, Vereinigtes Königreich. Auch diesen Link gibt BrickDb unverändert so aus, wie er im Produktdatenfeed steht: er enthält die Publisher-Kennung von BrickDb, eine Angebotskennung und die Zieladresse im Shop und nichts über dich. Der Link zur LEGO-Geschenkkarte stammt nicht aus dem Produktdatenfeed: Rakuten Advertising hat ihn BrickDb einmalig erzeugt, und er enthält ebenso nur die Publisher-Kennung von BrickDb, die Kennung von Giftcards.com und die Zieladresse bei Giftcards.com. Klickst du ihn an, ruft dein Browser zuerst eine Adresse von Rakuten Advertising auf (click.linksynergy.com) und wird von dort zum Shop weitergeleitet. Dabei kann Rakuten Advertising Informationen direkt bei dir erheben und auf seiner eigenen Domain Cookies in deinem Browser setzen oder auslesen, um einen späteren Kauf diesem Klick zuzuordnen, nach der eigenen Datenschutzerklärung von Rakuten Advertising. Deine Rechte gegenüber Rakuten Advertising machst du über dessen Formular für Datenschutzanfragen geltend; Kontaktmöglichkeiten stehen hier. BrickDb setzt dafür kein Cookie, zeichnet den Klick nicht auf dem eigenen Server auf und übermittelt selbst keine Daten über dich an Rakuten Advertising.

Tradedoubler. Die Links zur Buchhandlung Hugendubel, deren Preise BrickDb aus einem Produktdatenfeed von Tradedoubler übernimmt, laufen über das Partnernetzwerk Tradedoubler. Verantwortlich ist nach der eigenen Datenschutzerklärung von Tradedoubler die Nyorda AB (Schweden), die Muttergesellschaft der Tradedoubler-Gruppe. Auch diesen Link gibt BrickDb unverändert so aus, wie er im Produktdatenfeed steht: er enthält die Publisher-Kennung von BrickDb, die Kennung des Programms und des Produkts und die Zieladresse bei Hugendubel und nichts über dich. Klickst du ihn an, ruft dein Browser zuerst eine Adresse von Tradedoubler auf (pdt.tradedoubler.com) und wird von dort zu Hugendubel weitergeleitet. Dabei kann Tradedoubler Informationen direkt bei dir erheben und auf seiner eigenen Domain Cookies in deinem Browser setzen oder auslesen, um einen späteren Kauf diesem Klick zuzuordnen, nach der eigenen Datenschutzerklärung von Tradedoubler. Deine Rechte gegenüber Tradedoubler machst du unter privacy@tradedoubler.com geltend. BrickDb setzt dafür kein Cookie, zeichnet den Klick nicht auf dem eigenen Server auf und übermittelt selbst keine Daten über dich an Tradedoubler.

Amazon. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. BrickDb nimmt an den Amazon-Partnerprogrammen für amazon.com (betrieben von der Amazon.com Services LLC) und amazon.de (betrieben von der Amazon Europe Core S.à r.l.) teil. Eine Set-Seite verlinkt auf eine Suche im jeweiligen Amazon-Shop; von Amazon wird auf BrickDb nichts geladen – kein Skript, kein Bild, kein Preis und kein Logo. Folgst du einem solchen Link, bist du auf Amazons eigener Website; dort kann Amazon Informationen direkt bei dir erheben und Cookies in deinem Browser setzen oder auslesen, nach Amazons eigener Datenschutzerklärung. BrickDb erhält von Amazon nur zusammengefasste Berichte, keine Angaben zu einzelnen Besuchenden.

Eine Ergänzung seit der Reichweitenmessung: Hast du dieser nach Ziffer 10 zugestimmt, wird der Klick auf einen solchen Link zusätzlich als Ereignis in Google Analytics gezählt — mit der Zieladresse, ohne Angabe dazu, wer geklickt hat, außer der dort beschriebenen zufälligen Kennung. Ohne deine Einwilligung geschieht auch das nicht.

11. Betriebsüberwachung und Fehlerdiagnose

Die Anwendung ist mit OpenTelemetry instrumentiert. Ein Export dieser Daten erfolgt nur, wenn ein Ziel ausdrücklich konfiguriert ist; im Betrieb ist kein solches Ziel konfiguriert, sodass diese Telemetriedaten den Prozess nicht verlassen. Aufrufe der Statusendpunkte werden von der Aufzeichnung ausgenommen.

Für Fehlerberichte wird darüber hinaus der Dienst Sentry eingesetzt. Stürzt die App ab oder schlägt auf dem Server eine Anfrage unerwartet fehl, wird ein Fehlerbericht an Sentry übermittelt, damit der Fehler gefunden und behoben werden kann. Das betrifft vier Stellen: den API-Server, den Webserver, den Lesedienst nach Ziffer 8.5 und — anders als alles andere in dieser Ziffer — die App auf deinem Gerät. Die Verbindung zu Sentry baut in allen vier Fällen die Anwendung selbst auf; in die Website ist kein Skript eines Fehlerberichtsdienstes eingebunden, der Browser sendet also von sich aus nichts dorthin (Ziffer 10).

Anbieterin ist die Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA. Sie ist insoweit Auftragsverarbeiterin nach Art. 28 DSGVO. Eine Niederlassung in der Europäischen Union, mit der ein Vertrag geschlossen werden könnte, unterhält Sentry nach eigenen Angaben nicht — Vertragspartnerin ist damit ein Unternehmen mit Sitz in den Vereinigten Staaten.

Verarbeitungsort: Davon zu unterscheiden ist, wo die Daten liegen. Die Berichte gehen an die EU-Region von Sentry, die Sentry selbst als European Union (EU) bezeichnet und die als Speicherregion unserer Organisation eingestellt ist. Die Empfangsadresse aller vier Stellen lautet auf ingest.de.sentry.io und nicht auf die weltweite Adresse des Dienstes. Das sind zwei verschiedene Dinge, und nur das zweite ist ein Hostname: die Adresse, an die die Software sendet, gegenüber der Einstellung des Kontos, die darüber entscheidet, wo das Angekommene liegt.

Drittlandsübermittlung: Weil die Vertragspartnerin ihren Sitz in den Vereinigten Staaten hat, lässt sich ein Zugriff von dort — etwa im Rahmen von Support und Wartung — nicht ausschließen. Sentry stützt solche Übermittlungen auf die Standardvertragsklauseln der EU-Kommission, die dem Auftragsverarbeitungsvertrag in der Fassung 5.1.0 vom 29. Mai 2024 zugrunde liegen.

Was ein Fehlerbericht enthält: die Art des Fehlers und seine Meldung, den technischen Aufrufverlauf (Dateien, Methoden, Zeilennummern), die Version von BrickDb, die aufgerufene Adresse samt ihren Abfrageparametern, soweit diese nicht wie unten beschrieben entfernt werden, beim API-Server und beim Webserver außerdem die Kopfzeilen der Anfrage — etwa die Kennung deines Browsers, die bevorzugte Sprache und die Seite, von der aus du gekommen bist — sowie die Angaben, die das Sentry-SDK von sich aus über die Umgebung sammelt — insbesondere Gerätemodell, Betriebssystem und dessen Version, Sprache und Zeitzone. Auf dem API-Server kommt die pseudonyme Kennung deines Kontos hinzu, wenn du angemeldet warst; der Webserver und die App übermitteln gar keine Kennung.

Was der Lesedienst meldet: Der Lesedienst nach Ziffer 8.5 sendet einen Fehlerbericht nur, wenn das Lesen eines Fotos unerwartet fehlschlägt; dass er ausgelastet ist oder ein Foto abweist, meldet er nicht. Ein solcher Bericht enthält die Art des Fehlers und seine Meldung, den technischen Aufrufverlauf, die Version von BrickDb, die interne Adresse, unter der ihn der API-Server aufgerufen hat, die Kopfzeilen dieses internen Aufrufs — nicht die deines Browsers — und die Angaben zur Serverumgebung. Eine Kennung deines Kontos übermittelt der Lesedienst nicht. Das eingereichte Foto ist in einem Bericht des Lesedienstes nie enthalten, auch nicht in Teilen: Der Inhalt einer Anfrage wird nicht erfasst, und der Lesedienst protokolliert nichts über das Foto.

Was die App zusätzlich festhält: Damit sich ein Fehler auf deinem Gerät nachvollziehen lässt, hängt die App einem Fehlerbericht eine Verlaufsspur an. Sie enthält die Namen der zuletzt geöffneten Seiten (nicht ihre Adressen); für jede Anfrage an unseren Server, die nicht erfolgreich war, die Methode, die Adresse als Muster ohne Kennungen, den Statuscode, die Dauer und, soweit bekannt, die Art des Fehlers; die beim Start festgehaltenen Einstellungen — die Adresse des Servers ohne Pfad, ob Anmeldung und Fehlerberichte eingeschaltet sind und die eingestellte Sprache —; und, weil das Sentry-SDK seine eigene Verlaufsspur für Anfragen führt, für jede Anfrage der App — an unseren Server und an den Anmeldedienst — zusätzlich die vollständige Adresse mit Methode und Statuscode, einschließlich des Pfades, der etwa eine Setnummer oder die Kennung einer Sammlung enthalten kann, und der Abfrageparameter, etwa eines Suchbegriffs. Auch aus dieser Adresse werden die oben genannten Abfrageparameter, deren Name auf ein Geheimnis hindeutet, und E-Mail-Adressen vor dem Senden entfernt. Dieselbe Adresse kann außerdem in einer Laufzeitmessung stehen, die Sentry für einen zufällig ausgewählten Anteil von 2 % der Abläufe in der App erstellt.

Angaben zum Gerät: Jeder Bericht, den die App nach ihrem Start sendet, trägt die Plattform, die Version des Betriebssystems, die Geräteart (etwa Telefon oder Tablet) und die Version der App; sobald die Startprüfung der Darstellung gelaufen ist, außerdem die Art und Hauptversion der Web-Ansicht, in der die App läuft. Lädt die App ein Bild, eine Stilvorlage, ein Skript oder eine Schriftart nicht, oder blockiert sie einen Inhalt aus Sicherheitsgründen, wird festgehalten, was das war — bei eigenen Dateien der Pfad ohne Kennungen, bei fremden Adressen nur der Name des Servers, bei einer Schriftart ihr Name —, und einmal beim Start eine Prüfung der Darstellung: welche Stilvorlagen geladen wurden, wie viele Regeln sie enthalten und welche Schriftart tatsächlich verwendet wird. Ein solcher Ladefehler, ein Serverfehler oder eine Anfrage, die gar keine Antwort erhält, kann auch ohne Absturz einen eigenen Bericht auslösen — derselbe Fehler bei einer Anfrage höchstens einmal in zehn Minuten, bei einem Ladefehler höchstens einmal je Start der App.

Das Protokoll auf deinem Gerät: Die App schreibt in ein Protokoll im eigenen Speicherbereich der App: jede Anfrage an unseren Server — auch jede erfolgreiche — mit Methode, Adresse als Muster ohne Kennungen, Statuscode, Dauer und einer zufälligen Vorgangsnummer; die oben genannten Ladefehler; das Ergebnis der Startprüfung der Darstellung samt Art und Version der Web-Ansicht; die beim Start festgehaltenen Einstellungen; und die übrigen Meldungen der App ab der Stufe „Information“. Die Namen der geöffneten Seiten, die Art eines Fehlers, die Angaben zum Gerät und die vollständigen Adressen aus Sentrys eigener Verlaufsspur stehen nicht in diesem Protokoll. Es umfasst höchstens drei Dateien zu je einem Megabyte, die ältesten Einträge werden überschrieben, und jeder Eintrag wird beim Schreiben so bereinigt wie ein Fehlerbericht. Dieses Protokoll verlässt das Gerät nicht von selbst. Nur wenn du unter „Info“ auf „Diagnosedaten kopieren“ tippst, legt die App die Version der App, die Plattform, die Version des Betriebssystems, die Geräteart, die beim Start festgehaltenen Einstellungen und bis zu 200 der letzten Einträge — noch einmal bereinigt — in die Zwischenablage; wohin du sie einfügst, entscheidest du.

Was ausdrücklich entfernt wird, bevor ein Bericht das Gerät oder den Server verlässt: alle Cookies, der gesamte Inhalt einer Anfrage, jeder Abfrageparameter, dessen Name auf ein Geheimnis hindeutet (unter anderem code, state, token, password, email, key), jeder Kopfzeilenwert, dessen Name auf ein Geheimnis hindeutet, jede Kopfzeile, in der unsere vorgeschalteten Server deine IP-Adresse weiterreichen, sowie E-Mail-Adressen und Zeichenketten, die wie ein Token aussehen — auch mitten in einer Fehlermeldung. Ein Benutzername, eine E-Mail-Adresse oder eine IP-Adresse im Nutzerabschnitt des Berichts wird überschrieben, bevor der Bericht gesendet wird, ebenso die Installationskennung, die das SDK dort von sich aus einträgt. Diese Bereinigung ist so gebaut, dass sie im Fehlerfall den Bericht verwirft statt ihn ungefiltert zu senden.

Die Anwendung selbst übermittelt keine IP-Adresse: SendDefaultPii steht an allen vier Stellen auf false, die gerade beschriebene Bereinigung überschreibt dieses Feld ohnehin, und sie entfernt auch die Kopfzeilen, in denen unsere vorgeschalteten Server deine IP-Adresse an den Webserver und den API-Server weiterreichen. Bildschirmfotos werden nicht angehängt, und die Texte der Bedienoberfläche werden nicht in die Verlaufsspuren aufgenommen; beides ist ausdrücklich abgeschaltet. Fotos können einen Fehlerbericht nicht erreichen, weil der Inhalt einer Anfrage ohnehin vollständig entfernt wird.

Laufzeitmessungen auf dem Server: Unabhängig davon, ob ein Fehler auftritt, erstellen der Webserver, der API-Server und der Lesedienst für einen zufällig ausgewählten Anteil der Anfragen eine Laufzeitmessung und übermitteln sie an Sentry, damit sich langsame Stellen finden lassen; Aufrufe der Statusendpunkte und die Prüfanfragen unserer vorgeschalteten Server sind davon ausgenommen. Der Anteil beträgt 5 %. Kommt eine Anfrage jedoch von der App, vom Webserver oder vom API-Server und gehört sie zu einem Ablauf, für den dort bereits entschieden wurde, ob er gemessen wird, übernimmt der Server diese Entscheidung, sodass ein solcher Ablauf entweder auf allen Stationen gemessen wird oder auf keiner. Eine solche Messung enthält dieselben Angaben zur Anfrage wie ein Fehlerbericht des Servers — die Methode, die aufgerufene Adresse samt ihren Abfrageparametern, etwa einem Suchbegriff, und die Kopfzeilen der Anfrage —, dazu das Muster der aufgerufenen Adresse ohne Kennungen, den Statuscode der Antwort, Beginn und Dauer der Bearbeitung und die Meldungen, die die Anwendung währenddessen protokolliert. Hinzu kommen die einzelnen Arbeitsschritte mit ihrer Dauer: die Anfragen, die der Server dabei selbst stellt — etwa der Webserver an den API-Server oder der API-Server an den Anmeldedienst —, jeweils mit Methode, vollständiger Adresse und Statuscode, und die Datenbankabfragen mit ihrem Text, in dem eingesetzte Werte nur als Platzhalter stehen und nicht die Werte selbst. Auf dem API-Server trägt die Messung die pseudonyme Kennung deines Kontos, wenn du angemeldet warst; der Webserver und der Lesedienst übermitteln keine Kennung. Beim Lesedienst betrifft eine Messung nur den internen Aufruf durch den API-Server; er stellt dabei selbst keine Anfragen an andere Server und keine Datenbankabfragen, und das Foto ist auch in einer Messung nie enthalten. Für jede Laufzeitmessung gilt dieselbe Bereinigung wie für einen Fehlerbericht, oben beschrieben; insbesondere werden die Cookies und die Kopfzeilen mit deiner IP-Adresse vor dem Senden entfernt. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse besteht darin, die Anwendung schnell und zuverlässig zu betreiben. Eine vollständige Laufzeitmessung bewahrt Sentry in unserem Tarif höchstens 90 Tage auf; eine verkleinerte Stichprobe der Messungen kann Sentry bis zu 13 Monate aufbewahren.

Die IP-Adresse der Verbindung bewahrt Sentry nicht auf. Beim Absenden eines Berichts wird eine Internetverbindung aufgebaut; die Adresse, von der aus gesendet wurde, ist der annehmenden Stelle während der Übertragung damit zwangsläufig bekannt. Sentry bietet eine Einstellung an, die diese Adresse verwirft statt sie aufzuzeichnen, und diese Einstellung ist für alle vier Projekte eingeschaltet — die des API-Servers, des Webservers, des Lesedienstes und der App. Ein Fehlerbericht behält die Adresse deshalb nicht. Das gilt auch für die Berichte der App, bei denen es die Adresse deines eigenen Internetanschlusses wäre; beim API-Server, beim Webserver und beim Lesedienst wäre es die Adresse unserer eigenen Server.

Für die Übertragung gilt alles Übrige dieser Ziffer unverändert: Empfängerin ist die Functional Software, Inc. d/b/a Sentry, die Berichte gehen an die oben genannte Speicherregion, und die Übermittlung stützt sich auf die oben beschriebenen Standardvertragsklauseln. Sentrys eigene serverseitige Bereinigung ist für alle vier Projekte — die des API-Servers, des Webservers, des Lesedienstes und der App — in ihrer Grundform eingeschaltet; wir haben ihr keine eigenen Regeln hinzugefügt und keine ihrer Regeln entfernt.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO — für den Fehlerbericht und für die IP-Adresse bei seiner Übertragung gleichermaßen. Das berechtigte Interesse besteht darin, Fehler und Abstürze zu erkennen und zu beheben. Die Adresse wird zu keinem eigenen Zweck verarbeitet und nicht dazu verwendet, dich wiederzuerkennen. Es ist dieselbe Grundlage, auf der Ziffer 3 die IP-Adresse verarbeitet, die bei jeder Verbindung zur Website zwangsläufig anfällt. Du kannst dem nach Art. 21 DSGVO über die Kontaktdaten in Ziffer 2 widersprechen.

Speicherdauer: 90 Tage. Wie lange ein Fehlerbericht bei Sentry aufbewahrt wird, folgt aus dem Tarif, in dem die Organisation liegt. Unsere liegt im Tarif „Business", für den Sentry eine Aufbewahrung von 90 Tagen veröffentlicht; im Tarif „Developer" wären es 30. Anhänge folgen dem Ereignis, zu dem sie gehören. Für ein einzelnes Projekt kann eine kürzere Frist gesetzt werden, die dann vorgeht; keines unserer vier Projekte trägt eine solche, sodass die 90 Tage für alle vier gleichermaßen gelten.

12. Empfänger

Personenbezogene Daten werden nicht verkauft und nicht zu Werbezwecken weitergegeben. Empfänger sind derzeit die Microsoft Ireland Operations Limited als Auftragsverarbeiterin für Hosting, Datenbank und Dateiablage sowie — allein auf deine ausdrückliche Anfrage nach Ziffer 8.6 — für die Bildauswertung durch Azure OpenAI, und die Twilio Inc. („SendGrid“) als Auftragsverarbeiterin für den E-Mail-Versand nach Ziffer 7.3, einschließlich der dort beschriebenen Verarbeitung in den Vereinigten Staaten. Hast du der Reichweitenmessung nach Ziffer 10 zugestimmt, tritt für deren Dauer die Google Ireland Limited als weitere Auftragsverarbeiterin hinzu; ohne deine Einwilligung erhält sie nichts. Für die Anmeldung nach Ziffer 7.1 ist Auth0 / Okta, Inc. Auftragsverarbeiterin, und für die Fehlerberichte nach Ziffer 11 die Functional Software, Inc. d/b/a Sentry; beide haben ihren Sitz in den Vereinigten Staaten und stützen die Übermittlung auf die Standardvertragsklauseln der EU-Kommission, wie in den genannten Ziffern beschrieben. Genehmigte Veranstaltungsangaben sind gemäß Ziffer 8.4 öffentlich; die Verknüpfung zum Konto gehört nicht dazu. Darüber hinaus erfolgt eine Weitergabe nur, wenn dazu eine gesetzliche Verpflichtung besteht.

13. Speicherdauer

• Sammlungsdaten und Fotos: bis zur Löschung durch die betroffene Person oder bis zur Löschung des Kontos.
• Einstellungen auf dem Endgerät: siehe Ziffer 6.1.
• Kontodaten beim Identitätsdienstleister (Ziffer 7.1 und 7.2): bis zur Löschung des Kontos, die das Konto bei Auth0 mitlöscht.
• Reichweitenmessung: bis zu 14 Monate ab der letzten Interaktion für ereignis- und nutzerbezogene Daten bei Google, 182 Tage für das Einwilligungs-Cookie auf deinem Gerät — siehe Ziffer 10.
• Veranstaltungsvorschläge: die nach Status getrennte Speicherdauer aus Ziffer 8.4.
• Supportanfragen: 24 Monate nach Abschluss des Vorgangs — siehe Ziffer 8.7, auch dazu, warum die Frist ab dem Abschluss und nicht ab dem Eingang läuft.
• Meldungen zu Inhalten: 24 Monate nach der Entscheidung — siehe Ziffer 8.8, auch dazu, warum die Frist ab der Entscheidung und nicht ab dem Eingang läuft und warum eine noch nicht entschiedene Meldung nicht gelöscht wird.
• Aktionen der Administration an Nutzerkonten (Audit-Protokoll): 24 Monate nach der Aktion — siehe Ziffer 8.9, auch dazu, was bleibt, wenn das Konto gelöscht wird. Kontodaten und Anmeldeverlauf, die der Administration angezeigt werden, werden live bei Auth0 gelesen und von BrickDb nicht gespeichert.
• Fotos zum Lesen der Setnummer (Ziffer 8.5) und zur Zustandsbewertung (Ziffer 8.6): werden bei BrickDb nicht gespeichert und mit Ende der Anfrage verworfen.
• Versendete E-Mails: bei BrickDb wird keine Kopie angelegt; zu den Zustelldaten beim Versanddienstleister siehe Ziffer 7.3.
• Protokolle auf Infrastrukturebene: siehe Ziffer 3.
• Fehlerberichte bei Sentry: 90 Tage — siehe Ziffer 11; die IP-Adresse der Verbindung, über die sie zugestellt wurden, bewahrt Sentry nicht auf.
• Laufzeitmessungen bei Sentry: vollständig höchstens 90 Tage, als verkleinerte Stichprobe bis zu 13 Monate — siehe Ziffer 11.

Wird ein Eintrag gelöscht, werden die zugehörigen Fotos mitgelöscht — einschließlich der verkleinerten Fassungen nach Ziffer 8. Aus Sicherungskopien verschwinden gelöschte Daten mit deren regulärem Ablauf, spätestens nach 35 Tagen.

14. Rechte der betroffenen Personen

Es bestehen die folgenden Rechte:

• Auskunft über die verarbeiteten Daten (Art. 15 DSGVO),
• Berichtigung unrichtiger Daten (Art. 16 DSGVO),
• Löschung (Art. 17 DSGVO),
• Einschränkung der Verarbeitung (Art. 18 DSGVO),
• Datenübertragbarkeit (Art. 20 DSGVO),
• Widerspruch gegen Verarbeitungen, die auf Art. 6 Abs. 1 lit. f DSGVO gestützt sind (Art. 21 DSGVO),
• Widerruf einer erteilten Einwilligung mit Wirkung für die Zukunft (Art. 7 Abs. 3 DSGVO).

Zur Ausübung genügt eine formlose Nachricht an die unter Ziffer 2 genannte E-Mail-Adresse.

Das Auskunftsrecht nach Art. 15 DSGVO lässt sich außerdem unmittelbar und ohne Nachricht ausüben: Die Kontoseite erzeugt eine vollständige, maschinenlesbare Kopie aller gespeicherten Daten — Konto und Profil, Sammlungen mit ihren Mitgliedern und den von dir ausgesprochenen Einladungen, die Exemplare darin mit Notizen, Schlagwörtern, Zustand, Kaufpreisen und Verkäufernotizen, einzelne Minifiguren und lose Teile, deine Exemplare von Magazinausgaben und Büchern, deine Lagerorte und welches Exemplar an welchem davon liegt, erfasste Signaturen, die Merkliste, die eigenen Beiträge zu Tütencodes und Verpackungsbarcodes, die eigenen Veranstaltungsvorschläge in jedem Moderationsstatus, angestoßene Stapelverarbeitungen von Verpackungsfotos, die Einträge des Audit-Protokolls der Administration zu deinem Konto (Ziffer 8.9), jedes hochgeladene Foto sowie dein Avatarbild, falls du eines hochgeladen hast.

Was diese Kopie nicht enthält, und warum: die Anmeldedaten beim Identitätsdienstleister (E-Mail-Adresse, Passwort, Anmeldeverlauf, hinterlegte zweite Faktoren) — sie liegen bei Auth0, das dafür eine eigene Auskunft erteilt; Einladungen, die andere an deine Adresse gerichtet haben, weil sie deren Daten sind und nicht deine; die aus deinen Exemplaren abgeleitete Teileansicht, weil sie nichts enthält, was nicht ohnehin in der Kopie steht; Supportanfragen — und zwar alle, weil in dieser Version kein Vorgang mit einem Konto verknüpft ist und wir nicht erkennen können, welche deine sind (Ziffer 8.7 sagt, wie du uns dazu erreichst); interne Notizen zu einem Supportvorgang, die uns gehören und nicht dir (ebenfalls Ziffer 8.7); die kurze Aufzeichnung einer Mail an die Supportadresse, die kein Vorgang wurde, weil sie mit keinem Konto verknüpft ist (Ziffer 8.7); Meldungen zu Inhalten, die ebenfalls mit keinem Konto verknüpft sind, und die Notizen, die wir bei der Entscheidung über eine Meldung zu deinem Inhalt geschrieben haben (Ziffer 8.8); wer aus der Administration an deinem Konto gehandelt hat, weil das die Daten dieser Person sind und nicht deine (Ziffer 8.9); und die eingereihte Benachrichtigung zu einem von dir eingereichten Veranstaltungsvorschlag, die nur Versandmechanik enthält und auf den oben bereits aufgeführten Vorschlag verweist.

Auch das Recht auf Löschung nach Art. 17 DSGVO lässt sich dort unmittelbar ausüben. Die Kontoseite zeigt vorab an, was genau gelöscht wird; bestätigt wird die Löschung dann sofort ausgeführt: die Sammlung, die Lagerorte, die Fotos (die Dateien selbst, nicht nur die Einträge) und das Anmeldekonto beim Identitätsanbieter. Das lässt sich nicht rückgängig machen.

Die Ausnahmen sind bewusst so geregelt; für Veranstaltungen gilt Ziffer 8.4. Die eigenen Beiträge zu den Tütencodes werden anonymisiert statt gelöscht: welche Figur in einer Tüte steckt, ist eine Tatsache über ein LEGO-Produkt, die andere Nutzerinnen und Nutzer gemeinsam ermittelt haben und auf die sie sich verlassen — der Beitrag bleibt bestehen, die Verknüpfung zur Person wird ersetzt durch einen neu gezogenen Zufallswert, zu dem kein Konto und keine Zuordnung mehr existiert (Erwägungs­grund 26 DSGVO). Ein Exemplar, das in eine mit anderen Personen geteilte Sammlung eingebracht wurde, wird ebenso anonymisiert statt gelöscht: es zu löschen würde den anderen Beteiligten ihren Eintrag zu einem gemeinsam geführten Set nehmen. Setnummer, Anzahl und Zustand bleiben daher bei der Sammlung; alles Persönliche daran fällt weg — der selbst vergebene Name, die Notizen, die Schlagworte, der Aufbewahrungsort, der gezahlte Preis, die eigene Wertschätzung und die Fotos — zusammen mit der Verknüpfung zur Person, ersetzt durch einen ebenso neu gezogenen Zufallswert. Ein Exemplar in einer Sammlung, in der sonst niemand ist, wird vollständig gelöscht — es gibt niemanden, dem es genommen würde. Und Sicherungskopien folgen weiterhin Ziffer 13: gelöschte Daten verschwinden dort mit deren regulärem Ablauf, spätestens nach 35 Tagen.

Die einzelnen Schritte, eine Aufzählung dessen, was gelöscht wird und was anonymisiert erhalten bleibt, und der Weg für Personen, die sich nicht mehr anmelden können, stehen zusammengefasst auf der Seite Löschung von Konto und Daten. Sie ist ohne Anmeldung erreichbar und gibt nur wieder, was in dieser Ziffer steht.

Beschwerderecht

Unabhängig davon besteht nach Art. 77 DSGVO ein Beschwerderecht bei einer Aufsichtsbehörde, insbesondere im Mitgliedstaat des gewöhnlichen Aufenthaltsorts, des Arbeitsplatzes oder des Orts des mutmaßlichen Verstoßes. Für den Verantwortlichen zuständig ist:

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
Postfach 20 04 44
40102 Düsseldorf
Telefon: +49 211 38424-0
E-Mail: poststelle@ldi.nrw.de
www.ldi.nrw.de

15. Pflicht zur Bereitstellung

Die Bereitstellung von Daten ist weder gesetzlich noch vertraglich vorgeschrieben. Ohne Angaben lassen sich die Sammlungsfunktionen jedoch nicht sinnvoll nutzen; die frei zugänglichen Teile des Angebots stehen ohne jede Angabe offen.

16. Änderungen und maßgebliche Sprachfassung

Diese Erklärung wird angepasst, wenn sich die Verarbeitung oder die Rechtslage ändert. Maßgeblich ist die jeweils hier veröffentlichte Fassung mit dem oben genannten Stand.

Maßgeblich ist die deutsche Fassung. Die Fassungen in englischer, französischer, niederländischer, dänischer, italienischer und spanischer Sprache sind Übersetzungen zur Information und haben keine eigenständige rechtliche Wirkung.