Android Mの
runtime-permissionに潜む罠
2015/8/11
塩田 明弘
自己紹介
株式会社NTTデータ所属
メインの仕事はセキュリティ
2014/4より社内向けのAndroidセキュリティ
ガイドライン作成やサポートに従事
今回の資料はAndroid M Developer Preview 2ベースです。
最終版では異なる仕様になっている可能性があります。
Android Mから
新パーミッションモデルが採用
新パーミッションモデルの特徴
インストール時ではなく、利用時に許可を求める
チェックや許可要求、結果受け取りは作ってやる必要有り
→公式やサンプル参照
許可を与えても後から変更が可能
新パーミッションモデルの特徴
Androidの抱える課題の一つ、
「許可したパーミッションを後から変更できない」
という状況の解消(ただし、一部のパーミッション)
インストール時ではなく、利用時に許可を求める
チェックや許可要求、結果受け取りは作ってやる必要有り
→公式やサンプル参照
許可を与えても後から変更が可能
新パーミッションモデルの特徴
 インストール時には変更可能なパーミッションは
許可されていない状態
インストール時
新パーミッションモデルの特徴
連絡帳の読取
利用時
 「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可す
る
新パーミッションモデルの特徴
連絡帳の読取
利用時
 「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可す
る
 設定画面からも変更可能で与えていた許可を
取り消したり、要求がなくても許可を与える
ことが出来る
新パーミッションモデルの特徴
連絡帳の読取
利用時
 「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可す
る
 設定画面からも変更可能で与えていた許可を
取り消したり、要求がなくても許可を与える
ことが出来る
 許可がないまま機能を使おうとすると、
「Permission Denied」として強制終了する
(パーミッション無いから当たり前)
アプリの動作に対する
ユーザーの決定権が大きくなった
懸念点
変更可能なパーミッションは
グループ単位で設定される
グループ単位での設定変更
 パーミッションの設定変更は、AndroidManifestで宣
言されているグループ内のパーミッション全てに対し
て一律に行われる
 設定画面からの変更でも、requestPermissionsによる
アプリからの要求でも同じ。要求は引数にパーミッ
ションを一つ指定すれば、グループ全体に影響が及ぶ
<use-permission android:name=“android.permission. READ_CONTACTS”>
<use-permission android:name=“android.permission. WRITE_CONTACTS”>AndroidManifestでの宣言
<pkg name="com.sample.sample">
<item name="android.permission. READ_CONTACTS" granted="true" flags="0" />
<item name="android.permission. WRITE_CONTACTS" granted="true" flags="0" />
</pkg>
パーミッションの許可状況
/data/system/user/{userId}/runtime-permissions.xml
requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
REQUEST_READ_CONTACTS);アプリ内でのパーミッション要求
パーミッションがグループ単位で
設定変更されることによる問題
1. 許可済パーミッションと
ユーザー認識のずれ
2. グループ全体で
要求ダイアログが表示されない
許可済パーミッションと
ユーザー認識のずれ(1/3)
パーミッション グループ パーミッション
android.permission-group.CONTACTS android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.READ_PROFILE
android.permission.WRITE_PROFILE
コミュニケーション系アプリで以下の機能を想定
A) 既存ユーザを探すために、連絡帳の情報を利用
要:android.permission.READ_CONTACTS
B) サービス上のユーザを連絡帳に追加
要:android.permission.WRITE_CONTACTS
いずれもandroid.permission-group.CONTACTSに所属
③パーミッショングループへの許可要求
「連絡帳の情報を使ってユーザーを探す
には、「連絡帳へのアクセス」を許可す
る必要があります。」
許可済パーミッションと
ユーザー認識のずれ(2/3)
ユーザは機能Aだけ許可したつもりでも、機能Bも許可される
①機能A利用の要求
④パーミッショングループへの許可 ⑤パーミッショングループ
への許可の付与
②パーミッションチェック
(READ_CONTACTS)
ユーザ アプリ・端末
⑥機能Aの利用
ここでREAD_CONTACTSだけでなく、
WRITE_CONTACTSにも許可が与えられる
③パーミッショングループへの許可要求
「連絡帳の情報を使ってユーザーを探す
には、「連絡帳へのアクセス」を許可す
る必要があります。」
許可済パーミッションと
ユーザー認識のずれ(2/3)
ユーザは機能Aだけ許可したつもりでも、機能Bも許可される
①機能A利用の要求
④パーミッショングループへの許可 ⑤パーミッショングループ
への許可の付与
②パーミッションチェック
(READ_CONTACTS)
ユーザ アプリ・端末
⑥機能Aの利用
⑦機能B利用の要求
⑧パーミッションチェック
(WRITE_CONTACTS)
⑨機能Bの利用
ここでREAD_CONTACTSだけでなく、
WRITE_CONTACTSにも許可が与えられる
許可済パーミッションと
ユーザー認識のずれ(3/3)
 「要求された箇所の機能を使うためにパーミッションが
必要」という説明だけではなく、「パーミッション(グ
ループ)を許可することによる、アプリ全体への影響」
の説明も必要かも
 公式のベストプラクティスのように、チュートリアルを
設ける手もあるが、全てをその中ではカバーできない。
グループ全体で要求ダイアログ
が表示されない(1/2)
 requestPermissionsでパーミッション要求を
行った際に、「今後は確認しない」に
チェックして「許可しない」を選ぶと、
次回以降ダイアログが表示されなくなる。
 「今後は確認しない」とした箇所だけではなく、同一
パーミッショングループ全体が同じ設定になる。
 各パーミッションの状態を、「flags」で管理しており、
この値もグループ単位で設定するため(「今後は確認し
ない」はflags=2)
<pkg name="com.sample.sample">
<item name=" android.permission. READ_CONTACTS" granted=“false" flags=“2" />
<item name=" android.permission. WRITE_CONTACTS" granted=“false" flags=“2" />
</pkg>
パーミッションの許可状況
/data/system/user/{userId}/runtime-permissions.xml
グループ全体で要求ダイアログ
が表示されない(2/2)
 この回避(正確には軽減策)のためには、表示しないと
したときのメッセージの作成や、復活させるための手
順を示したヘルプを設ける
 初めて利用する機能ですでに制限されてしまっている
場合には手順を表示、複数回反応がないのにボタンを
押したらヘルプ表示などのサポートも必要
 このバランスは今後ちょうどよいところを見つけてい
くしかない
まとめ
 AndroidのパーミッションモデルはAndroid Mで新しいモ
デルにとなりユーザーが決定権を持つようになった
 グループ単位での設定となったことによって、うまく説明
しないとユーザーに誤解が生じかねない
 問題は仕組み上、根本的に解決する方法がない。説明や補
助的な機能を作り、誤解を生じないようにするしかない。
分量のバランスはユーザーからのレスポンスをよく見てや
る必要がある。
 パーミッショングループのまとまりがiOSのプライバシー
設定と似ているものは、そのときの対応も参考に。
本資料の著作権は、講演者(塩田 明弘)に帰属します。

Android Mのruntime-permissionに潜む罠