Privacy Policy

This summary is here so you do not have to read the whole document to know what happens to your data. It is not a substitute for the sections below, which control.

• We read your Google Health data only after you grant permission on Google's consent screen, and only the categories you leave ticked.
• We read each record live from Google when you or a connected MCP client requests it, and by default we keep no copy of it.
• You can turn on stored history on your dashboard. While it is on, we fetch the categories you already authorized once a day and keep them, so questions that span more than the last few months can be answered. It is off until you turn it on, and turning it off deletes everything we kept.
• We do not sell your data, we do not use it for advertising, and we do not hand it to anyone else to use for their own purposes.
• We transmit your health data to a Model Context Protocol (MCP) client only when you connect that client yourself. You choose the client, and the data goes where you point it.
• You can revoke our access at Google, revoke an API key, revoke an application's approval, or delete your account entirely at any time, without giving a reason.
• We do not use your health data to train machine learning models.
• If you subscribe to a paid plan, Waffo Pancake handles the card details — they never reach our servers — and your health data is no part of the payment.

GHealth Connector by StillWarm.app ("the Service", "we", "us") is operated by Bestony, an individual developer based in the People's Republic of China (Mainland China). For anything in this policy, write to bestony@linux.com.

This policy covers the GHealth Connector by StillWarm.app website at https://www.stillwarm.app, the accounts it issues, and the MCP endpoint it exposes to you.

It does not cover:

• Google. Your Google Account and the health data held inside Google Health remain governed by Google's Privacy Policy. We are a client of Google's APIs, not a part of Google.
• MCP clients you connect. If you point an AI assistant or another tool at your MCP endpoint, that tool — and any model provider behind it — handles your data under its own terms. See section 7.
• Devices and apps that write to Google Health. How your watch, phone or fitness app collects data in the first place is between you and that vendor.

a. Account information

When you create an account we store your name, email address, whether that address has been verified, and the timestamps of account creation and updates. If you sign up with a password, we store a salted hash of it and never the password itself. If you sign in with Google, we store the Google account identifier and the basic profile fields Google returns for the openid, email and profile scopes.

b. Google Health data

Signing in with Google grants us nothing beyond your identity. Health access is a separate consent, which you give from your dashboard and which Google lets you narrow permission by permission. The categories we can request are:

"Read" means we can retrieve records from Google Health. "Write" means we can add records on your behalf; a write permission does not let us read, and it only covers records this app itself wrote. Whatever you leave unticked on Google's consent screen, we never receive. Your dashboard shows exactly which permissions Google actually granted.

By default the Service retrieves health records directly from Google for each request. It processes a record in memory only long enough to return the response you requested or send it to an MCP client you connected, and does not write it to a database, a server-side cache or a backup.

Stored history changes that, and only for as long as you leave it on. Turning it on from your dashboard tells us to fetch the categories you already granted on a daily schedule and keep the records in our database, so that a question about last year can be answered without asking Google for a year of data in one request. It never widens what we may read: we store only what your Google permissions already allow us to retrieve, and a category you leave unticked is never fetched and never stored. See section 9 for how long we keep it and section 10 for how to delete it.

c. Google authorization credentials

To keep reading your data after you close the browser, we store the OAuth access token and refresh token Google issues, their expiry times, and the list of scopes Google says you granted. These tokens are encrypted at rest with a key held only on our server. They are credentials, not content: we use them to call Google's APIs as you, and for nothing else.

d. MCP application registrations and approvals

An OAuth application can register its name, application URI and redirect URIs with the Service. When you approve an application, we store which application you approved, the scopes you granted, and when you approved or updated them. Connected apps on your dashboard shows these records back to you.

e. Session and technical data

We set a session cookie so you stay signed in. It is strictly necessary for the Service to work — it is not an advertising or tracking cookie, and we do not use any. Our servers also record ordinary operational logs: IP address, user agent, request path, response status, timestamps, and diagnostic detail when something fails.

f. Billing information

If you subscribe to a paid plan, Waffo Pancake collects your payment details and takes the payment. Your card number is entered with them and stored by them; it does not pass through our servers and we have no way to see it. What we hold is your plan, your billing period and its renewal date, Waffo Pancake's customer and transaction references, and the invoices we are required to keep. If you only ever use the free plan, none of this exists.

Your health data is never part of a payment. Waffo Pancake receives what it needs to charge you — an account identifier, an email address and an amount — and nothing about what is in your account.

g. What we do not collect

We do not use third-party analytics, advertising SDKs, tracking pixels or fingerprinting. We do not buy data about you from data brokers, and we do not collect precise device location outside the workout GPS traces Google Health itself holds and you explicitly authorize.

We use each kind of data only for the purposes listed against it:

