Hazely Privacy Policy

1. Who we are (controller)

For the purposes of the EU General Data Protection Regulation 2016/679 (GDPR) and the Dutch Uitvoeringswet AVG (UAVG), the controller of the personal data described in this policy is:

Ali Khoshraftarmonfared, a natural person established in the Netherlands, trading as Tesseractive — the developer name published on the Google Play listing for nl.hazely.app.

Hazely is not run by a company. There is no BV, no other legal entity and no Chamber of Commerce (KvK) registration behind it yet, so this section gives you no KvK number, no VAT number and no company legal form: there are none to give, and we are not going to invent one. A Dutch business registration is being arranged. When it exists, this section will be updated and this policy reissued under a new version number.

Postal address. We do not publish one, because the only address that exists today is a private home address. You can still have it: ask at privacy@hazely.nl and we will send it to you in writing. That is also the address to use if you need to serve something formally.

We are established in the Netherlands, so no representative under Art. 27 GDPR is required.

About dpo@hazely.nl. We have not designated a Data Protection Officer, and we are not required to under Art. 37(1) GDPR: we are not a public authority, and Hazely does not operate at the scale that provision contemplates. dpo@hazely.nl reaches the same person as privacy@hazely.nl. It is published because earlier versions of this policy published it and it still appears in the app and on our website. Treat it as a routing alias for privacy correspondence, not as the designation of a data protection officer under Arts. 37–39 GDPR. If that ever changes, we will say so here and notify the Autoriteit Persoonsgegevens as Art. 37(7) requires.

2. Scope and definitions

This policy covers the personal data we process when you install, open, or use the Hazely mobile app — nl.hazely.app on Android and nl.hazely.ios on iOS — and when you visit hazely.nl.

• "You" means the person using the App or the website.
• "We" means the controller named in §1.
• "the App" means both the Android and the iOS app. Where the two behave differently, we say so.

Hazely is an information-only app. It shows publicly listed licensed coffeeshops, their opening hours, ratings and house rules, gives walking directions, extracts text from a photo of a printed menu, and shows a reference catalogue of cannabis strains. It sells nothing, takes no orders, processes no payments, and has no user accounts.

This policy does not cover coffeeshops, third-party websites, or any other service you reach from a link in the App. Read their own privacy notices.

Two companion documents form part of this notice:

• The Cookie & Tracker Policy explains what is stored on or read from your device, and the consent required for that under Art. 11.7a Telecommunicatiewet and Art. 5(3) of the ePrivacy Directive 2002/58/EC.
• The Notice and Action procedure, available in the App, explains how to report illegal content. You can also write to abuse@hazely.nl.

This policy is also the privacy policy referenced in Hazely's Google Play Data safety section and in the App Store privacy label. Those two disclosures must say the same things this policy says. If you spot a difference, tell us at privacy@hazely.nl.

3. What data we process

3.1 Data you give us directly

We do not operate a feedback form, and there is no crash-reporter comment box. Version 2.1 said we did. That was wrong and has been removed.

3.2 Data collected automatically

Most of the rows below are off unless you switch them on. Firebase Analytics, Crashlytics and Performance Monitoring all ship disabled in the app manifest and stay disabled until you consent. A few rows run regardless of your choices; those are marked.

The exact analytics events. If — and only if — you turn Analytics on, the Android app can send these events to Google. Each is tied to a Firebase app-instance identifier: a pseudonymous per-installation ID that Google can link across your sessions.

The iOS app sends a smaller set: search_submitted (query length and result count), shop_selected (shop ID and name), strain_viewed (strain ID and strain name — the Android equivalent sends the type instead of the name), menu_scan_started (shop ID) and navigation_started (shop ID and name).

Android shortens every event parameter to 100 characters before sending it. iOS does not, which matters for none of the parameters above, since none of them carries text you typed.

A change already under way: from the next releases — Android 1.0.7 and the next iOS build — the shop-name parameter is removed from all events (the shop ID remains) and iOS's strain_viewed sends the strain ID instead of the name; everything above describes the builds currently shipping.

3.3 What happens to your menu photos

Before the camera opens, on both platforms, the App tells you that an AI reads the photo and asks you to keep faces, ID documents and vehicle plates out of the frame, and then asks you to confirm. You can cancel at that point. Nothing is captured or sent unless you confirm. Then:

