Last updated: 12 September 2026
This policy describes how Personal Health Hub, operated by the owner of yaniss.fr, handles data for a personal fitness and health data project. The application is currently used only by its operator. It is not a public service and does not accept registrations.
Data accessed
With the Google account owner’s consent, Personal Health Hub accesses the following Google Health API categories using read-only permissions:
- Activity and fitness: available steps, distance, active zone minutes, and exercise sessions.
- Sleep: available sleep sessions, summaries, stages, and awakenings.
- Health metrics and measurements: available heart rate, resting heart rate, heart-rate variability, oxygen saturation, respiratory rate, and sleep temperature metrics.
Records may include source and device information, identifiers, dates, timestamps, UTC offsets, units, and other metadata returned by Google. The current importer retains only records whose source platform is Fitbit and whose device name is Google Fitbit Air, subject to a measurement-date cutoff of 10 September 2026. Responses may contain other sources before filtering. Initial diagnostic response files may also contain such records and are held privately for setup and troubleshooting.
The project separately imports workout files exported by the operator from Strong. These may contain exercise names, sets, repetitions, weights, durations, rest timers, and workout notes.
Google authorization credentials, including access and refresh tokens, are stored to support authorized API access. The application does not request or store the operator’s Google password.
How data is used
Data is used for personal record keeping, importing and organizing fitness history, checking data quality, troubleshooting the connection, and producing personal analyses of workout, activity, sleep, and health trends. Original API record contents are retained where available so that calculations and database structures can be reviewed or changed.
Google Health data is not used for advertising, sold, or used to train generalized artificial intelligence or machine-learning models. The application does not modify or delete data in Google Health.
Storage and access
The application runs on a personally managed Raspberry Pi. Imported records are stored in PostgreSQL, with source files and authorization credentials stored separately on the Pi. Remote administration and uploads use SSH and/or Tailscale. Access is restricted through account authentication and file permissions.
Exports, diagnostic samples, and backups may also be copied to computers and storage used by the operator. Some setup copies have been stored on a work-managed computer, which may be subject to the employer’s administrative access and retention rules. The project does not claim that every stored copy is encrypted at rest.
The public pages on yaniss.fr describe the application and its privacy practices. Health records and Google authorization tokens are not intentionally published on these pages. Browsing these pages may be subject to the website’s separate hosting, logging, and cookie practices.
Disclosure and service providers
Google provides the source data and authorization services. Tailscale is used for private network connectivity. These services operate under their own applicable terms and privacy policies.
There is no automatic forwarding of health records to an AI service in the current importer. The operator may deliberately share selected sample files with an AI assistant or another technical support provider for development and troubleshooting. Any such disclosure is subject to that provider’s applicable terms and privacy practices. Authorization tokens should not be included in those samples.
Health data is not made available to advertisers or other users. Data may be disclosed if required by applicable law.
Retention and backups
Imported records and retained source exports are kept for personal historical analysis until the operator deletes them. There is currently no fixed automatic deletion period for all source files or diagnostic samples.
The current Fitbit importer replaces its previous complete database snapshot and its latest eligible-record export after a successful refresh. It does not currently guarantee permanent retention of every historical revision. The local database backup script is configured to retain approximately seven days of dated backups. Copies made elsewhere are retained until separately deleted by the operator.
Any future change to archival or retention behavior will be reflected in this policy.
Revoking access and deleting data
The operator can revoke the application’s Google access through Google Account connections. Revocation prevents further authorized retrieval but does not automatically erase records already downloaded.
To remove stored data, the operator must delete the relevant database records, source exports, diagnostic files, and authorization credentials, and separately remove retained backup copies. Backups are not immediately erased when live database records are deleted.
Changes and contact
This policy may be updated as the personal project changes. The date above identifies the latest revision.
For privacy questions, contact illoul at yaniss dot fr.