Hatena::ブログ(Diary)

mad-pの日記 Twitter

2014-02-19

JICS2014レポート(6) 1/15後編 ジェネラルパネル

ジェネラルパネル

ここ5年でクラウドを取りまく環境はどう変わったか
  • 玉川さん
    • 世界的にはAWSは2006年から始まり、ここ5年で大きく成長した。5年前には東京リージョンはなかった
    • 日本にDCがないと日本のお客様には門前払いだった。東京にできてからのスピードは速かった。世界中でも速いほうだった
    • 最初はクックパッドなどインターネット系、5年たったら官公庁、教育機関などが入った
  • 舘野さん
    • 2008年だと物理ベースのDCだった。さくらVPSが2010/10、さくらクラウドが2011/11
    • 今ではクラウド系イベントに呼ばれるまでになった
      • 藤井さん: サーバーメーカー系 → DC系の人がパネルに並ぶ感じ
    • 5年前は自社設計サーバーを売っていた → クラウド化 → サーバーベンダーの売先がDCになった
    • 立ち上げ時毎月 10% の伸び
      • 物理サーバーは増えていない。VPSが圧倒的。専用サーバー1〜2万台、仮想は3年で6万台
  • 宮内さん
    • 法律的、コンプラ的にクラウドに置けるようになった
    • リスク評価が妥当な判断となり得るようになった
Consumerization of IT
  • BYOD、エンプラとコンシューマの垣根、Google Apps、端末もアプリもグローバル
  • 玉川さん: AWSの理由…コンシューマ寄り
    • アマゾンはeコマースだが、多くのお客様に来てもらえるように機能を早く作りたい → サーバーをすぐ入手したいという社内ニーズがあった
    • 作ったら便利だった → 公開
    • 社内ネットから使いたいと要望
      • → 2009年 VPNで仮想閉域網を使う Virtual Private Cloudを開始。いまは使おうとするとVPC内で立つのがデフォルト
    • アマゾンのサーバーとAWSのサーバーどちらが多いか?
      • 誤解: 本屋をやっていて、余ったサーバー資源を売っている
      • amazon.comの全サーバー量(7千億企業だったころ)のサーバー数を毎日追加している
  • 舘野さん
    • 個人向 → 企業向けに採用される
    • 所有と利用は二元論ではない
      • 仮想的に占有
      • 物理サーバーを占有
    • 玉川さん: パブリッククラウドは表で△になっているが、そんなことはない
      • インテルから一般発売前のチップを出してもらって提供していたときもある
  • public/privateクラウドは安全かどうか
  • 宮内さん: まずこの表には安全性が書かれていない(会場笑)
    • 海外に出して大丈夫なのか? NSAとパトリオットactとか
    • 現実には心配ではない。海外の業者に強制執行は大変。EUからもって来るのも大変
    • 国内だと{なくなっちゃう,もらしちゃう}のが心配
      • 実際に発生した(firstserver)
    • 起こったときに保障とれるのか
      • 被害額を算定できない
      • お金をもらうよりもデータを返してほしいという問題も
    • 藤井さん: それってクラウド特有の問題なのか?
      • 玉川さん: あずけている方が楽
        • 耐侵入とか → 第3者認証を示せる
        • アプリ、プラットフォーム → これはお客様にやっていただく
        • デフォルト暗号化がトレンド。http → httpsの流れと似ている
    • 舘野さん: SaaS, BaaSだとデータ置場の所在をコントロールできない場合もある。IaaSだとコントロールできる。
      • 仮想か、物理か、どこからコントロールするか
        • 昔: 企業 ----(FW)---- インターネット
        • 今: 企業 ∵∴(??)∵∴ クラウド
      • IDの果たせる役割
        • アナリストによると、ID管理、アクセス管理がキーになる。SNSがドライバに
クラウド時代のIDとは
  • IDの囲い込みの流れ → 今後のID
  • 宮内さん: ID連携: 認証の連携 + データの連携
    • 囲い込んだとき、私のデータはどのように集約されるのか?
    • IDについている属性、履歴をどう管理するのか?
    • 多くのユーザーは消費者である(つまりよくわかっていない)
    • → わかってコントロールできるようにする/なってもらう必要がある
      • 白紙委任状のような形で渡すのではなく、真摯な同意が必要
      • 例: 2chとニコニコのIDを名寄せされたくないよね
  • 玉川さん: 利用者側が知識をつけていかないとリスクが高い
    • 米国でよくある、買収によってIDが名寄せされる事態
    • 各サービスにそれぞれIDを入れるのは大変
      • FB, Amazon, Googleの各IDと連携する機能を用意した
    • 今後: ID連携 → 便利 ≒ リスク となるだろう。勉強すべき
  • 宮内さん
    • 訪問販売法には「クーリングオフは大きく」という考え方がある。同様なルールが必要ではないか
    • IDが新たな境界線になれるのか → テクノロジーの出番
    • IoTを考えると、「人でないID」というものも出てくる

エンディング

  • 総括 from 中村さん
  • JICSは去年から始めて2回目。NII + 学認
    • 去年: いかに世界は進んでいるか(日本は遅れているか)を知ってもらいたかった
    • 今年: 導入部分を手厚くした
    • のべ1200人以上が参加/2日間
  • 動向 from 崎村さん
    • 今年を占うキーワード
      • 「Password is Dead!」 リスト型攻撃
      • 「Personal Data」 2014/6 個人情報保護法大綱にパブコメを出そう

2014-02-17

Cross 2014メモ(1) 現場に聞くパネル

2014/01/17にベルサール新宿グランド行われた、Cross 2014に行ってきました。当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。

現場に聞く!テスト/CI/DevOps、実際のところどうなの

参加者
  • 直也さん @naoya_ito
  • 石橋さん @iandeth
    • KAIZENプラットフォーム 調整さんを作った人
    • 調整さん知名度高い
  • 舘野さん @hotchpotch
  • 伏井さん @hakobe
    • はてな アプリケーションエンジニア
テーマ
Github, プルリク
  • 直也さん: github+プルリク開発のブログ記事を書いたときは、決して「最新の」とは言わなかったが、いろんな反論があった。「そんなツールあるのか」「そんなのあたりまえ」など
  • 舘野さん: コードレビューはツールも使っていたが、ツールの生産性が低く、コードレビューのコストが高すぎた。2012年頭くらいからgithubを使った業務フローを考えてみた。プルリク→マージ→CIをやってみようという感じ
  • 舘野さん: 入社して1年くらいはgithubがなく、review boardを使ったりしていたが、コストが高かったのであまりやっていなかった。テストはあった
  • 伏井さん: はてな入社当時、テストはあったがあまり定着していなかった
    • 直也さん: はてなダイヤリーではじめてテストを書いたが、それはちょっと変えるとこわれるからという。はてなダイアリーの大規模改修のときにがんばって書いたが、手元で流すだけで20分かかって大変だった
    • 舘野さん: buildbotなどのCIツールはあったが自分達でやるメリットがあまりわからなかった。書いて2分後にデプロイしたり。あまりバグることもなく、テストの重要性・メリットがわからなかった
    • 伏井さん: はてなブックマークの機能が増えてきたときに、t/以下にテストを全部持っていったり。あんちぽさんが整備してテストやるようになった。ある時期CIがもり上がったときにテストも書こうということになった
    • 直也さん: Webアプリだと「ビルド」という概念がなかったので、「夜間にビルドがこわれないか保証する」という当時のCIの解説はひびかなかった。自分達と関係ないことだと思っていた
    • 石橋さん: コンソールに緑のラインが出ないとテストした気にならないから、Jenkinsとかだとテストしてる気にならなかった
  • 石橋さん: 開発が1人から2〜3人になったときに自動化した。開発チームがさらに大きくなるとCIとかなしではやっていられなくなった
  • 直也さん: CIがあたりまえと思う人と、やらない人のギャップが大きくなっている気がする
    • 舘野さん: やってみないとわからない面がある。文章で読んでもメリットがわからない。
  • 直也さん: 講演会でgithubは21世紀の革命だと言ってもポカーンってなることもあった
    • 伏井さん: gheができがよくてあれ使ってはじめて役に立つ、みたいな感じ
テスト考2014 by えじまさん
  • 直也さん: テスト考2014について。テストを書きすぎると自分の足を撃ってるようなこともあるよね、という話。ユニットテスト書きすぎるとリファクタしにくい、テストが必要というのはいいコードでないなどの指摘
    • 直也さん: yoshioriさんは自分のためのテストと守りのためのテストは違うよねというようなことを言っていた
    • 伏井さん: ひとでくんの意見: DHHがあまりテストを書きすぎるのは意味がないよと言っている → テストは書かなくていいんだという言い訳を与えるのはよくない
    • 伏井さん: はてなではコードの寿命がすごく長い。10年とか。その間に担当の人も移りかわっていったりする。自分の意図が伝わるように、他の人がこわさないようにテストを書いておくという文化
    • 直也さん: ひとでくんは執拗にテストを書くくらいでいい、と言っている。はてな座談会ではテストをテキトーに書いてレビューに出すとひとでくんがおこると言われている
    • 伏井さん: C0カバレージ(すべての行を過去することを保証)くらいはちゃんとしようという基準にしている。本当に問題のあるコードはリリースしたくない。C0は自動で調べるツールがあるので1日に一度くらい流している
    • 石橋さん: C0を100%にするのとテストをたくさん書くのでどれくらい大変になるの? 伏井さん: C0はそんなに大変ではない 直也さん:入力をモックとか使ってやらないといけないよね、それも大変ではない? 伏井さん: やればいい
    • 伏井さん: C0を重視というわけではないが、C0くらいはカンタンだからやろうよねと 舘野さん: C0は重視していなくても、テストがちゃんと意図したテストをしているかどうか判断するのにC0は役立つ
    • 舘野さん: 社の基準としてはテストを書きましょうとしていて、C0全部とは言っていない。コードレビューとテストで言うと、C0はちっとも本質ではない。実装に対して適切なテストを書いているかどうかの方が大事。テストのリファクタリング、テストの構造化はテストが伝えやすいかわかりやすいかをレビューで見るようにしている
  • 伏井さん: はてなでは開発チームごとにツールも違ったりしている。テストをどれくらい書きましょうという考え方もチームごとに違う。C0も一つの基準としてありますよねという程度。このくらいがいいという雰囲気を都度判断している
  • 石橋さん: KAIZENはテストの基準はない。モデル、コントローラも書いてる
    • 舘野さん: webだとend-to-endのテストがカンタンになっているので、それとビジネスロジックユニットテストを書いている 石橋さん: 同意。end-to-endが重要
    • 伏井さん: はてなブログではcasper.jsを使っている
    • 直也さん: end-to-endテストって昔のseleniumの印象があって、すぐこわれる。すごい大変。いまはカンタンに書けるしheadlessになっているしすごくよくなった
    • 舘野さん: Rubyではcapybaraで抽象化されていて、バックエンドは切りかえられるようになっている
    • 石橋さん: 宣言的に書けるのがいい
    • 伏井さん: casper.jsだとボタンクリックの後の変化をsleepで待つなどを明示する必要がない
  • 直也さん: コントローラとかどうすんの?
    • 伏井さん: JSとかあまり関係ないところはPerlで。編集画面などはcasper.jsを使ってなどという感じ
  • 石橋さん: end-to-endはなかなかできていない。KAIZENの特殊なのは、いろんな環境でこのJS貼ってくださいということがあって、クロスブラウザもやっつけられていない
    • 直也さん: browser stackなどもあっていろいろできる
  • 直也さん: テストはみなさんやっていると。ところがstack overflowは面白いこと書いてて、テストはほとんどしないがユーザーが報告してくれる、と言っている。このアプローチもなかなかいいよね
    • 伏井さん: そのへんはバランス。テストでそこそこやって、条件が特殊な部分は組み合わせ爆発とかあるからやらないとか
  • 直也さん: えじまさんの議論は立場が違うところで話している面もある。開発チームが2〜3人のところと20人以上でレガシーもあるようなところだと大変。自社サービスかお客さんからお金をもらっているかによっても違う
    • 直也さん: テスト書きすぎ問題もいろんな反論が来て「3か月で終わりのプロジェクトでそんなにテスト書いても仕様ないだがう」というのもあった。話のコンテキストが違う
  • 石橋さん: マネージメントから倍のコストかかったじゃないか、テストなんかやめろと言われ、戦ったとき、数字で勝ったことはない。頭を下げてやったところ、メンテコストが倍まで行かなくてもよくなって認められた例はあった
テストの環境整備
  • 舘野さん: クックパッドには開発基盤グループがあってテスト環境の整備などをやっている 石橋さん: それいいよね
    • 舘野さん: テストがどんどんやれることによってユーザーに価値を届けることができる。テストそのものでなく速度を上げるとか、Jenkins回ったあとにステージングに自動で上げて本番環境同等のテストができるとか
  • 直也さん: 普通の会社だと顧客要望に応えるのが優先でCIサーバー立てたりという作業がどうしても後回しになってしまう。クックパッドのように組織だってやっているのいうのはひとつのやり方
  • 伏井さん: はてなでは、これはぜったいイイと思ったら実装していいという文化がある
    • 伏井さん: CIでテストが落ちるとIRCで「【悲報】○○ブランチのテストが落ちました」が来たりする。そういうものがイイと思ったら作っていいという文化
  • 直也さん: テストを書かせてくださいと説得してしまうと、次にCIやりたいと思うとまた説得しなくちゃいけない。クックパッドのアプローチはいいと思う 舘野さん: 会社のミッションから立てているのでやりやすい
  • 直也さん: 「テストから見えてくるグーグルのソフトウェア開発」という本に、developer productivityと書いたらテストが定着したという話があった。開発者生産性向上という言葉で考えるといいと思う
    • 舘野さん: 最初にこのままではダメになると思って1人で一気に書いたりしたこともあった。そこから開発者の間にもテストっていいんだということが啓蒙できたと思う
    • 直也さん: 「うちの会議テストやってなくて無理っすよ」という会社もあるけど、ここらへんの会社でもここ2〜3年のことだと思うと、できないことではないんだと思う
    • 直也さん: 最近はツールがよくなっている。ぼくらはコードレビューとか10年前からやっていてもなかなか定着しなかった面がある。いまはいいツールもあるのでやりやすくなっているはず
情報共有
  • 直也さん: 情報共有どうしてますか? はてなはてなグループってのがあって、業務中にブログ書きながら仕事する。社長も書いてる。メールでやりとりすることはほとんどない。誰が何をやっているか検索するとすぐわかる
  • 舘野さん: クックパット入社時はそういうものがなかった。wikiはあったけどこういう風には書いていなかった 直也さん: それでgrouppadってのを作ったんだよね 舘野さん: めっちゃ使われてますよ
  • 舘野さん: WEB+DB vol77に書いている。コミュニケーションが増えちゃってよくないんじゃないのという声が最初はあったが、すごくよくなった
  • 直也さん: こういうのはすごく大事だと思う。wikiにみんな書くんだけど、いつ誰が何を書いたのか伝わってこない。ブログだとアンテナみたいのがついている。社内勉強会で月に1回だと「あそこはJenkins入れたみたいだぞ」が1か月遅れちゃう
  • 直也さん: gree groupも作った
  • 石橋さん: 日報ブームがある。ひとりが書き始めるとみんながやりはじめる 伏井さん: こういうのがあると社内で認められて承認欲求も満たされる。社内ホッテントリもいい 舘野さん・直也さん: うちにもあるよ!
  • 直也さん: CIやるぞテスト書くぞでもいいんだけど、エンジニア間の透明性が十分ないと、局所最適になってしまう

Cross 2014メモ(2) 機械学習パネル、次世代Webセッション

もくじ

機械学習(後編)

参加者
  • 福島さん @fukkyy
  • 油井さん @myui
  • 村上さん @junichi_m
  • 小宮さん @komiya_atsushi
  • 平手さん
  • 田島さん
  • 比戸さん
前半の振り返り
  • ビッグデータブーム、データサイエンティストブームにより、各社横並びになるだろう。次のキーは機械学習
  • パネリスト自己紹介
  • 機械学習「超」入門
自己紹介・事例紹介続き
  • 福島さん @ グノシー
    • ニュースのリコメンドサービスを提供
    • 似たユーザーをさがす、ユーザーのクラスタリング
    • サービスの分析、アルゴリズム選択にも使っている
      • グノシー、twitterのつぶやきからユーザーの性別を推定
    • アダルト記事、炎上記事の検出と回避
    • 最近の研究は次元を増やして人間に解釈できないところへ行きましょうという流れだが、人間に理解可能なモデルでもまだまだやれることがあると思う
  • 比戸 @ PFI Preferred Infrastructure
    • 検索エンジン、レコメンドエンジンを売っている
    • Jubatus: Hadoopの先を行っ大規模データ解析
      • 集計・ルール処理のリアルタイム処理
      • 機械学習の機能を網羅、分散リアルタイムアルゴリズム
    • Bazil: 分析向けツール
パネルディスカッション
  • 後半の流れ
    • 導入と展望
    • 精度で人間に勝てるのか
    • 役立つケースとそうでないケース
    • 支える技術やツールは何が有望か
    • どのように導入を進めていけばいいか
機械学習導入の展望: どこから導入が進むのか
  • 田島さん: 間違えてもおこられないところ。広告やリコメンデーションは多少間違えてもおこられない。広告の審査にも使っているが、薬事法に反した広告が出てはまずい。最終的には人間の判断になるが、その前段として使うと、問題の切り出しが難しい。間違ってもいいかどうかは導入のポイントのひとつ
  • 平手さん: 人手で不可能とあきらめている大規模なデータでの発見などから始まっている印象がある
  • 小宮さん: マーケティングでは機械学習は手段のひとつ。Webマーケティングにおいては利益追求のためのリコメンドなど。リアルマーケティングでは在庫管理などで使うことが多そう
  • 村上さん: セキュリティーについては間違えてもいいという点で同意できる。機械学習の誤判定はセキュリティーにおいてはクリティカル。すぐ人間をリプレースできるという話ではない。人に対する説明が求められるので、専門家のヘルプや専門家の教育などに使える
    • 村上さん: 実用化しようとすると、技術を受け入れようとする国や文化が重要。日本では誤検知がすごくイヤがられる。欧米では多少の誤検知は受け入れられるカルチャーがある。日本では精度向上が求められる
    • 比戸さん: 異常検知のしきい値を国によって変えたりする? それ自体も機械学習で決めるとか 村上さん: 難しいです。ユーザーが選択できるようになっているかどうかも含めて
  • 油井さん: 別の軸もある。機械学習でどれだけ質のよい文例データが集められるかという面もある。CTR/CVRなど直接レベニューに効いてくるところから導入が進むだろう
  • 福島さん: ようするにもうかるところ、精度が上がることが売上に直結するところで進むと思う。タスクの切りやすさ、男女予測やスパムフィルタは問題が明確であり、人手がかからないし意志決定者が問題を理解しやすい。そういう部分は進めやすい
    • 福島さん: そうでない部分では、例えば広告システムでは意志決定者が理解できない部分では導入が進まない。なぜこうなるのかを広告主に説明できないと困る。人間の解釈可能なモデルが面白い
    • 福島さん: やらないとわからないし、やってダメでしたも受け入れられる人が経営者にいるかどうかもポイント。仮説が感覚と合っていると使われやすいだろう
      • 比戸さん: 自社サービスを社内で評価するときはやってダメでしたならいい。しかし、お金をもらって分析した結果、データに価値がありませんでしたをちゃんと報告できるかと言うと難しい。これで何%くらい出そうですかと聞かれてもやってみないで答えるのは無理
  • 比戸さん: 投資対効果について
    • 平手さん: ダメなものはダメだとして直さないといけない。変な画像を出してしまうとサービスの質の印象が下がってしまう。
    • 田島さん: ROA的に見合いそうなところをさがしている。審査にしてもどうしても人間が見ないといけないところは難しい。機械でなんとかなるかどうかパートナーと相談するような感じ
機械学習は人間に精度で勝てるのか
  • お題
    • 専門家の経験とカン vs 過去データからの学習、あるいは両方を使う
    • データ前処理の中に専門家の経験を生かすのはどこまで有効?
    • 精度は高いが解釈できないもの vs 精度はそこそこだが解釈しやすいもの
  • 田島さん: ブラックボックスでもいいから精度高くというのはなかなかない。なんでこんなの出ちゃったの、というのが現場で一番問題になる。対策打てないとどうしようもない。解釈可能なものが使いやすい
    • 比戸さん: 人間が見るものを機械学習で絞り込んでおくのかな、と思いましたが、そうではないと
  • 平手さん: 機械学習の結果と専門家によるマーケティングで一致する部分があるよね、という事例もあった。人間ではできなかったところを機械学習が切り拓く
  • 小宮さん: 利益追求が大事。技術のほうはどうでもいい。精度は重要とはいえほどほどであって、その上で利益最大化できるのがうれしい。このリコメンドがなんでされたのか、適切なのか判断できることが精度よりも大切
    • 比戸さん: CTRなど金額の大小によって誤判定のインパクトからリコメンドの活用度合を変えたりということはある? 小宮さん: ありますね
    • 村上さん: 機械学習でうまくいかなかったときに、究極的にはそれを人間が正解かどうか判断できる、という前提に立っている。間違った結果を専門家が見たときに正解がどれか判断できる。セキュリティーは何に対するかで考える。人間がいなくてもうまくできますという世界になった場合、機械学習のことがわかる人がセキュリティーの専門家になるのだろう。うまくいかないときの説明可能性が大事
    • 油井さん: 将棋・チェスでコンピュータが勝てるのは、いいデータがあるから。専門家の経験はデータ可が可能で、そこは対立軸ではないと思う
    • 福島さん: 機械学習で勝つパターンは、トレーニングデータがいいとき。将棋やチェスは勝ちの条件が明確、かついいデータがたまっている。そういうとき人間は勝てないと思う。もうプロ棋士が負けたりしている。一方難しいのは価値判断が明確に決まらない部分
    • 福島さん: モデルの解釈性で問題になるのは失敗時の説明もあるが、モデルのパラメータがチューニングにおいて、教科書的には特徴量の抽出のハイパーパラメータをやるが、実際には外れたデータが来たときにどうするかが困る
  • 比戸さん: 論文レベルではデータ固定でアルゴリズムのチューニング勝負だったでしょうけど 福島さん: 企業してからはモデルを変えるよりも特徴量を変えた方がうまく効くということに気づいた。人がどういう記事が好きかどうかは曖昧なので
  • 比戸さん: アカデミックな評価と実用の評価とは基準が違う。一方で新しい手法はアカデミアから来る。論文ではよさそうなのに使ってみたらダメダメということがある。これから機械学習をやってみようという人はどのように学んだらよいか
  • 田島さん: 機械学習は1回でポンといいモノが入るわけではない。KPIを決めておく。売上なのかクリックなのか。それができないとプロジェクトが迷走してしまう。やりながらKPIが上がっていく、上げることを楽しむのが大事
  • 油井さん: どういったアルゴリズムを適用したかなやんだとき、複数の手法で予測した結果を統合するアンサンブル学習という手法がある。データサイエンティストのコンペティションサイトで、上位の人の結果をマージしたらうまくいったという例がある。安定した結果を得られる