• Your camera takes the photo. On Android it is written to the App's private cache, rotated, resized and re-compressed, and the temporary file is then deleted. On iOS it is compressed in memory. Re-compressing removes EXIF metadata as a side effect.
• The image is uploaded over HTTPS (maximum 8 MB) to our Cloud Function in europe-west1 (Belgium). If you scanned from a shop's page, the shop's ID is sent with it.
• Our server re-encodes the image to strip EXIF, IPTC and XMP metadata. If the image cannot be decoded, and therefore cannot be stripped, the upload is rejected — you are asked to retake the photo, and nothing is forwarded to anyone. Version 2.1 promised unconditional stripping while the server actually forwarded the original bytes on a decode failure. That is fixed and deployed; the promise is now true without qualification.
• The cleaned image is sent to Google's Gemini API at generativelanguage.googleapis.com — the Gemini Developer API, which is a global endpoint with no EU data-residency guarantee. Version 2.1 said "EU region selected". That was wrong. Version 2.1 also named Anthropic, PBC as an alternative provider; no Anthropic service is used and that name has been removed.
• We never store the image. Only the extracted text.
• The extracted result (item names, categories, warnings) is written to our database as a record with a random ID and no identifier of you. It is kept for up to 30 minutes and then deleted — see §7 for how that is enforced.
• Strain names in your photo that are not already in our catalogue are added to a shared, public strain catalogue as AI-generated entries and served to all users. These are kept indefinitely. They contain no information about you.
• For each scan our server logs the image sizes, the media type and the shop ID. That log line sits in the same log entry as your IP address.

Does Google train on your photo? We are not going to tell you it does not, because we have not established that we are entitled to say so. Google's Gemini API Additional Terms treat data use differently across service tiers and customer establishments, and which of those apply to our API key is not something the App's source code shows. Version 2.1 stated flatly that images are never used to train the model. We have removed that claim rather than repeat it unverified. If you would rather no photograph of yours reached Google at all, do not use Scan Menu: nothing is sent unless you start a scan and confirm.

3.4 What we deliberately do not collect

• Account credentials. There is no login, anywhere in the App.
• Payment information. The App processes no payments.
• Your home or work address.
• Background location. We do not request it and the App cannot track you when it is closed.
• Your contacts, your photo library, your microphone, or your calendar.
• Health, biometric or identity-document data — we never ask you for any.
• Any user ID of our own. We never call setUserId. We do not build a cross-device profile.
• Your favourites list. It stays on your device.
• Your location, on our own servers. Our shop API is called with no coordinates at all.
• What you type into the map search bar. It filters the list on your device; only its length and the number of results are ever sent, and only with Analytics on. This is not true of the strain catalogue search, which is sent — see §3.1.

Version 2.1 also claimed we collect no "record of which coffeeshop you visited". That claim was not correct when Analytics is switched on, and has been removed. See §3.5.

3.5 Cannabis, coffeeshops and special-category data

We never ask about your cannabis use, your health, or what you buy. We hold no purchase record and no visit log, and your location never reaches our servers.

But we will not tell you that no inference is possible. If you turn Analytics on, the events in §3.2 include the names of coffeeshops you open, favourite, ask directions to and photograph a menu at, and the strain pages you read — all under one per-installation identifier held by Google, kept for the analytics retention period. Photographing a menu board in particular can normally only happen while you are physically at that shop.

EU case law applies a broad test: data can fall under Art. 9(1) GDPR if it is liable to reveal a special category by inference, not only if it states one (CJEU C-184/20 OT, 1 Aug 2022; C-252/21 Meta Platforms, 4 Jul 2023; C-21/23 Lindenapotheke, 4 Oct 2024). Whether interest in a coffeeshop is "data concerning health" under Art. 4(15) GDPR has not been decided by any court or regulator. We are not going to claim the answer is obviously no, and we are not going to claim it is obviously yes. What we can tell you is exactly what is sent, which is the table above.

What this means for you in practice: if you do not want that stream to exist, leave Analytics off. It is off by default and refusing it costs you nothing — every feature of the App works exactly the same. Crash reporting carries the same signal in a smaller way, through the two Crashlytics keys named in §3.2, and it is off by default too.

We have taken external advice on whether to remove the shop identifier and shop name from those events entirely. Until that is settled, the position is the one described here rather than a promise we have not implemented.

3.6 Data about people who are not Hazely users

Some data we hold is about people who never used the App. Art. 14 GDPR applies to it, and this section is that notice.

