1. Preamble / Publication Notice

1.1 Purpose and Scope (App & PHP (without CMS) Website)

This privacy policy provides transparent information about the nature, scope, purposes, legal bases, and recipients of the processing of personal data in connection with:

• the Trabista app (Android and iOS) and
• the accompanying PHP website (without CMS) of Trabista.

It describes in particular:

• which data is processed locally on the device and which data is optionally processed in the cloud (Premium),
• which legal bases apply in each case (including consents),
• which third-party providers/recipients are integrated (e.g., Supabase, Google services, Scaleway),
• retention periods, deletion concepts, and data subject rights,
• as well as the technical and organizational measures (TOMs) for data protection.

This statement is addressed to users of the app and visitors to the website and applies regardless of whether the app is used offline or optional online features (e.g., cloud synchronization, premium APIs) are activated.

1.2 Note: This Version is Published in the App and on the Website

• This privacy policy is published identically in the app (Legal/Info section) and on the website (separate page).
• Changes/versions are made traceable synchronously in both publications (see chapter "Changes & Updates").
• Insofar as individual services are only activated in the future (e.g., later analytics extensions, new third-party providers), the corresponding sections will be supplemented and -- where necessary -- new consents will be obtained.

1.3 Validity for Android & iOS, Website without Tracking

• Android: This privacy policy applies to the published Android app (available via the Google Play Store).
• iOS: The policy also applies to the published iOS app (native Swift app, available via the Apple App Store). Platform-specific differences (e.g., Apple ATT instead of CMP/UMP for advertising; Sentry as error/performance analysis instead of Firebase) are flagged separately in the relevant chapters (see 5.4, 5.6, 5.10, 8.3.6, 8.3.7).
• Website (PHP website (without CMS)): The website deliberately refrains from tracking/analytics and marketing cookies. Only technically necessary data is processed (e.g., server log files, contact form emails) -- details in the website chapters.

2. Controller, Contact & Imprint

2.1 Controller (Name, Legal Form, Addresses incl. c/o Delivery Address)

Controller within the meaning of Art. 4 No. 7 GDPR
Danilo Endesfelder -- Sole Proprietorship
Delivery/Service Address (c/o): c/o Nico Eberhardt, Pfotenhauerstraße 65, 01307 Dresden, Germany
Note on Address Protection: The address provided is a delivery address (c/o). The operator's private address is not published for privacy protection reasons.
VAT ID No.: TBD (to be added)
Responsible for Content (§ 18 Para. 2 MStV): Danilo Endesfelder, c/o Nico Eberhardt, Pfotenhauerstraße 65, 01307 Dresden, Germany

2.2 Communication Channels (Email General, Phone, Contact Form)

• General Email: gobbltech@proton.me
  • We use the ProtonMail service provided by Proton AG, Route de la Galaise 32, 1228 Plan-les-Ouates, Switzerland for email communication. Data processing is based on Art. 6 Para. 1 lit. f GDPR. Proton AG processes data in a country with recognized adequate data protection level according to Art. 45 GDPR. Further information can be found at: https://proton.me/legal/privacy
• Contact Form: via the website https://impressum.gobbltech.com/contact.php
• Legal Notice: A telephone number is not mandatory (ECJ, C-298/07; BGH, PM 41/2025). For the legally required fast and direct contact option, we provide email and a contact form.

2.3 Privacy Contact: ,

For all privacy matters (e.g., information, correction, deletion, withdrawal, objection), you can reach us at:
datenschutz@trabista.app · privacy@trabista.app

2.4 Official Imprint (Binding URL)

Binding exclusively: https://impressum.gobbltech.com/\

2.5 Competent Data Protection Supervisory Authority (Address, Tel., Fax, Email, Web)

Saxon Commissioner for Data Protection and Transparency
Maternistraße 17, 01067 Dresden, Germany
Phone: +49 351 85471-101 · Fax: +49 351 85471-109
Email: post@sdtb.sachsen.de · Web: www.datenschutz.sachsen.de

2.6 Data Protection Officer (Status: Not Appointed)

There is currently no data protection officer appointed, as no legal obligation exists.
Should the obligation arise, the information will be added here immediately.

3. Definitions (GDPR Definitions)

Our privacy policy is based on the terminology used by the European legislator when adopting the General Data Protection Regulation (GDPR). Our privacy policy should be easy to read and understand for the public as well as for our customers and business partners. To ensure this, we would like to explain the terminology used in advance.

We use, among others, the following terms in this privacy policy:

3.1 Personal Data

Personal data means any information relating to an identified or identifiable natural person (hereinafter "data subject"). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.

3.2 Data Subject

Data subject is any identified or identifiable natural person whose personal data is processed by the controller.

3.3 Processing

Processing means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction.

3.4 Restriction of Processing

Restriction of processing is the marking of stored personal data with the aim of limiting their processing in the future.

3.5 Profiling

Profiling means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyze or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behavior, location, or movements.

3.6 Pseudonymization

Pseudonymization is the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.

3.7 Controller

Controller or controller responsible for the processing is the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data. Where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.

3.8 Processor

Processor is a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller.

3.9 Recipient

Recipient is a natural or legal person, public authority, agency, or another body, to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular inquiry in accordance with Union or Member State law shall not be regarded as recipients.

3.10 Third Party

Third party is a natural or legal person, public authority, agency, or body other than the data subject, controller, processor, and persons who, under the direct authority of the controller or processor, are authorized to process personal data.

3.11 Consent

Consent is any freely given, specific, informed, and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.

4. Principles of Data Processing

4.1 Lawfulness, Purpose Limitation, Transparency

• Lawfulness (Art. 5 Para. 1 lit. a, Art. 6 GDPR): We process personal data exclusively on a legal basis (in particular contract/contract performance, consent, legitimate interests, legal obligations). For consents, we inform in advance, document the consent demonstrably (timestamp/scope) and enable withdrawal at any time with effect for the future.
• Purpose Limitation (Art. 5 Para. 1 lit. b): Data is processed only for clearly defined, legitimate purposes (e.g., local travel management, optional cloud sync, advertising in the free version, support communication). We review purpose changes according to Art. 6 Para. 4 GDPR (compatibility assessment, see 7.2).
• Transparency (Art. 5 Para. 1 lit. a, Art. 12-14): We inform clearly and comprehensibly about purposes, legal bases, retention periods, recipients, third country transfers, data subject rights, and about the voluntary/mandatory nature of data provision. Changes to this statement are versioned and published synchronously in-app and on the website.

4.2 Data Minimization & Storage Limitation

• Data Minimization (Art. 5 Para. 1 lit. c): We collect only data that is necessary for the respective function. By default, the app runs offline; optional functions (cloud sync, premium APIs, advertising in the free version) are deactivatable or require consent (where necessary).
• Storage Limitation (Art. 5 Para. 1 lit. e): We store data only as long as necessary for the purposes or legal obligations exist. Specific periods and deletion concepts are described in Chapter 10 (including account deletion, inactivity rules, backup windows).
• Accuracy Principle (Art. 5 Para. 1 lit. d): We take appropriate measures to ensure that stored data is factually correct and up-to-date (self-management in-app; corrections upon request).

4.3 Integrity & Confidentiality (Security)

• Protection Goals (Art. 5 Para. 1 lit. f, Art. 32): We ensure confidentiality, integrity, availability and resilience of systems.
• TOMs (Overview): Encryption in transit (TLS) and at rest (e.g., SQLCipher locally, server-side encryption for cloud service), key management (Android Keystore/HSM), access controls (least privilege, RLS/JWT), logging/audit, hardening/firewalls, backup/recovery concepts (PITR), incident response procedures including notifications according to Art. 33/34 GDPR. Details in Chapter 11.
• Confidentiality in the App: No disclosure of local content without active user action (e.g., cloud sync, export). Optional sensitive content (e.g., allergies) remains exclusively local and encrypted.
• Access by Third Parties: Data processors act under instruction based on Art. 28 GDPR and DPA/SCC; sub-processors are integrated in a controlled manner (see Chapters 8-9).

4.4 Privacy by Design & by Default

• By Design (Art. 25 Para. 1): Functions are designed to process as little personal data as possible (offline-first, local encryption, proxy concepts for premium APIs, no obligation to use cloud accounts).
• By Default (Art. 25 Para. 2): Privacy-friendly default settings:
  • App usable without cloud sync by default.
  • Crashlytics/Analytics deactivated; activation only after opt-in.
  • Personalized advertising only after CMP consent (EEA/UK); otherwise non-personalized or completely removed by upgrade.
  • Notifications/Alarms only after OS opt-in.
• Accountability (Art. 5 Para. 2): We document processing (register according to Art. 30), manage legal bases/consents, conduct DPIA when necessary (Art. 35) and train processes for data subject rights, deletions and incidents.

5. Processing in the App (Operations & Legal Bases)

5.1 Local Data Processing (Standard Operation without Cloud)

Core Statement: The app is fully usable offline. All content is processed and stored exclusively locally in the private app storage of the device. No transmission to our servers or third parties, unless you actively trigger an online function (e.g., cloud sync, premium APIs) or an export.

5.1.1 Data Categories (incl. optional special categories locally only)

• Travel Data & Content
  • Travels/Trips (name, description, time period)
  • Participants (name/pseudonym, role, optional: contact details such as email/phone for emergencies)
  • Packing lists/Checklists (entries, status, notes)
  • Expenses/Costs (without payment methods; amounts/categories/notes)
  • Attachments (e.g., documents, images) -- in app-internal storage
  • Free text fields (can be filled in by the user as desired)
• App Settings
  • Language, UI preferences, Theme (Light/Dark)
  • Reminder/notification preferences (local)
  • Optional App Lock (PIN hash with salt; biometrics via OS)
  • Contextual help preferences (viewed topics, dismissed status for 11 help topics)
  • Tab visibility preferences (Customize Tabs, Premium Level 1+)
  • Statistics and Achievements (locally calculated travel analytics, progress tracking)
• Special Categories (Art. 9 GDPR) -- exclusively local & voluntary
  • e.g., health information (allergies, medication notes) only if voluntarily entered by you in free text fields.
  • Biometrics (fingerprint/face): no storage by the app; verification is performed system-side (OS).
• Explicitly not collected locally
  • No location tracking via GPS.
  • No calendar or contact book synchronization.
  • No external storage access (no READ/WRITE-External-Storage permission).

5.1.2 Purposes (Travel/Packing Planning, Exports, Local Reminders)

• Travel & Packing Planning: Structured organization of trips, participants, tasks and lists without network connection.
• Local Reminders/Alarms: Time-accurate notifications for tasks/events without data transmission (OS opt-in required).
• Exports/Sharing (optional, by user action):
  • ICS export (e.g., appointments) via FileProvider; you decide whether and with what you share/import the file.
  • File/Report export (e.g., PDF/CSV planned) also via FileProvider; without permanent app permission for external storage.
• Security/Convenience: App lock (PIN/biometrics), session timeout, encrypted local storage.

Important: Without your active action (e.g., activating cloud, sharing file), local content does not leave your device.

5.1.3 Legal Bases (Art. 6 Para. 1 a/b/f; Art. 9 Para. 2 a)

• Art. 6 Para. 1 lit. b GDPR (Contract/Contract Performance):
  • Core functionality of the app (travel/packing management, local storage, local reminders, exports at your request).
• Art. 6 Para. 1 lit. a GDPR (Consent):
  • Notifications/Alarms (OS opt-in), insofar as to be qualified as consent under platform law.
  • Voluntary entries of special categories (e.g., allergies) in free text fields.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest):
  • App security (e.g., app lock, integrity checks), abuse prevention within local app usage.
• Art. 9 Para. 2 lit. a GDPR (Explicit Consent):
  • For special categories (health information), if you voluntarily enter them.
  • Note: This data remains locally encrypted; no transmission to us or third parties.

Voluntary Nature & Consequences: Entry of optional data (especially sensitive information) is voluntary. Without this data, certain convenience functions (e.g., specially tagged reminders) may remain unused, but the core function of the app is retained.

5.1.4 Storage & Security (SQLCipher, Keystore)

• Storage location: exclusively internal app storage (sandbox); Room Database v10 with 13 tables (trips, travels, stays, checklists, luggage, participants, costs, participant_associations, notification_history, file_attachments, weather_cache, pois, place_contact_cache); no external device storage; other apps have no access.
• Encryption "at rest":
  • SQLite with SQLCipher (AES-256) for content databases.
  • Encrypted SharedPreferences for sensitive settings/flags.
• Key Management:
  • Android Keystore (hardware-backed, where available) for secure key storage.
  • PIN Protection: Storage as hashed value (SHA-256 with salt); no plaintext PIN.
• Biometrics:
  • Authentication via operating system API (e.g., fingerprint/face); no raw biometric data in the app.
• Transport Security:
  • For purely local usage, no network connection required.
  • If the device is network-capable (e.g., for later online features), cleartext traffic is disabled in the app (Network Security Config); generally TLS is enforced; critical domains are certificate-pinned (affects only online features).
• Backups (local):
  • Android Auto-Backup is enabled by default. Behavior depends on encryption status:
    • Database NOT encrypted: Full backup is transferred end-to-end encrypted via Android mechanisms to Google Drive (clientSideEncryption, max. 25MB).
    • Database WITH SQLCipher encrypted: Database excluded for security reasons; other app data (settings, preferences) are still backed up.
    • You can disable Android Auto-Backup at any time in system settings.
• Retention Period/Deletion (local):
  • Unlimited until manual deletion by you or app uninstallation (then local data is removed).
  • In-app functions allow targeted deletion of individual or all content.
• Exports:
  • Files are only provided via FileProvider (temporary, controlled access for the target app you choose).
  • No permanent read/write access to external storage areas.

Additional: There is no profiling, no automated decision-making and no silent background transmission of local content. All online processing is described separately in the following sections and requires your active use/consent (where required).

5.2 Optional Cloud Synchronization (Premium)

Core Statement: Cloud synchronization is voluntary and part of a paid premium offering. Without your active decision, the app remains purely local. When cloud is activated, selected data is transmitted encrypted and processed in the EU (Frankfurt/eu-central-1).

5.2.1 Data Categories (Account Email, IDs, Encrypted Content, IP/Logs)

• Account & Authentication Data
  • Email address (account identifier for Supabase Auth)
  • Password hash (server-side; hashing e.g., with bcrypt -- no plaintext)
  • Session/Access tokens (JWT), expiration times
• Device/Session Identifiers
  • Installation ID/UUID, possibly device alias (freely selectable)
  • Technical metadata for session management (timestamps, token status)
• App Content (synchronized user data)
  • Travels/Trips, participants (if recorded), packing/checklists, expenses (without payment methods), notes, attachments/files
  • Note: Content is transmitted transport-encrypted and stored server-side encrypted ("at rest"). End-to-end encryption with exclusively client-side key control is currently not planned (optionally possible later).
• Technical Logs
  • IP address and User-Agent during API access
  • Error/access events for stability and abuse prevention (minimized; no profiling)

5.2.2 Purposes (Sync, Auth, Stability, Support)

• Synchronization of your app content across multiple devices
• Authentication (login, token management, access control)
• Operations & Stability (scaling, fault tolerance, troubleshooting at meta/protocol level)
• Support (e.g., diagnosis based on timestamps/error codes -- without content review of your stored records, unless you grant explicit consent/access)

5.2.3 Legal Bases (Art. 6 Para. 1 a/b/f)

• Art. 6 Para. 1 lit. b GDPR (Contract/Contract Performance):
  • Provision of the expressly requested cloud service (sync, account, access from multiple devices)
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interests):
  • Operational security, abuse/fraud prevention, error diagnosis based on minimal log data
• Art. 6 Para. 1 lit. a GDPR (Consent):
  • Email communication for account flows (e.g., verification, password reset) as well as any purpose consents (if required in the future)

Voluntary Nature & Consequences: The cloud is optional. Without account/cloud activation, all local functions are available; only cross-device usage is unavailable.

5.2.4 Hosting/Region (Supabase, AWS Frankfurt, EU)

• Service Provider/Platform: Supabase (data processor)
• Primary Region & Storage Location: EU region, Frankfurt (AWS eu-central-1)
• Architecture/Isolation: Multi-tenant database; Row-Level-Security (RLS); access exclusively via JWT-protected endpoints; least privilege principle
• Transport/Storage Security: TLS for all connections (in transit), server-side encryption (at rest, typically AES-256)
• Email Delivery for Auth Flows: transactional via Scaleway (Paris/FR)

5.2.5 Backups & Recovery (PITR, 7 Days)

• Backups/Point-in-Time-Recovery (PITR): By default up to 7 days recovery window
• Purpose: Protection against data loss due to technical errors; no independent evaluation purpose
• Visibility: Backups are not productively accessible; recovery only in incident/recovery cases according to strict access processes

5.2.6 Deletion/Account-Delete & Inactivity Rules

• In-App Deletion (Cloud Account & Data):
  • You can delete your cloud account including all associated cloud content in the app (deleteAccountAndData).
  • Deletion occurs immediately in the production database.
  • Backups/PITR: Already created backups may persist for up to 7 days for technical reasons; after the PITR window expires, the data is permanently irrecoverable.
