nekoblog

nekoblog

ちょっとためになるブログ

ゲームアプリ開発でGDPR(EUでの一般データ保護規則)に対応した時の話

概要

2018年5月25日にEUで一般データ保護規則(GDPR)の運用が開始されました。 日本でも個人情報保護法が改定されましたが、まだWebやアプリ上のデータに関しては大きく問題視はされておりません。一方海外では、Webやアプリ上の個人を特定する情報(IPアドレスCookieなど)に関しても、問題視され始めました。そのような流れを受け、米国においてもカリフォルニア州で2020年1月より新たに消費者プライバシー法(CCPA)が施行されました。

今後、Webやアプリ上の個人情報の保護をどのように対応するのか明確にする事が求められています。 私自身、ゲームアプリ開発ローカライズ作業を進めながら、現地の情報収集を行い、対応するGDPRの実装には、かなり苦労しました。

そこで、GDPRとは何か、またその罰則と私がゲームアプリ開発でどのような対応をしたかなどに関して、備忘録的にまとめます。

事前準備

現地の情報を収集について、実装当時は海外のホームページの情報しかない状態でした。 また、なかなか分かりやすくまとまった情報も少ない状態でした。

現在では検索すると簡単に日本語で情報を収集する事が出来ます。

GDPRとは何か?

GDPRとは「General Data Protection Regulation」の略で、「一般データ保護規則」の事です。 全99条の条文と173項目の前文で構成された法律です。EU域外へのデータ移転を原則認めない、規約に違反すると制裁金が発生します。

GDPRの罰則について

会社のゲームアプリ開発GDPRに従わなかった場合、最大で企業の全世界年間売上高の4%以下、もしくは2000万ユーロ以下のいずれか高い方が適用される状態でした。

  • 初回かつ意図的でない違反の場合は、書面による警告
  • 規則に基づく定期的なデータ保護監査
  • 企業の場合、10,000,000ユーロ、または、前会計期間の全世界の売上高の2%のうち、いずれか大きい方の過料(第83条4項)
  • 企業の場合、20,000,000ユーロ、または、前会計期間の全世界の売上高の4%のうち、いずれか大きい方の過料(第83条5項および6項)

対応

GDPRは、EU域内の事業者だけでなくEU域外の事業者にも適用されます。各組織・企業等の業務への影響について、あらかじめ備えておく必要がありました。

1.GDPRで対応しなくてはならない個人データの洗い出し

GDPRで対応しなくてはならない個人データとは、個人の私生活であれ、職業であれ、あるいは公的生活であれ、個人に関係するあらゆる情報のことだそうです。氏名、自宅住所、写真、電子メールアドレス、銀行口座の詳細情報、ソーシャル・ネットワーク・ウェブサイトへの書き込み、医療情報、または、コンピュータのIPアドレスまで、あらゆるものを含むとのことです。

ゲームアプリ開発では、広告SDKのアナリティクス/PUSH通知で個人データ使用していた。 Firebase Cloud Messagingがデバイストークンを取得していた為、対応が必要な個人データに該当していました。

Firebaseのプライバシーとセキュリティ https://firebase.google.com/support/privacy

GDPR では、データ管理者とデータ処理業者に対して責務を課しています。通常、Firebase のお客様は、Firebase の使用に伴って Google に提供するエンドユーザーの個人データの「データ管理者」の役割を担い、Google は「データ処理業者」となります。

これは、データはお客様の管理下にあることを意味します。データ管理者は、個人データに関する個人の権利を守るなどの責務を負います。

データ管理者としての責務について把握するには、GDPR の規定について十分に理解し、コンプライアンス プランを確認することをおすすめします。

条文には以下の記載があります。

データの収集および利用目的(第7条、第4条の規定)について、有効な同意が明示的に行われなければならない。児童に対する同意は児童の親、または、保護者が与え、確認しなければならない。データ管理者は"同意"(オプトイン)を証明できる必要があり、その同意は取り消されうる。

Firebase Cloud Messagingでデバイストークンを取得の同意を確認して、ユーザーに解除させる必要がありました。

2.Firebaseの対応

Firebase Cloud Messagingの対応をしたのでまとめます。

Firebase Cloud Messagingの使用用途

Firebase Cloud Messaging は、メッセージの配信先デバイスを判別する際にインスタンス ID を使用します。

個人情報の保存期間

Firebase のユーザーが API 呼び出しでインスタンス ID を削除するまで、Firebase はこの ID を保持します。このデータは、呼び出しから 180 日以内にライブシステムとバックアップ システムから削除されます。

コードの対応

ユーザーがサービスやそれに付属するデータ収集にオプトインする機会を提供したいお客様は、ほとんどの場合、サービスを使用する前にダイアログを追加するか、トグルを設定するだけで済みます。ただし、一部のサービスはアプリに含めると自動的に起動します。このようなサービスを使用する前にユーザーにオプトインする機会を与えるには、各サービスの自動初期化を無効にし、代わりに実行時に手動で初期化するという方法があります。

iOSで自動初期化を禁止する

FCM では FCM 内で登録トークンとして使用されるインスタンス ID が生成されます。インスタンス ID が生成されると、ライブラリによりその ID と構成データが Firebase にアップロードされます。インスタンス ID を使用する前に明示的にオプトインする場合は、構成時に FCM を無効にして生成を禁止できます。禁止するには、Info.plist にメタデータ値を追加します。

FirebaseMessagingAutoInitEnabled = NO

FCM をもう一度有効にするには、ランタイム コールを実行します。

iOS で Firebase Cloud Messaging クライアント アプリを設定する https://firebase.google.com/docs/cloud-messaging/ios/client#prevent_auto_initialization

Androidで自動初期化を禁止する

FCM は、Firebase が生成するインスタンス ID を使用して登録トークンを生成します。また、アナリティクスは、この ID を使用してデータを収集します。インスタンス ID が生成されると、ライブラリではその ID と構成データが Firebase にアップロードされます。インスタンス ID の自動生成を禁止するには、次のようにメタデータ値を AndroidManifest.xml に追加して、FCM とアナリティクスで自動初期化を無効にします。

<meta-data
    android:name="firebase_messaging_auto_init_enabled"
    android:value="false" />
<meta-data
    android:name="firebase_analytics_collection_enabled"
    android:value="false" />

FCM をもう一度有効にするには、ランタイム コールを行います。

FirebaseMessaging.getInstance().setAutoInitEnabled(true);

この値をいったん設定すると、アプリを再起動しても維持されます。

Messaging.messaging().autoInitEnabled = true

この値をいったん設定すると、アプリを再起動しても維持されます。

Android で Firebase Cloud Messaging クライアント アプリを設定する https://firebase.google.com/docs/cloud-messaging/android/client#top_of_page

まとめ

今回はEUで一般データ保護規則(GDPR)の運用に対する対応をまとめました。しかし現在、EU域外の特にアジア地域で、ビジネス展開を行う企業では、シンガポールやマレーシアのデータ移転規制や、中国をはじめとして整備が進むデータローカライゼーション規制や、米国においてもカリフォルニア州で2020年1月より新たに消費者プライバシー法(CCPA)が施行された事など、ポストGDPRとして取り組みが各国で進んでいます。

海外へのビジネス展開を行う機会が益々増える中、こうした法的な問題が発生するかと思います。英語でなかなか分かりやすくまとまった情報が少ない状態でも実装する為に必要なノウハウが、今後益々求められていくと思います。