JICS2014レポート(1) 1/14前編
2014/01/14に学術総合センターで行われたJICS2014に行ってきました。当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。
ビッグデータとアイデンティティ
- 10:30- #intro
- 資料
城田真琴さん
- 城田さん@NRI @Makoto_Shirota
- 新技術の動向調査、ここ2〜3年はビッグデータ(その前はクラウドコンピューティング)
- パーソナルデータWG委員
- 今日のおはなし
- ビッグデータ=ビッグリスク?
- 企業のビッグデータへの取り組み状況
- 日米英独中の中では日本の取り組みが遅れている。中国は「すでに」「試験的に」を加えると50%超え。日本は10%未満
- 企業のビッグデータへの取り組み状況
- ビッグデータリスクの事例
- ビッグデータ活用の高度化に向けた事業者側の狙い
- 現在: 自前で収集したデータの活用
- 次のステップ: 他社データの利用
- 自社(単一)→自社(複数)→他社(単一)→他社(複数)
- 右に行くほど、得られる価値も大きいがリスクも大きくなっていく
- 目指すのはあらゆるチャネルからのデータを活用した真の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
- EU 「オプトインでないと勝手に収集してはいけない」
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のみ
- 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はアドオンではなくコア
- cloud-based
- identity platform: salesforceの設計思想を紹介
- SFの相互運用性に関する戦略
- Internet scale
- SF ID Platformを絵にすると
- クラウドの中核には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
まとめ
- セッション参加も楽しいが、自分でセッション立てると得るものは多い
- エンジニアじゃなくても貢献できる & 得るものはある
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使ってました?
- @_nat: 使うのは基本ケータイやスマホでPCではなかった?
- 当時はほとんどガラケー
- 山中: ネットでモノを買うときは、スマホ? PC?
- → パソコンが多い(学生も会場も)
- @hiroki: アパレルのような見定めしにくいものはケータイ・PCで買うことはあるか?
- 服だとサイズもあるし、店で試着してからPCで買うこともある
- 「意識している」というのをどう定義しているのか?
- アンケートで「はい」と答えた人だとすると「アンケートバイアス」がかかっているのでは?
- はいってみんな言うと思うが、いいえと答えた人もいる
- 「はい」の書いてある同じページに公開項目の問を置いたが、バイアスがかかった状態でも「実名」などは公開するにチェックをしている回答が多かった
- @shingoym: 意識してるかしてないか、と言うと意識している。それは無意識に意識している。それを深ぼりすると面白い。どうして意識するようになったか、そのリテラシーをどこから得たのか、誰から教わったのか。失敗して学んだのか、親から学んだのか。質的なインタビューする必要があるでしょう
- みなさん使い方はどうやって学んだ?
- → 使っているうちに。設定しないといけないな、と思った → それが identityのめばえ
- みなさん使い方はどうやって学んだ?
- なぜ田中太郎なのか
- @_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)
- 自己紹介
- 暗号技術、暗号プロトコル技術、情報セキュリティー技術
- 自称「生活者視点の暗号研究者」
- 電子投票、入札、抽選システム、匿名認証
- 最近の興味: innovation producer
- ネットって生きにくい
- パスワード多すぎる
- 行動ターゲティング広告
- Doc Searlsの「インテンションエコノミー」に感動
- IIW17に参加
匿名認証
- verifierにユーザIDを伝えることなく、ユーザの属性を証明する方法
- issuerがユーザーにcredentialを渡す。ユーザーがverifierに何らかの正当性を証明したい。属性を証明したい。ただし、自分が後で特定されるような情報(IDなど)は渡さない
- 特定されない(匿名)、属性を証明(認証)
「匿名」「プライバシ保護」について、暗号研究者の視点から
- 電子投票のプライバシ保護を例として
- 「田中さんがObamaに投票した」を安全に集計する方法(何を暗号化するか)
- 「誰か」がObamaに投票した → 投票主体を匿名化
- 田中さんが「誰か」が投票した → 投票内容を暗号化
- 「誰が」「何をした」の何かをかくそうとする、それが匿名化だと考えていた
- 「田中さんがObamaに投票した」を安全に集計する方法(何を暗号化するか)
- 最近の「k匿名性」
- 「田中さんが田町で乗車して渋谷で下車して化粧品を買って老眼鏡を修理に出した」
- 田中さん、だけをかくしても他が見えていれば「田中さんぽいぞ!?」と特定されてしまう
- 行動データを「あいまい化」して、一連の行動データや属性データから推測されないようにする
匿名認証(ユーザー匿名化) + (属性認証)
- 属性証明書との違い?
- one-time 属性証明書であれば?
- issuerとverifierが持ちよれば、誰に発行した属性証明書が使われたかわかってしまう
- 暗号コミュニティーのめざす匿名認証
現実にセキュリティとプライバシが両立されるような応用例を考えるために、シンプルな匿名認証方式で考えてみよう
- デジタル署名
- だれでも個人公開鍵を用いてユーザを特定可能
- → 「あの人こんなこと言ってたよ」が転送できる → 「署名のひとり歩き問題」
- グループ署名
- 応用例
- 例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脆弱性を持つログインサーバー
- ログインフォームからID/PWを送る → ログイン
- 攻撃者のID/PWを送ってやると、ユーザーAのセッションの中で攻撃者のアカウントとしてログインしてしまう
- 気づかずに保存したデータを悪用されてしまう
- とるべき対策
- セッションIDをログインフォームのhiddenに入れておく
OAuth 2.0とCSRF
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でも使えるよ(今日は割愛)
Q&A
- @lef: サーバー重くなんないですか
- なんないです。長くなるので略
- @_nat: RFCにはいつするの?
- 心しておきます
YAPC::Asia 2013セッションメモ9/21分
後でちゃんと編集します。
乱文でごめんなさい。
Perlで書く結合テスト
- @ikasam_a
- Testing Casual Talks #2 11月ごろで調整中
SWET, TE
Developer Productivity
- 2つの役割
- (後でスライド見て補完)
- Testingにかかわる活動
- SWET Group Mission Statement
- テストをしやすくして、生産性を上げる
- エンジニアリングとしてtesting活動をしていく
- 自動化など
テストの分類
- 4つの分類軸
Perspective Target
How What
Integration Testing
- 結合テスト: 「何と何が結合している状態」なのか?
- 単体の裏返し
- 「モジュールが結合」してコンポーネントを作る
- 「コンポーネントが結合」してシステムになる
- ユニット間のインタラクション/オーケストレーションをテストしていく
結合テストのケーススタディー
- Web API
- HTTP JSON-RPC API
- interaction & integration
- テスト用クライアントからAPIサーバーにリクエストを出し、レスポンスを見る
- APIサーバ内のモジュール間結合、バックエンドサーバー群との連携
- 入力: HTTPリクエスト、出力: JSONレスポンス
- HTTPクライアントには
- JSON validation
- gray box fixture
- DB/Cache manipulation
- テストケースに依存したデータを作成
- 継続的テストのためにキャッシュを消したりとか
- 普通のオペレーションで生成できないデータを用意する
- 特定サーバー向けリクエスト
- HTTP Messageを見る
- Web Application
- UIのWebアプリ
- interaction & integration
- Web Appモジュール: MVC的な
- Web APPとバックエンドサーバーとの間の連携
- 入力: HTTPリクエスト、出力: HTMLレスポンス
- ブラウザ、user agentを使う: JavaScriptが解釈できることが重要
- Switch Browser
- テストの中でJSを使えるブラウザとJSを使えないブラウザを切りかえたいというニーズがたまにある
- ブラウザはHTTPヘッダをさわれない
- エミュレータはJS実行できない
- ブラウザのpseudo state(セッションなど)をセーブ/リストアする
- ヘルパーとしてまとめておく
役立つモジュール
これからのPerlプロダクトのかたち
- @goccy54
- 自己紹介
gperl
Compiler::Lexer
Compiler::Parser
Compiler::CodeGenerator::LLVM
使い方
PerlをiOSやOSXで動かす
静的解析ツールとして使う
Lexerを使っているモジュール
- Perl::MinimumVersion::Fast
- Test::LocalFunctions::Fast
今後
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
- t: 15歳くらいからRubyとPythonを使っていた。Rubyist Magazineに寄稿した。LLの実行委員をやったときにPerlの会社に行って書くようになった
- t: 当時naoyaさん、miyagawaさんがblog hacksをやっていて楽しそうだった。言語そのものに興味があったので、それまで使ったことのないPerlをやってみた
- いちばん好きな言語はRubyだと思うが、こういうところが好き、とかある?
- h: Perlとの比較では、標準ライブラリのセンスがすごくいい。PerlだとList::Util使わないといけなかったりという部分が、そのままサポートされている
- n: やろうと思えばできるというのと、処理系がサポートされていることには違いがあるのか?
- h: 学習のしきいが高かったと思う
- s: ごく最近Perlをさわりはじめた。違うところより似ているところが多かった。仕事の中でpr出したら何も問題なくマージされた。差分よりは似ているところのほうが多いと思う
- m: RubyはMatz Rubyの他に処理系のバリエーションが多い。JRubyとか。最近だとmrubyが出たりしている。こういうのはPerlにはあまりない
- h: Perlとの比較では、標準ライブラリのセンスがすごくいい。PerlだとList::Util使わないといけなかったりという部分が、そのままサポートされている
- 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: RubyはRails以前から使っているが本格的に使うようになったのはRails。Railsはビジネスとつながって経済圏ができているのがすごい。herokuとかNewRelicとか。RubyはOSSコミュニティーだけでなくお金が出るコミュニティーもしっかりしている
- s: RubyがすごかったというよりRailsが切り開いた面がある
- n: Rubyが良かったのかRailsが良かったのか、そのへんはどう?
- m: コミッタの視点でどう?
- s: いろんな分野のいろんな専門化の人が来て、こんなところが気になっているんだけど、みたいな話をしてくれる。特にusabilityについて。いろんな人が来ることがRubyの開発をドライブしている面がある
- n: PerlとビジネスということでSaaSサービスのサポート状況とかどうですか
- t: SaaS的なところで言うとherokuとdotcloudくらいしか使えない。積極的にサポートしてくれる/サポートしてくれという動きがないのはよくないかなあ
- n: travisでperlが検証できるようになったのはコミュニティーが主導していったのかな
- n: エコシステムとしてPerlはCPANからという流れがありますが、Rubyはrubygemsにコミュニティーがあるというよりも、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: コミッタのコミュニティーについてどうか
- 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を良くすることではなくみなさんを、プログラミングをハッピーにすること。RubyがPerlがというよりもっと大事なことがあるんじゃないかな、と。
- h: ぼくらはユーザーに価値をどれだけ速くとどけられるか、そこに適したRubyをいま使っている。Perlのコミュニティーを見ると他の言語やコミュニティーをすごくよく見ていて、Perlに取り込んだりしている。miyagawaさんはあっという間にRubyとRubyコミュニティーの文化を吸収して、またPerlに輸出している。そういうことができる人がいることが大事かなーと思う
- t: ぼくが言っていることは10年前と同じで変わっていない。Perl6も出ないしもうダメーと言っている。その状況も変わらず。変わらないながら進んでいくんだろうなーと思っている。言語ってのは仕事の一部でしかない。要素技術のひとつを取りかえたくらいで自分のスキルが役立たなくならないようにするのがエンジニアとして大事だろうと思います
- n: Perlリスクに対してPerlでもこんなことできるよと反論していくのも手であるとは思うけど、他の言語の世界を見て学ぶ機会を得ていくほうが大事。みんなで未来を見ていきましょうと思います。
本当にあったレガシーな話
- @lestrrat
コードベース
ログを取ってください
- 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ハンドラはクラスベース(オブジェクトを作らない)
- 初期化コードが大変になる
- フラグ・スイッチを親クラスに集約
Phase2: 配信システム → PSGI
- ApacheハンドラをPSGIに
- 直す → 走らせる → 直す → 走らせる →
- RubyのKageをAnyEventで
-
- metacpan.rog/release/Geest (ヘイスト)
- 出力の差分を見る
-
- やっとPerlのバージョンを上げられる
- せっかくならcpanfile + carton
- セットアップ
- 数台だけ入れかえたら、パフォーマンスが30%落ちる
- Devel::NYTProfを使う
- → mountを多用していた。数が多すぎると遅くなる
- → パッチ書いた
- query_parameters()がやたら重い
- uri()をキャッシュするようにしたら10〜15%速くなった → マージ済
- 再デプロイ
- 全て落ち着く… svc -hするまでは
- → 突然load averageが上がる
- Server::Starterで管理していても-hでやると一気に上がってリソース食う
- → 既知の問題: 前の世代を殺すタイミングと次の世代が立ち上がるタイミングが同じになってしまう → kazuhoブログ
tips
- plackup多すぎ問題
- $0に代入してpsで見える名前を変更。リクエスト情報やハンドラ・日時を入れるのも便利
スマフォアプリ開発を支える認証認可アーキテクチャ
- 今日のメイン: 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
シングルサインオンの実現方法
- 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でゲストとリポジトリを共有する
- Virtualboxのshared folderは遅い
- perl-buildで5.8.8を入れる (tokuhirom/perl-build)
- CPANモジュールはcookbookに記述
- ChefのLWRPを使う
- carton化も進めている
- ./bin/server
- git.io/PBG-og にて公開予定
課題
- 二重管理なのはそのまま → 問題をすりかえただけ
- 本番環境のchefと共有したい
- メンテしているのは自分だけ
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
- Parser
- Complier
- 設計方針
- Learn from the good
- POTION
- 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タイプに少しのビット、残りをオペランドに回す余裕がある
- common number interfaces
- parser
- peg, enhanced to greg
- 最大3ノードのASTを作成
- compiler
- ifはただのブロックつきのリストのメッセージ
- control structureはマクロのように処理できる
- VM
- everything is an object, every object is a function
- MOP
- 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
- まだ決めてない
キーノート: management and Perl culture
- 池辺さん LINE Corp
- Career
- on the Edge → EDGE → livedoor → NHN Japan → LINE
- 実は転職していない
- Products
- LINE ○○
- livedoor ポータル
- livedoor Blog
- naverまとめ
- livedoor Blog
- 10周年
- mod_perl 1で動いてるサイトの中でさばいてるPVは1位だったと思うけど、一気に返済していただいた
- お仕様: software development
- ソフトウエアの開発ってPCに向かってカタカタやってウフフって感じなんでしょ、なんて個人技っぽく思われてる
- いいソフトウエアってのはすごい少ない人数のちょっとオカシイくらいのすごい人が作ったモノが流行ると思っていたが違う
- ソフトウエアは人間が作る。いまだに人間が作っている。人間が集まって作っている
- → Team
- management
- management != 管理
- 上から目線で管理すればいいというものではない
- 心がけていることを紹介します
- as is ではなく to be ですよ
- work environment
- 働く環境ってみなさんまあまあウルサイというか非常に大事でしょう
- PCは速くなくちゃとか、椅子がつらいとか、朝起きれないとか、ワークライフバランスとか
- 環境をちゃんと備えるために、人事とか総務に通していく仕事がある
- human resources
- 人事
- 自分よりデキル人を雇えないとダメだとか言われる
- 優秀すぎてどうしよう、取ってかわられるんじゃないかと思ってコワイ
- ちゃんとやらないとチームとしてのcapがマネージャーのそれになってしまう
- SKE48の写真、16人みんな色が違う。みんな違うのがいいことで均質化する必要はない。みんな好きキライがあってもいい
- ビジネスよりに興味があって売上あがるのがいい、細かいチューニングで貢献、いやいや技術的負債は許せない、など、みんなが自分の特性を発揮してくれればいい
- ユーザーが近いのが得意な人と苦手な人は割とハッキリ分かれているかも。ユーザーからの辛辣な指摘に耐性のある人に大規模な改修してもらうといいかな、とか
- 将来どうすんの?
- management or engineer
- 35歳定年説
- 人事制度もちゃんと考えないといけない
- ダメだと思うのは「デキルエンジニアをおまえマネージャーな」とやること
- 向いている人、向いていない人いると思うし、マネージャーできないとダメだよというのはおかしい。エンジニアはエンジニアのまま給料ももらえるような人事制度にするようハックしていくべき
- マネージメントとリーダーシップはまた違う。数人でゴールさせるリーダーシップを持っているエンジニアは結構いると思う
- 「マネージャーならないといけないんですよね、そろそろ」という価値観でやらない方がいいと思う
- direction: 方向づけ
- 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に乗ろうという気持ちがすごく大事
- 入ったときには弾さんがもうそうしてた
LT2日目
すいませんログ取ってません
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
Patches
- ほとんどのパッチは4人からsubmitされてくる
- みんなもっと貢献できる
Hopes and Dreams: Perl 5.20
今時のカジュアルなデータベース関連開発
- @songmu
- カヤック技術部ソシャゲ部
- Riji
Teng vs DBIx::Class
例外処理 - 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設計
- テーブル定義
- ActiveRecordっぽく id定義 (アンチパターンだけど)
- テーブル名の単複変換はキモチワルイ
- インデックスは必要最低限: 複合インデックスあるのに単独も作っちゃうミス
- 外部キー張らない
- バッドノウハウ
- リレーション先のレコードロックが発生したり、不要なインデックスが自動で作られて重複になったり
- 外部キー側のデータも作らないとテスト作れない。そのかわりちゃんと作ってちゃんと確認すると得
- 接続時処理
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
ありがちな開発開始手順
ひな形作成のポイント
ひな形作成の失敗・反省ポイント
- ひな形作成スクリプトをコピペするようになってしまった → ふり出しに戻った
- 標準で使いたい機能も差しかえ可能にしたい
- ひな形作り直した!
新しいひな形の要件
- シンプルに
- 同じモノを使ってるならコピペ不要に
- YAPCに向けた誓い
ksgk Knack of the System Generation for Kurouto
よかったこと
- このひな形のこのディレクトリだけ見ればわかるようになった
- 思想と形てはchef, puppetと同じで、最小限のコードレシピを蓄積 → 適用可能性が上がる
SPDY、HTTP/2.0の使い方
- @takesako
firesheep
SPDY, HTTP/2.0
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からのインポートが多い
最近のp5
Rakudo Starは実用に耐えるか?
- say [+] 1..100 → 0.945秒
- The nqp language
- nqp: Perl6のサブセット。Perl6を実装するために作られた言語
- Rakudoはnqpで書かれている。mostly
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
- Regexp::Rules (tokuhirom)
- Reduction operators [+] 1..100
- Hyper Operators: >>*<< zipっぽく
- Cross Operators: X 直積っぽく
Perl6 related hacks
Seis demo
- for 1..12 { .say }
- [+] 1..100
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で依存ライブラリの断続的バージョン上げ
@yappo: I NEEEEEED HTTP::Body::Builder
@hirose31 inspect-perl-proc
@comewalk しげたさん Contributing to open source products
@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__:
- Xslate
- Mouse
- Power Assert → Test::Assert
- JS界隈で話題になっていた
- perl.js
- emscripten
- LLVM to JavaScript compiler: kernel & CPUみたいなもの
- これを使ってPerlをJSにコンパイルした → 動いてしまう
@mizuki_r P5-SPICA
OpenID Technight #10レポート
9月4日に行われたOpenID Technight #10に行ってきました。
IIJさんの会議室を借りて行われました。
「JOSE + JWT 翻訳」
JWT in Production
会場に質問
- JWT知ってる人 … 3割くらい
- OpenID Connect IdP/RP 実装した人 … 十数人
- してみたい人 … 2割くらい
- cf. ID & IT 2013 東京9/20
- SAMLのIdP/SP実装したことある人 … 数人
- CSV万能?
SAML, The Enterprise
JWT, JWS, JWE
-
- 何に使うの? → Use Cases
- トランスポートレイヤーではなくオブジェクトベースのセキュリティメカニズム
- 何に使うの? → Use Cases
JOSE Use Cases
JWTのフォーマット
セキュアに使うには? → JWS
その他のJOSE/JWT関連仕様
「CIS 四方山話」
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
- Obs. #8: パーソナルとビジネスのクラウドがいっしょくたになってきている
- consumerization is real. solutions are born in the void between convenience & control
- 便利と管理のはざまからソリューションが生まれる
- Obs. #9: Idは電話の回わりに集中してくる
- Identityは、ISO 7階層モデル/TCP4階層モデルの第3層(transport層)と第4層(application層)の間にあると考えられる
- Id must be embedded
- IAM: SaaSでFederation、次はIDaaS: IAMはenterpriseからIDaaSに移る
- Liberty Alliance Projectの始まりのころ、Netscapeは.comなどのベースを作りたかった
- Network Identity → Outsource Identity Infrastructure → Outsource Identity
- つまり Federation → IDaaS → Trusted ID providers
- CISのIdentity Manifestoではだいたい流行っているものが殺される
- @shingoym: B2CのC, B2B2EのE, G2CのCって、結局同じ人じゃん。相手によって決まる。どういうこと?
- → ペルソナを切り換えて使うようなことを言っている
- 企業の中ってプライバシーが難しい。従業員IDというと、その属性の持ち主は企業。クラウドを使い出すと、属性が外へ出ていく。いままで雇用契約で閉じていたところが、漏れていく
- → ID & ITでもセッションを用意
- @_nat: プライバシーは所有権ではなく使用権として考えたほうがいい
セッション全体の傾向
- API化の流れ
- as a service
- IDaaS: 必然
- 単純にID管理をクラウドに持っていくだけではない
- Trust framework, Attribute exchange
- AXの例: FCCX
- NSTIC: National Strategy for Trusted Identities in Cyberspace
- slideshare.net/CloudIDSummit
OpenID Connectはあなたの課題をどう解いてくれるか
雑談
Q&A
- 本人認証、シェアアカウントじゃないか、副アカじゃないかという検証は、現状スマホにワンタイムパスワードを送るしかない。このようなやり方はどう考えられているか。他の方法はあるか
- 知ってる認証、持ってる認証、生体認証。生体はお金かかるし難しいと思うが、いまはできるようになっているのか?
感想
私もJWSの翻訳チームに参加しました。多人数で手分けして翻訳したのは初めてで、訳語の統一などレビューが大事だなあと感じました。
パネルは本当に面白かったです。発表に使われたスライドは冒頭で紹介したDoorkeeperのイベントページにリンクされるとのことです。
近くのレストランで懇親会も行われ、こちらでもおおいにもり上がりました。
idcon 16レポート
5月24日に行われた #idcon #16に行ってきました。ヒカリエ21Fの:DeNAセミナールームです。
今回はconsumer secretの秘匿、IIW報告などディープな話が聞けそうです。
(19:10)
OIDFJからごあいさつ
- インド、ブッダガヤにいる山中さんから動画が届いています
- 江川さんからイベント告知
「公式Twitterアプリに望まれる認証鍵の難読化とリバースエンジニアリング対策(仮)」
- @BlackWingCat (黒翼猫)
- スライド
- [補助資料] 超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 - GIGAZINE
- フリーソフト作家: ベクターなどで公開
- Application Blocker
- User32.dllをロードするときに、ポリシーを参照して、特定プログラムをブロック
- Windows 2000拡張カーネル
- レガシーカーネルを使いたい。.Netアプリや最新ブラウザ、メディアプレイヤーなどが動作可能
- Application Blocker
- もふったー
- 本題: GIGAZINE記事のネタ: consumer secret keyの難読化について
- もふったーの難読化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: 抜かれて困るのは、自分のクライアントの名をかたって悪意のあるクライアントを作られるリスクだけか? エンドユーザーもサーバーも困らない。アプリ作者だけが困る
- 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」
- セッション「Reputation Consulting .05Cents」
- Dinnerで
- 「Anonymousの逆って何だと思う?」 → 議論がもり上がり、セッションやろうかな
- セッションやれるよ → やってみよう
- セッションの立て方
- 誰でもOK!
- 1セッション50分
- 自分でテーマを決め、色紙に書き、早い者勝ちでセッションボードに貼っていく
- 大きい紙にトピックを書く、ふせんが部屋になっている
- 本当に早い者順
- 会場にてログ係(note taker)を指定する
- セッション「What is Real Name」
- やってみて
- 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で公開される
- http://iiw.idcommons.net/IIW_16_Notes
- 赤いリンクはノーツがないよ
- セッション「Mobile SSO」
- セッション「Mobile SSO」
- 「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
- Smarter Hardware
- 「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は発行しない
- Justin Richer, MITRE
- 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: 財務、戦略
- WGが仕様を作る
- OIDFメンバーの得
- 戦略に影響を与えられる
- 思想的なリーダーに接触して話を聞くことができる
OpenID Foundation
- Don Thibeau
- Identity Data Leverage
- 金融市場のレバレッジと比べてみよう
- データレバレッジ
- ツールとルール
- 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を決め、相互運用性を保証する
- OpenID Foundationと日本ブランチ
- 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
- nat, John Bradley
- OpenID Connect: OAuth2.0の上に乗せるidentity層
- identity = ある実体に対する属性の集合
- entity - attribute modelを理解
- 相手によってどの属性を見せるかを制御することによってidentityを見せている
- 男性は数個、女性はもっとたくさんのidを使い分けているw
- OAuthじゃダメなの?
- OAuthはアクセス許可プロトコルなのでidentityの概念は含まれていない
- aliceがcindyにbettyの情報アクセスを許可してもcindyはaliceではない
- OAuthはアクセス許可プロトコルなのでidentityの概念は含まれていない
- Signed Request vs Id Token
- 誰がいつ何の目的で認証を受けたのか
- OpenID Connect
- Interop中。始めるならいま
- OpenID Connect: 共同作業の産物
- MS, G, f, ebay, Y!, T, ...
- 週2回電話会議、大量のMLメッセージ
- OpenID 2.0との違い
- 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は完了
- 仕様のopen issues → すべて解決した
- webfingerを使うことを決定した
- related specs
- OAuth dynamic-registration
- User managed access
- risk
- IETF仕様への依存が少し残っている
Acconut Chooser
よ
- Federated Identity
- 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に教える。通常は何も発生しないけどね
- とってもカンタン
- 1. https://www.accountchooser.com/ac.js をインクルードしたらOK。これだけ
- account chooserのセキュリティー
- ACの画面に行くと通常のWebサイトに見えるが、これはfakeである。リストされているアカウントの情報はHTML5のローカルストレージに記録されている。これらの情報はaccountchooser.comに送信されるわけではない
- Account Chooserは
- ID連携の最初のステップ
- ブラウザのHTML5 storageを使用。すべての情報はユーザーのPC内
- ワンクリックでログイン、ワンクリックで登録
Backplane Protocol
- Backplane
- trusted application間で情報共有するためのprotocol
- アプリウィジェットが複数のIdPからの情報を共有
- トラストモデルdriven
- Social Identity Can Make Apps Sticky
- 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
- app developers
- backplane v2 demo in janrain
- oppotunity
- simplify integration to share information btwn sites
- backplanex.com/japanに資料貼っとくからー
OpenID活用事例と最新動向
- 越川さん (楽天)
- Open Services Platform Section
- あんしん支払い、OpenID / OAuthなど
- Open Services Platform Section
- 楽天について
- 1997年創業、年商1兆円
- 楽天スーパーポイント → 会員データベース
- 渡辺さん
時間があまったのでQ&A
- DNSポイゾニングをしてac.jsを置きかえる攻撃に対してどうな対策をしているか
- BackplaneとOpenSocialの違いは?
- good question!
- trust frameworkでやる
その他
- 会場では各種のデモなどもありました。その中でTuliooのデモはなかなか面白かったです
- https://www.trulioo.com/
- facebookアカウントを実在する人間かフェイクのスパム用アカウントか判定してくれます
- 「このアカウントの現在のありようをフェイクするなら1000時間かかる」などと結果が出ます
- ホテルレビューサイトでヤラセ評価を検出するために活用しているとのことです
- クローリングした日記や写真などの活動を元に評価しているそうです。アジアの言語はどうやっているのかと聞いたのですが、難しいようですね
- この後の懇親会にも参加させていただきました