役立つケースとそうでないケースの違いとは
  • 比戸さん: うまくいかなかった事例、他社事例でこれいい、これひどい、などあるか
  • 田島さん: KPI設定の失敗は細かくいろいろある。失敗した例としては国によってマーケット規模を推定するようなこと。為替がががっと変わってモデルがダメになってしまったことがある。時間軸が短く、確実に構造が同じだよね、というところで生かせると思う
  • 平手さん: よい学習データが得られるところがいいというのはある。これを抽出したい、に対してこういうのではない、ということがよくわかっているのがよい。不正検知は、こういうパターンはダメだったというのはよく上がってくるが、うまくいった例は上がってこないので難しい。正例・不例の用意が重要
  • 小宮さん: 機械学習は手段という観点をくり返しますが、機械学習のアウトプットをそのまま顧客に渡すのではなく、ドメイン知識で解釈したものを出すべき
    • 小宮さん: これはひどいの例: 冷蔵庫の商品ページで別の冷蔵庫を出すのはおかしい。一家に冷蔵庫は2台必要ない。冷蔵庫を買った人には同じメーカーの電子レンジをすすめるようなフィルタを入れるのがよいと思う
    • 小宮さん: 購売ログではなく閲覧ログを元にリコメンドしてしまうとそういう変な例になってしまうと思われる
  • 村上さん: 正常なソフトと不正なものを分離するという仕事をしているが、それは不可能なんではないかという考え方もある。ソフトウエア全体の中にマルウエアがあるとしても、その集団が全体から見ると小さい集合。それをうまく切るのはできないと考えることがたまにあります。データの性質や偏りによっては機械学習が適用できない場合もありそう
    • 村上さん: ノイズのようなデータやリアルな未知のデータもある。うまくいくデータとのギャップを考える
  • 油井さん: 学習データをもっとくれくれと言って集めてきても、特徴がいっぱいあってもノイズをうまく除去してくれるとは限らない。劇的な変化に対して過去のデータからの学習が予測に役立たないことがある。特徴選択というトピックで扱われる問題
  • 福島さん: 問題の設定がうまくない場合もある。100個の中にスパムが1個あるときに「全部スパムではない」と答えると精度が高いと評価されてしまう。そういうミスは結構ハマりやすい
  • 福島さん: リコメンドエンジンも「好きな物」がたくさんないとうまくいかない。不動産リコメンドエンジンも不動産は営業が集めてくるので、十分な数が集まらず失敗する
ツール、ソフトウエア
  • 比戸さん: RとかSciPyを使っている人も、機械学習を使うといいかもしれない
会場から質問
  • のべやまさん: 小宮さんの手元にある本は何ですか?

次世代Webセッション プロトコル

パネリスト
  • Jxckさん: @Jxck
    • Jxckさん: おれが考える次世代Webをブログに書くまでがセッションですよ
  • 吉野さん: @ysnysnysn グーグル chromeチーム
  • 辻川さん: @tatsuhiro_t Aria2/Spdylay/nghttp2/Wslay の作者
  • 林さん: @lef レピダム IETFやidconなど
プロトコル
  • 何がおこっているのか、どこへ向かっていくのか
  • Jxckさん: 去年からの1年間でプロトコルにどんなアップデートがあったのか
    • 林さん: QUICが出てきたのと、PRISMの話。PRISMが出てきたので、みんなプロトコルを見直そう、古いものを新しいプロトコルで置きかえとようというチャンス
    • 吉野さん: QUICのねらいは自然。基本世の中はHTTPだろうということをベースにTCPがやりたかったことにこだわる必要ないよね、と考えたら自然に出てくる
    • 辻川さん: アプリプログラマとしては待ち。既存アプリに入れるときにひとつレイヤーを下げないといけない。しきいは高いんじゃないかと思う。去年は見送りでした。今年はIETFで議論が進んでもう少し見直すかも
  • Jxckさん: PRISMがプロトコルの見直しにどんな影響が
    • 林さん: 平文か暗号かという話が一気にend-to-end暗号に傾いた。その空気は実装してる人にはまだ届いていないかもしれないが
    • 辻川さん: HTTP/2.0のUpgradeは、サーバーが対応しても、chromefirefoxがかたくなに実装しないので話が進まない
  • 林さん: TLS前提になるのはあると思う。元々はOSがやるべき機能をアプリでやってると思う。layer violationについて保守的だった人達も先へ目が向いたと思う
  • 吉野さん: QUICでも暗号化ができるように考えて設計している
  • Jxckさん: SSLの必要性が高まっていると?
    • 林さん: TLS 1.3の仕様はだいぶ変える気がある。まだ時間はかかると思うがTLS 1.3/QUIC/HTTP2.0は間に合えば、みんなが見ているレイヤから下がごそっと変わる可能性がある。まだ何も決まっていないが
    • 林さん: 古いアルゴリズムは切ってしまいたい。ALPNみたいなものも出てきた
    • 辻川さん: GNU TLSにはALPNが入っている。逆にNPNは入っていない。結局プロトコル選択がサーバーかクライアントかしか違わないはずだが、ちょっとAPIが違う。ALPNがメジャーになればNPNは落とすのかな、と。googleは両方サポートしているんじゃないかな
  • Jxckさん: upgradeだとまだ通らないことがあるのかな?
    • 吉野さん: chromiumチームが実験して、80番ポートが何をされるかわからないという話が残っている
  • Jxckさん: 証明書もいろいろ攻撃されてますよね
    • 林さん: CA局もDNSもやられている。PKIはちょっと分けて考えている気はする。Web PKIの話題もホット
  • Jxckさん: SSL前提になるとCAと証明書の重要性がまた上がってくる?
    • 林さん: CA局ビジネスがこれ以上進んで、CA局に責任が全部行ってしまうのはインターネットとしてはどうよと様子を見ている。だから日和見暗号が出てきている
  • Jxckさん: 暗号化がWSSでできてdeflateが拡張でできるとして、あとはマルチプレクス?
    • 吉野さん: HTTP/2.0にみんな取られちゃってWS over SPDYにする方向
    • 辻川さん: SPDY上でWSをどう効率的にやるか。データフレーム内に全部隠蔽する方法がひとつ(jettyの人、ぼく)。フレームレイヤにヒントを入れる方法(グーグルの人)
  • Jxckさん: deflateもできたし、HTTP/2.0を待ちつつWSをSPDYに乗せていく方向? 吉野さん: そう Jxckさん: そうするとまた同じ問題にぶつかってWS over QUICになると?
  • Jxckさん: XHR2だとバイナリに行くんですかね
    • 吉野さん: バイナリもひとつだけどstream使えるようにしたい。ダラダラと入力をたれ流したり
  • Jxckさん: いま一番大きい問題は? 吉野さん: 技術的というよりみんなでコンセンサスを得るところ Jxckさん: 標準化作業ですか
  • 辻川さん: HTTP/1.1にしても、ラストコールが起こるとみんな意見を言い始めて、そうするとみんな読んで意見言うので話が進まない
  • 林さん: HTTP/1.1が早く終わって番号ついてくれないとHTTP/2からreferできなくて困るんだけど。あきらめてさっさと通せという圧力が最近やっと通ったので、同時に出たりしかねない
  • 辻川さん: ヘッダ圧縮(HPACK)をどうするか細かい仕様がなかなか決まらない。ラストコールになると意見が出る
  • Jxckさん: 最近はフレームの話よりセキュリティーやプロキシの話が多いんですか
  • 辻川さん: フレームのpriorityが31bitくらいの整数だが、どう意味づけするかは完全に実装依存。server-clientが1対1なら問題ないが、プロキシが間に入るとpriority levelingが難しくなる。いまグーグルの人が重みつきなんとかという文書を書いているところ
  • Jxckさん: 去年なんとなく話題になったのはWebRTC。IETFでも話が多かった?
    • 林さん: 毎回2コマずつ、つまり1週間に4時間ずつWebRTCの話がある。1個だけ絶対に実装しないといけないコーデックを決めましょう戦争というのがあって、投票がようやく終わったはず。VP8になるかH264になるか、両方になるか
    • 林さん: でも実装はみんなできてて相互接続できてるからいいじゃんという感じ。実装が先に出ていて、標準化が後という感じだと思う。少しずつインプリの調整をして、いつのまにかできてるって
  • Jxckさん: それ以外のプロトコルには問題ない? 林さん: ほとんど見えている。もうスマートフォンでもちゃんとつながる状況。残る問題はカメラ使ってるときにindicationどうするとか周辺の問題
  • Jxckさん: 個人で遊ぶにはNAT越えとか難しい仕様があったり 辻川さん: NAT越えはフォールバックがいくつもあって、とりあえずつながるのは面白い
  • Jxckさん: NATがあるとみんななえるというか、WebRTCではNATが一番難しいんですかね
    • 林さん: TURNサーバ用意したりとか、サービス提供者は考えること多いけど、ユーザー視点ではちゃんと考えられているプロトコルだと思う
  • Jxckさん: WebRTCはP2Pという、今までと違うところから話が入ってきている。彼らがIETFで2時間話しているのはコーデックばっかり?
    • 林さん: W3Cとのリエゾン。全体の話はちゃんと進めている。政治的な話とコーデックの話両方やってるから時間かかってる
  • Jxckさん: プロトコルについてはカーネルに手を入れないとできないことも出てきていると思うけど、round trip数とか輻輳制御とか
    • 吉野さん: layeringは維持した方がいいって教科書的に言うけど、こわしたくなる。いろいろやってみるのがいいと思う
    • 辻川さん: 流れとしてはいい
  • Jxckさん: カーネルに全部入れるよりUDPに全部入れてオレオレでやったほうがいいよね、と言うとQUICはわかりやすい。オレ達のやりたいことを入れていくとQUICになるってことですかね
    • 林さん: レイヤをこわすならTCP/IPをこわせばいい。それは変えられないからUDPで妥協している。あれをこわすチャンスが来ているという面白味はすごくある
    • 辻川さん: みんなが一番よろこぶのは何もしなくてもそのまま速くなること。互換APIがあるといい
  • Jxckさん: レイヤを見直さないといけない、そういう時期に来ている、QUICはそのひとつと考えられるわけですかね。QUICでぶっこわせそうですか
    • Jxckさん: Google内ではQUIC通ってるんですか 吉野さん: まだだけど人は割いている
  • Jxckさん: TCPが3way handshakeしてるからUDPで全部やってTLSやってWS通せばいいじゃんっていくと、カーネルに何か通してもらうとかしなくてもいいじゃん、って話かと思うんですが、それでみなさんいいんでしょうかね
    • 辻川さん: Windowsとかモバイルとかどうなんでしょうか…
  • Jxckさん: Google, Facebook, twitterとか、それがないとどうにもならない人達が使えばいいものであって、全員がHTTP2を使うべきとは作ってる方も考えていないんじゃないか
    • 辻川さん: HTTP2はサーバーとクライアントが対応してくれればWebアプリはサーバーpushとか使わなければそのまま動く。QUICよりはHTTP2の方がみんなに使われるのではないかと思う
  • Jxckさん: 本当に大きなトラフィックを流す人達でなくても、ちゃんと動けば使えると 辻川さん: 使うぞと思わなくても使えていると
  • Jxckさん: DevOpsというチャンネルができたと思うけど読んでます? 林さん: 本当に流量がない
  • 林さん: ログの記録とか何も決まっていないのに何をMLに流すのかという
  • Jxckさん: 運用仕用はこなれてない中でゴリゴリやるのかな
  • 林さん: 今年はやるんじゃないですかね
  • Jxckさん: 来週IETFありますよね 林さん: 来週はHTTP2 Interimです。IETFは来月末。IETFではメインは暗号。多くのプロトコルTLSを使うためのutlというWGができる。そこはもり上がっている
  • 辻川さん: priorityの話はまだやらないと思う。プロキシのユースケースでうまくいかない
  • 辻川さん: 今のHTTP2はSPDYを前提にしているが、はるかにうまく考えられている。SPDYは各種オプションをサーバ/クライアント間で送るが、同期の仕組がない。HTTP2では必ずACKを返すようになっていて、エラーハンドリングが厳密になる
  • Jxckさん: 細かいところはともかく、動かすだけ考えるなら、そろうところはそろったなという感じ 辻川さん: そうですね。最初はfirefoxで動かなくて、ヘッダ圧縮のバグでメタメタになったりしていた。数をこなすうちよくなってきた
  • Jxckさん: interopなんかで確認しながらじゃないと作れないですよね 辻川さん: ひとつのページを2度3度見てもダメで、違うページを次々見ていかないとバグが発現しなかったりして大変
  • Jxckさん: 単体では日本はすごくそろっている → 林さん: クライアント/サーバー/ライブラリ全部自分で作っている辻川さんに日本語で質問できるのが、われわれ日本人にとってはうれしい
  • Jxckさん: 2014どうなりますかね
    • 吉野さん: WSマルチプレクスの上でAPIが使えるようになってほしい。WS APIにもっと日の目を見せてあげたい
    • 辻川さん: 今年は去年に引き続きHTTP2をやっていこうと思う。HTTP1についてはわからない。WSも自前のドライバに入れていく。QUICは待ち
    • 林さん: WSはブラウザ上にソケットが増えるということでブラウザの舞台が増えるということ。いいプラットフォームができて違ったプロトコル世界が見えるようになると楽しいなと思う
    • Jxckさん: 実装担当と政治担当という感じで
    • Jxckさん: まじめにネットワーク見始めたのは去年。QUICのねらいもわかるようになった。HTTP2も標準プロトコルとして最終的にはみんなが使えるようになるとしても、最初はHTTP1とあまりにも違うのでとまどう部分があると思う。ブログに書いたりします

次世代Webセッション アーキテクチャ

パネリスト
アーキテクチャ
  • 何がおこっているのか、どこへ向かっていくのか
  • Jxckさん: 前半をふまえると、TLS前提のWebを求めている人達がある程度はいるらしいとわかった。どうですか?
    • Jxckさん: TLS前提のWebとなるとどう変わりますか 藤原さん: SSLは重いのでCPUがムダ、台数が増えるということはある。知らないうちに混在ページ作られちゃってギャーとか。画像だけHTTPだったり
    • Jxckさん: クッキーの取り回しとかどうですか 竹馬さん: いろんなものができない前提でできているので、レイヤーができてしまうのはフロントからしても難しい。やるなら全部HTTPS化のほうがうれしい
    • 田中さん: ブログやっているとSSLが増えることの影響はある。リファラに検索ワードが書き込まれなくなる。ブログへどんな導線で来たかわからなくなる。ブラウザによってリファラの飛び方の仕様も違う。ブログには外部リソースを貼る人も多くて、世の中TLS前提で進められると困る面もある
  • Jxckさん: フルHTTPSはつらい? 田中さん: 何かヘッダを出すとHTTPコンテンツ入れられるんだったらいい Jxckさん: いっそ全世界がHTTPSになればいいと 田中さん: それならリファラも飛ぶし
  • 藤原さん: telnetで通らなくなるとか、素人が手を出せる領域じゃなくなってくる、あたりがちょっとさびしいような
  • Jxckさん: HTTPレイヤを誰もが書くわけではないので、辻川さんのような人が書いてくれるのならいいと 藤原さん: 難しいところはまかせて、その上で仕事ができるようになれば
  • Jxckさん: 運用の話がまだ入ってないという点については? 藤原さん: SSLはセッションが重い。TCP張るよりSSLネゴシエーションも重いしセッションIDのマッピングとか大変
  • 竹馬さん: リクエストを並行して投げたときにどれくらい失敗するのかとか。1秒が1.5秒になるのはいいが、0.1秒のものが0.5秒になるのはつらい。webゲームで顔しか表示されない、ようなネットが細くなったときの対応とか求められるのはつらい
  • Jxckさん: 仕様を作ってる人達が最初に考えるのはモバイルでは1本のセッションを大事に使うという部分だろう。SSLはまた別の理由で入ってくるとは思うが、HTTP2は高速化をねらっているはずだが
    • 竹馬さん: 細かいインタラクションが多くなってきている。セッションをたくさん作るのは大変。ぷよぷよの1アクションを1リクエストでやるのは大変。1万人がやるなら新しいレイヤでやらないと
      • Jxckさん: WSの方が適しているような。使っていますか? 竹馬さん: スケールさせる部分の運用ノウハウが足りない。
  • 藤原さん: WSあまり使ってないですね。数年前にサファリがプロキシ通すとクラッシュするとかあって採用できなかった
  • 田中さん: はてなではWSを実際に使っている場所はない。モバイルになって必要性が増してきていて、実験したことはある。iOSアプリにSPDYのせて3G回線上でレイテンシの改善具合を見たことはある。結構使える。LINEがTLSなしでSPDYオレオレ実装していたり、ネイティブアプリでは高速なレスポンスができるようになってきた
  • Jxckさん: 運用しているところはgoogleくらいしかなく、ノウハウが出てこない
    • 田中さん: 今年後半では使えるようになるかな
  • Jxckさん: LINEが辻川さんのライブラリ使っているというように、モバイルだと変わってくるのか
  • 藤原さん: モバイルの方が環境決めうちできるのでやりやすい。先進的なことをやろうとするとネイティブでガッチリ組まないといけないのはつらい。リアルタイムが本質のものは使う必要があるだろうが、APIたたくだけのアプリならいらない
  • 藤原さん: ゲームがコンソールのようなリアルタイム性を要求するようになってきたことも効いている
  • 竹馬さん: ネイティブゲームだと変わってくるかというと、HTML5だといままでネイティブだったものがAPIとして出てきているので、emscriptenのようなガッツリのものが出てくる。ソーシャルゲームがリッチになってきた結果、ゲーム業界が参入してきた。Webもコンシューマゲームのようなリッチなものを作っていた人でないとリッチなものは戦えなくなるのではないか
  • 竹馬さん: Webって初期化のレイヤが多い。永続化していって速くするというような、モバイルで回線が細いときの工夫がいろいろ必要になるだろう
  • Jxckさん: シングルページとWebの対象ではブログがいい例だと思うが 田中さん: ツールはAngularJSで作ってみましたというのはある。スタティックなページとツールっぽいリッチなページと2分化していくのではないか
  • Jxckさん: シングルページで遷移しなくなることによってJS初期化のレイヤがなくなってステート管理が大変などあると思う。運用からは結構変わるのか
    • 藤原さん: 遷移しないとJSで通信するという部分が増える。ネイティブと同じでユーザーのアクションがなくても通信が発生する。リトライコードの書き方をしくじると、ブラウザ内でずっとバックグラウンドで動くことがある。堅牢に作らないとみんなが不幸に
    • 藤原さん: ステータスが取れないので503を返してても無視してリトライされる場合もある
  • Jxckさん: Webを作る上でここが変わったとか
    • 竹馬さん: JS回りのエコシステムが充実した。去年と今年でJSでテスト回している人が増えた。ようやく開発がモダンになってきたと感じる
    • 竹馬さん: IEとかAndroidブラウザとかJSのイケてないところに引っぱられていて、AltJSが流行る背景にもなっている。静的型付け言語でやっていた人にいきなりJSやれというのも無理。そのへんが変わっていくだろう
    • 田中さん: JSに加えて、DevOps的な進化もある。上と下がすごく進化した。サーバーサイドアプリのレイヤーは相対的には進化しなかった Jxckさん: JSONだけ返せばいいから進化しなくてよかった
    • 田中さん: シングルページだとパフォーマンス管理も難しい。サーバーで時間測ればよかったのが、クライアント側の処理が増えるとどのへんが遅いとか気づきにくくなる。Firefoxだけ遅いみたいになると方法を確立しないといけないな
    • Jxckさん: ISUCONでシングルページを速くするとかなった場合にどうやって測るか 藤原さん: クライアントで何をしてから何をするまでの時間を測るような仕組を作らないとサーバー側で知り得ない
    • 竹馬さん: JQueryを使っていることもあり、一度作ったDOMは使い回すとして、自分でやる分にはキャッシュ作ったりなどできるが、サーバー側のレンダリング処理の延長上でならない部分がある
    • 藤原さん: 去年はWebの世界をあまり見ていなかったが、ゲームがリッチになってきて、Webやってた人が延長でやりたくなる部分、そうやると大変という部分がある Jxckさん: ゲーム部分はドキュメントベースの人が装飾でやっていると大変と
  • Jxckさん: Angularなどはみんなゲームがやりたくてデータbinding入れたわけではないと思うけど 藤原さん: JSでリッチにしようと思うと職人芸。とは言えWebでやりたいという感じはある。いまは容易にできない。もう少しJSとかブラウザ型で性能が出るようになるといい
  • 竹馬さん: 高速化というのは結局UXのためにどれだけ20msの中でやるかという部分であって、ユーザーに影響出ないようにインタラクティブにする以上、ゲームじゃなくても教育ソフトなどでも問題になる部分
    • Jxckさん: ゲームでなくても職人芸的な部分を持っていたからできたという部分があると
    • 田中さん: はてなにはそんなヘビーな部分はないが、すみずみまで知っている人がいて、安心感を持ってできている。まだしばらくは年単位で職人芸が残っていくのではないか。新しいのが出てくることを期待
  • 竹馬さん: デザイナーとペアになってこれ重いですかとやっている。最低限速度を満たさないといけない部分は何msを取らないといけない。ユーザーに間を取らせるためのアニメーション遷移などはあきらめて職人芸でやるのもありかな、と
  • 藤原さん: ロングpollしてるやつにリクエストが来るまでの時間を測ったり、リアルタイム通信でいかに速く返すかは少し入れたりした
  • Jxckさん: いまのISUCONで勝つような人達はバックエンドのチューニングができる人達。フロントについては測定ができないのでISUCONで扱えないというような 竹馬さん: 職人芸というか定量的には測れないだろう
  • 竹馬さん: 確実にボトルネックになるような部分があって、タイマーで更新されるべき部分をちゃんとできるか見るとか。モダンなブラウザは60FPSでやってると思うが1/60秒以上遅れるとユーザーは気づいてしまう
  • Jxckさん: セキュリティー的にはJSで行くと抜かれちゃうという穴ができてしまうとか、そういう事例はありますか
    • 田中さん: いまのところはそういうインシデントはありませんね
    • Jxckさん: ダイアリーがブログになったときに問題が出ませんでしたか? 田中さん: ドメイン構造の変化によってクッキーのセキュリティーなど気を使った部分はあるが、HTML5だからどうということではない
    • 藤原さん: フロントでいろいろやるようになった分、フロントで処理した数字をサーバーに送るようになって、その数字が正しいかチェックが必要になった。いわゆるゲームのチート対策
    • 藤原さん: ゲームでランキングやるとチートが発生しやすい
    • 竹馬さん: サーバーとクライアントで別々にバリデーションを持っているのがつらい。nodeを使って同じにできるとうれしいが今の枠組では難しい。walmatみたいにフロントサーバーを置くようなアーキテクチャが出てくるのではないか
    • 藤原さん: nodeの運用については、メモリーリークがある。デーモン作るスキルのない人でもやるとできちゃうから問題。リクエスト単位で死んでもよければ多少リークしてもいいが、nodeはそういう用途では使わないので、逆に時々再起動とか残念な感じ
  • Jxckさん: なんでもゲームの話になっちゃいますね。次世代Webでもゲームが求められているのかなw
  • Jxckさん: シングルページのようなゲームのノウハウが必要なくらいクライアントリッチなものが書けるようになった。全部SSLとか言ってんじゃねーよ的な話が出ましたが、今年はどうなってほしいですか
  • 藤原さん: HTTP2はなかなか実装が出てくれない一方、素人では作れないとなると、待つしかない。結局ビッグプレーヤーしか使えない。AWSさんがそういうレイヤを置いてくれれば使えるが、それだとつまんない#cross2014a
  • 竹馬さん: MVC,MVVMとか2014年もライブラリがボンボン出ると思う。いままでのクライアントがflashでやってたような、デスクトップのフレームワークに近くなってリアルタイムJSに振られるのでは
  • 田中さん: ゲームが一番のユーザーになるのかなと。PCの性能アップのときもそうだった。WSとか極めて高いリアルタイム性はゲームの方が需要が多いので、そこが牽引役になって進めてくれるとありがたい
  • 田中さん: permalinkの扱いがどんどん雑になっている。その中でどうやってはてなブックマークなどでpermalink扱うにはどうするかは考えていかないと
  • Jxckさん: 去年リアルタイムと言ってた部分が今日はまるまるゲームに置きかわったような気がして、Web上でもゲームの存在感強いな、と思いました。データバインドの話として去年はangularとbackboneの話がありましたがまだまだ結着はつかないですね
  • Jxckさん: 「オレの考える次世代Web」についてみなさんブログに書いてください。そこまでがこのセッションです