Two things we would rather be able to write differently, stated as they are:

• There is no automatic deletion for the cached reviews and photos. We have not set a period and we are not going to publish one we do not enforce. We delete on request, and we delete a shop's cached content when we stop listing the shop.
• We give this notice publicly rather than individually. We hold no contact details for review authors — the Places API gives us a display name, not an address — so there is no one to write to. We are not asserting here that Art. 14(5)(b) GDPR (disproportionate effort) applies; that assessment has not been completed. We are telling you what we hold and how to get it removed.

If you are a review author or appear in a photo and want that removed, email privacy@hazely.nl. We will remove it from our cache. We cannot remove it from Google.

4. Purposes, lawful bases, recipients and retention

4.1 The full table

Consent-based rows are marked Consent. Where the operation also stores information on, or reads information from, your device, Art. 11.7a Telecommunicatiewet requires that consent separately from the GDPR — that is noted as (+ Tw 11.7a).

Where we rely on legitimate interests (Art. 6(1)(f)), the interests are: giving you a working map and directions; keeping public listings accurate; keeping the service secure and available; being able to demonstrate the consent you gave; and keeping minors out of a cannabis-related app. You can object to any of it under Art. 21 GDPR — see §9.

Two bases that changed since version 2.1, and why it matters to you. Version 2.1 gave Art. 6(1)(c) (legal obligation) for the age gate and the acceptance log. Art. 6(3) GDPR requires such an obligation to be laid down in Union or Member State law, and there is none here: the Opiumwet tolerance criteria bind the coffeeshop rather than an information app, and the age there is 18, while our 21+ rule comes from app-store policy. We now rely on Art. 6(1)(f) instead. The practical difference is in your favour: Art. 6(1)(c) processing carries no right to object, and Art. 6(1)(f) processing does.

On Remote Config and App Check. Neither runs before you have answered the consent screen, on either platform — that is a hard gate in the code, not a convention, and it holds whatever you answered, because the "update required" kill switch has to keep working for someone who declined everything optional. For the on-device storage those two use after that point, we rely on the strictly-necessary exemption in Art. 11.7a(3)(b) Tw. That assessment is our own and has not been confirmed by an external adviser or by a regulator; we say so rather than present it as settled.

4.2 Do you have to give us this data? (Art. 13(2)(e) GDPR)

Nothing here is a statutory or contractual requirement to provide data, except that we cannot lawfully or practically operate the App for someone who will not confirm they are 21+.

4.3 Advertising and partner links, as they actually stand today

No advertising runs in Hazely. The Android app contains the Google Mobile Ads (AdMob) SDK and Google's certified consent management platform (UMP), but every one of the six ad placements is switched off, both in the app's built-in defaults and in the published server configuration. No ad is requested, no ad consent form is ever shown, the ads SDK is never started, and no ad has ever been served. The iOS app has no ads SDK at all.

No affiliate or partner monetisation runs either. The "food nearby" card that can appear when you arrive at a shop carries no partner link today: the feature is switched off and the partner URL is empty. We are not in any affiliate programme, and we receive no commission from anything in the App.

5. Recipients — who else handles your data

Removed in this version: Anthropic, PBC and Hetzner Online GmbH / the current VPS provider were both named as processors in version 2.1. Neither receives any data. There is no Anthropic call anywhere in our systems, and we no longer run a VPS. GoDaddy was listed as our domain registrar; a registrar does not process your personal data and has been removed.

On processing agreements. Version 2.1 stated that every processor is "contractually bound by a Data Processing Agreement under Art. 28 GDPR". We do not repeat that, because we have not verified it for every recipient in the table above, and stating it would be easier than checking it. Where a recipient is not a processor at all we now say so — AdMob is an independent controller for ad data, and Google Play and Apple are independent controllers for their store data. We are working through the remainder; when it is settled this section will say which terms cover which recipient, per recipient, rather than in one sentence.

We do not sell your data to anyone, ever.

6. International transfers (GDPR Chapter V)

Some of the recipients above process data outside the European Economic Area. Being accurate about which ones matters, and version 2.1 was not.

Version 2.1 said Firebase Analytics and Crashlytics were processed in "EU (Frankfurt region)" and that Gemini ran in "an EU region selected". Neither is correct. Google's own documentation (Privacy and Security in Firebase, page last updated 18 February 2026) states that most Firebase services run on global Google infrastructure with no data-location choice, and the Gemini Developer API endpoint we call offers no regional selection.

