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
  • 事例
  • 活用の進展
         自社データ       他社データ
 ネット  Web              Web Giant(G, FB, Y!)
         ↑↓        //
 リアル  リアル店舗  ←→ ポイントカード業者(CCC, ロイヤリティーマーケティング等)
  • ビッグデータ活用の高度化に向けた法規則動向
    • EU 「オプトインでないと勝手に収集してはいけない」
      • 2012/5 クッキー法: 事前に同意を得ないとクッキーを出してはいけない
    • 米 「プライバシー憲章」
      • クッキーのオプトアウトサイト: どんな情報を収集して何に使うのか書いている
      • 透明性を担保
    • Do Not Trackを使ってブラウザによる意志表示
      • 広告会社がちゃんと自主規則してくれるか → 業界まかせ
      • CA州 オンラインプライバシー保護法(CalOPPA)
        • DNTに対する対応方法をちゃんと書かないとUSD2500の罰金
        • 例: LinkedIn: 使わない、DNTも使わない
        • trackingしてるなら「してる」と正直に書け、という法律
    • 将来像
      • 消費者本人が自分のデータを管理し、提供先を選択
      • 自分のデータを電子データとしてダウンロード → パーソナルデータストア → 提供したいところを選んで提供
      • 英: midata、米: Smart Disclosure、日: 情報銀行??
    • 行動トラッキングに対する受容性
    • パーソナルデータの利活用に関するWG
  • まとめ
    • 事業者の狙い: customer 360度view       ←┓
    • 消費者は常にトラッキングされることを好まない ←┛ ギャップ
    • 将来的には英米のように自分でコントロールできるようになっていく
Pat Patterson 「Identity in the Cloud」
  • Pat Patterson@Salesforce @metadaddy
  • 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と連携させて使うとも可能

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のみなさんと

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 <
  • 今後
    • 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月から開始
PerlWebブラウザ上で動かす
  • perl.js (@gfx)と同様のアプローチ
    • 最後にemscriptenを使っているのは同じ
    • LLVM-IRに食わせる
  • 違い
  • enscriptenのバグに遭遇して、ところどころ動かない
  • 今後
    • github.com:goccy/p5-Comiler-Tools-Transpiler
PerliOSOSXで動かす
  • RubyMotion, mocl, Titanium
    • Perl版を作ろう!
  • PerlMotion
  • アーキテクチャ
  • デモ
    • 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 を使っています
自己紹介
言語の比較
  • なぜ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: travisperlが検証できるようになったのはコミュニティーが主導していったのかな
    • 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を使っても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 もちろんこれが一番いいが
    • 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から生成する
  • 中国語で発表、すごい!

OpenID Technight #10レポート

9月4日に行われたOpenID Technight #10に行ってきました。
IIJさんの会議室を借りて行われました。

「JOSE + JWT 翻訳」

  • @nov, OIDFJ翻訳WG
  • openid-foundation-japan.github.io
  • JSON Web Tokenとその回り
    • JWT, JWS, Use Cases
JWT in Production
会場に質問
  • JWT知ってる人 … 3割くらい
  • OpenID Connect IdP/RP 実装した人 … 十数人
  • SAMLのIdP/SP実装したことある人 … 数人
  • CSV万能?
SAML, The Enterprise
  • XML Signature / Encryption
  • エンプラは大丈夫。しかし、XML亡き今……
  • XML Sig/Enc for JSON
    • JSON Web Token (JWT), 〜 Signature (JWS), 〜 Encryption (JWE)
JWT, JWS, JWE
    • 何に使うの? → Use Cases
      • トランスポートレイヤーではなくオブジェクトベースのセキュリティメカニズム
JOSE Use Cases
  • 実際のユースケースのリストアップ
    • OIDC, OAuth, XMPPなど
  • JOSEが何に使えるのかをざっくり知れる
  • JOSE仕様に求められる要件をまとめたドキュメント。MLの議論のバックグラウンドなど
JWTのフォーマット
  • コンパクトでURL-safeなクレームの表現方法
  • Claimの集合: SAMLなどから来ているものも
  • JSONBase64 URLエンコードして"."でつなぐ
  • キー名は短縮型。謎の3文字縛り
セキュアに使うには? → JWS
  • 署名したり、MACをつけたりできる
  • ペイロードJSONとは規定していないが、JWTと組み合わせてもOK
  • JWS == 署名つきのJWT、でだいたい合ってる
  • alg = RSA-SHA256 / HMAC-SHA256 × JWS Compact Serialization
    • JWS Compact Serialization: ドットでつなぐやつ
  • 世の中のライブラリもこれらのアルゴリズムしかサポートしてなかったり
その他のJOSE/JWT関連仕様
  • JWE ┓
  • OAuth 2.0 JWT Bearer Token ┛→近日翻訳予定
  • JSON Web Algorithm アルゴリズムの定義
  • JSON Web Key 鍵情報のJSON表現仕様
Q&A
  • JWTの売りは?
    • @nov アプリケーションレイヤで署名が必要かという問がある。XMLならばXML Sigで。JSONでやるとき何を使うかというと、JWSが一番。他にはOAuth 1.0があるが、正規化が必要で、パラメータのキー順に並べないといけなかったり、大変である。OAuth 2.0では署名がないので、署名が必要になったときにこれが使える
  • @tkudos 社内で広めるのに困ったことは?
    • @nov iOSRSAが使いにくい。使ったことのある技術者がいない
    • MAC系とライブラリが分かれていて、低レイヤのライブラリをたたかないといけないなど
  • @tkudos APIプロバイダがJWT使うよと言うので、使わざるを得ない人? → いない

