Hatena::ブログ(Diary)

mad-pの日記 Twitter

2013-01-19

CROSS 2013レポート(3)

CROSS 2013レポートパート3です。malaさんのセッション

間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。

安全な利用規約の作り方

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

ここでPCが電池切れとなったので、自分のツイートから発掘

  • M: 「個人を特定できる情報ではありません」と書くより、「そういう用途には使いません」と書いてくれたほうが、ぼくは安心だけど、人によっては逆なのかな
  • M: 解釈にブレが残るようにしておいて、いざとなったらそこを使うみたいな利用規約のありようは、いいのか悪いのかわからない
  • T: 利用規約改定ごとに炎上するのはナンセンス。悪いことするつもりなら黙ってやる
  • M: 正直者がたたかれている状況。炎上をあおってる人がいる。技術者としての普通のセンスではありえないことでも、あおりに乗ってキケンキケンと叫んだりするのよくない
感想

80分でスライド230枚という超ペースだったため、そして美味しいプレモルが程よく効いてて、セッション中に内容をツイートするのは無理ゲーでしたね。

利用規約というお題でしたけど、語られていたことは技術者の考えと利用者の考えの間にあるギャップをいかに小さくするか、ということでした。企業では利用規約は企画担当の人が書いたり、法務の人が書いたりしているのだろうと思いますが、もっともっと技術者が関わっていける部分があるだろうというmalaさんの主張には深くうなづきました。

利用規約改定で炎上すると、ついアオる側に回ってRTとかしてしまいますが、技術者の態度ではなかったなーと反省します。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/mad-p/20130119/1358577013