Privacy Policy

Last updated: April 4, 2026

1. Data Controller

Tibor Kontos Munkacsy ut 43, Martfu, Hungary Email: privacy@dinorant.com

This Privacy Policy explains how Dinorant ("we", "us", "our") collects, uses, stores, and protects your personal data when you use the Dinorant mobile application ("the App") and the Dinorant website at dinorant.com ("the Website"), collectively referred to as "the Service". We are committed to protecting your privacy in accordance with the General Data Protection Regulation (EU) 2016/679 ("GDPR") and applicable Hungarian data protection legislation.

Appointment of a Data Protection Officer is not currently required under GDPR Art. 37; we review this assessment regularly as our processing activities evolve.

2. Data We Collect

2.1 Account Data (Firebase Authentication)

When you create an account, we collect:

• Email address — for registration, login, and password recovery
• Password — stored as a cryptographic hash by Firebase Authentication; we never have access to your plain-text password
• Display name — optional, for profile display
• Profile photo URL — only if provided via Google or Apple Sign-In
• Firebase User ID (UID) — a unique identifier for your account
• Email verification status — to confirm your identity

Legal basis: Performance of contract (GDPR Art. 6(1)(b)) — necessary to provide the service.

2.2 Social Sign-In Data

If you sign in with a third-party provider, we receive:

We only use this data to create or link your account. We do not access your contacts, calendar, or any other data from these providers.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)).

2.3 User Preferences (Cloud Firestore)

When logged in, we store your preferences to sync across devices:

• Home country (code and name)
• Allergen selections (EU-14 allergen categories) with per-allergen severity levels (mild, severe, or life-threatening)
• Dietary preferences (e.g., vegetarian, vegan, gluten-free)
• Taste DNA personalization data, including dish and ingredient preferences, flavor affinity settings, recommendation feedback, and derived recommendation summaries
• UI settings (theme, language, measurement units)
• Privacy consent choices

These are stored in Google Cloud Firestore under your user ID with strict security rules ensuring only you can access your own data.

When you use personalized recommendation features, we may also create and update a Taste DNA profile linked to your account. This profile may include:

• Explicit food preference data you provide, such as dishes and ingredients you like, dislike, love, or hate
• Flavor affinity values across sweet, salty, sour, bitter, umami, smoky, and spicy dimensions
• Interaction-based signals such as viewed dishes, saved dishes, shared dishes, explored destinations, generated dietary cards, and recommendation feedback actions
• Derived personalization data such as favorite cuisines, taste archetypes, recommendation strength labels, short recommendation explanations, and cached AI-generated recommendation summaries

Your allergen and dietary preferences (including severity levels) may also be sent to our backend and forwarded to the OpenAI API when you use the Gastro Explorer feature (personalized dietary tips, AI gastro chat) or the Dietary Card feature. This allows the AI to generate destination-specific dietary safety guidance and dietary communication cards tailored to your needs. No personally identifiable information (no name, email, user ID, or other direct identifiers) is included in the data sent to OpenAI — only allergen category names, severity labels, dietary preference types, and destination context in pseudonymized form, limited to the minimum necessary.

When you use menu translation with Taste DNA personalization, a pseudonymized summary of your Taste DNA profile may also be sent to our backend and forwarded to the OpenAI API so the AI can rank menu items, generate recommendation labels, and produce short recommendation explanations. This summary may include favorite cuisines, liked or disliked dishes and ingredients, flavor preferences, recommendation feedback signals, and other derived preference indicators. No direct identifier (such as your name, email address, or user ID) is included in that transfer.

Special category data notice: Allergen data with severity levels (particularly "life-threatening") constitutes health-related data under GDPR Art. 9. Processing of this data requires your explicit, separate consent, which is obtained via a dedicated consent mechanism in the App when you first configure your allergen severity levels. You may withdraw this consent at any time in Settings > Privacy, which will remove severity-level data from future server-side processing. Withdrawal applies to future transfers only and does not have retroactive effect on requests previously sent to OpenAI in pseudonymized form, those requests remain subject to OpenAI's own data handling policies. Basic allergen category selections (without severity) may still be maintained under the contract performance legal basis.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)) for basic preference storage, synchronization, and delivery of personalized recommendation features that you request through the Service. Explicit consent (GDPR Art. 9(2)(a)) for processing allergen severity levels as health-related data.