「CIS 四方山話」

  • 「Cloud Identity Summit 2013 で話されたこと、思ったこと」
  • by Ping Identity 近藤さん、福家さん、EXGEN 江川さん、@_nat 、KDDI 小畑さん
CIS 2013 Napa
  • 近藤さん
  • CIS 知ってる人? → 半分くらい
  • Napa だったのでワインのんだくれ + 和装 浴衣より下駄がウケた
  • ファミリー連れてきてください系。家族も楽しめる
    • 家族は期間通しで50ドルで面倒見てくれる
  • テーマ: The Great Enabler of Next
キーノート他
  • 江川さん
  • OIDC、日本ではどういう状況なの、っていう話をしてきた
  • プレゼンがさんざんだった。アメリカのTEDスタイル
    • アメリカのプレゼンスタイル:
    • 歩き回る。スライドめくるのはリモコン
    • 抽象的な写真が多い
  • Ping社長アンドレデュランドのキーノート
    • Identiityについて世の中で何が起こっているかを紹介、その考察
    • 9つのobservation
  • Observation #1: ヒゲが生えるように属性が増えていく
    • Linked.in 属性を22個登録すると、回りの人が評価してくれる
    • 自分についての知ることのできることで、他の人に役立っていること → 伸びていく
  • Obs. #2: I (Id) is connected
  • Obs. #3: I'm been watched
    • 1990年代: ネットの向うのヤツは君が犬なんてわからないよ(Internet Dog) → Now: わかっちゃう
    • IDの便利さはプライバシーの懸念と表裏一体
  • Obs. #4: Even being watching, I'm watched
    • 家でアカウントをシェアしていると、そのシェアした属性が使われる
  • Obs. #5: Cyberがリアルを侵食する
  • Obs. #6: なんでもタグ付けできる
    • Square tag: なくしたときになくしたよってツイートすると、見つけた人が報告してくれる
    • stick-n-find 50m以内で見つけてくれる
    • "Internet of things"の時代が来た
  • Obs. #7: Location, Location, Location
    • どこにいるか追跡される
    • バイス+位置でauthenticationに使われる
    • toopher: ロケーション情報をスマホを通して認証に使う
  • Obs. #8: パーソナルとビジネスのクラウドがいっしょくたになってきている
    • consumerization is real. solutions are born in the void between convenience & control
    • 便利と管理のはざまからソリューションが生まれる
  • Obs. #9: Idは電話の回わりに集中してくる
    • iPhoneケースにクレジットカードを入れている。find my iphoneなど考えるとサイフより安全かも
  • Identityは、ISO 7階層モデル/TCP4階層モデルの第3層(transport層)と第4層(application層)の間にあると考えられる
  • Id must be embedded
  • IAM: SaaSでFederation、次はIDaaS: IAMはenterpriseからIDaaSに移る
    • IAM = Identity Access Management
    • 日本ではSAMLが流行っていない。その次にもっと軽いOpenID Connectが来ているから、これを流行らせよう
  • Liberty Alliance Projectの始まりのころ、Netscapeは.comなどのベースを作りたかった
  • Network Identity → Outsource Identity Infrastructure → Outsource Identity
    • つまり Federation → IDaaS → Trusted ID providers
  • CISのIdentity Manifestoではだいたい流行っているものが殺される
    • 今回は B2B and B2C が殺された
    • これからはP2P、M2M
    • Identity has to move from geek to sheik (sheik: 族長、色男)
  • @shingoym: B2CのC, B2B2EのE, G2CのCって、結局同じ人じゃん。相手によって決まる。どういうこと?
    • → ペルソナを切り換えて使うようなことを言っている
  • 企業の中ってプライバシーが難しい。従業員IDというと、その属性の持ち主は企業。クラウドを使い出すと、属性が外へ出ていく。いままで雇用契約で閉じていたところが、漏れていく
    • → ID & ITでもセッションを用意
    • @_nat: プライバシーは所有権ではなく使用権として考えたほうがいい
セッション全体の傾向
  • 福家さん
  • いきなりまとめ
  • OpenID Connect / SCIMは?
    • Interopやってた
    • OpenID Connect: 実装・普及へ
      • SAML is dead? → 使い分け。みんな話はしないけど使われていく
    • SCIM: 実装・普及へ
      • エンプラにおいて対向はない
      • ネタ: ExcelマクロによるSCIMクライアント
  • API化の流れ
    • アプリの変化
    • API
      • コンシューマからエンプラにも拡大
      • パートナーだけに公開するAPIなど
    • バイスの変化
      • スマホ: ネイティブアプリ。APIによる情報をユーザへ提供
      • 提供形態もAppStoreからダウンロード
      • だけじゃない: カメラ、端末ID、GPS、……
      • Ping Identityでは社内アプリがAppダウンロードで送られてくる
    • これらの変化をふまえて…
      • identityの役割: OpenID Connect / OAuth2 が事実上の前提
    • 一方で認証自体に関しては…
      • バイス自体がidentity表明の中心となり得る
      • クライアント証明書・端末ID
      • バイスの特性を活かした認証: カメラ・マイクで生体認証、指紋、Geo Location
    • ネイティブアプリの活用
  • as a service
    • IDaaS: 必然
    • 単純にID管理をクラウドに持っていくだけではない
      • Trust framework, Attribute exchange
      • AXの例: FCCX
  • NSTIC: National Strategy for Trusted Identities in Cyberspace
    • アメリカのガバメントが進めている
    • Citerion クライテリオン
      • AXN Services Framework
      • IdPとAP (attribute provider)は分離されている
      • @shingoym: 扱う属性はどういうもの?
    • Daon TrustX ダオン
      • スマホを認証デバイスとして活用
      • IdPの出すチャレンジによってPINだったり音声だったりを使って認証
      • PCで認証したいのにスマホに認証要求が来る
      • セカンドチャネルに同意内容を出すことによって、yesと言ったのと違う内容に同意させられたことにされたりということがなくなる
  • slideshare.net/CloudIDSummit