For transfers outside the EEA we rely on the safeguards in each provider's own terms — the Standard Contractual Clauses modules those terms incorporate, and/or the provider's certification under the Data Privacy Framework:

• the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914); and
• where the recipient is certified, the EU–US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795, in force). An appeal against that decision is pending before the Court of Justice (C-703/25 P), which is why the Standard Contractual Clauses remain relevant even where a certification exists.

We say "rely on" here the way §5 says it about processing agreements: we have not independently verified, recipient by recipient, which of these instruments is actually in place for each transfer. The protections we can verify are the practical ones described in §3 and §5: an EU processing region where the provider offers one, and sending as little as possible in the first place.

Ask us at privacy@hazely.nl for a copy of the safeguards.

7. How long we keep things

Version 2.1 also promised an "audit log of AI API calls" kept for 90 days, "nightly database backups" kept 14 days, and irreversible deletion "within seven days" of a retention period ending. None of those controls exists. They have been removed rather than restated.

8. Automated decisions, profiling and AI features

8.1 Automated decision-making (Art. 22 GDPR)

We make no automated decisions that produce legal effects on you or similarly significantly affect you. Nothing in the App scores, ranks, segments or profiles you. Menu scanning reads text from a photo; it does not decide anything about you.

8.2 AI transparency (Art. 50, Regulation (EU) 2024/1689 — the EU AI Act)

Article 50 of the AI Act has applied since 2 August 2026. Two features of Hazely use AI, and this is our disclosure for both. A disclosure buried in a document like this one is not enough on its own, so both of them also appear in the App.

Menu scanning. When you tap Scan Menu, an AI system — Google's Gemini — reads the text in your photograph and turns it into a list. Results can be incomplete or wrong. Do not rely on a scan for prices, availability, or anything that matters. In the App:

• Both platforms tell you before the camera opens that the scan is AI-assisted, what it extracts, and that faces, ID documents and vehicle plates should stay out of the frame, and ask you to confirm. You can cancel at that point, and nothing is captured or sent if you do.
• Both platforms repeat, with the result, that it was produced by AI and can be incomplete or wrong.

AI-generated strain entries. If you search the strain catalogue for a strain we do not have, an AI system generates an entry — name, indica/sativa type, THC and CBD ranges, effects, flavours, parentage and a one-line description — and stores it in the shared catalogue for everyone. These entries are written by AI. They are not verified by a human, and they may be wrong.

Stated plainly, because it is the weakest point in our AI transparency: those entries are shown alongside human-curated ones without a visible "AI-generated" label, and the record carries no machine-readable marker of having been AI-generated — the field for one does not exist in our data format yet. Until both are in place, treat any strain entry in Hazely as possibly AI-written, and treat this section as the notice that it may be.

Neither feature is a high-risk AI system under Annex III of the AI Act.

9. Your rights

You have the following rights. They are free to exercise, and we answer within one month (extendable by two months for complex requests, Art. 12(3) GDPR).

How to make a request: email privacy@hazely.nl. The page at hazely.nl/data-request sets out what to include and what happens next; it is a page you can read, not a redirect.

One gap on our side, stated rather than hidden: the Android app has no in-app link to that page. The iOS app does, under Settings. On Android you reach it from hazely.nl or by emailing privacy@hazely.nl directly, which works just as well. The next Android release adds that link, together with an "App instance ID" display in Settings (with a copy button) so you can quote the identifier your analytics data is keyed to; the next iOS build adds the same ID display.

An honest limit on access, erasure and portability. We deliberately built the App without accounts and without any identifier of our own. That is good for your privacy, and it has a cost: for the analytics, crash and performance data held at Google, the records are keyed to a per-installation identifier that we cannot connect to you, and that the App does not show you. Where we genuinely cannot identify you, Art. 11(2) GDPR provides that Arts. 15–20 do not apply unless you give us information that makes identification possible.

What we can always do:

• Delete or correct an owner request or a report you submitted, using the email address you gave.
• Delete correspondence you sent to any of our published addresses.
• Confirm what categories of data exist and where — this policy.
• Tell you how to erase everything on your device: uninstall, or use Settings → Reset all my privacy choices.

And the practical answer, which is better than any of them: if you do not want analytics, crash or performance records about your installation to exist at Google, leave those switches off. They are off unless you turn them on, and uninstalling the App discards the identifier they were keyed to.