JICS2014レポート(4) 1/15前編

ソーシャルメディア/モバイルとアイデンティティ

  • 寺田さん @ オプト
    • オプト: 広告代理店
    • モバイルコンテンツフォーラム: 業界団体
  • ソーシャルメディアとモバイルが変えたもの
    • 購売行動の変化: ソーシャルでAIDMAがAISASになった
    • AIDMA: attention, interest, desire, memory, action
    • → AISAS: attention, interest, search, action, share
    • 検索するときは価値の比較、口コミのチェックもする
    • 共有される: 製品のいいところ、悪いところなど口コミ情報
    • ZMOT: 店舗に行く前に意志決定がされてしまっている
      • zero moment of truth
      • first moment of truth → 店舗に行くこと
    • showrooming: 店舗で見てネットで買う
    • O2O: online to offline、クーポンや位置情報から店舗に誘導
  • オムニチャネルという考え方
    • 顧客接点が増えてくる → 個々の顧客の行動を把握する必要
      • シングルチャネル: 単一接点
      • マルチチャネル: 店舗、ネット、カタログが分離されている
      • クロスチャネル: 一元化される
      • オムニチャネル: シームレスに。チャネル横断の顧客管理
  • 3つのLife: Real Life, WEB Life, Social Networking Life
    • 行動の領域別にモデル化
      • SNS上とリアルでの行動に違いがありそうだ
    • ユーザーの識別
      • Real: サービス毎の会員ID → ポイント交換、クレジットカード
      • WEB: クッキー → クッキー連携、アドネットワーク
      • SNS: OpenID, SocialID → ソーシャル連携
    • Life間連携
      • IDとクッキーのひもづけ
        • CCCのT-ポイントカードとクッキーのひもづけ: 1千万人超
      • Real会員とSNS IDのひもづけ
        • 同意を取らないといけないので難しい
        • SNS側は同意済でもリアル側で情報公開などの同意を取っていることはほとんどない
    • Do Not Trackの影響
      • EUのクッキー法
  • モバイルファーストの台頭
    • 最初の接触はスマホタブレットになってきた
    • Real: アプリでデバイス自体を会員カード化
    • SNS: メッセンジャー(LINEなど)を活用
    • WEB: PC上のサービス会員化でIDを付与(ニュースサイト等)
  • ソーシャルコネクト
    • SNSのIDを中心としていろいろ連携(API利用)
  • 各所に散在する利用者情報
    • サーバーがあちこちに
    • 端末内にも情報が
    • 自分自信が適正に扱っているだけではすまない
      • 連携先が適正に扱っているかも把握
  • パーソナルデータ利活用の原則
    • 2013/8 総務省 研究会報告書
  • Privacy by Design
    • 自社もだが、ID連携先が問題: 契約だけ良ければいいのか

「デジタルマーケティングアイデンティティ

  • 平川さん @ 電通
  • 変化するマーケティング環境への対応
    • SNS + スマホビッグデータ
    • 消費行動の意志決定の変化
    • 20世紀モデル: 口コミ(記録に残らない)を情報流通サービスがフィルタ
    • ネット登場: 検索で必要な情報を発見
    • ソーシャル時代: 情報の膨大化
      • ログが残るのでトラッキングしたくなる
      • モノを売りたい人達がお金を払って分析(原資はプラットフォーマーではない)
  • 購入プロセスのシームレス化
    • O2O: トラッキングしやすくなった
    • 購入・リピート: POS情報
  • オムニチャネル化
    • すべてがトラッキング可能になる
  • O2Oの流れ
    • 販売店送客モデル
    • これまでは集客は流通にまかせていい製品を作っていればよかった
    • アプローチした顧客の情報(営業マンが取ってくる)は、楽天IDなどから取ったものとは扱いが違う
  • IDデータマネジメント
    • 情報提供の入口を消費者がベネフィットを持って同意するのが原則
      • デフォルトで取るのはもはやあぶない
    • マスセグメントとして処理した上で、顧客にとってパーソナルに見えるようにメッセージを工夫。本当の意味でのone-to-oneではない。タイミングが重要
      • メールアドレスは利用
  • デジタルマーケティングの運用フロー
    • マスセグメントとして統計知を得る → セル分割の更新
  • ビッグデータ×アイデンティティ
    • 電通: 「ヒト」の動きを見てきた
    • メーカー: 「モノ」の動きを扱ってきた
    • 「と」でカンタンにつながるものではない
    • 丁寧な情報入手、顧客主導の情報開示を入れていく
  • 具体的にはどんなデータが
    • マーケティング上はIDは必要なく属性データがあればいい
    • 購売行動に行く手前の行動をモデル化できればいい
    • アノニマスな個」の集団を集合として分析できればいい
      • 商品別に集合が異なる
  • ビッグデータ時代のマーケティング分析
    • モノの動き×ヒトの動き → 分析 → ROI見える化×将来予測×CRM
    • CRMのない商材はモデリングをひたすらくり返せばいい
    • 商材ごとのクラスター最適化
  • セグメントオファーとフィードバック
    • タイミングが重要
    • 「ジオフェンス送信」時間と位置、顧客がアクセスしやすい「今」のタイミングで送ると購入率が3倍になる → スパムメールが減る
    • サーバーサイドでセグメントモデル構築 → クラスター別のオファーを端末に送信
      • 端末でタイミングと位置を見て表示
      • クーポンを「使った」タイミングからフィードバック
      • 個人情報は端末内にあるが、コンバージョンレートに変換した上で入手したい
      • 高額商品は人間関係なので業務インターフェースとしてセキュアに管理
  • ソーシャルCRM
    • 優良顧客のお友達は優良な潜在顧客
    • インフルエンサーから同意を得てID化
    • 「いいね!」を集める時代の終焉
  • まとめ
    • アノニマスな個へのマスセグメントでのアプローチ
      • 最低限必要なログをいただく
    • 購売に向けてパーソナルアプローチを行うための顧客情報取得・活用
    • O2O: オンラインでの待ちぶせとは本質的に違う
    • サーバーサイドでセグメント化 → 端末サイドでのパーソナル化
      • 行動は端末内で使います、コンバージョン情報を送付しますという同意
    • 個から個への拡散アプローチ

ビッグデータとIdentifier(識別子)」

  • 佐藤一郎さん @ NII
    • 人のIDよりモノのIDで仕事をすることが多い
  • IDとは
    • identify document (身分証明書)
    • identity (個人特定、パーソナルデータ)
    • identifier
モノのID、特に商品のID
  • JANコード: バーコードになっている
    • 国番号、企業コード、アイテム番号、チェックディジット
    • 国際的なとり決め
    • 国番号(日本は49)より下は各国が決めてよい
    • 日本では企業コードより下は各企業が決めてよい
  • チェックディジット
    • JANコードは13桁だが、本当は12桁でよい
    • → バーコードという読み取りシステムを前提としたcheck digitも含まれている
    • → ID(識別子)は読み取り技術と独立とは限らない
  • 商品コードは世界共通
    • 各国によって使えるプリフィクス範囲が異なる
    • 先に手を挙げた国が広い空間を得ている
  • 商品バーコードが生まれた理由
    • 誰が発明したのかよくわからない状況
    • レジ待ちの時間短縮のため
      • 1970年代のアメリカ、巨大スーパーで普及
    • 各スーパー内で番号をつければ十分だった
      • → スーパーごとに番号をつけるのはムダ → メーカでつけるように → 標準化
  • IDと商品
    • レジ待ちを短くする → 商品DBは各スーパーで待っている
IDで見えてくること
  • POSシステムから見ると
    • IDのついた商品パッケージを買っているにすぎない
    • もっと言うとIDを買っているにすぎない
  • 商品コードは誰が管理するのか
    • JANコードでは流通システム開発センターが企業番号を割り当て
  • POSが広く使われる時代
    • 商品IDのない商品は流通できない(事実上存在しないのと同じ)
    • 流通データを持っているのは小売 → 商品情報を登録してくれなければ売れない(存在しないのと同じ)
  • プライベートブランド商品とJANコード
    • あるスーパー系PB商品は基本は各製造メーカーのJANコードを提示
      • 7&iプレミアム
    • 別のスーパー系PB商品は基本はPB事業部のJANコードを提示
      • topvalu
    • PBの主旨から言うと、JANコードの製造者番号==商品について責任を取る先
  • 書籍には2つのバードコード
    • 上: ISBN
    • 下: 販売情報
      • 価格情報が入っている → 再販制度があるから
    • 一般的に返品可能な業種は在庫管理を含めIT化が遅れている
  • カフカ事件
    • 某出版社の文庫本で、相違な書籍に同じISBN番号をつけてしまった
    • 書店や図書館などは翻訳できない大事件
ビッグデータとID(識別子)
  • 商品でA/Bテストしたい
    • パッケージの絵が変わったくらいではJANコードは変えられない
    • JANコードではA/Bテストできない
    • IDは関心事によって付けられる
      • 商品の印刷デザインはJANコードの関心事ではない
      • IDを目的外に使おうとするといろいろ問題がおこる
  • IDとビッグデータ
    • コンピュータは現実世界を直接扱えない
      • IDをつけて、そのIDを扱う
    • 関心事に応じて対象にIDを付番するのが第一歩
  • モノのID
    • 自動車番号(ナンバープレート)
      • 設計の悪いIDの代表
      • 目視による識別性を重視
      • 桁数が少ない → 空間不足 → 拡張を重ねた → 読みにくい
    • 製品の製造番号
      • 個体識別は必要とは限らない(大根1本に1ID、など)
      • 品質管理が目的ならば生産日時とライン番号で十分
      • RFIDが普及しなかった最大の要因は需要がなかったこと
        • 大根1本1本のトレーサビリティーはそもそも必要ない
      • IDをつける人と管理するとが一致するとは限らない
    • 磁気カード
      • クレジットカード以外のものも統一されている
      • 磁気カードは医療にも使われている。クレジットカードを間違って通したときに問題が起きないように、同じID空間で識別できるように付番している
  • まとめ
    • 「IDの秘密」佐藤一郎著

「プライバシーとアイデンティティ

  • 崎村さん @ OIDF
プライバシーって何?
    • privacyとdata protectionの混乱
  • 語源からのアプローチ
    • private + -cy
    • privatus(ラテン語) 他から分離して、自身に帰属させた
      • publicus(公共の)、communis(共同体の)と対義
    • プライバシーがよくわからないのは、文化によって公共・共同体の考え方が違うから
  • 個人情報とプライバシーの混乱
    • 文献からのアプローチ
    • 「Right to be let alone」
    • 個人の不可侵の権利
  • プロッサーの4類型
  • レッシグのプライバシー定義論
  • 自分に属する情報は自分がどう使うか決めてよい〜情報流通の自由
    • 自己決定の権利
    • 自分が出したいところに出すのも権利 → identity連携
アイデンティティって何?
  • エンティティと属性
    • 属性(名前や行動履歴など)でエンティティを認識している
    • アイデンティティ := ある実体に関連した属性の集合
      • ISO 24760-1:2011 による定義
    • アイデンティティ = パーソナルデータの(部分)集合
  • 自己像(identity)
    • どの属性をどのコンテキストに見せるかを自己決定
    • 友達と上司とで見せる自己像を変えたい
    • コンテキストを越えて自己の望まない形で属性が出てしまうと「プライバシー侵害」
  • アイデンティティ連携
    • 属性の集合から、どの部分集合をサービスに提供するかを同意する
  • もう一つのポピュラーなモデル「バレたら炎上モデル」
    • ひそかに or だまして集めて勝手に使う
      • お客に正直なことを言ったら同意してもらえない
        • お客の利益にならないことをやろうとするから
      • 後から何に使うかわからない、後から同意をもらえない
  • 「ブレーキは速く走るためにある」
  • 米国「消費者プライバシー憲章」PIA
    • PIAの標準化作業中
  • プライバシートラストフレームワーク
    • ルールと強制手段
  • PTFの現状
    • ID trust framework
      • 属性の質品
    • privacy trust framework
      • パーソナルデータの扱い方
  • 明示的同意?
    • そもそも同意の向きが逆
    • 個人が企業に対してパーソナルデータ提供をライセンス、同意するのは企業の側、となるべきでは?
  • 個人によるプライバシー侵害
    • ケースとしては多いだろう
    • 見なかったことにするプライバシー(大人の対応)が重要になる
      • MAC Address, BT Address、取れてしまったとき、見なかったことにして捨てる
    • 個人をリスペクトせよ! そうすればそんなに大きな間違いはおきない

JICS2014レポート(5) 1/15中編 基調講演、エンプラトラック

基調講演

パーソナルデータ利活用の最前線
  • 牧野さん @tomoe @ twitter
    • twitterのデータ提供と活用について
    • twのデータをパーソナルデータとして活用してもらうために
  • twitter
    • 世界的なニュースの配信と言えば
      • これまで: メディアが取り挙げる → 個人が情報入手という流れ
      • twitter後: twitterがメディアより早い: ハドソン川飛行機事故、アラブの春、ボストン爆破事件
  • tw
    • アクティブユーザー 2.3億人
      • 日本は世界でもかなりtwを使っている。ユーザー数は米国に次いで2番目に多い
    • 5億ツイート/日
    • モバイルからのアクセス 75%以上
      • 140文字という制限はSMS利用を想定していた
  • twからのデータ提供を考えた場合のtweetデータの特徴
    • Real Time
    • Public
    • Conversational
      • テキストベースなので解析しやすい
  • 情報利用とプライバシー保護
    • メアドのみでsign up可能 (電話番号、住所等は不要)
    • twは公開前提で利用 (非公開オプションもあり)
      • 利用規約での事前承諾
      • 他社、個人での利用を前提とした同意をいただいている
      • データを利用可能
    • 利用側のルール: tw ディスプレイガイドライン
    • ブロードキャストガイドライン: TV局がユーザーの許諾なくツイートを利用可能
  • 公開APIでの無料利用
    • 検索で取得できるtw数の制限
    • 全データから1%までしか取得できない
    • 全ての日本語ツイートデータ提供
      • NTT dataが再販パートナー
    • コンシューマ向けのデータ利用
      • Y!とNTT Dataがリアルタイムサーチを提供
  • 活用事例
    • 事業戦略: 東急百貨店
      • ヒカリエ内ShinQsオープン1か月前とオープン後の生の声や本声を把握
      • メリット: すぐに利用できる、カンタン
        • コールセンターの声より本音に近い
    • 商品情報の把握: NTTデータ
      • 栄養ドリンクに関連するキーワードを分析
    • 購入者情報の把握: Ponta
      • Ponta IDとひもづけて、O2Oに活用
      • #ケンタで大豪遊 キャンペーン
      • ID連携したユーザの3割が店舗に足を運んだ
    • 選挙運営の指標: 自民党 Truth Team
      • ネットにある情報から国民が求める政策や姿勢を把握・分析
    • ネット選挙twitter分析: 朝日、毎日新聞
    • 災害ビッグデータ
      • NHK: 記者のいない空白地帯の情報取得に活用
      • NTTデータ: 竜巻被害の状況把握
    • QUICK端末にもツイートデータを利用
      • 株価との関連を分析中
    • TV指標
      • 視聴率と比べて、話題に出した指標として活用
      • ビデオリサーチへの提供
  • インプレッション指数
    • 投稿数 = unique user数
    • インプレッション数: そのツイートを何人が見たか
楽天のデータサイエンスによるEC革命〜おもてなしと興奮をデザインする〜」
  • 北川さん @ 楽天
    • 元々は理論物理屋、量子コンピュータの提案など
    • twitterのフォロワーを増やす方法を検討、とか
  • 楽天の紹介
    • 楽天Amazon
      • トップページ: 楽天のほうがごちゃごちゃしてると言われているが、そう変わらない
      • アイテムページ: 楽天のは長すぎるだろう
        • 長いものは20ページもある
        • Amazonのモノの売り方: 価段・送料・配送日を表示 → 理性的なアピール
        • アイテムページは店舗さんが作っている。セールストークに似ている: タレント活用、自分と似ている同一視、効能、専門性・ランキング → 感情価値のアピール
  • Rakuten Diversity
    • 感情価値をどうビジネス上で表現するのか、どう顧客のベネフィットに変えていくのか
  • Rakuten Global Expansion
    • 日本発の感情価値、「おもてなし」などをいかに世界に発信していくか
  • B to B to C
    • ネットモールとしての成り立ち
    • 共通IDによってなしとげられること
  • 店舗さんのempowerment
    • マーケティングの4P, 4C
      • Product, Price, Place, Promotion
      • Customer Value, Cost, Convenience, Communication
      • Product: フランス人がおいしくないと思ったワインも中国人にバカ受けということがあり得る(?)
        • わさびピーナツがイギリスで大人気
      • Place: WEBページのおもてなし表現
        • ロングページによるstory telling
  • 「おもてなし」のプラットフォームを作る
  • ものを売る・買うことそのもののサービス向上
    • Google: テクノロジーによる情報の質向上
      • SEOへの要求がwebページの質を押し上げた
    • 楽天: テクノロジーによる購売の質向上
  • Shopping Entertainment
    • 買うこと
      • 買ったモノに幸せを感じる人
      • 買うことそのものに幸せを感じる人
    • 購売体験そのものを売る例: IKEA
      • IKEAに行くこと自体が楽しい
  • 日本のEC率 4% (イギリスは10%くらい)
    • 感情価値による購売
      • 便利さは買い続ける理由ではあるが買い始める理由ではない
      • 感情価値は買い始める理由になる
  • 楽天市場、店舗さん、お客さんによる感情価値のエンパワー

エンタープライズトラック

14:40- #enterprise

  • 富士榮さん @phr_eidentity @ 伊藤忠
  • Identity Trends
    • BYOI: BYO identity (Coud Identity Summit 2011)
    • Identity is the new perimeter (Coud Identity Summit 2012)
      • 企業の中から外のサービスを使う、外から中のサービスを使う
      • サービスは企業の境界線ではなく、IDが境界線になる
    • Identity Management in the Internet of Things (IoT)
      • Big Data
    • Identity as a Serviceへ

Developing Modern Identity and Access Solutions

  • Vittorio Bertocci @ Microsoft
  • Agenda
    • Identity workloads in the cloud era
    • An example of Identity as a Service offering: Windows Azure AD
    • Developing for an IDaaS platform
Identity workloads in the cloud era
  • ディレクトリはオンプレで使うために作られた。いまでもほとんどの使い方はそうだ
  • オンプレのディレクトリの回りにリソースやアプリを配置していく。もちろんユーザーもオンプレで活用していた。管理者にとってはパラダイスであった。
    • 管理者にとってはパラダイスであった。すべてをコントロールできた
  • 境界が進化し、パブリッククラウドができると様変わりしてしまった
    • 会社バウンダリの外に活用したいリソースを設けるようになった
    • 2つの問題が出てきた
      • 境界の外にあるものの認証
      • firewall背後のdirectoryへのアプリからのクエリ
    • 影のITの出現: クレジットカードでIT部門の許可なくサービスを購入できるようになった
    • BYODの台頭によって、オンプレで管理できるリソースは縮小した。 デバイスはドメインに参加しないので、本当に必要なところはアクセスできない。モバイルデバイスなので置き忘れによるトラブルも発生。管理者は怒り心頭
    • 従来のディレクトリに問題があるわけではないが、リソースは増える、デバイスが使えるアプリは増える。そして従来のperimeterは消えつつある
    • パブリッククラウでも活用できるIDaaSがこれを解決する。Active Directoryをなくすのではなく、機能拡張することにした。新たにクラウド上で展開可能
An example of Identity as a Service offering: Windows Azure AD
  • Windows Azure AD
    • 従来のオンプレディレクトリがあり、user, group, 証明書などがある。クラウドの先にWindows Azure ADがある
    • クラウドに常駐するアプリからオンプレディレクトリにはクエリがかけられないので、クラウド上にディレクトリをコピーする
    • クラウドはテナント構成になっており、your tenant, your domainと呼ぶ
    • dir sync: 定期的にコピーを同期する。Office 365において一部差分をコピーするために長年使っているもの
    • デフォルトでユーザー、グループをコピーするが、クレデンシャルは知らない。認証する場合にはオンプレのディレクトリにリダイレクトする。ここでID連携技術を使う
    • クレデンシャルをクラウド上に置くことも可能。もちろん生パスワードをコピーするのではなく、ハッシュをコピーする
    • 中小企業や分散拠点であれば、クラウド上のディレクトリだけで完結することも可能
  • ユーザーによるIDaaSの活用
    • エントリポイントはWindows Azure Management Portal
    • AzureはPaaSである。そのひとつであるADにナビゲーションする
    • マルチテナントサービスのうち、特定のUIから入ることも可能
    • まずアドミンとして入る。左下のほうにあるActive Directoryを選ぶ
    • user, group, applicationがリストされる。アプリは自作のものも3rd partyのものもある
    • アプリ追加の方法は2つ、ひとつめは自社開発のもの、もうひとつはプリインテグレートされている3rd-partyアプリ(500以上ある、salesforce, dropboxなど)
    • ポータルからはSSOでアプリを使うことができる。twitterとか。ユーザーはSSOが使え、管理者はクレデンシャルを管理する必要がない
    • Graph APIもサポートしている。従来のLDAPに相当する役割を持つ。RESTful APIになっていて、オブジェクトにアクセスすることができる
  • Developer視点での開発
    • 認証エンドポイントも提供している: SSOにはSAML, WS-federation、WEB APIやプログラムにはOAuth、WEB Service+WEB SSOとしてOpenID Connect
    • IDaaSシステムを介したアプリ開発
    • 従来のIDシステムと同様にパラメータを設定する。アプリが何であるかを使用プロトコルのパラメータ、暗号化方式などを記述する
    • 従来型よりも使いやすくなっている。オンプレでは管理者が独自の判断でディレクトリに合わせたパラメータを指定していた。今後はconsistentな方法で設定ができる
    • 従来型ディレクトリは管理者のみがアクセスするように設計されていた。しかしAzure ADではプログラムベースになっているため、delegation前提で設定されている。アプリから見て統一的なアクセスが可能
    • ADに対するアプリを開発する方法は2つある。ディレクトリに対してアプリ記述を提供する方法。マネジメントポータルを使う方法と、Visual Studioを使って記述する方法
    • 大事なことはアプリがオープンプロトコルのどれかを話すこと。ここだけ守ればプラットフォームに依存せずに開発できる
    • SDKが提供されているので、例えば認証プロトコルで何が起こっているかを知らずにアプリに認証機能を作ることができる
    • Web Sign Onでは、SAMLまたはWS-Federationを活用する。Azure ADのメリットとして多要素認証やレポーティングなどをすぐ使える
Developing for an IDaaS platform
  • Visual Studioを使った開発デモ
  • Web APIも同様。VSで同じように作れる
    • クライアント用ライブラリも提供
    • プラットフォームとして iOS, Androidもサポート
    • OpenID Connect: 現在はMS開発のAPIに対して使える。今後は3rd-partyに対しても使えるようになる
  • Graph API
    • RESTful interface。fine-grained delegationが可能