• Selective Deletion/Modification:
  • Individual records (trips/lists/attachments) can be deleted or modified by you at any time; changes are synchronized with the cloud.
• Inactivity Rules:
  • After 365 days without active login, the cloud account may be automatically marked for deletion; we notify in advance (once in-app/email notification is implemented).
• Impact on Local Data:
  • Cloud deletion does not affect your local data. Local content remains on your devices until you delete it yourself or uninstall the app.
• Data Portability:
  • Before account deletion, you can export your content (e.g., ICS; additional export formats as available).
• Identity Verification & Abuse Protection:
  • Account-critical actions (e.g., email change, password reset, account delete) are secured through confirmation flows (e.g., link/token).

Note on Support Cases: For access to content data, we require your explicit consent and a technical release. Standard support is based on meta/log data (timestamps, error codes) -- without access to content.

5.3 Notifications & Alarms (POST_NOTIFICATIONS / SCHEDULE_EXACT_ALARM)

Core Statement: Notifications/alarms serve exclusively for local reminders (e.g., packing list check, departure time). There is no server push; content is not transmitted to us or third parties.

5.3.1 Type of Function

• Local Push Notifications: Triggered by the device at the scheduled time.
• Exact Alarms (optional): For minute-accurate reminders, the app uses -- if allowed by you -- the system permission SCHEDULE_EXACT_ALARM (platform-dependent).
• No Remote Push/FCM/APNs: No device tokens are sent to third parties and no server-side push services are used.

5.3.2 Processed Data (local, without transmission)

• Planning Data: Timestamps/triggers (date/time), recurrence rules.
• Content Data: Short notification text (e.g., "Check packing list") and internal references to the affected entry/trip.
• Status Data: Whether notification was displayed/dismissed/tapped (only local, for UI control).
• No creation of personal profiles, no disclosure.

5.3.3 Purpose

• Reminder function for tasks/appointments you set within the app.
• User convenience & safety (e.g., timely reminder for important documents or medication reminder, if locally recorded by you).

5.3.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (Contract/Contract Performance) for the core function "reminder", if you actively configure it.
• Art. 6 Para. 1 lit. a GDPR (Consent) for the OS-side approval of notifications (POST_NOTIFICATIONS) and -- where legally necessary under platform law -- for exact alarms.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest) in reliable execution of the reminders you set (minimal system data, no profiling).
• Special Categories (Art. 9): Only if you voluntarily include such content in reminder texts; then exclusively local and based on Art. 9 Para. 2 lit. a (explicit consent through your input).

5.3.5 Permissions & Control

• POST_NOTIFICATIONS: Requested by the OS; you can consent or decline and revoke at any time in system settings.
• SCHEDULE_EXACT_ALARM: Separate system approval (depending on Android version/manufacturer) for particularly punctual alarms; revocable at any time.
• In-App Toggle: Notifications can additionally be globally disabled in app settings or adjusted per reminder.

5.3.6 Retention Period & Deletion

• Planning/Status data exists only locally and is deleted when you delete the reminder, remove the trip, disable notifications, or uninstall the app.
• No storage in cloud backups by us; Android auto-backup is disabled by default.

5.3.7 Security

• No plaintext transport, as no transport takes place (local function).
• Notification content remains on the device; the app uses OS interfaces without disclosure to our servers.
• Access to stored content occurs only within the app sandbox.

5.3.8 Consequences of Non-Provision

• If you do not enable notifications/alarms, the app remains fully usable; only time-accurate notifications are unavailable.
• Without SCHEDULE_EXACT_ALARM, reminders may be delayed depending on the device's power-saving mechanisms.

5.4 Advertising (Free Version Only) -- Google AdMob

Core Statement: In the free app version, we integrate Google AdMob. In Premium/Pro there is no advertising. For users in the EEA/UK, we implement a consent/preference dialog (CMP/UMP) on Android and the Apple App Tracking Transparency (ATT) framework on iOS.

5.4.1 Data Types (AD_ID / IDFA, IP-based Coarse Location, Interactions)

• Advertising ID: Android: AD_ID (from Android 12+ can be reset/removed by the user). iOS: IDFA (Identifier for Advertisers) -- readable only with ATT status authorized; otherwise iOS returns a null IDFA.
• Technical Usage/Device Information (e.g., app version, OS version, device model, language, screen parameters).
• IP Address (derivation of an approximate location at country/region level for delivery/fraud prevention).
• Ad Events/Interactions (e.g., impressions, clicks, error codes, frequency capping information).
• No payment data (advertising is independent of in-app purchases).
• No combination with local app content (travel data etc. is not transmitted for advertising purposes).

5.4.2 Personalized vs. Non-Personalized Advertising, CMP Consent

• Personalized Advertising (EEA/UK only with consent):
  • Profile/signal usage by Google for interest-based delivery (e.g., AD_ID / IDFA, interactions).
  • Android: We ask explicitly via the consent/preference dialog (CMP/UMP) for your consent; without consent no personalized advertising.
  • iOS: We ask via the Apple App Tracking Transparency (ATT) framework (ATTrackingManager.requestTrackingAuthorization). Only on authorized is the IDFA used and personalized ads served; on denied, notDetermined, or restricted we serve exclusively contextual/non-personalized advertising (SKAdNetwork). The Info.plist justification (NSUserTrackingUsageDescription) is transparently shown to the user in the ATT dialog.
• Non-Personalized Advertising (NPA):
  • No interest-based delivery; ad selection primarily contextual/aggregated.
  • Used by default in EEA/UK when no consent is given (or when you revoke it).
• Your Control:
  • In-App: Settings > Privacy/Advertising → Grant/revoke consent or set preference to non-personalized.
  • OS Settings (Android): "Reset/remove advertising ID" and "Disable personalized advertising".
  • OS Settings (iOS): Settings → Privacy & Security → Tracking (revoke ATT permission per app) and Settings → Privacy & Security → Apple Advertising (disable personalization).
• Child/Youth Protection: Target audience 18+; no child-directed treatment.

5.4.3 Upgrade without Advertising

• With Premium/Pro, AdMob is completely removed.
• Already saved advertising preferences then have no effect as long as your account/status Premium/Pro is active.

5.4.4 Processing Purposes

• Refinancing of the free app version.
• Operational Security/Fraud Prevention (e.g., frequency capping, abuse detection).
• Error Analysis at ad level (e.g., loading errors, mediation).

5.4.5 Legal Bases

• Art. 6 Para. 1 lit. a GDPR (Consent) for personalized advertising in EEA/UK.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest) for non-personalized advertising and for operation/fraud prevention.
• Withdrawal: At any time via the in-app preference dialog or OS settings (take effect ex nunc).

5.4.6 Recipients & Google's Responsibility

• Google Ireland Limited is the independent controller for AdMob processing (Art. 4 No. 7 GDPR).
• Relevant are the Google privacy information (including policies.google.com/privacy) and -- for integrated services -- notes on "How Google uses data" (policies.google.com/technologies/partner-sites).
• We receive no raw profiles; only aggregated or technical signals necessary for ad integration.

5.4.7 International Data Transfers

• With AdMob, third country transfers (especially USA) may occur.
• Safeguarded by EU Standard Contractual Clauses (SCCs) and -- where applicable -- EU-US Data Privacy Framework (DPF).
• Additionally, Google implements technical/organizational measures against unauthorized access.

5.4.8 Retention Periods

• Ad/event-related data is retained by Google according to their own policies (typically on the order of up to 14 months for certain advertising signals).
• We ourselves do not store personalized ad profiles.

5.4.9 Security

• Transport encryption (TLS) between app and ad endpoints.
• App sandboxing: Advertising has no access to local content (trips/attachments) outside the OS-released ad interfaces.

5.4.10 Consequences of Non-Provision / Refusal

• Without consent (EEA/UK), we show non-personalized advertising; the app remains fully usable.
• With Premium/Pro, advertising is completely eliminated.
• If AD_ID is deleted/blocked by the OS, there may be less relevant/duplicate ads; app functionality is retained.

5.4.11 Transparency & Links (for the Privacy Policy)

• Google Privacy: https://policies.google.com/privacy
• How Google uses data: https://policies.google.com/technologies/partner-sites
• Advertising/Technologies: https://policies.google.com/technologies/ads

Note (Website): On the website, no AdMob advertising is delivered; Section 5.4 concerns only the app.

5.5 Weather & Geocoding (Photon/OSM; optionally Google Maps via Proxy)

Core Statement: For location search/geocoding and (in the premium plan) weather information, the app uses data-efficient EU services by default. Free users: Photon (komoot) with OSM/Nominatim as fallback. Premium users: optionally Google Maps Geocoding (via EU proxy), plus OpenWeather (weather) -- also via EU proxy. No GPS movement profiles are created; queries are based on manually entered locations or user-triggered coordinate requests.

5.5.1 Data Categories

• Search/Query Content: User-entered location names, addresses, POIs, or coordinates (possibly derived from target information by the user).
• Technical Metadata: Time of query, User-Agent, possibly IP address (on server/proxy side), error codes/rate limit signals.
• No Personal Identifiers: No names/emails/account IDs are transmitted to geocoding/weather APIs.
• No Persistent Location Tracking: The app uses no continuous GPS tracking; location reference is solely derived from your search terms or manually set destinations.
• Cache data (Smart Contact Auto-Fill): 30-day cache for contact information (phone number, website) of hotels/hostels in local place_contact_cache table for API cost optimization.

5.5.2 Processing Purposes

• Geocoding/Completion: Location/address search and conversion to coordinates (and vice versa) for convenient travel planning.
• Map/Context Functions (optional): More accurate results through premium geocoding (Google Maps).
• Weather Information (Premium): Display of forecasts/conditions for travel destinations for better planning.

5.5.3 Services & Operating Model

• Free (Standard):
  • Photon (komoot, DE): Primary geocoding service; queries pseudonymous, without user identifiers.
  • OSM/Nominatim (EU/UK servers): Fallback for geocoding/reverse geocoding.
• Premium (optional):
  • Google Maps Geocoding (Google Ireland): Higher precision/coverage; all requests are proxied through an EU-based Supabase Edge Function (no direct app call to Google).
  • OpenWeather (UK): Weather data; access via EU proxy (Supabase Edge) with coordinates as parameters.
  • Smart Contact Auto-Fill (NEW: 2025-10-24): Automatic filling of contact information for hotels and hostels via Google Places API (Enterprise) via EU proxy.
    • Auto-fills: Phone number and website URL
    • 30-day cache for API cost optimization (place_contact_cache table)
    • Only activated for business types: Hotels ✅, Hostels ✅, Airbnb/Private ❌
    • User can manually override/edit
    • Access to 170M+ business database
• Proxy/Edge Layer (Supabase, Region EU-Central/Frankfurt):
  • Mediates requests, decouples your app from the external service, reduces exposure of your IP to third parties and enables rate limiting/error handling.
  • Collects minimal technical logs (timestamp, app client IP, status/error code) for operational security and abuse prevention.

5.5.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (Contract/Contract Performance): Required for location/destination search and -- for premium -- for weather display for the travel features you use.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest): Operation/stability/security of interfaces (logging at meta level, rate limits, error diagnosis).
• Art. 6 Para. 1 lit. a GDPR (Consent): Only if individual optional detail functions require consent in the future (currently not planned).

5.5.5 Recipients / Responsibility

• Photon (komoot GmbH, DE): Recipient of pseudonymous search queries.
• OpenStreetMap Foundation (EU/UK servers): Recipient of pseudonymous search queries in fallback.
• Google Ireland Limited (Premium Geocoding only): Recipient of EU proxy-forwarded geocoding parameters; Google acts in its own responsibility.
• OpenWeather Ltd. (UK, Premium Weather only): Recipient of EU proxy-forwarded coordinate parameters (weather); OpenWeather acts in its own responsibility.
• Supabase (EU Proxy/Edge): Data processor for mediation/aggregation of API requests and minimal logging (operation/defense).

5.5.6 International Data Transfers & Safeguards

• Photon/OSM: Processing on DE/EU/UK servers; no regular third country transfer.
• Google Maps (Premium Geocoding): Google may process data EU-internally and -- depending on service -- also to the USA. Safeguarded via EU-SCC and possibly EU-US DPF (Google).
• OpenWeather (UK): UK is secured by adequacy decision from the EU; additionally request via EU proxy.
• Supabase Edge (EU): Processing/logs in EU region; any sub-processors are integrated via DPA/SCC.

5.5.7 Retention Periods

• App-side: Search terms/coordinates are retained only in the necessary functional context (e.g., in current project/trip). No independent "history" unless you keep it yourself in your travel data.
• Proxy/Edge Logs (Supabase): Minimal logs for operation/security; rotate after short technical period (operational); no creation of user profiles.
• Services (Google/OpenWeather/Photon/OSM): Storage according to their own policies; we transmit no user identifiers, only search/coordinate parameters.

5.5.8 Security

• Transport: Exclusively TLS between app ↔ proxy (Supabase) ↔ external API.
• Data Minimization: No email/account ID/name in API calls; only search string/coordinates.
• Architecture: Proxy model (EU-based) protects against direct third-party exposure of app IP; rate limit and error sanitizing prevent unnecessary data flows.
• At-Rest Protection: Server-side encryption at Supabase; local travel data still SQLCipher-encrypted (see 5.1.4).

5.5.9 Control & Consequences of Non-Provision

• Free Usage: Photon/OSM are available without account. If you do not perform location search, the app remains functional (manual entries possible), though with limited convenience (no auto-completion, no reverse geocodes).
• Premium Geocoding (Google): Purely optional; without use, the app remains usable (you then use the free geocoders).
• Premium Weather (OpenWeather): Also optional; without use, no weather display, all other functions remain.

5.5.10 Transparency & References (for the Privacy Policy)

• Photon (komoot) -- Privacy:
• OpenStreetMap Foundation -- Privacy Policy:
• Google -- Privacy: https://policies.google.com/privacy
• "How Google uses data" (Partner Sites): https://policies.google.com/technologies/partner-sites
• OpenWeather -- Privacy: https://openweather.co.uk/privacy-policy (or respective provider's policy page)

Note (Website): On the website itself, no geocoding or weather queries occur. Section 5.5 concerns exclusively app functions (and the EU proxy/edge layer in cloud operation).

5.6 Crash Reporting & Analytics (Android, Opt-in) -- Firebase

Core statement (Android): Firebase Crashlytics is active in release builds, but sends data only with explicit consent (opt-in) to Google. Firebase Analytics is disabled by default. Activation of both services occurs only after consent within the app (EEA/UK via CMP/UMP). In Debug/Dev/Benchmark builds, both are completely disabled. Without consent, no crash or usage data is transmitted to Google.

iOS note: On iOS, we do not use Firebase but Sentry (EU region). See section 5.10 for details.

5.6.1 Scope of Functions (Opt-in required)

• Firebase Crashlytics (Error Reports): Capture of crashes and severe exceptions for stability improvement (stack traces, affected classes/methods, timestamps).
• Firebase Analytics (Usage Analysis): Aggregated event and screen calls for product improvement (e.g., feature usage frequency, app starts, session duration). No content-related tracking (no evaluation of your travel/packing data).

5.6.2 Data Categories (when function is activated)

• Device/App Metadata: App version/build, OS version, device model, language/region, network status (e.g., online/offline).
• Crash Data (Crashlytics): Timestamp, stack trace, process/thread info, app state (foreground/background), possibly last log messages (only technical contexts).
• Analysis Events (Analytics): Event name and parameters (e.g., "screen_view", "first_open"), session ID/time, coarse geolocation via IP (country level).
• Identifiers: Pseudonymous app instance IDs/session IDs; no assignment to your cloud account or your email; no use of local content; no contact or payment data.
• Exclusions: No collection of special categories (Art. 9 GDPR), no content from your travels/files, no continuous location tracking.

5.6.3 Processing Purposes

• Stability & Quality: Prioritization of bug fixes (crash clusters), prevention of regression errors.
• Product Improvement: Understanding which screens/features are used to improve UI/UX -- without user profiles or personal data evaluation.

5.6.4 Legal Bases

• Art. 6 Para. 1 lit. a GDPR (Consent): Prerequisite for any data transmission to Firebase (Crashlytics/Analytics).
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interests): Internal local logs (without transmission) for error analysis, where required.
• Withdrawal: At any time in app settings possible; takes effect for the future.

5.6.5 Responsibility & Recipients

• Google Ireland Limited is the independent controller for Firebase processing.
• Our app receives no raw profiles; we only see aggregated reports/metrics or crash clusters.

5.6.6 International Data Transfers

• Firebase may transfer data to countries outside the EEA (especially USA).
• Safeguarded by EU Standard Contractual Clauses (SCCs) and -- where applicable -- EU-US Data Privacy Framework (DPF) as well as additional technical/organizational measures by Google.

5.6.7 Retention Periods

• At Google (Firebase): According to Google's own retention policies (crash and event data are typically retained in aggregated/shortened form for longer periods; detailed states time-limited).
• At our end: No storage of personal raw data from Firebase; we only keep configuration-technical information (e.g., whether consent was granted/revoked).