10. Turning optional processing off

11. Security

What we actually do:

• Encryption in transit. TLS on every connection between the App, our backend and every processor. Plain-text traffic is disabled in the Android app.
• A closed database. Our Firestore security rules deny all direct client access. Nothing reaches the database except through our own API.
• App attestation. On Android, the App attaches a Google Play Integrity token to its requests through Firebase App Check. Server-side enforcement of those tokens is currently switched off, so today this is a defence-in-depth measure, not a guarantee that only real installations reach our API. We may switch enforcement on at any time, without notice.
• Rate limiting. The API, and the menu-scan endpoint in particular, are rate limited to prevent abuse and runaway cost.
• Managed secrets. API keys are held in Google Secret Manager and injected into the backend at runtime. They are not in our source code.
• Data separation. Public shop data is stored separately from personal submissions such as owner requests and reports.
• Menu images are never written to storage. Only extracted text is stored.
• Metadata stripping, without exception. Menu photos are re-encoded on the server to remove EXIF, IPTC and XMP metadata, and an image we cannot re-encode is rejected instead of forwarded. There is no path by which an unstripped image reaches Google.

Version 2.1 described an Nginx reverse proxy, a service bound to localhost:8080, a chmod 600 secrets file, unattended OS security updates, and truncation of IP addresses on receipt. That described a self-hosted server we no longer run. None of it applies to the current system, and the IP-truncation control does not exist in it.

No system is impenetrable. If a personal data breach occurs we will notify the Autoriteit Persoonsgegevens within 72 hours where required (Art. 33 GDPR).

How we would tell you. We have no accounts, no email address for you, and no push notifications. We therefore cannot contact affected users individually. Where a breach is likely to result in a high risk to your rights and freedoms, we will rely on Art. 34(3)(c) GDPR and make a public communication: a notice on hazely.nl and a notice inside the App. Version 2.1 promised to notify you directly. The App cannot do that.

12. Children and the 21+ age gate

Hazely is not intended for anyone under 21. On first launch we ask you to confirm you are 21 or older, and Android blocks the App if you say you are not.

This is a self-declaration. We cannot verify anyone's real age, and we do not try — verifying age would mean collecting identity documents, which would be far more intrusive than the problem it solves.

We do not knowingly process the data of anyone under 21. If you are a parent or guardian and believe someone under 21 has used the App, email privacy@hazely.nl. Almost everything the App holds is on the device itself, so uninstalling removes it immediately.

Version 2.1 described the age gate as "a technical measure under Art. 8 GDPR". That citation was wrong — Art. 8 governs a child's consent to online services below the age of 16 (set at 16 in the Netherlands by Art. 5 UAVG), which is not what a 21+ declaration is. It has been removed.

13. Changes to this policy

We will update this policy when what we do changes. The version and effective date shown with this document always identify the current text.

What re-prompts you, and what does not. The App's acceptance gate is keyed to the Terms of Use and the Cookie & Tracker Policy — the two documents you are asked to accept — and not to this Privacy Policy, which is information we owe you rather than something you agree to. Stated plainly for each platform:

• On Android, the App stores the exact version string you accepted for those two documents and asks again whenever either of them moves, including a minor revision such as 2.1 to 2.2. It used to store a whole number, so minor revisions re-prompted nobody; that is fixed.
• On iOS, the App records only that you accepted, not which version. No document change re-prompts an iOS user today. That gap is real and we are not going to describe it as anything else.
• A change to this policy does not by itself produce a new prompt on either platform.

Where a change here is material we publish it at hazely.nl/privacy and hazely.nl/privacybeleid and note it in the App's release notes.

Earlier versions. We do not publish an archive page. Ask privacy@hazely.nl for the text of any earlier version and we will send it to you. Version 2.1 promised an archive at hazely.nl/privacy/archive that never existed; the promise has been removed rather than left standing.

One text, several places. The English text of this policy is generated from a single source file into the copy bundled in the Android app and the page at hazely.nl/privacy, so those two cannot disagree. The Dutch text is generated the same way into hazely.nl/privacybeleid and into the Android app for devices set to Dutch. The App's own screen headings are still English even when the body text is Dutch. iOS opens the published web version rather than carrying a copy.

