Privacy Policy

1. In brief

BrickDb is a private fan project with no ad banners and no tracking. This policy describes the data that is actually processed — not what such texts usually say.

• There is no analysis of usage behaviour. No analytics, tracking or advertising services are embedded.
• Opening a page establishes no connection to any third party. Fonts, too, are held on our own server.
• Photos are visible only to the person who uploaded them. Embedded metadata — including GPS coordinates — is removed during processing.
• Nothing is stored on the device before a setting has been actively chosen. That is why there is no consent banner.

2. Controller

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

Thimo Buchheister
Bergstrang 105
49479 Ibbenbüren
Germany
Telephone: +49 (0) 5451 - 893 922-1
E-mail: thimo@brickdb.net

No data protection officer has been appointed; the conditions of Article 37 GDPR and of section 38 of the German Federal Data Protection Act (BDSG) are not met.

3. Visiting the website

When www.brickdb.de or 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.

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.

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.

Opening a page therefore establishes no connection to any third party and transmits no IP address to any third party.

6. Storage on the device

BrickDb sets no cookies for analytics, marketing or tracking purposes. The only thing stored is what records a deliberately chosen setting.

6.1 What is stored

Both entries contain nothing but the value last selected. They contain no identifier and nothing from which a person or a device could be recognised. Both are first-party storage; no third party has access to them.

6.2 Why no consent is required

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

A setting that is remembered on express request is therefore strictly necessary in order to provide the service requested. A consent banner is accordingly not required and is deliberately not used.

Objection and deletion: Both 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.

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

7. User account

7.1 Signing in

A sign-in procedure is currently not available. No account can be created, and no sign-in data is processed. For as long as that is so, the collection features are not offered publicly.

Once sign-in is introduced, it will run via the identity provider Auth0 (Okta, Inc.) through a tenant in the European Union. This policy will be extended accordingly before it goes into operation; without that extension the procedure will not be put into operation.

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.

Legal basis: for first name, last name, about text and country, 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.

8. Collection data and photos

The following statements describe the processing that takes place once the collection features are usable with sign-in (see 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.

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

Uploaded photos are shown to the person who uploaded them and to no one else. They are not published, not made accessible to other users, 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 13, 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 community event information (Article 6(1)(f) GDPR). You may object to processing based on legitimate interests using the contact details in section 1. 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 image is decoded solely in process memory to propose the printed set number. It is not stored, logged or used to train models, is not sent to a third party, and is discarded when the request ends. Legal basis: Article 6(1)(b) GDPR — this processing provides the reading you requested.

To keep that compute-intensive service available, BrickDb permits six requests per originating IP address in a rolling minute. The address is held only as a key in one web process's memory; it is never logged, persisted or disclosed. After one minute it no longer affects a decision and is removed when that address returns or request-driven cleanup needs room. At most 1,024 address keys are held; 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 sound, secure 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.

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, advertising, profiling

None of this takes place. No analytics services, no advertising networks, no social plug-ins and no error reporting services are embedded. There is no automated decision-making, including profiling, within the meaning of Article 22 GDPR.

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.

11. Operational monitoring

The application is instrumented with OpenTelemetry. This data is exported only if a destination is expressly configured; in operation no such destination is configured, so telemetry data does not leave the process and no third party receives it. Calls to the status endpoints are excluded from recording. Should a monitoring service be connected in future, this policy will be extended beforehand.

12. Recipients

Personal data is not sold and not passed on for advertising purposes. The only recipient at present is 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. With the introduction of the sign-in procedure (section 7), Auth0 / Okta, Inc. will be added as a further processor. Approved event details are public as described in section 8.4; the account link is not. Beyond that, data is passed on only where there is a legal obligation to do so.

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.
• Event submissions: the state-dependent storage periods in section 8.4.
• 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.
• Logs at infrastructure level: see section 3.

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, your collection with its notes, tags, condition, purchase prices and seller notes, your bag-code contributions, your event submissions in every moderation state, every photograph you have uploaded, and your avatar picture if you uploaded one.

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 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. Collections cannot yet be shared with anybody, so today every copy of yours is deleted outright; this describes what happens once they can be. And backups continue to follow section 13: deleted data leaves them at their regular expiry, at the latest after 35 days.

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 English version is a translation provided for information and has no independent legal effect.