5.6.8 Security

• Transport: TLS-secured transmission app ↔ Firebase endpoints.
• Data Minimization: No local content data in crash/analytics events; deactivation by default; collection only after opt-in.
• Access Control: Limited access to Firebase consoles (role-based, need-to-know).

5.6.9 User Control & Consequences of Non-Provision

• Opt-in/Opt-out in-app: Menu Privacy → Separate toggles for Crashlytics and Analytics.
• Consequences of Refusal: The app remains fully functional; we simply receive no telemetry for improvement/stability analysis from your device.

5.6.10 Transparency & Links (for the Privacy Policy)

• Google Privacy: https://policies.google.com/privacy
• "How Google uses data" (Partner Sites): https://policies.google.com/technologies/partner-sites
• Firebase Crashlytics/Analytics -- Product Info: (viewable on Google's product pages)

Note (Status): At the time of this statement, Crashlytics and Analytics are deactivated in the app. Activation occurs only after explicit consent (opt-in) and is revocable at any time.

5.7 Purchases & Subscriptions (ACTIVE) -- Google Play Billing & Apple App Store (StoreKit) via RevenueCat

Core Statement: Processing via Google Play (Android) or Apple App Store / StoreKit 2 (iOS) with server-side, cross-platform subscription management through RevenueCat. We receive no payment method data (e.g., credit card/IBAN). In the app, only metadata required for license verification is processed. The system is productively active with backend verification via RevenueCat and Real-Time Developer Notifications (RTDN / App Store Server Notifications).

5.7.1 Data Categories

• Processed by Google (own responsibility, Android):
  Google account, payment profile, billing/invoicing data, transaction history, possibly device/purchase protection signals. (We do not see this data.)
• Processed by Apple (own responsibility, iOS):
  Apple ID, payment profile, billing/invoicing data, Apple Transaction IDs, subscription history, possibly device/purchase protection signals. (We do not see this data.)
• Processed by RevenueCat (subscription management, as data processor):
  • Anonymous User ID ($RCAnonymousID -- generated by RevenueCat, no link to app account/email)
  • Purchase Token / Transaction ID (Android: Google Play Purchase Token; iOS: Apple Transaction ID / JWS signature, each for server-side validation)
  • Product/Subscription Information (plan, duration, renewal, status/expiration date)
  • App/Platform Metadata (OS version, app version, platform, locale)
  • IP Address (during communication between app SDK and RevenueCat backend)
• Processed by us (license/function-related):
  • Entitlement Status (active/inactive, retrieved from RevenueCat)
  • Product/Subscription Information (plan, duration, status/expiration date)
  • Upgrade/Feature Flag (Free/Premium/Pro) in encrypted app preferences)
  • Device/App Metadata (version, language, possibly anonymous installation ID for license checks)
  • No payment methods, no billing address, no plain data from payment profile

5.7.2 Processing Purposes

• License Verification & Activation of paid features (e.g., cloud premium, extended geocoding/weather functions, ad-free usage)
• Subscription Lifecycle Management via RevenueCat (renewals, cancellations, grace periods, billing issues)
• Abuse/Fraud Prevention (e.g., token validity, improper multiple use)
• Billing/Support Traceability at functional level (without payment details)

5.7.3 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (Contract/Contract Performance): Purchase/subscription processing via Play Store, activation of paid app features
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest): License protection, fraud prevention, technical traceability
• Art. 6 Para. 1 lit. c GDPR (Legal Obligation): Insofar as legal retention/evidence for business records is required (only insofar as personal data actually arises with us)

5.7.4 Process & Recipients

• Purchase/Renewal occurs directly in Google Play (Android) or directly in the Apple App Store / StoreKit 2 (iOS); Google and Apple are independent controllers for this.
• The app communicates via the RevenueCat SDK with the RevenueCat backend (USA), which performs server-side validation against Google Play or the Apple App Store.
• RevenueCat returns the entitlement status (permissions) to the app to locally activate features.
• Real-time notifications: Google (Android) notifies RevenueCat via Real-Time Developer Notifications (RTDN); Apple (iOS) via App Store Server Notifications V2 about subscription changes.
• No disclosure to other third parties. RevenueCat is contractually bound as data processor (see Section 8.6).

5.7.5 International Data Transfers

• Google may process data outside the EEA (especially USA). Safeguarded according to Google via SCC and -- where applicable -- EU-US DPF.
• Apple processes customer data primarily through Apple Distribution International Ltd. (Ireland, EU); intra-group transfers to the USA are possible and, per Apple, safeguarded via SCC and -- where applicable -- the EU-US Data Privacy Framework (DPF).
• RevenueCat processes data on AWS in the USA. Safeguarded via EU Standard Contractual Clauses (SCC) and -- where applicable -- EU-US Data Privacy Framework (DPF) (see Section 8.6).

5.7.6 Retention Periods

• RevenueCat: Subscription/transaction data stored during active business relationship and deleted after contract end according to DPA.
• Subscription/License Status (at our end): During active term, then + 90 days (grace, reversal/error analysis), then deletion/anonymization.
• Upgrade/Feature Flag (local): Until app uninstallation or downgrade (encrypted preferences).
• Transaction History/Payment Methods: Not stored by us (reside with Google).

5.7.7 Security

• Transport: Exclusively TLS between app ↔ RevenueCat SDK ↔ RevenueCat backend ↔ Google Play Billing.
• At rest (RevenueCat): Encryption "at rest" on AWS infrastructure; SOC 2 Type II certified.
• At rest (app): SQLCipher/encrypted preferences.
• Key Management: Android Keystore (app); RevenueCat manages keys according to SOC 2 standards.
• Access Controls: Role/rights concept, need-to-know, logging of critical accesses.

5.7.8 Control & Consequences of Non-Provision

• Without Purchase/Consent, the app remains fully usable, but without premium features or with advertising (free).
• Withdrawal/Refund is processed within Google Play policies; after reversal, license status is revoked.
• Device Change/Reinstallation: License is restored via Google signals; possibly brief validation phase (offline limited).

5.7.9 Transparency & References

• Google Privacy: https://policies.google.com/privacy
• Google Play -- Payments & Subscriptions (Help Center): https://support.google.com/googleplay/answer/2476088
• Google Terms of Use: https://policies.google.com/terms
• Apple Privacy: https://www.apple.com/legal/privacy/
• Apple Media Services Terms: https://www.apple.com/legal/internet-services/itunes/
• RevenueCat Privacy Policy: https://www.revenuecat.com/privacy
• RevenueCat DPA: https://www.revenuecat.com/dpa

5.8 Communication & Support (In-App Email, Website Contact Form)

Core Statement: We offer support via direct email from the app as well as a contact form on the website. There is no ticket/helpdesk system; messages are processed as emails (transport TLS). Website forms are sent via Scaleway Transactional Email (Paris/FR).

5.8.1 Channels

• In-App Email: Link/button opens the standard mail app of the device with our destination address (no sending via our app servers).
• Website Contact Form (PHP website (without CMS)): Form contents are received server-side and delivered to us as email via Scaleway. No storage of form message in website database (unless technically required for error storage/queue).

5.8.2 Contact Details

• General: gobbltech@proton.me
• Privacy: datenschutz@trabista.app, privacy@trabista.app

5.8.3 Processed Data (Categories)

• Contact Data: Sender email, optionally name/signature, possibly phone/postal address (if provided).
• Message Content: Free text, file attachments (only if you attach them).
• Metadata/Logs: Send/receive time, technical headers (Message-ID, routing), delivery status, Scaleway delivery logs (success/failure, bounce/complaint).
• Website Form: additionally timestamp, possibly IP/UA in web server log (see 6.1); form itself does not store in DB.
• No evaluation of local app content; no automated profiling.

Special Categories (Art. 9 GDPR): Please do not transmit sensitive content (e.g., health data) via email/form. If this is exceptionally necessary, processing occurs only based on your explicit consent (Art. 9 Para. 2 lit. a) and exclusively to process your request.

5.8.4 Purposes

• Communication & Support Processing (answering your inquiry, problem solving, follow-up questions).
• Documentation of the process, where necessary (e.g., proof of processing, warranty/contract).
• Operational Security of form sending (Scaleway logs for error analysis/deliverability).

5.8.5 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (Contract/Initiation): Inquiries about use, contract, service, defects.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest): General communication, support organization, IT security/deliverability (minimal logs).
• Art. 6 Para. 1 lit. c GDPR (Legal Obligation): Retention/evidence, where applicable (e.g., commercial/tax records, only if personal).
• Art. 6 Para. 1 lit. a GDPR / Art. 9 Para. 2 lit. a GDPR: If you voluntarily transmit sensitive data (explicit consent required).

5.8.6 Recipients / Data Processors

• Email Delivery (Form): Scaleway SAS, Paris/France -- Data Processor (Art. 28 GDPR), EU location, no third country transfer planned.
• Mail Hosting/Client: Our respective mail providers/mail clients for retrieval/delivery (TLS).
• No disclosure to third parties for advertising/analysis purposes.

5.8.7 International Data Transfers

• Not planned. Processing and sending run within the EU (Scaleway Paris). Should a sub-processor outside the EEA be used for technical reasons, this occurs exclusively with appropriate safeguards (especially SCC) and documented transfer impact assessment.

5.8.8 Retention Periods & Deletion

• Email Inbox: Fundamentally no automatic deletion; manual deletion after problem resolution.
• Scaleway Logs: Delivery logs 30 days; bounce/complaint lists 90 days.
• Legal/Evidence Obligations: If applicable (e.g., correspondence on contract/billing issues), retention according to legal periods; otherwise deletion once purpose ceases.

5.8.9 Security

• Transport Encryption: Email delivery via TLS (opportunistic/required depending on participating mail server). End-to-end encryption (PGP/SMIME) occurs only if you use it yourself.
• Form Protection: CSRF protection, spam/abuse prevention (without tracking), input validation; no analytics/marketing pixels.
• Access Control: Access only for authorized persons (need-to-know), logging of administrative accesses, secure account/client configuration (MFA, strong passwords).

5.8.10 Voluntary Nature & Consequences of Non-Provision

• Provision of your contact/content data is voluntary. Without sufficient information, we may not be able to process your request or may need to ask follow-up questions.
• Alternatives: Instead of the form, you can also contact us directly via email or mail (see Section 2.2).

5.8.11 Transparency Notes (for the Privacy Policy)

• Scaleway (Privacy): Information in Scaleway DPA/policies (EU hosting, data processing).
• Email Security Notice: Emails are not necessarily end-to-end encrypted despite TLS. Transmit sensitive content only if necessary and preferably encrypted.

Note: Please direct inquiries about data subject rights preferably to datenschutz@trabista.app or privacy@trabista.app (see Section 12.10).

5.9 App Permissions & Device Interfaces

Principle: We request only the permissions that are absolutely necessary for the respective function (runtime permissions). Every permission can be revoked at any time in system settings. Without permission, the app remains basically usable; only the associated convenience/online functions are unavailable.

5.9.1 INTERNET

Purpose:

• Cloud Synchronization (Premium), authentication (Supabase Auth)
• EU Proxy/Edge for Geocoding/Weather (Supabase)
• Advertising in free version (AdMob)
• Google Play Billing ACTIVE -- license verification/activation
• General TLS-protected communication; cleartext traffic is disabled (Network Security Config)

Processed Data (typical):

• IP address, timestamp, minimally required protocol/error codes; for used online features, the purpose-necessary parameters (e.g., search string/coordinates via EU proxy, cf. 5.5)

Legal Bases:

• Art. 6 Para. 1 lit. b GDPR (contract/provision of selected online functions)
• Art. 6 Para. 1 lit. f GDPR (operational security, abuse/error prevention)
• Art. 6 Para. 1 lit. a GDPR (if an individual online feature requires consent)

Control/Consequences of Non-Provision:

• Without internet, the app remains fully usable offline (local planning, reminders, exports). Online functions (cloud, weather/geocoder proxy, advertising, billing) are then unavailable.

Security:

• TLS 1.3 (in transit), certificate pinning for critical endpoints; server-side encryption "at rest" (for used services)

5.9.2 POST_NOTIFICATIONS / SCHEDULE_EXACT_ALARM

Purpose:

• Local reminders/notifications, optionally exact alarms for minute-accurate delivery

Processed Data:

• Only local triggers/status (time, title/short notification text); no server pushes, no transmission to third parties

Legal Bases:

• Art. 6 Para. 1 lit. b GDPR (fulfillment of your reminder configuration)
• Art. 6 Para. 1 lit. a GDPR (OS-side consent to notifications/alarms)
• Possibly Art. 9 Para. 2 lit. a (if you voluntarily include sensitive content in reminder texts)

Control/Consequences:

• Opt-in via OS; revocable at any time in system/app settings. Without permission, the app remains usable; reminders/exact alarms are unavailable or may be delayed.
• Details see 5.3.

5.9.3 AD_ID (com.google.android.gms.permission.AD_ID)

Purpose:

• AdMob in free version (frequency control, fraud prevention, possibly personalization only with consent in EEA/UK)

Processed Data:

• Advertising ID (AD_ID), technical signals (app/OS version, device characteristics), IP for coarse location (country/region), ad events

Legal Bases:

• Personalized Advertising: Art. 6 Para. 1 lit. a GDPR (consent via CMP/UMP)
• Non-Personalized Advertising & Operations: Art. 6 Para. 1 lit. f GDPR

Control/Consequences:

• In-App Preference: Grant/revoke consent;
• OS Settings: Reset/deactivate AD_ID;
• Upgrade (Premium/Pro): Advertising completely removed.
• Details see 5.4.

Security/Delineation:

• No access from advertising to local app content (trips/attachments); sandboxing by OS/SDK.

5.9.4 File Export via **FileProvider** (no external storage access)

Purpose:

• Secure sharing/exporting (e.g., ICS files, later possibly PDF/CSV) without permanent storage permissions

Functionality & Data Flow:

• Export files are created in internal app storage and provided via Content URIs of the FileProvider.
• The app grants the target app you choose temporary URI access rights.
• No READ/WRITE permission on "external" device storage; no general file system access.

Legal Bases:

• Art. 6 Para. 1 lit. b GDPR (export/sharing at your request)

Control/Consequences:

• Export is optional. Without export, all functions remain; no files are created/shared.

Security:

• Temporary, narrowly limited URI grants; content remains in app sandbox until you share or delete it.

5.9.5 **No Calendar Access** (only **ICS Export**)

Purpose/Delineation:

• The app requests no calendar permissions (no READ_CALENDAR/WRITE_CALENDAR).
• Appointments can be exported as ICS; the import action is performed by your calendar app.

Legal Bases:

• Art. 6 Para. 1 lit. b GDPR (export at your request)

Control/Consequences:

• You decide whether and where to export. Without export, the app remains fully functional.

5.9.6 READ_CONTACTS (Optional)

Purpose:

• Import participant data from device contacts
• Facilitates adding travel companions through quick contact import

Processed Data:

• Name, email, phone number from selected contacts
• Only upon explicit user request when adding participants
• No automatic synchronization or background access
• Data stored exclusively locally in the app

Legal Basis:

• Art. 6(1)(b) GDPR (convenience feature for trip planning)
• Art. 6(1)(a) GDPR (OS-level consent to permission)

Control/Consequences:

• Opt-in via OS permission; revocable at any time in system settings
• Without permission, participants can be entered manually
• App requests permission only when needed (e.g., first attempt to import a contact)

Security:

• No access to contacts without explicit OS permission
• Imported data subject to same security measures as manually entered participant data (optional SQLCipher encryption)
• No transmission of contact data to servers without cloud sync

5.10 Error & Performance Analysis (iOS) -- Sentry (EU Region)

Core statement: In the iOS app, we use Sentry (sentry-cocoa SDK) for automated capture and analysis of application crashes and performance issues. Processing takes place primarily in the EU region (ingest.de.sentry.io; AWS Frankfurt). No IP addresses, no user identifiers, and no email addresses are transmitted to Sentry. The legal basis is legitimate interest pursuant to Art. 6 Para. 1 lit. f GDPR; a right to object under Art. 21 GDPR applies.

5.10.1 Scope of Functions

• Crash reporting: Automatic capture of crashes and serious exceptions (stack traces, affected classes/methods/lines, timestamps, release tag).
• Performance monitoring: Sampled transactions to identify bottlenecks (app start, navigation, network calls). Sampling rate 20 % in production.
• Profiling: Sampled CPU/time profiles of individual sessions for performance analysis. Sampling rate 10 % of sessions in production.
• View-hierarchy snapshot at crash: Snapshot of the current UI structure at the time of a crash for improved error diagnostics.
• Log forwarding: Selected OSLog/print output from the app is forwarded as structured log events to Sentry (enableLogs).
• Only release builds transmit data to Sentry; in debug builds the SDK runs locally for development purposes.

5.10.2 Data Categories

What Sentry receives:

• Stack traces / exception context (function name, file, line, thread state).
• Device/OS/app metadata: device model, iOS version, app version/build, release tag (production / debug), language/region, network state.
• Breadcrumbs: short event traces leading up to the error (e.g., navigations, automatic network events; no content data).
• Performance/profiling traces (anonymized, aggregated).
• View-hierarchy snapshot at the crash time (UI structure without content data; text in input fields is not deliberately captured, but a full exclusion of sensitive content cannot be technically guaranteed).
• Forwarded log lines (from OSLog/print).