A limitation you should know about. Some text shown in the App — including wording on the age-gate and consent screens — can be replaced remotely through Firebase Remote Config without a new app release. We use this to fix wording quickly. It means we do not keep a snapshot of the exact words you were shown when you gave consent, and so we cannot demonstrate afterwards precisely what any individual user read. We are telling you because Art. 7(1) GDPR makes that our problem, not yours; nothing about it limits any right you have under §9.

14. Contact and complaints

• Privacy questions and rights requests: privacy@hazely.nl
• Data-protection contact: dpo@hazely.nl (a routing alias — see §1)
• Legal: legal@hazely.nl
• Security: security@hazely.nl
• Illegal content and abuse: abuse@hazely.nl
• Postal address: not published. Ask at privacy@hazely.nl and we will send it to you in writing.
• Dutch supervisory authority: Autoriteit Persoonsgegevens, https://autoriteitpersoonsgegevens.nl/en — you may complain to them at any time, and you do not have to contact us first.

Changelog

Version 3.0 — 4 August 2026 (replaces version 2.1 of 21 May 2026)

This is a major version because the previous version described a system we no longer run and, in several places, described data handling that did not match the app. Under Art. 5(1)(a) and Art. 13 GDPR a privacy notice has to be accurate, and correcting an inaccurate notice is itself a material change.

Who we are, at last:

1. The controller is now named — a natural person established in the Netherlands, trading under the name published on the Google Play listing. Version 2.1 pointed at "the publisher identified in the Google Play listing", which told an iOS user or a website reader nothing (§1). 2. No company registration is claimed, because there is none yet. When a Dutch business registration exists, §1 will be updated and this policy reissued (§1). 3. A postal address is available on request rather than published, and §1 and §14 both say so and both give the address to ask at (§1, §14). 4. dpo@hazely.nl is explained rather than left ambiguous: no Data Protection Officer has been designated, none is required, and the address is a routing alias (§1).

Corrections of statements that were not accurate:

5. Search text. Version 2.1 said search queries were "in-memory only — never transmitted". With Analytics on, the raw text of a map search used to be sent to Google. It no longer is: only the number of characters and the number of results are sent, on both platforms. The original claim is true again, and §3.4 states it in the narrow form that is actually true (§3.1, §3.2, §3.4). 6. Strain searches. Text typed into the strain catalogue is sent — to our server and on to Google Gemini when there is no local match. Previously undisclosed, and deliberately separated from the map search so the difference is visible (§3.1). 7. Hosting. Removed "Hetzner Online GmbH or the current VPS provider". Added Google Cloud Functions and Firestore in europe-west1, which is where the data actually is (§5, §6). 8. Anthropic. Removed. No Anthropic service is used; menu scanning uses Google Gemini only (§3.3, §5). 9. Data location. Removed the claims that Firebase Analytics and Crashlytics run in "EU (Frankfurt)" and that Gemini runs in a selected EU region. All three are global services (§6). 10. IP addresses. Removed the claim that IPs are truncated to /24 and /48 on receipt. They are not truncated anywhere in the current system (§3.2, §7, §11). 11. EXIF stripping. Version 2.1's unqualified promise was false at the time — an image the server could not decode was forwarded intact. The server now rejects such an upload, so the promise is true as written (§3.3, §11). 12. Menu-scan retention. "Server memory only" corrected to the actual database record, and the 30 minutes is now enforced by a time-to-live policy that deletes the record whether or not anyone reads it again (§3.3, §7). 13. The training claim about menu photos has been removed, not weakened. We do not state that Google does not train on your image, because we have not established that we may (§3.3). 14. "We collect no record of which coffeeshop you visited" — removed, because the analytics events contradict it. §3.5 now states the position honestly instead of arguing that Art. 9 GDPR cannot apply (§3.4, §3.5). 15. Security section rewritten for the Firebase architecture; the Nginx, localhost:8080, chmod 600 and unattended-upgrades description was removed (§11). 16. Breach notification reframed to a public communication under Art. 34(3)(c), because the App has no way to contact you individually (§11). 17. Retention promises removed that had no implementation: the AI-call audit log, nightly backups, the seven-day deletion service level, and the 24-month period for owner requests (§7). 18. AdMob re-described as an independent controller for advertising, not as a processor under Art. 28 GDPR — and the whole advertising section rewritten to say plainly that nothing runs today (§4.3, §5). 19. The blanket Art. 28 assurance was dropped. We do not claim every recipient is bound by a processing agreement, because we have not verified it for every recipient (§5). 20. Legal bases corrected: Art. 6(1)(c) removed for the age gate and the acceptance log; Art. 6(1)(f) used instead, which gives you a right to object that the old basis did not (§4.1). 21. Art. 8 GDPR citation removed from the children section (§12). 22. Feedback forms and crash-reporter comments removed — neither exists (§3.1). 23. The archive promise removed. hazely.nl/privacy/archive never existed; earlier versions are available on request instead (§13).