OpenID Connectはあなたの課題をどう解いてくれるか
  • @_nat
  • ISO29003: IDは4つくらいに分ける: G2E B2E G2C B2C
  • OpenID Connecってコンシューマ向けじゃないの?
  • デファクトのID Federationはパスワード共有, Account ProvisioningはCSV
    • SAML: 難しすぎ
  • なぜ失敗したか…
    • 3人以上が知っているものは秘密じゃない
    • 同期が崩れやすい
    • 手動編集はリスク
  • やりなおしだ! 今回は死ぬほど簡単に
  • identity: 定義: 実体に関連する属性の集合
  • ABAC: attribute based access control
  • deployments
    • Windows domain: IIS上にOpenIDプロバイダを実装
    • SMTP/IMP/SSH & OpenID Connect: PAMモジュールとして作成
      • ユーザーはデバイスごと、アプリごとのパスワードをOIDCトークンとして受信
    • token integrity prospection、large providerでやると大量にリクが来て大変
    • privacy proxy
雑談
  • 意外に初心者な質問も出る「SAMLってどうやってパスワード送るんですか?」 Federationというとパスワードを送ることだと思ってる人がいる
  • federationすると集中するからあぶないのでは? と思われる
    • SPOFになるんじゃねーの? 的な
    • パスワードを共有してあちこちに置いちゃうとアタックポイントが増えていく。一番弱いところを攻めればいいので攻める側が楽になっていく
  • 5日間のCISで、3日目からのチケットもあるが、全日参加したほうがいい。頭の2日間のinteropなどがすごくコアで面白い
Q&A
  • 本人認証、シェアアカウントじゃないか、副アカじゃないかという検証は、現状スマホワンタイムパスワードを送るしかない。このようなやり方はどう考えられているか。他の方法はあるか
    • 江川さん: 2要素認証、持ってるものを使うのは大原則。ただしどう維持し続けるかが問題
    • _nat: 声を使うなど。プライバシーと紙一重なので気をつけないと
    • 小畑さん: やりすぎるとコンシューマが使わない。声紋・顔・PIN・パスワード認証の組合せをやってみた。Googleではlocationを使って、ここならば確実に君だよね、ということもやった
  • 知ってる認証、持ってる認証、生体認証。生体はお金かかるし難しいと思うが、いまはできるようになっているのか?
    • 小畑さん: PCでも指紋認証などは値段が下がってきている。AndroidAPIが公開されているかどうだの話だと思う。SMS、メールによるワンタイムなどはカンタン。レガシーではあるがコールバック方式も意外と使える
    • _nat: Googleを代弁すると「自分でやるな」。リスクベース認証をやらざるを得ない。Googleは百何十ファクタを150人体制でやっている。それくらいの覚悟でなければやるな、という時代

感想

私もJWSの翻訳チームに参加しました。多人数で手分けして翻訳したのは初めてで、訳語の統一などレビューが大事だなあと感じました。

パネルは本当に面白かったです。発表に使われたスライドは冒頭で紹介したDoorkeeperのイベントページにリンクされるとのことです。

近くのレストランで懇親会も行われ、こちらでもおおいにもり上がりました。

idcon 16レポート

5月24日に行われた #idcon #16に行ってきました。ヒカリエ21Fの:DeNAセミナールームです。

今回はconsumer secretの秘匿、IIW報告などディープな話が聞けそうです。

(19:10)

OIDFJからごあいさつ

