Privacy Policy

1. In brief

Everything in this policy has been checked against the application's source code. If you need an answer on any of it, please use the contact details in section 2.

BrickDb is a service of ThreeB IT GmbH, with no ad banners. This policy describes the data that is actually processed — not what such texts usually say.

• Your consent is asked for before any audience measurement with Google Analytics. Without it none takes place: no script is loaded, no identifier is set, and nothing is sent to Google. Section 10 has the detail. The same holds for the usage statistics in the apps, which the app itself asks about (section 10.3).
• For session recordings and heatmaps with Microsoft Clarity, a separate consent of its own is asked for. Without it nothing of Microsoft Clarity's is loaded, and anyone who has agreed only to the audience measurement is not recorded. Text, images and input are masked in a recording. Section 10.2 has the detail.
• Without your consent, opening a page establishes no connection to any third party. Fonts, too, are held on our own server. The one exception is the anti-spam check on the pages that carry a public form (section 8.13).
• Photos are visible only to you and to those members of a shared collection to whom you have granted the private details; they never appear on a collection's public page. Section 8.2 has the detail. Embedded metadata — including GPS coordinates — is removed during processing. For the automated check under section 8.12, a reduced copy is sent to Microsoft as processor.
• Nothing by which you could be recognised is stored on the device before you have actively chosen a setting, signed in, or given your consent. What the browser needs purely technically for the security of the site's forms, and what carries your sign-in, is listed in full in section 6.1; what the app puts on the device is in section 6.5. You can change your decisions about the audience measurement and about the session recordings at any time, behind the cookie symbol at the bottom right of every page, each on its own.

2. Controller

The controller within the meaning of Article 4(7) GDPR is:

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Germany
Telephone: +49 (5451) 893922-0
E-mail: hello@brickdb.net

Represented by its managing directors (Geschäftsführer) Thimo Buchheister and Thorsten Brügge.

No data protection officer has been appointed.

3. Visiting the website

When www.brickdb.de or one of the further addresses BrickDb is reachable at (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) is accessed, the web server processes the data that a browser must transmit for technical reasons in order for a page to be delivered: IP address, date and time of the request, the address requested, the volume of data transferred and the status code, the browser and operating system identifier (user agent), and the language preference sent by the browser (Accept-Language).

This data necessarily arises with every connection on the internet. It is processed in order to deliver the page, to ensure technical functioning and to defend against attacks.

One further, narrow use is made of the language preference: the region subtag it carries (for example DE from de-DE) is read while the request is being answered, in order to pre-select a country: on the events list, and for the prices on set and minifigure pages, that is, which shops' prices are shown and in which currency prices are displayed. If you are signed in and have recorded a country in your profile (section 7.2), that country is used instead. A country you have chosen and saved on the site itself (section 6.1, bd-country) takes precedence over both. The region is not stored, not combined with anything else and not passed on; the chosen country is visible on the page — on the events list also in the address bar — and can be undone there in one click.

On the addresses that belong to one country (for example www.brickdb.de or www.brickdb.fr), the country follows from the address itself. On www.brickdb.net and www.brickdb.eu, which belong to no single country, one further item is used: the delivery network in front of the site (Azure Front Door, a service of the processor Microsoft named in section 4) derives a two-letter country code (for example SE) from the IP address of the request at the edge of the network there and passes it to the application. It serves the same purpose as the region: pre-selecting a country for prices and events. The application receives nothing but that code, and in particular no more precise location; the code is not stored, not logged and not combined with anything else. No third party's geolocation service is used; the IP address is not disclosed for this purpose to anyone who does not process it anyway in order to deliver the page. The legal basis for this is Article 6(1)(f) GDPR; the legitimate interest is to show you prices and events for your own country without asking you first. You can override it at any time by choosing a country on the site itself (section 6.1, bd-country).

Legal basis: Article 6(1)(f) GDPR. The legitimate interest lies in the technically sound and secure operation of the service.

Storage period: The application itself keeps no access log. Logs arising at infrastructure level are retained only for as long as is necessary for operational security, and for 30 days at most, unless they are needed to investigate a specific security incident.

4. Hosting

The service is operated on Microsoft Azure; the provider is Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland. The Azure region Germany West Central (Frankfurt am Main) has been chosen as the place of processing; the database and the file storage are therefore located in Germany.

In this respect Microsoft is a processor under Article 28 GDPR on the basis of the Microsoft Products and Services Data Protection Addendum.

Requests to BrickDb pass through Microsoft's delivery network Azure Front Door. It accepts the connection at a location near you — which can be outside Germany and outside the EU and the EEA — and forwards it; the application and all stored data remain in Germany West Central (Frankfurt am Main). This, too, takes place as processing on our behalf under the Microsoft Products and Services Data Protection Addendum; where it involves a transfer to a third country, what the following paragraph says about Microsoft under “Transfer to third countries” applies to it.

Transfer to third countries: Access from third countries cannot be entirely ruled out in the course of support and maintenance operations. Microsoft bases such transfers on the European Commission's standard contractual clauses and is additionally certified under the EU-US Data Privacy Framework.

5. Fonts and external content

The fonts used are delivered from our own server. No fonts are loaded from third-party servers — in particular not from Google Fonts. There are no maps, videos, social media plug-ins or other embedded third-party content.

Without your consent, opening a page establishes no connection to any third party and transmits no IP address to any third party — except for the anti-spam check on the pages that carry a public form (section 8.13).

The only other exceptions are the audience measurement described in section 10 and the session recording described in section 10.2, and they are not a qualification of that sentence but its condition: Google's script is loaded only after you have agreed to the audience measurement in the consent banner, Microsoft Clarity's script only after you have agreed to the session recordings there. Until you have agreed or refused, nothing of Google's and nothing of Microsoft Clarity's is loaded — not even a so-called cookieless ping.

6. Storage on the device

BrickDb sets no cookies for marketing or advertising purposes. The only things stored are what records a deliberately chosen setting, what the security of the forms requires, what carries your sign-in if you sign in — and, if you have agreed to the audience measurement in section 10, the analytics cookies described there, and, if you have agreed to the session recordings in section 10.2, the entries of Microsoft Clarity described there. None of these entries is set before you have given the agreement it depends on. What the app also keeps on the device so that it works without a connection is described in section 6.5.

6.1 What is stored

The entries for appearance, language, country, currency and the closed country hint contain nothing but the value last selected. They contain no identifier and nothing from which a person or a device could be recognised. They are first-party storage; no third party has access to them. Each of them applies only to the address it was set on: a choice made on www.brickdb.de is not read on www.brickdb.fr. bd-country arises when you choose and save a country, bd-market-hint when you close the hint that there is an address of its own for your country — all it does is keep that hint from being shown again on every page. bd-analytics-consent is additionally HttpOnly, because no script in the browser needs to read it: whether the audience measurement or the session recording runs is decided by the server before the page exists. It records separately for each of the two purposes whether you have allowed it. An agreement you gave before 10 October 2026, when there was only the audience measurement (granted), continues to apply to that alone; you are asked about session recordings once, separately (section 6.6). The cookie also records which version of this notice you answered, when that was, and a random number under which the record of your consent is kept as described in section 6.6; that number says nothing about you.

The antiforgery cookie is set by the web framework on every page that carries a form — including the page the consent banner is on. It protects those forms from being submitted from someone else's site (cross-site request forgery), carries nothing about you, is HttpOnly and SameSite=Strict, and ends with the session. For the consent banner it is the reason nobody else can record an agreement in your name.

The sign-in cookies arise only when you sign in. bd.auth holds your sign-in session; its contents are encrypted, it is HttpOnly and Secure, and it is sent only to this site (SameSite=Lax). It does not extend itself: the session ends when the sign-in does, not when you stop clicking, and signing out removes it. The two handshake cookies are set by the framework for the duration of a single sign-in; they bind the return from the sign-in screen to the attempt you actually started, and are removed afterwards.

bd-ref, _ga and _ga_… are the cookies of the audience measurement from section 10. They are set only after your consent. bd-ref is set by BrickDb itself, and only at the moment you agree: for one minute at most it holds the address of the page you came to BrickDb from — without its query string (everything from the "?" on), and only if that page is not one of BrickDb's own — it is HttpOnly, and it is deleted again with the next page; what it is for is described in section 10. The Google Analytics cookies carry a random identifier by which repeat visits from the same browser are recognised.

The entries _clck, _clsk and _cltk are set by Microsoft Clarity as described in section 10.2 — only after your separate consent to the session recordings. _clck carries a random identifier by which repeat visits from the same browser to this website are recognised, _clsk groups the page views of one visit into one recording, and _cltk tells several open tabs apart. The two cookies may be set for the parent address (for example brickdb.de instead of www.brickdb.de); they are not shared between the country addresses. Cookies on Microsoft's own addresses, by which Microsoft recognises browsers across different websites (MUID and the like), are not set: the matching needed for that is switched off, as section 10.2 describes.

bd-currency arises when you choose a currency. Appearance and currency are additionally kept in local storage, so that the page can apply them without asking the server. acaAffinity is set not by BrickDb itself but by the hosting platform described in section 4: it makes consecutive requests from your browser reach the same server, which the page's live connection requires. It names a server and carries nothing about you, is HttpOnly, and ends when the browser is closed. The table is generated from the same list as the Cookies page, where every entry is shown by purpose.

6.2 Why no consent is required for anything but the entries of the audience measurement and the session recording

The relevant provision is section 25 of the German Telecommunications Digital Services Data Protection Act (TDDDG). It covers any storage of information on a terminal device and any access to it — so not only cookies, but expressly local storage as well. Under section 25(2) no. 2 TDDDG, consent is not required where the storage is strictly necessary in order to provide a service expressly requested by the user.

That is the case here, and for reasons that can be verified against the behaviour of the application:

• Nothing is stored before an active choice is made. Merely opening the page writes no entry. An entry arises only when the switches for appearance or language are operated, when you choose and save a country, or when you close the hint pointing to another country address.
• Returning to the default deletes the entry again. If "System" is selected, the corresponding entry is removed rather than overwritten.
• What is stored is precisely the setting that was expressly requested, and nothing else.
• bd-analytics-consent qualifies for a reason of its own: it records the decision you have just made. Without it the question would have to be asked again on every page — including of somebody who has only just refused.
• The antiforgery cookie is the clearest of the three: without it a form on this site cannot be protected from misuse from outside, and that includes the button with which you agree to or refuse the audience measurement. It is not stored so that something can be measured, but so that the input that counts is your own.
• For the three sign-in cookies it is clearest of all: without them a sign-in can neither be carried out nor kept. Somebody who signs in is asking for exactly the service they provide, and they arise only at the moment it is asked for — somebody who does not sign in receives none of them.

A setting that is remembered on express request is therefore strictly necessary in order to provide the service requested; for the security of the forms and for signing in that is true in any case. No consent is obtained for those entries.

Objection and deletion: The appearance and language entries can be removed at any time by selecting "System" again in the switch or by clearing the browser data. The site works unchanged without them; it then appears in the appearance and language specified by the operating system or the browser respectively. The entries for the country and for the closed hint are removed by clearing the browser data; without them the country is pre-selected again as section 3 describes.

6.3 Audience measurement and session recording — only after consent

Section 25(2) no. 2 TDDDG does not apply to the audience measurement's cookies or to the session recording's entries: neither measuring reach nor recording sessions is necessary for the service you asked for, and the site works completely without them. They therefore fall under section 25(1) TDDDG and are set only once you have agreed to the respective purpose in the consent banner. The banner appears on the first page you open. It names both purposes individually, neither is pre-selected, and it offers "Allow all", "Refuse all" and "Save selection" as buttons of the same size, side by side — allowing everything and refusing everything are each a single click.

6.4 Technically necessary connection data

The user interface is rendered on the server and holds a WebSocket connection to the server while it is in use. The associated session state resides exclusively in the server's memory, is not stored on the terminal device and ends when the page is closed.

6.5 In the app

The BrickDb app for mobile devices and computers shows the same pages but puts nothing into browser storage. There, the appearance and language settings live in the operating system's own settings store and contain, as in section 6.1, nothing but the value last selected.

If you sign in within the app, your session is placed in the device's protected storage — the Keychain on iOS and macOS, Keystore-backed storage on Android. Four things are placed there: the access token, the refresh token, the expiry time and which way you signed in.

A fifth is the ID token, and it is the only one of them that contains details about you. It is issued by Auth0 when you sign in and kept there because the app reads from it who it is dealing with. It contains your account identifier at the identity provider, your name and your e-mail address, whether that address is confirmed, and a technical one-time value from the sign-in. Those details are therefore on the device, even though under section 7.1 they are not taken into our database. A password is not among them, because the app never accepts one (section 7.1).

All five are removed when you sign out. So that you can use the app without a connection, it also keeps three stores on the device:

• A copy of your collection. While you are signed in, the app keeps a copy of what you have entered in your collection under section 8.1: your sets with the details of each copy, including notes, the price paid and notes on the seller, your wishlist, your minifigures, loose parts, books, magazine issues and video games, the storage places of the collections you can see, and the last value worked out for your collection with its date. The copy is brought up to date every time the app synchronises with BrickDb — when it starts, when it returns to the foreground, when a connection is available again, and when you choose “Send now” — and it is shown only when BrickDb cannot be reached. The photos of your copies are not in it. In the same file, also when you are not signed in, the app keeps the approved shops of the one country you last looked at in the store finder and the series of collectible minifigures and sets you opened — without values and without anything about what you own.
• Changes you make without a connection. If you add something to your collection, change it or remove it while BrickDb cannot be reached, the app saves the change on the device — including a photo you add to a copy at the time, of up to 25 MB — and sends it to BrickDb's server as soon as a connection is available again. Only there is a photo's metadata removed (section 8.2); until then it is on the device as it was taken. A change that has been sent is deleted from the device; one that cannot be sent is shown to you by the app, and you can discard it.
• Recently viewed pages. The app keeps the pages of the catalogue, the blog, the FAQ, the reviews, the guides and the glossary that you have looked at, with their pictures, so that they open without a connection too — also when you are not signed in. How much space it uses for this is your choice in the app's settings under “Offline cache”: 100 MB, 200 MB, 500 MB or 1 GB, with 200 MB preset. When the chosen space is used up, what you have not looked at for longest is removed first, and “Clear” deletes everything at once. Prices and offers, search results, anything that concerns only you — such as your collection, your wishlist or your account — and pictures of people's own creations (MOCs) are never kept in it. This store is in the device's cache, which the operating system may empty by itself when space runs short.

All three stores are only on your device, in files in the app's data area and not in the protected storage that holds your session. They are not passed on to third parties; the only thing transmitted is the held-back changes, and only to BrickDb's server (section 4). All three are deleted when you sign out; if there are changes not yet sent, the app first asks whether you want to sign out anyway. Depending on your device's settings, the copy of your collection and the held-back changes may be included in a backup you have set up with the provider of your operating system; the recently viewed pages are not.

Legal basis for these three stores is Article 6(1)(b) GDPR — as for your collection data itself (section 8.1), the processing is necessary to provide the service you asked for without a connection as well. No consent under § 25 TDDDG is required, because storing on the device is strictly necessary for that (§ 25(2) no. 2 TDDDG, section 6.2).

For the app's usage statistics (section 10.3) the same settings store holds two more values: your decision about them — allowed or refused, with the time — and, only after your consent, a random identifier of the installation. The decision is kept when you sign out; the identifier is deleted then and, for as long as your consent stands, replaced by a new one.

For push notifications (section 10.4), once you switch them on in the app, OneSignal’s SDK stores values of its own in the operating system’s settings storage: an identifier from OneSignal, the status of your subscription, the device token and your push ID. Before that, the app stores nothing for this. When you sign out, the device is disconnected from your push ID.

6.6 Cookie settings, the record of your consent, and Global Privacy Control

Cookie settings. The Cookies page shows every entry from section 6.1 by purpose, and one box each for the audience measurement and for the session recordings. It can be reached from the consent banner, from the cookie symbol at the bottom right of every page and from the footer, and it works without script. Your choice applies only to the country address you make it on.

The record of your consent. We have to be able to demonstrate that consent was given (Art. 7(1) GDPR). For every decision — agreement, refusal, change, withdrawal — we therefore store an entry on our server: a random number, which is also in the bd-analytics-consent cookie, the purposes allowed afterwards, the version of this notice, the country address and the time. Your account, your IP address and details of your browser or device are not stored. The number exists otherwise only in your cookie; we therefore cannot attribute the entry to a person unless you tell us the number yourself. The legal basis is Art. 6(1)(c) GDPR in conjunction with Art. 5(2) and Art. 7(1) GDPR. Each entry is deleted 36 months after the decision it records; that is how long claims about processing based on it can ordinarily be raised. Because the entry is not linked to an account, it is neither part of the information about your account's data nor deleted with your account. You can delete it yourself at any time on the Cookies page; your browser then counts as not yet asked.

Versions of this notice. The notice you decide against carries a date as its version; the version currently in force is that of 10 October 2026. If it changes materially — a purpose, a recipient or a kind of data is added — we ask you again, and only about the purpose the change concerns. Until you answer, that purpose is off; everything else stays as you chose it. A change of wording alone does not lead to a new question.

Global Privacy Control. If your browser sends the "Global Privacy Control" signal (Sec-GPC: 1) and you have not yet made a choice on this address, we treat that as a refusal of both purposes: nothing is loaded, and the banner does not ask you. The panel behind the cookie symbol at the bottom right of every page and the Cookies page say that the signal was honoured; you can decide otherwise there. If you make a choice yourself, it takes precedence over the signal, because it refers expressly to this website and to the individual purpose; you can withdraw it at any time. Nothing is stored for the signal alone, not even a record of consent. We do not evaluate the older "Do Not Track" signal.

7. User account

7.1 Signing in

BrickDb can be used without an account: the catalogue, the search and the scanner are open without signing in. You need an account only in order to keep a collection of your own.

Signing in runs via the identity provider Auth0 (Okta, Inc.), through a tenant in the European Union. Four ways are offered: an account with an e-mail address and a password, signing in with an existing Google account, signing in with your Apple Account ("Sign in with Apple"), or signing in with a personal Microsoft account (such as Outlook.com, Hotmail or Xbox); Microsoft work and school accounts are not accepted. Which of them you use is your choice. The same applies to the website and to the app.

The sign-in form is a page of Auth0's, not of BrickDb's. A password is never entered on, accepted by or passed through a BrickDb page; changing a password happens at Auth0 as well. Somebody who signs in with Google, Apple or Microsoft has no password at Auth0 at all — the credential then lives at Google, Apple or Microsoft, and BrickDb sees it just as little. With "Sign in with Apple" you can also choose to hide your e-mail address: BrickDb then receives an address of Apple's relay service (ending in @privaterelay.appleid.com), through which Apple forwards our e-mails to you.

Several ways into one account. On the account page you can connect further ways of signing in to your account, for example Google to an account you created with an e-mail address and a password. To do so you sign in once with the new way; only that sign-in shows that it is yours. We never connect accounts because their e-mail addresses match. At Auth0 the two sign-ins are joined into one user; profile details that are empty in your account are taken over from the other one. If the connected way already had a BrickDb account of its own, we move its contents (collection, wishlist, photographs, storage places, MOCs, contributions and support requests) into your account and delete the other account; anything a person can have only once, such as the same wish twice, becomes one entry. You can disconnect an added way of signing in at any time; your data stays with this account. The data export (section 14) lists the connected ways of signing in. The legal basis is Art. 6(1)(b) GDPR.

Google, Apple and Microsoft are responsible for their own part of the sign-in. If you choose one of these ways, you sign in on a page of that provider. The provider processes your credentials and the data of that sign-in as an independent controller under Article 4(7) GDPR, not on BrickDb's behalf, and under its own terms: for users in the European Economic Area, Google Ireland Limited (Google's privacy policy), Apple Distribution International Limited (Apple's privacy policy) or Microsoft Ireland Operations Limited together with Microsoft Corporation (Microsoft's privacy statement). Through Auth0 the provider passes on to BrickDb only the details the next paragraph names.

What BrickDb receives. After a successful sign-in, Auth0 hands over what was asked for: a pseudonymous identifier for your account, the profile details held with the sign-in, and your e-mail address. None of it is stored except the pseudonymous identifier and the time the record was created — that is the entire content of our own account record. Your name, profile and e-mail address stay at Auth0 and are read there when they are needed (section 7.2); they are not taken into our database.

