idcon12レポート

idcon12に行ってきました。
今回はプライバシー特集のような感じでしたね。

• イベントリンク: https://www.facebook.com/events/339714289414033/
• http://togetter.com/li/284269

間違い指摘、ツッコミなどお願いします。

(18:42)

on Data Privacy, EU, USA, ... and Japan

• 高間さん @gohsuket
• slideshare.net/gohsuket
• http://www.slideshare.net/gohsuket/eu-12299533

• 最近プライバシー情報が話題に
  • 東洋経済のFB特集
  • 週刊ダイヤモンド

• Gohsuket: Meta Associates: コンサルティング

• EU vs. USA: Data Privacy -- harmonize or conflict?
  • 1/25 EU General Data Protection Regulation改正案
  • 2/23 米 Consumer Privacy Bill of Rights
  • データプライバシー → お風呂場をのぞかれるのは対象外
  • EUと米国とでやり方が全然違うので緊張関係がずっとある → 新しいページに

• • 1/25 EU General Data Protection Regulation改正案 → 「総合データ保護規則」という訳を当てた
    • いままではデータ保護指令に国ごとに法律を乗せて使っていた
    • 今回はEU全体の整合取る方向に動いている
  • 2/23 米 Consumer Privacy Bill of Rights (消費者プライバシー権利章典)
    • オバマ政権が発表
  • 3/19 EUとアメリカが協議、Safe Harbor合意の方向で共同声明

• どこが違うのか?

• 歴史のふりかえり
  • 70年代: メインフレーム: 集めるのは大企業 → OECDプライバシーガイドライン
  • 80年代: PC + スーパーコンピュータ: 処理能力↑
  • 90年代: PC + インターネット + データセンター → EUデータ保護指令
  • 2010: モバイル、ソーシャル、クラウド、ビッグデータ → EU GDPR, US CPBR
  • USは包括的な法制はないが個別法をたくさん作っていた
    • 通信販売→消費者保護、児童オンラインプライバシー、健康保険可搬性(HIPAA)

• 考え方の違い
  • EU: プライバシーは人権である(ECHR)
    • 国ごとに少しずつ違う → 食い違いができる
    • データ監督機関(DPA)を国ごとに作っている(ドイツは市単位)
  • US: 合衆国憲法の修正4条など → 個人の自衛権の延長
    • レンタルビデオ屋の履歴をピンポイントで扱う法律がある、など、ピンポイント型多数
    • DPAはないがFTCによる消費者プライバシー保護活動 → FTCが訴訟を起こす(実弾を持たせる)

• 日本は?
  • 個人情報保護法の上に省庁ガイドラインや自治体条例
  • 日本ではプライバシーの権利は規定されていない(暗黙の前提なので通常論じられない)
    • 憲法25条が絡むのでは
  • DPAもFTCも相当機関がない
    • EUから見ると日本は十分な保護があるとは見なされていない

• これからはSafe Harbor合意で整合持ってやっていく
  • EU: データ保護役員会
    • より強い執行力
  • US: CPBR
    • 章典は法律ではない → これから法側化

• 気にしておいた方がいいところ
  • 何が個人情報、個人データに当たるか?
  • US: personal data, any data, aggregationしたりlinkできるものなんでも
  • EU: personal data ::= 個人が直接or間接に特定できるすべてのデータ
  • 日本では名前が、電話番号が、とかひとつずつ議論しがちだが、EU/USは全部ひっくるめて考えている

• 3次元プライバシー測定基準 カナダ Peter Hope-Tindall, 2002
  • identity/linkability/observability

(19:04)

WebIntentsでConnect Discovery @nov

• http://www.slideshare.net/matake/openid-connect-via-webintents
• HTML5にWebIntentsというのがある: 別のサイトに対してリンクをシェアする、など
  • これを使ってOpenIDのDiscoveryをする
