Google Fitで歩数を取得するための手続きが大変だった話

こんにちは。株式会社JMDC インシュアランス本部ソリューション部の由利です。
今年、JMDCではアドベントカレンダーに参加しています。
qiita.com

本記事は、JMDC Advent Calendar 2023 16日目の記事です。

私は、iOS/Android向けPHRアプリの開発を担当しています。
現在開発しているアプリの機能の1つとして、歩数等を端末から取得して表示するものがあります。
AndroidはGoogle Fit経由で取得しているのですが、Google Fitを使うための手続きに結構な手間がかかりました。
本記事では、時系列でその流れを振り返ってみます。

モバイルアプリで歩数を取得したい

今回は、iOSはHealthKit経由、AndroidはGoogle Fit経由で取得しています。
（後述しますが、Androidはヘルスコネクト経由で取得する方法もあります。）
両者とも、基本的にはアプリの権限設定をし、ライブラリ等を使うだけで、データ取得自体は簡単にできると思います。
開発環境までなら何も問題ありません。

Google Fit APIを使用するためには何が必要か

Google Fit APIを使用するには「制限付きOAuthスコープへのアクセス」が必要です。
プライバシーデータのアクセスや利用は厳しく、フィットネス系はこのカテゴリに属するようです。
そのため、Googleが定める審査基準を満たす必要があります。
Verify your app for use with Google Fit API | Google for Developers

審査通過までは未検証のアプリとして表示され、以下のような表示になります。

審査通過後は、ロゴと許可する項目などが表示されるようになります。

開発環境向けでユーザーが100人以下の場合など（未検証のアプリ画面で問題ない場合）は、審査は不要です。
When is verification not needed - Google Cloud Platform Console Help

OAuthの利用申請をしよう

OAuthを使うために必要な検証については以下で説明されています。
OAuth App Verification Help Center - Google Cloud Platform Console Help

Submitting your app for verification - Google Cloud Platform Console Help
まずは、Google Cloud プロジェクトが必要です。
今回はFirebaseを利用していたので、この辺りはすでに用意済みでした。
手順に従って「APIとサービス」を有効にし、「OAuth同意画面」にたどり着きます。
アプリの情報を入力していきます。プライバシーポリシーやドメインなど、この辺りはストア掲載情報と似ているので問題ないと思います。

続いて、使用するスコープを追加します。
ここでは歩数と消費カロリーを取得したかったので、「制限付きのスコープ」の「Fitness API - .../auth/fitness.activity.read」を追加しました。
ここで、用途説明を記入する必要があります。

さらにデモ動画を用意する必要もあります。

アップロードするYouTubeチャンネルがなければ、ブランドアカウントとかでいい感じに用意しましょう。
動画用に画面録画をする端末の言語設定は、英語にする必要があるようです。
該当の操作を行い、英語の字幕説明をつけてアップロードし、URLを用意できればOKです。

審査ステータスにも記載がありますが、数週間単位で時間がかかります。
指摘事項が上がってくる場合もあるので、根気よく対応していきましょう。
OAuthボタンのガイドラインに準拠していない点を指摘されたりしました。

審査完了

審査完了です。お疲れ様でした。

再審査要求（1回目）

アプリ自体の更新はしていなかったのですが、ポリシーが変わったようで再審査を要求されました。
ここでは申請項目を入力するだけで対応完了しました。

再審査完了（1回目）

再び審査完了ステータスになりました。

再審査要求（2回目）

またポリシーが変わったのかな？と思い手続きしていたら、追加で別の手順を要求されました。

CASA評価対応が必要

CASA（Cloud Application Security Assessment）のTier2評価を受ける必要があるようです。
これは毎年対応する必要があるそうです。
Security Assessment - Google Cloud Platform Console Help

対応期限は、通知時点から3か月後でした。
指定ツールでセルフスキャンを行い、ポータルサイトを通じて審査手続きを行うか、
認定評価機関にスキャンと審査手続きをしてもらうかが選択肢のようです。
ここではセルフスキャンで対応を進めることにしました。

セルフスキャンを実行

プロセスにしたがってセルフスキャンを進めていきます。
CASA Tier 2 Process | App Defense Alliance

