Privacy

Plain language, no legalese wall. This page describes what the site does today, not what it might do one day. It gets rewritten whenever that changes.

Last updated 30 August 2026

The short version

Browsing this site collects nothing. No analytics, no cookies, no tracking. If you sign in to the tracker, your log is stored in a database that is configured so that no other account can read it — enforced by the database itself, not by application code. You can export everything or delete everything, permanently, at any time.

If you never sign in

Home, Method, Nutrition, About and this page are static files. They make no network request to anything but this domain.

Collected: nothing

No analytics, no tag manager, no tracking pixel, no ad network, no fingerprinting, no third-party script of any kind. The TDEE calculator and food reference run entirely in your browser — nobody, including me, ever learns what you searched for or what you weigh, because there is no endpoint to send it to.

Stored in your browser only

Your theme choice (udip-theme), your calculator inputs (udip.fit:tdee-inputs), your macro targets and any custom foods you add logged-out. All in localStorage, all on your device, none of it an identifier. Clearing your browser data removes it.

If you use the tracker

Signing in: Google only, requesting exactly three things: openid, email,profile. No Drive, no contacts, no calendar. Google sends you a receipt listing what was shared, so you do not have to take my word for it. There are no passwords, so there is no password database to leak.
What is stored: Only what you type: the date, weight, water, meals and their macros, exercises, sets, reps, weights, RPE, your notes, your macro targets over time, and any custom foods. Nothing else.
Your email address: Held by the authentication provider, and never copied into the application's own tables. It cannot leak through a share, an export bug, or a careless database query, because it is not there to leak. That is a structural guarantee, not a promise about being careful.
Where it lives: A PostgreSQL database hosted by Supabase, in their Mumbai region. Every table has row-level security enabled and forced, with separate policies for reading, creating, updating and deleting. One account physically cannot return another account's rows — the database refuses, regardless of what any app or script asks it for.
Who can see it: You. That is the default and it stays that way until you change it. There is no public profile, no directory, and nothing discoverable.

Off by default. Two modes, both read-only — a person you share with cannot write to your log, because no rule in the database permits it, not because a button is hidden.

Specific people: You name Google addresses. Access is matched against that person's own verified sign-in, so it cannot be faked by anyone claiming to be them. They see only the log, only within the date range you chose — never your targets, your custom foods, your profile, or who else you shared with.
Anyone with the link: The link contains 32 random bytes. Only a one-way hash of it is stored, so if the database were ever stolen, no working link could be rebuilt from it. It is shown to you exactly once. Shared pages are marked noindex and excluded inrobots.txt, so they do not end up in search results.
Turning it off: Revoking takes effect on the very next request, server-side. Rotating replaces the link and kills the old one instantly. Nothing depends on the other person's browser cooperating. A 30-day expiry is offered by default, because a link that outlives its purpose is the most common way data leaks in practice.

Leaving

Export

One click for a complete, schema-versioned JSON file, plus CSV and a printable PDF. All three are generated in your browser from data already on screen. There is no export endpoint and no server-side job — your log is never sent anywhere to be turned into a file.

Deletion

One click, confirmed by typing DELETE. Every log, meal, set, custom food, target and share is removed, enforced by the database rather than by code remembering every table. There is no 30-day recovery window. That is the promise, not an oversight.

The honest caveats

Any privacy page that stops before this section is skipping something.

The host sees requests

The site is served by GitHub Pages. Like any web host, GitHub's infrastructure receives your IP address and browser user-agent in order to send the page back. That is how HTTP works. I do not receive it, cannot query it, and have no dashboard showing who visited. It is governed byGitHub's privacy statement. The database provider likewise sees the requests your browser makes to it.

Deletion is immediate; backups are not

Deleting removes your data from the live database at once. The database provider also keeps their own operational backups on a schedule I do not control, so a copy may persist there for a short period before being cycled out. This is true of every hosted database, and it is the one honest asterisk on "deleted immediately". SeeSupabase's backup documentationfor their current retention.

Two security headers are missing

GitHub Pages cannot set HTTP response headers, so this site cannot sendStrict-Transport-Security or frame-ancestors. A Content Security Policy is applied via a <meta> tag instead, which covers most of the same ground but not those two. A real gap, stated rather than hidden, and fixed by moving to a host with header control.

Links out are still links out

Links to YouTube, Instagram and TikTok are ordinary links. Nothing loads from those services while you are here, and no request reaches them until you click — but once you do, you are on their site under their rules.

What will never happen

These do not move for money, growth, a partner, or a platform.

Your data is never shared, sold, rented or brokered — not aggregated, not "anonymised", not as a bonus in a partnership.
No tracking pixels, ad networks, profiling analytics, or fingerprinting.
Only the fields a feature actually needs get collected. No phone number, no contacts, no location, no device inventory.
No dark patterns — no fake scarcity, no countdown timers, no guilt-trip unsubscribe flows.
Your custom foods are private data. They can reveal diet, religion or a health condition, so they are never pooled and never used to "improve the database".

Questions

Email atomicdeveloper0329@gmail.com. The site's full source — including every database rule described above, and the tests that prove they work — is public atgithub.com/udip-rai/udip.fit. None of this has to be taken on trust. You can read it.