What Sentry does NOT receive:

• No IP address (sendDefaultPii = false; default setting, not overridden in Trabista).
• No user identifier (no SentrySDK.setUser(...) call in the app).
• No email address, no travel/luggage data, no file attachments, no payment/purchase information.
• No special categories under Art. 9 GDPR (e.g., allergies in local free-text fields remain strictly local).

5.10.3 Processing Purposes

• Stability: prioritization and resolution of crashes and serious errors.
• Performance quality: detection of bottlenecks and regressions in the iOS app.
• Operations & error diagnostics: fast isolation of production problems.

5.10.4 Legal Basis & Balancing of Interests

• Art. 6 Para. 1 lit. f GDPR -- legitimate interest in the stable, secure, and performant operation of the iOS app.
• Balancing of interests: Since no personal identifiers (IP, user ID, email) are transmitted and processing takes place primarily in the EU, the impact on users' rights is low; there is no profiling and no advertising use. The interest in stability and quality prevails.
• Right to object (Art. 21 GDPR): Users may object to the processing for the future (contact: see Section 18). An objection means that future crash/performance data will not be transmitted to Sentry; the app remains fully functional.
• No opt-in required: Since no personal identifiers are sent and no end-device trackers within the meaning of § 25 TDDDG are used, no consent is required.

5.10.5 Responsibility, Data Processing & Recipients

• Provider: Functional Software, Inc. (d/b/a Sentry), 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA.
• EU representative: Sentry GmbH, Berlin, Germany.
• Role: Data processor under Art. 28 GDPR; a Data Processing Agreement (DPA) is in place.
• Sub-processors: in particular Amazon Web Services, Inc. (AWS Frankfurt, EU) as hosting provider for the EU region.

5.10.6 International Data Transfers

• Primary region: EU (Frankfurt, AWS) -- DSN endpoint ingest.de.sentry.io. No planned primary transfers to the USA.
• Support/maintenance access by Sentry personnel in the USA may be required within the DPA framework; safeguarded via EU Standard Contractual Clauses (SCC) and -- to the extent Functional Software, Inc. is DPF-certified -- the EU-US Data Privacy Framework (DPF) (fallback).
• Additional safeguards: TLS transport, EU residency at database/storage level, strict access controls (least-privilege, audit logs) per the DPA.

5.10.7 Retention Periods

• At Sentry: per our current plan max. 90 days (standard on business plans); automatic deletion on Sentry's side thereafter. Aggregated/summary statistics may be retained longer in anonymized form.
• At our end: no permanent storage of raw events; only the issue metadata necessary for error analysis/product improvement in the Sentry interface.

5.10.8 Security

• Transport: TLS 1.3 between app and ingest.de.sentry.io.
• At rest: encryption on AWS infrastructure; Sentry is SOC 2 Type II and ISO 27001 certified.
• Access: role-based, need-to-know, logged; our access to the Sentry console is limited to the product/tech team.

5.10.9 User Control & Consequences of Non-Provision

• No in-app opt-out toggle: Since no personal identifiers are processed, no consent/opt-out toggle is provided. Users who still wish to object to the processing may exercise their right to object under Art. 21 GDPR (contact see Section 18).
• Consequences of an objection: The app remains fully usable; we no longer receive crash/performance data from the device, which can delay bug fixes.

5.10.10 Transparency & References

• Sentry Privacy Policy: https://sentry.io/privacy/
• Sentry Data Processing Agreement (DPA): https://sentry.io/legal/dpa/
• Sentry -- data collected (Apple/iOS): https://docs.sentry.io/platforms/apple/data-management/data-collected/
• Sentry Trust Center: https://sentry.io/trust/
• EU Region (FAQ): https://sentry.zendesk.com/hc/en-us/articles/25074658211227

Note (Website): The PHP website does not load any Sentry SDK. Section 5.10 concerns exclusively the iOS app.

6. Website Processing

6.1 Server Log Files (Contents, Purposes, Separate Storage)

Core statement: Trabista's PHP website (without CMS) operates without tracking. When pages are accessed, technically necessary server logs are generated. These serve exclusively for operation, security, and error analysis.

6.1.1 Processed Log Data (typical)

• IP address of the requesting device
• Date and time of access (timestamp)
• Accessed resource/URL, HTTP method (e.g., GET/POST)
• Status code (e.g., 200, 404, 500), amount of data transferred
• Referrer URL (the previously visited page, if transmitted by the browser)
• User agent (browser/OS type and version, device type)
• Error/diagnostic entries in error logs (e.g., stack traces for server errors)
• Server-side protection signals (e.g., rate limit hits, firewall events, bot/spam indicators)

No content analysis: There is no analysis of your input contents for marketing/profiling purposes.
No merging with other data sources (e.g., app usage data).

6.1.2 Purposes of Processing

• Operation & functionality of the website, delivery of content
• Security/defense against attacks, abuse and fraud prevention (e.g., DDoS detection, bot defense, firewall rules)
• Error analysis & stability, performance monitoring, capacity planning
• Traceability in case of technical disruptions and unlawful access

6.1.3 Legal Bases

• Art. 6 Para. 1 lit. f GDPR (legitimate interest) -- secure, stable website operation and defense against attacks
• Art. 6 Para. 1 lit. c GDPR (legal obligation) -- if and to the extent we are legally obligated to provide or retain data upon order (e.g., in the context of investigations)

6.1.4 Storage Duration & Deletion

• Access logs: short-term retention for technical operation (typically 7-14 days).
• Error logs/security events: Storage until resolution/clarification of the incident; in case of security incidents, a temporary extension may be necessary.
• Thereafter deletion or anonymization (e.g., truncation of the IP address).

(Specific periods depend on technical necessity in hosting operations; there is no long-term retention for marketing purposes.)

6.1.5 Recipients & Data Processing

• Hosting/operating service providers (data center/managed hosting) as data processors pursuant to Art. 28 GDPR -- processing strictly purpose-bound according to instructions.
• IT security service providers (if engaged) within the scope of disruption/incident analyses -- likewise data processors.
• Authorities/law enforcement -- only within the legally prescribed framework and in case of corresponding obligation.

6.1.6 Separation from Other Data / No Profiling

• Server log files are kept separate from other user-related data (e.g., contact form data, see 6.2).
• No profiling, no cross-site tracking, no marketing/analytics purposes.

6.1.7 Processing Security

• TLS encryption (HTTPS) for transmission paths
• Hardening & firewalling at server/application level, rate limiting, bot/spam protection
• Access/role principle (need-to-know), administrative access logged
• Regular updates/patches (PHP website (without CMS), server stack)

Note: In connection with Section 6.4 (cookies & tracking), we confirm that no analytics/marketing cookies are set and no third-party trackers are loaded.

6.2 Contact Form & Email (Purposes, Contents, Sending)

Core statement: On the PHP website (without CMS), we provide a contact form. Submissions are not stored in the website database but sent as email to us. Sending occurs via Scaleway Transactional Email (Paris/FR). Alternatively, you can write to us directly by email.

6.2.1 Functional Description (Website)

• Contact form: Transmission of form fields to the web server; immediate forwarding as email to our destination mailboxes.
• No ticket system: There is no separate helpdesk; cases are handled as emails.
• No database storage: Form contents are not persistently stored in the PHP website (without CMS) (except short-term technical buffers/error queues, if necessary).

6.2.2 Processed Data (Contents)

• Required/voluntary fields (form-dependent): Name (optional), email address, subject, message; optionally phone number/attachment, if provided.
• Metadata: Sending/receipt time, technical headers (message ID, routing), delivery status.
• Server logs (see 6.1): Time, IP, user agent only within the scope of the website visit (operation/security).
• Please do not send sensitive content: Do not transmit special categories of personal data (Art. 9 GDPR) via the form/email unless this is necessary and expressly desired (see 6.2.9).

6.2.3 Purposes

• Processing your inquiry, follow-up questions and communication.
• Evidence and documentation of case processing, as necessary.
• Ensuring deliverability/error analysis (Scaleway sending logs).

6.2.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (contract/pre-contractual measures), when the inquiry relates to contract/app usage.
• Art. 6 Para. 1 lit. f GDPR (legitimate interest) for general communication, support organization, and IT security/deliverability (minimal logs).
• Art. 6 Para. 1 lit. c GDPR (legal obligation), insofar as retention/evidence is legally required (only to the extent personal data is involved).
• Art. 6 Para. 1 lit. a in conjunction with Art. 9 Para. 2 lit. a GDPR in case of voluntary transmission of sensitive data (explicit consent required).

6.2.5 Recipients / Data Processors

• Scaleway SAS (Paris/FR) -- data processor for email sending of the form (EU location; no planned third-country transfer).
• Mail providers/mail clients -- delivery/retrieval of emails (transport TLS).
• No disclosure for advertising/analytics purposes; no other third parties, except when legally obligated (authorities/law enforcement).

6.2.6 Storage Duration & Deletion

• Email mailbox: No automatic deletion; manual deletion after problem resolution.
• Scaleway sending logs: 30 days; bounce/complaint lists: 90 days.
• Legal/evidence obligations: To the extent applicable (e.g., correspondence with contract reference), retention according to legal periods; otherwise deletion after purpose fulfillment.

6.2.7 Security

• Transport encryption: Form → server → Scaleway → destination mailbox via TLS.
• Spam/abuse protection: Validations/CSRF protection (without tracking); no marketing pixels.
• Access protection: Access only for authorized persons (need-to-know), administrative access logged; strong passwords/MFA.

6.2.8 Voluntariness & Consequences of Non-Provision

• Providing your email address and a message is required for processing. Without sufficient information, a meaningful response may not be possible.
• Alternatives: Direct sending by email or post (see contacts in Section 2.2).

6.2.9 Special Categories (Art. 9 GDPR)

• Please do not send sensitive data (e.g., health data) via form/email.
• If this is exceptionally necessary, processing occurs only with your explicit consent solely for the purpose of handling your concern; thereafter deletion, unless mandatory reasons prevent it.

6.2.10 Transparency Notes (References)

• Scaleway (data processing in the EU; DPA/TOMs): Sending logs/lists according to 6.2.6.
• Email security: Emails are not necessarily end-to-end encrypted despite TLS. Use E2E encryption (PGP/SMIME) if you are sending particularly sensitive content.

6.3 Registration on the Website (currently not active)

6.3.1 Status

• On the PHP website (without CMS), no registration for visitors is provided.
• No user accounts for website functions (e.g., comments, shop, customer area) are offered.
• Cloud synchronization of the app is not accessible via website login but -- if desired by the user -- exclusively in the app (see 5.2).

6.3.2 Current Data Processing

• Since no registration on the website is possible, no corresponding processing (collection, storage, or use of registration data) takes place.
• No passwords, no user profiles, and no social logins are processed on the website.

6.3.3 Future Outlook (if activated in the future)

Should an optional website registration be introduced in the future (e.g., for support portal, customer area, training materials), the following principles apply -- only after activation. Before starting, we will update this privacy policy synchronously in-app and on the website and -- if necessary -- obtain consent.

6.3.4 Potential Data Categories (only if activated)

• Master data: Name (optional), display name, email address (required), possibly username.
• Authentication: Password (server-side stored exclusively as strong hash), email verification/double opt-in (timestamp, token), possibly 2FA seed/2FA backup codes.
• Logs/metadata: Account creation time, last login, failed logins (for abuse prevention), roles/permissions.
• Communication: System emails (verification, password reset, security-related notices).

6.3.5 Potential Purposes (only if activated)

• Provision of the website function for which login is required (e.g., protected download area, ticket overview).
• Security/abuse prevention (e.g., account locking logic, rate limiting, audit).
• Support/administration (e.g., role management, traceability of security-relevant changes).

6.3.6 Potential Legal Bases (only if activated)

• Art. 6 Para. 1 lit. b GDPR (contract/pre-contractual measures) for provision of a registration-required service.
• Art. 6 Para. 1 lit. f GDPR (legitimate interests) for security, abuse prevention, logging of minimal login metadata.
• Art. 6 Para. 1 lit. a GDPR (consent) for individual convenience features (e.g., "stay logged in", optional newsletter -- if offered).

6.3.7 Potential Storage Durations & Deletion (only if activated)

• Account data: for the duration of account use; deletion upon request or in case of inactivity after a defined period (will be specified before activation).
• Security/login logs: short-cycle, only as necessary for defense/analysis; subsequently deletion/anonymization.
• Legal/evidence obligations: only to the extent legally required (and personal).

6.3.8 Potential Security Measures (only if activated)

• TLS (HTTPS) throughout; hardening of PHP website (without CMS);
• Passwords: exclusively strongly hashed (e.g., Argon2id/bcrypt), no plain text;
• 2FA/MFA (recommended), rate limiting, account locks for brute force;
• Role concept/least privilege, logging of critical admin actions.

6.3.9 Potential Recipients & Data Processing (only if activated)

• Hosting/managed services as data processors (Art. 28 GDPR);
• Mail sending for system emails (verification/reset) via EU-based mail infrastructure (e.g., Scaleway -- see 6.2);
• No disclosure to third parties for advertising/tracking purposes.

6.3.10 Voluntariness & Consequences of Non-Provision (only if activated)

• Providing email and a password would be required for account creation. Without this data, no access to registration-required website functions.
• App usage is independent of this (app remains fully usable without website account).

6.3.11 Minors (only if activated)

• Target audience 18+. No child-oriented registration functions are offered.

6.3.12 Update of the Privacy Policy

• Before introducing website registration, the specific parameters (exact data fields, storage periods, recipients, TOMs) will be precisely added to this privacy policy and published.

6.4 Cookies & Similar Technologies (PHP website without CMS)

Core statement: Our website uses exclusively strictly necessary cookies (in particular the PHP session cookie that remembers your language preference). No analytics, tracking, or marketing cookies, no third-party pixels, and no external CDN/font resources are loaded. For this reason, no consent banner is displayed — in line with the German Datenschutzkonferenz (DSK) guidance on § 25 TTDSG, which states that a consent banner should not be shown when only strictly necessary cookies are used. Instead, a static informational notice in the page footer refers to this privacy policy.

6.4.1 Deployment Overview

• No tracking/analytics cookies, no marketing/retargeting cookies, no third-party pixels.
• No external services (Google Fonts, CDNs, cloud consent tools) are loaded — all static resources (fonts, Play Store badge, QR code) are self-hosted.
• Strictly necessary cookies only (e.g., PHP session for language preference, possibly CSRF/security tokens).

6.4.2 Strictly Necessary Cookies (Examples)

• PHP session cookie (PHPSESSID): stores your language preference (en/de) within a browser session. Expires when the session ends (browser close).
• Session/security cookies (server): where applicable for page delivery, CSRF protection, firewall/rate limit.
• Properties: purely functional, no cross-site tracking, no profiling.

6.4.3 No Consent Tool

• No consent-management tool (cookie banner) is deployed because no consent-requiring cookies are set.
• Static notice: A non-blocking informational line in the page footer states that only strictly necessary cookies are used and links to this privacy policy.

6.4.4 No Statistics/Marketing Cookies, No External Resources

• No services like Google Analytics, Facebook Pixel, Hotjar, Umami, etc., are loaded.
• Fonts (Cormorant Garamond, Plus Jakarta Sans, Inter) are self-hosted as WOFF2 files served directly from our web server — no requests to Google Fonts.
• Play Store badge and QR code are stored as static files in the project; there is no passive embedding of play.google.com, api.qrserver.com, or similar services.
• If optional services are introduced in the future, the following will happen beforehand: update of this privacy policy and — where legally required — introduction of an opt-in mechanism.

6.4.5 Legal Bases

• Strictly necessary cookies: Art. 6 Para. 1 lit. f GDPR (legitimate interest in secure, functional operation) in conjunction with § 25 Para. 2 No. 2 TTDSG (strictly necessary to provide the telemedia service explicitly requested by the user).

6.4.6 Control

• Browser settings: You can delete or block cookies at the browser level at any time.
• Consequences: Without the session cookie, your language preference is lost on page navigation; the website otherwise remains fully usable.

6.4.7 Storage Durations & Deletion

• PHP session cookie: session-based (deleted when the browser closes).
• Server-side logs (access/error logs): see 6.1.4 (typically 7–14 days).

7. Applicable Legal Bases (Overview)

7.1 Art. 6 Para. 1 lit. a-f GDPR (specifically for Trabista)

a) Consent (Art. 6 Para. 1 lit. a GDPR)
Deployed when a function is legally permissible only with prior opt-in or we voluntarily implement it as such:

• Personalized advertising (AdMob, EEA/UK): Opt-in via CMP/UMP in the app (see 5.4).
• Crash reporting & analytics (Firebase): deactivated, only after explicit opt-in in the app (see 5.6).
• Notifications/alarms (POST_NOTIFICATIONS / SCHEDULE_EXACT_ALARM): OS-level opt-in; classified as consent under data protection law (see 5.3).
• Special categories in free text (e.g., allergies): only voluntarily by the user and exclusively locally (Art. 9 Para. 2 lit. a, see 7.4 and 5.1).
• Possibly future optional services (e.g., additional third-party integrations): consent before activation.