「公式Twitterアプリに望まれる認証鍵の難読化とリバースエンジニアリング対策(仮)」

  • フリーソフト作家: ベクターなどで公開
    • Application Blocker
      • User32.dllをロードするときに、ポリシーを参照して、特定プログラムをブロック
    • Windows 2000拡張カーネル
      • レガシーカーネルを使いたい。.Netアプリや最新ブラウザ、メディアプレイヤーなどが動作可能
  • もふったー
    • Win95で動くuser stream対応のtwitter client
    • MS Unicode, OpenSSL, GDIPLUSを使い、日本語にも対応、アニメアイコンも対応
    • Win95デザインのレガシーな見た目がクール
  • 本題: GIGAZINE記事のネタ: consumer secret keyの難読化について
    • twitterクライアントのConsumer key, Consumer secret key
    • Q: consumer secret keyは難読化しないといけないのか
    • A: 公式の開発ページに「never be human-readable」とある
    • ところがtwitter公式アプリでは生で読める状態だった(メモ帳で開くだけで見える)
  • もふったーの難読化1
    • ハッシュ化していたが、実行時にメモリダンプすると見えてしまう
  • もふったーの難読化2
    • 必要なときにsecretを部分ごとに取り出せるようにしてみた
    • HMAC計算の途中で見えてしまう。メッセージが空白なのでpadとxorしただけのものが見えてしまう
    • 対策
      • メッセージが空白ということは定数なので、ハッシュ済のものを持っておく
      • padのxorを行う関数もひとつにした(ブレークポイントを置けないように)
  • もふったーの難読化3
    • メッセージが長い場合のSHA-1計算2回目が難しい
    • プログラム中の他の部分とxor。どこだかはわからない
  • おまけ: リバースエンジニアリング対策
  • Q&A
    • nov: Windowsの場合の話だったが、iPhoneとかだとどうかくしたらいいのか
    • BlackWingCat: 開発環境でないとそもそも見られない。少し難読化した方がいいだろう。Javaだと逆コンパイルで見えてしまう場合もある。公式アプリは特権を持っているので、漏れてしまうと困る
    • nov: 公式アプリだからって特権(rate limitを上げるなど)を与えなければいいのに
    • lef: じゃあどこまでやったら納得いくのか。最後の最後は読まれてしまうのは避けられない。みんなここまでやれるんですかというバランスの問題。実際どうだった、やりすぎだったのか
    • BlackWingCat: うちのは公式アプリではないし有名でもなかったので、ここまでやる必要はなかっただろう。しかしkeyを抜かれて悪意あるアプリに組み込まれると信用を失ってしまう。最低限の難読化は必要だろう
    • ?: secretをサーバーに置いて、トークンだけをクライアントにもらってくるようにしたらどうだろう
    • → nov: OAuth1.0aだとリクエストごとに署名が必要なため、クライアントがsecretを知っていないと
    • → BlackWingCat: サーバーでproxyしてやればOK → それならブラウザアプリでいいじゃん
    • → nov: OAuth2.0ならば、トークンだけ渡してやればいい
  • nat: dynamic client registrationでインスタンスごとにsecret作るしかない。これ以上はOSの支援でクライアントのハッシュを得るなどが必要
  • mad_p: 抜かれて困るのは、自分のクライアントの名をかたって悪意のあるクライアントを作られるリスクだけか? エンドユーザーもサーバーも困らない。アプリ作者だけが困る
    • nov: 公式アプリのsecretを使ってtwitterphishingサイトを作ることができる。多くの人が使っている公式アプリをbanしにくいだろう
    • nov: nativeアプリのcredentialを抜いてnativeアプリで使われる分にはApp Storeのような仕組みでなんとかなる。iframeでいたずらされると困る
  • lef: twitterにOAuth2対応してくれ、でFA。開発者としてはつらい
  • ?: API1.1から、いくつかのAPIではOAuth2.0ベースで実装されている部分もあるようだ
    • nov: twitter anywareは裏でOAuth2のような何かを使っていたようだ。実装は持っているのに公開していない印象
  • 感想: 懇親会などでも、結論は OAuth2.0にしてdynamic registrationを使う、ということのようです。refresh_tokenも永続化するのであるし、dynamic registrationは難しくないとのこと

(20:00)

休憩

(20:10)