まとめ
  • IDaaSでハーモニー

パネル・ディスカッション

  • 工藤さん: ASPSaaSが出てきたので、ログインも個別に持っていたものから、企業IDやコンシューマIDを使うようになってきた
    • ユーザー企業において今後利用するもののヒントになるだろう
    • 2001〜2002年にSAMLやLiberty Alliance製品が出てきた
    • 2008年のスライドでは社外サービスを使うにあたって社外IDを使う、社外ユーザーへのサービス提供のようなことを言っていた
    • 2013年のITRさんの発表: フェデレーション市場が増加。クラウドサービスの連携が牽引力となっている
    • 応用はさらに進んでいる。昨日のPat Pattersonのsalesforceの発表では、SFがCRMユーザー管理まで引き受けるというところまで進んでいる
    • SAMLはまだまだ使われている。SAMLでいいというのはベースラインとしてある。しかし広い形で使われているとはいえない。特定のサービスでのみ使われている。それでいいのか
  • 関根さん
    • fileforce: クラウド上のストレージサービス
      • コンシューマ向けにはdropboxがある。エンタープライズに特化して提供するのがfileforce
      • セキュアな機能、拡張性などエンタープライズ向け機能がある
      • 認証連携はSAML2.0に対応
      • 中小企業ではGoogle Appsなどを活用している。単純にSSOしたいというニーズが出てきている → ID連携
      • 関根さん: 個人事業主向けのコンシューマID連携ニーズが高まっている
  • 浅賀さん
    • サイボウズ システムコンサルティング部門
    • 認証回りアライアンスを担当
    • 10年以上パッケージでオンプレ製品を提供
    • 2012/12からcybozu.comを提供
      • office, ガルーン、キントーン(DB)、メールワイズ
    • 申し込みから最短5分で環境を自動講築
    • セキュリティー(IP制限、BASIC認証、2要素認証)
    • データバックアップ(ミラーリング、西日本へのコピー)
    • ID連携: SAML 2.0 (SP-initiated)
      • SSOのニーズが多かった
      • 統合Windows認証、認証用クッキーはクラウドなので使えなかった
      • 2500社のうち10社程度がSAML連携を利用。上げていきたい
    • プロビジョニング
      • 独自API (CSVを送信し、結果を非同期に確認)
      • 標準化されたAPIを使っていきたい(SCIM?)
  • 河野さん
    • 河野さん: 福利厚生のアウトソースサービス
    • IDは当社から初期パスワード設定の上提供
    • 企業IDを使ったID連携、コンシューマIdPとのID連携のニーズが高まっている。
    • 2013年、SAMLを使って自社社員番号でのSSOを実現
      • 河野さん: 自社はOpenID Connect RPとして動作、ID連携ゲートウェイ(Uni-ID RP)を利用
      • 各会員企業様のSAML IdP設定の違いを吸収
お題
  • 工藤さん: 10年前からID連携はあったが、ここに来て対応が進んだ理由とは
    • 関根さん: オンプレに置いた社内での連携というのはこれまでもあった。クラウドになってからのニーズが2〜3年前から。googleなどクラウドサービスの台頭が効いている。salesforce, google appsなどからのそのままのIDでのSSOをしたいお客様が多かった。なぜSAMLかというのは→ OIDCも対応していきたい(よく聞きとれなかった)
  • 工藤さん: SAML使いたいというよりはすでにログインしているIDが使いたいという要望なんでしょうか
    • 浅賀さん: お客様としてはID連携ができると知らない人もいる。競合ができるからやらざるを得ないというモチベーション。RFPに入ったりはしていない
    • 河野さん: 競合がID連携しているかどうかは知らない。お客様要望により対応しているのが現状
  • 工藤さん: 始めてみてこういう話があった、ようなエピソードは?
    • 河野さん: 背景としては私どもが発行しているIDが長く覚えにくい、利便性が悪い(セキュリティーのため)。社員番号を使いたいという声はあった。社員番号になって便利になったという声がある
    • 浅賀さん: SSOがニーズとしては高い。情シスとしてはパスワードをクラウドに持ちたくない
  • 工藤さん: ID連携は部署単位のほうが多い?
    • 関根さん: ID連携というと全社レベルの方が多い。部署単位だとSSOだけあればいいということが多い。5〜10のクラウドサービスを使っている場合に、自社IDでSSOしたいという要望につながることが多い。ユーザーとしてはSSOの利便性になるが、情シスからは管理コストが重要になってくる。パスワード更新なども1人×サービス数で効いてくる
    • 河野さん: コールセンターコストではID忘れの問合せが減った。社員番号を忘れる人は少ない
  • 工藤さん: SAML対応した結果、ここがいい、ここが悪い?
    • 浅賀さん: IdPアラアンスだと他社とやりやすいということがある。仕様の細かい部分で合わないことがあった。Azure ADとはうまくつながらない
    • 浅賀さん・関根さん: 他のサービス、アライアンス連携ではSAMLはだいたいサポートしているので組みやすい。そのままで行かないケースが多い
  • 工藤さん: 自社でSAML環境を構築して使ってくださいということはあるか
    • 河野さん: 見積りを作ったこともあったが、コストに見合わなかった
    • 工藤さん: 何千、何万もお客様がいるところではうまくいっている印象がある。
  • 工藤さん: お客様にこういう仕様でやってくださいと言うとSAMLの知識が必要になると思うがどうか
    • 関根さん、SAMLの認知度が低い。そもそもSAMLの実装をしていないお客様も多い。デベロッパの理解度がなかなか上がらない
    • 浅賀さん: SSOベンダーさんの方がより理解されていることの方が直い。仕様というか、レスポンスのどことどこをチェックしていますということで検証していくことが多い
      • 工藤さん: エンドユーザー企業がアライアンスパートナー製品を導入して、その後ということになるのか
      • 浅賀さん: ホワイトペーパーを出すなどして、エンドユーザー企業さんの導入がうまくいくように工夫している。SAMLの認知度からはまだまだSAMLと言っただけでうまくいくというわけではない
  • 工藤さん: 統制できない他社サービス、どういう使い分け?
    • 河野さん: Y!さんと直接連携するわけではない。社内で使っているIDをいただいて会員IDとのセットで扱うというような使い方
    • 工藤さん: Y!で悪いことをしてアカウントを止められちゃったなど、統制不能な場合はどう考えている?
    • 河野さん: 他社で使えなくなったというような情報がこっちに来るわけでもないので難しい
    • 工藤さん: 契約関係のないサービスとうまくやるのは難しい
  • 工藤さん: コンシューマIDの受け入れはビジネス的には大きい?
    • 関根さん: 少人数になればなるほど、管理可能かどうかより利便性を優先することが多い
  • 工藤さん: 認証と認可とは別だが、認可を使うということは?
    • 浅賀さん: 権限管理が同一ではないので逆に難しい
  • 工藤さん: プロビジョニングは?
    • 浅賀さん: ほとんどはアカウントの自動生成までを使っていただいている感じ
    • 河野さん: 役員だけはサービスレベルを上げるということは対応している。人事情報を取り込んで設定するような仕組がある
  • 工藤さん: SCIMなどの標準化は?
    • 河野さん: 標準化よりはお客様のご都合に合わせることが多い。
  • 工藤さん: サービスから使ってくださいと言わないとユーザー企業さんに詳しい人がいるわけでもないから難しいと思うがどうか。CSVでこういう風にカンマで区切ってくださいとか
    • 浅賀さん: ITスキルの高くないお客様も多いので、カンタンでないと使ってもらえない。プロビジョニング、フェデレーションをなんのためにやるのかということを機能として見せる、ハードルを下げるしかけが必要
  • 工藤さん: google market placeに乗るなどのやり方はあるのではないか
    • 関根さん: 先行するgoogleユーザーさんが見てくれるメリットはある。しかしID管理としてはお客様としても理解していない場合があり、漠然とSSOということが多い。利用イメージと結びついていない。理解度を上げることが必要
    • 関根さん: 様々な企業がクラウドサービスを使う上でSSOは必要になってくる。インタフェースの標準化が普及を助けると思う
  • 工藤さん: ビジネス的な位置づけはあるか
    • 河野さん: うちは福利厚生なので、入っていただいた後、利用していただかないといけない。利用率を上げるための最大のハードルはログインするところ。社員番号で手軽にログインできるのが付加価値
  • 工藤さん: IDaaSのようなユーザー企業自体でID管理を持たずにsalesforceやAzure ADを使っている場合、どういうインパクトがあるか
    • 浅賀さん: IdPが必要になった場合、SIが発生するとかハード買うとかの工数がクラウドのメリットに反している。IDaaSと組み合わせて安価にできるとクラウド利用も普及するだろう
    • 関根さん: 使いやすくするための手段としていろいろ出てきてほしい
  • 工藤さん: 最後にエンタープライズアイデンティティの活用としてはOIDFとしてもWGを作っている。ID連携やプロビジョニングのAPIが標準化されようとしている。なかなか日本からの参加が少ない中で活動している

2014-02-16

JICS2014レポート(1) 1/14前編

2014/01/14に学術総合センターで行われたJICS2014に行ってきました。当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。

ビッグデータアイデンティティ

城田真琴さん
  • ビッグデータ=ビッグリスク?
    • 企業のビッグデータへの取り組み状況
      • 日米英独中の中では日本の取り組みが遅れている。中国は「すでに」「試験的に」を加えると50%超え。日本は10%未満
  • ビッグデータリスクの事例
    • 事例1: Target(米、大手スーパーマーケットチェーン)の例
    • 購売行動に合ったクーポンを送っている
      • 毎年4月に水着を購入する顧客 → 7月に日焼け止め、12月にダイエット本
      • 女子高生に妊婦向けクーポン → 「高校生に妊娠を勧めるのか!」とクレーム → 実際に妊娠していた
      • sensitiveな情報をなんでも把握してもいいのか、さらにクーポンを送ってもいいのかと物義をかもした
      • ここから学べること: 法にふれないからと言って何でもしていいのか
        • 消費者の気持ちを推し量るべき
        • Target自体はプライバシー/コンプライアンスに対して保守的な企業であった
        • 購売履歴と関係ないクーポンを混入させるように工夫
        • 法令遵守は必要条件であって十分条件ではない、顧客の信頼を得ることが重要
    • 事例2: フロリダのDisney World「MyMagic+」
    • RFIDの入ったMagicBand(リストバンド): ホテルのルームキー、チケットとして機能
    • 相当の個人情報、プライバシー情報を収集している
      • 事前にWebで全員の名前、誕生日、ファストパス希望情報を入力
      • 入園後、売店で何を買ったか、どのアトラクションで遊んだか、位置情報、待ち時間、ミッキーと握手をしたか(ミニーか)などの情報を収集
    • 利用者のメリット
      • 好きなキャラクターが建前を読んでくれる
      • アトラクション、レストランの予約ができるFastPass+
    • 学ぶべきこと
      • サービス開始に際に収集する情報の内容・目的・オプトアウト方法・第三者提供の有無、動作の仕組などをFAQとして詳しく公開している → 利用の有無は利用者にゆだねる
        • 透明性を確保することが重要
  • ビッグデータ活用の高度化に向けた事業者側の狙い
    • 現在: 自前で収集したデータの活用
    • 次のステップ: 他社データの利用
    • 自社(単一)→自社(複数)→他社(単一)→他社(複数)
      • 右に行くほど、得られる価値も大きいがリスクも大きくなっていく
    • 目指すのはあらゆるチャネルからのデータを活用した真のCostomer 360degree view
      • お客様のことをもっとよく知りたい → その人に最適なサービスを提供・推奨できます
    • 困難を極めるマルチデバイス時代の消費者行動の全体像の把握
    • ポータルサイトとの連携
      • O2O online2offline: ネットとリアルの消費者行動の結びつけ
      • Y!J + CCC / Y!J + SAISON
      • 事例: Y!J + SAISON
        • Y!ロコでキープ(お気に入り) → そのお店で買物 → クレジットカード情報とY!IDをひもづけると2000ポイント
        • 本当に買物をしたかどうか、クレジットカードの決済履歴でわかる
      • 事例: Amex「Link, Like, Love」
        • クレジットカード番号とFBアカウントのひもづけ
        • いいね!、4sq チェックイン → クーポン券(Amexカードで決済したら15%引など)
  • 参考) インセンティブの違いによる個人情報の提供許容度
    • ハードルが低い: 年齢、性別、居住エリア
    • ハードルが高い: 電話帳情報、友人知人の連絡先、FBなどSNSのID
  • 事例
    • 原資なしで会員IDのひもづけ → クックパッドとアイディーズ
      • ユーザーが自分でひもづける
      • 今日のお買得品からレシピが見られる
    • 楽天グループ約40のサービスから成る楽天経済圏の構築 → 横断的な追跡
  • 活用の進展
         自社データ       他社データ
 ネット  Web              Web Giant(G, FB, Y!)
         ↑↓        //
 リアル  リアル店舗  ←→ ポイントカード業者(CCC, ロイヤリティーマーケティング等)
  • ビッグデータ活用の高度化に向けた法規則動向
    • EU 「オプトインでないと勝手に収集してはいけない」
      • 2012/5 クッキー法: 事前に同意を得ないとクッキーを出してはいけない
    • 米 「プライバシー憲章」
      • クッキーのオプトアウトサイト: どんな情報を収集して何に使うのか書いている
      • 透明性を担保
    • Do Not Trackを使ってブラウザによる意志表示
      • 広告会社がちゃんと自主規則してくれるか → 業界まかせ
      • CA州 オンラインプライバシー保護法(CalOPPA)
        • DNTに対する対応方法をちゃんと書かないとUSD2500の罰金
        • 例: LinkedIn: 使わない、DNTも使わない
        • trackingしてるなら「してる」と正直に書け、という法律
    • 将来像
      • 消費者本人が自分のデータを管理し、提供先を選択
      • 自分のデータを電子データとしてダウンロード → パーソナルデータストア → 提供したいところを選んで提供
      • 英: midata、米: Smart Disclosure、日: 情報銀行??
    • 行動トラッキングに対する受容性
      • トラッキングされたくない 4割くらい、自分でコントロールしたい3割くらい
    • パーソナルデータの利活用に関するWG
  • まとめ
    • 事業者の狙い: customer 360度view       ←┓
    • 消費者は常にトラッキングされることを好まない ←┛ ギャップ
    • 将来的には英米のように自分でコントロールできるようになっていく
Pat Patterson 「Identity in the Cloud」
  • Pat Patterson@Salesforce @metadaddy
    • principal developer evangelist
    • salesforceに入って3年強
    • sun microsystemsでOpen SSOのコミュニティーleadをしていた
    • IDの仕事をして10年
  • Safe Harbor
    • salesforceのプレゼンのときに必ず見せている。今日の講演の情報を元にSFの株を買わないでね、という内容
  • Identityのこれまでの問題: 会社の中で従業員のアクセス管理
    • 社内、firewallのみ
      • 財務情報は関係する社員だけが扱える、社員が必要な情報にアクセスできる、など
      • わかりやすい世界だった
    • いまは、社内ネットの外からのアクセスが必要
      • 今日この会場から社内ネットにアクセスした人、挙手! → 20人くらい / 200人くらい
    • IT部門もID技術を連携して社外からのアプリ使用を行えるようになってきた
      • アプリはインターネットの外にあるので、firewallだけ心配していればよいという時代は終わった
      • 企業によってはインタネットも社内も信頼度(level of trust)は変わらないところもある
      • 多くの企業が協業しているパートナーとデータ(の少なくとも一部)を共有する必要がある
      • IDを持っているのは人間だけではない。製品もAPIをアクセスする
      • ID数は社員数よりオーダーが違ってくる
      • many apps, many access, from any of locations in the world
  • Solutions?
    • identity platform: salesforceの設計思想を紹介
      • cloud-based
        • 2014現在、起業しようとするときにサーバーやCRMを買う必要はない。ID管理のためのサーバーを買うなんて考えられない
      • interoperability
        • たった1社のみのアプリを使うとは考えられない
      • mobile-enabled
        • モバイルが一番のアクセス元になるはず
      • internet scale
        • millions of customers, partners, devices: 社員数とは桁が違う
      • single point of control (一元管理)
      • Webの民社化
        • 規模を問わず、あらゆる企業が利用可能(大手企業だけがID管理できるのがこれまでの世界)
      • core application platform
        • identityはアドオンではなくコア
  • SFの相互運用性に関する戦略
    • マルチテナントシステム → 標準化がキー戦略
    • SSOの標準は依然としてSAML2.0
    • OAuth 2.0: APIに対して安全なアクセス
      • SAMLと協調して動く必要がある
      • モバイルアプリはOAuth2を使ってAPIアクセス
      • 例: ユーザーログインは企業内でIdPを使ってログインする → SAMLと連動してトークンを送る必要がある
    • SAMLは古くなった。XMLベースなのでintegrationが難しい
    • → そこでOpenID Connectだ
      • OAuth2と親和性がよく、新しいアプリから使いやすい
  • Internet scale
  • SF ID Platformを絵にすると
    • central control of identity and policies
    • 中小企業の場合、リポジトリとして扱うことができる
      • 大手ならADやLDAPかも。SAMLを使ってplatformに持ち込める
      • SFではADからのintegrationはカンタン
    • G+, FBからのidentityを持ち込むこともできる
    • 顧客コミュニティーにとってはすでに持っているIDの活用が重要
    • いったんSF identity controlに加えれば、社員/パートナーがアクセス可能
    • identity platformがSFのコアにある。SF上の行動はすべてID platformによってgovernされる
  • クラウドの中核にはidentityがある
    • デモ: SF岡本さん
    • グーグルIDでログイン → OpenID Connectを使っている
      • IDトークン内のemailで突合してログインさせるデモとなっている
      • 連携の取り消しもできる
    • 社外パートナーからのアクセス: ポータルIDを発行しケース(問合せ対応)データだけを見せることが可能
      • FBアカウントとポータルIDをひもづけ
      • FBアカウントはnative APIとして登録
    • Salesforce IdPを他のRPと連携させて使うとも可能

JICS2014レポート(2) 1/14中編

13:00-14:00 基調講演

