Privacy Policy

Effective date: September 4, 2026

Last revised: October 20, 2026 — the key-value store of your iCloud account also holds, for each installation, its identifier drawn at random and a technical clock boundary for the log, subscriber or not; the backup holds them too (§0, §4, §4.1, §4.3, §4.4, §11, §15).

This is a translation for information. The French version (privacy-policy.md) is the reference text and prevails in case of any discrepancy for users resident in France.

0Summary#

BrickBack has no user account, no sign-up, no password, and never asks for an email address. It contains no analytics tool, no advertising SDK, no behavioral tracker. Your collection stays on your device. The getbrickback.app website, for its part, measures its traffic in aggregate and without cookies (§2.1).

Eight things may leave your device. They are detailed below and you should read them:

BrickBack sells no data, rents no data, and earns no advertising revenue. Store offers use affiliate links: a store may pay us a commission on a purchase made through a link, without the app sending it data that identifies you (§9).

1Who is the controller#

BrickBack is published by an individual (natural person).

2Scope#

This policy covers the BrickBack iOS app, its catalog relay, its price and alert server (§6.4), and the getbrickback.app website (§2.1). It describes what data is processed, what leaves your device, who receives it, how long it is kept, and what rights you have.

It does not cover third-party sites the app may send you to (shops, catalogs). Once you are there, their own policies apply (§9).

2.1The getbrickback.app website — audience measurement#

The getbrickback.app website measures its traffic with Cloudflare Web Analytics, a service of Cloudflare, Inc. The measurement is aggregated: it sets no cookie, assigns no persistent identifier, computes no fingerprint of your browser, and its data is neither sold nor used for advertising.

The data measured is the page visited, the referring page or site, the country, the type of device and browser, and the page's loading performance. URL parameters, whatever follows a “?”, are not recorded.

Legal basis: our legitimate interest in knowing how much the website is visited and how well it performs (Art. 6(1)(f) GDPR). Cloudflare keeps detailed measurements for seven days, then in aggregated form only; the statistics remain available for six months.

This measurement concerns the website only. The app contains no analytics tool (§14).

3The principle: no account, no profile#

BrickBack never asks you to create an account. There is no sign-up, no login, no password, no email collected, no social sign-in. No user-authentication screen, service or network call exists in the app.

The direct consequence is that we cannot identify you by name. We do not know who you are and cannot link your use of the app to your civil identity. That does not mean no personal data is processed — the IP address described in §6 is personal data under the GDPR. It means the processing is pseudonymous, and that exercising your rights follows the specific route set out in §12.

Price alerts do not change this. If you enable them, your registration on our server uses an identifier drawn at random by the app and the device notification token (§6.4): no name, email address or Apple Account identifier.

iCloud synchronization does not change this. It addresses the Apple Account already signed in on the device: the app never asks for your Apple Account identifier, does not read it and does not keep it. It places the data in a space to which Apple holds the key and we do not (§4.2).

4What stays on your device#

Almost everything you create in BrickBack never leaves the iPhone.

⚠️ What is not in this table: the scan itself. The app keeps no scan history. No database row, no copy of the photo on disk: the identified part is shown, and you tick it against a set, add it to your loose bricks, or do nothing. What gets written is the action you take — a tick or an addition, dated, in the log of §4.4 —, never a memory of what you looked at: no photo, no confidence score, no trace of a scan you did nothing with. The log does not even distinguish a part added from the scanner from one entered by hand. See §11.

This data is protected by Apple's operating-system encryption, at the app's default file protection level.

Uninstalling the app erases all of it from the device, with one exception: the copy of the installation identifier kept in the Keychain, which iOS may retain after uninstall and which the next install replaces (§4.4). None of this data is copied to any server of ours, with one exception that you control: enabling price alerts sends the numbers of wishlist sets with comparable target prices and those prices to our price and alert server (§6.4).

Three copies may nonetheless outlive it, and none of the three is ours:

• Your device backup, if you have enabled it in iOS. It carries the app's database like any other app's. It applies to everyone, subscriber or not, it is performed by Apple, under Apple's policy, and we have no access to it.
• Your private iCloud database, if you subscribe to the Pro plan: the synchronization in §4.2 has placed your sets, progress, loose bricks, action log, wishlist and collection organization there. Uninstalling the app does not erase it; §4.2 says how to.
• The key-value store of your iCloud account, which holds the list of set numbers already counted by the free-version limit (§4.3). It applies to everyone, subscriber or not, and that is exactly its purpose: uninstalling must not reset the limit. It also holds, for each installation, its identifier and its clock boundary (§4.3). It contains only set numbers, installation identifiers and their boundaries.

⚠️ These are three distinct mechanisms, often confused because they share a brand name. §4.2 and §4.3 keep them apart.

4.1Taking your data with you#

The app lets you export your entire collection to a readable file (documented JSON format) and import it back on another device. This feature is free and requires no account. It is the practical way to exercise your right to portability (§12.1). It is a backup you create yourself, whether or not you have enabled the device backup described in §4. Pro adds iCloud synchronization (§4.2), which does not replace it. Restoring a file on the free plan remains subject to the limits on sets (§4.3) and different loose pieces (§4.4); previously counted items can be restored without being counted again.

Use “Back up my data” in Settings, under “IMPORT & EXPORT”; “Restore backup” imports the file.

The file carries your sets with their contents and progress, the saved rows of your old shopping list, your loose bricks and taken-apart sets, your wishlist and collection organization (notes, “Built” status, tags, dated “Bought new” and “Imported” labels), and the log of your actions (or, if it has been condensed, the summary that replaces it and the actions that follow it, §4.4) and the list of parts already counted by the free loose-bricks limit. The log appears there with the installation identifier that each of your actions carries (§4.4). The file also carries this installation's identifier, its clock boundary, and the boundaries of the other installations it knows about (§4.3). It does not carry the list of sets of §4.3, which lives in iCloud. It is created at your request, and you alone decide where it goes.

4.2iCloud synchronization — Pro plan#

The app can carry your sets, progress, loose bricks, wishlist and collection organization from one of your devices to another. It is reserved to the Pro plan: on a free account the gate closes before any iCloud object is created, and no request is ever made. The log of your actions is written on the device in every case (§4.4); it is sending it that is reserved to the Pro plan. Moving to the Pro plan therefore sends the whole log, from the first action it contains.

What travels, and nothing else:

Where it goes. Into your own private iCloud database — the container iCloud.app.brickback.ios, under your Apple Account. That is the point which decides everything else: a private database is not accessible to the publisher. We cannot read it, copy it or browse it, and we run no server that receives it. Apple provides the transport and the storage, under its own privacy policy, and thereby becomes a recipient (§13).

When it happens. At app launch, on demand from the Settings screen, and whenever the system itself notices changes. There is no switch inside the app: subscribing to the Pro plan is enough to open it.

If you change iCloud account on the device, the app republishes your whole log, and its summary if there is one, into the new account's private database: that is how that account gets back your loose bricks and your progress in full.

A rare case, stated in advance. If two subscribed devices have each condensed their log (§4.4) under different iCloud accounts and then meet on the same account, their two summaries cannot be merged without risking counting a part twice. The one in iCloud then prevails, and what only the device knew is lost. The app tells you so, and offers to export a backup (§4.1) before applying anything.

How to stop it. Three ways, all outside the app:

• iOS Settings, in the iCloud section of your Apple Account: there you can stop BrickBack from using iCloud and delete the data it has placed there. That control belongs to the system, and it is the only one that erases the remote copy.
• Signing out of iCloud on the device: synchronization stops immediately.
• Letting the subscription lapse: at the next launch the gate closes and nothing more leaves.

In all three cases, nothing is erased from your device. Synchronization never deletes locally what it has not seen disappear from the server.