2.4 Locally Stored Data

The App stores certain data locally on your device to support faster operation, offline access, and a better user experience.

Depending on the platform, operating system, and app version, this local data may be stored using a combination of app sandbox files, operating-system secure storage, SharedPreferences, and similar local persistence mechanisms. Not every data category uses the same storage layer on every platform.

Some of this data remains only on your device. In particular, locally saved translation images and related local history records are not uploaded to our servers for historical storage.

When you are signed in, certain settings and consent choices may also be synced to Google Cloud Firestore, linked to your user account, to support cross-device synchronization. Authentication and session data stored locally on your device may also be transmitted to our backend during authenticated API requests so that we can identify you and authenticate those requests.

We use this locally stored data only to operate the app, preserve your settings, support cross-device synchronization, and maintain authenticated access to the Service.

2.5 Location Data

• GPS coordinates (latitude/longitude) are used to find nearby restaurants and display weather information.
• Location data is not stored persistently. It is used only during the active session.
• Location data is sent to our backend server, which forwards it to Google Places API and Apple WeatherKit.
• The backend may temporarily cache weather results per user for up to 1 hour and nearby restaurant results for up to 24 hours (location-based, not user-specific).

Legal basis: Consent (GDPR Art. 6(1)(a)) — you grant location permission through your device settings.

2.6 Camera and Image Data

• Menu photos taken via camera or selected from gallery are sent to our backend for AI-powered translation.
• Images are processed in memory on our backend and forwarded to OpenAI's API for analysis.
• If Taste DNA personalization is available for your account, we may also send a pseudonymized summary of your stored Taste DNA profile together with the translation request so the AI can return personalized recommendation labels and short explanations.
• Images are not stored permanently on our backend. They are discarded after processing.
• You may save translation results (including photos) locally in your translation history.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)).

2.7 Dietary Card Data

When you generate a Dietary Card for a travel destination, the following data is processed:

• Allergen and dietary preferences (including severity levels) are sent to our backend and forwarded to the OpenAI API to generate a bilingual dietary communication card.
• The generated card content includes: a greeting, a main message explaining your dietary restrictions, your allergens (translated, with severity and emoji icons), your dietary needs (translated), an emergency phrase, and a thank-you message — all in the destination's local language with English counterparts.
• Generated dietary cards are cached locally on your device (in SharedPreferences, keyed by destination) to avoid unnecessary regeneration.
• The inputs needed for generation and the generated card content may also be temporarily stored in our backend cache for up to 30 days to reduce unnecessary regeneration, improve performance, and enforce usage limits.
• Dietary cards may be pre-generated automatically when a border crossing is detected, using your locally stored preferences.

We do not maintain a separate long-term user content archive of dietary cards, but the temporary server-side cache described above is part of how the Service operates. These cached records are not public, are not shared with other users, and expire automatically.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)) for generating dietary cards. Explicit consent (GDPR Art. 9(2)(a)) for processing allergen severity levels as health-related data. If you withdraw your consent to the processing of allergen severity levels in Settings, these features will no longer process your health data when generating cards and passes.

2.8 Wallet Pass Data (Apple Wallet & Google Wallet)

When you add a dietary card to Apple Wallet or Google Wallet, the following data is processed:

• Your dietary card content (greeting, allergens with severity, dietary needs, emergency phrase, thank-you message) is sent to our backend to generate a wallet pass.
• Apple Wallet: Our backend generates a .pkpass file (a signed ZIP archive) containing the card information. The pass is signed using an Apple-issued Pass Type ID certificate. The pass displays your allergens and dietary needs on the front, with full emergency information and English translations on the back.
• Google Wallet: Our backend generates a signed JWT containing a GenericObject with your card information and returns a save URL. The pass is hosted by Google.
• Wallet passes contain a serial number derived from your user ID, destination, and a timestamp — this is used solely for pass identification and is not shared with other users.
• We do not store wallet passes on our servers. They are generated on-the-fly and delivered to your device.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)) for generating wallet passes. Explicit consent (GDPR Art. 9(2)(a)) for processing allergen severity levels as health-related data. If you withdraw your consent to the processing of allergen severity levels in Settings, these features will no longer process your health data when generating cards and passes.

