What I collect
- Search queries. When you ask for somewhere to eat, I save the query, the resulting ten places, and the date — at a permanent URL on this site. Useful for sharing, useful for me to spot patterns. No personal data attached unless you explicitly add an email or phone for a follow-up notification.
- Submissions. Tips, complaints, newsletter signups, Tribunal rulings, restaurant rebuttals — these arrive with whatever you typed. The email or phone you supply stays on the row. I do not pass it on.
- Your IP, briefly.Stored on rate-limit rows (so a single hammering client can't take the site down) and on submission rows (so I can match abuse to a source). Purged on a rolling basis.
- One cookie. If you sign in to the admin dashboard, an HttpOnly session cookie is set. It contains a short HMAC of the admin secret — not the secret itself. No other cookies are set anywhere on this site.
What I don't collect
- One exception: analytics. Google Analytics on this website, Firebase Analytics in the iOS and Android apps — aggregate, anonymised product-usage stats only (which pages or screens get used, roughly how many visitors, session length). Google Signals — the setting that would link this to a signed-in Google identity across devices for ad personalisation — is off. No ad networks, no pixels beyond that, no fingerprinting libraries, no data sold or shared with advertisers.
- No cross-site tracking. No referrer storage.
- No location data beyond what you explicitly pass via the search box or the “near me” prompt — on the website or in the apps — and that coordinate is only used for the in-flight request, never stored, never linked to you.
Where it lives
All of it on a managed Postgres instance via Neon, in the EU region. The app runs on Vercel, also EU. No data leaves the EU for storage, though our LLM calls hit Anthropic's endpoints (US-located) — content sent is restaurant data + your query, nothing personally identifying.
Asking for it back
Submit the contact form with the address you supplied. I will delete every row that matches, confirm in reply, and not retain a back-channel copy. If you supplied a phone instead of an email, include enough context to identify the row (date and approximate search), and the same applies.
On the iOS app
- Same rules as the website. The Harry Hungry iOS app talks to this same site. It sets no cookies, uses Firebase Analytics for the same aggregate usage stats described in §02 (no ad personalisation, no Google Signals), uses no advertising identifier (no IDFA), and needs no account or sign-in.
- Location is opt-in.The app only asks for your location when you tap “near me.” The coordinate is sent with that one search so I can rank places near you, then it's gone — not stored, not tied to a profile. iOS lets you revoke the permission any time in Settings.
- Nothing published.Searches you run in the app aren't minted into a public URL the way a website search can be. Your query text is used to find and describe places for that request, nothing more.
On the Android app
- Same rules as the website and the iOS app. The Harry Hungry Android app talks to this same site. It uses Firebase Analytics for the same aggregate usage stats described in §02 (no ad personalisation, no Google Signals), uses no advertising ID, and needs no account or sign-in.
- Location is opt-in.The app only asks for your location when you tap “near me.” The coordinate is sent with that one search so I can rank places near you, then it's gone — not stored, not tied to a profile. Android lets you revoke the permission any time in Settings, and lets you grant an approximate location instead of a precise one.
- Nothing published.Same as the iOS app — searches you run aren't minted into a public URL. Your query text is used to find and describe places for that request, nothing more.
If any of this changes
It will say so here, in this section, with a date. I will not quietly switch on tracking and hope you don't notice.