⚠️ Not to be confused with your device's iCloud backup. These are two distinct mechanisms, and only the name is shared. The device backup is an iOS setting; it applies to everyone, subscriber or not, it carries the app's database exactly as it carries any other app's, and we have no access to it (end of §4). The synchronization described here belongs to BrickBack, is reserved to the Pro plan, and carries only what the table above lists.

Your reference backup remains the export in §4.1.

4.3The free-version counter and the log boundary — subscriber or not#

The free version tracks two sets in total, and they are counted once and for all: removing a set from your collection does not free up its place. So that this limit does not start again from zero at the first reinstall, the app keeps the list of set numbers already counted in the key-value store of your iCloud account.

What the counter writes there, and nothing else: a list of set numbers — 10276-1, 75192-1 — capped at 5,000 entries. Not your progress, not your set contents, not your shopping list, no photo, and nothing that identifies you.

The log boundary. The same store holds a second entry. For each installation of BrickBack on your account, it pairs two values:

• its installation identifier, drawn at random (§4.4);
• a technical clock boundary: a number taken from the log's clock. It corresponds to the time, to the millisecond, of the last action that installation knew about before its update. It is zero on a new installation.

It serves a single purpose: knowing, across devices on the same account, which log actions precede the app update. An earlier action is thus never read as a take from your loose bricks. It contains no action, no part, no set, no photo, no device name.

It is written subscriber or not. The app publishes it at launch, on returning to the foreground, and when iCloud signals a change. It writes only if the store does not already hold the same values. A boundary never increases. The app removes no entry: the identifier of an uninstalled, reinstalled or restored installation remains there, with its boundary.

⚠️ This is not the synchronization of §4.2. The two mechanisms share the iCloud name and nothing else:

Where it goes. Into your own iCloud space, under your Apple Account. As in §4.2, we have no access to it: we cannot read it, copy it or browse it, and no server of ours receives it. Apple provides transport and storage, under its own privacy policy, and is a recipient on that basis (§13).

If you have no iCloud account, or have turned it off, the app works exactly the same: the counter and the boundary then stay on the device alone, and nothing leaves.

How to erase it. From iOS Settings, under the iCloud section of your Apple Account, by deleting the data BrickBack has placed there — the same control as in §4.2. That control belongs to the system, and it is the only one that erases the remote copy.

Loose bricks have their own free limit (§4.4), and that list does not go through this store: it stays on the device.

4.4Your loose bricks and the log of your actions#

Your loose bricks. The parts you add to "My loose bricks" are recorded in the local database, and nothing else: for each part and each color, the quantity stored. No photo, no storage place, no location. Sets you may have pieces for are computed on your device, from the local catalog: no request goes out to obtain them.

The log of your actions. So that two devices always count the same parts, every action that touches your loose bricks or a set's progress is written to a log, once and for all: adding, correcting a part or a color, removing, emptying, taking from your loose bricks, ticking or unticking, taking a set apart, resetting it, deleting it — with or without adding its parts to your loose bricks —, undoing. An action in the log contains exactly:

• an identifier drawn at random;
• its date and time, to the millisecond, and a counter that breaks ties;
• its kind (add, take, take apart…);
• if it concerns a set: its number, and the date you started tracking it;
• for an undo, the identifier of the action undone; for a take-apart, its mode (add to loose bricks, or keep in its box); for an addition, the "counted by the free limit" mark;
• for each part touched: its number, its color, the quantity, and whether it concerns your loose bricks or a set;
• the installation identifier that wrote it, and its sequence number within that installation.

Nothing else: no photo, no location, no device name, no account. On the device only, the app also notes when it received each action and where it came from (made on this device, received from iCloud, imported from a backup). The first launch of the version that introduces the log carries your existing progress and completion dates into it, without any installation identifier.

⚠️ The log is never rewritten. Emptying your loose bricks, removing a set or undoing a tick adds an action; the earlier actions remain. That is what guarantees a part is never counted twice from one device to another, and it is also what you should know: the dated list of your actions stays on the device after the parts have left the screen, and in your private iCloud database if you subscribe to the Pro plan.

