CROSS 2013レポート(3)
CROSS 2013レポートパート3です。malaさんのセッション
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
安全な利用規約の作り方
- http://www.cross-party.com/programs/?p=131
- @bulkneets(mala) NHN ライブドア方面
なぜ利用規約
- エンジニア方面の話をします
- 炎上したり、海外だといきなり訴訟
- 利用規約やプライバシーポリシーの無理やりな解釈
- 個人がさわぐ → メディアとりあげる → 取材に応じる前に広まる
- そんなつもりじゃないのに炎上する
- 作る側、使う側の視点から
- 無理やりなイチャモンでサービスの印象を落とすのは本意ではない
- 本当にヤバイものがわからなくなってしまう
- 利用規約が「評判リスク」であると扱われてしまう
- エンジニアができそうなこといろいろあるんじゃないの
- 「利用規約はgithubに置け」
- やってるのはtumblrくらい
- 変更履歴 〜 ユーザーに不利な変更などもわかる
- 普通の企業の法務はぜったいにやらない → エンジニア発想
前提知識
- 個人情報保護法
- 種類・利用目的
- 特定電子メール法: オプトイン
- プロバイダ責任制限法
- 不正アクセス禁止法
- あずかったパスワードを別目的で使ってはいけない
- 不正指令電磁的記録に関する罪
- 「意図に反する動作」+「故意」=ユーザーをだましてやるという意志が必要
- 例: HDDフォーマットツール
- だまして実行させることを意図して配布すると有罪
- バグ → 意図がないので罰されない
- じゃあ、利用規約のバグは?
- ソフトウエアの挙動と利用規約の説明がくい違う場合がある
- ユーザーが「そんな動作をするとは思わなかった」「だまされた」と主張するかも
- バグは処罰されないはずだが、「本当にバグなのか」
- 絶対にユーザーの意図に反することがない ← 幻想
- どうすればいいのか
- 解釈のぶれの範囲がプログラムの挙動と一致するように
- 心理学などが必要。人間は仕様書どおりに動いてくれない
- アプリの実行環境
- permissionモデルの欠陥
- アドレス帳使います、ネット使います → 送信するかどうかわからない
- Adobe Air → ネットとローカルは排他だった
- → いまは現実的ではない。ネットのないアプリなんか考えられない
- スマホアプリ → webアプリのfront endにすぎない
- サーバーのコードとローカルのアプリの組ではじめて仕事になる
- コードを見せたくない人 → 解析されずに動作が制限される仕組みが必要
- 逆にコードを見せてもかまわない人は見せればいい
- 法律面の変化
- 不正指令電磁的記録
- 今まさにソフトウエアの信頼を技術的に担保しようとしている時期に出た
- ユーザー側に害を与えるのは多くはサーバー側
- 不正指令電磁的記録
- 残念な運用
- どうしてこうなった
- ガチのマルウエア作者はつかまらない
- 完全匿名
- backorifice → 正当な目的もあるので堂々と配布されてる
- プログラムの信頼 != サービス全体の信用
- 実際のサービスの信頼が必要
- 社員が信頼できるのか
- 法だけが規制ではない
- 法律による規制はどうせ無法者には役に立たない
- アーキテクチャによる規制・技術的に悪用できない仕組みが必要
- 市場原理 → 悪用することによる利益よりも、バレたときの不利益を大きくする
- 取得できる情報は様々、確認ダイアログがあったりなかったり
- ブラウザ履歴、アプリ一覧、プラグイン一覧など
- フォント一覧は描画してみればわかる → どんな年賀状ソフトが入ってるかわかる
- iOS
- canOpenURLでカスタムスキーム登録状況がわかっちゃう
- 自分の電話番号は公式には取れない → アドレス帳から推測
- Android
- アプリ一覧は誰でも取れる(package一覧)
- 保護されるべき情報とそうでない情報
- 境界は曖昧
- 実行環境によって多種多様
- CSSのvisited linkの取得問題
- 訪問済みリンクの色でわかっちゃう
- プライバシー侵害の問題が正当な利用より大きく評価された
- 取れちゃマズイ情報 → ユーザー許可
- 現状、許可なく取れる情報は使っていいの? → 判断が難しい状況
- 画面の解像度とか
- アドバイス
- 情報の質、ユーザーリスク、悪用・漏洩した場合の被害規模を考える
事例
- スクエニの会員制サービス
- 本サービスへの不満を流布する行為を禁止
- 他サービスでも「その他当社が不適切と判断する行為」があるから、スクエニの方が正直
- 元々、解釈次第でなんとでもできる → エンジニア視点ではバグのようなもの → 運用でうまく
- googleの通話履歴利用問題
- Instagramの例
- 写真を売るはずはないのだが
- ビジネスモデルに無理解だと、無料サービスだから個人情報売ってると誤解される
- 典型的な間違い
- 売ってしまったら継続的に利益が出ないので、そんなサービス作るはずはない
- 使う権利を売っている
- ビジネスモデルの知識欠如、無理解から、「悪いことしてるんじゃないか」という憶測が生まれる → 根拠のないまま流布される
ケーススタディ 〜 よい事例
- Mozilla
- 潜在的個人情報: 単体では個人を特定できないが他の情報と組み合わせると特定できるもの
- 収集している情報は後天的に個人を特定できる情報となり得る
- 「個人情報ではありません」という間違った表示をして回避しようとしてしまう
- Siri: リンクしないポリシー
- URLにはsensitiveな情報が含まれることが多い
- 個人情報かどうかってはっきり決まるものではない
- 個人情報です → 取扱いに制約
- 個人情報ではありません → うそになってしまう
- アドバイス
- 楽天の生メールアドレスをショップに渡すかどうか問題
- 委託 → 楽天に監督義務
- 提供 → 義務はない
- 「業務に必要な範囲」かどうかすぐにはわからない
- そもそもメアドって個人情報?
- 総務省: 組織名、個人名が入ってない記号は違う → えええぇ?
- アドバイス
- ユーザーがコントロールを失うタイミングで警告するのがよい
- 誤解を招きそうなときは別途補足すべき
- 暗号化・ハッシュ化
- 通信経路だけなのか、保存状態なのか。社員でも復号でなくなっているのか
- Dropboxの例
- 技術的に不可能なのか、就業規約としてダメなのかがわからない
- 著作権管理
- リンク
- 電話番号自体はひみつじゃない。「誰が持っているか」が秘密の情報
- メアドも
- 公開/非公開の中間状態があるだろう
- googleの予備のメールアドレス
- 予備のメールアドレスでプロフィール検索できる
- パスワード再発行専用で非公開のものと区別される
- FBのソーシャルグラフ
- ユーザーが許可しても、アプリ外にexportは禁止
- livedoor.comの画像
- クッキーからセッション見ると、Web行動履歴を取ることはできる
- だけど静的情報なのにわざわざセッションデータベース見たりしないよ
- google+
- +1ボタンのポリシー: 統計には使えると表示
- やらないことを明示しているにもかかわらず炎上
まとめ
- サービス提供側とユーザー側の認識のギャップが無視できない
- 経営者、法務、技術者の利解も違っている
- リスクマネジメント → 悪循環
- 透明性確保
徳丸さんとの対談
ここでPCが電池切れとなったので、自分のツイートから発掘
