Version 1.1 — effective 17 September 2026. Changes from 1.0: the operator is now 42 TAPS INC, a Delaware corporation (§1, §7, §12); the website moved to grif.fit; product analytics (PostHog, EU) is named in §3 and §6; checkout on the website is no longer offered and its payment processors are removed from §3 and §6; how to exercise your rights and where to complain is set out in §8; what PostHog receives, including your IP address in transit, is stated precisely, and that our server can link the analytics key to your account (§2, §3, §6, §8); subscription analytics in Apphud is named with its legal basis (§3, §6); purchase records rest on legitimate interest and are kept for as long as applicable tax and accounting laws require, instead of a fixed five years (§3, §8); the remaining references to website receipts, orders and charge references are removed; the website grif.fit no longer sets cookies or runs analytics scripts (§3, §8).
This policy explains what the Grif mobile app (iOS and Android), its backend, and the website grif.fit do with information about you. It is written to match what the software actually does.
Grif is a fitness and nutrition programme: it works out calorie and macronutrient targets from your body figures by formula, builds a training and meal programme around them, keeps a daily diary, and — if you choose — estimates the calories of a meal from a photograph. Grif is not a medical device and does not diagnose, treat, cure or prevent any condition.
The data controller (the "operator", "we") is:
42 TAPS INC, a Delaware corporation, 200 Continental Dr Ste 401, Newark, Delaware 19713-4337, United States.
Contact for anything in this policy, including requests to exercise your rights (§8): support@grif.fit
The table lists every category the current build collects. "Basis" refers to GDPR Article 6 (and Article 9 for health data); the same categories apply outside the EU/UK under the laws named in section 12.
| Category | What exactly | Where it comes from | Why | Basis | Kept until |
|---|---|---|---|---|---|
| Account | Email address (also your username), first and last name as typed at registration, password (stored hashed by our sign-in service Keycloak), an internal account id | You, at registration | Sign you in, address you by name, contact you about your account | Contract (6(1)(b)) | Account deletion. The internal id is retained as a tombstone so that a stale sign-in token is refused rather than creating a new account (§8) |
| Questionnaire and body figures | Sex, date of birth / age, height, weight, activity level, goal, training experience, where you train, training days per week; optional neck, waist and hip circumferences; food exclusions (allergies and foods you do not eat); the frozen calculation (BMR, TDEE, targets, body-fat estimate) | You, in onboarding and Profile → Recalculate | Compute your targets by formula (US Navy body fat, Katch-McArdle or Mifflin-St Jeor, activity factor, goal correction), build the programme and menu | Explicit consent for health data (9(2)(a)) — the "Health data processing" consent | Until you erase your data, withdraw the health consent, or delete the account |
| Diary | Daily: weight, steps, workout (type, minutes, sets, RPE, estimated kcal), calories and macros eaten and where the figure came from; weekly: circumferences, body-fat %, average weight; exercise log (exercise, weight lifted); saved meals (name, grams, kcal, protein, fat, carbs, source: scan / manual / day total); programme enrolment (which programme, which week) | You, by hand, from a meal scan, or imported from Apple Health / Health Connect after you confirm it | Run the tracker, adjust targets week by week, show progress | Explicit consent (9(2)(a)) — the same health consent | Until erase / withdrawal / deletion. Programme enrolment (which week you are on) survives an erasure because it is the state of a paid service, not a health record |
| Health platform data (Apple HealthKit, Health Connect) | Read: steps, weight, body-fat %, nutrition (kcal, protein, fat, carbs), workouts, active energy. Written: weight and the kcal/protein/fat/carbs of a meal you confirmed in the diary; body-fat % computed from your own circumferences is being added | Your phone's health store, only after you grant the permission from Profile → Health | Pre-fill the diary with what you would otherwise type; keep your health store in step with the diary | Explicit consent, expressed by granting the OS permission, and the health consent above for what you then save | What you read is shown to you first and reaches our server only when you save the diary entry. What we write stays in your health store under your control |
| Meal photographs and the free text you type with them | One photo per scan (taken or picked), normalised on the phone (resized, EXIF and location removed); the optional hint typed before the scan and the correction typed over the result; the meal slot and your language | You, in the food tab | Recognise the food on the plate and estimate portions; the calories are then computed by our server from a food database, never by the model | Explicit consent for the transfer to named providers (9(2)(a)) — the "Food diary photographs" consent, given at a specific text version | We hold the photo only in memory for the duration of the request; the pending attempt's body on your phone is erased on the answer, after 24 h, or when you withdraw the consent. A working copy of the result (rows, grams — no image) lives in our cache for 24 h. The provider's retention is in §6 |
| Nutrition-label photographs (upcoming) | A photo of a packaged product's nutrition label, sent through the same pipeline as a meal photo | You | Read the label's serving size and per-100 g figures into your diary | Same consent as meal photographs | Same as meal photographs |
| Barcode lookups (upcoming) | The EAN/UPC number read by your phone's camera | Your phone reads it; only the digits are sent | Find the product in Open Food Facts | Contract (6(1)(b)) — no photo, no consent gate | The product record is cached for 30 days (7 days for "not found"); nothing about you is attached to it |
| Subscription and purchases | Store product, original transaction id, purchase and expiry dates, storefront country, state (active, grace, expired, refunded…), environment | Apple, Google (via Apphud) | Grant and check access to the paid programme; keep purchase records; subscription analytics (conversions, renewals, refunds) in Apphud | Contract (6(1)(b)) for access; legitimate interest (6(1)(f)) in complying with the record-keeping and tax requirements of the United States for the purchase records; legitimate interest (6(1)(f)) in understanding how subscriptions convert, renew and are refunded, for subscription analytics | Purchase records are kept after erasure and deletion for as long as tax and accounting laws that apply to us require |
| Apphud identifiers | Before sign-in: a random install id generated by the app. After sign-in: a keyed hash of your internal account id (not your email, not your sign-in subject) | Generated by the app / our server | Let Apphud attribute the store transaction to your subscription | Contract (6(1)(b)) | Until account deletion (the mapping); Apphud's own retention is governed by its policy (https://apphud.com/privacy; data processed in the United States) |
| Devices and push | Platform, push token (APNs or FCM), time zone, app version, last seen | Your phone, when you turn on reminders | Send reminders about today's session and the weekly check-in; with a separate opt-in, news and offers | Consent (the "Push notifications" consent, recorded when you grant the system permission); marketing pushes only on the separate "News and offers" opt-in, off by default | Removed on sign-out (best effort), on erasure, and on deletion. The push token is never included in your export |
| Product usage events | Event type, onboarding step number and screen id, a random session id, permission results (granted/denied), API error codes, paywall rail/surface/storefront, purchased plan, which home-screen widget opened the app; added by the analytics library: app version and build, device model, operating system and version, screen size, language, time zone, network type and its own random device and session ids. Keyed by a random key issued at installation; our server can link this analytics key to your account. No measurement, no free text: a deny-list on the phone drops any event that carries those field names | The app, sent to PostHog (see Product analytics below) | Understand where people drop out of onboarding, whether the paywall works, whether a feature is used | Legitimate interest (6(1)(f)) in improving a product we operate, balanced by the deny-list and by storing no IP address or location with the events | Kept in our PostHog project without a fixed end date; the events carry no measurement and no name or email. Deleting your account does not delete them from PostHog: ask support@grif.fit to delete these events |
| Preferences | Language, unit system (metric/imperial), time zone, notification toggles, referral code redemptions | You | Show the app in your language and units; schedule reminders at your local time | Contract (6(1)(b)) | Account deletion |
| Website visits (grif.fit) | The website sets no cookies and loads no analytics, advertising or tracking scripts. Like any web server, ours receives your IP address, the page requested, the referrer and your browser's user agent in order to answer the request | Your browser | Serve the page | Legitimate interest (6(1)(f)) | Web server log lines are kept like the server logs below. Visit records from the earlier website are detached from your person when you erase your data |
| Support | Whatever you write to us and the address you write from | You | Answer you | Legitimate interest (6(1)(f)) | 12 months after the request is closed |
| Server logs and error reports | Account id, event type, request path, timing, app version and platform. Error reports, if error reporting is enabled, carry the exception and stack, an allow-listed set of headers (User-Agent, Content-Type, Content-Length, Accept, Referer, X-Request-Id), and nothing else: no user object, no request body, no cookies, no query string, no Accept-Language | Our servers | Keep the service running and find faults | Legitimate interest (6(1)(f)) | Logs: 30 days. Error reporting is not currently enabled in production; if enabled, reports go to Sentry (EU-hosted) with personal fields scrubbed |
What we deliberately do not collect: precise or coarse location, contacts, your photo library (one picked image per scan, the library is never browsed), payment card details, advertising identifiers, device fingerprints for tracking, browsing or search history. The app links no advertising or attribution SDK, and a build check fails if one appears. The analytics library ships with a crash reporter; our code switches it off, so no crash reports are collected.
Free text about your food is treated like a measurement. The hint you type before a scan and the correction you type after it reach only the vision provider and our server; they are on the same deny-list that keeps weights out of analytics and error reports.
Product analytics. The product usage events are sent from the app directly to PostHog, in its EU cloud (PostHog Cloud EU, servers in Frankfurt, Germany), which processes them for us; they are not copied to our own server. The app sends a fixed set of event types and nothing else: opening the app (including from a home-screen widget); starting and finishing sign-in; seeing the paywall; starting, completing or restoring a purchase, or a purchase left pending by the store; viewing, completing or going back from an onboarding step; the answer to the Apple Health / Health Connect and notification permission dialogs; building your programme (started, completed, or failed with an error code) and seeing its summary. Before sending, the app checks every event and drops it whole if it carries a body figure, calories or macros, steps, email, phone number, date of birth, age, free text about food, or any field not allowed for that event type. IP address and location: PostHog receives your IP address in transit, like any server; our app replaces it with 0.0.0.0 in stored events, and no location is stored with events or profiles. PostHog's feature-flag service may use the request IP to evaluate flags for that request; we do not use feature flags. Automatic collection by the analytics library — screen views, taps, session recordings, surveys, push tokens, crash reports, device logs — is switched off in our code. The person in the analytics is the random key issued when the app is installed, not your name or email; our server can link this analytics key to your account. You can object to this processing by writing to us (§8).
Grif records three consents. Each is a dated, versioned entry; a new wording is a new entry, and a withdrawal stamps the old one. The history is your record and is included in your data export.
| Consent | What it covers | Where you give it | Where you withdraw it | What withdrawal does |
|---|---|---|---|---|
Health data processing (health) | Storing and processing the questionnaire, body figures and diary | Onboarding, before your figures are saved; Profile → Consents | Profile → Consents → "Withdraw consent and erase data" | Erases the questionnaire, measurements, diary, reports, targets and devices (the same as "Erase my data", §8). There is no basis to keep health data without it, so we do not keep it for a grace period |
Food diary photographs (diary_photo) | Sending a meal or label photo and your typed hint to the vision providers named on the consent card, for the retention stated there | The food tab, the first time you scan; Profile → Consents | Profile → Consents → toggle off | Stops every further scan (the server refuses with consent_required) and deletes the cached scan results. Meals you already saved stay in the diary under the health consent. If the providers or the retention change, the consent text gets a new version and the app asks again before the next scan |
Push notifications (push) | Reminders about the day's session and the weekly check-in | The system permission dialog, opened from a screen that explains why | Profile → Notifications → Reminders toggle, or the OS settings | Pushes stop. The device record stays so that turning reminders back on works without re-registering |
Under-18s cannot pass onboarding (§11), so no consent is ever collected from a minor by design.
We share data with the following recipients and with nobody else. None of them is permitted to use your data for its own advertising.
| Recipient | What it receives | Why | Role and location |
|---|---|---|---|
| Google (Gemini API) — primary vision provider | The normalised meal or label photo, your typed hint, the meal slot, your language, and our food catalogue ids | Recognise the food on the plate | Processor. United States. May keep the photo for up to 55 days for abuse monitoring; under the paid API terms it is not used to train models. Google is certified under the EU-US Data Privacy Framework; transfers rely on that certification and on Google's data-processing terms for the Gemini API |
| OpenAI — fallback vision provider | The same as Google, only when the primary provider fails or returns an unusable answer | Same | Processor. United States. May keep the photo for up to 30 days for abuse monitoring. OpenAI is certified under the EU-US Data Privacy Framework; transfers rely on that certification and on OpenAI's data-processing addendum |
| Apple (App Store, StoreKit, APNs) | Purchases: handled entirely by Apple on your Apple ID. Push: your APNs token and the reminder text (title, body, a deep link into the app) | Billing; delivering reminders | Independent controller for billing; processor for push delivery. See Apple's privacy policy |
| Google (Google Play, Play Billing, Firebase Cloud Messaging) | Purchases: handled entirely by Google on your Google account. Push (when enabled in the Android build): your FCM token and the reminder text | Billing; delivering reminders | Independent controller for billing; processor for push delivery. See Google's privacy policy |
| PostHog (product analytics) | The product usage events described in §3: event type and its allowed properties, the random install key, app version, device model, operating system, screen size, language, time zone, network type. No body figure, no free text, no name or email. PostHog receives your IP address in transit, like any server; our app replaces it with 0.0.0.0 in stored events, and no location is stored with events or profiles. PostHog's feature-flag service may use the request IP to evaluate flags for that request; we do not use feature flags. | Understand how the app is used and where onboarding and the paywall lose people | Processor. PostHog Cloud EU, Frankfurt, Germany |
| Apphud (subscription infrastructure) | The store transaction and receipt, your install id or hashed account id, device and app version as collected by its SDK, storefront | Verify store purchases and tell our server when a subscription starts, renews, lapses or is refunded; subscription analytics (conversions, renewals, refunds) | Processor. United States; policy: https://apphud.com/privacy |
| Open Food Facts (upcoming barcode lookup) | The barcode digits only, with a User-Agent naming the app and our support address. No account identifier, no photo | Look up a packaged product | Independent database operated by a French non-profit; the request is made by our server, not your phone. Data returned is under the ODbL (see Third-party notices) |
| DigitalOcean (hosting) | Everything stored on our servers, encrypted in transit; the API, database (PostgreSQL), cache (Redis), sign-in service (Keycloak) and the website run on our own server in Frankfurt, Germany | Hosting | Processor (infrastructure). The database, cache, sign-in service and the nightly backups are all in the same Frankfurt region |
| Cloudflare | DNS for grif.fit and our former domain; mail sent to support@grif.fit passes through Cloudflare Email Routing on its way to our mailbox; no web traffic is proxied through Cloudflare. A planned configuration file (app manifest, no personal data) may be served from a Cloudflare R2 bucket | DNS; forwarding support mail | Processor |
| Sentry (error reporting) | Not currently enabled in production. If enabled: server exceptions and stack traces, scrubbed as described in §3 — no user object, no request body, no cookies | Find faults | Processor, EU-hosted |
| Our staff | Support staff can look up a customer card (read-only) in the owner's cabinet; every search and view is written to an audit log, and body figures are behind a second, separately logged click | Support, re-sending access | Under the operator's authority |
| Authorities | Only when the law obliges us | Legal obligation | — |
We do not share with data brokers, advertising networks, or "partners". We have no affiliates.
The operator, 42 TAPS INC, is a company established in the United States. For people in the EU/EEA and the UK, the GDPR and the UK GDPR apply to our processing of their data because we offer the Service to them (GDPR Art. 3(2)), wherever that data is stored.
Our servers are in Germany (EU), and product analytics stays in the EU (PostHog Cloud EU, Frankfurt). Meal and label photographs, and the text typed with them, are transferred to Google and OpenAI in the United States when you use the photo feature; Apphud, Apple and Google process purchase and push data in the countries in which they operate.
For people in the EU/EEA, the UK and Switzerland, transfers to processors in the United States rely on the EU-US Data Privacy Framework (with its UK extension and the Swiss-US DPF) where the recipient is certified — Google and OpenAI are — and otherwise, where applicable, on the European Commission's Standard Contractual Clauses concluded with the processor (in the UK, the IDTA or the UK Addendum). You can ask us for a copy of the relevant safeguards at support@grif.fit.
Most rights are one tap away and need no email:
| What you want | Where |
|---|---|
| See and download everything we hold about you | Profile → Data and privacy → Export my data. One JSON file with your identity, questionnaire and frozen calculation, targets, daily and weekly reports, exercise log, every saved meal, consents with their full history, devices (platform and dates, never the push token), notification settings, subscriptions and store purchases, plus the processing notice in your language. The sign-in subject is deliberately not included |
| Correct something | Profile → Recalculate (questionnaire), the diary itself (entries), the account page of the sign-in service (email, name) |
| Erase your data but keep the account | Profile → Data and privacy → Erase my data. Deletes the questionnaire, measurements, diary, reports, targets, exclusions and push tokens; cancels scheduled messages; detaches website visits; withdraws all consents. Your purchases and access remain, and you can start again by giving consent anew |
| Delete the account | Profile → Data and privacy → Delete account, or by email from the address on the account (see grif.fit/delete-account). Does everything an erasure does, then removes your email and name, deletes the account at the sign-in service, and refuses any further sign-in. Product usage events in PostHog are not deleted by this; ask support@grif.fit to delete these events. A store subscription is not cancelled by this — cancel it in the App Store or Google Play first if you no longer want to be charged |
| Withdraw a consent | Profile → Consents (see §4). Withdrawal does not affect processing that happened before it |
| Object to processing based on legitimate interest, or restrict it | Email support@grif.fit. Note that the product-usage events carry no measurement |
| Portability | The export above is machine-readable JSON |
| Complain | You may lodge a complaint with the data protection supervisory authority of the country where you live or work, or where you believe the infringement took place (in the EU/EEA, the authority of that member state; in the UK, the ICO; in Switzerland, the FDPIC). Complaining to us first is not required, though we would rather hear from you |
Any right in this section, including those the app does not cover, can be exercised by writing to support@grif.fit. We answer within one month (GDPR, UK GDPR) or the shorter period your local law sets. We may ask you to confirm your identity by writing from the account's email address.
What survives erasure and deletion, and why: purchase records (tax and accounting law, see §3), product usage events in PostHog (deleted on request, see §3), granted entitlements (the proof of what you paid for), programme enrolment state, the append-only event and audit journals (they carry ids and event types, not measurements), the consent history with its withdrawal stamps (proof that consent was given and withdrawn), and the tombstoned account id. Backups: a nightly database dump is kept for 30 days, so an erased row can persist in a backup for up to 30 days; backups are not used to restore individual accounts.
No system is perfectly secure. If we learn of a breach affecting your data we will notify you and the competent authority as the law requires.
The app keeps a local copy of your diary and programme so it works offline, your sign-in tokens, your consent and preference choices, a pending meal-scan attempt (removed within 24 h), and — on iOS — a small snapshot for the home-screen widgets in the app group container (the widgets have no network access). Deleting the account clears this phone as well; uninstalling the app removes it too. Data in Apple Health or Health Connect is yours and is managed there, not by us; revoking our permission stops us reading it but does not delete what your health store already holds.
Grif is for adults. Onboarding asks your date of birth and stops for anyone under 18; the server refuses to store a profile outside 18–75 years. We do not knowingly collect data from anyone under 18; if you believe we have, write to us and we will delete it.
EU/EEA, UK, Switzerland. The legal bases are given in §3; health data is processed on explicit consent (GDPR Art. 9(2)(a)). Your rights are in §8.
United States — consumer health data. For residents of Washington (My Health My Data Act), Nevada (SB 370) and Connecticut (CTDPA as amended), the diary, body figures and meal photographs are "consumer health data". Our separate Consumer Health Data Privacy Policy sets out the categories collected, the sources, the purposes, the categories shared, the specific third parties who receive them, and how to exercise and appeal your rights. We obtain your separate, specific consent before sharing a meal photo with a vision provider (the "Food diary photographs" consent) and never sell consumer health data.
California. We do not sell or share personal information for cross-context behavioural advertising and do not use sensitive personal information for anything beyond providing the service you asked for. California residents have the rights listed in section 8.
Brazil, Canada, Australia and elsewhere. We apply the same practices everywhere; where local law grants you additional rights, write to us.
When we change what we collect, whom we share it with, or how long we keep it, we update this page and the version at the top, and — where the change concerns a consent — the consent text in the app gets a new version and the app asks you again before the affected feature is used. Material changes are announced in the app.
Terms · Privacy · Health data · Subscriptions · Third-party notices · Delete account · Home