The summary, and the actions that leave. On a Pro account whose synchronization is working, once the log holds at least 5,000 actions older than thirty days, the app condenses them — at most once a day — into a summary: the state of your loose bricks, your progress and your sets at that date. Once your private iCloud database holds that summary, the actions it covers are removed from the device, and the iCloud pages that held nothing but such actions are deleted. A free account never condenses: its log stays whole on the device.

The installation identifier. It is a number drawn at random at the first launch of the version that introduces the log. It derives neither from your device, nor from your account, nor from you: it only serves to name the pages of the log, to number your actions, and to link its clock boundary to its installation (§4.3). It is kept in three places — the device's Keychain, restricted to this device and never synchronized; a file the app excludes from backups; the local database. As soon as those three copies no longer agree — reinstall, restore from a backup, new device —, a new identifier is drawn, and the old one writes no further action. It accompanies each of your actions wherever the log goes: into your private iCloud database if you subscribe, and into the export file of §4.1. Subscriber or not, it is also written to the key-value store of your iCloud account, with its boundary (§4.3). The old identifier remains there after it is replaced. It goes to no other recipient, and in particular not to our relay (§6.2).

The free loose-bricks limit. The free version stores 30 different pieces, counted once and for all, like the sets of §4.3. The list of parts already counted — part number, color, date it was counted — lives in the local database only: it does not go to the iCloud key-value store. It is included in the export of §4.1. An addition made in the free version carries the "counted" mark; if you later move to the Pro plan, that mark travels with it, and the list is thus rebuilt on another device.

Taking apart, resetting, deleting. These three actions write nothing but a log entry — with the parts added to your loose bricks, if any — and the state the app derives from it: set taken apart, completion date cleared, set removed.

5Scan photos — please read carefully#

5.1Nothing is recognized on your device#

All part identification happens online. The app ships no artificial-intelligence model of any kind: no model file is bundled, and no local recognition framework is used. Without an Internet connection, scanning does not work.

Any statement to the contrary — identification happening on your device, artificial intelligence contained inside the app, "nothing leaves your phone" — would be false. No such wording belongs in this document, or on any of our public pages.

5.2Where the photo goes#

When you photograph a part, the image is compressed to JPEG and sent directly from your device to the Brickognize API (api.brickognize.com). It does not pass through our technical relay.

What is transmitted: the image itself. No account identifier, no device identifier and no personal filename accompanies it; the file is sent under a generic name. Your device's IP address is, by the nature of Internet communication, visible to the recipient.

⚠️ A photo contains more than its subject. If the background of your shot shows a room, a face, a document or a screen, that travels with the image. Frame the part tightly.

5.3What Brickognize reserves the right to do with your photo#

This is the part this policy has a duty to state plainly.

The terms of use published by Brickognize (brickognize.com/terms-of-service/, read on 26 August 2026) provide that any content submitted to the service grants it a worldwide, non-exclusive, royalty-free, transferable, sub-licensable, irrevocable and perpetual license to use, store, reproduce, modify, distribute, publish, process into derivative works, train machine-learning models, or otherwise exploit that content.

In plain terms, without softening it:

• Your photo may be kept indefinitely by that third party.
• It may be used to train its models.
• The license is irrevocable: once the photo has been sent, neither you nor we can compel its deletion by that provider as of right.
• We have no contract with that provider, no data-processing agreement, no service-level commitment and no power to instruct it. The service is free and provided "as is". Its terms designate Polish law.

In other words, for this specific function, Brickognize is not our processor: it processes your photo for its own purposes, as a separate controller. We cannot promise you that your photo stays with you, and we do not promise it.

5.4What we get, and what you can do#

From Brickognize we receive the result of the identification — a candidate part number, the part name, the proposed colors, a confidence score — and the address of a reference image. We do not receive your photo back, we do not store it on any server, and we do not use it for any training.