2.9 Tier Data

We store basic service-tier information in your Firestore profile:

• Tier status — your current service tier (e.g. Free)
• Tier expiry date — if applicable, when your current tier expires
• Tier activation date — when the tier was activated

This data is used to manage your service level and enforce usage limits.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)).

2.10 Support Tickets

When you submit a support ticket via the Website, we collect:

• Subject and description — the content of your support request
• Category and priority — classification of the issue
• Platform and app version — technical context for troubleshooting
• User ID and email — to identify your account and respond to you

Support tickets are stored in Cloud Firestore and linked to your authenticated account.

Legal basis: Performance of contract (GDPR Art. 6(1)(b)) — necessary to provide customer support.

2.11 Push Notification Data

To deliver push notifications (e.g., tier expiry warnings, service announcements), we store:

• FCM device tokens — unique identifiers for each of your devices, stored in Firestore under your user ID
• Notification delivery logs — type, title, target, timestamp, and delivery success/failure status (stored as audit records)

Stale device tokens are automatically removed when delivery fails.

We use FCM device tokens solely to deliver notifications and automatically clean up inactive tokens.

We retain notification delivery logs separately for audit and incident investigation purposes, to demonstrate when service integrity communications were sent and with what result, and to investigate disputes and delivery failures after the fact.

Legal basis: Consent (GDPR Art. 6(1)(a)) — based on the in-app consent prompt and the iOS system-level permission dialog. You may withdraw your consent at any time in your device notification settings.

2.12 Usage and Rate Limiting Data

To enforce fair usage and protect service quality, our backend stores per-user API request counters in a distributed cache (Redis):

• Rate-limit counters — request counts per minute, hour, and day windows (automatically expire within 48 hours)
• Daily usage counters — aggregate daily request counts retained for up to 31 days, used for service analytics and tier upgrade suggestions
• Tier cache — your current tier name, cached for faster request processing

These counters are keyed by your Firebase UID and contain no personal content — only numeric request counts.

Legal basis: Legitimate interest (GDPR Art. 6(1)(f)) — necessary to enforce fair usage, prevent abuse, and maintain service stability, which also serves your interest in reliable access to the service.

3. Analytics and Tracking

3.1 Firebase Analytics

• Analytics collection is disabled by default.
• We only collect analytics data if you explicitly consent on the Privacy Settings screen.
• On iOS, we additionally request App Tracking Transparency (ATT) authorization.
• You can withdraw consent at any time in Settings > Privacy.

When you consent, we collect:

• Screen views (screen name only)
• Translation events (page count, item count, duration, error types — no content)
• Authentication events (method used, success/failure — no credentials)
• Restaurant interaction events (place ID, distance — no personal data)
• Location permission results
• Onboarding progress (step names, completion/skip status)
• Subscription and purchase events (product ID, success/failure — no payment details)
• Notification interactions (permission granted/denied, notification opened)
• Dietary card usage (generation, sharing, errors — no card content)
• Camera and photo source events (camera or gallery — no image data)
• Gastro Explorer usage (destination searched, chat message count — no message content)
• Settings changes (theme, language selection — no personal data)
• Border crossing detection (country codes only)
• Travel tips viewed (destination country code only)
• Deep link navigation (route and source — no personal data)

User properties for segmentation (when you consent):

We may set the following anonymous user properties in Firebase Analytics to understand aggregate usage patterns. These do not contain personally identifiable information:

• Subscription tier (e.g. Free, Premium)
• App language and translation target language
• Home country code
• Measurement unit preference (metric/imperial)
• Spice tolerance level
• Whether allergens or dietary restrictions are configured (yes/no only — not which ones)
• Number of favorite cuisine categories
• Theme preference (light/dark/system)
• Onboarding completion status

When you withdraw analytics consent, we stop setting such user properties going forward, and previously recorded data is removed in accordance with Google's retention policies.