Two-factor authentication is offered and never required. Anybody who wants one may register an authenticator app (TOTP), a device key such as Face ID, Touch ID or Windows Hello, a hardware security key, and recovery codes. Without such a registration nobody is ever asked for one. Codes by SMS or by e-mail are deliberately not offered.

What Auth0 processes in doing so. Auth0 processes the sign-in credentials themselves along with the technical data of each attempt — time, IP address, browser and device identifier — in order to carry out the sign-in and to detect abusive attempts. When an account is created and whenever a password is changed, Auth0 additionally checks whether the chosen password has appeared in a known data breach, and refuses it if it has. That check does not run on an ordinary sign-in.

Legal basis: Article 6(1)(b) GDPR — without an account the collection features cannot be provided. For the detection of abusive attempts and the check against known breached passwords, Article 6(1)(f) GDPR; the legitimate interest lies in the security of accounts. Auth0 is a processor under Article 28 GDPR in this respect.

Transfer to a third country: the tenant is in the European Union and that is where signing in takes place. The contracting party, however, is Okta, Inc. (Auth0), based in the United States, so access from there — in the course of support and maintenance, for example — cannot be ruled out. Okta bases such transfers on the European Commission's standard contractual clauses, attached as separate documents to its data processing addendum of 15 December 2023.

Storage period: the account record exists until you delete your account. Deleting it on the account page also deletes the Auth0 account and with it the details held there (section 14).

7.2 Profile: name, about text, country and optional address

You may record a first name, a last name, a short text about yourself, your country, which of our avatar drawings you chose, and — optionally — a full postal address.

None of it is stored by BrickDb. It is held by the identity provider Auth0 with your sign-in account, and BrickDb reads and writes it there rather than keeping a copy: our own account record contains nothing but a pseudonymous identifier and the time it was created. The one exception: if you publish a MOC or make it unlisted, we store the name shown beside it as a copy with that MOC (section 8.11). Deleting your account under section 14 deletes the Auth0 account, and this profile with it.

Every field is voluntary. Nothing here is required, nothing is a condition of using BrickDb, and no function is withheld from you for leaving a field empty. You can change or clear any of it at any time.

Why the address is asked for, specifically. Two purposes, both stated here before the field is offered rather than afterwards:

• Insurance valuation. BrickDb will offer a valuation of a collection for insurance purposes. A valuation is tied to the place at which the collection is kept, and an insurer does not accept one without it.
• A planned marketplace with BrickDb as trust intermediary. BrickDb intends to offer a marketplace in which it acts as a trust intermediary between buyer and seller. A party's postal address is what makes such a transaction attributable and a dispute resolvable.

Neither service is available yet. The address is not used for anything else: not for advertising, not for profiling, not for any form of scoring, and it is not passed on to third parties.

Your country is also used to pre-select a country on the events list and for the prices on set and minifigure pages, ahead of the browser's language preference described in section 3. It is read from Auth0 when such a page is displayed, is not stored by BrickDb for this and is not passed on, and the choice can be undone on the page in one click.

The country and language you choose on the site. If you choose and save a country and a language for the site while signed in, both are stored with your sign-in account at Auth0 in addition to the entries in the browser (section 6.1), so that the choice also applies on another device and at another of BrickDb's addresses. BrickDb keeps no copy of its own of these either. If you are not signed in, the choice stays in the browser alone.

The view of the series lists you last chose. If you open the collectible minifigures or the collectible sets while signed in, the series and the owned-or-missing filter you last chose are also stored with your sign-in account at Auth0, so that the list opens there again next time. BrickDb keeps no copy of its own; like the profile, the view is included in the copy of your data and is deleted with your account. In the app it is kept in the device's settings store instead (section 6.5) and is deleted when you sign out.

Legal basis: for first name, last name, about text, country, the language chosen and the view of the series lists, Article 6(1)(b) GDPR — the processing is part of the service requested. For the address, Article 6(1)(a) GDPR — consent, given by filling the field in and withdrawn at any time by clearing it. Withdrawing affects nothing else about your account and has no effect on the lawfulness of processing carried out before it.

The profile is included in the copy of your data under section 14 and is deleted with your account under the same section.

7.3 Sending e-mail

BrickDb sends e-mail only where there is a specific occasion for it: confirming your e-mail address and resetting your password, an invitation to a collection when somebody invites you to one (section 8.1a), an invitation to choose your password when an administrator creates an account for you (section 8.9), our answer to a support request, and a notification to our own mailbox when somebody files one — that last one is addressed to us rather than to you, but it carries what the requester wrote (section 8.7 covers both) —, a notification to our own mailbox when somebody reports content, and the statement of reasons sent to you when a report about content you published is upheld, and the confirmation of receipt and the decision sent to you when you left an address with a report (all section 8.8). There is no newsletter, and advertising mail reaches you only if you have expressly switched it on yourself and confirmed it through the link in a confirmation e-mail (section 10.4). On top of that comes the message about a price alert, if you switched one on for a set on your wishlist (section 10.4); it is not advertising mail. If you asked for building instructions as a PDF while signed in, there is also the message that they are ready (section 8.14); it is not advertising mail either. If you are in a shared collection, or submitted an event while signed in, there are also the messages under section 10.4 that something changed for you there or how our moderation decided; they are not advertising mail either, and you can switch them off in your account under “Notifications”.