⚠️ That image address triggers a second request, to one more host. To show you the part the reading recognized, the app fetches that image from the provider's image storage — storage.googleapis.com, operated by Google. It is a destination distinct from the recognition API, it sees your device's IP address, and the part reference and its color are written into the address requested: what you have just scanned can be read from it. No image of yours is sent there — that request only asks for a catalog picture. The detail is in §7.

What you can do, concretely:

• Do not scan. Every other function of the app (set tracking, missing-parts lists, catalog lookup) works without sending any image.
• Frame tightly, on a neutral background.
• Read the provider's terms — https://brickognize.com/terms-of-service/ — before your first scan.
• Refuse the transfer when the app asks you, or withdraw your decision later in the settings (§5.5).

5.5Legal basis#

Sending the image is necessary to perform the function you requested (GDPR art. 6(1)(b)). The provider's reuse for its own purposes — training in particular — goes beyond that performance.

This is why the app asks you beforehand, not afterwards. Before your very first photo, a screen sets out who receives the image, why, and what that third party reserves the right to do with it. No image is sent until you agree. Refusing is a normal path: set tracking, manual entry, missing-parts lists and the catalog keep working. You can withdraw your agreement at any time in the app's settings, with immediate effect; if the wording of that notice changes, it is shown to you again.

6The technical relay#

6.1Why a relay exists#

The catalog is prepared in advance, signed and published through a relay that we operate on Cloudflare Workers. The app downloads it from that relay; no third-party database access key is placed in the app.

The relay serves only the catalog. New-set prices and price alerts use a separate server (§6.4).

6.2What the relay receives#

The catalog relay receives no device identifier. A previous version of the app generated one — a random number kept from one launch to the next — and attached it to every request. The relay never read it, so it served no purpose. It has been removed: the app no longer generates one, and any that remained on your device is erased on the first launch of the version carrying that change.

What the IP address is used for. Solely to count requests, so as to prevent any single caller from exhausting a service whose capacity is shared by everyone. The limits in force are 120 requests per minute for the availability check, 60 for the catalog manifest and 10 for the catalog download. That counting feeds no profile, no usage statistics and no analytics.

Legal basis: legitimate interests (art. 6(1)(f)), namely the security and availability of the service. That interest is proportionate: the address is never cross-matched with any identity, serves nothing but a counter, and the counter itself is not kept beyond its window.

What the relay does not receive. The sets in your collection, your progress, “Pieces to buy”, the saved rows of your old shopping list and your part photos never pass through it. The catalog is downloaded in full and then searched on your device: the relay therefore does not see what you look up in it.

6.3Logging#

The relay's code keeps no browsing log: a request served normally leaves no trace in it. The hosting platform's logs, on the other hand, do exist and depend on its settings.

The relay is hosted by Cloudflare, Inc., 101 Townsend Street, San Francisco, California 94107, USA — telephone +1 888 993 5273. The relay runs on its Workers service; the catalog it serves is stored on its R2 service and the rate-limit counters on its Durable Objects service.

What the relay's code writes. A single line, and only when a request is refused: it carries the status code, the reason for the refusal and the name of the route called. Your IP address is not in it — that omission is deliberate. A request served normally writes no line at all.

What the relay does with your IP address. It reads it to spread requests across rate-limit counters, one counter per address and per route. That counter holds only a request count and the start time of the current window; it is erased automatically at the end of each one-minute window. No history is derived from it, and the address is cross-matched with nothing.

The hosting platform's logs depend not on this code but on Cloudflare's settings. The relay runs on that provider's free plan, which caps their retention at 3 days. The platform may record request metadata of its own accord — timestamp, route called, response code, IP address — without the relay's versioned configuration asking for it. They are accessible to Cloudflare and to the account holder, that is, the publisher.

6.4The price and alert server#