• Discoveryの問題: XAuth, BrowserID, Account chooser
  • 外部のJSを読み込んだりと、けわしい道を行っている
  • 個人的にはHTML5の中に仕様を入れるのがアリなんじゃん?
• Discovery on SmartPhone
  • iOS: Custom Schema Delegation
  • Android: android.content.Intent Class
  • 仕様を書いているのはGoogleの人ばっかりなのでAndroidからスタートすることが多い
• WebIntents
  • delegatee側サイトがHTMLヘッダにintentタグを書く
    • action: URIを名前として使う。ここに情報がたまっていく
    • type: コンテンツのタイプ
    • href: どこに送るか
  • ブラウザがサイトを訪れたときに、このサイトはこういうサービスを受けているが登録するか?
  • delegator側JS
    • intent = new Intent(action, type, uri)
    • windew.navigator.startActivityに渡すと起動 → ユーザー確認
  • delegatee
    • shareしたい情報をポストする
  • delegator
    • shareされたものが処理される
• http://webintents.org
• これをOpenID Connect Discoveryに使いたい
  • OPがdelegatee、RPがdelegatorとなる
  • OPを開くとブラウザ内にintentが仕込まれる
  • RPでIntenetをさがすと、ブラウザが持っているOPにつながる
• 標準化
  • intentタグの書き方
    • actionの指定方法、ディスカバリメソッド
  • JSONを渡すときの形式、ポスト先など
• nat: とっととやろう。5月のIIWで検討
  • nov: intent入ってるブラウザないです。chrome → ウェブストアに行きたそう
  • lef: firefoxに入っているが相互接続性はまだ
• Q&A
  • lef: JSON返す、エンドポイントもいっしょにする、は標準化の過程で可能かも
    • nov: 通常のintentは何アクションかユーザーインタラクションが入るユースケースである
      • エンドポイントを分けるか、ヘッダでハンドリングを分けるか、それをConnect側で登録した方がいいだろう
  • ひろみつ: 悪意ある使い方、実装が悪いと変なことになりそうな予感はあるか?
    • nov: セキュリティーの検討がまだあまり行われていない。intentを書いているアプリが本当にそれをやるかもわからない。intentのポスト先がintentタグを書いたサイトと同じかどうかもわからない
    • ひろみつ: アプリの場合はアプリを入れた人の責任ということが言える。これだとWebなので訪れただけで登録されちゃう
    • nov: ユーザー確認ダイアログが入る予定になっている
    • ひろみつ: 大量にどんどん登録しちゃうなどが考えられるか。確認が入れば、それはそれで不便なUIになってしまう

(19:26)

FB iOS SDKでSSOしてるアプリにアタックかけてみる @nov

• 前回のritouさんの話で: Implicit Flowが認証に使うと脆弱……という話が
• 今日は実際にやってみましょう
• iOSをアタックするアプリ作ってみた
  • FBのiOS SDKがオフィシャルアプリに対してカスタムスキームで渡すようになっている
    • それを乗っとって、別のアクセストークン(被害者のもの)を返してやる
• foursquareもpinterestも被害者としてログインできてしまう
  • 悪いアプリ作者がいて、ユーザーにログインしてもらう
  • → FBのアクセストークンを抜いて、アプリに仕込む → 悪さができる
• ひろみつ: 悪いのは誰? FB SDKの提供者?
  • nov: y
• FB側がSDKを直してくれると拡散は防げる
  • SDKを使う側が工夫をすれば防止できるが、加害者側が古い(buggyな)SDKのアプリを持っている限り悪用はされてしまう
  • サーバー側で問題のあるSDKを使ったアプリをFBが蹴るようにしないとダメ
  • 悪意のないアプリ提供者・ユーザーを巻き込んだ形でしか対応ができない → 難しい判断になるだろう
• FBの情報がばれるのと、FBのトークンで4sqのプロフィールがばれることの問題の違いがなかなか理解してもらえない
• nat: そもそもimplicitが役に立つ場面はあるのか?
  • nov: クライアント上にnativeで完結しているゲームなどなら、サーバーサイドを持たない場合もある。そういうシナリオでは有効ではないか

