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.
• Without your consent, opening a page establishes no connection to any third party. Fonts, too, are held on our own server.
• 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.
• 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 decision about the audience measurement at any time, at the foot of every page.

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, which Amazon store is linked 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.

The one exception is the audience measurement described in section 10, and it is not a qualification of that sentence but its condition: Google's script is loaded only after you have agreed in the consent banner. Until you have agreed or refused, nothing of Google'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. None of the analytics cookies is set before you agree.

6.1 What is stored

The first five entries contain nothing but the value last selected. They contain no identifier and nothing from which a person or a device could be recognised. All five 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 runs is decided by the server before the page exists.

The sixth entry 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 next two entries 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.

The last entry is the analytics cookies from section 10. They are set only after your consent and carry a random identifier by which repeat visits from the same browser are recognised.

6.2 Why no consent is required for anything but the analytics cookies

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 Analytics cookies — only after consent

Section 25(2) no. 2 TDDDG does not apply to the audience measurement's cookies: measuring reach is not necessary for the service you asked for, and the site works completely without it. They therefore fall under section 25(1) TDDDG and are set only once you have agreed in the consent banner. The banner appears on the first page you open and offers agreeing and refusing as two buttons of the same size, side by side — either is 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. No copy of your collection is kept on the device, and no changes are held back for later transmission.

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. Three ways are offered: an account with an e-mail address and a password, signing in with an existing Google account, or signing in with your Apple Account ("Sign in with Apple"). 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 or Apple has no password at Auth0 at all — the credential then lives at Google or Apple, 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.

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. 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.

Legal basis: for first name, last name, about text, country and the language chosen, 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 (both section 8.8). There is no newsletter and no advertising mail.

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, and both report mails in section 8.8. 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. Your storage places belong to you, not to a collection: only you can create, change or assign them. Where a copy in a shared collection is kept is shown, read-only, to the members whose role in that collection is Owner or Editor; members with the Reader or Insurance role never see it, and a published collection never shows it (section 8.1a). If you delete your account (section 14), your storage places are deleted, and the place is removed from every copy that named one first — including a copy that stays in a collection shared with other people.

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.

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, not passed on to third parties and not used to train models.

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.

Who can see it. An avatar is stored so that it can be shown beside your name. BrickDb currently has no screen on which one person sees another person's profile, so today only you see yours. 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.

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.

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. 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 Box appearance suggestion from a photo

Separately from set-number reading, you can expressly ask for a suggestion of the visible condition of a retail box in a photo. Only when you have requested that assessment and confirmed the request does BrickDb send 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 image is re-encoded, stripped of all metadata and reduced to at most 1,024 pixels on its longer side. The connection is made by the server, not by your browser; opening a page never triggers it.

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 itself stays stateless: BrickDb does not store the photo or the result, does not log either, and neither is used to train models; both are discarded when the request ends. The result is an experimental, uncalibrated suggestion about the visible condition of the box alone — there is no measured accuracy, it says nothing about contents, seal or completeness, it writes nothing into your collection, and you expressly accept or replace it yourself. Please photograph the box only: no people, addresses or other personal details, and only images you are entitled to submit.

Legal basis: Article 6(1)(a) GDPR — your consent, given with each individual request. It is voluntary; without it no photo is sent and the condition question remains one you answer yourself. You withdraw it for the future by not requesting another assessment. It is not consent to training; any later, separately revocable opt-in would be its own declaration.

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.

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.

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). 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, and an optional e-mail address. 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, 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 and an address at most 254; 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, that no 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 do not write back by ourselves. Filing a report starts no correspondence: there is no confirmation e-mail, no status page, and no message when a report is decided. The address is there so that a person can come back to you if the report cannot be acted on without asking you something, and it is used for nothing else. What you get 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.

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.

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. The automatic events Google calls "enhanced measurement" are also on: scroll depth, site search, file downloads, video interaction 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.

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. 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 foot of every page there is an "audience measurement" section with a button that reverses your decision — one click, 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. 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.

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 that LEGO runs itself, and 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. 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 bookseller Hugendubel, whose prices BrickDb takes from a Tradedoubler product data feed, 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, 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. 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.

Amazon. As an Amazon Associate I earn 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.

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 four places: the API server, the web server, the reading service described in section 8.5 and — unlike everything else in this section — the app on your device. In all four 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 four 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 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 four 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 and the API 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 and the reading service 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 5 %. 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 and the reading service 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. 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 four projects — those of the API server, the web server, the reading service 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 and the reading service 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 four of our projects — those of the API server, the web server, the reading service 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 four projects carries one, so the 90 days applies to all four 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. 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. 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.

13. Storage periods

• Collection data and photos: until deleted by the data subject or until the account is deleted.
• Settings on the device: see section 6.1.
• 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.
• 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.

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

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.