What it does. A second server, separate from the catalog relay, provides Pro's price comparisons and price alerts in France and Germany only. Both the App Store account country and the iPhone region must be France, or both Germany. It runs for BrickBack on Cloudflare (Workers, a D1 database and R2 storage). Each night it records new-set prices at the compared stores; each day it publishes a country-specific file for “Sets for less right now”. If you have enabled alerts, it compares those prices with your target prices each morning and asks Apple to send you a notification.

What leaves the device for prices and alerts, and what never does:

Price recording contains no user data. The server requests offers from Affilizz using only the compared sets and country. It keeps 35 days of recorded prices to establish the lowest price of the previous 30 days.

What a registration stores. Its identifier; a hash of the secret (the secret itself is never stored); latest revision number; notification token and environment; country; Pro expiration date and auto-renewal status; creation, last confirmation and last notification dates; and, for each active alert, the set number, target price, currency and status (below your target price since a given date, notified on a given day).

Retention (see §11):

• Turning alerts off deletes the registration and its active alerts. The same applies when the app detects that Pro has ended, the device country is unsupported, or Apple reports an invalid token. The app requests deletion immediately. Offline, or if the server does not respond, the request stays on the device and is sent when the network returns or the app next opens. If it can no longer be sent, for example after uninstall, deletion still occurs after 60 days without reconfirmation.
• The app reconfirms the registration weekly. After 60 days without reconfirmation, it is deleted; sending a notification does not extend this period.
• Notifications stop 3 days after the Pro expiration date known to the server. If the app reported automatic renewal, notifications can continue for 31 days after that date, plus the same 3 days, since renewal can occur without opening the app. The 60-day limit without reconfirmation still applies.
• After deletion, only the deleted identifier and deletion date are kept for 60 days, to prevent reuse.

Evidence of comparisons. Recorded offers, the reasons for excluding offers and published files are archived for 6 years to substantiate published prices and comparisons. This archive contains no personal data.

Logs. The server records refused requests and stages of its daily work, without IP addresses, tokens, set numbers, registration identifiers or keys. It uses your IP address to limit requests per minute in a counter kept only in memory. Hosting-platform logs depend on Cloudflare's settings, as in §6.3.

Legal basis.

• Price alerts rely on your consent (Art. 6(1)(a) GDPR), given on the activation screen and through iOS notification permission. You can withdraw it at any time by disabling alerts, which deletes your registration. Refusing or withdrawing notification permission has the same effect.
• Price comparisons and daily files perform the service you request when opening a set's table (Art. 6(1)(b)).
• Request limits and the evidence archive serve our legitimate interest (Art. 6(1)(f)) in keeping the service available and substantiating published prices and comparisons.

7The brick catalog and the images#

BrickBack needs reference data: set names, part lists, colors, images. This section lists every host the app contacts to obtain them.

These requests describe what you are looking for, not who you are. None carries an account identifier.

Legal basis: performance of the service you requested (art. 6(1)(b)).

8Subscriptions#

If you subscribe, two third parties are involved.

Apple collects the payment through the App Store and handles renewal, cancellation and refunds. No payment method, card number or bank details ever pass through BrickBack or are disclosed to us. From Apple we receive only aggregated, anonymous sales data.

RevenueCat is the provider that verifies the validity of your purchase and determines whether paid features should be unlocked. On our behalf it processes an anonymous user identifier, the platform, and the technical transaction history (product purchased, start and renewal dates, status). It acts as a processor under the GDPR.

The last known subscription status is cached locally on your device so the app remains usable offline.

Legal basis: performance of the subscription contract (art. 6(1)(b)).

9Merchant links#

BrickBack may offer to open an external page to obtain a piece or a set — the manufacturer's store, a parts marketplace, a specialist catalog or an online store — or to view the manufacturer's building instructions.

There are two kinds of links.