「IIWでセッション立てたよ(技術者じゃないけど) -- IIW#15報告」

  • @IdentityPenguin
  • 本職は社会科学と技術の関わりについてを研究している
  • IIW#15 (2012/10/23-25)のレポート
    • 会場はおなじみ: Computer History Museum
  • IIW: worshopの進め方…アンカンファレンス
    • 顔を合わせた初日にスケジュールを決める
      • この分野の変化が非常に早い → ニーズはあらかじめわからない
      • 学ぶこと、contributeする情熱を持つ参加者を主体としたい
    • 毎朝セッション座長を立候補で決める
  • 軽い朝食、エスプレッソが提供されている → 食べ物があると人が集まる
  • まずはテーブルに分かれて座る
    • 必ず新人を一人は入れること! by IdentityWoman
    • テーブルごとにお題が配られて、言葉の定義を各テーブルで話し合う。例:「framework」
  • 参加者全員が輪になって座る
    • テーブルごとのお題の紹介 → セッションを立てる
  • セッション「Anonymous」
    • 匿名性について、4chan(米国版2ch)を引き合いに議論
    • Pseudonym(仮名)との違い
    • 「匿名性」の定義についてはうまく合意できなかった
    • Pseudonymは含まれるのか、複数の発言が同一人物とわかってはアウトなのか
  • セッション「Reputation Consulting .05Cents」
    • 1vs1のセッションになってしまった
    • 個人や企業についてのreputation controlの必要性
    • すべて実名でオープンは危険すぎる
      • シリコンバレーはみんな実名でしょ → そんなことはない、シリコンバレーは世界がせまいので、むしろオープンにできない
      • 例: Facebookは家族・親友のみ、LinkedInはオープン。私的なことは名前を変えてblogに書いたり。identity controlが必要。名寄せされたら困る
  • Dinnerで
    • 「Anonymousの逆って何だと思う?」 → 議論がもり上がり、セッションやろうかな
    • セッションやれるよ → やってみよう
  • セッションの立て方
    • 誰でもOK!
    • 1セッション50分
    • 自分でテーマを決め、色紙に書き、早い者勝ちでセッションボードに貼っていく
    • 大きい紙にトピックを書く、ふせんが部屋になっている
    • 本当に早い者順
    • 会場にてログ係(note taker)を指定する
  • セッション「What is Real Name」
    • 17名
    • note taker指名しなかったら誰も取っていなかった
    • 口火を切った人は、何度も実名が変わっている人だった
    • そもそも実名って変わるものじゃないの? 実名は変更できるの?
      • 法律の問題
    • Williamの愛称はBill。同一人物の担保が必要な場合も
    • 個人の識別と特定に必要な情報は何か?
      • 同姓同名の人がいれば別の属性が必要。居住地、髪の色など
      • 名前空間の大きさにもよる。国家・コミュニティーによって違う → サイズによるのでは?
    • 実名はなぜ必要か?
      • Reputationに結びつく
      • 信頼を担保する。社会のしくみとして必要
    • それなら、国に登録している名前でなくてもいいのでは?
  • やってみて
    • unconference形式 → 手を挙げてやってみると得るものは多い
    • 議論はできた
    • ログは残しておくこと!
      • フレッシュなものを議論する → フレッシュなものほど残しておくべき
  • 「最後に名寄せしておきます」ということで@IdentityPenguin の中の人は@oritakoさんでした。山中さんのビデオで言われていましたが、あれはプライバシー侵害ですよねー、自分の望まない名寄せは困るよねー、との指摘
  • nat: その1v1だったreputationの本書いた人ってRandy Farmer?
    • IdentityPenguin: わからない。名刺ももらったんだけど…
  • nat: real nameの話で、範囲が小さいと属性が少なくてすむ、大きくなると属性がたくさん必要というのがあった→これってISOの定義そのもの。ある範囲で特定するに足る十分な属性の集合。日本人はidentityと言うと1個のidentifierだと思ってしまうが、属性の集合としてとらえるべき
    • IdentityPenguin: なるほど! 実生活での実名の考え方とISOの定義がつながってすっきりした

(20:38)

「IIW #16に参加してきた。Sponsored by GREE

  • @nov
  • IIW参加は2回目。GWあけ直後
    • 前回は有給取って自費で行った。今回は会社が出張扱いにしてくれた
  • 会場はいつも同じ: Computer History Museum
  • session creation
    • personal cloudがバズってた
  • 大きな部屋は30人くらい。小さな部屋は8人会議室に15人とか。廊下もあり
  • NotesがWebで公開される
  • セッション「Mobile SSO」
    • Sascha Preibisch, Layer7
    • エンタープライズ分野のiPhoneに特化したSSO
    • Connectそのままはないが、OAuthするときにid_tokenを発行 → 同じベンダーでだけshareできるkey chainに入れる
      • アプリA1を認可した後、同じ会社のA2を入れると、認可の必要がない
    • mssoというスコープをつける
    • generate RSA key pair on client side (OPTIONAL)
      • 複数のアプリがそれぞれIdPになる
    • nat: OpenID Foundationでもうじきこの手のことのworking groupができる
  • セッション「Mobile SSO」
    • George Fletcher, AOL
    • モバイルのネイティブアプリと同じデバイス上のwebブラウザ
    • webssoというスコープでaccess_tokenを取る
      • webssoにdown scopeしたtokenをrefreshで取って渡す
    • ID tokenをweb appに渡すような感じ
  • 「Auth@Google - Next 5 Years」
    • Eric Sachs, Google
    • Google docsに資料あり
    • 過去5年何をやったか: リスクベース、2要素、OpenId, OAuth
    • good news: アカウントhijackされてスパム配信されたアカウント数。リスクベースでかなり減った
    • bad news:
      • OpenIDへのmigrationは難しかった。usabilityに難あり → account chooserへの流れ、account linking: 同じメアドのときに同じアカウントにするか分けておくべきか → RPの人達が考え込んでしまう
      • Account recoveryがアキレス腱
    • 今後5年間
      • 5年前にやろうとしていたことと5年間でやったこととは結構違っていた。スマホが流行ったとか
    • Setup, not sign-in
      • ネイティブアプリはインストール時にログインしたらそれっきり。クラウドのwebサイトはいつもログインし直し
      • webでもsetupすればいいんじゃないか。OSレベルのaccount managerが必要
      • account switchの機能もOSレベルで提供
    • Reduce Bearer Tokens
      • OAuth 2.0のaccess tokenはbearer
      • JWT bearer tokens
      • セッションクッキーもbearer
      • → こいつらをもっとsecureにしたい
      • self-signed cookie: ブラウザ内にキーペアを生成、サイトにpublic keyを登録
      • chrome://settings/cookies に行くと「チャンネルID」と出るのがそう
    • Smarter Hardware
      • Chromeでサイトにアクセスするとリスクベースの確認がAndroid側に出る
      • バイスのunlock/activationをすでに持っているdeviceを使って行う。google device同士だとできるんだけど → 標準化したい (FIDO ファイド Alliance)
      • nat: PayPalが中心になっている。これを標準化したい
      • universal second factor
      • yubikey: USB keyboardとしてワンタイムパスワードを入力してくれる、安いデバイス
  • 「OAuth & JOSE @ BlueButton+」
    • Justin Richer, MITRE
      • OAuth, OpenID ConnectのMLによくいる
    • OAuth2のdynamic client registrationのauthor
    • use caseとしてBlueButton+というのを作っている
    • 「trusted registration」
    • BlueButtonとは: ヘルスケア情報を患者が自分でアクセス可能にする
    • nat: 退役軍人さん達が自分の健康情報を取ってお医者さんに持っていく
    • class: クライアントのテンプレート
      • registration_jwtを発行 → nativeアプリにうめ込む
    • instantiation: Dynamic client registration
      • registration_jwtを使ってtrusted registrationできる
    • discovery: OAuth2にはまだない。
      • registry discovery: エンドポイントを見つける
      • providers authサーバーのリスト
      • provider ひとつのプロバイダのエンドポイントリスト
      • apps discovery AuthZがクライアントのリストを確認
    • push authorization
      • あるユーザーに定期的に過去3か月間の通院記録を送るための認可
      • authorizationだけして、access tokenは発行しない
  • Personal Cloudがよくわからなかった
    • nat: lifelog managementに近い概念かも
    • nov: パーツが全部クラウドにあって、どのパーツにどのベンターを使うかを自分で選べる
  • nov: device上にkey-pairを作ってseld-issuedみたいなのが面白かった