• Account information — to authenticate you, keep you signed in, tell your data apart from another user's, and reply when you contact us.
• Google Health data — to retrieve the records you authorized directly from Google, return them to you, write records you ask the app to write, and send them to an MCP client you connected.
• Authorization credentials — to call Google's APIs on your behalf and to refresh access when a token expires.
• MCP application and approval records — to identify the application asking for access, enforce only the scopes you granted, show your approvals, and let you revoke one application without revoking another.
• Session and technical data — to operate the Service securely: diagnosing faults, investigating abuse, enforcing rate limits, and meeting legal obligations.
• Billing information — to take the payment you authorized, renew or end a subscription when you say so, decide which plan's features you get, issue invoices and refunds, and meet tax and accounting obligations.

Health information is sensitive personal information under the personal information laws of the People's Republic of China (Mainland China) and under comparable laws elsewhere. We process it on the basis of your separate, specific and informed consent, given on Google's consent screen and recorded as the scopes Google returns to us. We process account and technical data on the basis of performing the agreement between us and of our legitimate interest in keeping the Service secure.

You can withdraw consent at any time, in whole or for individual categories, using the methods in section 10. Withdrawal stops future processing; it does not make processing that already happened unlawful.

Approving an MCP application is a separate, user-initiated consent. The approval page names the recipient, shows its registered redirect URI, and lists the requested scopes before any data can be disclosed.

In practice, that commitment means all of the following.

• We limit our use of data obtained through Google APIs to providing or improving the user-facing features that are prominent in the Service's interface, and which you have authorized.
• We do not transfer that data to others except: as necessary to provide or improve those features, with your explicit consent; for security purposes such as investigating abuse; or to comply with applicable law.
• We do not use, and do not allow others to use, that data for serving advertisements of any kind, including personalized, retargeted or interest-based advertising.
• We do not sell that data, and we do not transfer it to data brokers, information resellers, credit bureaus, or any party that would use it for their own purposes.
• We do not allow humans to read that data, unless: you gave explicit consent for specific data, for example so we can investigate a problem you reported; it is necessary for security purposes such as investigating abuse; it is required by applicable law; or the data has been aggregated and de-identified and is used for internal operations.
• We do not use health data to determine credit-worthiness, insurance eligibility, employment suitability, or for any similar decision about you.

The Service can expose your own data over the Model Context Protocol (MCP), an open standard that lets a tool you run — typically an AI assistant — read data from a server you point it at. The purpose is to let you use your health data with tools of your own choosing rather than only the ones we build.

• It is off until you turn it on. Data access requires either an API key you generate or an OAuth application you approve. An API key is an owner credential. An application receives only the scopes in its own approval. Without either credential, no health data is reachable over MCP.
• It is scoped to you. An API key and an OAuth access token resolve to only your account. An OAuth token is also limited to the scopes you approved. Neither reaches another user's data.
• You choose the destination. When you connect a client, your health data is transmitted to that client at your direction. If that client sends it onward to a model provider — a hosted AI service, for example — that provider receives your health data and handles it under its own privacy policy and terms.
• We never initiate that transfer. We do not send your data to any AI provider, or to any other third party, on our own initiative. Every such transfer is one you started by connecting a client.
• You can revoke it. Revoking the API key stops that key. Revoking an application under Connected apps deletes its approval and its stored access and refresh tokens. The MCP endpoint checks the approval on every OAuth request, so an access token that worked before revocation is rejected on its next request. Each control affects only that credential or application; it does not revoke the other access method. Revocation cannot recall data a client already received.

We do not sell your personal information, and we have never done so. We do not share it with third parties for their own marketing, advertising or analytics. The categories below are the complete list of cases where your information leaves our systems. The set of MCP recipients is open-ended because applications can register themselves. Data goes to one only after a mandatory, user-initiated and per-application consent that names the recipient and its redirect URI.

• Google — as the source of the health data you authorized us to read, and the destination for records you ask us to write back.
• MCP clients you connect — at your direction only, as described in section 7.
• Infrastructure providers — the hosting and database providers that run our servers. They process data only to provide that infrastructure to us, under contract, and are not permitted to use it for their own purposes.
• Waffo Pancake, our payment processor — only if you subscribe, and only what is needed to charge you: an account identifier, an email address and an amount. It never receives your health data. It acts on our instructions, and it is where your card details live: they are entered with Waffo Pancake and stored by Waffo Pancake, never on our servers.
• Legal compulsion — where we are required to disclose by valid legal process. We will tell you before we comply unless we are legally prohibited from doing so, and we will object to requests that are overbroad.
• Change of operator — if the Service is ever transferred to another operator, we will give you notice in advance, so that you can export or delete your stored account data before the transfer takes effect.