• Piece links and building instructions use direct addresses to the manufacturer's site, with no tracking parameter or partner identifier. We receive no commission.
• New-set offers — a set's store comparison and “Sets for less right now”, available with Pro in France and Germany — use affiliate links. They pass through redirect.affilizz.com, operated by Affilizz, before reaching the store. Affilizz records the visit through the link, and a store may pay us a commission on a purchase made through it. The commission changes neither the order of offers — a set's table sorts by price, and “Sets for less right now” by relative price difference, largest first — nor the price you pay. The app opens the link as supplied by Affilizz after checking its host; it adds no parameter, user identifier or device identifier.

What this means for your data:

• Links open in the system browser, outside the app. We see neither the page reached nor what you do there.
• For affiliate links, Affilizz and the store may set their own trackers in your browser, under their own policies, to attribute a purchase to the link. We receive no information identifying you or your purchase; an affiliate network may provide commission amounts.
• Once you leave the app, Affilizz's and the merchant's terms and privacy policies apply.

Before you tap a link, displaying a set's store comparison requests offers from Affilizz. §6.4 describes exactly what is sent and what is never sent.

10Permissions requested#

⚠️ These are the only two permissions the app requests.

BrickBack does not request access to your photo library, your location, contacts, microphone, calendar, health data, or cross-app advertising tracking.

11Retention periods#

There is no period to state for your scans, because nothing is left of them other than what you did with them: a part ticked against a set, or added to your loose bricks. The app used to write two things at every reading: a database row — part number, color, confidence, date — kept for 90 days, and a copy of the photo in its temporary directory, kept for 7 days. Neither was ever read back: no screen displayed them, the sets that are missing a part are computed from your inventory and your progress, and the export of your data did not return them.

So they are no longer written at all. This is the principle of minimization (art. 5(1)(c) GDPR) taken at its word: data that serves no purpose is not better retained, it is not collected. Existing installations lose their old rows on update, with nothing to do on your part.

What the app keeps of your scan, if you tick the part or add it to your loose bricks, is that action: the set's progress or the loose-bricks quantity, and the dated log entry (§4.4) — nothing of the reading itself. It is yours, on your device, under the terms of §4.4.

12Your rights#

The GDPR gives you rights of access, rectification, erasure, restriction, objection and portability, and the right to withdraw consent.

How you exercise them depends on who holds the data. Here is the honest picture:

12.1Data on your device#

It is entirely under your control, without asking us:

• Access: your sets, your progress and your loose bricks are displayed in the app; the detail of the log of your actions is in the export file (§4.1).
• Rectification: editable directly (progress, set contents, loose bricks, wishlist, notes and tags). Changes to progress and loose-brick quantities are recorded in the action log (§4.4). Wishlist and collection organization data keep their current values and latest revisions, rather than a log of every edit.
• Erasure: delete an item in the app, or uninstall the app to erase everything from the device at once. ⚠️ Deleting a set or emptying your loose bricks removes them from the screen, but does not erase the actions already written to the log (§4.4): only uninstalling erases them from the device. ⚠️ If you subscribe to the Pro plan, a copy of your sets in your collection, your progress, loose bricks, action log, wishlist and organization remains in your private iCloud database: it is deleted from iOS Settings, in the iCloud section of your Apple Account (§4.2). We cannot do it for you — we have no access.
• Portability: “Back up my data” in Settings exports your entire collection to a documented JSON file that can be imported on another device (§4.1). The feature is free and requires no account; restoring follows the free limits described in §4.1.

Not to be confused with exporting a shopping list in a marketplace format: that one is for ordering, and is not an export of your personal data.

12.2Data processed by the relay and by providers#

Write to the address in §1. We respond within one month.

Your price alert registration can be deleted without writing to us: turn alerts off in the app to request deletion from our server, together with all its active alerts (§6.4). The app shows the sets with active alerts and their status, giving you access to that data. Changing a target price in your wishlist corrects it on the next transmission.

⚠️ A limitation you should know about: we cannot identify you by name (§3). For a request about an IP address, you would need to provide that address and the relevant time. The app does not display your public IP address, and reinstalling it does not reset that address. If we cannot identify the data concerned, we will tell you, as Article 11 GDPR allows.