Legal basis: Consent (GDPR Art. 6(1)(a)) — based on the explicit consent you provide on the Privacy Settings screen.

3.2 User ID Linking

• Linking analytics data to your account is optional and requires separate consent ("Link Usage to Account").
• Both analytics consent AND user ID consent must be given for this to be active.
• Disabling this removes the Firebase User ID from analytics.

Legal basis: Consent (GDPR Art. 6(1)(a)).

3.3 Crash Reporting (Firebase Crashlytics)

• Crash reporting is a separate, independently controlled feature from Anonymous Statistics (Firebase Analytics).
• On mobile platforms (iOS and Android), crash reporting is managed via Firebase Crashlytics. Crash reporting is not available on the web platform.
• You can enable or disable crash reporting during the onboarding Privacy Settings step (presented with an off default), or at any time in Settings > Privacy > Crash Reporting.

When you enable crash reporting, the following data is automatically collected in the event of an app crash or error:

• Application crash stack traces, thread states, and error messages
• Device model, operating system version, and app version (including build number)
• Timestamp and app session identifier
• Non-fatal error reports from internal service failures (e.g., network errors, data processing issues)
• Diagnostic log entries ("breadcrumbs") recording technical navigation events (screen transitions, feature usage) leading up to the crash — these contain no user content (no menu text, translations, allergen selections, or personal messages)

When you are logged in and crash reporting is enabled:

• Your Firebase User ID (UID) is attached to crash reports, enabling us to correlate crashes with your account for support purposes.
• You can prevent this by disabling crash reporting in Settings > Privacy.

Crash reporting does NOT collect:

• Menu photos, translations, or any text you provide
• Allergen or dietary preference data
• Location coordinates
• Analytics events (these are controlled independently)

Legal basis: Consent (GDPR Art. 6(1)(a)).

3.4 Meta (Facebook) App Events

• Meta App Events collection is disabled by default in the App.
• We only enable Meta App Events if you explicitly consent to analytics on the Privacy Settings screen.
• On iOS, Meta App Events are additionally gated on your App Tracking Transparency (ATT) authorization status.
• You can withdraw consent at any time in Settings > Privacy, which will disable Meta App Events going forward.

When you consent, the Meta SDK may collect:

• App install and app open events
• Device information (device model, OS version, screen resolution)
• App version and SDK version
• Advertising identifier (IDFA on iOS with ATT consent, AAID on Android)
• IP address (used by Meta for approximate geolocation and fraud prevention)
• Aggregated Event Measurement (AEM) data for privacy-preserving campaign attribution on iOS

We use Meta App Events solely for measuring the effectiveness of app install advertising campaigns on Meta platforms (Facebook, Instagram). We do not use Meta App Events for behavioral profiling, retargeting, or building audience segments within the App.

Meta processes this data as an independent Data Controller for its own purposes, including campaign measurement and optimization. For more information, see: Meta Privacy Policy

Legal basis: Consent (GDPR Art. 6(1)(a)) — based on the explicit consent you provide on the Privacy Settings screen. Advertiser ID collection and automatic event logging are disabled until consent is granted.

3.5 TikTok App Events SDK (iOS only)

• On iOS, TikTok App Events collection is disabled by default in the App.
• We only enable the TikTok App Events SDK if you explicitly consent to analytics on the Privacy Settings screen.
• On iOS, TikTok App Events are additionally gated on your App Tracking Transparency (ATT) authorization status.
• You can withdraw consent at any time in Settings > Privacy, which will disable TikTok App Events going forward.

When you consent, the TikTok SDK may collect:

• Automatic app install, app launch, and retention events
• Device information (device model, OS version, screen resolution)
• App version and SDK version
• Advertising identifier (IDFA on iOS with ATT consent)
• IP address and attribution or measurement signals, including SKAdNetwork-related data where applicable

We use the TikTok App Events SDK solely for measuring and optimizing app install advertising campaigns on TikTok. In the current implementation, we do not send TikTok custom commerce or content events such as add-to-cart, checkout, purchase, or view-content events, and automatic purchase tracking is disabled.

TikTok processes this data as an independent Data Controller for its own purposes, including campaign measurement and optimization. For more information, see: TikTok Privacy Policy

