Android Bazaar and Conference 2012 Spring 参加メモ

スマホアプリの利用者情報送信における同意確認のあり方(産業技術総合研究所 情報セキュリティ研究センター 高木浩光氏)

  • オプトアウト方式で許されるのは限定的なケース
  • 端末IDは不必要または有害でありそもそも使わないべき
  • Permission機構では同意にならない
  • オプトイン方式にもいろいろある

背景:ウェブからスマホアプリへ

  • ウェブ
    • セキュリティ制約による厳しい機能制限
      • 収集できるのは利用者が自発的に入力した情報に限られる
      • 端末ID的な機能(super cookie)は徹底排除されている
    • 少数のブラウザベンダにより事実上の標準が確立していた
    • しかし利便性に限界
  • スマホアプリ
    • 中間的な緩さの機能制限

個々のアプリ提供者の裁量 → 新しい問題が発生

Permission確認方式の限界

  • PermissionはJavaの基本機能
  • 使用と送信の許可が独立
    • 「送信しない使用」と「送信する使用」を区別できない
    • 各情報の送信に同意したことにはならない
  • 機械式の同意確認には無理がある
  • アプリ提供者による同意確認のための仕掛けが必要

同意確認のレベル

  • 強制オプトイン(仮称)
    • 同意しなければ一切の利用ができない
  • 包括的選択オプトイン(仮称)
    • アプリ全体に対して起動時に同意を求め、拒否しても利用ができる
  • 個別的選択オプトイン(仮称)
    • アプリ使用中に当該機能を使用する段になって同意を求める
  • オプトアウト方式
  • 黙示の同意(仮称)

基本的な考え方

  • 利用者の意図に反した動作にならないようにする
  • 歴史的経緯(国際的な)を踏まえる
  • サービス実現のための技術的必然性があるか
  • 取得情報の範囲が利用者の想定し得る範囲内か
  • 情報元の種類による個別の判断

IDの匿名性レベル

  • アプリ間で共通で使用されるID(グローバルID)
  • 三者cookieスマホアプリでは現状使用できない)
  • アプリにローカルなID(第一者cookie相当)

オプトインを必要としないケース

  • 黙示の同意がある
    • 利用者の自発的な入力情報送信はそれ自体が同意によるもの
    • ウェブのブラウザが自動送信するのと等価な情報の自動送信
    • etc.
  • オプトアウトで許容される

端末IDは使用しない

  • そもそも不必要
    • アプリにローカルなIDを使用すれば済む場合が多い
  • 複数アカウント登録防止用としても有効に機能しない
    • 端末IDの偽装(すり替え)を防ぐことは原理的に不可能
  • なりすましを許すセキュリティ脆弱性となる
    • 端末IDで利用者識別をしている場合、他人の端末IDの送信で、その人になりすまして操作できてしまう欠陥となる

ADB(Android Debug Bridge):How it works?(京都マイクロコンピュータ株式会社 小林哲之氏)

3 elements of ADB

  • adb client
  • adb server
    • act as proxy between adb clients and adbd
  • adb daemon (adbd)

2 roles of ADB

  • Providing "Transport"
    • communication path between host and target device
  • Providing "Services"
    • executing something on the target devices through the transport

When does adb server start?

  • Explicitly, adb start-server
  • コマンド実行時に adb server がいなければ起動される
  • When you want to restart adb server, do "adb kill-server".

ADB internal

  • system/core/adb in Android source tree
    • 16000 lines in *.[ch]
  • adbd と adb で共通で使ってるソースもある

adb in Android Device

  • Android4.0以降ではAndroidバイスの中でもadbが動くようになった


検証、SEAndroid(矢倉大夢氏)

SEAndroidとは?

SELinuxとは?

  • National Security Agencyが作成
  • 代表的なLinix Security Module

SELinuxの基本

  • 従来のアクセス制御
  • SELinuxによる強制アクセス制御
    • もっと詳細なラベルで制御
  • カーネルに組み込まれている
    • root権限に対して制御可能
  • 他のプロセスへの干渉を止められる
    • 別プロセスの脆弱性が使用しにくい

できること

  • アプリによる権限昇格、データ漏えいの防止
  • データの強制アクセス制御による保護

SEAndroidの実装

  • カーネルレイヤー
    • yaffs2へのラベルシステムの追加
    • IPCシステムへのパーミshソン
  • ユーザーランド

速度

  • I/Oが少し遅い
  • rootは奪取できたがsuやbusyboxは書き込めない

SEAndroidの利点

  • root奪取されても問題ない
    • suなどンストールできない
    • 他のアプリケーションに干渉できない
  • そもそもAndroid脆弱性が利用しにくい

結論

  • SEAndroidは堅牢なAndroidシステムを作る上で有効
    • ただしコンテキストをきちんと設定しておく必要はある
  • まだ実用レベルではない
    • SELinux JNI APIは実装途中
    • Zygote(Dalvik VMの管理プロセス)がSEAndroidのコンテキストを読みにいってSEGVする
  • AOSPのMain StreamにMergeされてから使うくらいがいいかもしれない


点と線 - AndrobookとAmeroadが線になるとき(株式会社クレージーワークス代表取締役総裁 村上福之氏)

About Androbok

  • マネタイズは大事
    • Apkをユーザが生成 → マネタイズ不可
    • 日本はイグジット価格が安い
  • コンテンツは基本無料
  • 風呂敷は広げる
  • マネタイズは大事だけど大事じゃない
  • 人との出会いの方が大事

だいじなこと

  • やばいかなってサービスでもエンジニアは作るべき
  • 世に必要とされるサービスなら、誰か助けてくれたり、譲渡してくれたり、買ってくれたりします
  • 働くのは世のため人のためです
  • 基本、人のためになるものは、どうにかマネタイズできるか、どうにかなります。
  • 時価総額膨れてる中身ないソーシャルアプリは3年後80%消えると思う