(19:45)

番号制度について、どうなっているのか @HiromitsuTakagi

• 背景(1): 法案が提出された(マイナンバー法案)
  • 用語
    • 個人番号: マイナンバー
    • 特定個人情報: 個人番号を内容に含む個人情報 → きびしく規制しよう
      • 注目すべきは、ハッシュしても個人番号ですよー、と認められた → セキュリティーの方々ががんばった成果
      • 個人番号が単体で存在する場合も含むという意図だったが、表現はそうなっていない → どこに書いてある? → 法律の名前がそうだ
    • 個人番号情報保護委員会
• 背景(2): プライバシー保護に資する規定
  • 利用範囲を金銭情報に限定
  • 目的外利用、収集、提供の禁止(直罰規定あり)
  • 何人も他に対し個人番号の提供を求めてはならない(住民票コードと同じ)
    • かるい気持ちでレンタルビデオ屋が集めてしまう(悪意がなくても) → 流出 → 被害というのを念頭に置いている
    • たまたまひとりがやるだけなら大した問題ではない。みんながやり出すと困る
  • 個人番号で本人確認してはならない
    • 反対派が「なりすましに使われる」と言ってUSのsocial security numberを引き合いに出した → 使えなきゃいいじゃん、ということで入れた
    • 氏名と番号だけあればいいように素人が考えてしまうので、法律に入れた → 住民票コードには入っていなかった規定
    • 今回は納税者番号としてのIDなので、パスワードの機能はない
• 背景(3): 情報連携基盤のアーキテクチャは未決定
  • リンクコードに関する規定は外された ← 回りの人がいろいろ言ったんだろう
  • 民主党が案を出すことになっている
  • 情報連携基盤の名前 → 「情報提供ネットワークシステム」になった(余計ヤバイ感じの名前)
  • 所管は総務省: 総務省は情報保有機関とはならない
• 趣旨
  • 経済同友会の提言(3/21): いまさら何か言ってきた
  • リンクコードいらないんじゃね? 初期突合のコストは無駄では?
• リンクコードの存在意義
  • 国家による一元管理の回避とプライバシー保護
    • 結託してもマッチングができないように
    • しかし、同一のマイナンバーでマッチングできるじゃん
    • 使用目的を金銭に限定したので一元管理にはならない
  • 漏洩対策のため?
    • リンクコードを使っても番号を使うのと比べてセキュリティーで守れる範囲は変わらない?
    • 脅威の想定による
• 現状
  • 昨年7月の中間とりまとめ以降検討がストップしている
  • 昨年4月の山口英委員の質問に答えていない
• 高木案(案6: 分野別番号)
  • マイナンバーと住民票コードだけだと印象が悪い
  • 将来、便利だから何にでも使おう、となってしまう
  • → そうならないために、他の分野番号を想定した変換を示しておく
• 案7(崎村案)
  • リンクコードを使い、マイナンバーを(保管せず)すぐすてる
  • 「リンクコードが役に立つのはどういう場合か」と考えたときの答のひとつ
  • 会社が納税のために社員のマイナンバーを得る → 集めると漏洩リスク、内部犯行など心配でやりたくない
  • 故意は防げないが過失に対しては有効
• ハイブリッド案
  • 医療のために病院同士で連携すれば十分なのにいちいち国の情報連携基盤を通すのはなんかおかしい
  • 医療連携サブ基盤を作ればいいじゃん
    • 保険証に医療番号が書いてある → 符号を振り出し、診察券に符号を書いておく、以降符号だけで
• 論点
  • リンクコードって費用かかるの?
    • 大したコストじゃないと言う人もいる
  • 漏洩対策として意味ないんじゃね?
    • 連携基盤の内部犯行に対しては強いのでは? → リンクコードで要求すればデータが返ってくるからダメじゃん