b) Contract/contract performance (Art. 6 Para. 1 lit. b GDPR)
Required to provide the agreed app functions:

• Offline core functions: Travel/luggage management, local reminders, exports (5.1, 5.3).
• Optional cloud synchronization (Premium): Account, auth, sync, device access (5.2).
• Geocoding/weather (Free/Premium): to the extent necessary for the requested function (5.5).
• In-app purchases/subscriptions ACTIVE via Google Play Billing (Android) & Apple App Store / StoreKit (iOS), jointly via RevenueCat: License check/activation (5.7).
• Support communication with contract reference: Response/processing (5.8, 6.2).

c) Legal obligation (Art. 6 Para. 1 lit. c GDPR)
Where applicable:

• Evidence obligations (e.g., consent evidence Art. 7 Para. 1 GDPR; currently not applicable on the website since no consent-requiring cookies are set, see 6.4).
• Information/cooperation with authorities/courts, when legally required.
• Commercial/tax-related retention, only to the extent personal data is involved and actually occurs with us (e.g., correspondence with billing reference).

d) Vital interests (Art. 6 Para. 1 lit. d GDPR)
Generally not applicable. If processing should exceptionally be necessary to protect vital interests, we rely on this (currently no corresponding standard process in the app; emergency contacts are purely local fields).

e) Public task (Art. 6 Para. 1 lit. e GDPR)
Not applicable (no sovereign tasks).

f) Legitimate interest (Art. 6 Para. 1 lit. f GDPR)
Balancing of interests with right to object (see 12.7). Typical cases:

• Website operation & security: Server log files, firewall/rate limiting, error analysis (6.1).
• App operation & stability: Minimal logs/error codes for online features, abuse/fraud prevention (5.2, 5.4, 5.5, 5.7).
• Non-personalized advertising (AdMob) in EEA/UK without opt-in; purely contextual/aggregation-based (5.4).
• License/integrity protection with Play Billing (5.7).
• Error & performance analysis (Sentry, iOS): Collection of crash, performance, and profiling data without personal identifiers to ensure app stability and quality (5.10). Balancing of interests favors app quality; no profiling, no advertising use; the right to object under Art. 21 GDPR applies.

7.2 Purpose Changes (Art. 6 Para. 4 GDPR)

Should processing occur for a different purpose than originally collected, we examine the compatibility according to Art. 6 Para. 4 GDPR based on:

• Connection between original and intended purpose,
• Collection circumstances (relationship to us, user expectations),
• Type of data (including special categories),
• Possible consequences for data subjects,
• Existing safeguards (e.g., pseudonymization, encryption, access restrictions).
  Only when the requirements are met (or a new legal basis, especially consent, exists) does the purpose change occur. Transparent information and possibly renewed consent are ensured.

7.3 Consent & Revocation (Art. 7 GDPR) -- plus national ePrivacy rule

• Transparency & evidence: Consents are clearly explained, obtained per purpose, and logged (time, scope). No consent-requiring processing is currently performed on the website (see 6.4); logging therefore does not apply.
• Revocation: possible at any time with effect for the future -- in-app (e.g., switches for advertising/crash/analytics) and via OS settings (notifications, AD_ID).
• Consequences of revocation: Functionality generally remains intact; the respective optional function (e.g., personalized ads, telemetry) will no longer be used.
• Additionally (Germany/ePrivacy): § 25 TDDDG (formerly TTDSG).
  • For storing/accessing information on end devices (e.g., cookies, advertising IDs) -- outside technically necessary cases -- prior consent is generally required.
  • Our deployment: only strictly necessary cookies (PHP session for language preference), no statistics/marketing cookies -- therefore no consent banner is required (6.4). For app advertising ID/AdTech in EEA/UK, CMP/UMP opt-in is used (5.4).

7.4 Special Categories of Personal Data (Art. 9 Para. 2 GDPR)

• Principle: We do not process special categories (Art. 9 Para. 1 GDPR) except when you voluntarily enter them in local free text fields (e.g., allergies).
• Legal basis: Art. 9 Para. 2 lit. a GDPR (explicit consent), granted by your voluntary input; the data remains exclusively local and encrypted (5.1.4).
• No transmission of such content to our servers or third parties.
• No processing for medical purposes, no profiling based on sensitive data.
• Application procedures (only if used, see 15): To the extent applicants voluntarily provide sensitive information, processing likewise only according to Art. 9 Para. 2 lit. a GDPR; additionally § 26 BDSG (Germany) for employee data.

8. Data Processors & Recipients

8.1 Supabase (Data Processor) -- DB/Auth/Edge, Region, TOMs, Sub-Processors

8.1.1 Role, Contract & Scope

• Role: Supabase processes our customer data ("Covered Data") as a data processor. For own operational/billing/security data ("Usage Data"), Supabase acts as an independent controller -- each as regulated in the DPA with Supabase.
• Contractual Basis: Data Processing Agreement (DPA) with Supabase including annexes (TOMs, SCC, sub-processor regulations).

8.1.2 Region, Scope of Services, Architecture

• Region: Storage/processing of Covered Data in our selected EU region (Frankfurt/eu-central-1), according to DPA.
• Services: Database hosting (Postgres), Auth, Edge Functions/Proxy, Storage, Realtime, etc. according to DPA.
• Isolation: Multi-tenant schemas with Row-Level-Security (RLS) and JWT-based access, according to DPA.

8.1.3 Data Categories (processed by Supabase)