The mail provider is Twilio Inc. (“SendGrid”), 101 Spear Street, 5th Floor, San Francisco, CA 94105, USA. SendGrid receives the recipient address, a display name where one exists, the subject and the full content of the message, along with the technical delivery data (time, delivery status, the receiving mail server's answer). Your e-mail address is therefore passed to a third party, and it is the first thing that happens to it — before anything else does. That is why this is stated here and not further down under section 12.

Legal basis: Article 6(1)(b) GDPR — confirming an address, resetting a password and delivering an invitation are part of the service requested. SendGrid is a processor under Article 28 GDPR on the basis of the Twilio Data Protection Addendum.

Third-country transfer: mail is sent through SendGrid's global infrastructure, so the processing takes place in the United States — not in Germany, as the hosting under section 4 does. Twilio bases such transfers on the European Commission's standard contractual clauses and is additionally certified under the EU-US Data Privacy Framework.

Open and click measurement: yes for account mail, no for our own. E-mail about your account — address confirmation, password reset — is extended by SendGrid before it is sent with an invisible image, and its links are redirected through SendGrid. When your mail program displays such a message it fetches that image, and in doing so sends the time and your IP address to SendGrid; the same happens when you click a link. From that, SendGrid derives whether and when such a message was opened. Legal basis: Article 6(1)(f) GDPR — our legitimate interest in account mail arriving rather than landing in a spam folder. You may object under Article 21 GDPR using the contact details in section 2, and you can switch off image loading in your mail program, in which case no open measurement takes place.

Mail BrickDb sends itself contains neither such an image nor redirected links — today that is the collection invitations, both support mails in section 8.7, our answer to a request and the notification it sends us, the report mails in section 8.8, the message that building instructions are ready under section 8.14 and the messages about shared collections and submitted events under section 10.4. None of them requests anything from any server when opened; every send switches both measurements off at SendGrid explicitly.

Storage period: BrickDb keeps no copy of a message it has sent. At the mail provider, the delivery data remains retrievable in its activity log for a short period that depends on its plan.

Status of this version: this section describes the sending path as it currently stands. It read “as it has existed since 10 September 2026” until the support notification named above joined it.

8. Collection data and photos

The following statements describe the processing that takes place with an account under section 7.

8.1 Collection data

What is stored is what you enter yourself: set number, name, condition details, notes, date of acquisition, price paid, information about the seller, and the times of creation and of the last change. These entries are linked to a pseudonymous identifier.

The same is stored for what you enter in the other areas: individual minifigures and loose parts with the same details, copies of magazine issues and books with their grade, the state of a bundled polybag, your remarks on their condition, how and when you acquired them, the price paid, the note about the seller and your notes, collections with their name, their description, their visibility under section 8.1a and their members together with each member's role, invitations you have issued together with the e-mail address given for them, signatures you record against a copy, your wishlist, your contributions towards resolving bag codes and retail barcodes, and the batches of box photographs you submit for processing.

Copies of magazine issues and books are not filed into a collection; only you see them.

Storage places. You can record where your things are kept: rooms, locations inside a room and compartments inside a location, each with the name you give it, its level and its position in your list, and for each copy — sets, minifigures, loose parts, magazine issues and books — which place it is kept in. Every collection has its own storage places; yours are those of your personal collection, and if you share it you share its storage places too. A collection's storage places, and where its copies are kept, are seen by all its members, including those with the Reader or Insurance role; members whose role is Owner or Editor can create, change and assign them. A published collection never shows them (section 8.1a). If you delete your account (section 14), the storage places of a collection that still has other members stay with that collection; the others are deleted with the collection.

Free-text fields are not evaluated. Please do not enter any special categories of personal data within the meaning of Article 9 GDPR there.

Legal basis: Article 6(1)(b) GDPR — the processing is necessary in order to provide the service requested.

8.1a Who can see a collection

Every copy you own is filed into a collection, and a collection has one of three settings, which you choose and can change: private (only its members see it — the default for a new one), anybody with the link, or anybody, including search engines.

A collection you have made public shows its name and its description, the set numbers, the set names, how many copies of each you hold and the condition each one is in, and nothing else. No photographs, no notes, no tags, no nicknames, no storage locations, no purchase prices, no valuations, no acquisition dates and nothing about the seller. It does not name you or any other member, and it does not say how many people are in it. Those fields are not hidden on that page — they are not sent to it at all.

A link is not a password. A collection set to “anybody with the link” is served to whoever asks for that address, whether you gave it to them or not. The “anybody with the link” setting additionally asks search engines not to list the page, which they generally respect and are not obliged to. Setting a collection back to private stops it being served immediately, but it cannot recall a copy somebody — or a search engine — already took.

A collection shared with named members is different from a public one: what each member sees depends on the role you gave them. A Reader sees exactly what the public page shows. An Editor sees everything, including the fields listed above. Insurance sees the sets, their condition and valuation figures, and none of the rest.

The names of members. The member list of a shared collection shows, beside the role, the name your account carries at our sign-in provider Auth0 — the profile name, otherwise the nickname — and nothing else. It never shows an e-mail address, not even where your name at Auth0 is itself an e-mail address; the word “Member” is shown in its place. Whoever manages the members as an Owner sees the names of all members, every other member only their own. We do not store the names: when the list is opened, our API server asks Auth0 for them in a single request and keeps them in memory for at most one minute; if you delete your account, the entry is discarded at once. If Auth0 cannot be reached, every member is shown as “Member”. If you do not want the members of a collection to see your name, leave the collection. Legal basis: Article 6(1)(b) GDPR — the member list of a shared collection is the service you asked for.

A public collection can be reported. Its page carries the report control described in section 8.8, usable by anybody who can see the page. If an administrator upholds a report about it, the collection is set back to private; nothing in it is deleted and you can publish it again.

Legal basis: Article 6(1)(a) GDPR — you consent by choosing the setting, and withdraw it by changing the setting back.

8.2 Photos

Uploaded photos are shown to you and to those members of the collection whose role includes the private details — that is Owner and Editor under section 8.1a. If the copy is in a collection nobody else is in, only the person who uploaded the photo sees it. Photos do not appear on a collection's public page, and members with the Reader or Insurance role do not see them either. Photos are not published and not passed on to third parties, and are used to train models only with your consent under section 8.15; the pictures of one of your own creations (MOCs) that you publish or make unlisted yourself are described in section 8.11. For the automated check under section 8.12, a reduced copy of every photo is sent to Microsoft as processor; a photo refused in that check is not stored.

Metadata is removed. On upload every image is re-encoded: the orientation recorded in the image is baked into the image data and the entire metadata profile is then removed — EXIF, IPTC and XMP, and hence in particular GPS coordinates, the time the photo was taken and device identifiers. Only the cleaned image is stored; the file originally transmitted is not retained.

The original file name is not carried over. Every file is given a randomly generated identifier; nothing about the person who uploaded the file or about its origin can be derived from the storage path.

Resized versions. Smaller versions of a photo are generated on demand and cached for display. They contain the same image data — already stripped of metadata — are subject to the same access restrictions, and are deleted together with the photo.

Images in a format that cannot be re-encoded — HEIC/HEIF, the standard format of newer iPhones, among them — are refused rather than stored. The error message names the accepted formats (JPEG, PNG, WebP, GIF). Nothing is put into storage that was not cleaned first.

For each photo the following is stored: the random file identifier, a caption you assign yourself, the sort order and the time of upload.

Legal basis: Article 6(1)(b) GDPR.

8.3 Avatar picture

You may upload a picture as your avatar, or use one of the drawings BrickDb provides. The provided drawings are our own artwork and are not personal data; an uploaded picture is.

An uploaded avatar goes through exactly the same cleaning as any other photo: the orientation is baked into the image data and the entire metadata profile — EXIF, IPTC and XMP, and hence in particular GPS coordinates, the capture time and device identifiers — is removed. It is then cropped to its centre square, reduced to 256 by 256 pixels and re-encoded as WebP. Only that image is stored; the file you transmitted is not retained, and a picture that cannot be re-encoded is refused rather than stored. Before it is stored it is checked automatically under section 8.12; a picture refused in that check is not stored, and your previous avatar stays.

Who can see it. An avatar is stored so that it can be shown beside your name. Today only you see yours. Next to a MOC you publish or make unlisted, your display name appears (section 8.11), not your avatar. This section will say so explicitly at the point that changes: an avatar is intended to be visible to other users, which is the reason it is described separately from 8.2 above.

Only one avatar is stored per account; uploading another replaces it. It is included in the copy of your data under section 14, and it is deleted when you delete your account under section 14.

Legal basis: Article 6(1)(b) GDPR.

8.4 Event submissions

When you submit an event, we store its title, optional description, venue, country and schedule. For an all-day event, these are start and exclusive end dates. For a timed event, these are start and end instants and the venue time zone. We also store an optional registration opening, source URL, the link to your account and the submission time, together with the moderation state, the time of a moderation decision and an internal notification intent for the review queue. This intent does not send an email.

An administrator reviews submissions manually. Pending and rejected submissions are not public. After approval, the event details and source URL are publicly visible; your account identity is not published. Please include only event information you may publish, without personal contact details or private information about yourself or others. So that an event is described in English, German and the languages of its country, BrickDb has Azure OpenAI (section 8.6) write the languages your submission does not bring, from its title, dates, venue and country alone; your description, the organiser you entered and the link to your account are not sent, and every text written this way is reviewed by an administrator before it is published and marked as written with AI assistance.

Submission and moderation provide the service you request (Article 6(1)(b) GDPR). Maintaining the approved public calendar serves our and other visitors' legitimate interest in reliable event information (Article 6(1)(f) GDPR). You may object to processing based on legitimate interests using the contact details in section 2. Your Article 15 export on the account page includes your event submissions in every moderation state.

On account erasure, pending and rejected submissions and their notification intents are deleted. Approved events remain public with their submitter link anonymised: it is replaced by a fresh random identifier with no account or mapping back to you. The approved facts remain in the calendar so it continues to serve other visitors; there is no fixed expiry for that anonymised record. Backup deletion follows section 13. The other rights in section 14 remain available.

Flyers. If an event is submitted with a photo of its flyer, we store the flyer image as prepared for display, its size and the time it was uploaded, whether the automatic reading saw faces, phone numbers or e-mail addresses on it, as a pointer for the review, and the submitter's confirmation that the flyer was handed out publicly to promote the event and may be shared. A person reviews the flyer with the event and publishes it with the approved event only after confirming that it shows no identifiable private person beyond the organiser's published contact details; otherwise the event is approved without the flyer. A flyer that is not published is deleted 30 days after that decision. A published flyer is deleted when an administrator removes it or a report about it on copyright or personal-data grounds is upheld (section 8.8); the event stays listed. Storing and reviewing the flyer provide the service requested (Article 6(1)(b) GDPR); publishing it with the event serves the legitimate interest in complete event information (Article 6(1)(f) GDPR). Anyone shown on a flyer can object using the contact details in section 2 or report the flyer with “Report flyer” on the events page.

Photographing a flyer. With “Photograph a flyer” on the /events page you can suggest an event from a photo of its flyer, with or without an account. Your photo is sent to BrickDb’s servers (25 MB at most) and cleaned there: its metadata, including GPS coordinates, is removed, the flyer is cut out and straightened where its edges can be found, and it is re-encoded. Your original photo is not stored. To suggest the event’s details, BrickDb sends the cleaned flyer image from its own server to the Azure OpenAI service of Microsoft Ireland Operations Limited as processor (section 8.6); the processing takes place in Azure’s EU Data Zone, the request is made so that the service does not store it for later retrieval, and otherwise what section 8.6 says about Azure OpenAI applies, including the default abuse monitoring. The cleaned flyer image is kept as a draft so that you can check the suggested details and submit the event; if you do not submit it, the draft is deleted after one day, and if you submit the event without confirming that the flyer may be shared, the event is submitted without it and the draft is deleted. When it is submitted, the flyer is checked automatically under section 8.12. Without an account you confirm at each step, with the check under section 8.13, that you are a person; such a submission is linked to no account and names nobody, so there is neither a copy of it under section 14 nor a deletion with an account. The legal basis for cleaning and reading the flyer is Article 6(1)(b) GDPR: it provides the service you asked for.

8.5 Set-number photo reading

When you expressly submit a retail-box photo for set-number reading, BrickDb sends at most 8 MB from the browser to its own web and API servers. The API server passes the photo, unchanged, to a third server of our own, the reading service (the container app “brickdb-ocr”). It runs in the same Azure environment and the same region (Germany West Central, Frankfurt am Main) as the other servers described in section 4, can be reached only from within that environment, and has no access to the database or the file storage. Like the web and API servers, the reading service holds the image solely in memory; it returns to the API server only the possible set numbers read from it, and its log entry records only how the request ended (for example, read or refused) and how long it took, nothing about the photo. On none of the three servers is the image stored, logged or used to train models; it is not sent to a third party and is discarded when the request ends. We operate all three servers ourselves on Microsoft Azure; Microsoft acts as our processor as described in section 4. By way of exception, if you are signed in, a reduced copy of the photo is also sent to Azure OpenAI for a suggestion under section 8.6. Legal basis: Article 6(1)(b) GDPR — this processing provides the reading you requested.

To keep that compute-intensive service available, each server process permits six requests per originating IP address in a rolling minute. That limit is checked by both the web server and the API server, because the API server can also be reached directly. Each server process counts on its own, and several processes of each server may run at the same time, so this is a limit per process rather than one total across BrickDb. So that the API server counts your address rather than the web server's when a request comes through the web server, the web server passes your address to it along with the request; the reading service never receives it. On both servers the address — for IPv6 only its network part — is held only as a key in that server process's memory; it is never logged, persisted or disclosed to a third party. After one minute it no longer affects a decision and is removed when that address returns or request-driven cleanup needs room. Each server process holds at most 1,024 address keys; when all places are still active, a new address is refused instead of displacing one of them. Legal basis: Article 6(1)(f) GDPR. The legitimate interest is the technically secure, reliable and fair availability of the service.

8.6 Suggestions from a photo of a set or a minifigure

When you are signed in and submit a photo of a set to be read — in the set scanner’s photo mode (section 8.5), or with “Read the photo” and when you review a photo in the import of box photos — BrickDb suggests from the photo which set it shows and what condition it is in: sealed or opened, built or not, the condition of the visible box, of the instructions and of the stickers, and what the photo shows about completeness. For this, BrickDb sends a copy of the photo from its own API server to the Azure OpenAI service of Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland, as processor under Article 28 GDPR. Before that, the copy is re-encoded, stripped of all metadata, GPS coordinates included, and reduced to at most 1,024 pixels on its longer side; only the image is sent — no file name, no account identifier and nothing from your collection. The connection is made by the server, not by your browser; opening a page never triggers it. Without signing in, no photo is sent to Azure OpenAI.

The same applies when you are signed in and submit a photo of a minifigure on the “Identify a minifigure” page: BrickDb first compares the same downscaled copy, stripped of all its metadata, on a server of our own, the minifigure matching service (the container app “brickdb-minifig-match”), with our index of the catalogue’s pictures of minifigure torsos. It runs in the same Azure environment and the same region (Germany West Central, Frankfurt am Main) as the other servers described in section 4, and so in the EU, can be reached only from within that environment, holds the image solely in memory and returns to the API server only the most similar torsos from the catalogue; there the image is not stored, logged or used to train models, and it is not passed to third parties. Only if this comparison finds no confident match does BrickDb send the copy to Azure OpenAI to recognise which minifigure the photo shows. To compare each part with the recognised minifigure, find missing accessories and assess its condition, BrickDb always sends the copy — together with that minifigure’s parts list from our catalogue — to Azure OpenAI. At most two requests are made per photo, and each counts as one photo read towards the daily limits below. Only the image and the catalogue’s parts list are sent — nothing about you. What is said below about the result applies accordingly: it is a suggestion, a recognised minifigure is shown only when it is in our catalogue, and none of it is stored. If you start the live camera there instead, a recognition model on your own device looks for the figure in the camera picture. Once you have held the figure still for about a second, a crop of the camera picture around the figure is submitted automatically, without you choosing a photo — at most once per figure, until it is taken out of view or replaced by another; before that, no picture leaves your device. Otherwise this crop is processed exactly like a submitted photo.

Processing takes place in Azure's EU Data Zone, that is within the EU; the deployment is placed in the Germany West Central region and processing may occur in any EU member state. According to Microsoft, inputs and outputs are not used to train the models and are not made available to the model vendors. Default abuse monitoring: Microsoft screens inputs automatically for abusive use. An input flagged by that screening may be retained by Microsoft as a sample and reviewed by authorised Microsoft employees in the EEA; Microsoft states no fixed maximum retention period for it. Beyond that the service does not keep the photo.

BrickDb does not store the copy sent or the result, does not log either, and neither is used to train models; the request is made so that Azure OpenAI does not store it for later retrieval. The result is a suggestion: each detail says how sure the model says it is — there is no measured accuracy. A suggested set number is shown only when it is in our catalogue, and a set number our reading service (section 8.5) read always comes first. The suggestion only fills in the form; nothing is saved until you have checked it and confirmed it with the form’s add button, exactly like an entry made by hand. Please photograph only the set and its packaging: no people, addresses or other personal details, and only images you are entitled to submit.

To keep the cost bounded, BrickDb reads at most 50 photos per account and at most 1,000 in total per day (UTC); for this we store with your account only the number of photos read that day and the day. It is overwritten on the next day and deleted with your account. Legal basis: Article 6(1)(b) GDPR — the suggestion is part of the reading you request; for the count, Article 6(1)(f) GDPR, our legitimate interest in bounding the cost of the service.

8.7 Support requests

There is a support form on the support page, and you can use it without an account and without signing in. It asks for an e-mail address for the reply, a subject and your message; a name is optional. The language is not asked for — it is taken from the language the page was displayed in, so that the reply comes in the language you asked in. Writing to us at the address in section 2 instead reaches us just as well, but does not create a ticket; that message is simply an e-mail in our mailbox.

What you send is stored as a ticket with a ticket number: the e-mail address for the reply, the optional name, the language you wrote in, the subject, the text of your request, its state, how it reached us, and the times it arrived and was closed. If you object to an automatic check (section 8.12) from the account page, we also store which check you object to: a reference to the decision, the kind of content, the outcome and the category, a checksum of the content that was checked, and later our decision on the objection. Through that reference the checked content can be found for as long as it is stored. We store these details only when you are signed in and the checked content is yours; any other request is stored without them, as an ordinary request.

No ticket is linked to a user account in this version — not even one you send while signed in. The route that receives the form is open to everyone and establishes no sign-in at all, so the field intended for that link stays empty. What follows from that for your rights is in the erasure paragraph below. A ticket also has a field for an access key to a status page, and no such key is issued in this version either, so that field stays empty too. Were one issued, only its checksum would be stored, never the key itself.

Somebody is told straight away. A request you file is announced to our own mailbox by e-mail, so that it cannot sit unseen. That notification carries the ticket number, the address and the name you gave, your subject and the full text of your message. It is sent through the mail provider named in section 7.3, so those details are processed in the United States on the basis described there. Unlike the account mail in that section, it carries no invisible image and no redirected links. What you see yourself is your ticket number, on the page, once the form has been sent; our answer to you is a separate mail, under "How we answer" below.

Protection against mass submissions. So that the form cannot be used to flood us, BrickDb permits five submissions per originating internet connection in a rolling quarter of an hour. For that it holds a shortened form of your IP address as a key in one web process's memory — for IPv6 the network part alone, for IPv4 the address. It is never logged, never written into the ticket, never stored in the database and never disclosed, and it stops affecting any decision once the quarter of an hour has passed. At most 1,024 such keys are held; when every place is still in use, a new one is refused rather than displacing an existing one. There is no captcha, and nothing is fetched from any third party for this. Legal basis: Article 6(1)(f) GDPR. The legitimate interest is the technically sound, secure and fair availability of the service.

Legal basis: handling and answering your request (Article 6(1)(b) GDPR where it concerns your use of the service, otherwise Article 6(1)(f) GDPR — our legitimate interest in being able to answer questions about this service). You may object to processing based on legitimate interests using the contact details in section 2.

Storage period: a closed ticket is deleted 24 months after it is closed. The period runs from closure and not from arrival — a ticket you are still waiting on is not deleted, however old it is. Deletion happens as part of routine housekeeping and may therefore fall a few days after the period ends, never before it. Section 13 applies to backup copies.

On account erasure under Article 17 GDPR, deleting your account on the account page anonymises every ticket that is linked to your account: the e-mail address, the name and that link are removed and the access key stops working, while the ticket itself is anonymised rather than deleted, because the subject, the text and our replies are our own record of a conversation we were party to as well. Since no ticket carries such a link in this version, that step reaches nothing in practice: a support request is in neither the Article 15 export nor the account erasure on the account page, whether or not you were signed in when you sent it. The export's own list of what it does not contain names support requests for that reason.

Your rights under section 14 are unaffected, and this is how to exercise them for a ticket: write to us using the contact details in section 2 and quote the ticket number or the address you used. One thing to know when you do — removing fields does not anonymise free text. If you wrote your own name, an order number or other details about yourself into the request itself, those are still in the text. Tell us if that is the case and we will redact or delete that ticket by hand.

Internal notes: while a ticket is being worked on we also write notes to ourselves about it — what was tried, what we found, which state we moved the ticket to and who did so. Those notes are ours rather than yours: they are held against the person who wrote them, they never form part of a reply to you, and they are therefore neither in your Article 15 export nor anonymised when you erase your account. They are deleted together with the ticket, on the same period. If you want to know whether a note names you, write to us using the contact details in section 2 and quote the ticket number.

How we answer: we reply by e-mail to the address you gave us, in the language your request was written in. That reply quotes your own subject and message back to you so that you can place it, because filing a request sends you no copy of it. Our reply contains no link and no tracking — nothing in it is fetched from anywhere, and opening it tells us nothing. If something is still open, simply reply to that e-mail and leave the ticket number in the subject.

Translation: so that we can understand your request and answer you in your own language even when we do not speak it, BrickDb sends the subject and text of your request, any mail you send us about it afterwards, and the text of our answers from its API server to the Azure OpenAI service of Microsoft Ireland Operations Limited as a processor (section 8.6). The service recognises the language you wrote in and translates the text into the language of the person handling the request; you then receive our answer in your language and, if that is not English, also in English beneath it, clearly marked. Before anything is sent, we cut off quoted earlier messages and remove e-mail addresses, ticket numbers and the name you gave us from the text; in our answers they are replaced by placeholders and put back only after the translation. Any other personal data you write in the text yourself is sent with it. Processing takes place in Azure's EU Data Zone, the requests are made so that the service does not store the input and the answer for later retrieval, and everything else section 8.6 says about Azure OpenAI applies. We store the recognised language, the translations and the translated preview of an answer with the request, beside your original text and never in its place; they are deleted with the request at the same time, and an account erasure treats them like the text they were made from. The legal basis is the same as for handling the request above.

Mail to the support address: mail sent to support@brickdb.net — including a reply to one of our answers, which asks to be sent there — is turned into a ticket. Our mail provider (section 7.3) receives it on our behalf for the subdomain support.brickdb.net and hands it to BrickDb, so it is processed in the United States on the basis described there. A mail whose subject carries the number of an open ticket, which comes from that ticket's own address, and whose sender's domain signed or authorised it (DKIM or SPF, as checked on receipt) is added to that ticket; any other mail opens a new one, and the ticket records whether its sender could be verified that way. We store the sender's address and name, the subject, the language the mail declares and its text — never its attachments: an attachment is not stored anywhere, and the ticket only notes how many there were. A mail our spam check classes as spam, that comes from one of our own addresses, or that arrives after five mails from the same sender (or sixty from everybody) have already been accepted in the past hour, does not become a ticket; so that a real request caught that way can still be found and answered, we keep a short record of it — when it arrived, why it was refused, the sender's address and the subject, never the text — for 30 days. The legal basis, the storage period and your rights are otherwise those of the form above.

State of this version: the support request form on /support is in service, and so is the reply by e-mail described above. You can still reach us using the contact details in section 2 and in the imprint instead, which is what to do if the form refuses your request for any reason.

8.8 Reports about content

Every event on the events page carries a report control, and so does the page of every published collection (section 8.1a) and of every published or unlisted MOC (section 8.11), and to every photo mosaic shared by link (section 8.14), to every brick-built QR code shared by link (section 8.17), to every brick text sign shared by link (section 8.24) and to every approved photo of a store (section 8.19). You can use it without an account and without signing in — what a report is about is content that a signed-out visitor can see, so a wall in front of it would exclude exactly the person it exists for. The sheet asks for a reason from a fixed list, an optional description of what is wrong, your name if you want to give it, an optional e-mail address, and an optional statement that you believe in good faith that the report is accurate and complete. Only one reason — „something else“ — requires the description, because a report whose entire content is that word has to be read before it can be sorted. The language is not asked for — it is taken from the language the page was displayed in.

What you send is stored as a report with a reference of its own, which looks like BDR-000042: which kind of content it is about and that content's own key, the reason you picked, your description if you wrote one, the e-mail address if you gave one, your name if you gave it, whether you made the good-faith statement, the language you wrote in, the state the report is in, and the times it arrived and was decided. A description may be at most 2,000 characters, an address at most 254 and a name at most 100; anything longer is refused naming the field rather than written short.

No report is linked to a user account — not even one you file while signed in. The route that receives the form is open to everyone and establishes no sign-in at all, and there is no field for such a link: BrickDb deliberately does not know which report was yours. What follows from that for your rights is in the export and erasure paragraph below. There is also no status page for a report and no access key to one, so nothing of that kind is stored either.

Somebody is told straight away. A report you file is announced to our own mailbox by e-mail, so that it cannot sit unseen. That notification carries the reference, the kind of content, the reason, the key of the reported content and the full text of your description. It carries no address of yours: the message goes to us, and your address stays in the queue where only an administrator can see it. It is sent through the mail provider named in section 7.3, so those details are processed in the United States on the basis described there, and like the support notification it carries no invisible image and no redirected links. What you see yourself is the reference, on the page, once the form has been sent.

Protection against mass submissions. So that the control cannot be used to flood us, BrickDb permits four reports per originating internet connection in a rolling ten minutes. For that it holds a shortened form of your IP address as a key in one web process's memory — for IPv6 the network part alone, for IPv4 the address. It is never logged, never written into the report, never stored in the database and never disclosed, and it stops affecting any decision once the ten minutes have passed. At most 1,024 such keys are held; when every place is still in use, a new one is refused rather than displacing an existing one. There is no captcha, and nothing is fetched from any third party for this. Legal basis: Article 6(1)(f) GDPR. The legitimate interest is the technically sound, secure and fair availability of the service.

Who reads a report, and what deciding one does. A report goes into a queue at /admin/reports that only an administrator can open; there is no page on which anybody else can look a report up, not even by its reference. An administrator either dismisses it or upholds it, and upholding it takes the reported content down: an event a report is upheld against leaves the public calendar. A published collection a report is upheld against is set back to private: from then on only its members see it, nothing in it is deleted, and its owner can publish it again — a collection published again can be reported again. We act on the content, not on the person who posted it.

A decision about something a person published is also recorded against them. When an administrator upholds or dismisses a report about a collection, or about an event a member submitted, the decision is recorded in the audit log described in section 8.9, against the account of the person who published it: which report it was, the kind of content and its key, and how the report's state moved. The reporter is not named in that entry, and the moderator's notes are not part of that entry either.

Legal basis: Article 6(1)(f) GDPR. The legitimate interest is keeping the content BrickDb publishes free of unlawful and objectionable material, being able to receive an objection at all from somebody who has no account, and being able to show afterwards how a complaint was handled. Where a report concerns content we are obliged to act on, handling it also serves compliance with a legal obligation (Article 6(1)(c) GDPR). You may object to processing based on legitimate interests using the contact details in section 2.

When a report is upheld, the person who published the content is sent a statement of reasons by e-mail. That applies to a published collection and to an event a member submitted; for an event we took over from somebody else's calendar there is nobody we could write to. The message gives the report's reference, which content it concerns (its kind and its title or name), what we did and for how long, the reason the report was filed under and the section of our Terms of Use we decided under, whether automated means were used, and how you can object — by replying to the e-mail or through the support form, quoting the reference. It does not say who filed the report, and it contains neither the report's description nor the moderator's notes.

To send it, we ask Auth0 at the moment of the decision for your e-mail address and the language recorded with your account (section 7.1). The address is only used for this and is not stored by us; on the report we record only whether the statement could be sent and when — or why not, for instance because no address is on record. It is sent through the mail provider named in section 7.3, so those details are processed in the United States on the basis described there, and it carries no invisible image and no redirected links. Somebody whose collection is set back to private also sees the changed setting on their collections page. Legal basis: Article 6(1)(c) GDPR in conjunction with Article 17 of Regulation (EU) 2022/2065 (the Digital Services Act), to the extent that we are obliged to give such a statement, and otherwise Article 6(1)(f) GDPR — the legitimate interest is telling you what happened to your content and why, and giving you a way to object to the decision.

Storage period: a decided report is deleted 24 months after it is decided. The period runs from the decision and not from the filing — a report nobody has decided yet is not deleted, however old it is, because it is an objection still owed an answer. Deletion happens as part of routine housekeeping and may therefore fall a few days after the period ends, never before it. Section 13 applies to backup copies.

Neither the Article 15 export nor the account erasure reaches a report, and that is a limit rather than a choice. Because no report is recorded against an account, there is no way to ask which reports a given person filed — so a report is in neither the Article 15 export nor the account erasure on the account page, whether or not you were signed in when you filed it, and deleting your account does not delete one. The same is true if somebody reported something you posted: that report names the content, never your account, so it is not in your export either — the decision about it is, once an administrator has upheld or dismissed it, as an audit log entry under section 8.9. The export's own list of what it does not contain names both cases for exactly this reason. What you can actually do is write to us using the contact details in section 2 and quote the reference: with it we can find the report by hand, tell you what it holds, correct it, or remove the address and the text you wrote.

Removing fields does not anonymise free text. If you wrote your own name, an address or other details about yourself into the description, those are still in the text. Tell us if that is the case and we will redact or delete that report by hand.

Internal notes: while a report is being worked on we also write notes to ourselves about it — what we found, which state we moved it to and who did so. Those notes are ours rather than yours: they are held against the person who wrote them, they are never sent to you or to the person whose content was reported, and they are therefore neither in your Article 15 export nor reachable by an account erasure. They are deleted together with the report, on the same period. If you want to know whether a note names you, write to us using the contact details in section 2.

We confirm that it arrived and tell you the decision. If you gave an e-mail address, we send you a confirmation of receipt with the reference and, once the report is decided, the decision and how to object to it — each in the language you filed the report in, as Article 16(4) and (5) of Regulation (EU) 2022/2065 require. Both messages name the reference, the kind of content and the reason you picked, but neither its title nor your description; they are sent through the mail provider named in section 7.3 and contain no invisible image and no redirected links. Beyond that, filing a report starts no correspondence; a person may also use the address to come back to you if the report cannot be acted on without asking you something, and it is used for nothing else. The legal basis is Article 6(1)(c) GDPR in conjunction with Article 16(4) and (5) of Regulation (EU) 2022/2065. What you get in any case is the reference, on the page, straight away.

State of this version: the report control on /events and on every published collection's page is in service, and so is the queue behind it. If it refuses your report for any reason, the contact details in section 2 and in the imprint reach us just as well — a message sent that way is simply an e-mail in our mailbox and creates no report.

8.9 Administration of user accounts

BrickDb's administrators can look after user accounts in an area at /admin/users that only an administrator can open: see the list of accounts, look at one account, change its name, e-mail address, profile or roles, send a password reset, send the e-mail confirmation again, mark an e-mail address as confirmed, block or unblock it, or delete it through the same erasure described in section 14. The account details shown there are read live from Auth0 (sections 7.1 and 7.2) and are not copied into BrickDb's database. The same is true of an account's sign-in history: it is read from Auth0 when an administrator opens it and is kept only for as long as Auth0 itself keeps it.

What an administrator sees about one account. The account's page shows what Auth0 holds about it — its identifier, e-mail address and whether it is confirmed, the sign-in methods linked to it, when it was created, last changed and last signed in, how many times it has signed in, whether it is blocked, which types of multi-factor authentication are set up (the type only, never a secret or a phone number) and its roles — and the profile you filled in (names, country, the text about yourself, the avatar you chose and the language of your e-mails, but not your postal address). From BrickDb's own database it shows counts only: how many collections you own and have joined, how many copies you added, how many bag codes, set barcodes and events you contributed, how many of your support requests are open and how many content reports were filed with your e-mail address — never their content.

The sign-in history shows, for each event Auth0 recorded for the account, when it happened, what it was (a sign-in or a failed one, a sign-up, a sign-out, a password or e-mail change, an e-mail confirmation, a multi-factor step, an attempt Auth0 blocked, or a password found in a data breach), which sign-in method and which BrickDb application it went through, the country and city Auth0 derived from the IP address, and the browser and operating system with their major version. The IP address itself is not shown, and neither is the free-text description Auth0 attaches to an event. Administrators look at it to keep accounts secure — to recognise sign-ins that were not yours, or an attack on your password — and to help you when you ask us about your account.

No administrator ever sees, chooses or types a password. An account an administrator creates is given a random password nobody sees, and you receive an invitation mail from BrickDb (sent as described in section 7.3) with a one-use link, valid for seven days, to choose your own password. A password reset is Auth0's own mail with the same kind of link. Neither the password nor the link is stored or logged by BrickDb.

Every administrator action is recorded in an audit log, before the action runs, so that one that fails is recorded too: when it happened, which administrator took it, what it was, which account it concerned (its Auth0 identifier, and the e-mail address and name it had at that moment), the reason the administrator gave, which fields it changed with their values before and after, and whether it succeeded. It never records a password, a reset link or a token. Only an administrator can read the log, at /admin/audit, and it has no function that changes or deletes an entry.

Legal basis: Article 6(1)(f) GDPR. The legitimate interest is keeping accounts and the service secure, helping a person whose account needs it, and being able to show afterwards what was done to an account, by whom and why — the accountability Article 5(2) GDPR asks of us. That applies to the administrator's data in the log as much as to the account holder's. You may object using the contact details in section 2.

Storage period: an audit entry is deleted 24 months after the action, as part of routine housekeeping, so possibly a few days later and never earlier. Section 13 applies to backup copies.

If you delete your account, the entries about it are kept, but no longer name you. The account identifier is replaced by a random pseudonym, and the e-mail address, the name and every changed value are removed; which administrator acted, what they did and when stays, because that is what the record is for. The reason an administrator wrote is kept too, and may mention you in its text — tell us if it does and we will redact it. If you are an administrator and delete your own account, the entries for actions you took are kept unchanged.

An administrator deletes an account only through that same erasure (section 14), step for step, and only after typing the account's e-mail address and giving a reason, which the audit log keeps. We do that, for example, when you ask us to delete an account you can no longer sign in to. If you want a copy of your data first, download your Article 15 export from the account page before you ask — afterwards there is nothing left to export. An administrator cannot delete their own account this way; they use the account page like everybody else.

An administrator may also download your Article 15 export for you — for example when you ask us to send it because you cannot sign in. It is the same archive the account page gives you, built the same way, and an administrator can only download it after giving a reason. Every download is recorded in the audit log like any other administrator action: who downloaded it, when, and why. The archive is handed straight to the administrator's browser; BrickDb keeps no copy of it and does not write it to any log.

Your Article 15 export on the account page contains the entries about your account (under „adminAuditEntries“) — when, what, the reason and what changed — but not which administrator it was, because that is the administrator's data rather than yours. Write to us using the contact details in section 2 if you want to know.

State of this version: the user list with its search, the page of an individual account, its sign-in history, every action listed above and the audit log are in service.

8.10 Importing a collection from Rebrickable

At your express request, BrickDb can take the list of sets you keep as your collection on Rebrickable into your BrickDb collection, once. To do so, you enter the user name or e-mail address and the password of your Rebrickable account. BrickDb transmits both one single time, over an encrypted connection, from its server to Rebrickable and receives in return an access key (“token”), with which it retrieves the list of your sets immediately afterwards.

BrickDb stores neither the password nor the user name nor the token. All three exist only in memory for the duration of that one operation and are discarded afterwards — on success just as on an error or a cancellation. They appear in no log and in no error report. Only the imported sets are stored, as ordinary collection entries under section 8.1; they carry a note that they were imported from Rebrickable. To prevent abuse, we count how often an import has been attempted per account and per IP address; that count is held in memory only and expires after one hour.

Recipient: Rebrickable (rebrickable.com) receives the credentials of your account there — data Rebrickable already holds about you — from BrickDb's server. Rebrickable does not receive your IP address or your BrickDb identifier. Rebrickable processes the sign-in under its own responsibility and under its own terms.

Legal basis: Article 6(1)(b) GDPR — the import is a service you expressly request.

Transfer to a third country: to the best of our knowledge, Rebrickable is operated from Australia, a country for which there is no adequacy decision of the European Commission. The transfer takes place only if you have expressly consented to it before the import, after being told of the possible risks (Article 49(1)(a) GDPR), and because you initiate it yourself and it is necessary for the import you asked for (Article 49(1)(b) GDPR). Without that consent the server sends nothing to Rebrickable. The risk: the EU has not found that Australia offers protection equivalent to the GDPR, and there is no contract with Rebrickable that adds it, so it is not ensured that you can enforce your rights there or that authorities will not access the data. The consent applies to a single import and is asked for again each time.

Rebrickable has not expressly confirmed this use of its interface to BrickDb; this is not an official Rebrickable integration. If you would rather not enter your password, you can still add sets one at a time through the search or by scanning.

8.11 Your own creations (MOCs)

What is stored. For each MOC we store what you enter - name, description, the language of the text, tags, dimensions, parts list and pictures - plus the visibility you chose, the instants of the first and the last publication, the review status and the link to your account. At the first publication of a MOC we record which version of the terms you accepted, when, and when you confirmed your age under section 4.6.5 of the terms. The display name you confirmed is stored with the MOC as a copy of your profile name, so that it can be shown beside it; it is deleted with the MOC. A MOC made unlisted also receives a random, unguessable token that is part of its link; we store it with the MOC while it is unlisted and discard it as soon as you take the MOC back or publish it.

Pictures. Pictures go through the same clean-up as every photo under section 8.2; in particular GPS coordinates, capture time and device identifiers are removed. We accept pictures only as a file from your device, never from a web address.

Who sees them. A private MOC is seen by you alone. An unlisted MOC is seen by whoever has its link; it is in no overview, not offered to search engines for indexing, and its address is not sent to analytics services. A published MOC is seen by anybody, without an account; it may be indexed by search engines and shown in their results. For both we show the display name from your profile (section 7.2: your first and last name, as far as you entered them there) and nothing else about you - no e-mail address and no avatar. When a link to a published MOC is shared in a social network or messenger, that service fetches the title and preview image from us; that is a request made by that service, not a disclosure by us.

“Like”, saving, “I built this” and your builder page. When you are signed in you can mark a published MOC with “Like” and save it for later, and you can mark a published MOC or your own with “I built this”. For that we store which account marked which MOC, and for “I built this” also when. Of the likes we show everyone only the number beside the MOC, never who gave them; your saved and your built MOCs are seen by you alone. The parts of a MOC you marked as built count as your parts in your collection - for another person's MOC only while it is published. The builder page is voluntary and off until you switch it on; its address /mocs/by/… contains a random token formed neither from your name nor from your account identifier. It shows the display name you confirmed at your most recent publication and your published MOCs, nothing else about you, and search engines are asked not to index it. The legal basis here too is Art. 6(1)(b) GDPR. A mark lapses when you take it back or the MOC is deleted; all of it is in the copy of your data under section 14 and is deleted with your account.

Building instructions. You can add building instructions to a MOC: a PDF file, step pictures, a 3D model file (LDraw or Studio) and links to instructions elsewhere. Step pictures are pictures and go through the same clean-up as the pictures above (section 8.2). PDF and 3D files are stored in a storage of their own, apart from the photos, under a random name; we do not store the file name your device gives, only the title you enter yourself. A PDF file is first checked for active content (scripts, embedded files, password protection) and refused if it has any. It is then opened by the PDF check (section 11), which removes the metadata such as author, creator and dates and saves the file afresh; what is stored is the version saved afresh. We do not check what is inside the pictures embedded in a PDF file. We do not rewrite 3D files: a name that is in the file (such as an author line in LDraw or the design name in a Studio file) stays as you saved it and is visible to anybody who can download the file. A link is stored only as an address; we do not fetch it. Building instructions follow the MOC: for a private MOC only you see them, for an unlisted one whoever has the link, and for a published one anybody, without an account. The files are included in the copy of your data under section 14 and are deleted with the MOC or with your account.

Review and reports. A person reviews an account's first MOC before it is shown; until then only you see it. You can report a MOC, one of its pictures or one of its instructions, without an account too, through the report control on its page (section 8.8). A picture or file removed because a report was upheld is kept for six months so that it can be restored after a successful objection, and is deleted afterwards. When a report about a MOC is upheld, we record which account it counts against; that is what the restriction in section 7 of the terms of use is worked out from, and the record is deleted with the report.

Legal basis: Art. 6(1)(b) GDPR - storing and showing is the service you ask for by adding the MOC and choosing its visibility.

Retention. Until you delete the MOC or your account; backups follow section 13. Your MOCs are in the copy of your data under section 14, including private ones.

8.12 Automated checking of content

So that BrickDb neither stores nor shows unlawful or harmful content, BrickDb checks texts and pictures you add automatically, using the Azure AI Content Safety service of Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland, as processor under Article 28 GDPR on the basis of the Microsoft Products and Services Data Protection Addendum. The service rates how strongly a text or a picture shows sexual, hateful, violent or self-harm content; texts are additionally compared with a list of blocked terms that we maintain ourselves. The connection is made by BrickDb's server, not by your browser. The following are checked:

• a MOC's name, tags and description, your display name with it, and the titles and links of its instructions, when you publish it or make it unlisted and on every change while it is not private (section 8.11);
• a MOC's pictures and step pictures when they are uploaded;
• a collection's name and description when you publish it, and on every change while it is published (section 8.1a);
• an event suggestion's title, description, venue and link, and the image of its flyer, when it is submitted (section 8.4);
• your display name when you change it in your profile, because it appears beside your MOCs (section 7.2);
• the picture drawn from a photo mosaic when you share the mosaic by link (section 8.14) — never the photo it was made from;
• the text a brick-built QR code contains when you share it by link (section 8.17) — as a camera reads it from the saved studs; a QR code you do not share is not checked;
• the text of a brick text sign when you share it by link (section 8.24); a sign you do not share is not checked;
• the first name, initial and town of an advent calendar winner who agrees to be named (section 8.23);
• the name, maker, colour and size of a merchandise contribution when you submit it, and the photo you attach to it (section 8.16);
• the name, address, contact details, website and description of a store when you add it to the store finder or suggest an edit to it (section 8.19);
• a photo of a store you add (section 8.19);
• photos of your copies, photos from the import of box photos and your avatar picture when they are uploaded (sections 8.2 and 8.3) - that is, pictures nobody but you, or only members of your collections, can see as well.

What is sent. For a text, the text itself. For a picture, not the uploaded file but a reduced copy of the already cleaned picture (without GPS coordinates and other metadata, section 8.2), at most 960 pixels on its longest side; for an avatar, the stored 256 × 256 pixel picture. The copy is not stored by BrickDb. Your account identifier, your e-mail address and your IP address are not sent; your name only where it is itself part of the text checked, as your display name. Not checked are reports (section 8.8), support requests (section 8.7), notes and other private details of your collection, PDF and 3D files of instructions, and photos that are not stored (sections 8.5 and 8.6).

Where the check runs. Unlike what section 4 says for everything else, this check runs in the Azure region France Central (Paris, France), because Microsoft does not offer the service in Germany West Central; the data therefore stays in the EU. According to Microsoft, texts and pictures are not stored in the process, not used to train the models, not seen by Microsoft staff and not transferred to other regions; Microsoft stores the list of blocked terms in the same region. For access from third countries, what section 4 says under "Transfer to third countries" applies.

What the result does. If a picture or a text reaches a severity we have set as severe, it is refused when it is uploaded or saved and is not stored, and you are told at once. If the check flags content below that threshold, or cannot check it because the service cannot be reached or the monthly checking allowance has been used up, it is stored but shown to nobody except you and the administrators until a further check or a person clears it (section 4.7 of the Terms of Use). A refusal is an automated decision: it is made by the service alone, under the thresholds we have set. We do not consider it a decision with legal effect or a similarly significant effect within the meaning of Article 22 GDPR, because all it prevents is a single piece of content being stored; you can nevertheless ask at any time through the support form for a person to review it, put your point of view and contest it.

When a private photo is held. If the check flags a photo of one of your copies - including one from the import of box photos - and holds it for that reason, a person from the administration may look at it to decide whether to release it. A photo held only because the check could not run is not looked at; it waits for the next automatic check. The photo is loaded only when that person expressly opens it, and is not cached. Every look is recorded in the audit log under section 8.9: who looked at it, when, which photo it was and which account it belongs to. If it is released, it is shown again as before. If it breaches section 4.3 or 5 of the Terms of Use, that person may delete it; you then receive a statement of reasons by e-mail and can object as it describes.

Notifying the administration by e-mail. When something waits for a decision by the administration - a support request or an objection to an automatic check (section 8.7), a report (section 8.8), an event proposal (section 8.4), content held under this section or a proposal for the catalogue - every account with the administrator role receives an e-mail about it; whatever arrives within about ten minutes goes into one shared e-mail. It contains what the decision needs - for example the name and e-mail address of the person who made a request, their message and the result of the automatic check - and, of images that matter, a reduced copy attached to the e-mail, including private photos of your copies and photos from the import of box photos. It is sent through the e-mail service provider under section 7.3; it then lies in the mailbox of the respective person from the administration, who uses it only to handle the matter and deletes it once it is no longer needed. Decisions are made only after signing in to BrickDb. The legal basis is Art. 6(1)(f) GDPR; the legitimate interest is handling requests, reports and held content promptly.

What we store. For every check we store which content was checked (its kind and its key) and which account it belongs to, the result and, where it could not be checked, why, the rating per category, the numbers of any blocked-term entries matched (not the terms), the version of the service and of our thresholds, a check value (hash) of the content so that unchanged content is not sent again, the units billed and the time - not the text or the picture itself. We also count, per account, how many pictures and text units were checked in the current month; the count starts again each month. A check result is deleted when the content checked is deleted, and at the latest with your account; where content outlives the deletion of your account - a collection another member carries on, or an approved event (section 8.4) - its check result is kept without any link to you. Check results and the count are included in the copy of your data under section 14; for backups, section 13 applies.

Legal basis: Article 6(1)(f) GDPR. The legitimate interest is to keep the content BrickDb stores and shows to others free of unlawful and harmful material - to protect visitors, children among them, and as part of the diligence a provider of hosting services exercises under Regulation (EU) 2022/2065 (Digital Services Act) - and, for private photos, also neither to store such content on our systems nor to deliver it to the members of a shared collection. You may object to processing based on legitimate interests using the contact details in section 2.

Status of this version: The check can be switched on and off centrally. While it is switched off, nothing is sent to Microsoft and content is shown without it; we then only record that content was not checked, and catch up on the check once it is switched on.

8.13 Protecting the forms against spam (Cloudflare Turnstile)

The support form at /support, the form with which you report content on the page that shows it — an event or its flyer on the /events page, a published collection, a MOC, a shared mosaic, a shared QR code, a shared brick text sign or a photo of a store — and “Photograph a flyer” on /events (section 8.4) can be used by anyone, without an account. So that they are not misused automatically and in bulk, BrickDb uses the Turnstile service of Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA, to check before sending that the form is being filled in by a person. For this, your browser loads a script from Cloudflare and shows a small check field — only on the pages that carry one of these forms, and on them only once you open a report form or “Photograph a flyer” (on /support when the page opens), and on no other page. Mostly the check runs without anything for you to do; occasionally it asks you to tick a box. Its result is a single-use token sent with the form; BrickDb's server asks Cloudflare whether it is valid, and only then stores or sends the form. With “Photograph a flyer”, the check is asked for once before the flyer is read and once before it is submitted, and only if you are not signed in. In the BrickDb app the report form is offered only when you are signed in, and no check by Cloudflare is made there: your account takes its place, and the report is stored without any link to your account.

What is processed. When the check loads, Cloudflare receives from your browser your IP address, your browser's identifier (user agent), characteristics of the encrypted connection (TLS fingerprint), the site key and the address of the page, as well as characteristics of your browser and device and of your interaction with the check field, which the script reads in your browser. On a page you opened through a shared link — a shared MOC, a shared mosaic, a shared QR code or a shared brick text sign — the address of the page contains that link, so Cloudflare receives the link as well if you open the report form there. BrickDb's server sends Cloudflare only the token — not your IP address and nothing you wrote in the form; the content of the form never reaches Cloudflare. BrickDb stores neither the token nor the result of the check, and stores nothing on your device for it; what the check itself keeps within its Cloudflare frame is decided by Cloudflare.

Legal basis: Article 6(1)(f) GDPR. The legitimate interest is to protect the forms that can be reached without an account, and the people who read and answer them, against automated spam and abuse. The access to information on your device that the check requires is permitted without consent under section 25(2) no. 2 TDDDG, because it is strictly necessary for us to provide the service you have expressly requested: sending the form. You may object to the processing using the contact details in section 2; without the check the form cannot be sent, but you can always reach us by e-mail.

Recipient and transfer to third countries: The recipient is Cloudflare, Inc.; the data may be transferred to the United States in the process. Cloudflare is certified under the EU-US Data Privacy Framework, for which an adequacy decision of the EU Commission under Article 45 GDPR exists. According to Cloudflare's statements on Turnstile, the data is used only to detect and fend off bots and to improve that detection.

Cloudflare's role and retention: According to Cloudflare's privacy notice on Turnstile (as of 18 June 2025), Cloudflare is a processor for the data it processes to provide the check to us ("a data processor of Signals that we process to provide the Turnstile service to our customers"), and itself a controller where it uses the same data to improve its bot detection ("a data controller of Signals that we process to improve Turnstile's bot detection capabilities"). Cloudflare states no retention period in that notice; for its processing as a controller, Cloudflare's privacy policy applies. BrickDb stores nothing for the check.

8.14 Photo mosaic

When you choose a photo in the photo mosaic at /mosaic, it is not uploaded and not stored. Your device opens the photo itself and shrinks the chosen part of it to one pixel per stud, 96 × 96 pixels at most. Only this shrunk version leaves your browser on the website: it goes over the existing connection to our web server under section 4, which chooses the brick colours from it and draws the preview. The web server holds it only in memory while the page is open and discards it afterwards; it is not stored, not logged, not passed to any third party and not used to train models. In the app, the colours are chosen on your device too; there, nothing of the photo leaves the device. You do not need an account for the photo mosaic. Legal basis: Article 6(1)(b) GDPR — the processing provides the mosaic preview you asked for.

Saving and sharing by link. When you are signed in, you can save a mosaic to your account. What is saved is the name you give it, the plates and the element you chose, the colours used, the colour of every stud and when it was saved and shared — never the photo. Only you see a saved mosaic until you share it. When you share it, we create a random link that cannot be guessed; whoever has it sees the mosaic with its parts list and building instructions, but neither your name nor the name you gave the mosaic. Before the link shows anything, the picture drawn from the mosaic is checked automatically under section 8.12: if the check holds it back, the link shows nothing until a person has looked at it; if it refuses it, nothing is shared. Anybody with the link can report the mosaic under section 8.8; if the report is upheld, we take the link down. A shared link is not taken up by search engines, not passed to any audience measurement service and not passed on as the referring address when you leave the page. You can take the link down and delete a mosaic at any time. Saved mosaics stay saved until you delete them or your account; they are part of the data export under section 14 and are deleted with your account. Legal basis: Article 6(1)(b) GDPR — saving and sharing are the service you asked for; sections 8.12 and 8.8 apply to the check of the shared picture and to reports.

Creative mosaic. You save and share a creative mosaic the same way. What is then saved in addition is the areas you marked in the picture, the part families and colours you chose, the parts as they were placed, the accents, and the name and colour value of every colour used, as they were when it was saved — here too never the photo. When you share it, what is checked is the finished picture with all its parts, as the link shows it.

Building instructions as a PDF. If you ask for the building instructions of a creative mosaic as a PDF, the page sends us the design — the plates, the colour of every stud, the areas you marked, the fill's part families, colours and settings, the accents and the instructions' wording in your language —, never the photo. The PDF is made in the background on our servers under section 4; you do not need to keep the page open for it. For this we store a job with the design, the language, its progress and the times — if you are signed in, also your account ID — and the finished PDF in the file storage under section 4. The link to the PDF is random and cannot be guessed; we store only an irreversible hash of it. It works for 24 hours from completion; after that the PDF and the job are deleted, within 48 hours of completion at the latest, and a job that produced no PDF within 48 hours of the request at the latest. If you ask for the instructions again after that, they are made afresh. The website or the app tells you with a notice that they are ready while you have it open. If you are signed in, we also send you an e-mail through the mail provider under section 7.3 and, if you have switched push notifications on in the app, a push notification through OneSignal under section 10.4. Both state only the number of pages and the 24 hours, nothing of the design, and lead to “Your booklets” in your account, not to the link itself. Both are on until you switch them off in your account under “Notifications” at “Files you asked for”, e-mail and push separately. Without signing in, you learn it only on the page, and the job names nobody. A job with your account ID is, for as long as it exists, part of the copy of your data under section 14 and is deleted with your account. Legal basis: Art. 6(1)(b) GDPR — making and holding the instructions and the message that they are ready are the service you asked for; for the push notification on your device, section 10.4 applies as well.

Building instructions for a brick sign. If you ask for the building instructions of a sign made of bricks as a PDF, they are made in the background, kept, announced and deleted exactly as a creative mosaic's are in the paragraph above. For this the page sends us the design — the text you typed, the typeface, the letter height, the building technique, the colours, the frame and the stand — and the words of the instructions in your language. Because the instructions cannot be drawn without your text, it is in the stored job and in the PDF, both only for as long as described there: 24 hours from completion, deleted within 48 hours of completion at the latest. We write your text into no log and no error report, and neither the e-mail nor the push notification names it. Legal basis: Art. 6(1)(b) GDPR — making the instructions and holding them for you are the service you asked for.

8.15 Training the image recognition with your photos (optional)

On your account page at /account you can allow us to use the photos of your own copies under section 8.2, and the resized versions made from them, to train and test BrickDb's image recognition — for example so that it can one day tell from a photo whether a minifigure is complete. This consent is voluntary and switched off to begin with. It is a declaration of its own, separate from the right of use in your photos under section 4.2 of the terms, which does not cover training, and no feature of BrickDb depends on it.

What it covers. For as long as the consent stands, all photos of your own copies — including those you uploaded before you consented and those you add later — together with their resized versions. It does not cover photos held back by the automatic check under section 8.12, the pictures of your own creations (MOCs), your avatar, event flyers or photos still waiting to be imported. The photos have already had their metadata removed (section 8.2).

Copy into our storage for training data. For as long as the consent stands, we copy every photo it covers, at night, into BrickDb's own storage reserved for training data on the hosting platform under section 4, at Microsoft as processor. It is not public; only our nightly import service and the administration have access to it. With the photo we store nothing about you there — neither your name nor your account ID, your notes or details of your copy — but only an identifier of the photo, which only our database can link to your account, and the catalogue number of the set the photo shows. At most 500 photos are copied per night, so many photos take several nights. We use the copies solely to train and test BrickDb's image recognition.

Who, where and for how long. Only the controller under section 2 trains and tests, itself, on the hosting platform under section 4; the photos and their copies are not passed on to third parties for it, and the only recipient is Microsoft as processor under section 4. No model is currently being trained. Before a model is trained with the copies, we will add to this section the kind, place and duration of the training and how long a trained model is kept, and if that changes anything material, we will ask you again. Retention: A copy is kept for as long as your consent stands and the photo is stored at BrickDb. If you withdraw the consent, delete the photo or your account, if the automatic check under section 8.12 holds the photo back, or if the consent ends when two accounts are merged, we delete the copy the following night, so as a rule within a day, together with every index of our training data that named it. The consent does not extend how long your photos are stored.

Withdrawal. You can withdraw the consent at any time with effect for the future, with the same switch you gave it with, or when you are asked again under the next paragraph. On withdrawal, none of your photos is released for training any more, at once, and their copies in our storage for training data are deleted the following night; we record with your withdrawal that they are to be removed. The lawfulness of the processing carried out until the withdrawal is not affected.

Consents given before 3 November 2026. The copy into our storage for training data exists since 3 November 2026, and we changed the wording of the declaration for it. If you consented before, your consent stands, but we copy none of your photos until you have agreed to the new wording. We ask you for that after your next sign-in on the website or in the app, and on your account page. If you agree, your photos are copied from the following night. If you choose “Not now” or do not answer, everything stays as it was, nothing is copied, and we ask again at a later sign-in. A withdrawal of such an earlier consent still records that no training data were made or passed on.

Proof. We store every consent and every withdrawal with the time and the version of the wording, so that we can show that you consented and to what (Article 7(1) GDPR). These entries are part of the copy of your data under section 14 and are deleted with your account. If you merge two accounts and only one had consented while the other has photos, the consent is withdrawn in the process, so that it does not extend to photos it was not given for.

Legal basis: Article 6(1)(a) GDPR — your consent; for the proof, Article 6(1)(c) GDPR in conjunction with Article 7(1) GDPR.

8.16 Merchandise you add to the catalogue (with a photo)

When you are signed in you can add LEGO merchandise the catalogue lacks on the page /merchandise/contribute: an item, or another colour of a listed item, in the one size you own. Your copy goes into your collection at once, marked as awaiting review; nobody else sees the contribution until a person from the administration approves it. You can attach one photo of your item to the contribution — this is optional. The purpose is for the administration to check that the item exists as you describe it and to recognise duplicates. Legal basis: Art. 6(1)(b) GDPR — the contribution you asked for, with your copy in your collection; for the check and the administration looking at it, Art. 6(1)(f) GDPR (legitimate interest: taking only checked entries into the catalogue and keeping it free of unlawful material).

What we store. With the contribution we store which account submitted it (the only place in the catalogue that names you), the item's name, maker, year, colour, set number and size, the time, the administration's decision with its time and, for a refusal, the reason you are shown. The photo is cleaned like every photo on BrickDb — the format is recognised from the bytes, the image is re-encoded and all metadata including GPS coordinates is removed (section 8.2) — and kept as our own copy in our storage under section 4, never as a link to somebody else's image. There is one photo per contribution, and it can be attached only while the contribution waits for review.

Automatic check. The text of the contribution and the photo are checked automatically when you submit them, under section 8.12; for the photo, the reduced copy described there is sent to Microsoft as processor. A refused photo is deleted and not stored. If the check flags it or cannot run, it is stored but held: even when the contribution is approved, only you and the administration see it until a new automatic check or a person releases it (section 4.7 of the terms).

Who sees the photo. A person from the administration looks at the photo to decide on the contribution — even if the automatic check flagged nothing; that is what sets it apart from the private photos under section 8.12, which the administration looks at only when the check flagged them. The photo is loaded only when they expressly open it and is not cached. Every look is recorded in the audit log under section 8.9: who looked, when, and at which contribution. If the automatic check holds the photo, approving the contribution lifts that hold only if the same person looked at the photo first; otherwise it stays held. The photo is not shown publicly today: no page of BrickDb shows it to anyone but you and the administration, not even after approval. If we want to show it on a public page in future, we will amend this section first. If a contribution is merged into an item that is already listed because it was a duplicate, its photo stays between you and the administration.

How long. While the contribution waits you can remove the photo at any time; it is then deleted together with its check results. If the administration refuses the contribution, the photo is deleted; you see the reason. If the contribution is approved or merged, the photo stays stored — still not public — until you delete your account, and can no longer be removed on its own. The approved item itself stays in the catalogue and does not name you.

Data copy, deletion, merging. Your contribution and its photo are part of the copy of your data under section 14; the photo is a file in the archive. If you delete your account, the contribution, its photo and the photo's check results are deleted, an approved contribution's too; the item in the catalogue stays, without referring to you. If you merge two accounts, the contribution moves to the remaining account with its photo. The photo is not a photo of one of your copies under section 8.2 and therefore never falls under the consent in section 8.15.

8.17 Brick QR code

What you type in the brick QR code at /qr-code — a web address, a contact card or a Wi-Fi network's name and password, for example — is turned into the code where the page runs: on the website, on our web server under section 4 over the existing connection; in the app, on your device. The web server holds it only in memory while the page is open and discards it afterwards; it is not stored, not logged, not passed to any third party and not used to train models. If you ask for the printable building instructions, they are made step by step in the background, like a creative mosaic's under section 8.14: the page sends our servers under section 4 the colour of each stud, the chosen plates and element, whether the code is built from larger plates, the instructions' labels in your language and the domain printed in the footer (in the app, derived from your country), and we keep the job with these details and the finished PDF for 24 hours, as section 8.14 describes; because the built code can be read, your content is in that grid too, and so in the job and the PDF. That is why these instructions are never made for a code that joins a Wi-Fi network. For such a code, and wherever the step-by-step instructions are not offered, the printable instructions are the section sheet: for it, only the colour of each stud, the page's labels and choices (title, size, language) and the domain printed in the footer are sent to our servers under section 4, which draw the PDF file from them and neither store nor log any of it. Anyone who scans the built code can read what it contains — for a Wi-Fi network, the password. You do not need an account for the brick QR code. Legal basis: Article 6(1)(b) GDPR — the processing provides the code, its parts list and its building instructions you asked for.

Saving to your account. When you are signed in, you can save a QR code to your account. What is saved is the name you give it, the plates and the element you chose, the colours used, the colour of every stud, whether it is built from larger plates and when it was saved — not the text you typed. Because the built code can be read, however, your content is in that grid, and whoever reads the grid reads the content too. That is why a code that joins a Wi-Fi network is never saved: before saving, our server reads every grid the way a camera would and refuses it if it contains a Wi-Fi network. Only you see a saved QR code, until you share it. You can delete it at any time; it stays saved until you delete it or your account, is part of the data export under section 14 and is deleted with your account. Saved QR codes and the mosaics under section 8.14 count together towards the most an account keeps. Legal basis: Article 6(1)(b) GDPR — saving is the service you asked for.

Sharing by link. You can share a saved QR code by link. For this we create a random link that cannot be guessed; whoever has it sees the code with its parts list and building instructions and can scan it, but neither your name nor the name you gave it. Only when you share does our server read the saved studs the way a camera would and check the text they contain automatically under section 8.12; a QR code you do not share is not checked. If the check holds the text back, the link shows nothing until a person has looked at it; if it refuses the text, nothing is shared. We do not store the text read; whoever checks the code in the administration reads it again from the studs. Anyone with the link can report the code under section 8.8; if the report is upheld, we take the link down. A shared link is not taken up by search engines, not passed to audience measurement services and not passed on as the referring address when you leave the page. You can take the link down at any time. A code that joins a Wi-Fi network cannot be shared, because it is never saved. Legal basis: Article 6(1)(b) GDPR — sharing is the service you asked for; sections 8.12 and 8.8 apply to the check of the shared text and to reports.

8.18 Stores and events near a place or near you

Searching by place. If you type a town, an address or a postcode into the store finder at /stores or the events at /events, our server sends that text to the Azure Maps service of Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland, as processor under Article 28 GDPR on the basis of the Microsoft Products and Services Data Protection Addendum, to turn it into coordinates. The connection is made by BrickDb's server, not by your browser: Microsoft receives the text you typed and nothing else about you, not your IP address either; Azure Maps processes and stores the request in its European region. So that the same search is not paid for twice, our API server keeps the answer — the place's name and coordinates, not who searched — in its working memory for up to 24 hours. The place you typed is part of the result page's address, so that you can share it; search engines do not index that page. To limit misuse, our API server counts the searches of the last minute per IP address (for IPv6, per /64 network) in its working memory and allows at most ten a minute.

Near me. When you tap “Near me”, your browser asks whether it may share your location; it is never asked for without your tap and your permission in the browser. If you allow it, the page rounds the location to about 100 metres and sends it once over the existing connection to our web server under section 4, which passes it to our API server to find the stores or events within the distance you chose. The location is not stored, not logged, not written into the page's address and not passed to any third party — not to Azure Maps either. In our apps it is your device’s operating system rather than a browser that asks for permission at the first tap, and the app asks only for your approximate location; it rounds it the same way, sends it once directly to our API server and treats it in exactly the same way. A search near a place or near you covers every country. You need no account for either. Legal basis: Art. 6(1)(b) GDPR — the processing performs the search you asked for; for your location also your permission in the browser or in your device’s settings, which you can withdraw there at any time; the limit per IP address rests on Art. 6(1)(f) GDPR, our legitimate interest in protecting the service and its costs against misuse.

Where events take place. When an event is approved — or when an administrator later looks up the places of events approved before — our server sends the venue's name and the country to Azure Maps to find the place for the nearby search; nothing about the person who submitted the event is sent. The coordinates found and the place's name are stored with the event; a place found only roughly is used only once an administrator confirms it. They describe the venue, not the person who submitted it, and so are not part of the data export under section 14. Legal basis: Art. 6(1)(f) GDPR, our legitimate interest in making events nearby findable.

8.19 Stores you add to the store finder or correct

When you are signed in you can add a shop that sells LEGO to the store finder on the page /stores/add, and suggest an edit on the page of a published store, such as different opening hours. Nobody else sees your contribution; it appears in the store finder only once a person from the administration has checked and approved it. Please enter only the business details the store itself makes public, and no private contact details of people. Legal basis: Art. 6(1)(b) GDPR — the contribution you asked for; for the check and the publication, Art. 6(1)(f) GDPR (legitimate interest: taking only checked stores into the store finder and showing other visitors reliable details).

What we store. For each contribution we store which account submitted it, whether it is a new store or a suggested edit, the store it concerns, for an edit the proposed details as you sent them, the time, the administration’s decision with its time and, for a refusal, the reason you are shown. You can add or correct at most five stores a day. The store’s own details — name, address, coordinates, categories, features, phone, e-mail, website, opening hours and description — are public once approved; the store finder names neither you nor your account.

Automatic check. The texts of your contribution are checked automatically when you submit them, under section 8.12, and are sent to Microsoft as processor for that. If the check refuses them, the contribution is not stored. The result of the check is stored and shown to the administration as advice when it decides; the decision itself is recorded in the audit log under section 8.9.

Photos of stores. When you are signed in you can add a photo you took inside or outside a published store on its page. We store our own copy in our storage under section 4 — the format is recognised from the bytes, the image re-encoded and all metadata including GPS coordinates removed (section 8.2) — and with it which account added it, whether inside or outside, the time, and the administration’s decision with its time and, where given, its reason. The photo is checked automatically under section 8.12; for that, the reduced copy described there goes to Microsoft as processor, and a refused photo is deleted. A person from the administration looks at every photo before approving it; every look is recorded in the audit log under section 8.9. Only after approval does the store’s page show the photo to every visitor, without naming you (section 4.8 of the terms). Do not photograph recognisable people without their consent. Anyone shown in an approved photo, or who considers it unlawful for another reason, can report it beneath the photo under section 8.8; if the report is upheld, we take the photo down and delete the file, and you are told why. You can remove any of your photos at any time, an approved one included; if the administration refuses a photo or takes it down, the file is deleted and you are shown the reason. Your photos are part of the copy of your data under section 14 — as files in the archive —, are deleted with your account, approved ones included, and move to the remaining account when you merge two accounts. Such a photo never falls under the consent in section 8.15. Legal basis: Art. 6(1)(b) GDPR for adding it; for the check and the publication, Art. 6(1)(f) GDPR (legitimate interest: showing other visitors what a store looks like).

How long; data copy, deletion, merging. Your contributions are kept until you delete your account; on the page for adding a store you see your latest fifty with their decision. They are part of the copy of your data under section 14. If you delete your account, your contributions and their check results are deleted, and so is every store you proposed that was not approved; an approved store and an applied edit stay in the store finder, without referring to you. If you merge two accounts, your contributions move to the remaining account.

8.20 Claiming a store in the store finder

If you own, manage or work at a store in the store finder at /stores, you can claim it with your account. For that we store which store you claim, your role, the name we may address you by, optionally a business phone number and a note, the state of the claim and the decision with its reason. Confirmation code: if the store has a published e-mail address, we send a six-digit code there through SendGrid (section 7.3), valid for 30 minutes; the e-mail does not say who asked, and of the code we keep only a hash. Documents: you can upload up to three documents — a trade or court register extract, a business registration, other proof or, only with your explicit consent, a copy of your identity card or passport; black out everything on it except your name and photo. Pictures are re-encoded without their metadata, PDF files re-saved by our own server. The documents are kept encrypted in a separate, non-public store at Microsoft as our processor (section 4); they are not checked automatically, not passed to any third party and not used for anything else. Only an administrator deciding your claim can look at them, and only while it waits for the decision; every opening is recorded in the audit log under section 8.9. How long: a document is deleted as soon as the claim is decided or you withdraw it, at the latest 30 days after the upload; a claim never submitted after 30 days, a refused or withdrawn one 180 days after the decision. An approved claim stays while you manage the store; the store's page then says “Managed by the store”, without your name. Your claim is part of the copy of your data under section 14 — the documents with their kind and deletion date, not as files —, is deleted with your account and moves to the remaining account when two accounts are merged. Legal basis: Article 6(1)(b) GDPR for the claim and its handling; Article 6(1)(f) GDPR for checking the documents — our and the store's legitimate interest that only those entitled manage a store; for a copy of an identity document, in addition your consent under section 20(2) of the German Identity Card Act (PAuswG), which you can withdraw at any time by deleting the document or withdrawing the claim.

Managing an approved store: once an administrator approves your claim, you can change the store's opening hours, contact details, what it offers and its description yourself; the change is on the store's page at once. Before that, its text is checked automatically under section 8.12, like every member contribution; a text that is held goes to an administrator first. For each change we store your account, the store, the time and the store's details before and after it, so that an administrator can undo a change that is wrong; such an undoing is recorded in the audit log under section 8.9. The record is part of the copy of your data under section 14, is deleted with your account – the change itself stays on the store's page, which belongs to nobody – and moves to the remaining account when two accounts are merged. Legal basis: Article 6(1)(b) GDPR.

8.21 Testing BrickDb

Request. Signed in, you can ask to test BrickDb on your account page at /account. For that we store your account, the time, the platforms you can test on, optionally a reason of up to 1,000 characters, the state of the request and the decision with its time, for a refusal its category, which you are shown, and — for the administrators only — who decided and an internal note. We tell the administrators about a new request by e-mail (section 7.3), with your name, your e-mail address, the age of your account, the platforms and your reason; you get an e-mail about the decision. Legal basis: Article 6(1)(b) GDPR.

Results. As a tester — administrators always are — you check the items of a checklist at /testing. For every result we store your account, the item and the version of the checklist, the platform, the outcome (passed, failed, blocked or skipped), your comment, the times, how far the administrators have handled it and, if they set a result aside, the category you are shown. We also store the environment you tested in: platform, form factor, device model and manufacturer, operating system and its version, the app's version and build, the website's version, the store the app was installed from, browser or web view with its version, window size and pixel density, the colour scheme, the interface language, the address you use BrickDb at, and whether you were offline. The app reads these from the operating system when you save. For this we collect no IP address, no time zone, no advertising ID and nothing else by which a device could be recognised, and nothing of it is stored on your device. You and the administrators see your results; other testers see at most how many reports an item has, never from whom.

Screenshots. You can attach up to three screenshots to a result. Like photos under section 8.2 they are re-encoded, stored without their metadata in a non-public store under section 4 and checked automatically under section 8.12; a refused screenshot is not stored. Show no one else's data on them. Only you and the administrators can look at one; every look by an administrator is recorded in the audit log under section 8.9.

From result to bug report. So that we can fix a bug, the administrators group results and can have an English bug report drafted from them. For that the comments and the environment — without your name, your e-mail address, your account and without screenshots — go to the Azure OpenAI service of Microsoft Ireland Operations Limited as our processor (section 8.6); they are processed in Azure's EU Data Boundary and not used to train models. An administrator reviews and edits every draft, and only once they approve it do we file it as a bug report in our non-public code repository at GitHub, Inc., USA; none of this happens automatically. The report names neither you nor your account and holds no screenshot, at most a link to a page that only signed-in administrators can open. Legal basis: Article 6(1)(f) GDPR (legitimate interest: finding and fixing bugs in BrickDb).

How long; copy of your data, deletion, merging. A decided request is deleted 24 months after the decision, an open one only after its decision. Results are deleted with their screenshots 24 months after the version of the checklist they belong to was taken out of use. Requests and results are part of the copy of your data under section 14 — the screenshots as files, without the internal note and without who decided —, are deleted with your account, the screenshots first, and move to the remaining account when two accounts are merged. A bug report that was filed does not name you and stays; a link in it to a deleted screenshot leads nowhere.

8.22 Social wall

At /about/social-wall we show our own posts on YouTube, Instagram and Facebook and posts by other people with the hashtag #BrickDb. For this our server — not your browser — reads the newest public posts several times a day through the platforms’ interfaces: the YouTube Data API of Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, and the Graph API of Meta Platforms Ireland Limited, Merrion Road, Dublin 4, D04 X2K5, Ireland. Of a post by another person we store only what is public and what a card needs: a text excerpt of at most 400 characters, the date, the link to the post and, on YouTube, the public name of the channel (at most 100 characters); Instagram names no username in its hashtag search. We do not copy other people’s pictures; the pictures of our own posts we keep in our own store under section 4. A post by another person appears only after a person from the administration has looked at it and shown it.

How long; removal. Every post is deleted 30 days after we last read it. If the administration hides another person’s post, we delete its text, the name and the link at once and keep only its identifier at the platform, so that it does not appear again. Opening the page makes your browser connect to none of YouTube, Instagram or Facebook; that happens only when you click a link. If you would rather a post of yours did not appear here, write to us via /support; we hide it and delete it. Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in pointing to our own channels and to what others share publicly about BrickDb; you can object to this at any time under Art. 21 GDPR via /support.

8.23 Advent calendar 2026

From 1 to 24 December 2026 you can open one door of the BrickDb advent calendar each day and take part in that day's draw; the rules are in the terms of entry. Without signing in you can view the door of the day; nothing about you is stored when you do.

What we store. When you open a door while signed in, we store your account, the day, the time you opened it and whether your entry takes part in the draw and, if not, why (for example because your e-mail address is not confirmed yet). At the first door we store your declarations that you are 18 years old or older and live in Germany, Austria or Switzerland, and your acceptance of the terms of entry, each with its time and version. For each draw we store a check value of the list of entries, the random value, the entry drawn and who confirmed the draw and when. If you win, we store the state of the prize (drawn, notified, claimed, forfeited, redrawn, shipped), the deadline to claim it, your delivery address, your renewed confirmation that you are of age, whether you consented to publication, and the time of shipping. If you want the daily reminder, we store that wish and the way it reaches you (push or e-mail). So that it reaches you at most once a day, we also store the day of the last reminder until we send you the next one. For the time of day we read the country in your profile from the sign-in service when we send it and do not store it in addition; without a country, the time in Germany applies.

Purposes and legal bases. Taking part, checking eligibility, the draw and its record, the notification and the shipping serve to run the prize draw under the terms of entry; the legal basis is Art. 6(1)(b) GDPR. Naming your first name, the initial of your last name and your town on the advent calendar's page, and the daily reminder, are based on your consent under Art. 6(1)(a) GDPR. You can withdraw it at any time with effect for the future, the publication through /support and the reminder where you switched it on. We send the e-mails and push notifications as described in sections 7.3 and 10.4. If you win and have switched on push notifications in the app, you also receive a push notification that only says you have won and leads to claiming the prize; it is on until you switch it off in your account under “Notifications” at “Prizes you won”. Your first name, initial and town are checked automatically under section 8.12 before they are published; if the check holds them back, we name you only once a person has looked at them, and if it refuses them, you can claim the prize without being named.

Recipients. We do not pass your data on to the LEGO Group; it is not involved in the promotion. Apart from us, only Deutsche Post / DHL, which delivers the prize, receives your delivery address. We name winners publicly only with their consent.

How long; copy and deletion. We delete your delivery address 3 months after the prize is shipped or, if it is forfeited, 3 months after the deadline ran out. We delete entries, declarations, draws and prizes 12 months after the end of the promotion on 24 December 2026, by 31 December 2027 at the latest. If you withdraw your consent to publication, we remove your details from the advent calendar's page. Your entries, declarations and prizes are part of the copy of your data under section 14 and are deleted with your account.

8.24 Brick text

Saving to your account. If you are signed in, you can save a sign you designed in brick text at /text-builder to your account. We store the name you give it, your choices — the lines of text, the font, its height and style, the technique, the three colours, the frame's finish and the stand — and when it was saved, changed and shared; the parts and pictures that come from it are worked out again when it is opened. Nobody but you sees a saved sign until you share it; a sign you do not share is not checked.

Sharing by link. If you share a saved sign, we create a random link that cannot be guessed. We store only a check value (hash) of the link, not the link itself, which is why we show it to you only once. Whoever has the link sees the sign, but neither your name nor the name you gave it. Before the link shows anything, the text of the sign is checked automatically under section 8.12: if the check holds it back, the link shows nothing until a person has looked at it; if it refuses it, nothing is shared. A shared link is not taken up by search engines, not passed to audience measurement services and not passed on as the referring address when you leave the page. If you share a sign again, you get a new link and the old one shows nothing any more. Anyone with the link can report the sign under section 8.8; if the report is upheld, we take the link down, and the saved sign stays in your account. You can take the link down at any time and delete a sign at any time.

How long; copy of your data and deletion. Saved signs stay saved until you delete them or your account; they are part of the copy of your data under section 14 — without the link, which we do not store — and are deleted with your account. Legal basis: Article 6(1)(b) GDPR — saving and sharing are the service you asked for; sections 8.12 and 8.8 apply to the check of the shared text and to reports.

9. External data sources

BrickDb displays catalogue and price data from third-party sources, in particular Rebrickable and BrickLink. That data is retrieved on the server only and taken into our own store. At no point does the browser establish a connection to those providers.

No personal data is transmitted to those providers — neither IP address nor identifier, nor the information about what was searched for or about what someone owns. Queries are made on our own schedule and not as a pass-through of a user request. The one exception is the import of your Rebrickable collection under section 8.10, which you trigger yourself.

The posts under /blog are held by Postnomic, a blog service that ThreeB IT GmbH operates itself. Each country site of BrickDb shows its own blog, in the languages of that country and in English. Our API server fetches the texts and pictures there and serves them from our own servers; your browser makes no connection to Postnomic, and Postnomic learns neither your IP address nor who reads a post. BrickDb neither shows comments on posts nor accepts any.

Some of the blog's texts are written with the help of an AI: the monthly overview of new sets, the posts about deals, and the translations of hand-written posts into a blog's further languages. For this, BrickDb sends text from its own servers to the Azure OpenAI service of Microsoft Ireland Operations Limited as processor (section 8.6). For the automatically created posts, that is stored information from the catalogue and about offers — such as set numbers, names, piece counts, release dates, prices, merchant names and voucher codes —; for a translation, it is the title, the excerpt and the text of the post that has already been published. These requests contain no information about readers, about user accounts or about the people who administer BrickDb. Where a hand-written post names people — the organisers of an exhibition, for example — those names, which are already published, are part of the translated text; the legal basis in that respect is Article 6(1)(f) GDPR, our legitimate interest in offering a post in the languages of its country.

Processing takes place in Azure's EU Data Zone, that is within the EU; the deployment is placed in the Germany West Central region. The requests are made in such a way that the service does not store input and answer for later retrieval; in all other respects what section 8.6 says about Azure OpenAI applies, including default abuse monitoring. In concrete terms this means here too: Microsoft automatically checks the inputs – including the text of a post being translated and any names in it – for misuse; an input flagged in that check may be kept by Microsoft as a sample and reviewed by authorised Microsoft staff in the EEA, and Microsoft states no fixed maximum period for this. BrickDb itself stores no text of a translation, only check values (hashes) of the original and of the translation, a note of whether a person has edited it, a reason for refusal where there is one, and the number of requests. Posts written with the help of an AI say so in the post itself; a translation is marked as an AI translation, also after a person has edited it, and links to the original.

10. Audience measurement with Google Analytics

BrickDb uses Google Analytics 4 to count how often pages are opened and which areas are used. This happens only with your consent. Until you have agreed, no script of Google's is loaded, no identifier is set and nothing is sent to Google — not even a so-called cookieless ping. Google's advanced consent mode ("Consent Mode v2 advanced"), in which the script loads immediately and transmits data before consent, is deliberately not used.

Legal basis: Article 6(1)(a) GDPR — your consent — together with section 25(1) TDDDG for storing and reading the information on your device.

Recipient and processor: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, on the basis of Google's data processing terms (Google Ads Data Processing Terms), accepted for the jurisdiction of Germany.

What is processed: the page opened and its title, the referring source, an approximate location at country and region level, device type, browser, operating system, screen size and language, the date and time, and a random identifier in the cookies listed in section 6.1 by which repeat visits from the same browser are recognised. BrickDb can be reached at several country addresses (for example brickdb.de, brickdb.fr and brickdb.net). If you have consented and follow a link from one of these addresses to another, Google Analytics appends this identifier to the link's address for a short time (parameter "_gl"), so that the same visit is not counted twice. At the destination address it is read only if you have consented there as well. The automatic events Google calls "enhanced measurement" are also on: scroll depth, site search, file downloads and clicks on links to other websites — which includes the affiliate links described in section 10.1. Your IP address is used by Google to derive the approximate location and, according to Google, is neither logged nor stored in doing so.

The referring source of the first page view counted: Your decision in the consent banner is a form that is submitted and answered with a redirect; the first page view counted afterwards would therefore name BrickDb itself as its referring source. So that it names the page you actually came to BrickDb from, that page's address is carried in the banner's form — scheme, host and path only, without its query string and without its fragment, and only if it is not one of BrickDb's own pages. Until you have agreed, nothing is stored on your device for this and nothing is sent to Google. If you agree, the cookie bd-ref (section 6.1) holds that address for one minute at most: the next page hands it to Google Analytics as the referring source of that one page view and deletes the cookie in the same response. If you decline, the address is discarded; a withdrawal deletes this cookie as well.

What does not happen: "Google signals" and personalised advertising are switched off in the page source itself (allow_google_signals and allow_ad_personalization_signals are both false), and sharing with "Google products and services" is disabled on the property. No advertising or audience lists are built, no data is passed to Google for advertising purposes, and no cross-device profiles are created. There is no automated decision-making, including profiling, within the meaning of Article 22 GDPR. Apart from the session recording described in section 10.2, which needs a consent of its own, no other analytics services, no advertising networks and no social plug-ins are embedded in the page, and no script belonging to an error-reporting service either: the browser loads nothing from such a service and sends it nothing. The error diagnosis BrickDb does use runs on the server and — in the app — on the device itself; it is described in section 11.

Transfer to third countries: the contracting party is Google Ireland Limited; a transfer to Google LLC in the United States cannot be ruled out. Google LLC is certified under the EU-US Data Privacy Framework, for which the European Commission adopted an adequacy decision on 10 July 2023; the standard contractual clauses in Google's data processing terms apply in addition.

Storage period: event-level and user-level data is retained on the Google Analytics property for up to 14 months from your last interaction, and is then deleted by Google. The period is measured from the last visit rather than the first, because the property's "reset on new activity" option is on: every further visit starts the 14 months again, so for somebody who keeps coming back the data is not deleted while they do. This covers the data tied to individual events and identifiers. The aggregated standard reports — "how many page views did September have" — are not governed by that setting and remain available at Google beyond it. The consent cookie on your device expires after 182 days, after which the question is asked again.

Withdrawal: at the bottom right of every page the cookie symbol opens an "audience measurement" section with a button that reverses your decision — one click there, exactly as agreeing was (Article 7(3) GDPR). Withdrawal takes effect immediately: the script is no longer loaded, and the cookies Google set (_ga and _ga_…) are deleted on the same request. The lawfulness of processing carried out before the withdrawal is unaffected. For data already transmitted to Google you can additionally exercise the rights described in section 14.

What this means for the numbers: only those who agreed are counted. The figures are therefore incomplete and lower than actual usage. That is the intended consequence of the decision to load nothing without consent.

10.1 Affiliate links

BrickDb takes part in affiliate programmes; the links concerned are labelled "Werbung" (advertising) immediately beside the link, or once above a table of several shops, before its first link. This does not change anything said above: no affiliate network is embedded in the page, no script or counting pixel belonging to one is loaded, and no identifier is set. Merely opening a page does nothing of the kind.

On a set page, the deals, a blog post, the catalogue and the home page, BrickDb shows at most one banner from an affiliate programme, also labelled "Werbung" (advertising). The picture is a copy BrickDb fetched from the affiliate network and serves from its own server: showing it contacts neither the shop nor the affiliate network. Only a click on the banner is a click on an affiliate link in the sense of the paragraphs below.

Only when a person clicks such a link does their browser go to the merchant's or the network's address. That is a navigation the person chose, and the site they arrive at is the controller for it. The address carries an identifier that tells the merchant the visit came from BrickDb; it is visible in the address bar. BrickDb does not learn who clicked: the network provides aggregated settlement data only, and no personal data about individual clicks.

Awin. The links to merchants whose prices BrickDb takes from an Awin product data feed run through the Awin affiliate network (AWIN AG, Berlin). BrickDb renders such a link unchanged, exactly as the feed supplies it: it carries BrickDb's publisher identifier, the merchant's identifier and the destination at the merchant, and nothing about you - no account identifier and no click or visitor identifier assigned by BrickDb. When you click it, your browser first goes to an Awin address (awin1.com) and is redirected from there to the merchant. In doing so Awin may collect information directly from you and place or recognise cookies in your browser on its own domain, in order to attribute a later purchase to that click, under Awin's own privacy notice. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Awin.

Rakuten Advertising. The links to online shops - those LEGO runs itself and those of games and toy retailers - whose prices BrickDb takes from a Rakuten Advertising product data feed, run through the Rakuten Advertising affiliate network, and so does the link to the LEGO gift card at Giftcards.com that a set page offers visitors in the US, and the links to LEGO Pick a Brick in a photo mosaic's parts list, where one of LEGO's programmes covers the visitor's LEGO shop. The controller is Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, USA, which states that this also applies to visitors in the United Kingdom and the European Economic Area. For the purposes of its privacy policy, Rakuten Advertising names Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, France, as its establishment in the EU and Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, United Kingdom, as its establishment in the UK. BrickDb renders this link unchanged too, exactly as the product data feed supplies it: it carries BrickDb's publisher identifier, an offer identifier and the destination address in the shop, and nothing about you. The link to the LEGO gift card does not come from the product data feed: Rakuten Advertising generated it for BrickDb once, and it likewise carries only BrickDb's publisher identifier, Giftcards.com's identifier and the destination address at Giftcards.com. When you click a link, your browser first goes to a Rakuten Advertising address (click.linksynergy.com) and is redirected from there to the shop. In doing so Rakuten Advertising may collect information directly from you and place or recognise cookies in your browser on its own domain, in order to attribute a later purchase to that click, under Rakuten Advertising's own privacy notice. You can exercise your rights towards Rakuten Advertising through its privacy request form; its contact options are here. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Rakuten Advertising.

Tradedoubler. The links to the booksellers Hugendubel and eBook.de, whose prices BrickDb takes from Tradedoubler product data feeds, run through the Tradedoubler affiliate network. According to Tradedoubler's own privacy policy the controller is Nyorda AB (Sweden), the parent company of the Tradedoubler group. BrickDb renders this link unchanged too, exactly as the product data feed supplies it: it carries BrickDb's publisher identifier, the programme and product identifiers and the destination address at Hugendubel or eBook.de, and nothing about you. When you click it, your browser first goes to a Tradedoubler address (pdt.tradedoubler.com) and is redirected from there to Hugendubel or eBook.de. In doing so Tradedoubler may collect information directly from you and place or recognise cookies in your browser on its own domain, in order to attribute a later purchase to that click, under Tradedoubler's own privacy notice. You can exercise your rights towards Tradedoubler at privacy@tradedoubler.com. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Tradedoubler.

CJ. The links to the US bookseller Books-A-Million, whose prices BrickDb takes from the product catalogue CJ (Commission Junction) provides for it, run through the CJ affiliate network, which belongs to the Publicis Groupe. According to CJ's privacy policy for the EU and the United Kingdom the controller is Epsilon International UK Ltd, 1st Floor, 2 Television Centre, 101 Wood Lane, London W12 7FR, United Kingdom. BrickDb renders this link unchanged too, exactly as CJ supplies it: it carries BrickDb's publisher and website identifiers, the identifier of the advertising link and the destination address at Books-A-Million, and nothing about you. When you click it, your browser first goes to a CJ address (one of the domains anrdoezrs.net, dpbolvw.net, jdoqocy.com, tkqlhce.com) and is redirected from there to Books-A-Million. In doing so CJ may collect information directly from you and place or recognise cookies in your browser on its own domain, in order to attribute a later purchase to that click; by its own account CJ also processes this data in the United States and bases that transfer on the European Commission's standard contractual clauses, under CJ's own privacy notice. You can exercise your rights towards CJ at privacy@cj.com or through CJ's privacy request form. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to CJ.

Daisycon. The links to the games retailer Spiele Offensive, whose prices BrickDb takes from the product feed Daisycon provides for it, run through the Daisycon affiliate network of Daisycon B.V., P.J. Oudweg 5, 1314 CH Almere, the Netherlands, part of the Linehub group. BrickDb renders this link unchanged too, exactly as Daisycon supplies it: it contains the identifiers of the programme, the advertising link and BrickDb's medium and the destination at Spiele Offensive, and nothing about you. If you click it, your browser first goes to a Daisycon address on the domain glp8.net and is redirected from there to Spiele Offensive. In doing so, by its own account, Daisycon sets a cookie in your browser on its own domain in order to attribute a later purchase to that click, and stores for that purpose an identifier made of the programme, the publisher, the click, the country and the device type, and a truncated and hashed IP address; by its own account Daisycon keeps this data for five years and bases any transfer outside the EEA on the European Commission's standard contractual clauses, according to Daisycon's own privacy policy. You can exercise your rights towards Daisycon at legal@linehub.com. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Daisycon.

Game of Bricks and UpPromote. The light kits on set pages, whose prices BrickDb takes from the product list Game of Bricks provides for it, link directly to the product page in the shop of Game of Bricks OÜ, Majaka tn 26, 11412 Tallinn, Estonia, at gameofbricks.eu. The link contains at most the identifier of BrickDb's affiliate account and nothing about you. If you buy there after the click, or with the discount code BrickDb names beside the set, the shop attributes the purchase to BrickDb's affiliate account with UpPromote, an app it uses for its affiliate programme and which by its own account acts as its processor; what the shop stores about you in doing so is governed by Game of Bricks' own privacy policy. You can exercise your rights towards Game of Bricks at support@gameofbricks.eu. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Game of Bricks or UpPromote.

BRICKMO. The links to the online shop BRICKMO, whose prices BrickDb takes from the product feed the shop provides to BrickDb directly, lead with no affiliate network in between to the product page in the shop of SCALEMO GmbH, Dieselstraße 1, 4623 Gunskirchen, Austria, at brickmo.com. The link contains BrickDb's partner identifier (sPartner=BrickDb) and nothing about you. If you buy there within 30 days of the click, the shop attributes the purchase to BrickDb's partner account; what the shop stores about you in doing so is governed by BRICKMO's own privacy policy. You can exercise your rights towards BRICKMO at office@brickmo.com. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to BRICKMO.

Baustein Store. The links to the LEGO® specialist Baustein Store, whose prices BrickDb takes from the product feed the shop provides to BrickDb directly, lead with no affiliate network in between to the product page in the shop of Matthias Ross, Baustein Store, Schwarzenbacher Ring 17, 91315 Höchstadt a.d.Aisch, Germany, at bausteinstore.de. The link contains BrickDb's partner identifier (ref=56) and nothing about you. If you buy there within 30 days of the click, the shop attributes the purchase to BrickDb's partner account with its affiliate programme, as far as you have agreed in the shop to the storage this needs; what the shop stores about you in doing so is governed by Baustein Store's own privacy policy. You can exercise your rights towards Baustein Store at info@bausteinstore.de. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to Baustein Store.

KiSebA. The links to the LEGO® specialist KiSebA, whose prices BrickDb takes from the product feed the shop provides to BrickDb directly, lead with no affiliate network in between to the product page in the shop of Sebastian Kirst, KiSebA, Obernstr. 10, 28832 Achim, Germany, at kiseba.com. The link contains BrickDb's partner identifier (BDB=a92d298j6a4a) and nothing about you. If you buy there after clicking a BrickDb link, KiSebA attributes the purchase to BrickDb through the partner plugin of its own shop and the partner identifier in the link. For this, KiSebA states that it stores in its shop, for 14 days, that you came via BrickDb; a purchase within that time is attributed to BrickDb. This happens in KiSebA's shop, under KiSebA's own responsibility and governed by KiSebA's own privacy policy, not on BrickDb's site. You can exercise your rights towards KiSebA at info@kiseba.com. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to KiSebA.

eBay Partner Network. The links to listings on eBay, whose prices BrickDb reads through eBay's own programming interface, have been affiliate links of the eBay Partner Network since 28 October 2026, which eBay Partner Network, Inc., 2145 Hamilton Avenue, San Jose, CA 95125, USA, operates. To the link to a listing BrickDb adds only the identifiers the eBay Partner Network prescribes for it - BrickDb's campaign id and identifiers of the eBay marketplace and of the tool - and nothing about you. If you click it, your browser goes straight to the listing on eBay (such as www.ebay.de or www.ebay.com); eBay may collect information directly from you there and set or read cookies in your browser on its own domain in order to attribute a later purchase to that click, according to eBay's own privacy notice. Under that notice the controller for users in the EU is eBay GmbH, Albert-Einstein-Ring 26, 14532 Kleinmachnow, Germany; you can exercise your rights towards eBay through eBay's privacy contact page. BrickDb sets no cookie for this, does not record the click on its own server and does not itself transmit any data about you to eBay.

Amazon. As an Amazon Associate, BrickDb (ThreeB IT GmbH) earns from qualifying purchases. BrickDb takes part in the Amazon Associates programmes for amazon.com (operated by Amazon.com Services LLC) and amazon.de (operated by Amazon Europe Core S.à r.l.). A set page links to a search in the Amazon store; nothing of Amazon's is loaded on BrickDb - no script, no image, no price and no logo. Once you follow such a link you are on Amazon's own site, where Amazon may collect information directly from you and place or recognise cookies in your browser, under Amazon's own privacy notice. BrickDb receives aggregated reports from Amazon, not data about individual visitors.

One addition since the audience measurement: if you have agreed to it under section 10, the click on such a link is additionally counted as an event in Google Analytics — with the destination address, and with nothing identifying who clicked beyond the random identifier described there. Without your consent that does not happen either.

10.2 Session recordings and heatmaps (Microsoft Clarity)

BrickDb uses Microsoft Clarity to see how pages are used: where people click, how far they scroll, and at which points a page is not understood. To do so, Clarity records the course of a visit ("session recording") and combines many visits into click maps and scroll maps ("heatmaps"). This happens only with your own consent to it. It is asked for in the consent banner separately from the audience measurement described in section 10 and is not pre-selected; anyone who has agreed only to the audience measurement is not recorded. Until you have agreed to the session recordings, no script of Microsoft Clarity's is loaded, no entry is set and nothing is sent to Microsoft Clarity. The mode of Clarity in which recording takes place "cookielessly" without consent is deliberately not used.

Legal basis: Article 6(1)(a) GDPR — your consent — and section 25(1) TDDDG for storing and reading the information on your device.

What is recorded: mouse movements, clicks, scrolling, resizing of the window, and that and where something was typed — not what; the structure of the page displayed, in the masked form described below; the address of the page, its title and the address of the page visited before it; technical details of the device and the browser (browser, operating system, screen and window size, language and time zone); the date and time; errors in loading scripts and images; and the random identifiers from the entries listed in section 6.1, by which the page views of one visit and repeat visits from the same browser are brought together. Your IP address reaches Microsoft with every transmission; according to Microsoft, it derives the approximate location from it. Whether and for how long Microsoft stores the IP address beyond that, Clarity's documentation does not say.

What is masked: text and images are masked in your browser itself, before anything is transmitted: of a text only its length is transmitted, of an image only its size and not its address. That applies to the whole page. The only things that remain readable are the labels of the navigation and — only while you are not signed in — the content of the public catalogue and editorial pages, which is the same for everyone, for example that of a set page, a blog post or the frequently asked questions. If you are signed in, nothing but the navigation remains readable: your collection, your copies, notes, photos, prices, storage places, your wishlist, your account and your name are not contained in any recording. What is typed into form fields is never recorded, in any case. A recording therefore shows how a page was built and how it was used — not your data.

What cannot be masked: the address and the title of a page. At BrickDb the title contains nothing you entered yourself. The address contains your search term when you use the search and, on the pages of your own copies, a random identification number.

Where recording never takes place: on the following pages Clarity — like Google Analytics — is not loaded, regardless of your consent: on invitation links to a shared collection, on published collections, in the administration area, during sign-in, during the hand-over to another country address, and on the error page. Clarity is not used in the app.

No link to your account: BrickDb passes Clarity no account identifier, no e-mail address and no name, and does not link recordings to your account.

Analysis with AI: in our Clarity project the features Microsoft calls "Copilot" are switched on. With them, Microsoft also processes the recordings and heatmaps with AI features, in order to produce summaries for us and to answer questions about them. What is processed is what was recorded — that is, the masked version. Which AI model Microsoft uses for this, where this processing takes place and how long the summaries it produces are kept, Clarity's documentation does not say. Microsoft gives no assurance for Clarity that the data is not used to train AI models; under Clarity's terms of use, Microsoft may also use non-personal data from Clarity to train AI models.

Recipient and its role: Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland. Unlike for the hosting described in section 4, Microsoft is not a processor here: under Clarity's terms of use, BrickDb and Microsoft are each an independent controller. Under those terms Microsoft may also use the data collected through Clarity for its own purposes in accordance with the Microsoft Privacy Statement — according to those terms, to provide and improve its own products and services and to build user profiles, including for advertising. Passing the data on to Microsoft's advertising services is switched off: the page source tells Clarity that there is no consent for advertising purposes (ad_Storage: 'denied'), the matching with Microsoft's advertising identifier is therefore not triggered, and the browser is not allowed to call the addresses Microsoft uses for it. How Microsoft processes data in other respects is set out in Microsoft's privacy statement.

Transfer to third countries: according to Microsoft, it stores the data in its cloud service Azure and gives no assurance for Clarity of a storage location within the EU; processing in the United States is therefore to be expected. According to Microsoft, Microsoft Ireland Operations Limited is the contracting party for Clarity customers in the EU and bases the transfer to Microsoft Corporation on the European Commission's standard contractual clauses; otherwise what section 4 says about transfers to Microsoft applies.

Storage period: according to Microsoft's documentation, recordings are kept for 30 days; heatmap data, and recordings that we have marked or that Microsoft selects as a sample, for up to 9 months. After that Microsoft deletes them. The entries on your device are listed in section 6.1.

Connection with Google Analytics: our Clarity project is connected to our Google Analytics property. Through that connection Clarity retrieves reports from Google Analytics and displays them in Clarity; this concerns data that arose under section 10 with consent to the audience measurement. According to Microsoft's documentation, Clarity sends no recordings and no addresses of recordings to Google Analytics in doing so, and Clarity's script in your browser passes nothing to Google.

Withdrawal: at the bottom right of every page the cookie symbol opens the section in which, next to the button for the audience measurement, there is a separate one for the session recording — one click there, exactly as agreeing was (Article 7(3) GDPR). Withdrawal takes effect immediately: the script is no longer loaded, and the cookies _clck and _clsk are deleted on the same request; _cltk ends with the tab. The lawfulness of processing carried out before the withdrawal is unaffected. For data already transmitted to Microsoft you can exercise the rights described in section 14 against us and, because Microsoft is an independent controller, also directly against Microsoft. We cannot attribute individual recordings to a person and therefore cannot pick them out specifically.

10.3 Usage statistics in the apps

The BrickDb apps for Android, iOS, macOS and Windows count how they are used — only with your consent, which is asked for in the app itself. The app asks on first start. Until you have agreed, nothing is stored on your device for this and nothing is sent. The consent on the website and the one in the app are independent of each other.

What is counted — and nothing beyond it:

• the start of the app, with the platform (Android, iOS, macOS or Windows), the store it was installed from, and the version number;
• the opening of a screen, named by its kind — "set page", for instance — and never by the set, the collection or the search it shows;
• a sign-in, with the kind of sign-in route (e-mail, Apple, Google or Microsoft) — never with an address;
• the use of a scanner, with the kind of scanner and whether the code named something in the catalogue — never with the code;
• an addition to a collection, with the kind of item (a set or a magazine, for instance) — never with the item itself;
• a click on a link to a shop, with the shop's hostname and the price source — never with the link itself.

Not recorded: search terms, set or part numbers, the contents of your collection, prices you entered, your account or your e-mail address, a location, and free text. The events are defined so that they cannot hold such details.

The identifier: with your consent, the app places a random identifier in the operating system's settings store (section 6.5), by which repeated use of the same installation is recognised. It is tied to the device and not to your account, and it contains no details about you. When you sign out it is replaced by a new one, so that two accounts on the same device are not connected with each other.

The route the data takes: the app sends the events to BrickDb's server and to nobody else; it establishes no connection to Google or to any other third party for this. Our server forwards them to Google Analytics, through Google's endpoint for collection in the European Union. Your IP address is not passed on to Google: Google sees our server's address, and no location is derived from yours. Details about your device and your account are not sent along either.

Recipient and processor is, as for the website, Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, under Google's data processing terms (Google Ads Data Processing Terms); for the third-country transfer, what section 10 says above applies. The events go into a data stream of their own in the same Google Analytics property, separate from the website's figures. Every transmission carries the statement that the data may not be used for personalised advertising; no advertising or audience lists are built.

Legal basis: Art. 6(1)(a) GDPR — your consent — and § 25(1) TDDDG for storing and reading the identifier on your device.

Storage period: at Google as above — up to 14 months from your last interaction. On the device the identifier stays until you withdraw, sign out or remove the app.

Withdrawal: in the app, "Settings" has the entry "Usage statistics" with the buttons "On" and "Off". "Off" takes effect at once: the app deletes the stored identifier and sends nothing more; whatever had not been sent yet is discarded. The lawfulness of processing carried out before the withdrawal is unaffected. Your decision itself stays stored on the device, so that the app does not ask again at every start. If what is counted changes, the app asks again.

10.4 Notifications by e-mail and push

If you switch on a price alert for a set on your wishlist — for a target price or for the lowest price of the last 30 days —, we compare the prices in our own store with what you asked for and tell you when it is reached: at most once a day, in one message for everything that fired, and by the ways you switched on. The message names the set and the price. Where you switch the ways on and off is in your account under Notifications.

E-mail: You get the e-mail as soon as you switch on a price alert; it contains a link that switches the alert off with one click, and you can switch it off in your account under “Notifications”. It is sent through the mail provider described in section 7.3, and what is said there applies here too. Legal basis: Art. 6(1)(b) GDPR — the alert is the service you switched on.

Push notifications: In the apps for Android and iOS they exist only if you switch them on yourself: your device is registered for push notifications only when you switch a push switch on in your account in the app, and when you do, your device’s operating system asks for permission as well; the push switch for price alerts is off until you switch it on. On the website, push works in the browser instead, as described below under “Push notifications in the browser”. On a device that supports none — an Amazon Fire tablet, for example — the app says so and offers e-mail only. At present we send nothing by push but price alerts and the message that building instructions you asked for as a PDF are ready (section 8.14); its switch, “Files you asked for”, is on until you switch it off, because that message comes only in answer to your own request, and it too reaches only a device you registered as described. Before we send anything else we name it here, and we send messages of a promotional nature only if you have expressly switched them on. Push notifications: They exist only in the apps for Android and iOS, and only if you switch them on yourself: your device is registered for push notifications only when you switch a push switch on in your account in the app, and when you do, your device’s operating system asks for permission as well; the push switch for price alerts is off until you switch it on. There are no push notifications on the website. On a device that supports none — an Amazon Fire tablet, for example — the app says so and offers e-mail only. At present we send nothing by push but price alerts and the message that building instructions you asked for as a PDF are ready (section 8.14); its switch, “Files you asked for”, is on until you switch it off, because that message comes only in answer to your own request, and it too reaches only a device you registered as described. Since 3 November 2026 we also tell you, by push and by e-mail, when something changes for you in a shared collection you are in (someone adds you, changes your role or removes you, accepts your invitation or leaves a collection you own), when our moderation has decided about something you submitted (a MOC, an event, a claim to a store), and – by push only – when we have answered a support request you sent while signed in. These three switches are on until you switch them off, because they concern only your own things; they too reach only a device you registered as described. A moderation decision that gives reasons, and our answer to a support request, always come to you by e-mail, whatever these switches say. On each of these three topics you get at most one push notification a day; for that we keep the day on which we last sent you one on which topic, until we send you the next one or your account is deleted; that entry is part of the copy of your data under section 14. Before we send anything else we name it here, and we send messages of a promotional nature only if you have expressly switched them on. Push notifications: They exist only in the apps for Android and iOS, and only if you switch them on yourself: your device is registered for push notifications only when you switch a push switch on in your account in the app, and when you do, your device’s operating system asks for permission as well; the push switch for price alerts is off until you switch it on. There are no push notifications on the website. On a device that supports none — an Amazon Fire tablet, for example — the app says so and offers e-mail only. At present we send nothing by push but price alerts and the message that building instructions you asked for as a PDF are ready (section 8.14); its switch, “Files you asked for”, is on until you switch it off, because that message comes only in answer to your own request, and it too reaches only a device you registered as described. Since 3 November 2026 we also tell you, by push and by e-mail, when something changes for you in a shared collection you are in (someone adds you, changes your role or removes you, accepts your invitation or leaves a collection you own), when our moderation has decided about something you submitted (a MOC, an event, a claim to a store), and – by push only – when we have answered a support request you sent while signed in. These three switches are on until you switch them off, because they concern only your own things; they too reach only a device you registered as described. A moderation decision that gives reasons, and our answer to a support request, always come to you by e-mail, whatever these switches say. On each of these three topics you get at most one push notification a day; for that we keep the day on which we last sent you one on which topic, until we send you the next one or your account is deleted; that entry is part of the copy of your data under section 14. There are promotional messages on three topics, and only if you switch them on yourself in your account under “Notifications”, for e-mail and push separately: new sets in themes you follow, new events in your country and, while the advent calendar runs, the advent calendar reminder (section 8.23). The e-mail is double opt-in: when you switch it on, we send you a single confirmation e-mail, and it is switched on only once you click its link while signed in and confirm there. The link works for 7 days and only for your own account. For this we keep which topic you asked to confirm, when, when you confirmed, which version of this text applied, and, where it applies, when you switched the e-mails off again, together with an irreversible hash of the link; an unconfirmed request is deleted as soon as you ask for a new one or switch the e-mails off, and the proof of a consent given is kept until your account is deleted and is part of the copy of your data under section 14. For push notifications, your device’s or browser’s permission is the second step. You can follow a theme on its theme page while signed in; we keep which themes you follow and since when, until you stop following them or your account is deleted, and that list is part of the copy of your data under section 14. For the events we use the country you gave in your profile; we read it from the sign-in service under section 7 when we send, and do not store it separately, and without a country in your profile you get no such message. We send each at most once a day, the first two in one message for everything that is new. Legal basis: Article 6(1)(a) GDPR and, for the e-mail, § 7(2) No. 2 of the German Act against Unfair Competition (UWG) – your consent, which you give with the switch and can withdraw with it at any time, and also through the link in every one of these e-mails. Before we send anything else we name it here, and we send messages of a promotional nature only if you have expressly switched them on.

What goes to OneSignal with a push notification — and nothing beyond it:

• a random push ID that BrickDb assigns to you; it is neither your account identifier nor your e-mail address, and it is linked to you only through our database;
• the device token your operating system issues for push notifications, and the technical details OneSignal’s SDK sends with it — operating system and version, device model, app version, language and time zone — and the IP address of the connection;
• the usage details that OneSignal’s SDK keeps on its own for the operation of the service: how often the app was started and how long it was in the foreground, with the times of the first and the last start, the status of the notification permission, the country, the type of the network connection (for example Wi-Fi or mobile network) and the name of the mobile network operator, and that — and when — a notification arrived and was opened. These are not the usage statistics of section 10.3 and do not depend on the consent given there;
• the content of the notification: title and text, for a price alert with the name of the set and the price, for building instructions with their number of pages and the 24 hours, for a message about a collection, a moderation decision or a support answer only what happened – without the name of a collection, a MOC or an event, without reasons and without the content of an answer –, for a promotional message only how many new sets or events there are – without your themes and without your country –, in all the languages of the website, and the page it opens;
• not your name, your e-mail address, your account identifier, or the rest of your collection and wishlist.

The processor is OneSignal, Inc., San Mateo, California, USA, on the basis of the data processing agreement (Art. 28 GDPR) that ThreeB IT GmbH concluded with it on 1 November 2026. Delivery runs through the operating system’s push service: on Android through Google’s Firebase Cloud Messaging, on iOS through Apple’s Apple Push Notification Service. Both receive the device token and the content of the notification from OneSignal for that purpose and pass both on to your device; their own privacy terms apply to them.

Transfer to a third country: OneSignal processes the data in the United States. The transfer rests on the European Commission’s adequacy decision for the EU-US Data Privacy Framework — OneSignal, Inc. is listed there as actively certified (checked on 1 November 2026 at dataprivacyframework.gov) — and, in addition, on the European Commission’s standard contractual clauses, which are part of the data processing agreement.

Legal basis: Art. 6(1)(a) GDPR — your consent, which you give by switching push notifications on in the app and confirming your device’s permission — and § 25(1) TDDDG for storing and reading the identifiers on your device. Withdrawal: at any time, by switching the push switches in your account off — we then send you nothing more —, by forbidding the notifications in your device’s settings or by removing the app. The lawfulness of the processing carried out until then remains unaffected.

Storage period and your rights: At BrickDb your push ID and your settings stay until your account is deleted; a switch that is off does not delete the ID. BrickDb does not store the content of a notification. If you delete your account (section 14), we first delete the user assigned to you at OneSignal and only then our own data; if the provider cannot do that, the deletion stops and is continued at the next attempt. The push ID and your settings are part of the copy of your data under section 14 and pass to the remaining account when two accounts are merged; the device token is held by OneSignal and is not part of that copy. At OneSignal, by its own statement in the data processing agreement, data from the interface and from automated messages is kept for 30 days and then deleted, and data in the dashboard for as long as the application exists; if you delete your account, we delete the user at OneSignal.

Push notifications in the browser (web push): On the website you can switch push on for the browser you are using, in your account under “Notifications” at “Push in this browser” — separately for each BrickDb address, because to a browser every address is a website of its own. Only when you switch it on does your browser ask for permission, and only then does the website register a small script of ours in your browser (a service worker, listed in section 6.1) and subscribe it at your browser’s push service. No script of a third party is loaded for this, and OneSignal is not involved. For each browser we store the address its push service gave it, two keys your browser created for it, the BrickDb address and the language it was switched on in, and when; nothing else about your device. Which notifications arrive is decided by the same push switches as in the app. We send each notification from our own server, encrypted so that only your browser can read it and signed with our own key; it contains the title, the text and the page it opens on the same BrickDb address. On an iPhone or iPad, Safari offers this only for a website added to the Home Screen.

Who delivers it: the push service of your browser’s maker, which your browser chooses, not we: for Chrome, Edge on Android, Opera, Samsung Internet and Brave, Google’s Firebase Cloud Messaging (Google LLC, USA); for Firefox, Mozilla’s push service (Mozilla Corporation, USA); for Safari, Apple’s push service (Apple Inc., USA); for Edge on Windows, Microsoft’s Windows Push Notification Services (Microsoft Corporation, USA). It receives the address and the encrypted notification, and from your browser the connection data its operation needs; it cannot read the content. Its own privacy terms apply to it. Transfer to a third country: these services may process the data in the United States. Where the provider is certified under the Data Privacy Framework, the transfer rests on the European Commission’s adequacy decision; otherwise on Art. 49(1)(b) GDPR, because the notification you switched on can be delivered only through the push service your browser uses.

Legal basis: Art. 6(1)(a) GDPR — your consent, which you give by switching push on in the browser and confirming its permission — and § 25(1) TDDDG for the service worker and the subscription on your device. Withdrawal: at any time, by switching “Push in this browser” off — we then delete the subscription —, by blocking notifications in your browser’s settings or by deleting the website’s data in your browser; a subscription that the push service reports as no longer valid we delete when we next try to send. Until then the subscriptions stay with us, at the latest until your account is deleted; they are part of the copy of your data under section 14, are deleted with your account and pass to the remaining account when two accounts are merged. The lawfulness of the processing carried out until then remains unaffected.

11. Operational monitoring and error diagnosis

The application is instrumented with OpenTelemetry. That data is exported only if a destination is expressly configured; in operation no such destination is configured, so this telemetry does not leave the process. Calls to the status endpoints are excluded from recording.

For error reports, the service Sentry is used in addition. If the app crashes, or a request on the server fails unexpectedly, an error report is transmitted to Sentry so that the fault can be found and fixed. That concerns seven places: the API server, the web server, the reading service described in section 8.5, the PDF check for building instructions, the minifigure matching service described in section 8.6, the MCP server for AI assistants and — unlike everything else in this section — the app on your device. In all seven the connection to Sentry is made by the application itself; no script belonging to an error-reporting service is embedded in the website, so the browser sends nothing there of its own accord (section 10).

The provider is Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA, and is a processor under Article 28 GDPR in this respect. By its own account Sentry maintains no establishment in the European Union with which a contract could be concluded — so the contracting party is a company based in the United States.

Place of processing: where the data sits is a separate question. The reports go to Sentry's EU region, which Sentry designates European Union (EU) and which is the storage region set for our organisation. The receiving address in all seven places is on ingest.de.sentry.io and not on the service's worldwide address. Those are two different things and only the second is a host name: the address the software sends to, as against the account setting that decides where what arrives is kept.

Transfer to a third country: because the contracting party is based in the United States, access from there — in the course of support and maintenance, for example — cannot be ruled out. Sentry bases such transfers on the European Commission's standard contractual clauses, which underlie its data processing addendum in version 5.1.0 of 29 May 2024.

What an error report contains: the kind of error and its message, the technical call trace (files, methods, line numbers), the version of BrickDb, the address requested with its query parameters, except those removed as described below, on the API server and the web server also the headers of the request — the identification of your browser, the preferred language and the page you came from, for example — and what the Sentry SDK collects of its own accord about the environment — in particular the device model, the operating system and its version, the language and the time zone. On the API server the pseudonymous identifier for your account is added if you were signed in; the web server and the app transmit no identifier at all.

What the reading service reports: the reading service described in section 8.5 sends an error report only when reading a photo fails unexpectedly; that it is busy, or that it refuses a photo, it does not report. Such a report contains the kind of error and its message, the technical call trace, the version of BrickDb, the internal address at which the API server called it, the headers of that internal call — not those of your browser — and the details of the server environment. The reading service transmits no identifier for your account. The photo you submitted is never contained in a report from the reading service, not even in part: the content of a request is not captured, and the reading service logs nothing about the photo.

What the PDF check reports: building instructions in PDF format that you upload for a MOC under section 8.11 are checked by a further server of our own, the PDF check (the container app “brickdb-pdf-sanitiser”), which saves them afresh in doing so. It sends an error report only when saving a file afresh fails unexpectedly or its licence key is refused at startup; that it refuses a file, or that it is busy, it does not report. Such a report contains the kind of error and its message, the technical call trace, the version of BrickDb, the internal address at which the API server called it and the details of the server environment — but no headers, neither those of that internal call nor those of your browser. The PDF check transmits no identifier for your account. The file you uploaded is never contained in a report from the PDF check, neither its content nor its file name, and Sentry does not keep the IP address of the connection for these reports either.

What the minifigure matching service reports: the minifigure matching service described in section 8.6 sends an error report only when comparing a picture fails unexpectedly; that it is busy, or that it refuses a picture, it does not report. Such a report contains the kind of error and its message, the technical call trace, the version of BrickDb, the internal address at which the API server or our nightly catalogue import called it, the headers of that internal call — not those of your browser — and the details of the server environment. The minifigure matching service transmits no identifier for your account. The photo you submitted is never contained in a report from the minifigure matching service, not even in part, and Sentry does not keep the IP address of the connection for these reports either.

What the MCP server reports: through our MCP server (the container app “brickdb-mcp” at mcp.brickdb.net) you can use BrickDb from an AI assistant, such as Claude or ChatGPT; for every request from the assistant it calls the API server with your own sign-in. It sends an error report when a request fails unexpectedly or a tool the assistant calls fails unexpectedly; that the API server refuses a request, it does not report. Such a report contains the kind of error and its message, the technical call trace, the version of BrickDb, the address called, the headers of the request your assistant's software sent — without your access token and without the headers carrying an IP address —, the name of the tool called, the requests the MCP server made to the API server in doing so, with their full address, and the details of the server environment. The MCP server transmits no identifier for your account. What you asked the assistant to do is not contained as such in a report from the MCP server: the content of a request is not recorded, and of a tool the MCP server logs only its name, not the details the assistant passes to it. Such a detail can, however, appear in the address of a request to the API server, for example a search term or a set number. Sentry does not keep the IP address of the connection for these reports either. If you run the MCP server yourself on your own computer, it sends no error reports.

What your browser reports to the web server: if a script on a page of the website raises an error in your browser, the page reports it to the web server it was loaded from, and to nobody else — at most five times per page view, and the same error only once. What is reported is the kind of error, its message, the script's file name, line and column and the page's path, never its query parameters. Nothing is stored on your device for this. The web server reduces it at once: the path becomes the page's template (for example “/sets/{SetNumber}” instead of the set number), e-mail addresses, web addresses, identifiers, long strings and runs of digits in the message are replaced, and of the browser identification every request sends anyway only the browser family (for example “chrome”) is kept. Only these details are written to its log and sent to Sentry as an error report — without the request's headers, without the page's address, without your IP address and without an identifier of your account. The web server uses your IP address only to limit the number of reports per sender; for that it holds it in memory for at most ten minutes and writes it down nowhere. No consent is needed for this, because nothing is stored on your device and your browser contacts no third party; for the legal basis, what is said below applies.

What the app records in addition: so that a fault on your device can be traced, the app attaches a trail to an error report. It contains the names of the pages opened most recently (not their addresses); for every request to our server that did not succeed, the method, the address as a pattern without identifiers, the status code, the duration and, where known, the kind of error; the settings recorded at start-up — the server's address without a path, whether sign-in and error reporting are switched on, and the language set; and, because the Sentry SDK keeps a trail of requests of its own, for every request the app makes — to our server and to the sign-in service — also the full address with the method and the status code, including the path, which can contain a set number or the identifier of a collection, for example, and the query parameters, a search term for example. From this address too, the query parameters named above whose name suggests a secret, and e-mail addresses, are removed before it is sent. The same address can also appear in a performance trace, which Sentry creates for a randomly selected 2 % of the operations in the app.

Details of the device: every report the app sends after it has started carries the platform, the version of the operating system, the kind of device (a phone or a tablet, for example) and the version of the app; and, once the start-up check of how the app is displayed has run, also the kind and major version of the web view the app runs in. If the app fails to load an image, a stylesheet, a script or a font, or blocks content for security reasons, what that was is recorded — for our own files the path without identifiers, for anybody else's addresses only the server's name, for a font its name — and once at start-up a check of how the app is displayed: which stylesheets loaded, how many rules they contain and which typeface is actually used. Such a failed load, a server error or a request that receives no answer at all can trigger a report of its own without a crash — the same fault at most once in ten minutes for a request, and at most once per start of the app for a failed load.

The log on your device: the app writes to a log in its own storage area: every request to our server — every successful one too — with the method, the address as a pattern without identifiers, the status code, the duration and a random request number; the failed loads named above; the result of the start-up check of how the app is displayed, including the kind and version of the web view; the settings recorded at start-up; and the app's other messages from the level "Information" up. The names of the pages opened, the kind of an error, the details of the device and the full addresses from Sentry's own trail are not in this log. It holds at most three files of one megabyte each, the oldest entries being overwritten, and every entry is cleaned as it is written in the same way as an error report. This log never leaves the device by itself. Only if you tap "Copy diagnostics" under "About" does the app put the app version, the platform, the version of the operating system, the kind of device, the settings recorded at start-up and up to 200 of the most recent entries — cleaned once more — on the clipboard; where you paste them is your decision.

What is expressly removed before a report leaves the device or the server: all cookies, the entire content of a request, every query parameter whose name suggests a secret (among them code, state, token, password, email, key), every header value whose name suggests a secret, every header in which our upstream servers pass on your IP address, and e-mail addresses and token-shaped strings — including in the middle of an error message. A user name, an e-mail address or an IP address in the report's user section is overwritten before the report is sent, as is the installation identifier the SDK writes there of its own accord. That cleaning is built so that when it fails it discards the report rather than sending it unfiltered.

The application itself sends no IP address: SendDefaultPii is false at all seven places, the cleaning just described overwrites that field in any case, and it also removes the headers in which our upstream servers pass on your IP address to the web server, the API server and the MCP server. Screenshots are not attached, and the text of the user interface is not taken into the breadcrumb trail; both are expressly switched off. Photographs cannot reach an error report, because the content of a request is removed in full in any case.

Performance traces on the server: whether or not an error occurs, the web server, the API server, the reading service, the PDF check, the minifigure matching service and the MCP server create a performance trace for a randomly selected share of requests and transmit it to Sentry, so that slow spots can be found; calls to the status endpoints and the test requests of our upstream servers are excluded. The share is at most 5 %, currently 0.2 %; requests for static files such as pictures, stylesheets and scripts are never traced. If a request comes from the app, from the web server or from the API server, however, and belongs to an operation for which it has already been decided there whether it is traced, the server adopts that decision, so that such an operation is traced either at every stage or at none. Such a trace contains the same details of the request as an error report from the server — the method, the address requested with its query parameters, a search term for example, and the headers of the request — and in addition the pattern of the address requested without identifiers, the status code of the response, when processing began and how long it took, and the messages the application logs meanwhile. Added to that are the individual steps with their duration: the requests the server itself makes in doing so — the web server to the API server, or the API server to the sign-in service, for example — each with the method, the full address and the status code, and the database queries with their text, in which values inserted appear only as placeholders and not as the values themselves. On the API server the trace carries the pseudonymous identifier for your account if you were signed in; the web server, the reading service, the PDF check, the minifigure matching service and the MCP server transmit no identifier. For the reading service a trace concerns only the internal call made by the API server; it makes no requests of its own to other servers and no database queries in doing so, and the photo is never contained in a trace either. Likewise, for the PDF check a trace concerns only the internal call made by the API server, with no requests to other servers and no database queries, and the file you uploaded is never contained in a trace either. For the minifigure matching service a trace concerns only the internal call made by the API server or our nightly catalogue import, with no database queries, and the photo is never contained in a trace either. For the MCP server a trace concerns the request from your AI assistant and the requests it makes to the API server for it, with no database queries; their addresses can contain a detail the assistant passed on, for example a search term. Every performance trace is cleaned in the same way as an error report, as described above; in particular the cookies and the headers carrying your IP address are removed before it is sent. The legal basis is Article 6(1)(f) GDPR; the legitimate interest lies in operating the application quickly and reliably. Sentry keeps a complete performance trace for at most 90 days on our plan; a reduced sample of the traces may be kept by Sentry for up to 13 months.

Sentry does not keep the IP address of the connection. Sending a report opens an internet connection, so the address it was sent from is necessarily visible to the receiving server while it is transmitted. Sentry offers a setting that discards that address instead of recording it, and that setting is switched on for all seven projects — those of the API server, the web server, the reading service, the PDF check, the minifigure matching service, the MCP server and the app. An error report therefore does not keep the address. That applies to the app's reports too, where it would be the address of your own internet connection; for the API server, the web server, the reading service, the PDF check, the minifigure matching service and the MCP server it would be the address of our own servers.

For the transmission, everything else in this section applies unchanged: the recipient is Functional Software, Inc. d/b/a Sentry, the reports go to the storage region named above, and the transfer rests on the standard contractual clauses described above. Sentry's own server-side cleaning is switched on in its default form for all seven of our projects — those of the API server, the web server, the reading service, the PDF check, the minifigure matching service, the MCP server and the app; we have added no rules of our own to it and removed none of Sentry's.

Legal basis: Article 6(1)(f) GDPR — for the error report and for the IP address in its transmission alike. The legitimate interest lies in detecting and fixing faults and crashes. The address is not processed for any purpose of its own, and it is not used to recognise you. It is the same basis on which section 3 processes the IP address that every connection to the website necessarily produces. You may object under Article 21 GDPR using the contact details in section 2.

Storage period: 90 days. How long Sentry keeps an error report follows from the plan the organisation is on. Ours is on Sentry's Business plan, for which Sentry publishes a retention of 90 days; on its Developer plan it would be 30. Attachments follow the event they belong to. A shorter period can be set for an individual project and would take precedence; none of our seven projects carries one, so the 90 days applies to all seven alike.

12. Recipients

Personal data is not sold and not passed on for advertising purposes. The recipients at present are Microsoft Ireland Operations Limited, as processor for hosting, database and file storage and — solely at your express request under section 8.6 — for image assessment through Azure OpenAI, and Twilio Inc. (“SendGrid”) as processor for sending e-mail under section 7.3, including the processing in the United States described there. If you have agreed to the audience measurement under section 10, Google Ireland Limited is a further processor for as long as that consent stands; without your consent it receives nothing. If you have agreed to the session recordings under section 10.2, Microsoft Ireland Operations Limited receives the data described there for as long as that consent stands — in that respect not as a processor but as an independent controller; without that consent it receives nothing for that purpose. For the sign-in under section 7.1, Auth0 / Okta, Inc. is a processor, and for the error reports under section 11, Functional Software, Inc. d/b/a Sentry; both are based in the United States and base the transfer on the European Commission's standard contractual clauses, as described in those sections. If you have your collection imported from Rebrickable under section 8.10, Rebrickable receives, once, the credentials you entered for your account there. For the AI-assisted blog texts under section 9, Microsoft Ireland Operations Limited is likewise a processor. Approved event details are public as described in section 8.4; the account link is not. Beyond that, data is passed on only where there is a legal obligation to do so. For the automated checking of content under section 8.12, Microsoft Ireland Operations Limited is a processor as well; that check runs in France. For reading a flyer under section 8.4, Microsoft Ireland Operations Limited is a processor as well. For the forms' anti-spam check under section 8.13, Cloudflare, Inc. receives the data described there. For the place search under section 8.18, Microsoft Ireland Operations Limited (Azure Maps) is also a processor. For push notifications under section 10.4, OneSignal, Inc. is the processor; it is based in the United States (the transfer is set out in section 10.4), and delivery runs through Google (Android) and Apple (iOS). For shipping a prize from the advent calendar under section 8.23, Deutsche Post / DHL receives the delivery address.

13. Storage periods

• Collection data and photos: until deleted by the data subject or until the account is deleted.
• Results of the automated check: as long as the content checked exists, and at the latest until the account is deleted, with the exception stated in section 8.12; the count of monthly checks until the account is deleted.
• Settings on the device: see section 6.1; the app's stores on the device: until you sign out, see section 6.5.
• Account details held by the identity provider (sections 7.1 and 7.2): until the account is deleted, which deletes the Auth0 account with it.
• Audience measurement: up to 14 months from the last interaction for user-level and event-level data at Google, 182 days for the consent cookie on your device — see section 10.
• Session recordings: 30 days for recordings, up to 9 months for heatmap data and for recordings that were marked or selected as a sample, at Microsoft — see section 10.2.
• Event submissions: the state-dependent storage periods in section 8.4.
• Support requests: 24 months after the ticket is closed — see section 8.7, including why the period runs from closure and not from arrival.
• Reports about content: 24 months after the report is decided — see section 8.8, including why the period runs from the decision and not from the filing, and why a report nobody has decided yet is not deleted.
• Administrator actions on user accounts (the audit log): 24 months after the action — see section 8.9, including what remains when the account is deleted. Account details and sign-in history shown to administrators are read live from Auth0 and are not stored by BrickDb.
• Photos for set-number reading (section 8.5) and for the box appearance suggestion (section 8.6): not stored by BrickDb and discarded when the request ends.
• E-mail sent: BrickDb keeps no copy; for the delivery data held by the mail provider see section 7.3.
• Logs at infrastructure level: see section 3.
• Error reports at Sentry: 90 days — see section 11; Sentry does not keep the IP address of the connection that delivered them.
• Performance traces at Sentry: complete for at most 90 days, as a reduced sample for up to 13 months — see section 11.
• Saved photo mosaics (section 8.14): until you delete them or your account.
• Saved brick text signs (section 8.24): until you delete them or your account.
• Jobs for building instructions as a PDF and the PDF itself (sections 8.14 and 8.17): 24 hours from completion, deleted within 48 hours at the latest.
• Copies of photos in the storage for training data (section 8.15): for as long as your consent stands and the photo is stored; deleted the following night after a withdrawal or after the photo or your account is deleted.
• Merchandise contributions and their photo (section 8.16): until your account is deleted; a refused contribution loses its photo at once.
• Store claims and their documents (section 8.20): documents until the decision, at the latest 30 days after the upload; a claim never submitted 30 days, a refused or withdrawn one 180 days after the decision, an approved one while you manage the store.
• Changes you made as a store's manager (section 8.20): until your account is deleted; the change itself stays on the store's page.
• The forms' anti-spam check (section 8.13): nothing is stored by BrickDb.
• Push ID and notification settings (section 10.4): until your account is deleted; the user at OneSignal is deleted with it. At OneSignal, by its own statement: data from the interface and from automated messages 30 days, then deleted.
• Browser subscriptions for web push (section 10.4): until you switch push off in that browser, its push service reports it as no longer valid, or your account is deleted.
• Requests to test BrickDb, and test results with their screenshots (section 8.21): a decided request 24 months after the decision; a result 24 months after its version of the checklist was taken out of use.

When an entry is deleted, the photos belonging to it are deleted with it — including the resized versions described in section 8. Deleted data disappears from backup copies as those expire in the ordinary course, at the latest after 35 days.

14. Rights of data subjects

The following rights exist:

• Access to the data processed (Article 15 GDPR),
• Rectification of inaccurate data (Article 16 GDPR),
• Erasure (Article 17 GDPR),
• Restriction of processing (Article 18 GDPR),
• Data portability (Article 20 GDPR),
• Objection to processing based on Article 6(1)(f) GDPR (Article 21 GDPR),
• Withdrawal of a consent given, with effect for the future (Article 7(3) GDPR).

An informal message to the e-mail address given in section 2 is enough to exercise them.

The right of access under Article 15 can also be exercised directly, without writing to anybody: the account page produces a complete, machine- readable copy of everything stored about you — your account and profile, your collections with their members and the invitations you have issued, the copies in them with their notes, tags, condition, purchase prices and seller notes, individual minifigures and loose parts, your copies of magazine issues and books, your storage places and which copy is kept in which of them, recorded signatures, your wishlist, your contributions towards bag codes and retail barcodes, your event submissions in every moderation state, batches of box photographs you submitted, the entries of the administrators' audit log about your account (section 8.9), every photograph you have uploaded, and your avatar picture if you uploaded one.

What that copy does not contain, and why: your sign-in details at the identity provider (e-mail address, password, sign-in history, registered second factors) — they are held by Auth0, which answers for them itself; invitations other people have sent to your address, because those are their data and not yours; the parts view derived from your copies, because it holds nothing that is not in the copy already; support requests — all of them, because no ticket is linked to an account in this version and we cannot tell which are yours (section 8.7 says how to reach us about one); internal notes about a support request, which are ours rather than yours (section 8.7 again); the short record of a mail to the support address that was not filed as a ticket, which is linked to no account (section 8.7); reports about content, which are linked to no account either, and the notes we wrote while deciding a report about your content (section 8.8); which administrator acted on your account, because that is the administrator's data rather than yours (section 8.9); and the queued notification for an event you submitted, which holds only delivery mechanics and points at the event already listed above.

The right to erasure under Article 17 can be exercised there too. The account page first shows you exactly what will be deleted; once you confirm, it is carried out immediately — your collection, your storage places, your photographs (the files themselves, not just the entries) and your sign-in account at the identity provider. It cannot be undone.

The exceptions are deliberate and explained; event submissions follow section 8.4. Your bag-code contributions are anonymised rather than deleted: what a bag code turns out to be is a fact about a LEGO product that other users established together and rely on, so the contribution stays and the link to you is replaced by a freshly drawn random value for which no account and no mapping exists (Recital 26 GDPR). A copy you added to a collection you share with other people is anonymised rather than deleted in the same way: deleting it would delete other people’s record of a set they share with you, so the set number, the quantity and the condition stay with the collection, while everything personal on it goes — your nickname for it, your notes, your tags, where you kept it, what you paid, what you thought it was worth, and its photographs — along with the link to you, replaced by the same kind of freshly drawn random value. A copy in a collection nobody else is in is deleted outright, because there is no one it would be taken from. And backups continue to follow section 13: deleted data leaves them at their regular expiry, at the latest after 35 days.

The individual steps, a list of what is deleted and what is kept in anonymised form, and the route for somebody who can no longer sign in are summarised on the deleting your account and data page. It is reachable without signing in, and it restates this section rather than adding to it.

Right to lodge a complaint

Independently of that, there is a right under Article 77 GDPR to lodge a complaint with a supervisory authority, in particular in the Member State of habitual residence, of the place of work or of the place of the alleged infringement. The authority competent for the controller is:

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

Additional information for the United Kingdom, the United States and Mexico

United Kingdom: If you live in the United Kingdom, the rights in this section are also yours under the UK GDPR and the Data Protection Act 2018. You can also complain to the Information Commissioner's Office (ICO), Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom, ico.org.uk. We have not appointed a representative in the United Kingdom under Article 27 UK GDPR, because we process data of people in the United Kingdom only occasionally (Article 27(2)(a) UK GDPR).

United States: We do not sell personal data and do not share it for cross-context behavioural advertising – neither “sell” nor “share” within the meaning of the California Consumer Privacy Act and comparable laws of other US states. You request access, correction, deletion and a copy of your data as this section describes: on the account page or with an informal message to the e-mail address given in section 2. Nobody is treated less favourably for exercising these rights.

Mexico: Under the Ley Federal de Protección de Datos Personales en Posesión de los Particulares you have the so-called ARCO rights – access, rectification, cancellation and opposition – and the right to withdraw a consent. You exercise them as this section describes, with an informal message to the e-mail address given in section 2, in Spanish if you prefer. In Spanish: Puede ejercer sus derechos de acceso, rectificación, cancelación y oposición (derechos ARCO) y revocar su consentimiento escribiendo a la dirección de correo electrónico indicada en la sección 2.

15. Obligation to provide data

Providing data is required neither by law nor by contract. Without entries, however, the collection features cannot be used meaningfully; the freely accessible parts of the service are open without any entry at all.

16. Changes and authoritative language version

This policy will be adjusted if the processing or the legal position changes. The version published here at any given time, bearing the date given above, is the one that applies.

The German version is authoritative. The versions in English, French, Dutch, Danish, Italian and Spanish are translations provided for information and have no independent legal effect.