• oiwa: 保護対象が個人番号か特定個人番号か、各条文がどっちで書いてあるか。特定個人番号と書いてあればハッシュを含むが、個人番号だったら含まない
  • hiromitsu: 間接罰は「何人も他人の…」、個人番号について言っている、法律の名称だから論がここにかかってくる
    • よく考え直した方がいい
• 日本の将来をずっと引くので、変なシステムだと困ってしまう
  • nat: ずっともうかる! (笑)
• oiwa: 身体情報はいつ金銭情報になるのか → どこかで変換 → すべての医療transactionが連携基盤を通らないといけないの?
  • hiromitsu: 企業が社員のマイナンバーを扱うことはさけられそうにない。右から左へ番号を流すように仕組ができれば、医療番号についても同じ。マッチングを行う悪い企業があったとしても、その企業内部だけの問題ですむのでは? → う〜ん
  • oiwa: 処方せんの時点では金銭情報なので、各病院がマイナンバーと医療番号のペアを持つことになる。
    • さもなくば処方せん発行の度に情報連携基盤まで直接にしろ間接にしろtransactionが行くので、ものすごい数になる。行政の比じゃない
    • 金銭情報の保険請求をペアにして考えないと難しい。複数の番号・バリデーションが絡んでくる(交通事故とか)
      • いまは電話で番号を言っている: 紙で回っているから間に合う
  • oiwa: ハイブリッド案は実はサブ基盤を分ける意味がないのではという指摘
• 案7: 紙で税金を扱う企業もある → 個人でリンクコード取ればいいじゃん
  • → 紙で扱う以上、トークンにならざるを得ない(signed tokenにできない)
  • → 紙とマッチングされるまで保存しないといけない
  • 問題: 紙を扱っている中小企業の方が圧倒的に多い

(20:34)

エンジニアのためのプライバシー入門 @_nat

• ISO 29100にpersonally identifiable informationの定義がある
  • 本人を識別し得る情報
  • 直接・間接にリンクできる情報
• identityとは何か?
  • 相手との関係性(context)において「〜としての自分」「〜として見られたい自分」どんな属性を出したいか
• contextが混同されるとマズイことがある
• プライバシーの尊重とはある人が保とうとしているcontextの尊重
• あるデータがプライバシー情報か否かは、データの種類ではなく、その開示・共有されたcontextによって規定される
  • 機微情報主義: 保護されるべきは情報の種類で決まる
  • コンテキスト主義: 保護されるべきは人間の尊厳
• 本人の望まない名寄せ → コンテキストを越えた名寄せ
• 「ああ無情」ビクトルユーゴーに例えた例
  • ジャンバルジャン: 昔の悪事で失墜
  • ジャヴェル警視の超能力: 何十年たっても絶対に忘れない。超人的な探索力
    • インターネットの特性そのもの
• USのSSNの2つの問題
  • 小さい問題: 一意性のある番号が広く知られてしまった
  • 大きな問題: 認証に使われている
  • 広く知られていない一意性のある番号がまだないならば作らないにこしたことはない
• 個人情報保護 vs プライバシー保護
  • 箱の中に入れて出さない vs コントロールする(混ぜるな危険)
  • 秘するもの vs 御するもの
• プライバシー侵害の事例いろいろ
  • AKB48やめちゃった娘: twitterの鍵アカ → twitpicはプライベート設定にはならない → 特定
  • フジTV職員炎上の話: 車のボンネットに映った回りの景色からバレてしまった
    • 2ちゃん住民は自分達がプライバシー侵害の加害者になっていると気づかずに名寄せを行った
  • ミログ
  • PASMO
• プライバシー脅威分析とコントロールの枠組み
  • カバレージの広いチェックリストがほしいのではないか?
  • Deng, et al, "A privacy threat analysis framework 〜", Requirements Engineering - Special Issue, Vol 16 Issue 1, March 2011, Springer-Verlag New York
    • 「LINDDUN methodology」でぐぐれ

(21:00終了)