12.3Photos sent to Brickognize#

You must contact that provider directly; its contact details appear in its terms of use. We have no power to instruct it (§5.3) and therefore cannot usefully relay an erasure request. This is a real limitation, and it is why §5 exists: so that you can decide, with full knowledge, before sending an image.

12.4Complaints#

If you believe your rights are not being respected, you may lodge a complaint with a supervisory authority. In France, the CNIL — 3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07 — www.cnil.fr. If you live in another EU country, the competent authority is the one in your country of residence.

13Transfers outside the European Union#

14What BrickBack does not do#

The app contains no analytics tool, no advertising SDK, no behavioral tracker, no third-party crash-reporting tool, and does not request cross-app tracking permission. Affiliate links (§9) do not change this: the app adds no user or device identifier.

We do not sell, rent or trade any data. We build no advertising profile. We carry out no automated decision-making producing legal effects concerning you.

Children. BrickBack has no social feed or messaging service and collects no identity data. Notes and wishlist content are kept privately; sharing them uses your device's sharing options. It is not directed at children specifically and does not attempt to identify them. A parent letting a child scan parts should have read §5.

15Apple privacy manifest#

The app contains the PrivacyInfo.xcprivacy privacy manifest that Apple requires. It declares exactly what this section sets out.

Required-reason APIs in the manifest:

Data types declared as collected:

Why alert registration data is linked. Apple treats data attached to a device identifier, even a random one, as linked: active wishlist alerts and target prices are kept with the notification token and registration identifier. None is used for tracking in Apple's sense: none is combined with data from other companies or sent to a data broker.

The iCloud synchronization of §4.2 adds nothing to this list, and the reason matters. Data placed in the private database of the user's own iCloud account is not "collected" in Apple's sense: the publisher has no access to it, cannot read it, and it remains under the user's account. Apple treats this as storage on the user's behalf, not as collection by the developer. ⚠️ This holds only while the database stays private: were a record ever to move to a public or shared database, the answer would change entirely and this paragraph would become false.

The three values synchronization writes to local preferences — engine state, date of last success, date of the last log condensation — fall under the CA92.1 declaration already made above.

The log of §4.4 adds nothing either. Its pages and its summary go into the same private database as the sets and the progress: the reasoning above applies, including to the installation identifier that accompanies each action — a number drawn at random, readable only from the user's own iCloud account and from the files the user exports. The Keychain, where a copy of that identifier is kept, is not on the required-reason API list.

The counter and the boundary of §4.3 add nothing either. They use NSUbiquitousKeyValueStore, which is not on Apple's required-reason API list: nothing to declare on that basis. What they write — set numbers, installation identifiers drawn at random and their clock boundaries — goes into the iCloud space of the user's own account, under their Apple Account, out of the publisher's reach. The reasoning of the previous paragraph applies word for word, and the "App Privacy" questionnaire is unchanged.

Data we do not collect: no contact data, no location data, no advertising identifier, no usage data for analytics. Server-side price recording contains no user data, and daily files are requested by country only. Nothing is used for tracking in Apple's sense, so NSPrivacyTracking is false and NSPrivacyTrackingDomains is empty. The App Store's privacy labels report the same five data types: device identifiers and user content (wishlist sets with active alerts and their target prices) are linked to you; the other three types are not. None is used to track you.

16Changes to this policy#

Any substantial change will be signaled in the app and published at the address where this policy is hosted, with a new effective date. The applicable version is the one in force at the time of your use.

17Trademark#

LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this app.

BrickBack is independently developed, without sponsorship, authorization or endorsement from the LEGO® Group, Rebrickable, Brickset, Brickognize, Affilizz or any marketplace. Affiliate commissions for new-set offers are described in §9. Building bricks compatible with LEGO® bricks, their names and their reference numbers are cited for strictly descriptive purposes. The app uses none of the LEGO® Group's logos, typefaces or official imagery.