レイヤー化する世界とID 佐々木 俊尚さん
  • 「安心社会から信頼社会へ」山岸俊男
    • 一般的信頼 vs ヤクザ的コミットメント
      • 米: 信頼する
      • 日: ムラ型、信頼しない
    • ヤクザ的社展 → 一般的信頼への移行?
  • 「ケンとメリーのスカイライン」「青春の殺人者」の'70年代的世界観
  • グラノベッター「転職」
    • strong ties / weak ties 理論
    • どちらが自分が社会生性年送る上で重要か
    • weak tiesから転職などの情報が入ってくる
      • 当時の皮膚感覚とは逆の主張だった
      • 知らないところの人のほうが情報を持っている
    • 訳者の渡辺さんいわく
      • '80年代の日本ではstrong tiesから就職情報が入ってきていた(コネ入社など)
      • 現在はweakの方が強くなってきているだろう
  • 米国は一般的信頼社会、weak ties型と言われてきた。でも、そうでもない面もある
    • 「On the Road」 一般的信頼の時代('50年代)
      • → '70〜'80年に劇的に低下
      • メディアの発達により、猟奇的殺人者の報道がなされるようになった
      • → 気ちがいヒッチハイカー、よそ者に警戒するようになった
  • 2000年代からまた変わった
    • 牧歌的信頼関係の復活
    • airbnb: 個人民宿サイト
      • FBアカウントを見れば、宿泊希望者の人となりがわかる → 安心して泊められる
      • 信頼の担保としてのSNS
    • lyft: 車の相乗りサービス
  • 日本におけるシェアハウスの流行
    • fb, twが信用できるかどうかの評価ポイントになっている
    • SNS → 信頼性の補完
      • → 新しい意味でのセーフネットとなる
      • → identity公開とのトレードオフである
  • 「総透明社会」と到来
    • private - public の境界線のゆらぎ
    • 環境管理型権力 … 「生政治」biopolitics ミッシェルフーコー
      • → 逆転: 政治も私的な生に侵食される
      • ファシズム的でもあり、生政治の逆転とも考えられる
  • 当事者性
    • 情報発信に対する態度: 発信者 → 反応者 → 観察者; そして無関心者
    • インターネット: 誰も観客にはなれない発信
      • cf: 観察者を意識した発信
    • 参加しなければ得られるものもない
  • 個人として考えるべきこと
    • 「他者」を受け入れること ┓
    • 「透明」を受け入れること ┣ が必要だよね
    • そして寛容であること   ┛
ID連携の必要性とセキュリティ 谷脇 康彦さん
  • 情報共有の重要性
    • 3.11: sinsai.info → googleマップとのマッシュアップ
      • ホンダが中心となってカーナビ情報をマップ上に表示、通行可能性情報
    • 情報 → 集積 → 蓄積 → 見える化 → 価値
    • 自治体情報 + 医療情報のマッチング
      • → 避難所で足りない薬の把握
  • 「情報をつなぎ合わせる」ことの重要性
  • 「世界最先端IT国家創造宣言」 2013/6
    • オープンデータ、ビッグデータ
    • 情報流通連携基盤の必要性
      • API        ┓
      • データ形式    ┣ 違うので進まない
      • 個人情報の扱い  ┛
  • Big dataの4分類
    • オープンデータ: machine readableにする
    • 知のデジタル化: 農業クラウド…老農夫のノウハウ、経験と勘の記録
    • センサー等のM2M: 車のプローブ → 信号間隔の調整
    • パーソナルデータ
    • → これら4者の活用、デザイン思考、異分野活用との組み合わせが重要
  • 東北メディカルメガバンク計画
  • パーソナルデータの利活用
    • プライバシー保護との調和
      • 適切なバランス            ┓→ 国際的調和
      • すでに蓄積されたデータは海外にもある ┛
  • パーソナルデータの利活用 制度見直し方針: 2013/12
    • 提案: 実質的識別性
      • 一律ではない、個人主体の許可、制御する権利
      • 2014/6までにとりまとめ → 2015国会提出を目標とする
  • 匿名化技術の活用とルール
    • 再識別を避けるには?
  • マイナンバー
    • 国・各自治体のシステム改修が必要
    • 自分の情報のログを自分でチェックできる
    • → 自治体クラウド
      • 検討事項(付則)
      • 3年後をメドに特定情報以外の活用 … 官民連携
    • トラストフレームワーク
      • Trust Framework Provider ← Policy Maker
      • IdP ← → Service Provider
      •   利用者
    • 民民から検討
  • サイバーセキュリティー
  • まとめ
    • 情報流通連携基盤づくり
      • 領域に閉じない連携 ←→ 個人情報の扱い
    • ID連携を通じた新たな価値・産業が生まれる
    • 平時に使っていないと非常時に使えない
    • 個人の情報コントロール権を確保する仕組み
    • 民間ID連携とSSO
    • LOAの類型化
    • IDフェデレーション型モデル: トラストフレームワークの官民連携

JICS2014レポート(3) 1/14後編

事例から学ぶID漏洩防止

  • 14:30-16:30 セキュリティートラック
  • togetter
根岸征史さん @ IIJ
  • 「情報漏洩事例から見えてくるユーザによるパスワード利用の実態と課題」
  • パスワード
    • 何十年もずーっと使われている。ずっと変わっていない
    • ユーザー視点 → 根岸さん
    • 攻撃者視点 → 辻さん
    • サイト運営者視点 → 徳丸さん
  • 情報漏洩事例(国内) 2013年
    • Y! 2200万件
    • OCN 400万件
    • NAVER 200万件
  • 海外
    • Adobe 1億5千万
    • Evernote 5千万
    • Living social 5千万
    • Cupid media 4千万
  • Adobeの例
    • 2013年10月
    • 「お客様のIDは攻撃を受けたデータベースに含まれていたものの、パスワードは影響を受けなかった」→うのみにしてはダメ
      • ヒント情報も漏洩している → ちゃんと書け
    • 9.3Gバイトのテキストファイルに1億5千万
      • メールアドレス、3DES
      • ECBモード → saltがない。誰と誰のパスワードが同じかわかってしまっていた
      • パスワードのヒントも平文で保存されていた
        • ヒントにそのまま書いてる人もいる「1〜6」とか
    • Adobeのパスワードトップ10
      • 123456が190万人とかとても信じられないものが並んでいる
      • トップ10だけで全体の2%くらい。これが実態です
      • JPドメインのIDに限ると、少し良くなる。数字の並びが多いのが日本の特徴
      • Gawker, LinkedInなどを持ってきても傾向は同じ
  • IDを入れると漏洩したか調べてくれるサービス
    • 他社の例を見て自社ユーザーに影響あるか調べる会社もいる
    • Evernote → 該当ユーザーに注意喚起: メアドだけチェック
    • Facebook → 自社ユーザーがそのパスワードを使っているかチェック。使い回していたらパスワードリセット
    • Y! J, Vimeo → 該当ユーザーのパスワード全部リセット (メアドだけでチェック)
    • ユーザーのとまどい「なんでAdobeからメール来てないのにEvernote来ちゃってるの?」「おれ使い回してないのに」
    • 被害が出るのを救うか巻きぞえでリセットされるかのトレードオフ
  • 2013年意識調査
    • 使い回している8割
    • 強いパスワード3割くらい
  • まとめると
    • 現実として弱いパスワードが使われている
    • 現実としてパスワードが使い回されている
  • 弱いパスワードの例
    • 他人にかんたんに推測される
      • telepassword
    • 総当たりで破られる
      • GRC Brute Force Search Space Calculator
      • 探索空間の広さを教えてくれる
    • 過去に漏洩したものを使っている
      • 2億4千万件の漏洩したパスワードを売っている
  • どういう世界が理想?
    • パスワードがダメだ
    • パスワードだけじゃダメ → 2要素
    • 使い回しできなければいいんだ → ID連携
    • ユーザーの責任だ
    • ユーザーがんばる/がんばらない × サイトがんばる/がんばらない
      • 両方がんばらない方法: OSやブラウザががんばる?
  • 論点
    • この先もずっとユーザーの責任?
    • サイト運営者はどこまでがんばればいいのか
    • 途中のプラットフォーム(ブラウザ、iPhoneのキーチェーン)ががんばるべきか?
    • どうすればうまく合意形成できるのか?
    • 責任分界点はどこなのか?
辻伸弘さん @ NTTデータ先端技術
  • 「パスワードの破られ方入門」
    • tsujileaks.com/ntsuji.pdf
  • 自己紹介 @ntsuji
    • 元侵入テスター → 攻撃側視点
    • 普段はanonymousあたりの観察をしたり
  • はじめに
    • 定期変更なんてイヤだ!
  • 攻撃手法いろいろ
    • brute force攻撃
    • 辞書攻撃、置きかえ(1→!、a→@など)
    • reverse攻撃: 弱いパスワードを固定して多数のIDを試す
    • リスト型攻撃: ID、パスワードの対をリストにして、使い回しを試す
      • どこから入手する? → 盗む or 買う
  • ツールあれこれ
    • medusa, キングギドラ(?), ncrack
    • デフォルトID/パスワード対のリスト
      • routerpasswords.com など
    • packetstorm, johntheripperなど
  • 流行としては…
    • 攻撃の流行りすたり
    • 最近は→リスト型
    • Adobeの漏洩では「adobe123」はリストにのっていない辞書にある単語のパスワード
      • 高いリスト買わなくても、辞書攻撃でいけるのでは?
    • 流行はあるものの、流行だけが危ないわけではない
    • 辻さん: 攻撃者はとっても有利。ぼくらが「どうすんねん」と言ってる間にどんどん弱いところをついてくる。こういう状況がずっと続いている
  • さいごに
    • 対リスト型攻撃 → 使い回しをやめる
    • 対brute forse → 質の高いパスワードをつける
  • 自分を母親が使えるような技術を採用したい
徳丸浩さん @ HASHコンサルティング
  • 「サイト運営者はパスワードリスト攻撃にどこまで責任があるのか」
  • パスワードリスト攻撃とは
    • 脆弱なサイトを攻撃して入手したパスワードリストで脆弱性のないサイトに入力してみると、一定の確率で入れる
      • 社会実験をしてみる人が多数出てきて迷惑しているw
  • 背景にあるのはネットの「格差社会」
    • 2005年ごろはほとんどのサイトが均等にぼろぼろだった
    • 2008年ごろから、よくできてるサイトが目立ちはじめた(格差)
      • 格差を利用して弱いところから抜いて強いところを攻めるようになってきた
    • ユーザー間にも格差がある
  • アカウントロック
    • ログインID毎にパスワード間違いを記録し、連続してN回間違えた場合、X分アカウントを無効にする
    • パスワード認証の保護機能の基本
      • しかしジョーアカウント、githubへの弱いパスワード攻撃などには有効でない
  • githubへの弱いパスワード攻撃
    • ゆっくりと、異なるIPアドレスから5回だけ試し、もう来ない
    • → 検出・ブロックが困難
  • IPアドレス単位での認証ロックあるいは監視
  • 2段階認証 & リスクベース認証
    • サイト側負担が大きい
  • ログイン履歴確認
    • 防御はできないが気づきがあるかも
  • パスワードの辞書チェック
    • パスワード変更時に弱いものをはじく
      • tw, g, fb, githubが使っている → これらのサイトはIDが公開だから?
  • 辞書、リスト、フィッシング、MITBに対する防御は、利用者の責任管あるものをサイト側が救済しようとしている
    • 本当にやらないといけないことは何か?
      • 長いパスワードをつけられるようにしておく
      • 1文字のパスワードをつけられたら、それは脆弱性? → ユーザー責任じゃねーの
  • パスワードリスト攻撃の登場人物
    • おもらししたサイト
    • 攻撃されたサイト
    • 攻撃者
    • 不正ログインされた利用者
    • 1番目 → 攻撃者
    • 2番目 → おもらししたサイト → わからないので出てこない
      • ハッシュ、ソルト、ストレッチで守る責務がある
    • 3番目 → 利用者: 使い回しをしていた責任
    • 一番悪くないのは攻撃されたサイト。正直守りようがない
    • でも利用者にも言い分が「ぼくパスワード認証使いたいとは言ってないもん!」
  • まとめ
    • パスワード認証のタテマエとして管理は利用者の責任という考え方がある
    • でもそれ無理だよね。そもそもパスワード認証したいとか頼んでないし…
    • サイト運営者の努力だけでは守り切れない面がある
パネル
  • 楠さん Y! ID本部長
    • 就任2日目で大規模な漏洩事件が
    • 「パスワード認証」50年残っているIT技術はなかなかない
    • 1965年passwdファイル公開の vulnerability 報告。来年が50周年
  • 主旨
    • 答を出すパネルではない
    • インターネットにターゲット
  • パスワードとはそもそも何か?
    • 合言葉、クレデンシャル
    • メリット・デメリット
      • 意識と記憶が正常なら安定して出力可能
      • 概ね人体(=本人)のみで完結
      • 任意の使い分けが可能
      • 記録・複製・伝搬が可能(=残念ながら自分の意志とは別に)
      • 変更時は相手との同期が必要
  • 根: 本音とタテマエのところで、使い回すのは悪いが、現実そういう人はいる。一方、パスワードはここ数年ではなくならない。そういう人を救うには極端な例でもいいからどういう方法があるか出してみてはいいのでは?
  • 徳: 成立してはいなくてもそこそこ攻撃を受けているサイトさんで、ユーザーがITに強くない → 1回パスワードリセットしてみては? → それ攻撃を受けたみたいだからイヤだ → 全国一済パスワードリセットデーをやってみてはどうか(無理っぽい)
    • 根: リセットしてもまた同じのつけるんじゃないかな
  • 根: ユーザーにパスワードつけさせるのが悪いのでは?
    • 徳: それはアリ
  • 徳: パスワードを表示するので回りに見られる人がいないことを確認して表示ボタンを押せ → 根: 覚えられないですよね!
  • 楠: パスワードどころかIDも忘れる人もいる。サイトの都合でやれ○文字だ、使い回すなと言われても困る
    • 楠: 複雑なパスワードを人に覚えさせるくらいなら、エントロピーの高いトークンをマシンに覚えさせればいい
    • 根: 押しつけるよりは置き換えるものが作れると思う
    • 楠: 技術的には可能だが汎用性がない。パスワードが果たしてきた役割が大きすぎて、結果としてuser firstで考えられていない。他の方法をつきつめて考えるプリンシパルが必要
    • 根: FIDOのやつは?
      • 林: グーグルのUSBキーボードの形のやつ。それをみんなが使えるかというと難しい。みんなの学習曲線よりも早く世の中が変わっていて、それがつらい
  • 楠: ユーザーにとってパスワードや暗証番号っていつから使っているのか。コンシューマにとってのパスワードはいつから?
    • 林: ダイヤル式鍵前が4桁
    • 楠: 4桁をこえるとパスワードとは呼ばないのでは? 住基パスワードリセットに30分かかって終わらない事件もあった
    • 楠: 4桁PINとパスワードは違うものとは認識していないのでは
  • 根: トークンをみんなに配ってとか大変。パスワードマネージャは?
  • 徳: トークンハンドリングを人手でやってるのがおかしいというのはそのとおり
  • 楠: 銀行カードの番号は奥さんにも教えてる。しかしY!のパスワードは教えない
  • 林: パスワードマネージャで言うと、googleにはパスワードっぽいところにランダム文字列を入力する機能をもっている
    • 楠: パスワードマネージャは可逆暗号なのでドキドキする。キーチェーンもiCloudなのかローカルなのかわからないので、うっかりワイプしてしまうリスクがある
  • 楠: ヨメさんに知られるのがイヤなだけで米政府に知られる分にはいい
  • 徳: これがダメとか言い出すとどれもダメなんで
    • 楠: 魂を売るのか問題になる
  • 楠: 相矛盾している神話がある。使い回すな、定期変更しろ、同じの使うな、とか。無理ゲーを強いられている
  • 辻: 毎回リセットしてる「なんちゃってワンタイムパスワード」をしてるとはいる「パスワードを覚えられない人はこちら」
    • 毎回リセットは覚えられない人がいるほどはめんどくさくない
  • 楠: パスワードリセットできない人は時々いる。「自分の誕生日を忘れました」という人がいる。ウソの情報でアカウント作って、後でリカバリーできなくなる
  • 楠: Evernoteが何で全件リセットできたかというと、到達可能なメアドが割と新しかったということ
  • 徳: ひみつの質問はなんとかなんないですか?
    • 楠: もう少しかかります。しかしこれもトレードオフ
    • 根: 事業者ごとの判断も難しい。ここまでやっとけばOKというのを作っておかないと、事業者コストがどんどん上がる。結局損をするのはユーザー
  • 楠: 生体認証はリカバリできないので、パスワードを最後の手段として残してある。一番弱いものを使わざるを得ないのが難しい
    • 辻: 攻撃側はローリスクでハイリターンが欲しいので、弱いところを狙うよね
  • 林: インターネットで一番弱いところがあると全部弱くなってしまうというのはショックで、みんなで歩調を合わせていかないと。これは国をまたいで攻撃が来ちゃうので、議論を進めていきたい
  • 根岸さん: 他から漏洩したときに自分も対処しないといけないので難しい。今後ウォッチし続けないといけないとすると、どうします?
    • 楠さん: やや緊急避難的に今回は対応しました。同様のことがしょっちゅう起こってもらっては困る
  • 楠: パスワードリスト攻撃、できることはある
  • 辻: 本当は攻撃したやつが教えてくれたら一番セキュアだが、それは無理
  • 辻: パスワードのつけ方とか、学校の教科書にはとてもいいことが書いてある。草の根的に「今日お母さんに教えてね」ってやらないと、我々では限界
  • 根: みんなでやっていかないといけない部分がある
  • 徳: カンタンログインはたたきつぶす立場なのですが、UI的にはよくできている。パスワードなくしたというのが大きいと思う。カンタンログインは技術的に残念なところがあったが、良くしていけばいい。アプリ認証が万全というわけではないが普及していけばいいと思う
  • 根: ID連携に乗ったらみんな幸せなのか。懐疑的なんですが
    • 楠さん: ID連携みんなしたいのか。事業の根幹であるユーザーリストを預けてこっちがお金を払うとかあり得ないでしょ。twやfbがうまくいったのは書き込みしたいから。そういうはっきりした価値を示さないとフェデレーションは進まない。事業者都合やユーザーがパスワード覚えたくないだろうというだけで押そうとすると、MS Passportの失敗から学んでいないだろうと思う
  • 辻: どうでもいいところだけ連携するのはどう?
    • 林: そういう目的でgmailアカウント取っている人はいる。意識的にせよ無意識的にせよやっている人はいる
  • 徳: 自前のパスワードつけるところには税金をかけるのはどうか
    • 楠: 海外にサーバー置くだけではないか
  • 林: 日本のIDって価値が上がっていると思いませんか? 日本語フィッシングメールの日本語がだんだん良くなっていますよね
  • 楠: 言語バリアに守られていたが、そのコストを無視するようなメリットがフィッシングに出てきたということだろう
    • 徳: 昔のケータイの公式サイトはIPアドレス制限をしていたので、あれは結果的に相当のバリアだった
    • 楠: IP鎖国するとLINEのようになる芽をなくしてしまうことに
  • 根: 格差ということにはドキッとした。これだけの対策ができるのは大手だけだよなあ、救わなきゃいけないユーザーもできてない人達なので
  • 楠さん: bitcoinマイナーのASICを使うと10^18 hash/sec行けてしまう。そのへんの危機感が共有されていない
    • 根岸さん: 攻撃側、解析側の能力向上がサイト運営者に伝わっていない感がある
  • 徳: 徳丸本でストレッチを書いたけど、レビューアにも抵抗があったようだ。書いといてよかったー
  • 根: いまはストレッチ5000、1万なんてのが普通なんですが、そういうことがわかっていない
  • 楠: パスワードマネージャが流行ったとたんにPMのふりしたマルウェアが出たりすると手に負えない
  • 根: PM使うとひとつのパスワードで全部やられちゃう。そういうリスクが評価できるのか。専門家しかできないだろ
  • 徳: (Y!さんの)ひみつの質問と答に関する確約をいただけたのが個人的にうれしい。リセットが安全になればパスワード管理の手間が助かるなあと
  • 辻: 「パスワード覚えられない人はこちら」を生みだせたのが今日の収穫w 使えない人が追いてけぼりを食ってしまうものだけは、なくしていきたい。それがITかな、セキュリティーかな、と思っている
  • 根: 普段は専門家としての立場から見ているけど、パスワードというのが使いにくい世間になってきている。うまい落としどころをさがしていく、答はないけどみんなでさぐっていくのが大事と思った
  • 楠: おととしの秋くらいから兆候があった。十数年やってきたパスワード管理のバランスが変わってきてしまった。過去からの経緯でこうなっているが、道具がそろっているのに惰性で続けてきたことが怪しくなってきている。これまでぼくらはわかっていながら何をやってこなかったかをよく振り返ってみたい

ジェネラルパネル: ビッグデータの可能性と現実

  • 参加者
    • モデレータ: 佐々木さん
    • パネリスト
      • 喜蓮川さん: NII所長
      • 板倉さん: 弁護士
      • 吉井さん: SBテレコム
  • 喜蓮川さん
    • 情報爆発なんとか H17年
    • 情報大航海プロジェクト 著作権法改正、検索エンジン合法化
    • ビッグデータに向けたデータベースエンジン
    • ビッグデータ、解析以前に「どう作るか」が問題
      • ミレニアム Development ゴール
      • 幼児医療、開発国の医療など: 向うではカルテは毎回もらうもの → 認証技術でなんとかしたい
    • 世界ではデータがないところがマジョリティーである
  • 吉井さん
    • bigdataは儲かっている(グローバルに見れば)
    • ビッグデータビジネスのエコシステム
      • 広告主 - ユーザ行動追跡 → 解析
    • 個人、データ収集者、データブローカー、利用者
    • ビッグデータはグローバルにはbig business → target広告など
    • 名寄せは善であり進む…関連を見出すことに価値が生まれる
    • プライバシーの話になると極端なことを言う人がいる
    • 「程よりプライバシー」が必要
  • 板倉さん
    • 内閣官房レベルになった
    • パーソナルデータ利活用に関する制度見直し
    • 6月の大綱に入れないとまに合わない
    • 毎年改正すべき(独禁法と同様なやり方)
    • 特定個人情報保護委員会で業務開始
    • 日本の法制備は遅れている
    • NSA事件があって、米国にデータを置きたくないという人が増えている
      • → EUに適合するように作れば、日本に持ってこれる!
  • 半導体でかつて勝っていた → 負けた
    • PC → Wintel
    • 情報家電、液晶 → 中韓に取られた
    • bigdata → last frontier と位置づけるべき
  • Social Machines
    • Internet of Things (IoT)
      • センサーで得た情報がソーシャル化される
      • IoTの中にSNS行動が組み込まれる → bigdataとして集約
      • アベノミクス第3の矢?
  • 佐々木さん: 何を突破すれば次のステップに進めるのか。今後のビジネスの突破口は?
  • 喜蓮川さん: 人間の行動と IoTをfusionする
    • 人とくっつけちゃうと Personal Dataになる
      • Personal Informationと言うと扱えなくなっちゃう
    • データのオーナーシップがはっきりしないことが多い
    • 東大にボーイングのVPが来たときの話
      • 飛行機に乗客にビデオを見せるシステムがある
      • あの視聴データは誰のものか? ボーイングは使っていいのか
      • → 参加プレイヤーが多すぎる(機体製作会社、航空会社、コンテンツの映画会社、システム開発者)
  • 佐々木さん: チャネルになっていればいいが、レイヤーだとどのレイヤーかわからない
  • 喜蓮川さん: データは国の財産だ。なにかというと「cool」に行ってしまう風潮はどうかと思う
  • 佐々木さん: コンテンツより流通構造が重要なはず
  • 吉井さん: bigdataやりたいが社内でも止めたがる
    • 名寄せしたい ← やめなはれ
    • privacy commissioner を置いてほしい
    • こういう使い方をしたいですよ、と見せると、OKとかNGとか言ってほしい
    • 気持ち悪さだけで話してほしくない
  • 佐々木さん: 顔認識カメラ実験 → 法的には問題ないのにキモチワルさで怒る人が多い
  • 板倉さん: 個人情報保護法でもそうだが、合意は無敵。一方で小さい字で書いて押させる流れは自爆的
    • 本人にリーチできるんだから、ちゃんと説明し、後からこんなことしてたとは知らなかったと言わせないようにする透明性が必要
    • わかんない、言わないでやった → キモチワルイの元
    • クリックさせればいい、ではなく、わかってもらうことが大事。UIデザインも重要
  • 佐々木さん: 医療学会では症例が出てみんなで学ぶ・共有することが求められている
    • 個人情報は削除するが、共有が前提である。一方で難病になるほど名寄せされやすく、共有が必要なのに難しくなる
  • 喜蓮川さん: オープンガバメント、オープンデータ
    • 「この人には開示する」をどうコントロールするかという問題。
    • 枠組をちゃんとつくるのが、少なくともヘルスケアには大事
  • 板倉さん: 日本は相当厳密な手続きで開示している。医療は別途法律をとりまとめるとして話が進まないままになっている
    • 包括して検討するには、やはりケースを持ってきてもらうしかない
  • 喜蓮川さん: IDとか公開していいものはもっとあるはずだ
    • 名寄せしないことにはビジネスは進まないよね
  • 吉井さん: 公共権という考え方がある。
    • 街中で顔かくすためにマスクする人はいない。同定率が80%〜90%ならいままでと同じなのではないか
    • 技術的にどうしようもないのがmac addressやbluetoothアドレス。これは受け入れないとやっていけない
    • 透明性が上がればよいのではないか。技術的に上がればいけると考えている
  • 佐々木さん: BT LEではペアリングなしでつながる。iPhone持って店に入るとすぐわかるようになる
    • NFCの代わりに決済できるよね。GoogleNFC押しである
    • 個人のデバイスのIDがビジネスに役に立つというのは、これもダメと言われると何もできなくなってしまう
  • 佐々木さん: プライバシー法制度の問題とキモチワルさの問題、これは構造的になんとかなるのではないか
    • netflixで1億人から2人を特定したという例がある
    • バカッター(ツイッターの炎上事例)でも特定できてしまう
    • 儀礼的無関心」が必要
      • これはマナーとしてできてきた概念
      • レストランでとなりの人が何を食べてるか、じろじろ見ない、というマナー
      • こういう方向はありえるのではないか
  • 喜蓮川さん: マナー、は拘束力がないので、やってもしょーがないという許容範囲を考えたい
    • しかしPasmoの乗車履歴のような情報は、人が殺められる可能性まである。これは規制したい
    • 自分が言ったことで起こりますというと、誰もせめられない
    • こういう世の中になったんですよ、説明していくしかない
    • → 教育の問題として考えるべき
  • 吉井さん: 技術的に言うと日本人の平均的なプログラミング能力は高くない
    • その教育によってITの仕組みや名寄せのタイミングなどが理解できるようになるだろう
  • 板倉さん: バカッターはデータ保護法制で救うべき範囲ではない
    • 「privacy by default」という考え方がある
      • google+はnewsgroupからの発展なのでオープンが原則でありデフォルト
    • 民民では官が統制できない。プライバシー侵害のまとめサイトは法規制できるかも
    • 人の信用にダメージをつけることで儲けることを社会として容認するのかという話
    • 教育でなんとかするのは、2才児でもSiriもYoutubeも事実上使えてしまう以上、難しい
  • 喜蓮川さん: 教科情報が大学入試にとりあげられていない
    • 「大学入試に出ない科目をどうして勉強するのか」と言われるとぐぅ…となってしまう

2013-11-30

idcon 17レポート

11月29日に行われた #idcon #17 に行ってきました。会場はmixiコラボスペースです。

今回はNext Generationとして若い世代のプライバシーに関する感覚が聞けました

@IdentityPenguin "IIW #17 報告"

  • 名前が目立つのか覚えてもらえた
  • 「ねえ、ペンギン」とか話しかけられるw
IIW#17 10/22-24 @Computer History Museum
  • 「four principles of unconferences」
  • ワークショップの進め方
    • 基調講演もプレゼンもなし
    • 初日にアイスブレイク的な
    • 学ぶこと、貢献することに情熱を持つ参加者主体で進める
    • 毎朝、セッションと時間割を立候補で決める
    • 夕方、一番貢献した人を決める
初日、冒頭のディスカッション
  • お題を与えられてテーブルに分かれて座る
  • 各テーブルに必ず新人を入れる
セッションのお題決め → スロット割り当て
  • 早い者順、他のセッションとのカブり具合を見ながら
topics around "Name"
  • NYM issues (pseudo-nym) Why do we need "real" name policies?
  • Personas and Privacy
  • real nameって何だ?
    • 戸籍名とは限らない。realなactivityが結びついているものをreal nameと考える
  • ペルソナって?
    • カカクコムではこれ、他ではこれ、という風に名前を使い分けているということ
Online data & ID after death
  • エンジニア、心理学者など多様な参加者6名
  • プライバシーとしての故人データ
    • 生きている間はプライバシー権としてコントロールするとして
    • モノと違って、これは誰に、という風に手渡しで分けられない
    • 何十年経つまでは非公開、というったオプションも可能?
  • 残す、残さないではなく、残す前提で話が進んでいった
    • 基本消すんじゃないかという立場で参加したのだが
  • 亡くなった人のデータには社会的な価値がある
    • 何気ない写真、そのとき食べているお菓子、日常が歴史的な史料になる
    • むやみに消していいんだろうか
  • 「その人の物語」が受け継がれていくこともできるだろう
まとめ
  • セッション参加も楽しいが、自分でセッション立てると得るものは多い
  • エンジニアじゃなくても貢献できる & 得るものはある
Q&A
  • @nov どんなキーワードが出てました?
    • UI & Identity: どう見えてどう人の振るまいを反映させていくか
  • @_nat 何人くらいでした? → 150人くらい
    • ヨーロッパ方面が多かった

"Next Generation 枠 - アカデミックな新風"

関東学院大学のゼミ生による発表

「個人情報? 守ってますが何か?」 チーム Shiroishi Tsubasa
  • たしろひかる、にしいりゅうじ、まつおかしょうご(田中太郎)、しばさきようすけ、から一字ずつ取ってプロジェクト「しろいしつばさ」
  • 研究の動機
    • SNSの広がりによって、様々なトラブルも発生している
    • ネット上の自分の情報に関して無防備な人が多いのではないか?
    • 大学生はどこまで個人情報について意識しているか、アンケートを取った
    • 2013/10下旬、アンケート用紙による。回収サンプル数103、男40.8%女59.2%
  • アンケートの内容
    • SNSの利用状況、目的、個人情報公開・保護を意識しているか、公開範囲、公開しているもの、マークの理解度、トラブルについて(自由記述)
  • 回答者の年齢: 19歳と20歳で95%
  • 使っているSNS: LINE 100%、fb74% tw83% mixi21%
    • LINE: 連絡手段、fb/tw/mixi: 他人の状況把握、自分の情報発信
  • 個人情報保護を意識しているか → 86%が「はい」を選択
    • 実名、生年月日などは9割以上の人が公開している
    • 「意識している」という答と実際に公開しているかどうかの間に有意な差はなかった
  • 有意な差があったもの: 女子学生は男子学生に比べて、「友人なら可」が多い
  • 公開している項目の中では実名の公開率が高い
    • 位置情報はどのサービスでも公開率が低い
  • fb投稿らんに表示されている「マーク」の理解度を調査
    • 全体への公開「地球マーク」が重要であるが、正解率は低い(24%)
    • 公開範囲をカスタムという「歯車マーク」の正解は1人
    • 個人情報への意識ありという答と正解率の間に相関がなかった
  • トラブルについて
    • いくつかのサンプルが得られた
    • (このスライド、もっと長い間映すか、読みあげてほしかったです)
  • まとめ
    • 個人情報の公開や保護については多くの人が意識している
    • その一方で知識はない
    • 実名や写真の公開の割合は高く、特にオープンな環境であるtwですら実名も公開
    • 位置情報については公開しない傾向
    • 大学生を対象とした調査であることに注意しつつ、意識はあるが行動が伴っていないことがわかった
    • 安全に使うにはどうするか: 公開範囲の設定をしないとアカウントが使えない、という方法はどうか
Q & A
  • @nov: 中学生のころどんなSNS使ってました?
    • mixi, fb(高校)
    • 中3でmixiが招待制から誰でも登録できるように変わった。高校に入ってすぐmixi, fb
  • @_nat: 使うのは基本ケータイやスマホでPCではなかった?
  • 山中: ネットでモノを買うときは、スマホ? PC?
    • → パソコンが多い(学生も会場も)
  • @hiroki: アパレルのような見定めしにくいものはケータイ・PCで買うことはあるか?
    • 服だとサイズもあるし、店で試着してからPCで買うこともある
  • 「意識している」というのをどう定義しているのか?
    • アンケートで「はい」と答えた人だとすると「アンケートバイアス」がかかっているのでは?
    • はいってみんな言うと思うが、いいえと答えた人もいる
    • 「はい」の書いてある同じページに公開項目の問を置いたが、バイアスがかかった状態でも「実名」などは公開するにチェックをしている回答が多かった
  • @shingoym: 意識してるかしてないか、と言うと意識している。それは無意識に意識している。それを深ぼりすると面白い。どうして意識するようになったか、そのリテラシーをどこから得たのか、誰から教わったのか。失敗して学んだのか、親から学んだのか。質的なインタビューする必要があるでしょう
    • みなさん使い方はどうやって学んだ?
      • → 使っているうちに。設定しないといけないな、と思った → それが identityのめばえ
  • なぜ田中太郎なのか
    • → 個人情報の公開に無駄に敏感。自分はfbに名前を公開するのもコワイので田中太郎を名乗っている
    • @_nat: TポイントカードやSUICAは使っている? → いいえ
    • @_nat: そこまで徹底しているの? → そうでもない。カードはいいと思う。SNSについてはトラブルのニュースが多く心配
  • @_nat: 個人情報とプライバシーは別の概念。そういうことは意識しています?
    • → しています。
    • → 田中太郎は偽名だけどスードニムになっていて、いろんな属性が結びついていく。アメリカではreal nameっていうのは名乗った名前である。同じ名前を使い続けるとそれがreal nameになってしまう。そういうことを意識したことはあるか → いや、いまの話を聞いて田中太郎でも安心できないなと思った
  • @oritako: 先生同士でもいまはMLなんか使っていない。まずLINEでした。大学からのメールも使っていない
  • @nov: 今日、もし連絡先交換してくださいと言われたら何を教える? (2年生にひとりずつ聞いてみた)
    • LINE: LINEの方が気軽
    • tw: LINEは話さない人増やしてもと思う。最初はtwというカベを作っておいて、仲よくなってからLINE
    • LINE: twはやってるけど見るだけ。使っているSNSはLINEだけ
    • tw: LINE連絡先が多くなっちゃう。会話がないのにLINEの意味がない。twのDで十分
    • LINE: 他にtwなどまったくやっていないしメールより気軽
    • 面と向った人ならLINEでもtwでも何でもいい。知らない人との間では個人が特定できるような話はしたくない。自分自身が現れないような会話ならメディアは問わない
    • LINE: 連絡には使わない
  • @oritako: 高校でLINE八分になってしまうと本当に深刻

NEC中央研究所 佐古和恵様 "匿名認証技術 〜私たちの生活はどうよくなるか〜" (Presented at IIW 17)

  • 自己紹介
匿名認証
  • verifierにユーザIDを伝えることなく、ユーザの属性を証明する方法
    • issuerがユーザーにcredentialを渡す。ユーザーがverifierに何らかの正当性を証明したい。属性を証明したい。ただし、自分が後で特定されるような情報(IDなど)は渡さない
    • 特定されない(匿名)、属性を証明(認証)
「匿名」「プライバシ保護」について、暗号研究者の視点から
  • 電子投票のプライバシ保護を例として
    • 「田中さんがObamaに投票した」を安全に集計する方法(何を暗号化するか)
      • 「誰か」がObamaに投票した → 投票主体を匿名化
      • 田中さんが「誰か」が投票した → 投票内容を暗号化
    • 「誰が」「何をした」の何かをかくそうとする、それが匿名化だと考えていた
  • 最近の「k匿名性」
    • 「田中さんが田町で乗車して渋谷で下車して化粧品を買って老眼鏡を修理に出した」
    • 田中さん、だけをかくしても他が見えていれば「田中さんぽいぞ!?」と特定されてしまう
    • 行動データを「あいまい化」して、一連の行動データや属性データから推測されないようにする
匿名認証(ユーザー匿名化) + (属性認証)
  • 属性証明書との違い?
    • 属性証明書って? → 役所の中で「この人は課長さんである」ことの証明など
    • 自分が秘密鍵を持っています。この秘密鍵を持っている人は課長さんですよとかお医者さんですよということを証明してくれる証明書があります
      • → 公開鍵がIDとして働くので、「この前来たお医者さんがまた来た」とわかってしまう
  • one-time 属性証明書であれば?
    • issuerとverifierが持ちよれば、誰に発行した属性証明書が使われたかわかってしまう
  • 暗号コミュニティーのめざす匿名認証
    • issuerとverifierが結託してもユーザが特定できない方式
    • ブラインド署名: Microsoft U-Proveなど
    • グループ署名
    • ゼロ知識証明 IBM Identity Mixerなど
    • Intel TPM 2.0 Anonymous Attestation
現実にセキュリティとプライバシが両立されるような応用例を考えるために、シンプルな匿名認証方式で考えてみよう
  • デジタル署名
    • だれでも個人公開鍵を用いてユーザを特定可能
    • → 「あの人こんなこと言ってたよ」が転送できる → 「署名のひとり歩き問題」
  • グループ署名
    • 同じ内容が正しいと誰かが保証してくれる。誰が保証してくれるかを調べるには2通りのレベルがある
      • レベル1: 秘密鍵を持つ特権者がユーザを特定できる
      • レベル2: グループを確認するレベル。ユーザは特定できない
      • 例: 「NECの社員なら入れます」というゲートでレベル2認証すると、NECの誰かが来たことはわかるが、実際に来たのがNEC社員のうち誰であるかはわからない
  • 応用例
    • 例1: 買物をするのには支払い能力の認証だけがあればよい。主体は特定しなくてもよい
    • 例2: ケータイのID
    • 例3: 車車間通信
Q&A
  • 失効させるには?
    • CRLと同じ仕組みでこのグループに属さないという情報を流通させる
  • ユーザーIDを暗号化して埋めているような感じ?
    • そのとおり。「確率暗号」という。nonceとidentifierをくっつけて暗号化したようなもの
  • グループ署名
    • 複数人が異なる秘密鍵を持ち、共通の公開鍵を持つことができる
    • 暗号化と署名はまた別
  • レベル1の人が暗号論的に存在しないことを保証することもできるか?
    • それもできる
  • 提示された例ではフロントエンドがレベル2でバックエンドがレベル1になっているが、これを逆にしてはどうか。集める人はレベル1で個人を特定して集めるが、第三者提供すると提供を受けた方はレベル2であって個人を特定できないという使い方があるのでは?
    • その場合、レベル1から先はどうせコントロールできない(集める人を信頼しているから)。それならもっと効率のいい方法があると思う
  • 「ポイントカードやSUICA、現在は完全に追跡されています。余分にお金を払うと追跡されないサービスがあるとして、いくらなら払うか」会場に聞いてみた
    • 100円: 多くの人がOK
    • 300円: 半数くらい
    • 1000円: 数人
    • 逆にぜったい払わないという人も2〜3人。「なんでユーザーが負担しなきゃいけないの」
  • revocation listが大きくなって運用が難しくなる? → そうです
まとめ
  • 匿名認証の性質とさまざまな実現方法があること
  • open question: このような技術をどう応用すれば、実生活が改善するか。

@ritou "OAuth 2.0のCSRF対策拡張の話"

CSRF脆弱性を持つ日記投稿サービスの例
  • ユーザー認証機能あり
  • 投稿フォームからPOST
  • CSRF例: 悪意あるサービスがユーザーAに「あるURL」をクリックさせると、日記サービスにPOSTする
  • リスク: ユーザーの意図しない投稿
    • 投稿された日記に悪意あるURLが入っていたら…
  • 日記投稿サービスがとるべきCSRF対策
    • セッションIDを投稿フォームのhiddenに入れておく
CSRF脆弱性を持つログインサーバー
  • ログインフォームからID/PWを送る → ログイン
  • 攻撃者のID/PWを送ってやると、ユーザーAのセッションの中で攻撃者のアカウントとしてログインしてしまう
  • 気づかずに保存したデータを悪用されてしまう
  • とるべき対策
    • セッションIDをログインフォームのhiddenに入れておく
OAuth 2.0とCSRF
  • 認可フローでは、ユーザーAのセッションにアクセストークンがひもづく
  • 第三者のセッションに攻撃者のアクセストークンをひもづけさせようとする攻撃があり得る
  • ユーザーA(攻撃者)が認可コードを得た時点で、それをユーザーBのセッションに送り込む
    • → ユーザーBのセッションにユーザーAのアクセストークンがひもづく
  • リスクはログインのCSRFと同等
  • 攻撃者は認可応答のURLを他人のブラウザで実行させるだけでよい
stateパラメータによる対策
  • clientがセッションにひもづくstateを生成
    • clientがstateをサーバーに送ると、それが送り返されてくる
    • clientではニセの認可コードをつかまされていないことがわかる
      • ユーザーBのセッションなのにユーザーAのstateを渡された
  • clientの実装に依存している
    • clientの実装を信用できない場合、server側で確認することはできない
server側で対策を取れる拡張を考えた
  • serverで生成するのでserver_stateパラメータを生成
  • clientはserver_stateをセッションにひもづける
  • serverは認可コードにserver_stateにひもづけ、認可応答には含めない
  • clientはセッションにひもづくserver_stateを認可コードにつけて送る
  • serverは一致するか確認
  • ポイント: clientが実装を省略できない
  • implicit grantでも使えるよ(今日は割愛)
導入状況
  • mixi Graph/APIなど
  • 全部に入れてしまうと実装しないと使えなくなるので、一部のみ
mixiOpenID Connect対応について
  • mixi platformもOpenID Connect対応したよ!
  • emailはログインに使っているものをverified=trueで提供
Q&A
  • @lef: サーバー重くなんないですか
    • なんないです。長くなるので略
  • @_nat: RFCにはいつするの?
    • 心しておきます

Mitsuo Okada, Founder & CEO, Capy Inc. "CAPTCHA is dead."

Capy: キャピー

CAPTCHA
  • 何回入れても正解しない
  • CAPTCHAとは → 人間かボットかを判別している
  • ボットがかしこくなってCAPTCHAが難しくなった結果、ボットは通れて人間は通れない現象が起きているw
  • CAPTCHAが入れられなくて離脱する人がいる
新しいCAPTCHA
  • パズル型: ジグソーパズルのピースを正しい位置に置く
  • 着せかえ型: クラウディアちゃんにサンタ帽をかぶせたら正解(ボットは絵が帽子であることがわからない)
スローガン
  • Innovation = Security x Design
  • 世界を2015年くらいまでに変える
Q&A
  • 何を送ってるの?
    • 座標
  • 音声のやつもある?
    • 要望があれば

懇親会

そのまま会場で懇親会に突入しました。

若い世代とも交流でき、また匿名認証やプライバシーについて、さらにつっこんだ話ができました。

リコーの新しい360度カメラ「THETA」で写真を撮ってみました。

  • Next Generationのみなさんと

2013-09-22

YAPC::Asia 2013セッションメモ9/21分

後でちゃんと編集します。

乱文でごめんなさい。

Perlで書く結合テスト

  • @ikasam_a
  • Testing Casual Talks #2 11月ごろで調整中
SWET, TE
  • SWET (Software Engineer in Test), TE (Testing Engineer)
    • テストフレームワークを作る、テスト環境を作る、テストコードを書く
    • テスト全般にかかわる仕事をする
    • WikipediaではSETで引くと一応書いてある
    • Google Testing Blogの解説
  • 呼び方
  • Google Testing Blog
Developer Productivity
  • 2つの役割
    • (後でスライド見て補完)
    • Testingにかかわる活動
  • SWET Group Mission Statement
    • テストをしやすくして、生産性を上げる
  • エンジニアリングとしてtesting活動をしていく
    • 自動化など
テストの分類
  • 4つの分類軸

Perspective Target

How What

  • Perspective: 誰がテストするか
    • 開発者テスト
    • 受け入れテスト
  • Target: テスト対象は何であるか
  • How: テストの手法
    • black/white/gray box testing
  • What: テストの目的
  • 今日のお話はTarget: 単体/結合テストについて
Unit Testing
  • 単体テストの「単体」って何?
    • チームで認識を合わせるのが大事
  • モジュールの中の「メソッド」
  • システムの中の「コンポーネント
  • ユニットの入出力にフォーカスしてテストしていく
Integration Testing
  • 結合テスト: 「何と何が結合している状態」なのか?
    • 単体の裏返し
  • 「モジュールが結合」してコンポーネントを作る
  • コンポーネントが結合」してシステムになる
  • ユニット間のインタラクション/オーケストレーションをテストしていく
Interaction
  • 単体テストでは
    • ターゲットだけに注目
    • 他の部分はモックやスタブでふうじこめる
  • 結合テストでは
    • 実際に動いている中でテストする
結合テストケーススタディ
  • Web API
  • HTTP JSON-RPC API
  • interaction & integration
    • APIサーバーのモジュール同士の
    • APIサーバー、DB、キャッシュサーバー間の
  • テスト用クライアントからAPIサーバーにリクエストを出し、レスポンスを見る
    • APIサーバ内のモジュール間結合、バックエンドサーバー群との連携
  • 入力: HTTPリクエスト、出力: JSONレスポンス
  • HTTPクライアントには
    • LWP::UAFurlを使う。特にどっちということはない
    • 注意: APIに特化したクライアント、特定サービス向けクライアントを使うと、テストで見たい部分が見られない可能性がある
      • 普通じゃない使い方に使えないことがある
  • JSON validation
    • JSON + Test::Deep系を使う
      • かゆいところは T::D::Matcher, T::D::Cond を使って
    • JSON Schemaを使う方法がありそうだ
  • gray box fixture
    • DB/Cache manipulation
    • テストケースに依存したデータを作成
    • 継続的テストのためにキャッシュを消したりとか
    • 普通のオペレーションで生成できないデータを用意する
  • 特定サーバー向けリクエスト
    • たくさんリクエストがくるような場合、ロードバランサなどで多重化することが多い
    • ある特定のインスタンスだけテストしたい
    • LWP::UA::DNS::Hosts 特定のホスト名に対して特定のIPを返す。リクエストを特定IPアドレスに向ける
    • Furl + inet_aton クロージャを渡して制御
    • MyDNSなどのツールで設定する方法もあり
  • HTTP Messageを見る
    • LWPはHTTP::Response::requestでリクエストが見れる
    • Furl: capture_request のパッチを送った
  • Web Application
  • UIのWebアプリ
  • interaction & integration
    • Web Appモジュール: MVC的な
    • Web APPとバックエンドサーバーとの間の連携
  • 入力: HTTPリクエスト、出力: HTMLレスポンス
  • ブラウザ、user agentを使う: JavaScriptが解釈できることが重要
    • WWW::Mechanize
    • Selenium::Remote::Driver
    • Wight: phantomjsのPerl実装
    • Brownie: 自分で書いて最近使ってないw Rubyのcapybara相当
  • Switch Browser
    • テストの中でJSを使えるブラウザとJSを使えないブラウザを切りかえたいというニーズがたまにある
    • ブラウザはHTTPヘッダをさわれない
    • エミュレータはJS実行できない
    • ブラウザのpseudo state(セッションなど)をセーブ/リストアする
      • ヘルパーとしてまとめておく
役立つモジュール
  • Test::Ika (RSpec for Perl)
  • Test::Requires::Env
    • 結合テストで必要なユーザー名、パスワードを環境変数から渡す
    • 渡し忘れのときにテストが落ちる
Q&A
  • キャッシュデータを入れるときにキーが重なったりするのはどうしますか?
    • 実際のキャッシュそのものを使って直接書き込んでいる
    • データ競合については本当にwhite boxで、APIのアクセス手段と同じ方法でアクセスする。もう一つのAPIから書き込むようなシーンを設定する

これからのPerlプロダクトのかたち

  • @goccy54
  • 自己紹介
    • ごっしー
    • mixi: 今年2年間
    • タンポポグループ
      • さしみタンポポ仕事をなくそう
      • 開発者のための開発
      • 技術的負債を効率的に検出して直すよう促す
      • Jenkinsテスト時間の短縮 50分 → 4分
    • Perlの中でPerlを作る → gperl
gperl
  • perl-like language written in C++
  • 最終コミットは11か月前。もう終わっちゃったの?
    • いやいや、まだ生きてます
    • Lexical analyzer: perl5 syntax highlighterを作ってます
    • Parser: 静的解析ツール作ってます
  • gperlからスピンアウトしたモジュールを見ていきます
    • Compiler::Lexer, Compiler::Parser, Compiler::CodeGenerator::LLVM
Compiler::Lexer
  • Perl5トークナイザを開発した
    • できるだけシンプルに: トークンのarrayrefを返すだけ
    • 高速にしたい: C++でスクラッチから書いた
      • perfect hash, memory poolなどを使って高速化
    • PPI::Tokenizeと比べて10〜100倍速い
    • Readableにしたい: yacc/bisonを使っていない
  • ハマりパターン
    • func * v: globなのmulなの?
    • func /: regex delimiter or dev?
    • func <<FLAG: heredoc or shift operator + const </li>
  • 今後
    • recursiveにトークナイズするように
Compiler::Parser
  • abstract syntax treeを生成
  • 速い: PPIより速いよ
  • Readableに作った
  • BlackPerlのパースに挑戦
    • 意味もないし動かないけどsyntax errorにはならないコード
    • ちゃんとパースできたよ
  • 今後
    • PPIを置きかえたい
    • PPIを使っているモジュールは有用であって使いたい → 実行時間が気になる → 速くしたい
    • 最低限PPIが使える部分は使いたい
Compiler::CodeGenerator::LLVM
使い方
  • Lexerでトークナイズ、ParserでASTにする。ASTをCCに渡す。LLVMで実行
  • ベンチマーク: Fibonacci
    • Fibonacciは有利なベンチマークなので数字が良く出る
      • 関数呼出し、整数など
  • まだチューニングは不十分
  • 開発は8月から開始
PerlをWebブラウザ上で動かす
  • perl.js (@gfx)と同様のアプローチ
    • 最後にemscriptenを使っているのは同じ
    • LLVM-IRに食わせる
  • 違い
  • enscriptenのバグに遭遇して、ところどころ動かない
  • 今後
    • github.com:goccy/p5-Comiler-Tools-Transpiler
PerliOSOSXで動かす
  • RubyMotion, mocl, Titanium
    • Perl版を作ろう!
  • PerlMotion
  • アーキテクチャ
    • LLVM-IRに落とす
    • Perl5 x Cocoa Touch Frameworksバインディングライブラリ
    • ネイティブコードに落とす
  • デモ
    • Hello Perl
    • タッチイベントを拾って画像を表示
  • どんだけ動くんですか
    • LLVMがどれだけ動くかに依存
    • Primitive Types: 全部
    • 演算子
    • 組込関数: 自分の好みでやっているw
    • 未サポート機能
      • glob・シンボル操作
      • GC未サポートなのでリークしまくりwww
      • 正規表現: pcre使おうかな
    • サポートするつもりがないこと
      • Appleが禁止しているdynamic evaluation
      • eval, s///e, require
  • 今後
    • 実機で動かせるようにしたい
    • デバッグサポート
    • 既存のUIKit、フレームワークのサポート
      • → generatorで一気に生成したい
    • Pure PerlCPANモジュールも使いたい
    • 来年の春くらいで出せるようにスケジュールを考えている
  • 名前も募集
静的解析ツールとして使う
  • Compiler::Tools::CopyPasteDetector
    • 検出エンジン自体はC++ → 高速
      • Native threadを使って動く
    • Compiler::LexerとB::Deparseを使っているので正確
    • 高機能なvisualizerつき
  • デモ
    • CatalystとMojoliciousを比べてみた
Lexerを使っているモジュール
  • Perl::MinimumVersion::Fast
  • Test::LocalFunctions::Fast
今後
  • Perl::Metrics::Simple::Fast
    • 循環参照の検出をしてくれる → 高速化したい
    • mixi社内の静的解析に時間がかかりすぎて困っている
    • うまく行ったら静的解析ツールをCPANizeしたい
gperlは生まれかわるよ!
  • gperlから派生したCompiler::* をgperlに還元
  • static typingを入れてみたい。型推論エンジンに興味がある

Rubyの良いところ語ってください 〜そんなPerlで大丈夫か?〜」

  • 司会 @naoya_ito
  • パネラー @tokuhirom, secondlife (@hotchpotch), @shyouhei, @masuidrive
  • 本メモでは発言者を示すプレフィクスとして n, t, h, s, m を使っています
自己紹介
  • @syouhei: Ruby committer
  • secondlife (@hotchpotch): Cookpad
  • @masuidrive: 風呂グラマー
  • @tokuhirom: Shibuya.pm, Amon2
言語の比較
  • なぜPerl, Ruby?
    • m: Rubyは日本語でいろいろできる
    • s: ブログブームのときt-diaryを使ったのがRubyの始まり
      • 十分満足していたらコミッターにはならない。不満があるのでパッチを送っていたらコミッターに
    • h: t-diaryから。Railsの回りのコミュニティー形成の流れ → Cookpad
      • n: 最初の会議はPHPだったんですよね。どうしてRubyに?
      • h: 仕事ではPHPだったが、趣味でRubyをやったときに考えたことがすっと表現できたから
    • t: 15歳くらいからRubyPythonを使っていた。Rubyist Magazineに寄稿した。LLの実行委員をやったときにPerlの会社に行って書くようになった
      • t: 当時naoyaさん、miyagawaさんがblog hacksをやっていて楽しそうだった。言語そのものに興味があったので、それまで使ったことのないPerlをやってみた
  • いちばん好きな言語はRubyだと思うが、こういうところが好き、とかある?
    • h: Perlとの比較では、標準ライブラリのセンスがすごくいい。PerlだとList::Util使わないといけなかったりという部分が、そのままサポートされている
      • n: やろうと思えばできるというのと、処理系がサポートされていることには違いがあるのか?
      • h: 学習のしきいが高かったと思う
    • s: ごく最近Perlをさわりはじめた。違うところより似ているところが多かった。仕事の中でpr出したら何も問題なくマージされた。差分よりは似ているところのほうが多いと思う
      • n: でもこういう機能がPerlにあったほうが、というの感じたことある?
      • s: いまRubyに一番あるのは「未来」。みんなポカーンとしてるな。Rubyプログラマーに提案をしてくる言語。思想を振りまいている言語。例えばキーワード引数とか。これから推奨されるべきだと思ったので、型チェックなどを言語でサポートするようにしました。ここはRubyPerlの大きな違いで、Perlは言語の側からやることはしない。Rubyはプログラミングをもっと楽しくしたい、世界を良くするために言語を変えていくことを考えている
    • m: RubyはMatz Rubyの他に処理系のバリエーションが多い。JRubyとか。最近だとmrubyが出たりしている。こういうのはPerlにはあまりない
      • t: goccyさんのgperlが出てきたりgfxさんのperl.jsがあったり。Perl6の実装はバリエーションがある。Perl6に労力を取られている面もあるけど、これからはPerl6ということかな
      • m: JVMのほうが性能がいい。Rubyもあんな複雑なものに他実装が出ないだろうと思っていたのが、いまは5つもあったりする。そのへんが、Perlと比べてに限らず、Rubyの面白いところ
  • n 言語を変えて生産性は変わる?
    • m: 言語を変えると変わってくるが、肌に合うか合わないかのほうが強いかと思う。引数の順番とか覚えなきゃいけないことが多いのはつらい
    • s: 適材適所がある。Rubyのいいところはあるけど、全部をRubyでやろうとするのは間違い。CapystranoでRubyで書いているコマンドは本当はshellの方がいい。なんでもやろうとしないほうがいい。
      • n: webアプリケーションでPPPRと並べたときはどうか
      • s: ツールや言語による違いよりもプログラマーのスキルによるところが大きいだろう
    • h: 現状を切りとると、何の・誰の生産性かというのでも違ってくる。Rubyは道具としてそろっているので何かを作るときにスピードは速い。ただしハッカーは何でもできてしまうのでPerlに足りないところはすぐ作ってしまう。Railsの批判としてはでかすぎるというものがあるが、Amon2作ったりして補ってしまう。普通のところでは道具とコミュニティーが現状Rubyにはそろっていると思う。社内で助言が得られるかというのは難しく、Web回りでコミュニティーができているのは大きい
    • t: PPPRの言語レベルの生産性の違いと言えるほどのことはないと思う。上のレイヤでツール・ライブラリなどが問題。行列計算のライブラリはPerlよりPythonのほうが充実している。Perlの場合は自分で使いたいライブラリは自分で書いているので、ぼくのユースケースと似ているところには合っていると思う。
  • n: フレームワークやライブラリということでRailsが勢力を変えたということがあるか
    • h: bundlerなど、コミュニティーの範囲が広く、うまいやり方がgithubを中心に広がっている。課題を考えたときに育つということがある。
    • h: Rubyはファッションの流れみたいなことがあって、それに乗ってる人もいる。node.jsのコミュニティーのでき方といま乗ればデファクトになれるというのに熱い風を感じる
    • s: 回りでPerlをやってた人がRubyに行ったという話を聞くと、Railsから転びましたという人はあまりいない。Rubyにはthreadがあったという人とstructがあったという人がいる
      • n: threadはね、Perlではいまだにちゃんと使えているとは言えない
    • m: RubyRails以前から使っているが本格的に使うようになったのはRailsRailsはビジネスとつながって経済圏ができているのがすごい。herokuとかNewRelicとか。RubyOSSコミュニティーだけでなくお金が出るコミュニティーもしっかりしている
    • s: RubyがすごかったというよりRailsが切り開いた面がある
  • n: Rubyが良かったのかRailsが良かったのか、そのへんはどう?
    • m: コミッタの視点でどう?
    • s: いろんな分野のいろんな専門化の人が来て、こんなところが気になっているんだけど、みたいな話をしてくれる。特にusabilityについて。いろんな人が来ることがRubyの開発をドライブしている面がある
  • n: PerlとビジネスということでSaaSサービスのサポート状況とかどうですか
    • t: SaaS的なところで言うとherokuとdotcloudくらいしか使えない。積極的にサポートしてくれる/サポートしてくれという動きがないのはよくないかなあ
  • n: travisでperlが検証できるようになったのはコミュニティーが主導していったのかな
    • m: 元々ビジネスとして使っているという人が多い。インドの人がオフショアするので日本で需要があったらみたいな名刺をよくもらった。Rubyは最初からそういう感じ
    • n: Perlは使えるようにしたいというと、コミュニティーの中からハイやりますみたいな人がいるが、Rubyは最初から。そのへんが違うということですかね
  • n: エコシステムとしてPerlCPANからという流れがありますが、Rubyrubygemsにコミュニティーがあるというよりも、github上にあるような感じですが
    • h: rubygemsも最初はrubyforgeというPHP上のサービスだった。いまはgithubではあるけど、最初からスムーズだったというよりは、githubが出てからそっちに移った感じ
    • s: lighthouseからgithubに移っていった。単に新し物好きというのもあるが、新しいものが出たときにどんどん流れて行くような人が多いという特性があると思う。これは古いチケットが放置されたり悪い面もあるけど。
    • t: CPANの中にbug tracking systemがあってみんなメールで登録したりしているけど、最近はgithub上でやる人が多い。意外とgithubに移ってきている人も多い
    • m: Perlの人ってgithubでやらないの?
      • n: CPANが機能をたくさん持っているので、そってちでやっている人が多かったということかな
    • m: githubの良さはコードとコミュニケーションが近づいたということ。コミュニケーション主体で大きくなってきたという流れがある
    • t: rtが重要で、なかなかとじることができなかったという面がある
  • n: DevOpsとしてRubyでこんなことやってるよ、みたいのある? 基本puppet使ってとか
    • h: SaaSとかアーキテクチャの話ではPerlとの差が出ると思うが、puppetのようなツールのレベルでは違いがないのかな。単にpuppetがRubyで書かれているだけというか
    • n: Rubyの人はツールもRubyで書かれているものが多い。そういう力が働くのかな
    • h: 道具を作ろうと思って書くからじゃない?
    • n: Railsから広がるというのとDevOpsの話と似たところがあるような
    • h: DevOpsというのはインフラができてソフトが書ける人がやっている印象。Rubyの方が学習コストが低いということがもしあるとすれば、関係しているのかも
    • m: ひと昔前だとRubyをサーバーに入れるのがイヤがられた。Perlは必ず入っていた。5年前に同じことをやろうとしたらPerlになったのでは
  • n: コミッタのコミュニティーについてどうか
    • s: 日本にはPerlのコミッタのコミュニティーがないので仕方ないと思うがRubyについて言うと、普通にコミットできます。まず、みんなで集まって今後のRubyをどうしましょうという話がある。地域Rubyコミュニティーにcommitterが来て「こういう問題があるけどどうすればいいですかねえ」という話をするというのが特徴的だと思う。
    • n: Ruby Kaigiでは言語そのものに関するセッションが多い印象
      • s: YAPCに始めてきたけど、意外に言語そのもののセッションがあって、うれしい意外でしたね
  • m: シアトルにコミュニティーがあって英語が十分でなくても理解してくれる。Matz is nice so we are niceという標語があって、Matzを中心としたコミュニティーがある気がする
    • n: 海外コミュニティーとの関わりってどうですか
    • m: (聞きのがした)
  • n 組織とコミュニティーとの関わりはどうですか?
    • h: 言語のバージョンアップで速くなるとか会社がビジネス面でもコミットしているところが違うと思う
    • t 日本にはPerlのコミッターがあまりいないし、committerをあがめるような文化がない。弾さんが持っているかなーってことくらい。言語コアよりはCPAN authorの方を大事にする文化があるように思う。コミュニティーに還元などはCPANを中心に回っていると思う
    • s: コミュニティーってどこにあるんだという話をしてみたい。Rubyコミュニティーに入るには羊の心臓をささげる、みたいなことはない。分断されていて敵対心をあおるのはよくないと思っていて、自分の所属意識があるのはいいが、排斥しないでほしいと思う
Perlリスク論
  • どう思うか、どう行動したらいいか
  • s: ブログで「まああるんじゃないですか」と書いた件について。去年まではRubyを作る会社にいて、いまはPerlを使う会社に転職してきました。Rubyを使うだけで終わりたくなかったという面はある。いまRubyはバーっともり上がっててカッコイイけど、10年後そうとも思わない。ゆるやかに使われなくなっていくのかな。Rubyを使い続けるのは得策ではなく、もっといい言語が出てきて、それにRubyが影響を与えればいいかなと。ぼくのゴールはRubyを良くすることではなくみなさんを、プログラミングをハッピーにすること。RubyPerlがというよりもっと大事なことがあるんじゃないかな、と。
  • h: ぼくらはユーザーに価値をどれだけ速くとどけられるか、そこに適したRubyをいま使っている。Perlのコミュニティーを見ると他の言語やコミュニティーをすごくよく見ていて、Perlに取り込んだりしている。miyagawaさんはあっという間にRubyRubyコミュニティーの文化を吸収して、またPerlに輸出している。そういうことができる人がいることが大事かなーと思う
  • t: ぼくが言っていることは10年前と同じで変わっていない。Perl6も出ないしもうダメーと言っている。その状況も変わらず。変わらないながら進んでいくんだろうなーと思っている。言語ってのは仕事の一部でしかない。要素技術のひとつを取りかえたくらいで自分のスキルが役立たなくならないようにするのがエンジニアとして大事だろうと思います
  • n: Perlリスクに対してPerlでもこんなことできるよと反論していくのも手であるとは思うけど、他の言語の世界を見て学ぶ機会を得ていくほうが大事。みんなで未来を見ていきましょうと思います。
  • dan: 今年に入ってfreebsdportsに入っているrubyが1.8から1.9になり、いろんなものがこわれた。Rubyはバージョンを上げるとこれがこうこわれますというチェックはどれくらいしていますか、そしてどれくらい反映していますか?
    • s: 何もやっていません。プログラミングを良くすることに主眼を置いているので。RedMineが動かない話が大きかったかな
  • h: バージョンを上げ続けるというのは生産性というかメンテナンスの問題だと思っている

本当にあったレガシーな話

  • @lestrrat
livedoor blog
  • 日本最大のブログサービス
    • 多機能
    • 推定22万行、mod_perl 1.3.x、Perl 5.8.8で動いていた
  • PV/UU非公表(残念)、ただ、ちょっと怖いくらいの量はある
    • サーバーもン百台
  • これをガリガリと変えて、もっと開発しやすく、運用しやすく、モダンにしたい!
  • どう実現できたのか?
    • 銀の弾丸など存在しない って言うと糸冬了してしまう
  • ベストでなくてもベターなコードを適用していく → 地道な作業
コードベース
  • mod_perl 1.3.x、Perl 5.8.8ベッタリ
    • 依存関係もよくわからない
  • これまで: エンジニア・スタッフの腕と力業でやってきた
    • いろんな工夫があっていいシステムではあった
  • これから: コードを良くして運用・メンテをしやすくしたい
目標
  • Perlのバージョンを上げる
  • パッケージングを近代化
  • mod_perlとサヨナラ
perl upgrade
  • PSGI化するまで何もできない。先は長い
phase 1: システムを分割
Road to PSGI
  • まず配信システムをmod_perlからはがそう
  • 仕様は? ログは?
ログを取ってください
  • Log::Minimal
  • 本番では最適化したい
    • 必要ないところではログの出力コードをそもそも消したい
    • 定数たたみ込みしましょう
      • if (LDBLOGNG_DEBUG) { ... } コンパイル時に定数たたみ込みで消える
  • 巨大なアプリではめんどうでもすべての分岐に入れるべき
    • ifの条件式が複雑な場合も、条件ごとにログを入れると後で得
    • 「x == 1なので離脱します」のように書く
    • コンポーネントが多いときはマーカーをつける
      • enter/leaveログ
      • guard objectつけるとインデントしたログを出せる
  • やっとコードの実行結果を追える
  • リファクタリング
    • 「$r」の追放。$rは邪悪そのもの
    • Apache::Request->instanceはさらに悪
  • $r->status(...); $r->send_http_headers()があちこちにある
    • → $class->not_found($r), $class->output_data($r)のような書き方に直す
    • ひと目見て何をやっているかわかる
  • クラス関係の見直し
    • mod_perlハンドラはクラスベース(オブジェクトを作らない)
    • 初期化コードが大変になる
    • フラグ・スイッチを親クラスに集約
  • とりあえずmod_perlのままデプロイ
    • なぜか404ページが真っ白になる
    • mod_perlのクソ仕様
Phase2: 配信システム → PSGI
  • ApacheハンドラをPSGI
  • 直す → 走らせる → 直す → 走らせる →
  • RubyのKageをAnyEventで
      • metacpan.rog/release/Geest (ヘイスト)
      • 出力の差分を見る
  • やっとPerlのバージョンを上げられる
    • せっかくならcpanfile + carton
  • 問題はCPANに上がってないモジュール
    • だいたい内製モジュール
    • tarballからyumで入れてたりとか
    • Class::Triggerだけは他のモジュール全部入れた後に入れたりとか
  • セットアップ
    • よく考えたらmod_perl → PSCIの移行を開発陣全員に教えるのだるい
    • PSGI版のコマンドをたたいたら全部setupするようにしよう
    • mysqlも入れちゃう、パッチ当てて入れちゃう
  • 数台だけ入れかえたら、パフォーマンスが30%落ちる
  • Devel::NYTProfを使う
    • → mountを多用していた。数が多すぎると遅くなる
    • → パッチ書いた
  • query_parameters()がやたら重い
    • uri()をキャッシュするようにしたら10〜15%速くなった → マージ済
  • 再デプロイ
  • 全て落ち着く… svc -hするまでは
    • → 突然load averageが上がる
  • Server::Starterで管理していても-hでやると一気に上がってリソース食う
    • → 既知の問題: 前の世代を殺すタイミングと次の世代が立ち上がるタイミングが同じになってしまう → kazuhoブログ
Phase 3: Sledgeさん
tips
  • plackup多すぎ問題
    • $0に代入してpsで見える名前を変更。リクエスト情報やハンドラ・日時を入れるのも便利

スマフォアプリ開発を支える認証認可アーキテクチャ

  • 鈴木理恵子
    • mixi Graph API、認証認可まわり
    • OAuthおねえさん
    • BaaSおねえさん
  • 今日のメイン: OAuth 2.0 Grouped Client拡張について
前提知識: OAuth 2.0
  • OAuth2.0の基本 (略)
  • Glossary
    • Access Token, Refresh Token, client_id, client_secret
OAuth 2.0 Grouped Client extension
  • 今年のミクシィ社はスマホネイティブアプリをたくさん作っています
  • スマホネイティブアプリ
    • mixi IDでログインするアプリ → 今日の主題
    • mixi IDを使わないアプリ
  • mixi公式アプリを立ち上げると、ログイン画面が出てaccess tokenを得る
    • それ以降、access tokenを使ってユーザーの情報を取得
  • mixi製アプリが増えると、それぞれログイン画面が出てしまう
シングルサインオンの実現方法
  • ID・パスワード共有
    • 最初に起動したアプリから後のアプリにID/パスワードを教える
    • OSの機能でKeychain, Account Managerが提供されている。これを使って共有する
    • mixi製でない他社製アプリとは共有できないので安全
    • 絶対の安全はない。root取られるくらいのイキオイでhackされると取られちゃう
      • パスワードが漏洩するとすべての情報がもれる
      • パスワード無効化すると影響が大きい
  • Grouping Refresh Tokenの共有
    • Refresh Tokenは通常アプリごとに異なる
    • Grouping Refresh TokenをOSの機能を使ってアプリグループ間で共有する
    • 不正アクセスに対して、client_id, client_secretが必要なので少し守れる
      • refresh_tokenだけをrevokeすればいい
      • 無効化した場合、grouping refresh tokenを共有している範囲だけで使えなくなる
おまけ
  • 共通アカウント管理機能を持ったBaaSを作ろうとしています
  • push通知機能、その他のBaaSの基本的な機能
  • scopeの違いは? → @ritou と @mad_p のtwitterログをここに入れる

Vagrant と Chef でプログラマブルな開発環境をつくる

  • @aereal
  • アプリを作るにはモジュールがいろいろ必要
  • 某Webアプリ3万コミット
とりあえず cpanm --installdeps
    • だいたい失敗する、オプション変えてみる。やっぱり失敗する。なんども失敗する
  • 2〜3日も開発環境のセットアップにかけるとか気が狂ってる
    • モチベーションも消費する
  • やることは単純な作業の積み重ね
    • → ログが残ることが大切。cpanmの引数とか
    • こわれたらすぐわかる。ドキュメントが陳腐化しているか調べるのは難しいが、プログラムがこわれているのはすぐわかる
vagrantを使う
  • 開発用にVMを立ち上げるのは以前からもやられていた
    • 単純な回帰ではない。Chefのようなソフト面での進化が大きい
    • 丹精こめて作ったVMイメージを大事に大事に使う → 壊れることを前提に環境を作っていく
  • NFSでゲストとリポジトリを共有する
  • perl-buildで5.8.8を入れる (tokuhirom/perl-build)
  • CPANモジュールはcookbookに記述
    • ChefのLWRPを使う
  • carton化も進めている
  • ./bin/server
    • 仮想マシンを使っていることを意識させないようなしくみ
      • vagrant up → vagrant ssh-config → ssh経由でplackup
    • procletを使うと便利
  • vagrantを使ってもprovisioningには時間がかかる
    • すぐに開発したい
    • provisioning済のboxを配布
    • 社内file serverに配置 → vagrantも取ってこれる
  • git.io/PBG-og にて公開予定
課題
  • 二重管理なのはそのまま → 問題をすりかえただけ
    • 本番環境のchefと共有したい
  • メンテしているのは自分だけ
まとめ
  • Vagrant + Chef: 銀の弾丸ではない
  • 新しい概念なので、ひとりしかわからないという状況で振り出しに戻ってしまうリスクはある
    • ならなんで使うの?
    • cartonの導入もままならないので、まずは開発環境だけでもなんとかしたい
    • 新規開発者がコンスタントに現れる(インターンなど)

p2

  • Reini Urban
  • 5 + 6 = 11
  • perl11.org/p2
  • Parrot performanceはイマイチ
  • perl11 = prel5 + 6
  • Perl is not dead, it is a Deadend」
  • Perl8.org pugs in scala
Perl 11
  • Pluggable perl5 + 6
    • Parser → AST
    • Compiler: AST → ops
    • VM execute ops
  • Parser
    • コミュニティーは信じないので自分で作った
    • YACC (bottom up)
    • PEG/prackrat (top down)
    • Marpa, ANTLR, ragel...
    • PGE, parsec, maru
    • Handwritten もちろんこれが一番いいが
      • pikeのいいトークがあった
    • maruは結構いい。state machine base(?)
  • Complier
    • AST → ops の線形化と最適化
    • Data Structures: native vs library
    • emit bytecode or jit
      • → pluggable: c, native, jvm, js
      • tieはjsでは難しい
  • VM
    • compile & execute ops
      • でっかいswitchループ
    • native関数を呼ばないといけない。コールバックは難しいものだがp2ではカンタン
    • Debugging support, reflectionが必要
      • メタモデルを持っていれば可能
  • 設計方針
    • frequent caseに最適化
      • math, conditionals, function calls,
      • method dispatchはsuperfast。メソッドキャッシュとjitのおかげ
      • local variables
      • string, build: closure内でのimmutable文字列をcopy-on-writeする必要がある。trieを使う(?)
      • memory allocation: GCがあればいい(?)
      • Default arguments: コンパイラでやればやさしいはず
  • Learn from the good
    • LLVMを使ってJITのためだけに大量のライブラリを用意するの?
    • JVM/.NETの起動オーバーヘッドはnot practical。JVMはdynamic data typeに強くない。.NETはマシ
    • 良いVMに共通のアプローチ: GC, register based, three-address coding, taggod small data, word-size ops
  • POTION
    • famous ruby ecleticが作った → いなくなった
    • stack-based expressive with data (lisp-like)
    • lua VM
    • io + soda objmodel (smalltalk based)
    • GC Cheny two-finger loop from QISH かしこい方法
  • potion: フラミンゴをマスコットにした。P 2 の姿をしている
  • potion / P2
    • common number interfaces
      • int, double: automatic promotion, 遅いけど最適化はカンタン
    • common hash/array interface
      • hash とarrayの自動キャスト
    • everything is an object, overy object is a word
      • data, vairables, functions, blocks, class, types, metaclasses, ...
      • 全部はlambdaである。変数もそう
    • every op is a word size: Perlでは4〜7ワード
      • 64bitの中にはopタイプに少しのビット、残りをオペランドに回す余裕がある
  • parser
    • peg, enhanced to greg
    • 最大3ノードのASTを作成
  • compiler
    • ifはただのブロックつきのリストのメッセージ
  • control structureはマクロのように処理できる
  • VM
    • everything is an object, every object is a function
  • MOP
    • object -vtable-> class -vtable-> metaclass
    • 5 core metaclass methods
      • addMethod, lookupp, allocate, delegated, intern
    • 4 ops in VM
      • SELF, CLASS, BIND(継承ツリーをたどってメソッドを決める), MSG
  • VMluaで50opsくらい。とてもカンタン
  • data
    • primitive vs extended object (vt, uniq, size, data)
    • INT, BOOL, NIL as primitives everything else is an object
    • tags LSB2桁
      • 00: foreign ptr or our obj
      • 10: bool
      • _1: int
  • calling convention
    • Native C cdecl (32bit) and fastcall (64bit)
  • GC
    • いろいろ
  • threading
    • まだ決めてない
  • design decisions
  • functions
    • コピーを返す、引数を変更しない
    • Str: immutable, Buf bytebuffers for io

キーノート: management and Perl culture

  • 池辺さん LINE Corp
  • マネジメントしてますという人のトークも多かった。Perlのカルチャーを持ってる人がマネジメントどうやってるかという話をします
  • Career
    • on the Edge → EDGE → livedoor → NHN Japan → LINE
    • 実は転職していない
  • livedoor Blog
    • 10周年
    • mod_perl 1で動いてるサイトの中でさばいてるPVは1位だったと思うけど、一気に返済していただいた
  • お仕様: software development
    • ソフトウエアの開発ってPCに向かってカタカタやってウフフって感じなんでしょ、なんて個人技っぽく思われてる
    • いいソフトウエアってのはすごい少ない人数のちょっとオカシイくらいのすごい人が作ったモノが流行ると思っていたが違う
    • ソフトウエアは人間が作る。いまだに人間が作っている。人間が集まって作っている
    • → Team
  • management
    • 誰かがやらなきゃいけない。大事だなあ
    • manager? えらい人? 「やってくれたまえ」みたいのでやっていけなさそう
      • 「マネージャー」をえらい人と考えるのは大人になってから
      • Google先生に聞くとマネージャーってめっちゃリア充
      • ぼくらの中学生の頃のマネージャーと言えば南ちゃん
        • 選手がパフォーマンスを出せるように麦茶やハチミツレモン作ったりするのがマネージャーの仕事
  • management != 管理
    • 上から目線で管理すればいいというものではない
    • 心がけていることを紹介します
      • as is ではなく to be ですよ
  • work environment
    • 働く環境ってみなさんまあまあウルサイというか非常に大事でしょう
    • PCは速くなくちゃとか、椅子がつらいとか、朝起きれないとか、ワークライフバランスとか
    • 環境をちゃんと備えるために、人事とか総務に通していく仕事がある
  • human resources
    • 人事
    • 自分よりデキル人を雇えないとダメだとか言われる
    • 優秀すぎてどうしよう、取ってかわられるんじゃないかと思ってコワイ
    • ちゃんとやらないとチームとしてのcapがマネージャーのそれになってしまう
    • SKE48の写真、16人みんな色が違う。みんな違うのがいいことで均質化する必要はない。みんな好きキライがあってもいい
    • ビジネスよりに興味があって売上あがるのがいい、細かいチューニングで貢献、いやいや技術的負債は許せない、など、みんなが自分の特性を発揮してくれればいい
    • ユーザーが近いのが得意な人と苦手な人は割とハッキリ分かれているかも。ユーザーからの辛辣な指摘に耐性のある人に大規模な改修してもらうといいかな、とか
  • 将来どうすんの?
    • management or engineer
    • 35歳定年説
    • 人事制度もちゃんと考えないといけない
    • ダメだと思うのは「デキルエンジニアをおまえマネージャーな」とやること
    • 向いている人、向いていない人いると思うし、マネージャーできないとダメだよというのはおかしい。エンジニアはエンジニアのまま給料ももらえるような人事制度にするようハックしていくべき
    • マネージメントとリーダーシップはまた違う。数人でゴールさせるリーダーシップを持っているエンジニアは結構いると思う
    • 「マネージャーならないといけないんですよね、そろそろ」という価値観でやらない方がいいと思う
  • direction: 方向づけ
    • 適材適所、人に向いたいい仕様を与えるというのはあるとして、
    • そもそもなんでこの仕事やってるの、ということはちゃんと伝えていかないといけない
    • 細かいことではPerl使いましょう、このフレームワーク使いましょうとか、弊社で言うとアプリに力入れましょうとか、こういう制御は大事なところですね
  • marketing
    • マーケティングというとアレっすかみたいな話になりがちだけど
    • チームがちゃんとがんばっているということを、技術がわからない人、決裁権を持っている技術のわからない人に伝えていくこと。これをやならないと損したりする
    • 牧さんのmod_perlからの脱却という話があるけど、自分はApache使いたい、でもCは書きたくないという感じでやった。そして脱却した牧さんはすごいんです。だからもっとお金をくださいとか、フレックスにしてくださいとか、そういう社内政治を、社内政治って悪い言葉っぽく聞こえるけどそうじゃなくて、ちゃんとやっていくことは必要
    • ちょっとずつ社内にうちの部署++みたいなカルマがたまっていって良くなるので、そういうスパイラルを回していけることが大事だと思います
  • our team
    • 80人強いる AKBの研究員を全部含めたくらい
    • サーバーサイドはだいたいPerl
    • 最近はアプリを作っているのでObjective-C, Java, JavaScript, Ruby
    • Rubyも実は使ってたり
  • Why we use Perl?
    • 入ったときには弾さんがもうそうしてた
      • dan: ぼくが入るまえに@takapon_jpさんが使ってた
    • 変えようとすれば変えられる
    • Perlリスクという話の中で面接してるときにPerlできませんと言ってすぐお引きとりください、なんて言われてたけどそんなことはない
    • いまPerlができないからってできるようにならないことはない
    • Webの仕事をしていてプログラミング言語で勝負が決まるようなことはない
    • 10年動いているものをRailsで書き直しましょうなんてコストは見合わない
    • タイミングを逃した? まあそうかもw
    • Perlって言語の側面というよりはカルチャーの側面、TIMTOWTDIとか多様性を認めるカルチャーとか大事
    • CPANソムリエという職がうちにはあって、CPANに乗ろうという気持ちがすごく大事
    • いいチームはいいカルチャーを持っている。その大部分はPerlのコミュニティー、Perlのカルチャーから学んだかな、と思います

LT2日目

すいませんログ取ってません

クロージング

  • @lestrrat
  • YAPC::Asiaももう8回目
    • ずっとスタッフしてるのはぼくだけ
  • チケットの売れた枚数 + 招待客、スタッフとか全部足すと → 1,131人
  • ベストトーク賞発表
    • 3位: 勉強会の参加費用
    • 2位: 国内カンファレンス参加費用 + 旅費
    • 1位: 米国、ヨーロッパなどのYAPC以外でもいいがカンファレンスに行く参加費 + 旅費
    • 3位: kazeburoさん
    • 2位: myfinderさん、lestrratさん
    • 1位: yusukebeさん
  • お知らせ
    • YAPC::Asia Tokyo これが最後です
      • 941 + lestrrat 引退
    • Exciting new things happening
      • Perl 5.20
      • Carton
      • PerlMotion
      • p2, pvip, perl.js
      • ほとんど日本発
    • Regional YAPCs
    • Perl入学式
    • 新しい息吹
    • 我々が4年間やってきたものが、芽が出てきた
  • Don't keep calm or carry on
    • Be the change you wish to see in the world
  • lestrrat: アイディアある人は今年中にぼくのところに来てください
  • スタッフ
    • NOCチーム: JANOG + LLNOC
    • 記録更新 100Mbps頭うっちゃって、みなさんiOS7ダウンロードしすぎです
  • See You Next At YOUR YAPC!

YAPC::Asia 2013セッションメモ9/20分

感想エントリは別途作成します。

とりあえずセッション中に取ったメモを公開。

後でちゃんと編集します。

乱文でごめんなさい。

Postcards from the Edge: The State of Perl 5 Development

  • Ricardo Signes rjbs
  • P5 Pumpking
  • Perlは昔も今もmess。Don't worry.
  • perldeltaに書いてあることの多くは誰の役にも立たない
    • %^Hをtieすると…、globにm?..?で代入すると…
  • 役にたつことを紹介しよう
What's new
  • RegexSets
    • (?[..])
    • +, -, (), &, \p{..}
  • Lexical Subroutines
    • my sub adder {} 毎回作る
    • state sub adder {} 最初に1回だけ作る → lazy closure creation
    • テストで便利
    • エラーのときサブルーチン名が出ないけどね
    • 名前がlexical scopeなだけで実態はパッケージサブルーチン
Experimental Features
  • みんなが使うなら生き残る
  • lexical topic: my $_
    • fixする
  • smart match, given
    • fixする
  • Hash Randomization
  • (?{..}) (??{..})
Fond Farewells
  • いくつかのモジュールはなくなった
  • Text::SoundEx, Pod::LaTeX, CPANPLUSなど
Perl5
  • 新しい名前が必要だ
  • いやいや、何も変える必要はない。ずっと Perl5
  • Backcompat killed my Dog: 後方互換性と進歩の間で
  • Success hates agility: 成功は迅速性の敵だ
Patches
  • ほとんどのパッチは4人からsubmitされてくる
  • みんなもっと貢献できる
Hopes and Dreams: Perl 5.20
  • fatal implicit close() → autodie
  • postfix dereferencing: @{ 長ーい式 }: ->@*
  • key-value slice: %h[ %w(a c) ]
  • chars vs. bytes
Q&A
  • tokuhirom: mop-reduxはいつ入るか? → まずはCPAN
  • miyagawa: CGI.pmは消えるのか? → 消えます

今時のカジュアルなデータベース関連開発

Teng vs DBIx::Class
  • スキーマ管理 DBIx::Schema::DSL
    • MyApp::Schema->outputでスキーマ出せる
    • 定数連携できる、ケツカンマ問題がなくなる
    • 外部キー制約がついたDDLを出し分けできる
    • GitDDLが神
  • なんでMySQL Workbench使わないの?
    • バイナリはつらい → マージできない
  • migration - use GitDDL::Migrator
    • GitDDLを運用向けに改良したもの
    • ミスったときに切り戻せる、履歴を残す
  • gitのコミットハッシュと適用日時(ミリ秒単位)をバージョンテーブルで管理
例外処理 - Exception::Tiny
  • 例外を階層化しておくと便利
    • MyApp::DB::Row::DeleteFailedException
  • findとsingleで見つからなかったときに例外を出すかどうか制御
TransactionManager::EndHook
  • nested transactionで一番外側のコミットが走った時点で処理したいこと
MySQL以外
  • Redis → memcachedが要らなくなった
    • キャッシュ用途というよりはミスヒットしないKVSとして使いたい
    • SortedSetでお手軽ランキングはよく言われる
    • Setが結構アツイ。和・差集合、ランダムに1つ取る、など
    • Listをジョブキューとして使う
  • Redisの注意点
    • Expire設定をしっかりやる
    • LRUには期待できない。あふれると結構変なのが消えちゃう。自分でexpireを管理すること
    • 冗長化つらい
  • Redis.pm
    • PurePerlであまり速くない
    • fork safeなforkあり
    • hiredisバインディングがほしい(EV::Hiredisはある)
  • Cache::Redis
  • Redis::LeaderBoard
    • 同率問題解消のために書いた → みんなやってる処理
  • Fluent::Logger
DB設計
  • テーブル定義
  • インデックスは必要最低限: 複合インデックスあるのに単独も作っちゃうミス
  • 外部キー張らない
    • バッドノウハウ
    • リレーション先のレコードロックが発生したり、不要なインデックスが自動で作られて重複になったり
    • 外部キー側のデータも作らないとテスト作れない。そのかわりちゃんと作ってちゃんと確認すると得
  • 接続時処理

set names utf8mb4;

set session sql_mode='TRADITIONAL';

    • TRADITIONALが一番厳密
    • mysql_enable_utf8している場合、mb4範囲が化ける
  • Unicode6とutf8mb4
    • Unicode絵文字時代
    • default character set utf8mb4
    • 767byte問題 → varchar(191)までしか入らない
  • マスターデータ
    • 固定データ
    • Google spread sheetとかから取ってくる
    • マスターデータの整合性検査をきちんとする
  • 論理削除を使わない
    • 最近はストレージの性能も上がったし、deleteもそんなに遅くない
  • ORM
    • モデルから呼ぶORMはprivateみたいな感じ。必要なクエリをORMに用意

社内開発簡単化と世界で戦う開発を考える技術

  • Inside amon2-livedoor-setup.pl with web application development 2013
  • @yappo
Development Framework
  • というのを考えてみた
  • 使うコードを書くことに集中する
  • WAFの標準的なセットだけでは足りない → 困った → 既存のWAFを使いつつ作れる
  • mission statement
    • アプリのsetupをしてからどういう考えてでモジュール開発をしたか、を統合的に話すトークが最近はない
  • Team Geek いい本でした: (kdmsnrさん監訳)
    • mission statementを書いておくとブレなくていい
ありがちな開発開始手順
  • amon2-setupなどの標準のセットアップスクリプト
    • ただ一つデメリットがある: 社内ルールが反映されていない
  • なんで使うの?
    • A. startupなのでサービスがひとつだけ
    • A. オレオレWAFとか使ってるし標準化とかいらないよね
      • なんとなくで自分のフレームワークとか作っちゃうと後で困る。会社なんでみんなと同じの使うべき
      • ノウハウのたまり具合が違う
    • A 足りないところは社内の別システムからコピペする → わけわかんない設定が入ってたり
  • コピペ駆動開発のデメリット
    • 秘伝のタレ化してしまって、有効性さえ疑われない
  • 社内開発環境の雛形を用意すると仕事が捗る
    • 社内固有のAPIを利用するモジュールを社内リポジトリで管理する
    • → グルー部分が必要になる → ひな形化するといい
ひな形作成のポイント
  • 入れすぎると要らない部分を削る作業に時間がかかってしまったり
    • → ひな形の種類が増える → 増えすぎ注意
  • 社内ルールを意識する。runファイルの置き方とか
  • 開発から本運用に必要なすべてを盛り込む
  • schema loader, deploy tools, CI tools, rundile, batch loader, translate data loader, sass/scss, js/css packer, etc.
  • amon2-livedoor-setup.pl
    • 「このスクリプトたたけば必要なもの全部入れてくれる」スクリプト大事
    • DBスレーブ用
    • warnを埋め込んでおく
    • 参考文献のURLをコメントに書いておく
    • submodule → リンク
ひな形作成の失敗・反省ポイント
  • ひな形作成スクリプトをコピペするようになってしまった → ふり出しに戻った
  • 標準で使いたい機能も差しかえ可能にしたい
  • ひな形作り直した!
新しいひな形の要件
  • シンプルに
  • 同じモノを使ってるならコピペ不要に
  • YAPCに向けた誓い
ksgk Knack of the System Generation for Kurouto
  • 「くそがき」
  • github.cmo/yappo/p5-Ksgk
  • ひな形のroleを指定可能 → role別拡張パラメータ・処理
よかったこと
  • このひな形のこのディレクトリだけ見ればわかるようになった
  • 思想と形てはchef, puppetと同じで、最小限のコードレシピを蓄積 → 適用可能性が上がる

SPDY、HTTP/2.0の使い方

  • @takesako
firesheep
  • firefoxのアドオンで、平文のセッションキーなどを盗む
    • → 各社いっぜいにSSL
  • HSTS: Strict-Transport-Security: max-age=31536000
    • そのURLでは今後一年間HTTPではなくHTTPSでアクセスする
    • 未対応のブラウザもある
SPDY, HTTP/2.0
  • SPDY indicator
  • IPv6都市伝説: コネクション数制限
  • SPDYの出現で発生しなくなった
  • SPDY対応Webサーバー
    • mod_spdy, node-spdy, nginx用ptach.spdy
  • SPDY対応クライアント
    • spdylay
  • Perlモジュールも
提案
  • outbound port 80 blocking
  • 80番をすべてブロック
Q&A
  • サイボウズはどう? → 正直まだ早い
  • SSLにするとCPU使用率上がるのでは?
    • クライアントはスマホ以外はOK。サーバーは上がる
  • 経路のプロキシとかCDNは?
    • akamaiさんは対応済のようだ。プロキシはあまり心配ない

Perlの過去と未来

  • Perl - Past and Future
  • @tokuhirom
Perl5の歴史
  • 1987: Perl 1.0, 1994: Perl 5.0
  • 1998: 5.5, 2002: 5.8, 2007: 5.10,
  • 5.12以降は1年に1回出る
  • cpanmで見るPerlユーザー
    • そんな中でも5.10.1を使ってる人が結構多い
    • 他の言語だとセキュリティーホールがあって更新せざるを得ないがPerlは意外と行ける
最近のupdate
  • say, //, smart-match & given
  • my sub hoge, hash randomization
  • method signatures, ..., ->@*
  • Perl6からのインポートが多い
  • バックエンド側機能
    • 5.8から入ったsource filter
      • → 5.14 custom ops, parser API
        • parse_barestmt, parse_block
    • 5.18: Pad APIs
    • 拡張性向け機能がほしいかな。DSLサポートとか
最近のp5
  • Perlの別実装が増えてきている
    • Moe: Stevan Little (Scala)
    • p2: perl 5+6 = 11: Listen Reini
    • goccy: Compiler::Parser, Compiler::Lexer, gperl, perlmotion
    • (ひとつ聞きのがした)
History of Perl6
  • 2000: Started
  • 2005: Pugs
  • 2010: Rakudo Star!
Rakudo Starは実用に耐えるか?
  • say [+] 1..100 → 0.945秒
  • The nqp language
    • nqp: Perl6のサブセット。Perl6を実装するために作られた言語
    • Rakudoはnqpで書かれている。mostly
Perl6 VM
  • parrot
    • Rakudo動くよー
  • nqpはJVM上でも動く
    • RakudoもJVM上で動くようになった
    • ビルドが大変
  • MoarVM
    • Lightweight VM for Perl6
Perl6 roast
  • test suite for Perl6
  • test suite for implementations
    • JVM, parrotなどのテストケースは最小限しかなく、roastで補う
  • 現状、roastをすべて通す実装はまだない!
Perl6 is awesome!?
  • いいところもある
  • Junction: $var = 3 | 5 | 7
    • Perl6::Junction
    • Syntax::Keyword::Junction
  • MOP, Role
    • p5-mop-redux
    • Mo[ou](se)?
  • slurp/spew
    • Perl6::Slurp, Path::Tiny
  • Rules
  • Reduction operators [+] 1..100
  • Hyper Operators: >>*<< zipっぽく
  • Cross Operators: X 直積っぽく
Perl6 related hacks
  • Perl6、意外と海外で人気ある
  • Regexp::Rules
  • PVIP
    • Perl6 parser library written in C
    • Perl5 bindingもある。roastの50%をparseできている
  • Seis: Perl6をPerl5に変換 (with XS hacks)
    • 1000+個程度のテストをパスしている 千 / 20万だけどw
    • CPANがそのまま使えるよ
Seis demo
  • for 1..12 { .say }
  • [+] 1..100
Q&A
  • dankogai: Perl6が現場で使えるようにならないかなー、と10年くらい待っているんだけど、nqpベースでRubyPHPのように使えるにはあとどれくらい?
    • tokuhirom: すでにaptで入るけど?
    • dankogai: 遅すぎて例外的に時間かかってもいいようにしている
    • tokuhirom: JVM版はそれほど遅くない。MoarVMはまだクロスコンパイルできないけど、それができればだいぶ速くなるかも
    • tokuhirom: MoarVMはparrot上で動くnqpで動くのでparrotの知識がないと貢献しにくい
  • songmu: 正規表現が変わると思うが、p5 regexは標準になっている。受け入れられるのかな?
    • Perl5の正規表現もprefixつければPerl6 regexの中でも動く。長く普及させていこう
  • seisとは「6」です

LT 1日目

@kazuho: Using the Power to Prove
  • 最近あまりPerlを書いてない
  • proveってコマンド知ってる?
    • Ext::HarnessのCLI
  • TAPで出力される。まとめて表示してくれるのがTest::Harness
  • proveを直接たたくと並列に走らせるとか、最近failしたのとか、早く終わるのからやるとかできる
  • Perl以外の言語のもできる
    • なんで? Perlが#!を読んで実行してくれる
    • でもCのバイナリはダメよ
  • .provercに --ext '' --exec ''
  • t/ に入れておけば prove だけでおk
  • サービスモニタリングもproveで可能
  • いろんなタスクを実行してくれる
  • インストールしなくても入ってる
  • TAPを使っているのでどの言語からも使える
@yashims85 ギークな異性を落とす魔法の言葉
@sanemat Tachikomaで依存ライブラリの断続的バージョン上げ
  • n-clickを1-clickにすると商売になる。0-clickにすると革命になる otsune, 2008
  • 変化に対応し続けるのはサービスの宿命
  • Rubyはこまめにbundle updateしないとしぬ。だいたいしない。なのでしぬ
  • プルリクエストでbundle updateしてくれてtravis ciしてくれる
  • CPANのtestamintがいい → 誰かRubyに持ってきてください
  • PerlにあってRubyにないのがfrepan
  • RubyにあってPerlにないものでいいモノというと ci hsbt org。rubyのtrunkで走ってくれる
  • しなないためには変化をしていきましょう!
@yappo: I NEEEEEED HTTP::Body::Builder
  • perlbrew install perl-5.17.2 --as perl-5.17
  • x-www-urlencodedとかform-dataとか
  • こんな仕様で誰か作って!
@hirose31 inspect-perl-proc
  • 実行中のプロセスの中身見たい
  • strace -fF -Tttt -s 512 -p PID
  • gdb
  • gdbperl github:ahiguti/gdbperl
  • inspect-perl-proc @hirose31
    • gdbでattach
    • evalするところで任意のperlコードを書ける
    • 対象Perlデバッグつきでコンパイルされていれば使える
    • どのパッケージがメモリ使っているのかわかる
@yusukebe: YAPC::NAへ行って来た
  • Texas州Austin
  • YAPC::NA厨
  • Inside Bokete
Eikichi Gotoh sendai.pm
@comewalk しげたさん Contributing to open source products
  • sixapart
  • patches welcome → しきい高い
  • stakeholdersがいろいろ
  • メーリングリストのモデレータ
    • spamが来たらだいじょぶな人かどうか見て判定する
    • 時差があるので十分な貢献に
  • 使う → ブログに書く → i18n手伝う → 仕様に使う → パッチ書く → スポンサーになる/メンテナになる
@bayashi 細かすぎて伝わらないモジュール選手権
  • CPANモジュール書けばいい。再開発もかまわない
    • 心配ならPrePANで聞けばいい
  • この1年で26モジュール上げた
  • モヒカンなんてこの世にいない
  • 俺得で十分
  • App::YG mysqlの \G をやる
  • Debug::TraceENV ENVの大域変数化をトレース
  • Plack::App::DummyBox
  • Sub::Sequence 長大なリストをぬるぬるやる → spliceでいいじゃんね
  • Log::Stamper
  • App::LogStats stats -f7 count/avg/max/min/range を出してくれる
  • Benchmark::Confirm 複数モジュールが同じ結果を返すか検証
  • Sub::Data::Recursive Encode::Recursiveでエンコードしない部分だけ
@__gfx__:
@mizuki_r P5-SPICA
  • WEB API便利ですよねー
  • APIにはドキュメントがなかったり
  • 複数APIの仕様が混在
  • base64エンコしたりしなかったりデコードしたり
  • APIごとの違いを吸収して本質的なコードだけ書きたい
  • Tengを参考にしていて、APIの仕様をDSLで書いておく: Github::Spec
@songmu: p5-Riji
  • カヤック
  • Riji: ブログツール
    • dynamic/static generation
  • RubyのJekyll みたいな
  • Riji: RSSをGitから生成する
  • 中国語で発表、すごい!