後で出てきますが、ポータルサイトで指定される別のツールでスキャンする方法もありそうです。

ここでは静的スキャンを選択することにしました。
Static Scanning Procedures | App Defense Alliance

アプリのソースコードをFluidAttacksというツールでスキャンします。
上記のApp Defense Allianceのページにも手順は記載してありましたが、
FluidAttacksの公式サイトを見ると、ADAの内容は古いらしいので以下を参考にしました。
Using Machine for CASA | Fluid Attacks Documentation

今回スキャンするアプリは、Flutterで作成しています。
ここではFlutterアプリケーションのルートディレクトリを対象として実行しました。
スキャンの実態としては./androidだけでもいいのかもしれません。

上記を参考に、設定ファイルのconfig.yamlを作成し、アプリケーションルートに置きます。

- sast: アプリケーションルート
- sca: アプリケーションルート
- apk: リバースエンジニアリングして解析されるようなので、予めビルドしておき、それを指定する
- checks: 指定しないと全部実行され、それが推奨されるようなので指定しない

続いて実行手順です。
記載の手順通りに毎回docker runしていると、FluidAttacks自体の構築に時間がかかっていました。
FluidAttacksのコンテナ自体を再利用できるようにdocker composeで構築しました。
実行コマンドは以下が参考になりました。
Makes | Fluid Attacks Documentation

version: "3"
services:
  app:
    image: ghcr.io/fluidattacks/makes/amd64:23.06
    command: >
      m gitlab:fluidattacks/universe@trunk /skims scan config.yaml
    volumes:
      - ./[config.yamlがあるソースコードのディレクトリ]:/working-dir

検出結果はマウントフォルダ配下にCSVで出力されます。（Fluid-Attacks-Results.csv）
検出内容に対しては、説明と対応方法のリンクが結果に応じて提示されており、対応がしやすかったです。
Vulnerabilities | Criteria | Fluid Attacks Documentation

ビルド設定等を修正することで、検出結果が0件になるようにしました。

指定ポータルでCASA審査を申請

Googleからきたメールの中に指定されていたポータルサイトで手続きを行います。
PwC Digital

アカウントを作成し、手順に沿って進めます。
提出用のプロジェクトを作成して進めていくと、Fortifyというツールでスキャンした結果を提出するフェーズになります。

対応言語にDartがなかったため、対応言語外であることと、FluidAttacksでスキャンした結果を提出したいという連絡を送ったところ、このフェーズはスキップできました。

Fortifyの対応言語としてKotlin、Javaがあるので、Flutterプロジェクト配下の./androidだけをFortifyでスキャンすることでも対応は可能なのかもしれません。

スキャン結果提出フェーズが終わると、アプリ情報やセキュリティ対策に関する確認事項に回答するフェーズになります。

設問数は多く、プログラム観点だけでなく、インフラや運用観点での対応内容についても確認が必要でした。
開発、インフラ、運用のそれぞれの担当者と責任者で確認しながら回答を作成しました。

確認事項への回答が終わると審査が開始されました。

再審査完了（2回目）

CASAの審査が完了すると、LOV（Letter of Validation）が発行されました。

ポータルサイト側からGoogleへ審査結果が連携されるようで、後日Google側の審査ステータスも審査完了となりました。

まとめ

ただ歩数を取得したいだけだったのに、iOSに比べてAndroidはかなり手間と期間がかかりました。
先日もまた、OAuthが再審査ステータスになり再審査要求をしました…。

他にも、Google Playのアプリアカウントの削除要件についての対応なんかもありました。
Android（Google）だけではありませんが、プラットフォームのポリシーとの付き合いからは逃れられませんね。

冒頭でも触れましたが、今後Androidで歩数を取得する場合は、ヘルスコネクトを経由することになると思います。
ヘルスコネクトとGoogle Fitの比較は、以下にあります。
Frequently asked questions | Android health & fitness | Android Developers

ヘルスコネクトはGoogleアカウントと関連付かないので、OAuth関連の煩わしさもなくなると推測しています。

Google Fit APIは非推奨になり終了するので、我々も移行作業を行う予定です。
Migration Guide | Android health & fitness | Android Developers