Verantwortlich im Sinne der DSGVO: Kai Rickert (Einzelunternehmer), Sternbergstraße 10, 76131 Karlsruhe, Deutschland, E-Mail: signalbytestudio@gmx.de.
Ich verarbeite personenbezogene Daten nur, soweit dies zur Bereitstellung der App, zur Funktionsfähigkeit des Backends, zur Rezeptgenerierung oder zur Erfüllung gesetzlicher Pflichten erforderlich ist.
Es findet kein Tracking, kein Profiling und keine Weitergabe zu Werbezwecken statt.
Mein Backend (api.cookgenapp.de) und die Website cookgenapp.de laufen auf einem von mir gemieteten Server der Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Deutschland, im Rechenzentrum Falkenstein (Deutschland). Hetzner ist mein Auftragsverarbeiter; ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO besteht.
Bei jedem Zugriff der App auf mein Backend und bei jedem Besuch der Website schreibt mein Webserver Zugriffsprotokolle: IP-Adresse (gekürzt: bei IPv4 ohne den letzten Block, bei IPv6 nur die ersten zwei Blöcke), Datum und Uhrzeit, aufgerufene Adresse ohne Such-, Filter- und Barcode-Angaben, HTTP-Status, übertragene Datenmenge, Referrer (falls vorhanden) und User-Agent. Zweck: sicherer Betrieb, Fehlersuche und Abwehr von Missbrauch. Die Zugriffsprotokolle werden täglich rotiert und nach spätestens 15 Tagen gelöscht; ich werte sie nur anlassbezogen aus. Bei schweren technischen Störungen kann der Webserver zusätzlich ein Fehlerprotokoll mit vollständiger IP-Adresse und aufgerufener Adresse schreiben; es wird ebenfalls täglich rotiert und nach spätestens 15 Tagen gelöscht.
Zur Begrenzung der Anfragen pro Minute nutzt das Backend die IP-Adresse außerdem im Arbeitsspeicher, ohne sie auf Datenträger zu schreiben. Die Website setzt keine Cookies, lädt keine externen Inhalte und nutzt keine Analyse-Werkzeuge.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an sicherem Betrieb, Fehlersuche und Abwehr von Missbrauch).
Sprache, Ernährungsweise, Allergien, Einheiten und optional einen Profilnamen speichert die App auf deinem Gerät. Einheiten und Profilname bleiben dort.
Tagesempfehlungen, Rezeptsuche, Kategorien und die Liste der bestbewerteten Rezepte filtert die App auf deinem Gerät nach deinen Allergien. Dafür übermittelt sie an mein Backend nur Sprache, Ernährungsweise und Such- und Filterangaben, dazu wie bei jeder Anfrage die Geräte-Kennung (4.6) und die App-Version (4.2); deine Allergien verlassen dafür das Gerät nicht.
Für die KI-Funktionen (4.2, 4.4, 4.13, 4.15) übermittelt die App Sprache und Ernährungsweise mit der Anfrage an mein Backend und von dort an Gemini (siehe Abschnitt 5), deine Allergien nur mit deiner Einwilligung (nächster Absatz).
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung).
Allergien: Ob Allergie-Angaben Gesundheitsdaten sind, ist rechtlich nicht abschließend geklärt; ich behandle sie vorsorglich so (Art. 9 DSGVO). Ich verwende sie, damit dir keine Rezepte mit diesen Allergenen vorgeschlagen werden und Nährwertschätzungen im Ernährungstagebuch dazu passen. In meine Protokolle schreibe ich nur, wie viele Allergien berücksichtigt wurden, und bei einem verworfenen Vorschlag den Grund, nicht die Allergien selbst (siehe 4.2). Vor dem ersten KI-Rezept fragt dich die App, ob sie deine Allergien dafür übermitteln darf. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO und, soweit es sich um Gesundheitsdaten handelt, deine ausdrückliche Einwilligung (Art. 9 Abs. 2 lit. a DSGVO). Ohne Einwilligung erstellt die App keine KI-Rezepte; alle anderen Funktionen bleiben nutzbar (die Nährwertschätzung im Ernährungstagebuch dann ohne Allergie-Angaben). Die App speichert deine Einwilligung mit Datum auf deinem Gerät. Du kannst sie jederzeit mit Wirkung für die Zukunft in der App unter Einstellungen → Einwilligungen widerrufen; danach übermittelt die App deine Allergien nicht mehr und fragt vor dem nächsten KI-Rezept erneut.
Ältere App-Versionen (bis 1.1.10) fragen noch nicht nach dieser Einwilligung. Sie übermitteln Allergie-Angaben weiterhin bei KI-Anfragen (an mein Backend und an Gemini, siehe 5 und 8) sowie beim Laden der Tagesempfehlungen und bei der Rezeptsuche. Mein Backend verwendet sie nur, um passende Rezepte zu erzeugen und auszuwählen, und schreibt sie nicht in seine Protokolle. Bitte aktualisiere die App.
Die vom Nutzer eingegebenen Zutaten werden an das Backend gesendet, um Rezeptvorschläge zu generieren. Zur Qualitätssicherung und Fehlererkennung erfasse ich befristet in den Anwendungs-Logs meines Backends (siehe Abschnitt 8): die Zutaten, die Ernährungsweise, die Sprache und die gewählten Premium-Filter deiner Anfrage, ob und wie oft du für dieselben Zutaten „Andere Vorschläge generieren“ angetippt hast, ob ein Gerichtwunsch gesetzt war (ohne dessen Text), wie viele Allergien berücksichtigt wurden (ohne welche), die installierte App-Version sowie die von der KI erzeugten und die von meiner automatischen Prüfung verworfenen Rezeptvorschläge; verstößt ein Vorschlag gegen eine Allergie-Angabe, steht dort nur der Grund, nicht der Vorschlag. Geräte-Kennung und IP-Adresse schreibe ich nicht in diese Logs. Die App-Version dient ausschließlich dazu, gemeldete Fehler der jeweiligen App-Fassung zuzuordnen und bereits behobene von noch bestehenden Fehlern zu unterscheiden. Es werden dabei weder Gerätemodell noch Betriebssystem übermittelt.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) sowie Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Qualitätssicherung und Fehlerbehebung).
Optional kannst du Zutaten, deinen Gerichtwunsch (Premium), Suchbegriffe im Ernährungstagebuch und Einträge der Einkaufsliste per Sprache eingeben. Die Erkennung übernimmt der auf deinem Gerät eingestellte Spracherkennungsdienst (meist Google, je nach Hersteller z. B. auch Samsung). Er kann die Aufnahme dafür ganz oder teilweise auf eigenen Servern verarbeiten; darauf habe ich keinen Einfluss. Die App sendet keine Audiodaten an mein Backend. Der erkannte Text wird wie eine getippte Eingabe behandelt (der Gerichtwunsch wie in 4.2, die Einkaufsliste bleibt auf dem Gerät). Das Mikrofon nutzt die App nur nach deiner Freigabe in der Berechtigungsabfrage und nur, wenn du die Spracheingabe startest; die Freigabe kannst du jederzeit in den Android-Einstellungen entziehen.
Rechtsgrundlage für die Verarbeitung des erkannten Textes: Art. 6 Abs. 1 lit. b DSGVO.
Premium-Nutzer können wahlweise ein Foto eines Gerichts aufnehmen oder ein bereits vorhandenes Foto aus der Galerie ihres Geräts auswählen, um daraus ein passendes Rezept zu erhalten. In beiden Fällen wird das Foto ausschließlich zur Erkennung des abgebildeten Gerichts an das Backend und von dort zur Analyse an das KI-Modell (Gemini, siehe Abschnitt 5) übermittelt. Mein Backend speichert das Foto nicht; es wird nur im Arbeitsspeicher verarbeitet und nach der Analyse verworfen. Vor dem Hochladen entfernt die App Standort- und andere Metadaten (EXIF) aus dem Bild. Zur Aufbewahrung bei Google (laut Google bis zu 55 Tage zur Missbrauchserkennung) siehe Abschnitt 8. Der erkannte Gerichtname wird dir zur Bestätigung oder Korrektur angezeigt, bevor daraus ein Rezept erstellt wird. Für das Rezept übermittelt die App den bestätigten Gerichtnamen zusammen mit Ernährungsweise und, sofern du eingewilligt hast (4.1), deinen Allergien; im Anwendungs-Log stehen dazu nur technische Angaben.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO. Die Kamera nutzt die App nur nach deiner Freigabe (in den Android-Einstellungen jederzeit entziehbar); bei der Galerie gibt die Fotoauswahl von Android nur das von dir gewählte Foto frei.
Die App kann ohne Benutzerkonto genutzt werden. Ich speichere keine Passwörter und keine Zahlungsdaten. Gesundheitsbezogene Angaben aus dem Ernährungstagebuch und dem kcal-Rechner bleiben grundsätzlich auf deinem Gerät (4.10). Allergie-Angaben übermittelt die App nur mit deiner Einwilligung (4.1). Welche Angaben einzelne Funktionen übermitteln und wie lange sie gespeichert werden, steht in 4.1, 4.2, 4.13, 4.15 und Abschnitt 8.
Bei der ersten Nutzung erzeugt die App eine zufällige Kennung (keine Hardware-ID, keine Werbe-ID). Sie enthält weder Namen noch Kontaktdaten und ermöglicht kein Tracking über andere Apps, ist aber ein Pseudonym im Sinne von Art. 4 Nr. 5 DSGVO. Die App übermittelt sie mit jeder Anfrage an mein Backend. Ich nutze sie, um tägliche Nutzungslimits durchzusetzen, den Premium-Status bei RevenueCat abzufragen (bei KI-Anfragen und für die Anzeige in der App, siehe 4.7) und Absturzberichte zuzuordnen (siehe 4.9). Auf meinem Server liegt sie als Tageszähler (Kennung, Datum, Anzahl) mit automatischem Ablauf nach spätestens 26 Stunden, als Ergebnis der Premium-Prüfung (Kennung, aktiv/nicht aktiv) für höchstens 5 Minuten und in Absturzberichten (90 Tage). Außer an RevenueCat als meinen Auftragsverarbeiter (4.7) gebe ich sie nicht weiter; nur bei einem Kauf erhält Google Play einen daraus berechneten Hashwert (siehe 4.7). Bei einer Neuinstallation erzeugt die App eine neue Kennung; zur Verknüpfung durch RevenueCat bei einer Kaufwiederherstellung siehe 4.7.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (faire Verteilung der Ressourcen, Missbrauchsschutz, Fehlerbehebung); für die Abfrage des Premium-Status siehe 4.7.
Für Kauf, Wiederherstellung und Prüfung von Premium-Abonnements setze ich RevenueCat, Inc., 1032 E Brandon Blvd #3003, Brandon, FL 33511, USA, als Auftragsverarbeiter ein. Ob Premium aktiv ist, fragt mein Backend unter der Geräte-Kennung (4.6) bei RevenueCat ab: bei KI-Anfragen und wenn die App den Premium-Status bei meinem Backend abruft. Das tut die App beim App-Start und von Zeit zu Zeit, wenn du in die App zurückkehrst, auch wenn das RevenueCat-SDK nicht läuft. RevenueCat erhält dabei von meinem Server nur die Geräte-Kennung, weder deine IP-Adresse noch Angaben zu deinem Gerät. Den zuletzt bestätigten Status (aktiv/nicht aktiv, mit Zeitpunkt) speichert die App auf deinem Gerät, um Premium in der App anzeigen zu können.
Das in die App eingebaute RevenueCat-SDK startet erst, wenn du Premium kaufen willst oder „Käufe wiederherstellen“ antippst, und beim ersten Mal erst nach einem Hinweis (siehe unten); danach startet die App es auch beim App-Start, aber nur, solange dein letzter Kauf- oder Wiederherstellungsvorgang weniger als vier Tage zurückliegt oder sobald in dieser Installation einmal ein Premium-Abo bestätigt wurde. Nur so bestätigt das SDK einen Kauf, bevor Google ihn nach drei Tagen automatisch erstattet, und erkennt ein Abo, das du später direkt im Play Store neu abschließt. Das SDK meldet sich mit der Geräte-Kennung bei RevenueCat und prüft, ob über dein Google-Play-Konto ein Abo besteht. RevenueCat erhält dabei die Geräte-Kennung, deine IP-Adresse, technische Geräteangaben (Modell, Hersteller, Android-Version), Sprach- und Ländereinstellung (Play-Store-Land), die App-Version sowie gegebenenfalls deine Kaufdaten aus Google Play (Produkt, Kaufdatum, Abo-Status), und legt dazu einen Kundendatensatz unter der Geräte-Kennung an. Zeigt die App die Premium-Übersicht von RevenueCat, lädt sie deren Gestaltung, Bilder und Schriften von Servern von RevenueCat und meldet RevenueCat, ob die Übersicht angezeigt, geschlossen oder ein Kauf begonnen wurde (mit Zeitpunkt, Sitzungskennung, Produkt, Sprache und Darstellungsmodus). Nach einer Neuinstallation kennt RevenueCat die neue Geräte-Kennung noch nicht; ein bestehendes Abo erkennt die App dann erst, wenn du „Käufe wiederherstellen“ antippst oder Premium kaufen willst. Dabei kann RevenueCat die alte und die neue Kennung verknüpfen. Zahlungsdaten erhält RevenueCat nicht. Zweck: Freischaltung und Prüfung von Premium, Wiederherstellung von Käufen, Missbrauchsschutz und Auswertung des Kaufablaufs.
Mit RevenueCat besteht ein Auftragsverarbeitungsvertrag (RevenueCat Data Processing Addendum, Fassung August 2026, revenuecat.com/dpa). RevenueCat setzt Unterauftragsverarbeiter vor allem in den USA ein und ist nicht nach dem EU-US Data Privacy Framework zertifiziert (geprüft am 25.09.2026); die Übermittlung in die USA stützt sich auf die in diesem Vertrag enthaltenen EU-Standardvertragsklauseln (Art. 46 Abs. 2 lit. c DSGVO). Eine Kopie erhältst du auf Anfrage per E-Mail.
Die eigentliche Zahlungsabwicklung erfolgt ausschließlich über Google Play Billing; Google tritt hierbei als eigenständig Verantwortlicher auf, nicht als mein Auftragsverarbeiter. Beim Kauf übergibt das RevenueCat-SDK an Google Play einen aus der Geräte-Kennung (4.6) berechneten SHA-256-Hashwert, nicht die Kennung selbst. Google speichert ihn mit dem Kauf, kann ihn nach eigener Angabe nutzen, um ungewöhnliche Aktivitäten zu erkennen, und gibt ihn in den Kaufdaten wieder aus. Der Hashwert enthält weder Namen noch Kontaktdaten, bleibt aber ein Pseudonym: Wer die Kennung kennt, kann ihn dem Kauf zuordnen. Zahlungsdaten (z. B. Karten- oder Kontodaten) laufen zu keinem Zeitpunkt über mein Backend, sondern werden direkt von Google verarbeitet. Es gelten ergänzend die Datenschutzbestimmungen von Google Play.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO für Kauf, Wiederherstellung und Prüfung deines Abos, einschließlich der Schritte vor einem Kauf, die du selbst anstößt. Soweit kein Abo besteht, stütze ich die Abfrage des Premium-Status über mein Backend und die weiteren Starts des SDK nach einem begonnenen Kauf oder einer Wiederherstellung auf Art. 6 Abs. 1 lit. f DSGVO (Prüfung von Premium, Abschluss begonnener Käufe, Missbrauchsschutz), die Auswertung des Kaufablaufs in jedem Fall (Verbesserung des Kaufablaufs). Das SDK speichert und liest Informationen auf deinem Gerät erst, wenn du kaufen oder Käufe wiederherstellen willst; das ist für diese von dir gewünschte Funktion unbedingt erforderlich (§ 25 Abs. 2 Nr. 2 TDDDG).
Google Play Billing Library: Für die Anbindung an Google Play enthält das RevenueCat-SDK die Google Play Billing Library von Google. Immer wenn das SDK startet (siehe oben), auch bei den dort genannten App-Starts ohne Kauf, schreibt diese Bibliothek technische Protokolldaten in einen Zwischenspeicher auf deinem Gerät und sendet sie selbstständig im Hintergrund gesammelt an Google: Angaben zur Nutzung der Bibliothek (etwa ob Aufrufe erfolgreich waren oder fehlschlugen) und zu Verbindungsproblemen samt Fehlermeldungen (z. B. dass der Kaufdienst auf dem Gerät nicht verfügbar ist), die Version der Bibliothek, Paketname und Version der App, Gerätehersteller, -marke und -modell sowie weitere technische Geräte- und Hardwarebezeichnungen, Android-Version und -Build (einschließlich Build-Fingerprint, der Gerätetyp und genaue Android-Fassung bezeichnet), Land, Sprache, Mobilfunknetz (Länder- und Netzbetreibercode), Netzwerktyp, Zeitzone sowie Zeitpunkt der Ereignisse und des Hochladens, jeweils mit der Laufzeit des Geräts seit dem letzten Neustart. Beim Hochladen erhält Google technisch bedingt auch deine IP-Adresse. Google nutzt diese Daten nach eigener Angabe, um die Leistung der Bibliothek zu verbessern und bei Fehlern besser unterstützen zu können. Google verarbeitet sie auch zu eigenen Zwecken und ist dabei nicht mein Auftragsverarbeiter. Empfänger ist Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irland. Für das Erheben dieser Daten in der App und ihre Übermittlung an Google bin ich verantwortlich (Einzelheiten und deine Rechte siehe 9). Für alles, was Google danach mit den Daten macht, ist Google allein verantwortlich und verarbeitet sie nach seiner Datenschutzerklärung; dabei können Daten an die Google LLC in den USA übermittelt werden, die nach dem EU-US Data Privacy Framework zertifiziert ist. Die Bibliothek bietet keine Möglichkeit, diese Übermittlung abzuschalten. CookGen wickelt Käufe ausschließlich über das Abrechnungssystem von Google Play ab, und ohne die Bibliothek ist ein solcher Kauf nicht möglich. Rechtsgrundlage für das Erheben und Übermitteln dieser Daten durch die App ist Art. 6 Abs. 1 lit. f DSGVO: mein berechtigtes Interesse, Premium über das von Google vorgeschriebene Abrechnungssystem von Google Play anzubieten, das nur mit dieser Bibliothek funktioniert. Eine Einwilligung frage ich dafür nicht ab, weil du sie nicht verweigern könntest, ohne auf den Kauf zu verzichten; du kannst aber widersprechen (Art. 21 DSGVO, siehe 9). Auf dein Gerät greift die Bibliothek erst zu, wenn du kaufen oder Käufe wiederherstellen willst (§ 25 Abs. 2 Nr. 2 TDDDG); zum Zwischenspeicher auf deinem Gerät siehe 7.
Hinweis vor dem ersten Start: Bevor die App das RevenueCat-SDK und damit die Google Play Billing Library in dieser Installation zum ersten Mal startet, weist sie dich im Kaufablauf auf die hier beschriebene Datenverarbeitung hin. Mit „Weiter“ startet sie das SDK und setzt den Kauf oder die Wiederherstellung fort; mit „Abbrechen“ startet nichts. Solange du nicht kaufen oder Käufe wiederherstellen willst, startet die App weder das SDK noch die Bibliothek; alle kostenlosen Funktionen bleiben nutzbar. Dass du „Weiter“ gewählt hast, wann du zuletzt kaufen oder Käufe wiederherstellen wolltest und ob hier schon einmal ein Premium-Abo bestätigt wurde, speichert die App auf deinem Gerät; danach richtet sich, ob sie das SDK beim App-Start startet (siehe oben).
Ältere App-Versionen (bis 1.1.10) starten das RevenueCat-SDK samt Google Play Billing Library bei jedem App-Start, auch ohne Kaufabsicht. Bitte aktualisiere die App.
Bewertungen (1–5 Sterne) werden an mein Backend übermittelt und dort einzeln mit Zeitpunkt, aber ohne Geräte-Kennung und ohne IP-Adresse gespeichert und nur für Durchschnittswerte ausgewertet (z. B. „Beliebteste Rezepte“). Ich ordne Bewertungen keinem Nutzer oder Gerät zu.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer nutzerbasierten Qualitätsbewertung der Rezepte).
Bei technischen Fehlern innerhalb der App werden automatisch begrenzte Diagnosedaten (Fehlermeldung, technischer Stacktrace, App-Version, Betriebssystem, Gerätemodell, die Geräte-Kennung aus 4.6) an mein eigenes Backend übermittelt, um Fehler zu erkennen und zu beheben. Absturzberichte enthalten keine Rezeptinhalte oder Zutatenlisten; technische Fehlermeldungen können in Einzelfällen Bruchstücke einer Eingabe oder einer Serverantwort enthalten. Ich werte sie ausschließlich zur Fehlerbehebung aus. Die Daten verbleiben ausschließlich auf meinem eigenen Server, es erfolgt keine Weitergabe an Dritte; sie werden nach spätestens 90 Tagen automatisch gelöscht.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Stabilität und Fehlerbehebung der App).
Das optionale Ernährungstagebuch speichert deine Einträge (Datum, Mahlzeit, Lebensmittel/Rezept, Menge, kcal und Makronährstoffe) sowie — falls du sie einträgst — deine persönlichen Daten für die Kalorienbedarfsberechnung (Alter, Größe, Gewicht, biologisches Geschlecht), deinen Gewichtsverlauf und deine Tagesziele (kcal- und Makro-Ziele) ausschließlich lokal auf deinem Gerät. Diese Daten werden grundsätzlich nicht an mein Backend oder an Dritte übermittelt. Ausnahmen, jeweils nur bei aktiver Nutzung: Suchbegriffe, Barcodes und eigene Lebensmittel (4.11, 4.12), der bestätigte Gerichtname bei der Foto-Erkennung (4.13) sowie Restkalorien und Gewichtsziel beim Rezept für deine Restkalorien (siehe 4.15). Du kannst Tagebuch, Gewichtsverlauf und persönliche Daten jederzeit einzeln über eigene Löschfunktionen in der App entfernen („Tagebuch löschen“ im Tagebuch, „Verlauf löschen“ im Fortschritts-Screen, „Persönliche Daten löschen“ im Profil).
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung, Bereitstellung der Tagebuch-Funktion).
Wenn du im Tagebuch nach einem Lebensmittel suchst (per Texteingabe oder Barcode-Scan), wird der Suchbegriff bzw. der gescannte Barcode von meinem Backend an folgende externe Datenbanken weitergeleitet, um Namen und Nährwerte zu finden:
Die Anfrage erfolgt jeweils von meinem eigenen Backend aus, nicht direkt von deinem Gerät — beide Anbieter sehen dabei nur die Server-IP-Adresse meines Backends, nicht deine eigene IP-Adresse. Der Suchbegriff selbst ist in aller Regel ein generischer Lebensmittelname ohne Personenbezug (vergleichbar mit den Zutaten-Eingaben aus 4.2). Mein Backend speichert Suchbegriffe und Barcodes nicht; nur bei schweren technischen Störungen können sie als Teil der aufgerufenen Adresse im Fehlerprotokoll des Webservers stehen (Abschnitt 3).
Weder mit Open Food Facts noch mit USDA besteht ein klassischer Auftragsverarbeitungsvertrag: Open Food Facts bietet für die kostenlose öffentliche API keinen gesonderten AVV an, USDA ist als US-Bundesbehörde kein Auftragsverarbeiter im Sinne der DSGVO. Da keine direkt personenbezogenen Daten übermittelt werden (siehe oben) und die Übermittlung durch mein eigenes Backend erfolgt, stütze ich diese Übermittlung auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer funktionsfähigen Lebensmittel-Datenbank-Anbindung).
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) sowie Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse, siehe oben).
Barcode-Scan: Den Barcode erkennt die App auf deinem Gerät mit der Bibliothek ML Kit von Google; es wird kein Bild übermittelt, an mein Backend geht nur die Barcode-Nummer. ML Kit legt dafür eine zufällige Kennung auf deinem Gerät an, schreibt dabei technische Nutzungs- und Diagnosedaten in einen Zwischenspeicher auf deinem Gerät und sendet sie selbstständig im Hintergrund gesammelt an Google: Paketname und Version der App, Version von ML Kit, Gerätehersteller und -modell sowie weitere technische Geräte- und Hardwarebezeichnungen, Android-Version und -Build (einschließlich Build-Fingerprint, der Gerätetyp und genaue Android-Fassung bezeichnet), Land, Sprache, Mobilfunknetz (Länder- und Netzbetreibercode), Netzwerktyp, Zeitzone, Leistungswerte, Einstellungen der Erkennung, Fehlercodes und diese Kennung sowie Zeitpunkt der Ereignisse und des Hochladens, jeweils mit der Laufzeit des Geräts seit dem letzten Neustart. Beim Hochladen erhält Google technisch bedingt auch deine IP-Adresse. Google nutzt diese Daten nach eigener Angabe für Diagnose und Nutzungsstatistik von ML Kit, um ML Kit zu warten und zu verbessern und um Missbrauch zu erkennen. Empfänger ist Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irland. Für das Erheben dieser Daten in der App und ihre Übermittlung an Google bin ich verantwortlich (Einzelheiten und deine Rechte siehe 9). Für alles, was Google danach mit den Daten macht, ist Google allein verantwortlich und verarbeitet sie nach seiner Datenschutzerklärung; dabei können Daten an die Google LLC in den USA übermittelt werden, die nach dem EU-US Data Privacy Framework zertifiziert ist. In der App lässt sich diese Übermittlung nicht abschalten. Rechtsgrundlage: deine Einwilligung, die die App vor der ersten Nutzung des Scanners einholt (Art. 6 Abs. 1 lit. a DSGVO, § 25 Abs. 1 TDDDG); zur Kennung und zum Zwischenspeicher auf deinem Gerät siehe 7. Ohne Einwilligung kannst du Lebensmittel weiterhin über die Suche eintragen. Du kannst die Einwilligung jederzeit mit Wirkung für die Zukunft in der App unter Einstellungen → Einwilligungen widerrufen. Daten, die bis zum Widerruf auf deinem Gerät zwischengespeichert wurden, können danach noch an Google gesendet werden, solange sie nicht älter als sieben Tage sind (siehe 8).
Findest du beim Suchen kein passendes Ergebnis, gibt es zwei Möglichkeiten:
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) sowie — für das eigene Lebensmittel — Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer wachsenden, für alle Nutzer nützlichen Lebensmittel-Datenbank).
Premium-Nutzer können ein Lebensmittel oder Gericht fürs Tagebuch per Foto erkennen lassen, wahlweise mit der Kamera oder aus der Galerie. Das Foto geht zur Erkennung an mein Backend und von dort an Gemini (siehe Abschnitt 5); mein Backend speichert es nicht (zur Aufbewahrung bei Google siehe Abschnitt 8). Den erkannten Namen bestätigst oder korrigierst du. Danach sendet die App den bestätigten Namen zusammen mit Ernährungsweise, App-Sprache und, sofern du eingewilligt hast (4.1), deinen Allergien an mein Backend und an Gemini, um kcal und Makronährstoffe je Portion zu schätzen. Deine übrigen Tagebucheinträge werden nicht übermittelt. Auf Wunsch („Auch als Rezept in Favoriten speichern“) lässt die App daraus zusätzlich ein vollständiges Rezept wie in 4.4 erstellen und legt es in deinen Favoriten ab. Im Anwendungs-Log stehen dazu nur technische Angaben.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO; zur Kamera- und Galerie-Freigabe siehe 4.4.
Du kannst folgende lokal gespeicherte App-Daten (Tagebuch, persönliche Daten und Gewichtsverlauf aus 4.10, Favoriten, Gewürz-Favoriten, Einkaufsliste, Essensplan, Allergien, Ernährungsweise, Anzeigename, Tagesziele) über die Einstellungen als Datei exportieren bzw. eine zuvor exportierte Datei wieder einspielen. Beim Erstellen und Wiederherstellen öffnet sich jeweils der native Datei-Dialog deines Betriebssystems — die Datei wird dabei NICHT automatisch an mein Backend oder an Dritte übermittelt. Wo du die Datei speicherst (z. B. lokal oder in einem selbst gewählten cloud-synchronisierten Ordner), entscheidest ausschließlich du selbst; das liegt außerhalb meines Einflussbereichs und ist keine Verarbeitung durch mich. Die Datei ist nicht verschlüsselt und enthält auch Gesundheitsangaben; bewahre sie entsprechend sorgfältig auf.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung).
Im Ernährungstagebuch kannst du dir als Premium-Nutzer ein Rezept vorschlagen lassen, das zu den heute noch offenen Kalorien passt. Nur wenn du diese Funktion aktiv aufrufst, werden für die einzelne Anfrage folgende Daten an mein Backend (siehe Abschnitt 3) und von dort an das KI-Modell (Gemini, siehe Abschnitt 5) übermittelt: die gewünschte Kalorienmenge (vorbelegt mit deinen Restkalorien für heute), der gewählte Makro-Schwerpunkt, dein Gewichtsziel aus dem kcal-Rechner (ohne Angabe: „Gewicht halten“), deine Ernährungsweise, die App-Sprache und, sofern du eingewilligt hast (4.1), deine Allergien; bei „Anderer Vorschlag“ zusätzlich die Titel der zuvor vorgeschlagenen Rezepte. Die Geräte-Kennung dient dabei dem Tageslimit (siehe 4.6) und der Premium-Prüfung (siehe 4.7). Vor der ersten Nutzung weist dich die App darauf hin; gesendet wird erst, wenn du „Einverstanden“ wählst.
Alter, Größe, Gewicht, biologisches Geschlecht und deine Tagebucheinträge verlassen dein Gerät dabei nicht. Die übermittelten Werte werden auf meinem Backend weder gespeichert noch zwischengespeichert; zur Aufbewahrung von KI-Anfragen bei Google (bis zu 55 Tage) siehe Abschnitt 8 („KI-Anfragen (Gemini)“). Das Anwendungs-Log erfasst je Anfrage nur technische Angaben ohne diese Werte: ob das Rezept im Zielbereich lag, die Portion angepasst wurde oder kein Rezept entstand, den Anpassungsfaktor, die Abweichung in Prozent, ob eine Korrektur-Anfrage an die KI nötig war, die technische Art beanstandeter Vorschläge (z. B. „keine Kalorienangabe“; nie mit Bezug zu Allergien oder Ernährungsweise), die Version der Anfrage-Vorlage, den Token-Verbrauch der KI-Anfragen und gegebenenfalls technische Fehlermeldungen.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung, Bereitstellung der Premium-Funktion) sowie, soweit die Angaben Rückschlüsse auf deine Gesundheit zulassen, Art. 9 Abs. 2 lit. a DSGVO (ausdrückliche Einwilligung durch „Einverstanden“ im Hinweis vor der ersten Nutzung). Du kannst die Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen, indem du die Funktion nicht mehr nutzt oder die Einwilligung in der App unter Einstellungen → Einwilligungen zurücknimmst; die App fragt dann vor der nächsten Nutzung erneut. Es werden danach keine dieser Werte mehr übermittelt.
Tippst du in den Einstellungen auf „Bewerte die App“, bittet die App Google Play, das Bewertungsfenster anzuzeigen (ob es erscheint, entscheidet Google), oder öffnet den Store-Eintrag, falls das nicht verfügbar ist. Die Bewertung läuft vollständig über Google Play; dafür ist Google allein verantwortlich (siehe die Datenschutzerklärung von Google). Die App erfährt nicht, ob und wie du bewertest. Öffentliche Rezensionen sehe ich in der Play Console mit dem dort angezeigten Namen, Sternen, Text und Datum sowie den von Google mitgelieferten technischen Angaben (Gerätemodell, Android-Version, App-Version, Sprache) und kann sie dort öffentlich beantworten.
Rechtsgrundlage für das Lesen und Beantworten von Rezensionen: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Rückmeldungen zur App und an ihrer Beantwortung).
Für die KI-Funktionen (Rezeptvorschläge, Foto-Erkennung, Nährwertschätzung) übermittelt mein Backend je nach Funktion folgende Daten an ein KI-Modell: Zutaten, Ernährungsweise, Sprache, gewählte Premium-Filter und den Gerichtwunsch (4.2), deine Allergien, sofern du eingewilligt hast (4.1), bestätigte Gerichtnamen (4.4, 4.13) sowie bei der Funktion aus 4.15 zusätzlich die dort genannten Werte. Die Geräte-Kennung und deine IP-Adresse gehen dabei nicht an den KI-Anbieter; er sieht nur die IP-Adresse meines Servers. Weitere personenbezogene Daten gehen nur an die KI, wenn du sie selbst in ein Freitextfeld eingibst.
Für die optionale Foto-Rezept-Erkennung (siehe 4.4) wird zusätzlich das ausgewählte oder aufgenommene Foto zur Bilderkennung an dasselbe KI-Modell übermittelt; es wird ausschließlich zur Erstellung der Antwort verarbeitet, nicht dauerhaft gespeichert oder zu Trainingszwecken verwendet (siehe unten), und von meinem Backend unmittelbar nach der Verarbeitung verworfen.
Für die optionale Foto-Erkennung im Ernährungstagebuch (siehe 4.13) gilt dasselbe: Das Foto wird ausschließlich zur Erkennung verarbeitet und von meinem Backend unmittelbar danach verworfen.
KI-Anbieter ist Google mit dem Modell Gemini über die kostenpflichtige Gemini-API. Vertragspartner: Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Irland. Google verarbeitet die Anfragen als mein Auftragsverarbeiter nach dem „Google Data Processing Addendum for Products Where Google is a Data Processor“ (business.safety.google/processorterms). Google kann Anfragen auch außerhalb der EU verarbeiten oder vorübergehend zwischenspeichern, insbesondere durch die Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. Die Übermittlung in die USA stützt sich vorrangig auf das EU-US Data Privacy Framework (Angemessenheitsbeschluss, Art. 45 DSGVO; Google LLC ist zertifiziert, geprüft am 25.09.2026), ergänzend auf die im Vertrag enthaltenen EU-Standardvertragsklauseln (Art. 46 Abs. 2 lit. c DSGVO).
Da CookGen die kostenpflichtige Gemini-API nutzt, werden laut Googles Nutzungsbedingungen weder die übermittelten Zutaten, Einstellungen und Werte noch die generierten Antworten zum Training oder zur Verbesserung von Googles Modellen verwendet.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.
Die App enthält fest hinterlegte Affiliate-Links zu Amazon und – über das Partnernetzwerk AWIN AG, Otto-Ostrowski-Straße 1A, 10249 Berlin – zu Picnic. Die Links öffnen sich außerhalb der App in deinem Browser oder in der App des Anbieters; die App übermittelt dabei keine Daten über dich. Ab dem Klick verarbeiten Amazon, Awin und Picnic Daten (z. B. IP-Adresse, Cookies zur Zuordnung der Provision) in eigener Verantwortung. Ich erhalte lediglich eine Provision, wenn ein Kauf zustande kommt.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Refinanzierung der App).
Die App setzt keine Cookies, nutzt keine Werbe- oder Tracking-Werkzeuge und kein eigenes Analyse-SDK und zeigt keine personalisierte Werbung. Drei eingebundene Bibliotheken senden allerdings selbstständig technische Daten an ihre Anbieter: das Abo-SDK von RevenueCat (Premium-Prüfung und Ereignisse der Premium-Übersicht) und die darüber eingebundene Google Play Billing Library von Google (Protokolldaten), beide erst, wenn du Premium kaufen oder Käufe wiederherstellen willst, danach in den in 4.7 genannten Fällen auch beim App-Start, sowie ML Kit von Google beim Barcode-Scan, erst nach deiner Einwilligung (siehe 4.11). Auf deinem Gerät speichert die App deine Einstellungen und Inhalte (4.1, 4.10), die Geräte-Kennung (4.6), den zuletzt bestätigten Premium-Status, ob du den Hinweis vor dem ersten Start des Abo-SDK bestätigt hast, wann du zuletzt kaufen oder Käufe wiederherstellen wolltest und ob hier schon einmal Premium bestätigt wurde (4.7) sowie einen Zwischenspeicher für Rezeptbilder. Diese Speicherungen der App selbst sind für die von dir genutzten Funktionen unbedingt erforderlich (§ 25 Abs. 2 Nr. 2 TDDDG). Erst wenn du kaufen oder Käufe wiederherstellen willst, entstehen die Speicherungen des RevenueCat-SDK (etwa sein Zwischenspeicher für den Premium-Status) und der Zwischenspeicher der Google Play Billing Library für ihre Protokolldaten; sie gehören zu dieser von dir gewünschten Funktion (§ 25 Abs. 2 Nr. 2 TDDDG, siehe 4.7). Erst nach deiner Einwilligung entstehen die Kennung von ML Kit und sein Zwischenspeicher für Nutzungs- und Diagnosedaten; dafür gilt deine Einwilligung (§ 25 Abs. 1 TDDDG, siehe 4.11). Keine dieser Kennungen dient Werbung oder dem Tracking über andere Apps.
Andere als die hier genannten Speicherungen nehme ich nicht vor, sofern keine gesetzliche Aufbewahrungspflicht besteht.
Nutzer haben folgende Rechte:
Zuständigkeiten bei den Google-Bibliotheken: Für das Erheben der Protokolldaten der Google Play Billing Library (4.7) und der Nutzungs- und Diagnosedaten von ML Kit (4.11) in der App und für ihre Übermittlung an Google bin ich verantwortlich: Ich entscheide, ob und wann die App die Bibliotheken nutzt (die Billing Library erst, wenn du kaufen oder Käufe wiederherstellen willst, und danach nur in den in 4.7 genannten Fällen; den Scanner mit ML Kit erst nach deiner Einwilligung), und informiere dich in dieser Erklärung und in den Dialogen der App. Für die Verarbeitung nach dem Eingang bei Google ist die Google Ireland Limited allein verantwortlich; welche Daten die Bibliotheken erheben und was Google damit macht, legt Google fest. Diese Aufteilung entspricht den Bedingungen, die ich mit Google vereinbart habe (Vertriebsvereinbarung für Google Play und Nutzungsbedingungen für Google-APIs, jeweils mit den Google Controller-Controller Data Protection Terms): Danach ist jede Seite für ihre eigene Verarbeitung verantwortlich, und ich informiere dich über die Datenerhebung in meiner App. Mit allen Anliegen zu diesen Daten kannst du dich an mich wenden; zu den Daten, die bei Google liegen, kannst du deine Rechte außerdem direkt bei Google geltend machen (policies.google.com/privacy). Über diese Daten kann nur Google Auskunft geben; ich habe darauf keinen Zugriff.
Widerspruchsrecht (Art. 21 DSGVO): Soweit ich Daten auf Grundlage berechtigter Interessen verarbeite (Art. 6 Abs. 1 lit. f DSGVO), kannst du aus Gründen, die sich aus deiner besonderen Situation ergeben, jederzeit widersprechen. Eine E-Mail an signalbytestudio@gmx.de genügt.
Die meisten Einstellungen und Daten (Sprache, Ernährungsweise, Allergien, Favoriten, Bewertungen, Tagebuch, persönliche Daten, Gewichtsverlauf) liegen auf deinem Gerät und sind damit jederzeit verfügbar und übertragbar; was davon an mein Backend geht, steht in Abschnitt 4. Über die Backup-Funktion (siehe 4.14) kannst du sie zusätzlich jederzeit als Datei exportieren. Für gezieltes Löschen stehen dir eigene Funktionen in der App zur Verfügung („Tagebuch löschen“, „Verlauf löschen“, „Persönliche Daten löschen“).
Da es keine Benutzerkonten gibt, kann ich Daten auf meinem Server und bei RevenueCat nur zuordnen, wenn du mir einen Anhaltspunkt nennst, etwa bei einem eigenen Lebensmittel dessen Namen. Protokolle, Zähler und Absturzberichte laufen nach den Fristen in Abschnitt 8 automatisch ab.
Anfragen können per E-Mail gestellt werden.
Stand: September 2026. Ich passe diese Erklärung an, wenn sich Funktionen oder Dienstleister ändern. Maßgeblich ist die jeweils aktuelle Fassung auf cookgenapp.de/datenschutz; die in einer älteren App-Version angezeigte Fassung kann veraltet sein.
Controller within the meaning of the GDPR: Kai Rickert (sole trader), Sternbergstraße 10, 76131 Karlsruhe, Germany, email: signalbytestudio@gmx.de.
I only process personal data to the extent necessary for providing the app, the functionality of the backend, recipe generation, or the fulfillment of legal obligations.
No tracking, profiling, or disclosure for advertising purposes takes place.
My backend (api.cookgenapp.de) and the website cookgenapp.de run on a server I rent from Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany, in the Falkenstein data center (Germany). Hetzner is my processor; a data processing agreement under Art. 28 GDPR is in place.
For every request from the app to my backend and every visit to the website, my web server writes access logs: IP address (truncated: for IPv4 without the last block, for IPv6 only the first two blocks), date and time, requested address without search, filter and barcode details, HTTP status, amount of data transferred, referrer (if any) and user agent. Purpose: secure operation, troubleshooting and preventing abuse. The access logs are rotated daily and deleted after at most 15 days; I only review them when there is a reason to. In the event of serious technical faults, the web server may additionally write an error log with the full IP address and requested address; it is also rotated daily and deleted after at most 15 days.
To limit requests per minute, the backend also uses the IP address in memory without writing it to disk. The website sets no cookies, loads no external content and uses no analytics tools.
Legal basis: Art. 6(1)(f) GDPR (legitimate interest in secure operation, troubleshooting and preventing abuse).
The app stores your language, diet, allergies, units and, optionally, a profile name on your device. Units and profile name stay there.
The app filters the daily picks, recipe search, categories and the list of top-rated recipes on your device by your allergies. For this, it only sends language, diet and search and filter details to my backend, plus, as with every request, the device identifier (4.6) and the app version (4.2); your allergies do not leave the device for this.
For the AI features (4.2, 4.4, 4.13, 4.15), the app sends language and diet with the request to my backend and from there to Gemini (see Section 5), your allergies only with your consent (next paragraph).
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment).
Allergies: Whether allergy information counts as health data has not been conclusively settled legally; as a precaution, I treat it as such (Art. 9 GDPR). I use it so that no recipes containing these allergens are suggested to you and so that nutrition estimates in the nutrition diary match them. In my logs I only record how many allergies were taken into account and, for a rejected suggestion, the reason, not the allergies themselves (see 4.2). Before the first AI recipe, the app asks whether it may send your allergies for this. Legal basis: Art. 6(1)(b) GDPR and, insofar as health data is concerned, your explicit consent (Art. 9(2)(a) GDPR). Without your consent, the app does not create AI recipes; all other features remain available (the nutrition estimate in the nutrition diary then without allergy information). The app stores your consent with its date on your device. You can withdraw it at any time with effect for the future in the app under Settings → Consents; after that, the app no longer sends your allergies and asks again before the next AI recipe.
Older app versions (up to 1.1.10) do not yet ask for this consent. They continue to send allergy information with AI requests (to my backend and to Gemini, see 5 and 8) and when loading the daily picks and searching recipes. My backend uses it only to create and select suitable recipes and does not write it to its logs. Please update the app.
Ingredients entered by the user are sent to the backend to generate recipe suggestions. For quality assurance and error detection, I record the following for a limited time in my backend's application logs (see Section 8): the ingredients, diet, language and selected Premium filters of your request, whether and how often you tapped “Generate other suggestions” for the same ingredients, whether a dish request was set (without its text), how many allergies were taken into account (not which ones), the installed app version, and the recipe suggestions generated by the AI as well as those rejected by my automatic checks; if a suggestion violates an allergy entry, the log contains only the reason, not the suggestion. I do not write the device identifier or IP address into these logs. The app version is used solely to attribute reported issues to the respective app release and to distinguish already-fixed from still-present errors. Neither device model nor operating system is transmitted.
Legal basis: Art. 6(1)(b) GDPR (contract performance) and Art. 6(1)(f) GDPR (legitimate interest in quality assurance and error resolution).
You can optionally enter ingredients, your dish request (Premium), diary search terms and shopping list items by voice. Recognition is performed by the speech recognition service set on your device (usually Google, depending on the manufacturer also e.g. Samsung). It may process the recording wholly or partly on its own servers; this is outside my control. The app does not send any audio to my backend. The recognized text is treated like typed input (the dish request as in 4.2; shopping list items stay on the device). The app only uses the microphone after you allow it in the permission prompt and only when you start voice input; you can revoke the permission at any time in Android settings.
Legal basis for processing the recognized text: Art. 6(1)(b) GDPR.
Premium users can either take a photo of a dish or choose an existing photo from their device's gallery to receive a matching recipe. In both cases, the photo is transmitted solely to identify the dish shown, to the backend and from there to the AI model (Gemini, see Section 5) for analysis. My backend does not store the photo; it is processed in memory only and discarded after analysis. Before uploading, the app removes location and other metadata (EXIF) from the image. For retention at Google (according to Google, up to 55 days for abuse detection) see Section 8. The recognized dish name is shown to you for confirmation or correction before a recipe is generated from it. For the recipe, the app transmits the confirmed dish name together with your diet and, if you have consented (4.1), your allergies; the application log only records technical information about it.
Legal basis: Art. 6(1)(b) GDPR. The app only uses the camera after you grant permission (revocable at any time in Android settings); for the gallery, Android's photo picker only shares the photo you select.
The app can be used without a user account. I do not store passwords or payment data. Health-related information from the nutrition diary and the calorie calculator generally stays on your device (4.10). The app only transmits allergy information with your consent (4.1). Which information individual features transmit and how long it is stored is described in 4.1, 4.2, 4.13, 4.15 and Section 8.
On first use, the app generates a random identifier (not a hardware ID, not an advertising ID). It contains no name or contact details and enables no tracking across other apps, but it is a pseudonym within the meaning of Art. 4(5) GDPR. The app sends it with every request to my backend. I use it to enforce daily usage limits, to query the Premium status from RevenueCat (for AI requests and for display in the app, see 4.7) and to assign crash reports (see 4.9). On my server it is kept as a daily counter (identifier, date, count) that expires automatically after at most 26 hours, as the result of the Premium check (identifier, active/inactive) for at most 5 minutes, and in crash reports (90 days). I do not pass it on except to RevenueCat as my processor (4.7); only when you make a purchase does Google Play receive a hash value derived from it (see 4.7). A reinstall creates a new identifier; for linking by RevenueCat when a purchase is restored, see 4.7.
Legal basis: Art. 6(1)(f) GDPR (fair allocation of resources, abuse prevention, troubleshooting); for the Premium status query, see 4.7.
For purchasing, restoring and verifying Premium subscriptions, I use RevenueCat, Inc., 1032 E Brandon Blvd #3003, Brandon, FL 33511, USA, as my processor. My backend asks RevenueCat under the device identifier (4.6) whether Premium is active: for AI requests and when the app retrieves the Premium status from my backend. The app does this at every app start and from time to time when you return to the app, even when the RevenueCat SDK is not running. RevenueCat receives only the device identifier from my server, neither your IP address nor information about your device. The app stores the most recently confirmed status (active/inactive, with its time) on your device so that it can show Premium in the app.
The RevenueCat SDK built into the app only starts when you want to buy Premium or tap “Restore purchases”, and the first time only after a notice (see below); after that, the app also starts it at app start, but only while your last purchase or restore was less than four days ago, or once a Premium subscription has been confirmed in this installation. Only this way does the SDK confirm a purchase before Google automatically refunds it after three days, and recognize a subscription you later take out again directly in the Play Store. The SDK contacts RevenueCat using the device identifier and checks whether a subscription exists via your Google Play account. RevenueCat receives the device identifier, your IP address, technical device information (model, manufacturer, Android version), language and country settings (Play Store country), the app version and, where applicable, your Google Play purchase data (product, purchase date, subscription status), and creates a customer record under the device identifier. When the app shows RevenueCat's Premium overview, it loads its design, images and fonts from RevenueCat servers and reports to RevenueCat whether the overview was shown, closed or a purchase was started (with time, session identifier, product, language and display mode). After a reinstall, RevenueCat does not yet know the new device identifier; the app only recognizes an existing subscription once you tap “Restore purchases” or want to buy Premium. RevenueCat may then link the old and new identifiers. RevenueCat receives no payment data. Purpose: unlocking and verifying Premium, restoring purchases, preventing abuse and evaluating the purchase flow.
A data processing agreement is in place (RevenueCat Data Processing Addendum, August 2026 version, revenuecat.com/dpa). RevenueCat uses sub-processors mainly in the USA and is not certified under the EU-US Data Privacy Framework (checked 25 September 2026); the transfer to the USA is based on the EU Standard Contractual Clauses included in that agreement (Art. 46(2)(c) GDPR). You can obtain a copy by email.
The actual payment processing is handled exclusively via Google Play Billing; Google acts as an independent controller in this respect, not as my processor. When you make a purchase, the RevenueCat SDK passes Google Play a SHA-256 hash value computed from the device identifier (4.6), not the identifier itself. Google stores it with the purchase, may use it, according to Google, to detect irregular activity, and returns it with the purchase data. The hash value contains no name or contact details but remains a pseudonym: anyone who knows the identifier can match it to the purchase. Payment data (e.g., card or account details) never passes through my backend and is processed directly by Google. Google Play's own privacy policy additionally applies.
Legal basis: Art. 6(1)(b) GDPR for purchasing, restoring and verifying your subscription, including the steps before a purchase that you initiate yourself. Where no subscription exists, I base the Premium status query via my backend and the further starts of the SDK after a purchase or restore you started on Art. 6(1)(f) GDPR (verifying Premium, completing purchases you started, preventing abuse), and the evaluation of the purchase flow in any case (improving the purchase flow). The SDK only stores and reads information on your device once you want to buy or restore purchases; this is strictly necessary for the feature you requested (Section 25(2) No. 2 TDDDG).
Google Play Billing Library: To connect to Google Play, the RevenueCat SDK includes the Google Play Billing Library from Google. Whenever the SDK starts (see above), including the app starts mentioned there without a purchase, this library writes technical log data to a queue on your device and on its own sends it to Google in batches in the background: information on the use of the library (such as whether calls succeeded or failed) and on connection issues, including error messages (e.g. that the billing service is unavailable on the device), the library version, the app's package name and version, device manufacturer, brand and model as well as other technical device and hardware names, Android version and build (including the build fingerprint, which names the device type and exact Android build), country, language, mobile network (country and carrier code), network type, time zone, and the time of the events and of the upload, each with the device's uptime since its last restart. When the data is uploaded, Google also receives your IP address for technical reasons. According to Google, it uses this data to improve the performance of the library and to provide better support for errors. Google also processes it for its own purposes and is not my processor in doing so. The recipient is Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland. I am responsible for the app collecting this data and transmitting it to Google (for details and your rights, see Section 9). Google alone is responsible for everything it does with the data afterwards and processes it under its privacy policy; in doing so, data may be transferred to Google LLC in the USA, which is certified under the EU-US Data Privacy Framework. The library offers no way to switch off this transfer. CookGen processes purchases exclusively via Google Play's billing system, and such a purchase is not possible without the library. The legal basis for the app collecting and transmitting this data is Art. 6(1)(f) GDPR: my legitimate interest in offering Premium through Google Play's billing system, which Google requires and which only works with this library. I do not ask for consent for this because you could not refuse it without giving up the purchase; you can, however, object (Art. 21 GDPR, see Section 9). The library only accesses your device once you want to buy or restore purchases (Section 25(2) No. 2 TDDDG); for the queue on your device, see Section 7.
Notice before the first start: Before the app starts the RevenueCat SDK, and with it the Google Play Billing Library, for the first time in this installation, it informs you in the purchase flow about the data processing described here. With “Continue”, it starts the SDK and continues the purchase or restore; with “Cancel”, nothing starts. As long as you don't want to buy or restore purchases, the app starts neither the SDK nor the library; all free features remain available. The app stores on your device that you chose “Continue”, when you last wanted to buy or restore purchases, and whether a Premium subscription has ever been confirmed here; this determines whether it starts the SDK at app start (see above).
Older app versions (up to 1.1.10) start the RevenueCat SDK, including the Google Play Billing Library, at every app start, even if you don't intend to buy anything. Please update the app.
Ratings (1–5 stars) are sent to my backend and stored there individually with a timestamp, but without device identifier or IP address, and are only used to calculate averages (e.g. “Most Popular Recipes”). I do not attribute ratings to any user or device.
Legal basis: Art. 6(1)(f) GDPR (legitimate interest in a user-based quality assessment of recipes).
In case of technical errors within the app, limited diagnostic data (error message, technical stack trace, app version, operating system, device model, the device identifier from 4.6) is automatically transmitted to my own backend in order to detect and fix bugs. Crash reports contain no recipe content or ingredient lists; in individual cases, technical error messages may contain fragments of an input or a server response. I use them solely to fix bugs. The data stays exclusively on my own server; it is not shared with any third party and is deleted automatically after at most 90 days.
Legal basis: Art. 6(1)(f) GDPR (legitimate interest in app stability and bug fixing).
The optional nutrition diary stores your entries (date, meal, food/recipe, amount, calories, and macronutrients) as well as — if you enter them — your personal data for calorie-need calculation (age, height, weight, biological sex), your weight history, and your daily goals (calorie and macro targets) exclusively on your local device. This data is generally not transmitted to my backend or to any third party. Exceptions, each only when you actively use the feature: search terms, barcodes and custom foods (4.11, 4.12), the confirmed dish name in photo recognition (4.13), and your remaining calories and weight goal for the recipe for your remaining calories (see 4.15). You can remove the diary, weight history, and personal data individually at any time via dedicated delete functions in the app (“Clear diary” in the diary, “Clear history” on the Progress screen, “Delete personal data” in your profile).
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment, providing the diary feature).
When you search for a food in the diary (by typing or by scanning a barcode), the search term or scanned barcode is forwarded by my backend to the following external databases to find names and nutritional values:
Each request is made from my own backend, not directly from your device — both providers only see my backend's server IP address, not your own IP address. The search term itself is normally a generic food name with no personal reference (comparable to the ingredient input described in 4.2). My backend does not store search terms or barcodes; only in the event of serious technical faults can they appear as part of the requested address in the web server's error log (Section 3).
Neither with Open Food Facts nor with USDA is there a classic data processing agreement in place: Open Food Facts does not offer a separate DPA for its free public API, and USDA, as a US federal agency, is not a GDPR processor in the legal sense. Since no directly personal data is transmitted (see above) and the transmission is made through my own backend, I rely on Art. 6(1)(f) GDPR (legitimate interest in a functioning food database integration) as the legal basis for this transfer.
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment) and Art. 6(1)(f) GDPR (legitimate interest, see above).
Barcode scan: The app recognizes the barcode on your device using Google's ML Kit library; no image is transmitted, and only the barcode number goes to my backend. For this, ML Kit creates a random identifier on your device, writes technical usage and diagnostic data to a queue on your device and on its own sends it to Google in batches in the background: the app's package name and version, the ML Kit version, device manufacturer and model as well as other technical device and hardware names, Android version and build (including the build fingerprint, which names the device type and exact Android build), country, language, mobile network (country and carrier code), network type, time zone, performance metrics, recognition settings, error codes and this identifier, and the time of the events and of the upload, each with the device's uptime since its last restart. When the data is uploaded, Google also receives your IP address for technical reasons. According to Google, it uses this data for ML Kit diagnostics and usage statistics, to maintain and improve ML Kit and to detect abuse. The recipient is Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland. I am responsible for the app collecting this data and transmitting it to Google (for details and your rights, see Section 9). Google alone is responsible for everything it does with the data afterwards and processes it under its privacy policy; in doing so, data may be transferred to Google LLC in the USA, which is certified under the EU-US Data Privacy Framework. This transfer cannot be switched off in the app. Legal basis: your consent, which the app asks for before you first use the scanner (Art. 6(1)(a) GDPR, Section 25(1) TDDDG); for the identifier and the queue on your device, see Section 7. Without your consent, you can still log foods via the search. You can withdraw your consent at any time with effect for the future in the app under Settings → Consents. Data stored on your device until the withdrawal may still be sent to Google afterwards, as long as it is not older than seven days (see Section 8).
If your search doesn't return a matching result, there are two options:
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment) and — for the custom food option — Art. 6(1)(f) GDPR (legitimate interest in a growing food database that benefits all users).
Premium users can have a food or dish recognized for the diary from a photo, taken with the camera or chosen from the gallery. The photo is sent to my backend and from there to Gemini for recognition (see Section 5); my backend does not store it (for retention at Google see Section 8). You confirm or correct the recognized name. The app then sends the confirmed name together with your diet, the app language and, if you have consented (4.1), your allergies to my backend and to Gemini to estimate calories and macronutrients per portion. Your other diary entries are not transmitted. On request (“Also save as recipe in favorites”), the app additionally has a complete recipe created from it as in 4.4 and saves it to your favorites. The application log only records technical information about it.
Legal basis: Art. 6(1)(b) GDPR; for camera and gallery permission see 4.4.
You can export the following locally stored app data (diary, personal data and weight history from 4.10, favorites, spice blend favorites, shopping list, meal plan, allergies, diet, display name, daily goals) as a file via Settings, or restore a previously exported file. Creating and restoring a backup each open your operating system's native file dialog — the file is NOT automatically transmitted to my backend or to any third party. Where you save the file (e.g. locally or in a cloud-synced folder of your choosing) is entirely up to you; this is outside my control and is not processing carried out by me. The file is not encrypted and also contains health information; store it with appropriate care.
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment).
As a Premium user, you can have the nutrition diary suggest a recipe that fits the calories still open for today. Only when you actively use this feature is the following data transmitted for that single request to my backend (see Section 3) and from there to the AI model (Gemini, see Section 5): the requested calorie amount (pre-filled with your remaining calories for today), the selected macro focus, your weight goal from the calorie calculator (if none is set: “Maintain weight”), your diet, the app language and, if you have consented (4.1), your allergies; with “Another suggestion”, also the titles of the recipes suggested before. The device identifier is used for the daily limit (see 4.6) and the Premium check (see 4.7). Before the first use, the app informs you about this; nothing is sent until you choose “I agree”.
Your age, height, weight, biological sex, and diary entries do not leave your device in the process. The transmitted values are neither stored nor cached on my backend; for Google's retention of AI requests for up to 55 days, see Section 8 (“AI requests (Gemini)”). For each request, the application log records only technical information without these values: whether the recipe was within the target range, the portion was adjusted, or no recipe was created; the adjustment factor; the deviation in percent; whether a correction request to the AI was needed; the technical type of flagged suggestions (e.g. “no calorie value”; never with reference to allergies or diet); the version of the request template; the token counts of the AI requests; and, where applicable, technical error messages.
Legal basis: Art. 6(1)(b) GDPR (contract fulfillment, providing the Premium feature) and, insofar as the data allows conclusions about your health, Art. 9(2)(a) GDPR (explicit consent by choosing “I agree” in the notice before first use). You can withdraw your consent at any time with effect for the future by no longer using the feature or by withdrawing it in the app under Settings → Consents; the app will then ask again before the next use. None of these values will be transmitted after that.
If you tap “Rate the app” in the settings, the app asks Google Play to show its rating dialog (Google decides whether it appears) or opens the store listing if that is not available. The rating is handled entirely by Google Play, and Google alone is responsible for it (see Google's privacy policy). The app does not learn whether or how you rate it. I can see public reviews in the Play Console with the name shown there, stars, text and date, as well as the technical details provided by Google (device model, Android version, app version, language), and can reply to them publicly there.
Legal basis for reading and replying to reviews: Art. 6(1)(f) GDPR (legitimate interest in feedback on the app and in responding to it).
For the AI features (recipe suggestions, photo recognition, nutrition estimates), my backend transmits the following data to an AI model, depending on the feature: ingredients, diet, language, selected Premium filters and the dish request (4.2), your allergies if you have consented (4.1), confirmed dish names (4.4, 4.13) and, for the feature described in 4.15, also the values listed there. Neither the device identifier nor your IP address is sent to the AI provider; it only sees my server's IP address. Other personal data only reaches the AI if you enter it yourself in a free-text field.
For the optional photo recipe recognition (see 4.4), the selected or captured photo is additionally transmitted to the same AI model for image recognition; it is processed solely to generate the response, is not permanently stored or used for training purposes (see below), and is discarded by my backend immediately after processing.
The same applies to the optional photo recognition feature in the nutrition diary (see 4.13): the photo is processed solely for recognition purposes and discarded by my backend immediately afterward.
The AI provider is Google, using the Gemini model via the paid Gemini API. Contracting party: Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Ireland. Google processes the requests as my processor under the “Google Data Processing Addendum for Products Where Google is a Data Processor” (business.safety.google/processorterms). Google may process or transiently cache requests outside the EU as well, in particular through Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. The transfer to the USA relies primarily on the EU-US Data Privacy Framework (adequacy decision, Art. 45 GDPR; Google LLC is certified, checked 25 September 2026) and additionally on the EU Standard Contractual Clauses included in that addendum (Art. 46(2)(c) GDPR).
Because CookGen uses the paid Gemini API tier, according to Google's terms neither the transmitted ingredients, settings and values nor the generated responses are used to train or improve Google's models.
Legal basis: Art. 6(1)(b) GDPR.
The app contains fixed affiliate links to Amazon and, via the affiliate network AWIN AG, Otto-Ostrowski-Straße 1A, 10249 Berlin, Germany, to Picnic. The links open outside the app in your browser or the provider's app; the app does not transmit any data about you. From the click onward, Amazon, Awin and Picnic process data (e.g. IP address, cookies to attribute the commission) under their own responsibility. I only receive a commission if a purchase is made.
Legal basis: Art. 6(1)(f) GDPR (legitimate interest in refinancing the app).
The app sets no cookies, uses no advertising or tracking tools and no analytics SDK of its own, and shows no personalized advertising. Three embedded libraries do, however, send technical data to their providers on their own: RevenueCat's subscription SDK (Premium check and events of the Premium overview) and the Google Play Billing Library from Google that it brings in (log data), both only once you want to buy Premium or restore purchases, and after that in the cases named in 4.7 also at app start, and Google's ML Kit during barcode scanning, only after your consent (see 4.11). On your device, the app stores your settings and content (4.1, 4.10), the device identifier (4.6), the most recently confirmed Premium status, whether you confirmed the notice before the subscription SDK first starts, when you last wanted to buy or restore purchases and whether Premium has ever been confirmed here (4.7) as well as a cache for recipe images. This storage by the app itself is strictly necessary for the features you use (Section 25(2) No. 2 TDDDG). Only once you want to buy or restore purchases are the RevenueCat SDK's storage (such as its cache for the Premium status) and the Google Play Billing Library's queue for its log data created; they are part of the feature you requested (Section 25(2) No. 2 TDDDG, see 4.7). Only after your consent are ML Kit's identifier and its queue for usage and diagnostic data created; your consent applies to this (Section 25(1) TDDDG, see 4.11). None of these identifiers is used for advertising or tracking across other apps.
I do not store data beyond what is listed here unless a legal retention obligation applies.
Users have the following rights:
Responsibilities for the Google libraries: I am responsible for the app collecting the Google Play Billing Library log data (4.7) and the ML Kit usage and diagnostic data (4.11) and for transmitting them to Google: I decide whether and when the app uses the libraries (the Billing Library only once you want to buy or restore purchases, and afterwards only in the cases listed in 4.7; the ML Kit scanner only after your consent), and I inform you in this policy and in the app's dialogs. Google Ireland Limited alone is responsible for the processing after the data reaches Google; Google determines which data the libraries collect and what it does with it. This division corresponds to the terms I have agreed with Google (the Google Play Developer Distribution Agreement and the Google APIs Terms of Service, each with the Google Controller-Controller Data Protection Terms): under them, each party is responsible for its own processing, and I inform you about the data collection in my app. You can contact me with any request concerning this data; for the data held by Google, you can also exercise your rights directly with Google (policies.google.com/privacy). Only Google can provide information about the data held by Google; I have no access to it.
Right to object (Art. 21 GDPR): Where I process data on the basis of legitimate interests (Art. 6(1)(f) GDPR), you may object at any time on grounds relating to your particular situation. An email to signalbytestudio@gmx.de is sufficient.
Most settings and data (language, diet, allergies, favorites, ratings, diary, personal data, weight history) are stored on your device and are therefore always available and portable; what is sent to my backend is described in Section 4. The backup feature (see 4.14) additionally lets you export them as a file at any time. Dedicated functions in the app let you delete specific data on demand (“Clear diary”, “Clear history”, “Delete personal data”).
As there are no user accounts, I can only match data on my server and at RevenueCat to you if you give me a reference, e.g. for a custom food, its name. Logs, counters and crash reports expire automatically after the periods listed in Section 8.
Requests can be submitted by email.
Last updated: September 2026. I update this policy when features or service providers change. The current version at cookgenapp.de/datenschutz is authoritative; the version shown in an older app version may be out of date.