Legal basis: Consent (GDPR Art. 6(1)(a)) — based on the explicit consent you provide on the Privacy Settings screen. TikTok SDK tracking is disabled until consent is granted, and on iOS access to IDFA also depends on ATT authorization.

4. Advertising

The App displays advertisements via Google AdMob (Google Mobile Ads SDK) on iOS and Android platforms. The Website does not display advertisements.

• Ads appear on: Home screen, translation results, history list, and history detail screens.
• The Google AdMob SDK may collect device identifiers (IDFA on iOS, AAID on Android), IP address, and interaction data.
• In the European Economic Area (EEA), we use the Google User Messaging Platform (UMP) to obtain your consent before personalized advertising, in compliance with the IAB Transparency and Consent Framework (TCF).
• You may choose non-personalized ads or decline ad tracking through the consent interface.

For more information on Google's data practices, see: Google Privacy Policy

Additionally, the App uses the Meta (Facebook) SDK to measure the effectiveness of app install advertising campaigns on Meta platforms (Facebook, Instagram). Meta App Events data collection is disabled by default and is only activated with your explicit consent. See Section 3.4 for details.

On iOS, the App also uses the TikTok App Events SDK to measure and optimize app install advertising campaigns on TikTok. TikTok App Events collection is disabled by default and is only activated with your explicit consent. See Section 3.5 for details.

Legal basis: Consent (GDPR Art. 6(1)(a)) — via the UMP consent form (AdMob) and the Privacy Settings screen (Meta App Events and TikTok App Events).

5. Third-Party Services

We use the following third-party services that may process your data:

Each service provider has their own privacy policy. We encourage you to review them.

6. International Data Transfers

Some of our third-party service providers process data outside the European Economic Area (EEA), particularly in the United States:

• Google (Firebase, Crashlytics, AdMob, Places, FCM): Operates under EU Standard Contractual Clauses (SCCs) and the EU-U.S. Data Privacy Framework.
• Apple (Sign-In, WeatherKit): Operates under SCCs.
• OpenAI: Operates under SCCs. Menu images, allergen category names, severity labels, dietary preference types, chat messages, and pseudonymized Taste DNA context may be sent to OpenAI's servers for processing. This Taste DNA context can include flavor preferences, favorite cuisines, liked or disliked dishes and ingredients, recommendation feedback signals, and derived recommendation summaries used to personalize menu translation results and generate AI-written profile insights. No direct identifier (name, email, or user ID) is included in the transmitted data; however, allergen severity levels constitute health-related data under GDPR Art. 9. Transfer of such data to OpenAI takes place only on the basis of your explicit consent under GDPR Art. 9(2)(a), and only to the minimum extent necessary, in pseudonymized form and without direct identifiers. Withdrawal of consent affects future transfers only; it has no retroactive effect on previously transmitted pseudonymized requests, which remain subject to OpenAI's own data handling policies. OpenAI may use anonymized or pseudonymized prompts as an independent Data Controller to develop its services.
• Upstash (Redis, QStash): Infrastructure operates in the EU and/or US. Data processing governed by their DPA.
• Meta (Facebook SDK): Operates under SCCs and the EU-U.S. Data Privacy Framework. App event data may be transferred to Meta's servers in the United States for campaign measurement and optimization. Meta Platforms, Inc. is a participant in the EU-U.S. Data Privacy Framework. Meta acts as an independent Data Controller for the event data it receives.
• TikTok (App Events SDK): App event and attribution-related data may be processed by TikTok outside the EEA. TikTok acts as an independent Data Controller for the data it receives. Where required, such transfers are subject to TikTok's own transfer mechanisms and safeguards as described in its privacy documentation.
• Koyeb: Backend hosting uses globally distributed infrastructure with intelligent load balancing. Requests are routed to the nearest available region: EU (Frankfurt/Paris), US (San Francisco/Washington DC), or Asia-Pacific (Tokyo/Singapore). Data processing occurs in the region closest to the user. Koyeb operates under SCCs and their DPA for international transfers.

We ensure that appropriate safeguards are in place for all international data transfers in accordance with GDPR Chapter V.

