Privacy Policy
Yoshifumi Kanno (the “Operator”) explains below how SyncFlow and its related services (the “Service”) handle information. Reviewing this Policy is separate from agreeing to the Terms.
For additional disclosures and rights concerning Washington and Nevada consumer health data, see the separate Consumer Health Data Privacy Policy (Washington and Nevada).
1. Information handled on the device
- Fitbit credentials, the health and fitness data you select, sync settings, and sync ranges.
- If you connect Google Health: the Google authorization state that Google Sign-In for iOS manages on the device, and your Google Health user identifier, granted permissions, per-category sync start dates, connection and migration state, and the time you accepted the disclosure (see Section 2).
- Apple Health permissions, HealthKit samples written by SyncFlow, and sync identifiers attached to those samples.
- Sync History containing information such as a run ID, source and destination, trigger, run/start/completion times, on-device execution owner, execution state and outcome, category, inspected range, summary unit and count, write count, and a bounded error code. Health measurements are not copied into the Sync History SQLite database.
- A limited Widget snapshot containing information such as local date, latest completion time, category, write count, display status, and plan-view state, plus outcome/category/write counts in an Auto Sync completion notification if you enable it. Lock Screen and Notification Center visibility follows your iOS notification settings.
- App state needed to operate the Service on the device, such as selected settings and ranges, Auto Sync and notification state, an installation ID and deduplication slot, cached legal-document versions and confirmation state, the optional analytics choice, limited entitlement/runtime snapshots, and announcement or display preferences.
SyncFlow applies iOS Data Protection and backup exclusion to Sync History and Widget storage, but cannot promise exclusion under every OS or environment condition. Currently, the Operator provides no Sync History cloud restore, cross-device transfer, iCloud/CloudKit History storage, or backup service. Uninstalling the app, replacing or losing a device, corruption, or deletion may permanently remove that history. Whether Apple Health samples sync through or remain in iCloud follows Apple's services and your device settings.
2. Information received from the Google Health API (Google user data)
This section explains how SyncFlow accesses, uses, stores, shares, retains, and deletes information it receives through the Google Health API when you connect SyncFlow to Google Health (“Google user data”).
2.1 Data accessed and permissions
SyncFlow requests read-only permissions and never writes data to Google Health. It requests only the permissions needed for the categories you enable for sync.
- Activity and fitness (googlehealth.activity_and_fitness.readonly): activity information such as steps, distance, floors climbed, active energy, and basal energy.
- Health metrics and measurements (googlehealth.health_metrics_and_measurements.readonly): health metrics and body measurements such as weight, body fat, blood oxygen, respiratory rate, and heart-related measurements such as resting heart rate.
- Sleep (googlehealth.sleep.readonly): sleep periods and sleep stages.
- Nutrition (googlehealth.nutrition.readonly): nutrition data such as water intake and dietary energy. Requested only when you enable water or dietary energy sync.
- Profile (googlehealth.profile.readonly): your Google Health user identifier, your legacy Fitbit user identifier if you migrated from Fitbit, and your Google Health membership start date. These are used only to determine the sync start date and the range of past data available for sync, and to verify that the same account is used when migrating from Fitbit to Google Health and when reconnecting. SyncFlow does not currently store other profile fields. The legacy Fitbit user identifier is compared on the device only and is not currently stored.
When you sign in, Google Sign-In for iOS may return basic Google Account information (such as name, email address, and profile picture) to the device. SyncFlow does not currently use, store, or transmit it.
A Google permission can cover a broader family of data types than the categories you enable. SyncFlow reads only the data types that correspond to the categories you enable. You may grant only some permissions on the consent screen; categories whose permission is not granted are not synced.
2.2 Use
Google user data is used only to provide and improve user-facing SyncFlow features, such as writing the categories you select into Apple Health (HealthKit) on the same device during a manual sync you start or an automatic sync you enable, and, for that purpose, verifying the account and determining the sync start date. It is not used to serve, target, or measure advertising, for usage analytics, for marketing, for sale, for credit-worthiness or lending decisions, for medical decisions, or to develop, improve, or train generalized artificial intelligence or machine learning models.
2.3 Processing and storage
- Requests to the Google Health API are sent directly from your device to Google over encrypted HTTPS. Google authorization and access tokens are managed on the device by Google Sign-In for iOS. Currently, SyncFlow uses an access token only for requests to Google during a sync and does not separately store it or transmit it anywhere else.
- Currently, health values are converted in device memory during a sync and written to Apple Health; they are not saved in SyncFlow's own on-device storage. Storage and sync of samples written to Apple Health follow Apple's services and your device settings.
- Currently, SyncFlow stores on the device your Google Health user identifier, granted permissions, per-category sync start dates, connection and migration state, the time you accepted the disclosure, and the operational Sync History information described in Section 1 (such as category, inspected range, outcome, and counts).
- Currently, SyncFlow processes Google user data, including health values, the Google Health user identifier, and access tokens, on your device and does not store it on the Operator's server, database, or server logs, or send it to Sentry, Firebase Analytics, AdMob, RevenueCat, or any other third party. The Operator does not allow people to read Google user data except with your explicit consent, for security, to comply with law, or in aggregated and anonymized form, as permitted by the Limited Use requirements.
2.4 Sharing
Google user data is not sold. Any transfer to a third party is made only as permitted by the Limited Use requirements. Currently, SyncFlow passes Google user data only to Apple Health on the same device as the result of a sync you request.
2.5 Retention, disconnection, and deletion
- “Disconnect Google Health” in SyncFlow asks Google to revoke SyncFlow's access and signs out the Google authorization state on the device. Syncs stop until you reconnect. The user identifier remains on the device so that a reconnection can be verified as the same Google Health account.
- You can also revoke access at any time in your Google Account under “Third-party apps & services” (https://myaccount.google.com/connections).
- “Delete Account” asks Google to revoke SyncFlow's access to Google Health, signs out the Google authorization state on the device, and deletes SyncFlow's on-device data, including the Google Health user identifier, permissions, and sync start dates.
- “Delete Synced Data and History” deletes data SyncFlow wrote to Apple Health and Sync History. It keeps the Google Health connection and user identifier.
- Data in Google Health itself follows Google's services and settings and is not deleted by SyncFlow.
2.6 Limited Use
The use of information received from Google Health API and/or Developer Tools will adhere to the Google Health API Developer and User Data Policy, including the Limited Use requirements.
SyncFlow's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
3. Information handled by the Operator's server
- Account information such as a pseudonymous Firebase user ID and account timestamps.
- For notifications and Auto Sync: information such as an installation ID, platform, time zone, Expo push token, notification permission, and app language, used to deliver Auto Sync triggers and announcement notifications; for Auto Sync, also information such as the user's enabled preference, remote-trigger eligibility, Background App Refresh and APNs registration status, next attempt, and latest delivery status. The Silent Push data payload contains the trigger type, time slot, and, when diagnostics are enabled, a diagnostic correlation identifier used to connect the same operation across the device, server, and Sentry for troubleshooting. It does not contain health values, health categories, ranges, counts, or a user ID.
- The Usage Analytics state (enabled, disabled, or undecided), its update time, and app/build version.
- Product Measurement: SyncFlow performs service-operation measurement separately from Firebase Analytics. It records installation-level information such as first-use and setup state, feature settings, daily counts and broad outcomes by sync path, Auto Sync delivery status, announcement engagement, and first milestone times. The purpose is to operate, measure, and improve the Service, including feature adoption, retention, sync reliability, and the performance of in-app features and offers. It does not include health measurements, health categories, sync ranges or health-item counts, Fitbit or Google credentials, or GA4 identifiers. This collection is separate from the Google Analytics setting under About SyncFlow > Usage.
- Regardless of the Usage Analytics setting, the server records per-installation daily operational activity to operate, measure, and improve the Service, including feature adoption, retention, sync reliability, and the performance of in-app features and offers. These records contain information such as the date, which sync paths were used, broad outcomes, daily Widget sync counts, app/build version, Usage Analytics state, and measurement-spec version. These daily records do not contain health measurements, health categories, sync ranges or health-item counts, Push tokens, GA4 identifiers, or exact sync times. They are associated with the server-side pseudonymous Firebase user ID through a pseudonymous installation identifier.
- Legal-confirmation information such as the exact Terms and Policy versions reviewed, confirmation time, app/build version, and locale.
- Connection and technical logs such as IP address, User-Agent, timestamp, route, response status, and timing for delivery, security, abuse prevention, and incident investigation. The app does not intentionally write health payloads, authentication tokens, or Sync History into its server application logs.
Currently, the Operator's server does not store Fitbit tokens, Google authorization data or access tokens, Google Health user identifiers, HealthKit samples, data received from Google Health, health measurements, Sync History categories/ranges/outcomes/counts, or arbitrary provider error text.
4. Analytics, ads, purchases, and diagnostics
- Firebase Analytics: after the legal documents are confirmed, bounded Usage Analytics is enabled. Firebase may process information such as viewed screens and general operations; which sync path was used and its broad outcome; configured Widget families; session and usage information; app version; OS and device model; approximate region; paywall display and purchase-flow events, including where in the app the paywall was shown (such as Settings, sync categories, Auto Sync, or Widget), and in-app purchase events; and an app-instance identifier. The setting is stored on your device and may be disabled under About SyncFlow > Usage at any time. Disabling stops future collection and resets the app analytics identifier; the Service remains usable. Analytics data excludes health data, Google user data, and credentials.
- Firebase operational services: Authentication, App Check, Remote Config, Hosting, and Cloud Run may process information such as a Firebase Installation ID, authentication and attestation material, IP address, country, language, time zone, device/OS/app and network information, request routes or URLs, and response status, size, and timing for authentication, abuse prevention, configuration, and service delivery. API bodies are limited to the information disclosed in Section 3, and application logs intentionally exclude authentication tokens and health payloads. This provider processing is separate from information stored in the Operator's Sync History database.
- AdMob / UMP: may process information such as ad delivery, choices, device or advertising identifiers, ad interactions, and approximate location. Health measurements, HealthKit or Fitbit samples, data received from Google Health, health categories, sync ranges/counts, run IDs, and credentials are not used for ad targeting, request keywords, or ad measurement.
- Apple / RevenueCat: process information such as purchases, receipts, entitlement state, device/app information, a pseudonymous user ID, paywall display and purchase-flow events (SyncFlow uses RevenueCat Paywalls to show subscription offers), and advertising-performance events such as the post-sync ad surface, placement, delivery, network, revenue, currency, and errors. The Operator does not receive payment-card numbers. Health measurements, HealthKit or Fitbit samples, data received from Google Health, health categories, sync ranges/counts, run IDs, and credentials are not sent to RevenueCat.
- Sentry: after the legal documents are confirmed, may process information such as an event ID, symbolicated stack, exception type and mechanism, native threads, release/build/environment, OS and device family/model, locale, app state, fixed diagnostic context, route-name-only navigation/lifecycle/fixed-phase/selected fixed ad-action breadcrumbs, and crash-free session information. Diagnostic data excludes health data, Google user data, and credentials.
5. Support, surveys, and feedback
For a bug report, the email or Google Forms destination may visibly prefill information such as the request type, app and build, platform and OS, device family, locale, entry surface, fixed diagnostic context, and a recent Sentry Event ID only when one already exists. For a question or feature request, a minimal set of app and device context may be prefilled. You can review and edit destination content before sending. Health or sync detail, run keys, credentials, raw errors, and provider payloads are not prefilled. Google, email providers, and the Operator may process the content and attachments you choose to send, plus ordinary web information such as IP address and browser data, to provide support.
The Operator may conduct optional surveys, feedback requests, requests for opinions or suggestions, and other research to improve the Service, develop features, understand usage, or make other operational decisions. These activities may collect usage information, purposes of use, requests, ratings, free-form responses, and other information identified in the relevant survey, and may use external services such as Google Forms to collect and manage responses.
6. Purposes
Information is used for purposes such as performing sync, showing local History and Widgets, making an additional Auto Sync attempt, sending announcements, showing subscription offers and verifying purchases, preserving settings, operating, measuring, and improving the Service and feature use (Product Measurement, regardless of the Usage Analytics setting), analyzing general use with Firebase Analytics while the Usage Analytics setting is enabled, serving ads, preventing failures and abuse, answering support, managing legal versions, and meeting legal or platform requirements. Health measurements, HealthKit or Fitbit samples, data received from Google Health, health categories, sync ranges/counts, run IDs, and credentials are not sold or used for ad targeting, general analytics, or marketing. General screen, ad-placement, paywall, purchase-flow, and post-sync ad-surface events disclosed above may be processed.
The Operator may create and use statistical or aggregated information that does not identify individuals. Google user data is used for this purpose only in aggregated and anonymized form as permitted by the Limited Use requirements.
7. Providers and international processing
The Service uses providers such as Apple Health / HealthKit, Fitbit, Google Health API, Google Sign-In, Firebase Authentication / App Check / Analytics / Remote Config, Google Cloud, Expo Push Service, RevenueCat, Sentry, Google AdMob / UMP, Google Forms, email providers, and other service providers that help operate the Service. They may process information outside your country under their terms, policies, and applicable transfer safeguards.
The Operator selects and uses external providers that implement safeguards required by applicable law and platform rules.
The Operator may disclose information when required by law or by a valid request from a public authority, or to protect the rights, property, or safety of users, the Operator, or others, or the Service, as permitted by law. Google user data is disclosed for these reasons only as permitted by the Limited Use requirements.
8. Retention
- On-device Sync History remains until you delete it or the app data is lost.
- Fitbit credentials and connection state remain until disconnection, replacement, account deletion, uninstall, or other device/OS handling. Settings, cursors, Widget, and notification state remain until update, disablement, Delete All, account deletion, uninstall, or similar handling.
- Google authorization state is kept on the device by Google Sign-In for iOS until you disconnect Google Health, delete your account, revoke access in your Google Account, uninstall the app, or other device/OS handling occurs. Google Health permissions and sync start dates remain on the device until you disconnect Google Health, delete your account, uninstall the app, or other device/OS handling occurs. The Google Health user identifier and connection state remain on the device until account deletion, uninstall, or other device/OS handling (after a disconnect, the user identifier remains so that a reconnection can be verified as the same account). Health values received from Google Health do not remain in SyncFlow's on-device storage or on the Operator's server after a sync completes.
- HealthKit samples written by SyncFlow may remain in Apple Health until deleted by you or SyncFlow, or otherwise handled by Apple. Apple Health/iCloud retention and sync follow Apple and your settings.
- Server user and legal-confirmation records generally remain until account deletion. Records reasonably needed for law, disputes, or abuse prevention may be retained where permitted.
- Successful account deletion removes the relevant records from the active database. Restricted disaster recovery and security backups may retain residual copies until ordinary rotation completes, and a limited number of backup generations are kept under ordinary rotation. Backups are not used except for recovery, legal, or security needs, and applicable deletions are reapplied to active systems after a restore.
- Installation information, its Push token, notification permission, and app language are retained while the push delivery route remains valid. Delivery information is removed when the token is replaced or reported invalid by the provider, or the account is deleted. Delete All stops Auto Sync triggers.
- Daily installation-activity records are retained without automatic elapsed-time deletion to measure long-term usage trends, retention, and the value of background features. They remain until account deletion, an applicable deletion request, or another reason ending the processing purpose applies.
- Product Measurement installation-linked daily facts and first-use times are retained while the account exists and the improvement purpose continues, and are removed from the active database on account deletion. Temporary Auto Sync push correlation records are kept for a limited period. Unsent on-device measurements are kept for a limited period and are deleted with the account.
- Support information is retained only as reasonably needed to answer, investigate, prevent recurrence, follow up, meet legal or security duties, or resolve a dispute, then deleted or anonymized. Provider backups or legally required retention follow provider rules.
- The Usage Analytics setting remains on the device until withdrawal, account deletion, uninstall, or other device/OS handling. Data processed while enabled, advertising, purchase, and diagnostic retention also follows provider settings and policies.
- Connection and technical logs for services such as Cloud Run follow the verified Google Cloud retention configuration for a limited period. Records may be preserved longer where permitted for law, security investigations, or legitimate dispute handling.
9. Deletion, choices, and rights
“Delete Synced Data and History” deletes local Sync History, Widget data, cursors, and SyncFlow-authored HealthKit data, but not the Fitbit connection, Apple purchase, legal confirmation, or account. “Delete Account” attempts deletion of the Operator-controlled user aggregate, push registration, legal confirmations, local installation ID, local history and credentials, and SyncFlow-authored HealthKit data. It also asks Google to revoke SyncFlow's Google Health access. Revoking Fitbit access, deleting Apple's transaction records, and canceling an Apple subscription are separate actions. See Section 2.5 for disconnecting Google Health and revoking Google access.
Usage Analytics may be disabled under About SyncFlow > Usage at any time, which stops future collection and resets the app analytics identifier. You may use the Service while Analytics is disabled.
If you do not confirm a new Terms or Policy version, or the documents cannot be retrieved, the app may still offer basic functions such as Delete Account on a limited screen. Firebase may still process data to retrieve legal documents, resolve an existing account, or enforce an analytics-disabled boundary.
Depending on your location, you may request access, correction, deletion, restriction, objection, withdrawal, portability, or complain to an authority. Identity verification and lawful exceptions may apply.
10. Security and incidents
The Operator uses reasonable safeguards such as encrypted transport, authentication, App Check, least privilege, device protection, backup exclusion, validation, minimized diagnostics, and deletion controls. No system is perfectly secure. Incidents will be investigated and notified where applicable law requires.
11. Children, business transfers, changes, and contact
The Service is not directed to children. Do not use it unless you have reached the minimum age to consent independently under the laws, platform, and health services applicable to you.
In a merger, acquisition, business transfer, or similar transaction, information may be transferred to the successor. Google user data is transferred in such a transaction only after the Operator obtains your explicit prior consent, as required by the Google API Services User Data Policy, including the Limited Use requirements.
The Operator may update this Policy. Unless applicable law requires otherwise, an update takes effect when it is posted on this page. For material changes, the Operator will give notice in the app or on this page and will obtain your consent where applicable law requires it. Before using Google user data in a new way or for a purpose not described in this Policy, the Operator will notify you and ask for your consent to the updated Policy, as required by the Google API Services User Data Policy.
Operator: Yoshifumi Kanno
Email: sync.health.app@gmail.com
Address and phone number will be disclosed without delay upon a legally valid request.
プライバシーポリシー
Yoshifumi Kanno(以下「運営者」)は、SyncFlowアプリおよび関連サービス(以下「本サービス」)における情報の取扱いを、次のとおり説明します。本ポリシーの確認は、利用規約への同意とは別の行為です。
Washington州およびNevada州の消費者健康データに関する追加開示と権利は、英語のConsumer Health Data Privacy Policy (Washington and Nevada)をご確認ください。
1. 端末内で取り扱う情報
- Fitbitの認証情報、利用者が選択した健康・フィットネスデータ、同期設定および同期範囲。
- Google Healthを接続した場合、Google Sign-In for iOSが端末内で管理するGoogleの認可状態、ならびにGoogle Healthのユーザー識別子、許可された権限、カテゴリごとの同期開始日、接続・移行の状態および開示への同意時刻(詳細は第2項)。
- Apple Healthへの読書き権限、SyncFlowが書き込むHealthKitサンプル、およびサンプルに付す同期識別情報。
- 同期実行ID、同期元・同期先、実行契機、実行・開始・完了時刻、端末実行であること、実行状態・結果、カテゴリ、確認期間、集計単位・件数、書込件数、限定されたエラーコード等からなるSync History。健康測定値そのものはSync HistoryのSQLiteデータベースへ複製しません。
- Widget表示用の日付、最終完了時刻、カテゴリ、書込件数、表示状態、プラン表示区分等の限定されたスナップショット、ならびに利用者が有効にした自動同期完了通知の結果・カテゴリ数・書込件数。通知のロック画面等への表示はiOSの通知設定に従います。
- 選択した設定・範囲、自動同期・通知の状態、端末内のインストール識別子・重複防止枠、法的文書の版と確認状態、任意の利用状況分析の選択、購入権利・運用設定の限定されたキャッシュ、お知らせ・表示設定等、本サービスを端末上で動作させるためのアプリ状態。
Sync HistoryとWidget領域にはiOSのData Protectionおよびバックアップ除外を適用します。ただし、OSや利用環境を含む全ての状況で除外を絶対に保証するものではありません。現在、運営者はSync History用のiCloud・CloudKit、クラウド復元、端末間移行またはバックアップサービスを提供しません。アンインストール、端末交換、故障、データ破損または削除により履歴を失う場合があります。Apple Health内のサンプルがiCloud等で同期・保持されるかは、Appleのサービスと利用者の端末設定に従います。
2. Google Health APIから受け取る情報(Googleユーザーデータ)
本項は、利用者がSyncFlowをGoogle Healthに接続した場合に、Google Health APIを通じて受け取る情報(以下「Googleユーザーデータ」)の取得、利用、保存、共有、保持および削除を説明します。
2.1 取得する情報と権限
SyncFlowは読み取り専用の権限だけを要求し、Google Healthへデータを書き込みません。権限は、利用者が同期対象として有効にしたカテゴリに必要なものだけを要求します。
- アクティビティとフィットネス(googlehealth.activity_and_fitness.readonly):歩数、距離、上った階数、アクティブエネルギーおよび基礎代謝エネルギー等のアクティビティ情報。
- 健康指標と測定値(googlehealth.health_metrics_and_measurements.readonly):体重、体脂肪率、血中酸素、呼吸数、ならびに安静時心拍数等の心拍関連の測定値といった健康指標・身体測定値。
- 睡眠(googlehealth.sleep.readonly):睡眠の時間帯と睡眠段階。
- 栄養(googlehealth.nutrition.readonly):水分摂取量や摂取エネルギー等の栄養データ。利用者が水分または摂取エネルギーの同期を有効にした場合だけ要求します。
- プロフィール(googlehealth.profile.readonly):Google Healthのユーザー識別子、Fitbitから移行した場合の旧Fitbitユーザー識別子、およびGoogle Healthの利用開始日。同期開始日と、同期できる過去データの範囲を判断するため、ならびにFitbitからGoogle Healthへの移行時および再接続時に同じアカウントであることを確認するためだけに使用します。SyncFlowは現在、その他のプロフィール項目を保存していません。旧Fitbitユーザー識別子は端末内での照合にだけ使用し、現在は保存していません。
Google Sign-In for iOSは、ログイン時にGoogleアカウントの基本情報(氏名、メールアドレス、プロフィール画像等)を端末へ返す場合があります。SyncFlowは現在、これらを使用、保存または送信していません。
Googleの権限は、有効にしたカテゴリより広いデータ種類をまとめて対象とする場合があります。その場合でも、SyncFlowは有効にしたカテゴリに対応するデータ種類だけを読み取ります。利用者は同意画面で一部の権限だけを許可でき、許可されなかった権限のカテゴリは同期されません。
2.2 利用目的
Googleユーザーデータは、利用者に提供するSyncFlowの機能の提供と改善にだけ使用します。例えば、手動同期または利用者が有効にした自動同期の実行時に、選択したカテゴリを同じ端末のApple Health(HealthKit)へ書き込むこと、およびそのためのアカウント確認と同期開始日の決定です。Googleユーザーデータを広告の表示・ターゲティング・効果測定、利用状況分析、マーケティング、データの販売、信用力の判断・融資、医療上の判断、または汎用的なAI・機械学習モデルの開発・改善・学習には使用しません。
2.3 処理と保存の場所
- Google Health APIへの通信は、利用者の端末から直接、暗号化されたHTTPS通信でGoogleへ行います。Googleの認可とアクセストークンはGoogle Sign-In for iOSが端末内で管理します。現在、SyncFlowはアクセストークンを同期中のGoogleへのリクエストにだけ使用し、独自に保存または他へ送信していません。
- 現在、健康データの値は、同期処理中に端末のメモリ内で変換してApple Healthへ書き込み、SyncFlow独自の端末内ストレージには保存していません。Apple Healthに書き込まれたサンプルの保存と同期は、Appleのサービスと利用者の端末設定に従います。
- 現在、SyncFlowが端末内に保存するのは、Google Healthのユーザー識別子、許可された権限、カテゴリごとの同期開始日、接続・移行の状態、開示への同意時刻、ならびに第1項のSync Historyに記録するカテゴリ、確認期間、結果、件数等の動作情報です。
- 現在、SyncFlowはGoogleユーザーデータ(健康データの値、Google Healthのユーザー識別子およびアクセストークンを含みます)を利用者の端末上で処理し、運営者のサーバー、データベースまたはサーバーログに保存していません。Sentry、Firebase Analytics、AdMob、RevenueCatその他の第三者へも送信していません。運営者は、Limited Use要件が認める範囲で、利用者の明示的な同意がある場合、セキュリティのため、法令遵守のため、または集計・匿名化された形式の場合を除き、人がGoogleユーザーデータを閲覧することを認めません。
2.4 共有
Googleユーザーデータを販売しません。第三者への移転は、Limited Use要件が認める範囲に限ります。現在、SyncFlowがGoogleユーザーデータを渡す先は、利用者が要求した同期による同じ端末のApple Healthだけです。
2.5 保持、接続解除および削除
- SyncFlowの「Google Healthの接続を解除」は、Googleに対してSyncFlowへのアクセス許可の取消しを要求し、端末内のGoogleの認可状態をサインアウトします。以後の同期は、利用者が再接続するまで停止します。同じGoogle Healthアカウントでの再接続を確認するため、ユーザー識別子は端末内に残ります。
- 利用者は、Googleアカウントの「サードパーティ製のアプリとサービス」(https://myaccount.google.com/connections)からもいつでもアクセス許可を取り消せます。
- 「アカウントを削除」は、Googleに対してSyncFlowのGoogle Healthへのアクセス許可の取消しを要求して端末内のGoogleの認可状態をサインアウトし、Google Healthのユーザー識別子、権限、同期開始日等を含む端末内のSyncFlowのデータを削除します。
- 「同期済みデータと履歴を削除」は、SyncFlowがApple Healthへ書き込んだデータとSync Historyを削除します。Google Healthの接続とユーザー識別子は維持します。
- Google Health内のデータ自体は、Googleのサービスと設定に従い、SyncFlowによる削除の対象ではありません。
2.6 Limited Use
The use of information received from Google Health API and/or Developer Tools will adhere to the Google Health API Developer and User Data Policy, including the Limited Use requirements.
SyncFlowによるGoogle APIから受け取った情報の利用および他のアプリへの移転は、Limited Use要件を含むGoogle API Services User Data Policyに従います。
3. 運営者のサーバーで取り扱う情報
- Firebaseの仮名ユーザーID、アカウント作成・更新時刻等のアカウント情報。
- 自動同期のトリガーとお知らせ通知の配信のためのインストール識別子、プラットフォーム、タイムゾーン、Expo Push Token、通知許可の状態、アプリの表示言語等、ならびに自動同期のための利用者の有効設定、リモート起動可否、Background App Refresh・APNs登録の状態、次回試行時刻、最新の配信結果等。Silent Pushのデータ部には、トリガー種別、時刻枠、および診断機能が有効な場合の診断相関用識別子が含まれます。この識別子は、端末・サーバー・Sentry上の同じ処理を関連付けて障害を調査するために使用します。健康値、健康カテゴリ、同期範囲、件数またはユーザーIDは含みません。
- 利用状況分析の有効・無効・未決定の状態と更新時刻、アプリ版およびビルド番号。
- Product Measurement:SyncFlowは、Firebase Analyticsとは別にサービス運営上の計測を行います。インストール単位の初回利用・同期準備状態、機能の設定状態、同期経路別の日次回数と大まかな結果、自動同期の配信状況、お知らせへの反応、初回達成時刻等を記録します。目的は、機能の利用開始、継続利用、同期の信頼性、ならびにアプリ内の機能・オファーの成果を含む本サービスの運営・計測・改善です。健康測定値、健康カテゴリ、同期期間・健康データ件数、FitbitおよびGoogleの資格情報、GA4識別子は含めません。この計測は「このアプリについて > 利用状況」のGoogle Analytics設定とは別です。
- 利用状況分析の設定にかかわらず、機能の利用開始、継続利用、同期の信頼性、ならびにアプリ内の機能・オファーの成果を含む本サービスの運営・計測・改善のため、サーバーはインストール単位の日単位の動作記録を保存します。この記録には、日付、利用された同期経路、大まかな結果、Widget同期の日次回数、アプリ版・ビルド番号、利用状況分析の設定状態、計測仕様版等が含まれます。健康測定値、健康カテゴリ、同期対象期間・健康データの件数、Push Token、GA4識別子または正確な同期時刻は、この日単位記録へ保存しません。日単位記録は仮名インストール識別子を通じて、運営者サーバー上のFirebase仮名ユーザーIDに関連付けられます。
- 確認した利用規約・本ポリシーの版、確認時刻、アプリ版、ビルド番号、言語等の法的文書確認情報。
- 配信、安全管理、不正利用防止および障害調査のため、IPアドレス、User-Agent、日時、経路、応答状態・所要時間等の接続・技術ログ。健康データ本文、認証トークンまたはSync Historyをアプリのサーバーログへ意図的に記録しません。
現在、運営者のサーバーへ、Fitbitトークン、Googleの認可情報・アクセストークン、Google Healthのユーザー識別子、HealthKitサンプル、Google Healthから受け取ったデータ、健康測定値、Sync Historyのカテゴリ・期間・結果・件数、または任意のプロバイダーエラー本文を保存していません。
4. 分析、広告、購入および障害診断
- Firebase Analytics:法的文書の確認後、限定された利用状況分析を有効にします。閲覧画面と一般操作、利用された同期経路と大まかな成否、設定済みWidgetの種類、セッション・利用状況、アプリ版、OS・端末機種、概算地域、ペイウォールの表示・購入フローのイベント(ペイウォールを表示したアプリ内の場所(設定、同期カテゴリ、自動同期、Widget等)を含みます)、アプリ内購入イベント、アプリインスタンスID等を処理する場合があります。この設定は端末に保存され、「このアプリについて > 利用状況」でいつでも無効にできます。無効化すると将来の収集を停止し、アプリ分析識別子をリセットします。分析データには、健康データ、Googleユーザーデータおよび資格情報を含めません。
- Firebaseの運用機能:Authentication、App Check、Remote Config、HostingおよびCloud Runは、Firebase Installation ID、認証・端末証明情報、IPアドレス、国・言語・タイムゾーン、端末・OS・アプリ・通信情報、リクエスト経路・URL、応答状態・サイズ・所要時間等を、認証、不正防止、設定配信およびサービス提供のため処理する場合があります。API本文は第3項で開示した限定情報に限り、アプリケーションログへ認証トークンや健康データ本文を意図的に記録しません。これらは運営者のSync Historyデータベースへ保存する情報とは別の、第三者サービスによる処理です。
- AdMob / UMP:広告表示・配置、同意選択、端末・広告識別子、広告操作および概算地域等を処理する場合があります。健康測定値、HealthKit・Fitbitサンプル、Google Healthから受け取ったデータ、健康カテゴリ、同期範囲・件数、Run IDまたは資格情報を広告ターゲティング、広告リクエストのキーワードまたは広告効果測定へ使用しません。
- Apple / RevenueCat:購入、レシート、権利状態、端末・アプリ情報、仮名ユーザーID、ペイウォールの表示・購入フローのイベント(SyncFlowはサブスクリプションの案内にRevenueCat Paywallsを使用します)、ならびに同期完了後の広告面を含む広告の配置・配信・ネットワーク・収益・通貨・エラー等の広告実績イベントを処理します。運営者はカード番号を取得しません。健康測定値、HealthKit・Fitbitサンプル、Google Healthから受け取ったデータ、健康カテゴリ、同期範囲・件数、Run IDまたは資格情報はRevenueCatへ送りません。
- Sentry:法的文書の確認後に、Event ID、シンボル化されたスタック、例外種別・発生機構とNative Thread、Release・Build・環境、OS・端末ファミリー・機種・言語・アプリ状態、固定された診断コンテキスト、画面名のみのナビゲーション・ライフサイクル・固定フェーズ・一部の固定広告動作のBreadcrumb、およびCrash-free Session情報等を障害調査のため処理する場合があります。診断データには、健康データ、Googleユーザーデータおよび資格情報を含めません。
5. 問い合わせ・アンケート等
不具合報告では、メールまたはGoogle Formsの送信内容に、利用者が確認・編集できる状態で、問い合わせ種別、アプリ版・ビルド、プラットフォーム・OS、端末ファミリー、言語、開始画面、固定された診断コンテキスト、既に存在する場合に限る直近のSentry Event ID等を事前入力する場合があります。質問・機能要望では、最小限のアプリ・端末情報を事前入力する場合があります。健康・同期の詳細、Run Key、資格情報、生エラーまたはプロバイダーのPayloadを事前入力しません。問い合わせ本文、利用者が選んだ添付、IPアドレスやブラウザ情報等はGoogle、メール事業者および運営者がサポート対応のため処理する場合があります。
運営者は、本サービスの改善、機能開発、利用状況の把握その他の運営上の判断のため、任意のアンケート、フィードバック、意見・要望の募集その他の調査を実施する場合があります。これらでは、利用状況、利用目的、要望、評価、自由記述その他各調査で案内する情報を取得し、Google Forms等の外部サービスを通じて収集・管理する場合があります。
6. 利用目的
同期の実行、ローカル履歴・Widget表示、自動同期の追加試行、お知らせの配信、サブスクリプションの案内と購入権利確認、設定維持、本サービスと機能利用の運営・計測・改善(利用状況分析の設定にかかわらないProduct Measurement)、利用状況分析の設定が有効な間のFirebase Analyticsによる一般的な利用状況の分析、広告、障害・不正利用の防止、問い合わせ対応、法的文書の版管理、法令・プラットフォーム要件への対応等の目的に利用します。健康測定値、HealthKit・Fitbitサンプル、Google Healthから受け取ったデータ、健康カテゴリ、同期範囲・件数、Run IDまたは資格情報を販売せず、広告ターゲティング・一般分析・マーケティングに利用しません。前項で開示した一般的な画面、広告配置、ペイウォール、購入フローおよび同期完了後の広告面に関するイベントは処理される場合があります。
運営者は、個人を識別できない統計情報・集計情報を作成し、利用する場合があります。Googleユーザーデータをこの目的に利用するのは、Limited Use要件が認める範囲で集計・匿名化された形式の場合に限ります。
7. 外部事業者と国外処理
本サービスはApple Health / HealthKit、Fitbit、Google Health API、Google Sign-In、Firebase Authentication / App Check / Analytics / Remote Config、Google Cloud、Expo Push Service、RevenueCat、Sentry、Google AdMob / UMP、Google Forms、メール事業者、その他本サービスの運営を支援する事業者等を利用します。これらの事業者は日本国外を含む地域で、各社の規約、ポリシーおよび法的保護措置に基づき情報を処理する場合があります。
運営者は、利用者の情報を取り扱う外部事業者として、適用法令およびプラットフォーム規則が求める保護措置を講じる事業者を選定して利用します。
運営者は、法令に基づく場合、公的機関からの有効な要請がある場合、または利用者、運営者その他の者もしくは本サービスの権利、財産もしくは安全を保護するため、法令が認める範囲で情報を開示する場合があります。Googleユーザーデータをこれらの理由で開示するのは、Limited Use要件が認める範囲に限ります。
8. 保存期間
- 端末内のSync Historyは、利用者が削除するか、アプリのデータが失われるまで保存されます。
- Fitbit資格情報および接続状態は、切断、置換、アカウント削除、アンインストールその他の端末・OS処理まで、端末設定・カーソル・Widget・通知状態は更新、無効化、Delete All、アカウント削除またはアンインストール等まで保持されます。
- Google Healthの認可状態は、接続解除、アカウント削除、Googleアカウント設定での取消し、アンインストールその他の端末・OS処理まで、Google Sign-In for iOSが端末内で保持します。Google Healthの権限と同期開始日は、接続解除、アカウント削除、アンインストールその他の端末・OS処理まで端末内に保持します。Google Healthのユーザー識別子と接続状態は、アカウント削除、アンインストールその他の端末・OS処理まで端末内に保持します(接続解除後もユーザー識別子は再接続確認のため残ります)。Google Healthから受け取った健康データの値は、同期処理の完了後にSyncFlowの端末内ストレージにも運営者のサーバーにも残りません。
- SyncFlowが書き込んだHealthKitサンプルは、利用者・SyncFlowによる削除またはApple側の処理までApple Health内に残り得ます。Apple Health/iCloud側の保存・同期はAppleおよび利用者設定に従います。
- サーバーのユーザーおよび法的文書確認記録は、原則としてアカウント削除まで保存します。法令、紛争対応または不正防止に必要な記録は必要な範囲で保持する場合があります。
- アカウント削除が成功すると対象記録を稼働中データベースから削除します。ただし、災害復旧・セキュリティ用のアクセス制限されたバックアップには通常のローテーションが完了するまで残る場合があります。バックアップは、通常のローテーションに基づく限られた世代数だけ保持します。バックアップは復旧、法令またはセキュリティ上必要な場合を除き利用せず、復元した場合は適用可能な削除を稼働系へ再適用します。
- Push配送先が有効な間、インストール情報、Push Token、通知許可の状態およびアプリの表示言語を保持します。Tokenの置換、配信事業者による無効判定またはアカウント削除により、該当する配送情報を削除します。Delete Allは自動同期のトリガーを停止します。
- 日単位のインストール活動記録は、利用状況の長期推移、継続利用およびバックグラウンド機能の価値を把握するため、経過日数による自動削除を行わず、アカウント削除、適法な削除要求または処理目的の終了等の削除理由が生じるまで保持します。
- Product Measurementのインストールに結び付く日次記録と初回達成時刻は、アカウントが存在し改善目的が続く間保持し、アカウント削除時に稼働中データベースから削除します。自動同期Pushの一時的な相関記録は限られた期間だけ保持します。端末内の未送信計測情報は限られた期間だけ保持し、アカウント削除時に削除します。
- 問い合わせ情報は、回答、調査、再発防止、フォローアップ、法令・安全上の義務または紛争対応に合理的に必要な期間だけ保持し、不要になった後に削除または匿名化します。第三者のバックアップ・法定保存は各社方針に従います。
- 利用状況分析の選択は、撤回、アカウント削除、アンインストールその他の端末・OS処理まで端末に保存されます。分析を有効にした後のデータ、広告、購入および診断の保存期間は各事業者の設定・方針にも従います。
- Cloud Run等の接続・技術ログは、運営者が確認したGoogle Cloudの保存設定に従い、限られた期間だけ保持します。法令、セキュリティ調査または正当な紛争対応に必要な場合は、許される範囲で別途保全することがあります。
9. 削除、選択および権利
「同期済みデータと履歴を削除」は、ローカルSync History、Widget、同期カーソルおよびSyncFlowが書き込んだHealthKitデータを削除しますが、Fitbit接続、Appleの購入、法的確認またはアカウント自体を削除しません。「アカウントを削除」は、運営者のユーザー集約、Push登録、法的確認、端末のインストール識別子、ローカル履歴・認証情報、およびSyncFlowが書き込んだHealthKitデータの削除を試みます。また、SyncFlowのGoogle Healthへのアクセス許可の取消しを要求します。Fitbit側の許可取消し、Appleの取引記録削除およびサブスクリプション解約は別の手続です。Google Healthの接続解除とアクセス許可の取消しは第2.5項をご確認ください。
利用状況分析は「このアプリについて > 利用状況」でいつでも無効にでき、無効化時に将来の収集を停止してアプリ分析識別子をリセットします。無効にしても本サービスを利用できます。
新しい規約・ポリシーを確認しない場合または文書を取得できない場合でも、限定画面からアカウント削除等の基本的な機能を利用できる場合があります。Firebaseは、法的文書の取得、既存アカウントの判定または分析収集を停止する境界の適用のため処理する場合があります。
居住地域に応じて、アクセス、訂正、削除、処理制限、異議申立て、同意撤回、データ移転または監督機関への申立てを行える場合があります。本人確認および法令上許される例外を適用することがあります。
10. 安全管理とインシデント
通信暗号化、認証、App Check、最小権限、端末保護、バックアップ除外、入力検証、診断最小化、削除手段等の合理的な対策を講じます。完全な安全性は保証できません。適用法令上必要な場合、インシデントを調査し、利用者または当局へ通知します。
11. 子ども・事業承継・改定・連絡先
本サービスは子ども向けではありません。居住地域および利用するプラットフォーム・健康サービスについて有効な同意を単独で行える最低年齢に達していない方は利用しないでください。
合併、買収、事業譲渡その他これらに類する取引に伴い、情報を承継者へ移転する場合があります。この場合でも、Googleユーザーデータは、Limited Use要件を含むGoogle API Services User Data Policyが求めるとおり、利用者の明示的な事前の同意を得た後にだけ移転します。
運営者は本ポリシーを改定することがあります。法令上別段の定めがある場合を除き、改定は本ページへの掲載時に効力を生じます。重要な変更については、アプリ内または本ページで通知し、法令上必要な場合は利用者の同意を得ます。Googleユーザーデータを新しい方法で、または本ポリシーに記載のない目的で利用する前には、Google API Services User Data Policyが求めるとおり、利用者に通知し、改定後のポリシーへの同意を求めます。
運営者:Yoshifumi Kanno
メール:sync.health.app@gmail.com
住所・電話番号は、法令に基づく請求があった場合に遅滞なく開示します。