• Covered Data: App content stored by us in Supabase (e.g., synchronized travel data/attachments) as well as auth/account data (email, token metadata) -- according to DPA.
• Usage Data (Supabase's own purposes): Technical operational/billing/security data, as necessary for provision and securing of services -- according to DPA.

8.1.4 Purposes (by Supabase)

• Provision and operation of subscribed services (hosting, auth, edge), support, security/scaling -- according to DPA.
• Use of Usage Data by Supabase for operation, billing, security and product improvement -- according to DPA.

8.1.5 Technical & Organizational Measures (TOMs)

• Transport/Storage Protection: TLS "in transit", encryption "at rest" (AES-256) including backups -- according to DPA.
• Access/Identity Controls: Roles/least privilege, 2FA/MFA, change management, logging -- according to DPA.
• Backups/Availability: Encrypted backups, PITR and high availability according to service description -- according to DPA.
• Tests/Monitoring: Regular security reviews, pen tests by third parties -- according to DPA.

8.1.6 Security Incidents & Notification

• Incident Handling/Breach Notice: Timely notification, ongoing information and support with authority/data subject notifications according to DPA.

8.1.7 Sub-Processors

• Categories/Examples: Hosting/network (e.g., AWS, network/CDN), logging/analytics for operational purposes, support/communication tools -- according to DPA.
• Integration/Transparency: Advance information on changes, objection/coordination mechanisms and liability of Supabase for sub-processors -- according to DPA.

8.1.8 International Data Transfers & Safeguards

• Transfer Mechanisms: EU Standard Contractual Clauses (SCC) (including possibly UK/Swiss addenda) and -- where applicable -- EU-US Data Privacy Framework (DPF) for participating US providers -- according to DPA.
• Additional Protective Measures (TIA/Safeguards): Risk-appropriate technical and organizational additional measures according to transfer impact assessment -- according to DPA.

8.1.9 Support for Data Subject Rights & Audits

• DSR Support: Support for information, deletion, correction, etc., only upon our instruction, according to DPA.
• Evidence/Audits: Documentation/certificate provision and audit rights within agreed limits -- according to DPA.

8.1.10 Return & Deletion After Contract End

• Return/Deletion of all Covered Data (including backups/sub-processors) after contract end within agreed periods -- according to DPA.

8.1.11 Implementation in "Trabista"

• EU region (Frankfurt), RLS/JWT, PITR (7 days), TLS/pinning and key management are active in our implementation (see sections 5.2, 10.2, 11).
• No transmission of sensitive local app content to Supabase outside of voluntarily activated cloud synchronization.

8.2 Scaleway (Transactional Email, FR)

8.2.1 Role, Contract & Scope

• Role: Data processor for transactional email sending (website contact form, system emails like verification/reset in cloud context).
• Contractual Basis: Data Processing Agreement (DPA) with Scaleway including annexes (TOMs, SCC/addenda, sub-processor regulations).
• Instruction Binding: Processing exclusively for provision of commissioned sending/delivery service according to DPA.

8.2.2 Processing Subject & Data Categories

• Content Data: User-entered contact form fields (name -- optional, email, subject, message) as well as attachments (if attached).
• Address Data: Our recipient email addresses (e.g., gobbltech@proton.me, datenschutz@trabista.app, privacy@trabista.app).
• Transport/Header Data: Sender/recipient, Message-ID, routing information, timestamps.
• Delivery Logs: Sending logs (success/failure), bounce/complaint lists (undeliverability/complaints).
• No Tracking: No marketing open/click tracking pixels; no profiling.

8.2.3 Processing Purposes

• Delivery of website contact requests and system-related notifications.
• Operational Security/Deliverability: Traceability for failed delivery/bounce, abuse prevention (spam, spoofing).
• Support & Evidence: Technical proof of sending/acceptance without content evaluation for marketing purposes.

8.2.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (contract/initiation), if request/usage-related.
• Art. 6 Para. 1 lit. f GDPR (legitimate interest) in secure communication, deliverability, abuse prevention (minimal logs).
• Art. 6 Para. 1 lit. c GDPR (legal obligations), where evidence/retention is applicable.
• Art. 6 Para. 1 lit. a in conjunction with Art. 9 Para. 2 lit. a GDPR for voluntary transmission of sensitive data -- only purpose-bound for request processing.

8.2.5 Location, Data Flows & International Transfers

• Primary Processing Location: France (Paris/EU).
• Planned Third Country Transfers: Not planned.
• Exception Cases/Sub-Processors: If required in individual cases outside the EEA, transfers occur exclusively with appropriate safeguards (SCC, possibly UK/Swiss addenda) according to DPA.

8.2.6 Technical & Organizational Measures (TOMs)

• Transport: Mail transport via TLS end-to-end as supported by participating servers; no forced marketing tracking.
• Storage: Purpose-bound temporary storage/processing within sending chain; access controls, role principle, logging according to DPA.
• Protection Mechanisms: Anti-spam/anti-abuse, rate limiting, IP/domain reputation; no content-based data mining.
• Organization: Security policies, patch/vulnerability management, business continuity/disaster recovery according to DPA.

8.2.7 Retention Periods & Deletion

• Sending Logs: 30 days (technical delivery logs).
• Bounce/Complaint Lists: 90 days (delivery protection/error analysis).
• Content Data: No independent, permanent storage beyond delivery purpose; deletion/rotation according to DPA and technical necessity.
• At our end: Emails in inbox without automatic deletion; manual deletion after problem resolution (see 5.8/6.2). Legal retention obligations remain unaffected.

8.2.8 Recipients, Sub-Processors & Responsibilities

• Scaleway acts as data processor; any sub-processors are only integrated according to DPA and with appropriate safeguards.
• No disclosure for advertising/analysis purposes. Authority access only in legally regulated exceptional cases.
• We remain controller for communication content and configure sending paths.

8.2.9 Data Subject Rights, Support & Audits

• Data Subject Rights: Information/deletion/correction are processed by us; Scaleway supports us according to DPA.
• Audits/Evidence: Provision of security/compliance evidence and audit options within agreed framework according to DPA.

8.2.10 Special Notes & User Controls

• Confidentiality: Emails despite TLS are not necessarily end-to-end encrypted. For sensitive content, we recommend PGP/SMIME.
• Voluntary: Use of form is voluntary; alternatively email or mail is possible (Section 2.2).
• No Marketing Emails: No sending of newsletters/marketing without separate consent.

8.2.11 Implementation in "Trabista"

• Website form sends directly via Scaleway to our inboxes; no DB storage in CMS.
• We implement no tracking pixels/click evaluations.
• Log/list periods (30/90 days) are configured at Scaleway; our internal deletion occurs after purpose achievement or legal obligations.

8.3.2 AdMob (Advertising in Free Version)

Purpose & Integration

• Delivery of display advertising exclusively in the free app version.
• No linkage with local app content (travel data, attachments, etc.).
• Premium/Pro: No advertising.

Data Categories (by Google)

• Advertising ID (AD_ID), device/app metadata (OS/app version, device model, language), IP address (derivation of approximate location at country/region level), events (impression/click/error).
• EEA/UK: Personalization only after consent via CMP/UMP in app; without consent non-personalized ads (context/aggregation-based).

Legal Bases

• Art. 6 Para. 1 lit. a GDPR (consent) for personalized advertising in EEA/UK.
• Art. 6 Para. 1 lit. f GDPR (legitimate interest) for non-personalized ads, reach limitation/fraud prevention and technical operation.

Control & Withdrawal

• In-App Preferences: Grant/revoke consent; switch to non-personalized.
• OS Settings: Reset/deactivate advertising ID.
• Upgrade removes ads completely.

International Transfers & Retention Periods

• Possible USA transfers by Google; safeguarded via SCC/DPF.
• Retention according to Google policies (e.g., ad signals typically up to ~14 months).
• We do not store personalized ad profiles.

8.3.3 Google Play Billing (Purchases & Subscriptions -- ACTIVE)

Purpose & Responsibility

• Processing exclusively via Google Play (account, payment method, billing).
• Google processes payment/account data independently. We receive only validation signals (e.g., subscription status).
• Server-side validation is handled via RevenueCat (data processor) -- see Sections 5.7 and 8.6.

Data Categories (minimal at our end, function-related)

• Subscription status/expiration, entitlement status (from RevenueCat), feature flags (Free/Premium/Pro) encrypted locally.
• No payment methods or address data at our end.

Legal Bases

• Art. 6 Para. 1 lit. b GDPR (contract/service: activation of paid features).
• Art. 6 Para. 1 lit. f GDPR (license protection/fraud prevention).
• Art. 6 Para. 1 lit. c GDPR (evidence obligations), only if personal data arises.

International Transfers & Retention Periods

• Google may process data outside EEA (SCC/DPF).
• At our end: License status term + 90 days; then deletion/anonymization (details 5.7.6).

8.3.4 Firebase (Crashlytics & Analytics -- **currently deactivated**, only after opt-in)

Purpose & Status

• Crashlytics: Technical crash reports/stack traces for stability improvement.
• Analytics: Aggregated usage signals (e.g., screen views).
• Both are implemented but deactivated by default in our app; activation only after explicit consent (opt-in) within app (EEA/UK via CMP/UMP).

Data Categories (when function activated)

• Device/app metadata (app/OS version, model), crash details (stack trace, timestamp), events (screen/event IDs), pseudonymous instance/session IDs; no local content data, no special categories.
• No linkage with your cloud account/email by us.

Legal Bases

• Art. 6 Para. 1 lit. a GDPR (consent) -- mandatory prerequisite for any transmission to Firebase.
• Withdrawal at any time in-app; takes effect ex nunc.

International Transfers & Retention Periods

• Possible USA transfers; safeguarded via SCC/DPF.
• Retention according to Google policies; we only keep configuration/consent status.

8.3.5 Google Maps Geocoding & Places API (Premium, **via EU Proxy**)

Integration & Architecture

• Two services in Premium tier:
  • Google Maps Geocoding API for enhanced location search
  • Google Places API (Enterprise) for Smart Contact Auto-Fill (NEW: 2025-10-24)
• All requests from the app are not sent directly to Google, but forwarded via an EU-based Supabase Edge Function (proxy).
• This ensures your device IP is not disclosed to Google; Google sees the proxy IP (EU).
• Smart Contact Auto-Fill:
  • Automatic filling of phone number and website for hotels/hostels
  • 30-day cache (place_contact_cache) for API cost optimization
  • Access to 170M+ business database
  • Only activated for business types (Hotels, Hostels)
• Only necessary parameters are transmitted (search string/coordinates for geocoding, Place ID for Contact Auto-Fill), no user identifiers (no email, no account ID).

Responsibility & Data Processing

• Google processes geocoding parameters independently (own purposes/terms).
• We use the response exclusively for display/further processing in app (e.g., destination coordinates).

Legal Bases

• Art. 6 Para. 1 lit. b GDPR (fulfillment of premium function requested by user).
• Art. 6 Para. 1 lit. f GDPR (operation/stability/error analysis of proxy layer at meta level).

International Transfers & Retention Periods

• Google may process data EU-internally and -- depending on service -- also transfer to USA (SCC/DPF).
• Proxy logs (EU): Minimal and short-cycle for operational/security purposes (details 5.5).

Website Note: On the PHP website (without CMS), no Google Maps widget and no Google Geocoding API is used. Section 8.3.5 concerns only the app (premium function).

8.3.6 Apple App Store / StoreKit (iOS Purchases & Subscriptions -- ACTIVE)

Integration & Architecture

• Apple Distribution International Ltd. (Hollyhill Industrial Estate, Hollyhill, Cork, Ireland) distributes the iOS app via the Apple App Store and processes in-app purchases/subscriptions via StoreKit 2.
• Apple Inc. (One Apple Park Way, Cupertino, CA, USA) is the global group operator; however, the contracting party for EEA customers is Apple Distribution International (Ireland).
• In-app purchases run directly between user and Apple; we see no payment method, billing, or Apple ID data.
• RevenueCat validates Apple transactions server-side (see § 8.6). Apple sends subscription status changes to RevenueCat via App Store Server Notifications V2.

Responsibility & Data Processing

• Apple is independently responsible (Art. 4 No. 7 GDPR) for processing all payment and account-related data. No DPA with us.
• We only receive pseudonymous entitlement/subscription status and transaction IDs via RevenueCat — without Apple ID, name, payment method, or billing address.

Data Categories (processed by Apple; not visible to us)

• Apple ID, payment profile, billing/invoicing data, transaction history, device/purchase protection signals.
• App Store Analytics on the developer side are aggregated and not viewable per user.

Legal Bases

• Art. 6 Para. 1 lit. b GDPR (performance of the purchase/subscription contract between user and Apple, activation of paid app features).
• Art. 6 Para. 1 lit. f GDPR (license protection, fraud prevention on our side via RevenueCat entitlements).

International Transfers

• Primary processing by Apple Distribution International (Ireland, EU). Intra-group transfers to the USA (Apple Inc.) are possible and, per Apple, safeguarded via Standard Contractual Clauses (SCC) and -- where applicable -- the EU-US Data Privacy Framework (DPF).

Retention Periods

• At Apple per Apple's own retention policies and statutory requirements.
• At our end: only pseudonymous entitlement status (see 5.7.6).

User Controls & Consequences of Non-Provision

• Subscription management/cancellation: via Settings → Apple ID → Subscriptions on the iOS device.
• Refunds: via reportaproblem.apple.com per Apple's media policies.
• Without purchase, the iOS app remains fully usable in the free variant (with advertising, see 5.4).

Transparency & Links

• Apple Privacy: https://www.apple.com/legal/privacy/
• Apple Media Services Terms: https://www.apple.com/legal/internet-services/itunes/
• App Store & Privacy (Apple Support): https://support.apple.com/en-us/HT210584

Website Note: The PHP website only links to the App Store (download badge). No website-side processing related to Apple takes place.

8.3.7 Sentry (iOS Error & Performance Analysis -- ACTIVE, EU Region)

Integration & Architecture

• Provider: Functional Software, Inc. (d/b/a Sentry), 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA.
• EU representative: Sentry GmbH, Berlin, Germany.
• Primary region: EU (Frankfurt / AWS) -- DSN endpoint ingest.de.sentry.io.
• Role: Data processor under Art. 28 GDPR; a Data Processing Agreement (DPA) is in place (https://sentry.io/legal/dpa/).
• Scope of use: iOS app only (native Swift client, sentry-cocoa 8.58+); not integrated into the PHP website, not integrated into the Android app.

Processing Scope & Data Categories

• Crash/error events: stack traces, exception context, release/environment tag.
• Performance traces (20 % sampling) and profiling sessions (10 % sampling) for performance analysis.
• View-hierarchy snapshot at crash (UI structure without content data).
• Forwarded logs: selected OSLog/print lines (enableLogs = true).
• Device/OS/app metadata: device model, iOS version, app build, language/region, network state.
• Explicitly NOT collected: IP address (sendDefaultPii = false, not overridden), user ID (no SentrySDK.setUser), email address, travel/luggage data, file attachments, payment/purchase data.

Processing Purposes

• Stability, performance quality, operational security, and rapid error diagnostics for the iOS app.

Legal Basis

• Art. 6 Para. 1 lit. f GDPR (legitimate interest in stable and performant operation). No consent required, since no personal identifiers are transmitted and no consent-requiring end-device access within the meaning of § 25 TDDDG takes place. The right to object under Art. 21 GDPR applies (contact see § 18).

International Transfers & Safeguards

• Primary: processing in the EU region (Frankfurt, AWS). No planned primary transfers to the USA.
• Support/maintenance access from the USA (Sentry personnel) may be required within the DPA framework; safeguarded via EU Standard Contractual Clauses (SCC) and -- where DPF-certified -- the EU-US Data Privacy Framework (DPF) (fallback).
• Sub-processors: in particular AWS (EU/US) per the Sentry DPA.

Security / TOMs

• Transport: TLS 1.3.
• At rest: encryption on AWS infrastructure.
• Certifications: SOC 2 Type II, ISO 27001.
• Access: role-based/least-privilege; audit logs.

Retention Periods

• Event/crash data: max. 90 days (standard retention on Business plan); aggregated/summary metrics possibly longer in anonymized form.

User Control

• No in-app opt-out, since no personal identifiers are transmitted; objection under Art. 21 GDPR is possible via contact.

Transparency & Links

• Sentry Privacy: https://sentry.io/privacy/
• Sentry DPA: https://sentry.io/legal/dpa/
• Sentry Apple/iOS -- data collected: https://docs.sentry.io/platforms/apple/data-management/data-collected/
• Sentry Trust Center: https://sentry.io/trust/

Website Note: The PHP website does not load any Sentry SDK. Section 8.3.7 concerns exclusively the iOS app.

8.4 Photon (komoot) & OpenStreetMap (Geocoding/Reverse)

8.4.1 Role & Integration

• Photon (komoot GmbH, DE) and OpenStreetMap Foundation (OSMF, EU/UK servers) are used for location search/geocoding and reverse geocoding -- primarily for free users (standard), OSM as fallback.
• Both act for their respective processing as independent controllers (Art. 4 No. 7 GDPR). No DPA with us.
• No continuous location tracking; requests arise only from manually entered locations/addresses or from coordinates initiated by you.

8.4.2 Processed Data (typical)

• Search/Query Parameters: Location/address/POI or coordinates (lat/lon) for geocoding/reverse geocoding.
• Technical Metadata: Timestamp, User-Agent, IP address (server-side), status/error signals, possibly rate limit indicators.
• Not Transmitted: No email addresses, no app accounts/IDs, no local content data (trips, attachments).
• App-side Local: Your entered destinations/travel objects are only stored locally encrypted (cf. 5.1.4).

8.4.3 Purposes

• Geocoding/Reverse: Conversion of search terms to coordinates and vice versa for convenient travel/list planning.
• Quality & Stability: Resolution of technical errors, compliance with terms of use/rate limits (meta/error information).

8.4.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR: Required for provision of location search/resolution you requested in the app.
• Art. 6 Para. 1 lit. f GDPR: Operation/security/abuse prevention based on minimal log data.
• Consent (Art. 6 Para. 1 lit. a GDPR): Not required, as no optional marketing/tracking services are integrated.

8.4.5 Recipients, Responsibility & Data Flows

• Photon (komoot GmbH, DE): Recipient of your pseudonymous search requests (without user identifier); processing on German/European servers.
• OpenStreetMap Foundation (EU/UK servers): Recipient of pseudonymous search/reverse requests; UK is secured by adequacy decision under data protection law.
• No disclosure by us to other third parties; no use of tracking/marketing pixels in connection with these API calls.

8.4.6 International Transfers

• Photon/OSM: Regularly no third country transfer; processing occurs on DE/EU/UK servers.
• Should a provider exceptionally mirror/deliver to other regions, their own safeguards/policies apply; we transmit no user identifiers.

8.4.7 Retention Periods

• At our end (app): Search terms/coordinates only purpose-bound in respective trip/object; no independent history/profiling.
• At services: Retention according to providers' own policies (e.g., short-term server/error logs). We transmit only the necessary query parameters.

8.4.8 Security

• Transport: Consistently TLS between app ↔ service.
• Data Minimization: No email/account IDs, only search string/coordinates and unavoidable technical metadata.
• Separation: Results are processed in app; no linkage with ad IDs, crash/analytics data, etc.

8.4.9 Control & Consequences of Non-Provision

• Without location search you can maintain travel destinations manually as free text; convenience functions (auto-completion, reverse geocodes) are unavailable.
• Core functions (local planning, checklists, reminders) remain fully usable.

8.4.10 Transparency & Links

• Photon (komoot) -- Privacy:
• OpenStreetMap Foundation -- Privacy Policy:

Website Note: On the PHP website (without CMS), no geocoding/maps services are loaded. Section 8.4 concerns only the app (free/fallback).

8.5 OpenWeather (Weather, UK -- via EU Proxy)

8.5.1 Role & Integration

• OpenWeather Ltd. (UK) provides weather forecasts for travel destinations -- only in premium plan.
• The app does not call OpenWeather endpoints directly. All requests run via EU-based Supabase Edge Function (proxy).
• Responsibility: OpenWeather processes parameters forwarded by proxy as independent controller. No DPA with us.

8.5.2 Processed Data (by proxy/service)

• Query Parameters: Coordinates (lat/lon) or possibly a destination location you selected in app.
• Technical Metadata (Proxy Level): Timestamp, status/error codes, proxy IP (EU), minimized logs for operational security/abuse prevention.
• Not Transmitted: No email addresses, no app accounts/IDs, no local content data (trips, attachments).
• OpenWeather Response: Forecast/weather data (temperature, precipitation, etc.) -- only displayed/processed in app.

8.5.3 Processing Purposes

• Weather Display for travel destinations you selected, to facilitate planning and preparation.
• Proxy Purposes: Stability, load control, IP shielding (OpenWeather sees not your device IP, but the EU proxy IP), error handling.

8.5.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (contract/service): Provision of premium weather function you requested.
• Art. 6 Para. 1 lit. f GDPR (legitimate interest): Operation/stability/security of proxy layer at meta level (minimal logging).
• Consent is not required for this function (no marketing/tracking services).

8.5.5 International Data Transfers & Safeguards

• UK has an EU adequacy decision. Requests to OpenWeather (UK) occur via EU proxy.
• Insofar as OpenWeather makes further transfers within its own service provision, their own safeguards/policies apply (e.g., SCC). We transmit only the necessary coordinate parameters.

8.5.6 Retention Periods

• App-side: Weather data is used only temporarily for display/session; no permanent, personal storage.
• Proxy Logs (EU): Short-cycle and purpose-bound (operation/security); no profiling.
• OpenWeather: Retention according to provider's own policies; no user identifiers are transmitted.

8.5.7 Security

• Transport: Consistently TLS (app ↔ EU proxy ↔ OpenWeather).
• Data Minimization: Disclosure exclusively of coordinate-based parameters; no email/account IDs, no AD_ID/tracking IDs.
• Architecture: EU proxy decouples your end device from OpenWeather; reduces data exposure and enables rate limiting/error sanitizing.

8.5.8 Control & Consequences of Non-Provision

• Weather function is optional (premium). If you do not use/cancel it, app remains fully functional; only weather display is unavailable.
• You can still plan travel destinations without weather data.

8.5.9 Transparency & References

• OpenWeather -- Privacy Policy: (see OpenWeather website)
• Note: On the PHP website (without CMS), no weather API is loaded. Section 8.5 concerns only the app (premium feature).

8.6 RevenueCat (Subscription Management & Validation, USA)

8.6.1 Role, Contract & Scope

• Role: Data processor for server-side subscription validation and subscription lifecycle management of in-app purchases and subscriptions (activation of premium/pro features).
• Provider: RevenueCat, Inc., San Francisco, CA, USA.
• Contractual Basis: Data Processing Agreement (DPA) with RevenueCat including annexes (TOMs, SCC, sub-processor regulations), effective since December 17, 2025.
• Instruction Binding: Processing exclusively for provision of commissioned subscription validation and entitlement management service according to DPA.

8.6.2 Processing Subject & Data Categories

• Anonymous User ID: Pseudonymous ID generated by RevenueCat ($RCAnonymousID); no link to email address, app account, or real name.
• Purchase Tokens: Purchase/subscription tokens generated by Google Play for server-side validation against Google.
• Product/Subscription Information: Plan identifier, duration, renewal/cancellation status, expiration date, entitlements.
• App/Platform Metadata: Platform (Android), OS version, app version, locale/language.
• IP Address: During SDK communication between app and RevenueCat backend (for transport purposes and security/fraud).
• Timestamps: Purchase, renewal, expiration timestamps.
• Not transmitted: No email addresses, no real names, no payment method data, no local app content (travel data, attachments), no device advertising IDs (collectDeviceIdentifiers() is not called), no custom subscriber attributes.

8.6.3 Processing Purposes

• Server-side purchase/subscription validation against Google Play (authenticity verification of purchase tokens).
• Subscription Lifecycle Management: Management of renewals, cancellations, grace periods, billing issues, and entitlement status.
• Entitlement Provision: Determination and return of entitlement status (Free/Premium/Pro) to app for feature activation.
• Operational Security/Fraud Prevention: Detection of invalid or abusive tokens/transactions.

8.6.4 Legal Bases

• Art. 6 Para. 1 lit. b GDPR (Contract/Service): Activation and management of paid app features as part of contractual service provision.
• Art. 6 Para. 1 lit. f GDPR (Legitimate Interest): License protection, fraud prevention, technical traceability, reliable subscription management.
• Art. 6 Para. 1 lit. c GDPR (Legal Obligation): Insofar as legal evidence obligations for business transactions are applicable (only insofar as personal data actually arises).

8.6.5 Location, Data Flows & International Transfers

• Primary Processing Location: USA (RevenueCat infrastructure on Amazon Web Services).
• Transfer Mechanisms: EU Standard Contractual Clauses (SCC) and -- where applicable -- EU-US Data Privacy Framework (DPF).
• Additional Protective Measures: Encryption in transit (TLS) and at rest; SOC 2 Type II certification; access restrictions based on role principle.
• Data Flow: App → (TLS) → RevenueCat backend (AWS/USA) → (validation against) → Google Play Developer API.
• No transfer to further third countries beyond USA processing.

8.6.6 Technical & Organizational Measures (TOMs)

• Transport: TLS for all communication between app SDK and RevenueCat backend.
• Storage: Encryption "at rest" on AWS infrastructure.
• Compliance: SOC 2 Type II certified (regular auditing).
• Access/Identity Controls: Role/rights concept, least privilege principle, logging.
• Data Minimization: By default only data necessary for subscription management; no optional identifiers (collectDeviceIdentifiers() not activated).
• Pseudonymization: User assignment exclusively via anonymous RevenueCat IDs ($RCAnonymousID); no mapping to email/real names.

8.6.7 Sub-Processors

• Infrastructure: Amazon Web Services (AWS) for hosting/storage/compute.
• Further Sub-Processors: According to RevenueCat sub-processor list (available at https://www.revenuecat.com/dpa).
• Integration/Transparency: Advance information on changes and objection mechanisms according to DPA.

8.6.8 Retention Periods & Deletion

• Subscription/Transaction Data: Stored during active business relationship between us and RevenueCat.
• After Contract End: Deletion of all processed data within periods agreed in DPA.
• Anonymous User IDs: Retained as long as an active or recently expired subscription exists; cleanup after purpose cessation according to DPA.
• Logs/Security Data: Short-cycle retention for operational and security purposes according to DPA.

8.6.9 Data Subject Rights, Support & Audits

• Data Subject Rights: Information/deletion/correction are processed by us; RevenueCat supports us according to DPA.
• Evidence/Audits: SOC 2 Type II reports and audit rights within agreed framework according to DPA.

8.6.10 Implementation in "Trabista"

• RevenueCat replaces the former Supabase Edge Function (/verify-purchase) for server-side purchase validation.
• No custom subscriber attributes configured (no email/name transmission to RevenueCat).
• No collectDeviceIdentifiers() calls (no advertising ID collection by RevenueCat).
• No attribution integrations, webhooks to third parties, or experiment features activated.
• The app receives from RevenueCat exclusively the entitlement status for local feature activation.

Website Note: On the PHP website (without CMS), no RevenueCat SDK is loaded. Section 8.6 concerns only the app (subscription management).

9. International Data Transfers

Core statement: Processing occurs primarily in the EU (especially Frankfurt/eu-central-1; Sentry also uses the EU region). International transfers occur only exceptionally and purpose-bound -- for example, with Google services (AdMob, Play Billing, optional Firebase; Premium geocoding), with Apple (App Store/StoreKit, intra-group USA) as well as with OpenWeather (UK) or OSMF (UK). All third-country transfers are secured by approved safeguards (especially SCC, possibly EU-US DPF) and additional protective measures.

9.1 Standard Contractual Clauses (SCC -- Modules 2/3)

• Scope of application: For data exports to third countries without adequacy decision, we use the EU SCC.
• Modules:
  • Module 2 (Controller → Processor): e.g., when we transfer EU data to a non-EU data processor.
  • Module 3 (Processor → Processor): e.g., when an EU data processor (our data processor) in turn engages a non-EU sub-processor.
• Onward transfers: Sub-processors may only transfer data based on equivalent protective mechanisms (SCC/adequacy).
• Core obligations: Purpose limitation, data minimization, confidentiality, state-of-the-art security, assistance with data subject rights, audits/evidence, information obligations regarding government access.
• Conflict-of-laws clauses: Legal disclosure requests are reviewed, challenged, limited to the legally necessary minimum, and documented; we will be -- to the extent permitted -- notified.

9.2 EU-US Data Privacy Framework (DPF)

• Applicability: For US recipients certified under DPF (e.g., certain Google entities), we rely on transfers -- to the extent applicable -- on the DPF.
• Fallback: If DPF does not apply (service/entity/scope), EU SCC (including UK/Swiss addenda, if necessary) plus supplementary TOMs are deployed.
• Transparency: We monitor changes to the legal framework and update this privacy policy and our contractual situation when necessary.

9.3 Supplementary Technical/Organizational Measures (Safeguards)

• Encryption: TLS 1.3 for all transmissions; encryption at rest at server/database level; SQLCipher (AES-256) locally.
• Key management: Android Keystore (app) and HSM-supported procedures on server/provider side (according to DPA).
• Data minimization/pseudonymization: No transmission of locally sensitive content; cloud sync only with opt-in; API calls (geocoder/weather) without email/account ID.
• EU proxy/edge: Premium geocoding (Google) and weather (OpenWeather) run via EU proxy; device IP is not disclosed (Google/OpenWeather see the EU proxy IP).
• Access/role principle: Least privilege, logging of administrative access, 2FA/MFA, RLS (database), JWT-based auth.
• Logs: minimal operational/error logs, short rotation periods, no profiling.
• Government access: Review of every request, narrow interpretation, challenging excessive demands, information forwarding to data subjects, to the extent legally permissible.

9.4 UK and Swiss Addenda

• UK: For transfers to or via the United Kingdom, we use the UK adequacy decision (if applicable, e.g., OpenWeather/OSMF) or EU SCC + UK addendum.
• Switzerland: If Swiss law is affected, SCC with Swiss addendum/adjustments are used.

9.5 Service/Recipient Overview (Transfer Short Profile)

• Supabase (EU, Frankfurt)
  • Role: Data processor (database/auth/edge).
  • Primary location: EU. Any sub-processors/telemetry exclusively according to DPA (SCC/safeguards). No export of sensitive local data.
• Scaleway (FR, EU)
  • Role: Data processor (mail delivery of contact form).
  • Transfer: no planned third countries.
• Google (independent controller)
  • AdMob (Free ads): EEA/UK with/without consent (personalization); possible USA transfers → DPF/SCC.
  • Play Billing: Payments/account with Google; possible USA transfers → DPF/SCC.
  • Firebase (opt-in only): possible USA transfers → DPF/SCC.
  • Maps Geocoding & Places API (Premium): Calls via EU proxy; Google sees EU proxy IP; possible USA transfers → DPF/SCC. Includes Smart Contact Auto-Fill for hotels/hostels (since 2025-10-24).
• Apple Distribution International Ltd. (Ireland, EU) -- independent controller
  • App Store distribution & StoreKit (iOS purchases/subscriptions): Contracting party for EEA customers is Apple Ireland; intra-group transfers to Apple Inc. (USA) are possible and safeguarded per Apple via SCC and -- where applicable -- DPF.
  • App Tracking Transparency (ATT) / SKAdNetwork: managed by Apple; ad-attribution data stays at device/Apple level.
  • We receive no personal purchase/payment data.
• OpenWeather (UK, Premium weather)
  • Role: independent controller.
  • Transfer: EU → UK (adequacy decision); call via EU proxy (no device IP at OpenWeather).
• Photon (komoot, DE) & OSMF (UK/EU servers)
  • Role: independent controllers (Free/fallback geocoder).
  • Transfer: DE/EU/UK; UK secured by adequacy decision; no planned USA transfers.
• Sentry (Functional Software, Inc.; EU region Frankfurt/AWS)
  • Role: Data processor (DPA in place).
  • Primary location: EU (ingest.de.sentry.io). No planned primary transfers to the USA.
  • Support access from the USA only within the DPA framework (SCC, possibly DPF fallback).

9.6 Your Options

• Without cloud/without Premium, nearly all processing remains local on your device (cf. 5.1, 5.3-5.5).
• Manage consents: Personalized ads as well as crash/analytics are opt-in and revocable at any time (cf. 5.4, 5.6, 7.3).
• Export/deletion: Cloud data can be exported and the account deleted in-app; backups expire after 7 days (cf. 5.2.6, 10.2).

10. Storage Durations, Deletion & Retention

10.1 Local Data (Device)

• Data types: Travel data (trips, participants, checklists, notes), attachments (e.g., photos/documents, if stored locally), settings/feature flags, reminders/alarms, possibly sensitive free text entries (only local).
• Storage duration: unlimited, until manual deletion by user or app uninstallation.
• Deletion:
  • In-app: Deletion of individual entries/trips or "Delete all."
  • System-side: Uninstallation removes all app data (app sandbox).
• Backups: Android Auto-Backup is enabled by default.
  • Database NOT encrypted: Full backup to Google Drive (clientSideEncryption, max. 25MB).
  • Database WITH SQLCipher encrypted: Database excluded for security reasons; other app data is backed up.
  • Can be disabled in system settings at any time.
• Manual Backups (.trabista format):
  • Users can create password-protected, encrypted backups (since 2025-10-02)
  • AES-256-GCM encryption with Argon2id key derivation (3 iterations, 64MB)
  • GZIP compression and HMAC-SHA256 integrity verification
  • Storage at any location (Google Drive, Downloads, local, USB)
  • Restoration with three merge strategies:
    • Replace All (replace all data)
    • Keep Newer (keep newer versions)
    • Keep Existing (keep existing data)
  • No password recovery -- data permanently locked if password forgotten
  • Full control: user decides storage location, timing, retention
• Security: SQLCipher (AES-256) + Android Keystore (key management).

10.2 Cloud Data (Supabase)

• Data types: When cloud sync is activated (Premium) -- account/authentication (email, token metadata), synchronized travel data/attachments, minimally required operational/error logs (edge/proxy).
• Storage duration:
  • As long as the account is active.
  • Inactivity: Deletion of cloud data after 365 days without active login (planned, see 10.6).
  • Backups: Point-in-time recovery (PITR) 7 days (rotation window).
• Deletion:
  • In-app function "Delete account & data" (deleteAccountAndData) → immediate deletion of primary data in the production database.
  • Backups: Technical immutability until scheduled overwrite after max. 7 days; no restoration from backups except for investigating a security incident/legal obligation.
  • Attachments/blobs: With account/object deletion, referenced files in cloud storage are also deleted.
• Note: Without activated cloud sync, no app content is transferred to Supabase.

10.3 Subscription/License Data (Google Play Billing & RevenueCat)

• Data types (with us):
  • Subscription/license status (plan, expiration, renewal) -- during active term, then + 90 days grace/error clarification.
  • Feature flags (Free/Premium/Pro) -- until app uninstallation or downgrade; in encrypted preferences.
• Data types (with RevenueCat):
  • Subscription/transaction data -- during active business relationship, then deletion according to DPA.
• Data types (with Google): Payment profile, billing/transaction data -- not with us, storage according to Google policies.
• Deletion: Expiration/cancellation revokes the license; local caches/status are removed/anonymized after the above periods.

10.4 Email Logs (Scaleway, Website Contact)

• Sending logs: 30 days (deliverability/error analysis).
• Bounce/complaint lists: 90 days (spam/delivery protection).
• Content data: No independent permanent storage at Scaleway beyond the sending purpose.
• With us (mailbox): No automatic deletion; manual deletion after problem resolution; legal retention obligations remain unaffected.

10.5 Advertising Data (AdMob -- Free version only)

• Data with Google (independent controller): AD_ID (if present), device/app metadata, IP (coarse location), ad events.
• Storage duration: According to Google policies; typical signal storage up to ~14 months.
• With us: No storage of personal ad profiles.
• Control: Opt-in/opt-out (personalization) in-app; AD_ID in OS reset/deactivate; upgrade removes advertising completely.

10.6 Automated Deletion Routines & Inactivity

• Planned:
  • Inactivity check for cloud accounts: Notification after 12 months without login; subsequent deletion after 365 days without response/renewed login.
  • Automated cleanup of temporary validation data (billing) after the periods specified in 10.3.
• Already active:
  • Backup rotation Supabase: Overwrite after max. 7 days.
  • Proxy/edge logs: short-cycle rotation (only operational/security purposes; no profiling).
• Website logs: Access/error logs 7-14 days (typically), cf. 6.1.

10.7 Procedure for Account Deletion (Cloud)

1. Initiation: In-app confirmation "Delete account & data."
2. Immediate action (T-0):
   • Access block, immediate deletion of primary data (database rows, storage objects) including references/metadata.
   • Invalidation of active tokens/sessions.
3. Follow-up:
   • Backups remain technically for up to 7 days and are then overwritten as part of rotation (no re-import for operational purposes).
   • Support/compliance exceptions: Restoration only if legally required (e.g., incident forensics), with logging and "need-to-know."
4. Confirmation: ACTIVE Email notice of completed deletion, if email address is available and delivery is not deactivated.

Legal bases for this section:

• Art. 5 Para. 1 lit. c/e GDPR (data minimization/storage limitation),
• Art. 6 Para. 1 lit. b/c/f GDPR (contract, legal obligations, legitimate interests),
• Art. 17 GDPR (right to erasure) -- implemented via in-app deletion functions and account delete,
• Art. 32 GDPR (security) -- including encryption/key management/backups.

11. Security (Technical & Organizational Measures -- TOMs)

Principle: Protection of confidentiality, integrity, and availability according to Art. 32 GDPR, state of the art, risk appropriateness. Measures apply to app and website; cloud components are operated in the EU (see 5.2, 6.x, 8.x, 9, 10).

11.1 Organizational Measures (Access, Role, Process Controls)

• Responsibilities & roles: Clear roles/least privilege; admin access only for a few authorized persons (need-to-know).
• Joiner/mover/leaver: On-/offboarding with documented rights assignment, immediate revocation upon departure/role change.
• Instructions/data processing: DPA with data processors (including Supabase, Scaleway). Sub-processors only according to DPA rules.
• Policies & training: Security/data protection policies; regular awareness training on phishing, password/device protection.
• Data classification & minimization: Collection "as little as possible"; separation of local/cloud data; no sensitive content in tickets/emails without explicit consent.
• Change/release management: Code reviews (four-eyes principle), reproducible builds, signed releases (store signature).
• Secret management: No secrets in source code; secure storage/rotation (provider secrets/keystore).
• Supply chain security: Updated dependencies; only necessary SDKs; avoidance of tracking libraries without opt-in.
• Incident management (IR): Documented procedures, escalation paths, notification chains; breach register (Art. 33/34).
• Audit & logging: Logging of critical admin actions; regular log review (technical, not personal).

11.2 Technical Measures -- Transport (Network/Transmission Security)

• TLS throughout: App/website ↔ services exclusively HTTPS/TLS 1.3; HSTS on the website.
• Certificate pinning (app): Active for critical endpoints (Supabase/edge, central APIs).
• No cleartext connections: Network Security Config rejects cleartext; only explicitly allowed hosts.
• Secure ciphers & PFS: Contemporary cipher suites with perfect forward secrecy (provider requirement).
• Proxy shielding: Premium requests to Google Maps/OpenWeather via EU edge/proxy (IP protection, rate limit, error sanitizing).

11.3 Technical Measures -- Storage (At-Rest Protection)

• Local (App):
  • SQLCipher 4.11.0 (AES-256) for optional DB encryption;
  • Argon2id password hashing (64MB memory, 3 iterations) -- 100-1000x more secure than SHA-256, resistant to GPU/ASIC attacks;
  • CharArray password storage with memory zeroing for increased security;
  • Triple data integrity verification (SQLite integrity check, structure verification, record count verification);
  • Biometric unlock (optional):
    • Password encrypted with AES-256-GCM in Android Keystore
    • BIOMETRIC_STRONG authentication required
    • Automatic invalidation on biometric changes
  • Android Keystore (preferably StrongBox) for keys;
  • Encrypted SharedPreferences for sensitive settings (e.g., feature flags, billing status).
• Cloud/server:
  • Encryption "at rest" (provider side, e.g., AES-256) including backups;
  • PITR backups (7 days) with automatic rotation;
  • Separation of production data and operational/error logs.
• Passwords (auth): bcrypt hashing (Supabase Auth), salting; no plain text storage.
• Data minimization: No storage of payment data; purchase validation handled via RevenueCat (data processor) -- see 5.7/8.6.

11.4 Access & Authentication (App/Backend/Admin)

• App side: Short-lived JWTs (Supabase Auth), row-level security (RLS) at database level, session timeouts; no direct third-party access to local content.
• Backend/admin access: MFA/2FA mandatory; strong passwords; IP protection/rate limit; logging of administrative access.
• Rights concept: Role/rights model (least privilege); regular review/recertification of permissions.
• Secret rotation: Regular key/token rotation; revocation of compromised tokens/sessions (invalidate on delete).
• Integrity checks ACTIVE: Regular certificate health check (worker), integrity checks for offline license window.

11.5 Monitoring, Firewalls, Backups (Operations & Availability)

• Hardening & firewalls: Provider-side network/application firewalls, rate limiting, protection against injection/XSS/CSRF (framework/middleware).
• Logging: Minimal operational/error logs (time, status, no content data); short rotation periods; no profiling.
• Performance/availability: Monitoring of core endpoints; automatic restart on failures; capacity planning.
• Backups: Encrypted backups, geographically redundant according to provider standard; PITR 7 days (see 10.2); no restoration for operational purposes after account deletion.
• Website operation: Regular core/plugin updates, theme hardening, only necessary plugins; protection against brute force/spam.

11.6 Incident Response & Notifications (Art. 33/34 GDPR)

• Detection & triage: Continuous monitoring of security-relevant events; prioritization by impact/scope.
• Containment & forensics: Immediate isolation of affected components, evidence preservation (log/system-side) to the necessary extent.
• Notification to supervisory authority: Without undue delay, where feasible within 72 hours after awareness (Art. 33), including nature, categories, approximate number of data subjects/records, consequences, and measures taken.
• Notification to data subjects: Without undue delay in case of high risk (Art. 34); clear, understandable information about risks and countermeasures.
• Follow-up: Root cause analysis, action plan, update of TOMs/training, documentation in breach register.
• Contact point: Data protection contact datenschutz@trabista.app / privacy@trabista.app (see Section 2/18); competent supervisory authority see Section 2.5.

12. Data Subject Rights

Principle: You have the following rights under Art. 15-21, 7 Para. 3, 22 GDPR. Exercise is free of charge. We respond within one month of receiving your request; extension by up to two months is possible for complex/numerous requests (notice with justification within one month). Manifestly unfounded or excessive requests may be rejected or subject to a reasonable fee.

Contact Channels for Exercising Rights:

• In-App: Settings → Privacy/Account (view/change data, local deletion functions, cloud account deletion).
• Email: datenschutz@trabista.app, privacy@trabista.app (Sections 2.3, 18).
• Mail/Phone: see Section 2.2.
• Website Cookies: Only strictly necessary cookies are set; deletion possible at any time via browser settings (Section 6.4).

Identity Verification: We may request additional information necessary to confirm identity (e.g., verification of cloud account email). This serves to protect your data.

12.1 Right to Confirmation

You have the right to request confirmation whether we process personal data concerning you (Art. 15 Para. 1 GDPR -- "whether processing").
How? Short-form request in app (cloud account) or via email (see above). For purely local data on your device, we confirm that it is processed only locally (Section 5.1).

12.2 Right of Access

You have the right to access information about:

• Processing purposes, categories of personal data, recipients/categories (including third countries/IO),
• Retention period or criteria,
• Origin of data, if not collected from you,
• Existence of automated decisions including profiling, including meaningful information about the logic involved, significance, and envisaged consequences,
• Your rights (rectification, erasure, restriction, objection, complaint).

You receive a copy of the personal data undergoing processing (Art. 15 Para. 3 GDPR). Further copies may be subject to a fee.
Note local/cloud: For local app data, only you have access (we do not). For cloud data (Supabase), we provide a structured data copy (depending on scope as download link; Sections 5.2, 10.2).

12.3 Right to Rectification

You have the right to have inaccurate personal data rectified without undue delay; incomplete data must be completed (Art. 16 GDPR).
How?

• In-App: All content (trips, participants, notes, etc.) is directly editable.
• Cloud Account: Email/profile data via app; if problems arise, via email to us.

12.4 Right to Erasure ("Right to be Forgotten")

You have the right to request erasure of personal data (Art. 17 GDPR), particularly if:

• The purpose has ceased,
• You withdraw consent and there is no other legal basis,
• You lodge an objection (Art. 21 GDPR) and no overriding grounds exist,
• Data was processed unlawfully,
• Erasure is necessary to fulfill a legal obligation,
• Data was collected in relation to information society services pursuant to Art. 8 Para. 1 GDPR.

How?

• Local (device): In-app "delete all" or selective deletion; app uninstallation completely removes local data (Section 10.1).
• Cloud: In-app "Delete account & data" → immediate primary deletion; backups overwrite within max. 7 days (no restoration for operational purposes), cf. 10.2/10.7.

Exceptions: Erasure may be refused/postponed if legal obligations or establishment/defense of legal claims prevent it (Art. 17 Para. 3 GDPR).

12.5 Right to Restriction of Processing

You may request restriction (Art. 18 GDPR) if:

• The accuracy of data is contested by you (for duration of verification),
• Processing is unlawful and you request restriction instead of erasure,
• We no longer need the data but you require it for establishment/defense of legal claims,
• You lodged an objection pursuant to Art. 21 Para. 1 GDPR (for duration of balancing).

When restricted, data is marked and processed only for the stated purposes.

12.6 Right to Data Portability

You have the right to receive data you have provided to us in a structured, commonly used, machine-readable format and -- where technically feasible -- to request direct transmission to another controller (Art. 20 GDPR).
How?

• App Export: e.g., ICS export (calendar format) via FileProvider (Sections 5.9.4/5.9.5).
• Cloud Data: Upon request data export; provision as download (format depends on data type).

12.7 Right to Object

You may at any time object to processing based on Art. 6 Para. 1 lit. e or f GDPR on grounds relating to your particular situation (Art. 21 GDPR). We will then no longer process the data unless we demonstrate compelling legitimate grounds.
Special Case Direct Marketing: Objection to processing for direct marketing is possible at any time; in this case we cease processing for these purposes.
For Trabista specifically:

• Non-personalized advertising (AdMob) is based on legitimate interest -- you can choose upgrade (ad-free) or use app offline; personalized advertising occurs only with consent (Art. 6 Para. 1 lit. a), which you can withdraw (see 12.8/5.4).
• Operational/security logs (app/website) are minimized (Sections 5.x/6.1); objection will be examined within balancing of interests.

12.8 Right to Withdraw Consent

You may withdraw granted consents at any time with effect for the future (Art. 7 Para. 3 GDPR).
How?

• In-App: Toggles for personalized advertising, Crashlytics, Analytics (by default off, 5.4/5.6).
• Website: Deletion of strictly necessary cookies possible via browser settings at any time (6.4).
• OS Settings: Notifications/exact alarms revocable; AD_ID resettable/deactivatable.
  Consequences: Withdrawal does not affect lawfulness of processing until withdrawal; respective option is deactivated.

12.9 Right to Lodge a Complaint with a Supervisory Authority

You have the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR), particularly in the Member State of your habitual residence, your place of work, or the place of the alleged infringement.
Competent at company headquarters:
Saxon Commissioner for Data Protection and Transparency
Maternistraße 17, 01067 Dresden
Phone: +49 351 85471-101 · Fax: +49 351 85471-109
Email: post@sdtb.sachsen.de · Web: www.datenschutz.sachsen.de
(Independently, you may contact any other supervisory authority in the EEA.)

12.10 Exercise of Rights (In-App & Email) -- Process & Notes

Process (Cloud Data):

1. Submit request (in-app or via email) with indication of your account email;
2. Identity verification (if necessary);
3. Processing within 1 month; possibly extension (notice with justification);
4. Provision of information/data copy/deletion confirmation via secure communication channel.

Locally Stored Data:

• This data resides exclusively on your device. You can manage/delete it yourself (Section 10.1). No remote access is possible for us.
• Upon app uninstallation, all local data is removed.

Special Cases:

• Special Categories (Art. 9 GDPR) -- only local and voluntary; we do not process them in the cloud (Sections 5.1, 7.4).
• Purchases/Subscriptions (Google Play, planned): Payment/account data resides with Google (independent controller). Exercise rights there; we support regarding license-related data (Section 5.7).
• Website Cookies: Adjustment immediately via browser settings (6.4).

13. Minors

13.1 Target Audience 18+

• Orientation: Trabista is exclusively directed at adult users (18+). The app store target audience is configured accordingly; content, functions, and communication are not child- or youth-oriented.
• No child orientation/profiles:
  • No design as a child- or youth-oriented offering, no addressing of minors, no dedicated children's areas.
  • No profiling, behavioral advertising, or personalization targeting minors.
• Cloud/online functions: The (optional) cloud synchronization as well as premium services are intended for adult users.
• Advertising (free version): Ads are not child-directed; personalization occurs only with consent (EEA/UK) and not with child-specific targeting.
• Notice upon knowledge of a minor: If we receive specific notice that an account/co-use occurs by a person below the applicable age of majority or digital consent age, we take appropriate measures:
  • Block further online processing (e.g., cloud sync),
  • Contact the reported user for clarification,
  • Deletion of the cloud account and the data stored there, unless a legal impediment prevents it.
    Local app data resides exclusively on the device and can be deleted there by the device owner.

13.2 No Parental Consent Activated

• No child consent processes: We do not collect consents from parents/guardians, as Trabista is not intended for minors and is not offered as child-oriented.
• Legal framework (EU/EEA/UK):
  • We do not rely on consents of minors for optional services. In the EU, the digital consent age is up to 16 years (depending on member state, possibly lower), in the UK 13 years. Since Trabista addresses 18+, we refrain from claiming child-related consents.
• Data subject rights by guardians: If a guardian asserts rights for an affected minor child (e.g., access/deletion for a wrongly created cloud account), we verify the representation authority and fulfill the request in accordance with GDPR (see Section 12).
• Contact point: Reports/inquiries please to datenschutz@trabista.app or privacy@trabista.app with a brief note on the minor-related matter (no upload of sensitive documents without request).

14. No Automated Individual Decision-Making/Profiling

14.1 No Decisions within the Meaning of Art. 22 GDPR

• No deployment at Trabista: No processing is carried out where exclusively automated decisions produce legal effects for users or similarly significantly affect them (Art. 22 Para. 1 GDPR).
• Specifically:
  • No credit/solvency checks, no suitability/risk assessments, no algorithmic blocking/exclusion decisions with legal effect.
  • License/access checks (e.g., Play Billing token, session/JWT validation, rate limits) are technical access controls for contract performance. They do not constitute a decision within the meaning of Art. 22; in case of technical misclassifications, manual review is possible (contact: datenschutz@trabista.app / privacy@trabista.app).
  • Support cases are always assessed by humans.
• Application procedures (Section 15): There are no automated selection/rejection decisions; decisions are human-led.

14.2 No Profiling with Legal Effect/Similar Significant Impact

• No own profiling: Trabista does not create personal usage profiles to evaluate personal aspects (e.g., interests, behavior) and make decisions based on them with legal effect.
• Analytics/crash (currently deactivated): If users voluntarily consent in the future, aggregated/technical signals (e.g., crash clusters, screen views) are used solely for product improvement -- without personal profiling, without feature gating by user characteristics.
• Advertising (AdMob):
  • Personalized advertising in EEA/UK occurs only with consent and is subject to the independent responsibility of Google under data protection law (Section 8.3.2). Even in this case, the delivery has no legal effect/similar significant impact within the meaning of Art. 22.
  • Non-personalized advertising (without opt-in) is based on context/aggregates; no profiling by us.
  • No linking of advertising signals/AD_ID with local app content (trips, notes, attachments).
• Geocoding/weather/cloud sync: The parameters generated (search strings/coordinates, sync metadata) are not used for personal profiling; no cross-device merging, no marketing segments.
• User controls: Consents can be revoked at any time (app settings / CMP; details in Section 7.3, 5.4, 5.6). For technical blocks/misclassifications perceived as unjustified: manual review upon request (contact see Section 18).

15. Application Procedures (Currently No Job Postings)

Applicability: This section applies only if you apply with us (e.g., to a job posting or unsolicited). Currently, we do not operate an applicant portal; applications are typically made by email or by post. An online form may optionally be provided; in this case, the following provisions apply accordingly.

15.1 Purposes & Legal Bases

Purposes of processing

• Conducting the application procedure: Review, selection, communication, appointment scheduling, decision preparation.
• Documentation/evidence of proper procedure (e.g., equal treatment).
• Possibly recruitment into an employment relationship.

Legal bases

• Art. 6 Para. 1 lit. b GDPR in conjunction with § 26 Para. 1 BDSG (pre-contractual measures for an employment relationship).
• Art. 6 Para. 1 lit. f GDPR (legitimate interest) for legal defense/securing evidence (e.g., within the scope of the AGG) or IT security (spam/abuse prevention).
• Art. 6 Para. 1 lit. c GDPR (legal obligations), where applicable (e.g., tax/commercial documentation for travel expense reimbursement).
• Art. 9 Para. 2 lit. b GDPR (labor law) or Art. 9 Para. 2 lit. a GDPR (explicit consent), only if you voluntarily disclose special categories of personal data (e.g., health data, disability) and these are necessary for the decision.
• Art. 6 Para. 1 lit. a GDPR (consent), only if you expressly consent to longer retention (talent pool).

15.2 Required/Voluntary Information

Required (typically):

• Master data/contact: Name, address, email, possibly phone number.
• Application documents: Cover letter, CV, qualification-related evidence (certificate copies, references).

Voluntary (optional):

• Additional information you wish to provide (e.g., portfolio, work samples).
• Special categories (Art. 9 GDPR), only if you voluntarily disclose them and they are relevant for the intended position (e.g., disclosure of a disability). In this case, we process this information purpose-bound (see 15.1) and only to the necessary extent.

Please note:
Do not submit unnecessary sensitive data. If we do not request such data, it is not necessary for the procedure.

15.3 Transmission/Transport (Email/Online Form, Encryption)

• Email application: Transport typically occurs via TLS between mail servers but is not automatically end-to-end encrypted. If you send sensitive content, we recommend PGP/SMIME or postal submission.
• Online form (if provided):
  • Transmission encrypted (HTTPS/TLS) to our server.
  • Forwarding as email to the internal mailbox (transport TLS).
  • No ticket/helpdesk system; processing occurs as email case (cf. website contact in 6.2).
• Postal route: Alternatively, you can submit documents by post.
• Internal recipients: Exclusively the departments responsible for personnel selection.
• Data processors: Mail/hosting services (EU), Scaleway for form emails (FR, EU) -- each DPA-bound; no disclosure to third parties for marketing/analytics purposes.

15.4 Storage Duration (typically 6 months) & Legal Retention

• Unsuccessful applications:
  • Deletion typically after 6 months from completion of the procedure to answer follow-up questions and defend against claims under the AGG.
  • Legal retention obligations remain unaffected (e.g., tax documentation for travel expense reimbursement -- retention according to tax/commercial retention periods).
• Talent pool (only with consent):
  • Separate, voluntary consent for extended retention (e.g., 12 months).
  • Revocation at any time with effect for the future; we delete the documents immediately unless legal obligations prevent it.
• Successful application:
  • The application documents become part of the personnel file and henceforth are processed for employment purposes (separate information obligations in employee data protection).
• Integrity & access:
  • Access only for authorized persons (need-to-know); logging of administrative access; protection against unauthorized access (technical/organizational).

Your rights in the application procedure: Access, rectification, erasure, restriction, objection, data portability, revocation of consents granted (cf. Section 12).
Contact: datenschutz@trabista.app / privacy@trabista.app (please subject "Application -- Data Protection").

16. Changes & Updates

16.1 Regular Review/Adjustment

• Review cycle: At least quarterly as well as event-driven (new features/SDKs, new recipients/regions, legal changes, app store requirements).
• Scope: App (Android & iOS) and PHP website (without CMS).
• Responsibility & documentation:
  • Internal owners (product/tech/data protection) maintain a change log with date, description, risk/legal review (including TIA/DPIA if necessary), approvals, and rollout plan.
  • DPA/sub-processor register is maintained synchronously (e.g., Supabase, Scaleway; Google as independent controller separately listed).
• Synchronization of technical artifacts: Adjustment of in-app consent (Android: CMP/UMP; iOS: Apple ATT), store questionnaires (Google Play Data Safety and Apple App Store App Privacy), release notes.

16.2 Consent-Relevant Changes (Information & Re-Consent Obligations)

Material changes are made transparent before activation; where legally necessary, we obtain new consents. These include in particular:

• New purposes or purpose changes (Art. 6 Para. 4 GDPR), e.g., introduction of analytics/crashlytics or personalized advertising in previously unaffected areas.
• New data categories (especially special categories under Art. 9 GDPR), extended logs, or profiling elements.
• New recipients/sub-processors, new regions/third countries, or changed transfer mechanisms (e.g., SCC/DPF status).
• Changes in roles/controllers, contact addresses, supervisory authority, or minimum age/target group.
• Integration of additional cookies/similar technologies (website) -- would trigger a privacy-policy update beforehand and, where legally required, a new opt-in mechanism.

How do we inform?

• In-app: Timely via notice banner/dialog with link to the new privacy policy; opt-in switches for affected features (e.g., ads personalization, analytics/crash).
• Email (cloud users only): Brief notice of material changes with link to the version and to opt-in/opt-out options.
• Website: footer notice bar; if consent-requiring cookies are introduced, an opt-in dialog would additionally be shown.

Re-consent & revocation:

• New/extended purposes are delivered deactivated (opt-in required).
• Already granted consents do not automatically apply to new purposes/categories.
• Revocation at any time in app settings/CMP (cf. Section 7.3).

16.3 Versioning & Validity

• Version information: Each version bears version and effective date (e.g., "Privacy Policy Trabista v1.0 -- effective from 2025-09-21").
• Archiving: Previous versions are archived and provided upon request; for material changes, we maintain a change log.
• Change log (excerpt):
  • 14.04.2026 -- v1.1: Release of the iOS app (native Swift app) on the Apple App Store (Sections 1, 5.4, 5.7, 8.3.6, 9.5, 16); introduction of Sentry (EU region, ingest.de.sentry.io) as error & performance analysis on iOS (new Section 5.10, 7.1(f), 8.3.7, 9.5); Section 5.4 extended with Apple App Tracking Transparency (ATT); the Firebase section (5.6) remains Android-only (opt-in).
• Multilingualism: An English translation is provided. The German version is binding.
• Publication: Simultaneous provision in the app (legal/info area) and on the website (static page). The reference to the official imprint remains unchanged (see Section 2.4).
• Conflict rule: In case of conflicts between brief notices (banner/release notes) and the complete privacy policy, the complete version applies.

17. Publication & Applicability

17.1 In-App Deposit (Legal/Info Area)

• Location: "Settings" → "Legal/Privacy."
• Version/version status: Clearly visible (e.g., "Privacy Policy Trabista v1.0 -- effective from YYYY-MM-DD").
• Offline access: Full text is cached locally so it is viewable without internet; upon updates, notice dialog (see 16).
• In-app links:
  • Privacy contact: datenschutz@trabista.app, privacy@trabista.app
  • Supervisory authority: Short link to the authority from 2.5
  • Imprint: Link to the binding imprint page (see 17.3)
• Store reference: The in-app text corresponds to the version published on the website (synchronized).

17.2 Website Publication (static page, without tracking)

• URL & findability: Static page "Privacy" in main menu/footer menu; no tracking scripts; no consent banner is required since only strictly necessary cookies are set (cf. 6.4).
• Languages: German (binding) + English (translation).
• Versioning/archive: Visible version information; older versions upon request.
• Play Store requirement: The "Privacy Policy URL" field in the Google Play listing refers to this website privacy page.
• Consistency: Content identical to the in-app version; changes are rolled out synchronously (cf. 16).

17.3 Reference to Official Imprint

• Imprint: https://impressum.gobbltech.com/\
• In-app & website: The above link is used uniformly everywhere (settings/legal in the app, footer/legal on the website).
• Contact options: Email (gobbltech@proton.me as well as datenschutz@trabista.app / privacy@trabista.app) remain unchanged; a telephone obligation does not exist (note as in Section 2).

18. Contact for Privacy Matters

18.1 Privacy Email Addresses

• Primary: datenschutz@trabista.app
• Alternative: privacy@trabista.app

Notes for efficient processing (voluntary):

• Subject e.g.: "GDPR request -- access/erasure/rectification/objection/data copy".
• Indication of the app version and -- if cloud sync is used -- the email address registered with us (for identity verification).
• No sensitive documents sent unencrypted. For confidential content, please use PGP/SMIME or initially only briefly outline; we will then coordinate the further procedure.
• We confirm receipt and respond typically within one month (Art. 12 Para. 3 GDPR). In complex cases, the period can be extended by up to two months; you will then receive an interim notification.

18.2 General Contact (without specific GDPR reference)

• Email (general): gobbltech@proton.me
• Contact form: Accessible via the official imprint (see Section 17.3).
• Postal address (delivery/legal capacity -- c/o):
  Danilo Endesfelder -- Sole Proprietorship
  c/o Nico Eberhardt
  Pfotenhauerstraße 65
  01307 Dresden
  Germany

Important:

• For GDPR rights (access, erasure, etc.), please use preferably the privacy emails from 18.1 -- this ensures fast, documented processing.
• The competent supervisory authority can be found in Section 2.5; you have the right to lodge a complaint there (Art. 77 GDPR).
• Telephone availability is not legally required; we offer email and contact form as immediate, verifiable communication channels.

Achievement unlocked: Privacy Policy 100%
Loot: GDPR know-how. Next run: Your own, robust privacy policy?
Email to info@trabista.app,
Subject "We also want a good privacy policy" -- Danilo knows someone.
Legal notice: purely informative; no change to the legal situation.