• Google Health data — not retained on our servers unless you turn on stored history. Without it we read a record from Google for one request and do not write it to our database, server-side caches or backups. With it on, we keep the records we fetched until you turn it off, delete them from your dashboard, or delete your account — whichever comes first. There is no separate expiry clock: we do not quietly discard your history behind your back, and we do not keep it once you have told us to stop. Google keeps the source records under your Google Account settings either way.
• Google authorization credentials — updated when Google refreshes them or you authorize again, and removed when we delete your account data. If you revoke access at Google, the stored tokens stop working immediately.
• MCP application registrations and approvals — an application registration remains while that client is registered. Your approval remains until you revoke it or delete your account. Revoking an application deletes your approval and the stored MCP access and refresh token rows for your account and that client. It does not delete the third party's application registration.
• Account information — kept until you delete your account.
• Server logs — kept for 30 days, then discarded.
• Billing records — invoices and transaction records are kept for as long as tax and accounting law requires us to keep them, which is years rather than days. This is the one thing deleting your account does not remove: we are not allowed to destroy a record of a payment we took. It contains what you paid and when, not what is in your health data.
• Backups — encrypted backups of stored Service data other than health records roll off within 30 days, so data you deleted can persist in a backup for up to that long before it is gone for good. We do not restore deleted data from backups.

These five controls are independent. You can use any of them at any time without giving a reason.

1. Revoke our access at Google. Go to https://myaccount.google.com/permissions and remove GHealth Connector by StillWarm.app. We can no longer read anything from Google Health from that moment, and the daily sync stops. If you had stored history turned on, the records we already fetched stay until you delete them — use the History tab on your dashboard, which removes them immediately, or delete your account. Revocation cannot recall data an MCP client already received.
2. Stop storing your history, and delete what we kept. Use the History tab on your dashboard. Turning stored history off deletes every record we cached for you straight away — not on a schedule, and not marked as inactive somewhere. The same tab can delete what is stored while leaving the setting on, if you would rather start the history over. Neither action affects your Google permissions, your API key or any connected application.
3. Revoke the API key. Use the API key tab on your dashboard. Requests with that key stop working immediately. This does not revoke an OAuth application's approval.
4. Revoke an OAuth application. Use Connected apps on your dashboard. Revocation deletes the application's approval and stored access and refresh tokens. The MCP endpoint rejects its old access token on the next request. This does not revoke your API key or recall data the application already received.
5. Delete stored account data, or your whole account. Email bestony@linux.com from the address on the account and say which stored account information you want deleted or whether you want the entire account removed. Deleting your account also deletes any stored health history. We complete it within 30 days and confirm when it is done. Deletion is permanent; see the backup window — and the billing records we are not allowed to destroy — in section 9.

Cancelling a paid subscription is another separate action, and it deletes nothing: your account and its stored data remain on the free plan. How to cancel is in the Terms of Service.

Deleting your account with us does not delete anything inside Google Health. Your data there stays yours, and you can export it with Google Takeout.

Depending on where you live, you may have some or all of the following rights. We honour them for every user regardless of location, because drawing the line by geography would be arbitrary:

• to know what personal information we hold about you, and why;
• to obtain a copy of it in a portable, machine-readable format;
• to correct information that is inaccurate or incomplete;
• to have it deleted;
• to restrict or object to particular processing;
• to withdraw consent, in whole or for individual categories;
• to be free from discrimination for exercising any of these rights. We do not deny service, charge different prices, or degrade quality because you exercised a right.

To exercise any of them, email bestony@linux.com from the address on your account — that is how we verify a request, and we will ask for more proof only if we have genuine reason to doubt it. We respond within 30 days. You also have the right to complain to your local data protection authority.

• All traffic to the Service is encrypted in transit with HTTPS/TLS.
• Google access and refresh tokens are encrypted at rest with a server-side key. Rotating that key makes every stored token unreadable, which forces re-consent rather than leaving a usable credential behind.
• Passwords, where used, are stored only as salted hashes.
• Session cookies are HTTP-only and same-site, so page scripts cannot read them and other sites cannot replay them.
• Access to production systems is limited to the operator, on the principle of least privilege, and health data is not read by a human except in the narrow cases listed in section 6.

No system is perfectly secure, and we will not claim otherwise. If a breach affects your data, we will notify you and the relevant authorities as required by law, without undue delay.

We operate from the People's Republic of China (Mainland China), and the servers and infrastructure providers we use may be located in other countries. Your data may therefore be transferred to, stored in and processed in a country other than the one you live in, where data protection law may differ. Where the law requires a safeguard for such a transfer, we put one in place. Using the Service means you understand this.

The Service is not intended for anyone under 18, and we do not knowingly collect personal information — least of all health information — from anyone under 18. If you believe someone under 18 has given us data, email bestony@linux.com and we will delete the account and its stored account data promptly.

We may update this policy. When we do, we change the "Last updated" date at the top and publish the new text here. If a change materially reduces your privacy — a new category of data, a new recipient, a new purpose — we will notify you by email or in the app before it takes effect, and where the law requires it we will ask for your consent again. Continuing to use the Service after a change takes effect means you accept the updated policy; if you do not, you can delete your stored account data and your account as described in section 10.

Questions, requests and complaints about privacy all go to the same place, and a person reads them:

• Email: bestony@linux.com
• Operator: Bestony, an individual developer based in the People's Republic of China (Mainland China)
• Service: https://www.stillwarm.app