(21:20)

懇親会

  • :DeNA様ご提供のフードとビールをいただきました。ごちそうさまでした
  • @flano_yuki さんから「OAuthたん」ステッカーが配布されました!
  • 秘密の質問と答の流出事件、マイナンバー法案、OAuth2 dynamic client registrationなどが話題になっていました
  • 個人的にはnatさんからOpenID ConnectのRequest File Methodを聞き、興味を持ちました。Open ID Artifact Bindingと呼ばれていたものですね。このメソッドではリクエストが業務に必要な情報しか取得しないことを第三者機関によって検証できるそうです。法律の要件に合致することが認められれば、ユーザーの同意画面をスキップ可能とのことです。ちょっと詳しく勉強してみようと思います

以上です。誤りや発言意図と違うなどあればご指摘ください。

JICS2013レポート(3) 3/4午後 OpenID Summit

OpenID Foundationについて

  • nat
  • 1997年米国オレゴン州
    • WGが仕様を作る
      • AB/Connect WG
      • Accont Chooser WG
      • Backplane WG
    • Specs Council: WGを設置していいかを審査する
    • membership 300名くらい
    • Board: 財務、戦略
  • OIDFメンバーの得
    • 戦略に影響を与えられる
    • 思想的なリーダーに接触して話を聞くことができる
  • 語彙
    • IdP: Identity Provider: 認証および属性の提供
    • OP: IdPのうち、OpenIDプロトコルに対応しているもの
    • RP: 認証結果および属性をIdPから受け取って使うサービス
    • Claims: 属性

OpenID Foundation

  • Identity Data Leverage
  • 金融市場のレバレッジと比べてみよう
  • データレバレッジ
    • 信頼ができて共通アクセスができる
    • 最も少ない摩擦で複数パーティー間で利用
    • 金融システムではルール・ツールの標準化が必要 → ステークホルダーによって信頼される
      • IDデータも同じ: 交換のためにルール・ツールが重要
  • ツールとルール
    • technology tools: open standards, protocols
    • policy and rules: trusted systemがvalueを生みだすためにdriveする
  • インターネットidentityの2つの組織
    • OpenID Foundationと日本ブランチ
      • protecting intellectual porperty, brand, trademarks
    • OIX: Open Identity Exchange
      • policyを決め、相互運用性を保証する
  • Tools + Rules = Trust
    • トラストフレームワークはデータレバレッジにおいて三者間の調停をする
      • Policy makers, IdPs, RPs
    • TFの例: クレジットカードシステム
      • VISA
      • pre-negociated tools + rules
      • issuing bank - merchant bank
      • cardholder - Merchant
      • repeatability
    • 効率のよいTFの働き → あらかじめ知ることができる
      • 文書化と標準化、義務の強制
      • 法的なきまりごと
      • data subjects: data integrity
      • RPs: assurance
      • IdPs: risk reduction
    • stakeholder requirements
      • reliability, predictability : これら2つが基本
      • interoperability: 技術的な標準、プロトコル → 複数サービスが情報の種類等をあらかじめ知ることができる
      • security: must: セキュリティーへの平等なcontribution
      • easy user interfaces
      • cost effectiveness: レバレッジ活用のために効率化が必要
      • risk reduction: ID盗用などのリスクをすべてのstakeholderが解決
      • trancparency
      • privacy-enhancing
      • → design principlesに反映
      • → 競合社をstakeholdersにかかえる中でdutyとpolicyを明らかにする
  • building 信頼 in online identity
    • tool + rulesができた後、shared notion of transparency
    • 標準の開発において平等であること
    • 価値創造
    • 学認の例: 複数のstakeholder, 組織が新しい価値を開こうとしている
      • 学認はtrust frameworkの日本における最初の挑戦であろう
    • 議論のコンテキストは広い。WGが初期のインサイトをtoolsに入れる
      • account chooserがUXを根本的に変える。backplaneではweb site運用者にまた違うaspectsをもたらす
    • Google in London, Mountain View, Munichで対話が始まっている
      • dataをunlockするための新しい方法