7. Data Retention

8. Your Rights (GDPR Articles 15-22)

You have the following rights regarding your personal data:

• Right of access (Art. 15) — Request a copy of the data we hold about you.
• Right to rectification (Art. 16) — Correct inaccurate data via app settings or by contacting us.
• Right to erasure (Art. 17) — Delete your account and the data directly associated with it, including synced settings, Taste DNA profile data, and support tickets, through the App's Settings screen. We may still retain certain audit or legal-compliance records in limited form, such as anonymized consent logs or service-integrity logs.
• Right to restriction (Art. 18) — Request that we limit how we process your data.
• Right to data portability (Art. 20) — Export the main account, settings, and local history data available in the App in a machine-readable format via the App, and request a more complete server-side export through the Website account management interface or by contacting privacy@dinorant.com.
• Right to object (Art. 21) — Object to data processing based on legitimate interest.
• Right to withdraw consent — Withdraw analytics, crash reporting, or advertising consent at any time in Settings.

To exercise any of these rights, contact us at privacy@dinorant.com. We will respond within 30 days.

8/A. Territory-Specific Rights and Notices

California residents (CCPA/CPRA) We do not sell personal information as defined under the CCPA/CPRA. California residents may request access to, deletion of, and portability of the data we hold about them by contacting privacy@dinorant.com.

Canadian residents Personal data is handled in accordance with PIPEDA and applicable provincial privacy laws.

Japanese users (APPI) Transfers of personal data to third countries are carried out subject to appropriate safeguards, including SCCs, in line with Article 24 of the APPI.

Chinese users (PIPL) Allergen severity levels that qualify as health-related data are also treated as sensitive personal information under the PIPL, and are processed only with your explicit consent. Please note that, under the Service's current infrastructure, data may be processed on servers located outside mainland China, including in the EU and/or the United States, and this Policy does not constitute a representation of full PIPL data localization compliance.

9. Children's Privacy

Dinorant is not intended for children under 16 years of age. We do not knowingly collect personal data from children. If you believe a child under 16 has provided us with personal data, please contact us at privacy@dinorant.com and we will promptly delete such data.

10. Data Security

We implement appropriate technical and organizational measures to protect your data:

• Authentication and session data stored locally on your device is protected using platform-appropriate secure storage and equivalent operating-system safeguards where applicable.
• Cloud Firestore uses document-level security rules ensuring users can only access their own data.
• All network communication uses HTTPS/TLS encryption.
• Our backend enforces authentication on all API endpoints and applies rate limiting.
• Menu images are processed in memory and not persisted on our servers.
• Administrative access is restricted to authorized personnel via Firebase custom claims and dedicated admin-only API endpoints with separate authentication.
• Push notification audit logs ensure traceability of all communications sent to users.

11. Data Breach Notification

In the event of a personal data breach, we will notify the relevant supervisory authority (NAIH) within 72 hours of becoming aware of the breach, as required by GDPR Article 33, unless the breach is unlikely to result in a risk to your rights and freedoms. If the breach is likely to result in a high risk to your rights and freedoms, we will also notify you without undue delay (GDPR Article 34), via email and/or in-app notification, describing the nature of the breach, the likely consequences, and the measures taken or proposed to address it.

12. Supervisory Authority

If you believe your data protection rights have been violated, you have the right to lodge a complaint with:

Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) (Hungarian National Authority for Data Protection and Freedom of Information) Address: 1055 Budapest, Falk Miksa utca 9-11, Hungary Phone: +36 (1) 391-1400 Email: ugyfelszolgalat@naih.hu Website: https://www.naih.hu

You may also contact the supervisory authority in your EU member state of residence.

13. Changes to This Policy

We may update this Privacy Policy from time to time. We will notify you of material changes through the App, Website, or by email. The "Last updated" date at the top indicates when the policy was last revised.

Continued use of the Service after changes constitutes acceptance of the updated policy.

14. Contact Us

For any questions, concerns, or requests regarding this Privacy Policy or your personal data:

Email: privacy@dinorant.com Data Controller: Tibor Kontos, Munkacsy ut 43, Martfu, Hungary