Newly disclosed processing that was previously missing:

24. Firebase Performance Monitoring, including its automatic network-request traces, and the fact that it has no control of its own (§3.2, §4.1, §10). 25. Firebase Remote Config and Firebase installation identifiers — now gated behind the consent screen on both platforms, where version 2.1's iOS build fetched at launch, before the age gate (§3.2, §4.1). 26. Firebase App Check / Google Play Integrity, which runs even if you reject everything optional (§3.2, §4.1). 27. The Google Play in-app update check, which runs before the age gate (§3.2). 28. GitHub, Inc. as a recipient of crash titles (§3.2, §5). 29. Microsoft Exchange Online as the recipient of everything emailed to our published addresses (§5, §6). 30. The Android Advertising ID, collected by the Analytics SDK under the Analytics switch rather than the ads switch (§3.2). 31. Mapbox Maps SDK telemetry — now switched off on Android unless you consented to Analytics, still not gated on iOS, and with the residual monthly-active-user event disclosed (§3.2, §4.1, §10). 32. The on-device 50-metre proximity check around coffeeshops (§3.2). 33. Permanent storage of AI-generated strain entries derived from scans and searches (§3.3, §7). 34. The full analytics event list, parameter by parameter (§3.2).

New sections:

35. §3.6 — an Art. 14 GDPR notice for people whose data we did not get from them: Google review authors, people in listing photos, and bystanders in menu photos, including the two things about it we cannot yet state as we would like. 36. §4 — a single table giving purpose, data, lawful basis, recipients and retention together, and §4.2, the Art. 13(2)(e) statement of what happens if you decline. 37. §8.2 — AI transparency under Art. 50 of the EU AI Act, applicable since 2 August 2026. Both platforms now show the AI notice before the camera opens; version 2.1's Android build showed it only with the result. 38. §9 — the Art. 11(2) GDPR limitation on access, erasure and portability, stated openly rather than promising rights the architecture cannot deliver. 39. §13 — an honest description of what re-prompts you on each platform, and the fact that in-app wording can be changed remotely.

Known defects we have chosen to publish rather than paper over: the merged Android "Analytics & Performance" switch (§10), the absence of version tracking on iOS (§13), the absence of an in-app data-rights link on Android (§9), the absence of a visible "AI-generated" label on generated strain entries (§8.2), the absence of a retention limit on cached shop reviews (§3.6), and the fact that consent-screen wording can be changed remotely (§13). Each of them is a thing to fix, and each is described here in the form it actually takes today.

• 3.1 (13 August 2026). iOS: the personalised-ads switch was removed from the consent screen and Settings after App Store review feedback (Guideline 5.1.2(i)). The iOS App has no advertising SDK and performs no tracking; the switch controlled nothing and implied otherwise. Android is unchanged. Section 10's toggle table was corrected to match.
• 3.2 (14 August 2026). Corrections and forward notices, in both languages. §11 no longer claims App Check lets us "tell a real installation from a script": the app does attach a Play Integrity token, but server-side enforcement of those tokens is currently switched off, so the sentence now describes a defence-in-depth measure, not a guarantee, and notes that enforcement may be switched on without notice. §10's iOS row was incomplete: Firebase Performance rides the Analytics switch on iOS too, and the row now names both switches correctly. §6 no longer asserts which transfer instrument covers each recipient; it is hedged the way §5 hedges processing agreements, pointing at the practical protections instead. The version 3.1 entry referred to the toggle table as Section 14; it is Section 10, and the reference is fixed. Forward notes added: from Android 1.0.7 and the next iOS build the shop-name parameter leaves all analytics events (the shop ID remains) and iOS's strain_viewed switches to the strain ID (§3.2); Advertising-ID collection is disabled from Android 1.0.7 (§3.2); and the next releases add the in-app data-request link on Android and an "App instance ID" display, with copy, on both platforms (§9). §7 now discloses a one-off manual cleanup (August 2026) of a small number of legacy scan records that predate the expiry field.