OpenID Connect

  • OpenID Connect: OAuth2.0の上に乗せるidentity層
  • identity = ある実体に対する属性の集合
    • entity - attribute modelを理解
    • 相手によってどの属性を見せるかを制御することによってidentityを見せている
    • 男性は数個、女性はもっとたくさんのidを使い分けているw
  • OAuthじゃダメなの?
    • OAuthはアクセス許可プロトコルなのでidentityの概念は含まれていない
      • aliceがcindyにbettyの情報アクセスを許可してもcindyはaliceではない
  • Signed Request vs Id Token
    • 誰がいつ何の目的で認証を受けたのか
  • OpenID Connect
    • interoperability
    • 実装がカンタン: JSONベース、REST Friendly
    • セキュリティーモデル: ISO 29115 LoA4〜1をサポート
    • 柔軟性、集約・分散クレーム
    • プロバイダ選択の自由: スマホ内のIdPもあり
  • Interop中。始めるならいま
  • OpenID Connect: 共同作業の産物
    • MS, G, f, ebay, Y!, T, ...
    • 週2回電話会議、大量のMLメッセージ
  • OpenID 2.0との違い
    • Amazon使ってる人は使ってる
    • OpenID 2.0はWeb用。スマホのAppsには対応していない → Connectの重要な課題のひとつ
    • emailサポート
    • user endpoint
    • XMLJSON/REST
    • 暗号化 → より高いLoA
    • セッションマネジメント すなわちログアウト
    • self-issued identity
  • Simple Things Simple/Complex Things Possible
    • Standard UserInfo for Simple "Connect" Ability だじゃれ
    • 必要なところだけ取って使えばいい
    • ゴール: すべてのプラットフォームで動く
  • claimモデル
    • 集合、分散、暗号
    • 公開鍵で暗号化すると、特定読者にしか読めないようにできる
    • SAMLとの違いとして
      • パラメータをクレーム上に乗せることができる
      • 18歳以上、クレジットステータスがOKなど
  • 集約クレーム
    • 従来の問題: 情報をひとつにまとめる必要があった
    • Connect: ポインターを複数入れればよい
    • シンプルクライアントは署名のこととか気にしなくていい
  • Connect Interop
    • 4th round
    • 14 implementationsが参加
    • 仕様が何を言っているのか合意できる
  • ID Token
    • JWT token representing logged-in session
    • iss, user_id, aud, iat, exp, nonce
  • claim requests
    • scopes: openid, profile, email, address, phone
    • UserInfo claims
  • implicit flowの例 ブラウザ内のJSアプリ
    • userinfo request にaccess_tokenを渡す
  • Connect仕様のサブセット
    • minimum
    • dynamic: discovery + dynamic client registration
    • complete: 集約・分散claim, セッション管理
  • basic client profile
    • シンプル、self-contained、web-server based RP
  • implicit profile
    • agent based, ブラウザ内のJavaScript clientなど
  • messages & standard
    • データフォーマット
  • session management
    • single logout機能: SAMLではうまく扱えなかった
    • G+を妻から夫に切り換えたらRPも同期して切り換わるなど
  • OAuth 2.0は完了
    • JWTはまだRFCになっていない: JWS, JWE, JWA, JWK (JSON Web Tokenシリーズ、Signature, Encryption, Algorithm, Key)
    • JWTはXMLと比べてcanonicalizationが楽になる
  • 仕様のopen issues → すべて解決した
    • webfingerを使うことを決定した
  • related specs
    • OAuth dynamic-registration
    • User managed access
  • risk
    • IETF仕様への依存が少し残っている

Acconut Chooser

  • Tim Bray (Google)
    • 資料
    • Account Chooserをプロモートしたい。自分はGoogle社員だけど、ACはGoogleの持ち物という訳ではない

  • Federated Identity
    • 未来である。重要。すべてのサイトでパスワードを管理したくない
    • 問題がある: NASCAR問題: たくさんのロゴが並んでどのIdPでログインするか選ばせる → NASCARレースの車の広告ロゴみたいだ
      • 選択肢が多すぎるのを人々は好まない
    • 別の問題: federated idを切り換えるのが難しい
      • 4月1日から従来のログインシステムからID連携に切り換えるとして、スパッといくとは思えない
  • Account Chooser デモ
    • FavColor、好きな色を覚えるアプリをデモのために作った
    • 従来のログイン画面: ユーザ名とパスワードではなく、nascar式のログインページ
    • Account Chooser: nascar問題っぽいものが見えるが、リストされているのはhighly personalized
      • G+とfacebookで同じメアドを使っているので同じユーザーとして認識される
      • 別のメアドでgmailにログインしたら色が記憶されていない
    • OpenID ConnectによってAccount Chooserが動いているのだ。理論上の存在ではなく動くソフトウエアだ
  • Account Chooser for users
    • ワンクリックでログイン可能
    • 複数のIdPをツークリックで切り換え可能
  • AC for Web sites
    • ワンクリックサインナップ
    • ナスカ問題なく正しいIdPを選択可能
    • ID連携への移行がカンタン: だんだんと移行可能
    • 間違ったIDでのログインが減る
  • AC for 開発者
    • 1. https://www.accountchooser.com/ac.js をインクルードしたらOK。これだけ
      • IdPリストを送ってもよい
    • 2. ac.jsがaccount-statusに情報をPOSTする
      • email address, IdP, Photo URL, Display Name
    • 3. account-statusから結果を返す。registered: true/false またはauthUrl
    • 4. After signin update ac.js 取得した情報をac.jsに教える。通常は何も発生しないけどね
    • とってもカンタン
  • account chooserのセキュリティー
    • ACの画面に行くと通常のWebサイトに見えるが、これはfakeである。リストされているアカウントの情報はHTML5のローカルストレージに記録されている。これらの情報はaccountchooser.comに送信されるわけではない
  • Account Chooserは
    • ID連携の最初のステップ
    • ブラウザのHTML5 storageを使用。すべての情報はユーザーのPC内
    • ワンクリックでログイン、ワンクリックで登録

Backplane Protocol

  • Backplane
    • trusted application間で情報共有するためのprotocol
    • アプリウィジェットが複数のIdPからの情報を共有
    • トラストモデルdriven
  • social identity → OpenIDに影響を与えた
    • 既存のクレデンシャルでfirewall外のサービスにアクセス
  • Social Identity Can Make Apps Sticky
    • Log in to my Samsung: ソーシャルログインしたユーザーがレビューを書く可能性506%も高い
    • ユーザー登録は面倒: 86%のユーザーは登録しろと言われたらサイトを去る
    • OpenIDがサイトに出現
  • janrainのsite admin: login widgetをつける
    • OpenIDでログインできるようになる
    • Backplaneサービスでこれが可能に
    • Add activity stream appを画面につける: ゲーミフィケーションとか
      • feedback widgetが他のサービスプロバイダ
    • どうやってログインしているユーザーの情報を渡せるか
  • integration challenges
    • transport layerがない
    • 実装がinconsistent
    • security leaks
    • ペイロードのセマンティクスが決まってなかったり
    • custom developmentが必要
  • backplaneで解決
    • secure transport layer
    • payload semantics
    • plug'n'play
    • speed the market
  • how it works
    • 1. publish event id/login
    • 2. receive event as activity
  • backplaneを使うとき
    • アプリ間でデータを渡したいとき: id, activityなど
    • consume profile data from IdPs, user id, profile, analysis, 3rd-partyシステムに知らせる
  • example: NASDAQシステム, AA(American Airlines) Social Newsroom
  • backplane-enabled apps
    • janrain, echo, marketo, onvelove, umbel, disqus,
    • backplaneを使っているサイト: sony, AA, disney, espn, nasdaq
  • app developers
  • backplane v2 demo in janrain
  • oppotunity
    • simplify integration to share information btwn sites
  • backplanex.com/japanに資料貼っとくからー

OpenID活用事例と最新動向

  • 課題と方向性
    • 多様化するメディア・デバイス → 認証、グローバルプロファイル → 利便性を高める
    • 楽天会員が世界中の楽天サービスをシームレスに利用できるようなシステムを目指す
  • 渡辺さん
  • ユースケース1: あんしん支払いサービス
    • checkout service
    • 外部サイトが楽天に登録されているクレジットカード情報で決済可能
    • 外部サイト「楽天で決済」 → OpenID楽天認証 → 元サイトに戻る
  • ユースケース2: 楽天kobo
    • 電子ブック
    • 楽天会員情報使ってログイン、決済
    • OAuth2.0を使用し、クレジット、スーパーポイント等の会員情報をAPIで取得
  • ユースケース3: お気に入りブックマーク
    • 楽天市場の商品をwishlistに
    • OAuth2.0を使って外部サイトからのアイテム追加・一覧取得などが可能
    • 楽天商品検索もできる
  • ユースケース4: アメリカダイレクト
    • buy.comの米国サイトの商品を日本でも買える
    • OAuth2.0を使う
  • 今後の取り組み
    • 世界各国のグループサイトをシームレスに使う
      • どこかの楽天グループサイトのIDをひとつ持っていれば他のグループサイトでも使える
      • 中央に認証/認可制御サイトを置く
      • Connectを使って、グループサイトをIdP/RPとして使う
    • 1. kobo IDでログイン、楽天会員情報でお買物
    • 2. Buy.comに登録したクレジットカード情報を使って楽天で買い物

時間があまったのでQ&A

  • DNSポイゾニングをしてac.jsを置きかえる攻撃に対してどうな対策をしているか
    • #1 worry である。あまりやってない
    • DNS攻撃だけが心配
    • DNSはセマンティクスで保証されている状態。同じことをするしかない。銀行なんかも同じ
    • TLS証明書の検証でブラウザから警告を出す
  • BackplaneとOpenSocialの違いは?
    • good question!
    • trust frameworkでやる

その他

  • 会場では各種のデモなどもありました。その中でTuliooのデモはなかなか面白かったです
    • https://www.trulioo.com/
    • facebookアカウントを実在する人間かフェイクのスパム用アカウントか判定してくれます
      • 「このアカウントの現在のありようをフェイクするなら1000時間かかる」などと結果が出ます
    • ホテルレビューサイトでヤラセ評価を検出するために活用しているとのことです
    • クローリングした日記や写真などの活動を元に評価しているそうです。アジアの言語はどうやっているのかと聞いたのですが、難しいようですね
  • この後の懇親会にも参加させていただきました