CROSS 2013レポート(3)
CROSS 2013レポートパート3です。malaさんのセッション
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
安全な利用規約の作り方
- http://www.cross-party.com/programs/?p=131
- @bulkneets(mala) NHN ライブドア方面
なぜ利用規約
- エンジニア方面の話をします
- 炎上したり、海外だといきなり訴訟
- 利用規約やプライバシーポリシーの無理やりな解釈
- 個人がさわぐ → メディアとりあげる → 取材に応じる前に広まる
- そんなつもりじゃないのに炎上する
- 作る側、使う側の視点から
- 無理やりなイチャモンでサービスの印象を落とすのは本意ではない
- 本当にヤバイものがわからなくなってしまう
- 利用規約が「評判リスク」であると扱われてしまう
- エンジニアができそうなこといろいろあるんじゃないの
- 「利用規約はgithubに置け」
- やってるのはtumblrくらい
- 変更履歴 〜 ユーザーに不利な変更などもわかる
- 普通の企業の法務はぜったいにやらない → エンジニア発想
前提知識
- 個人情報保護法
- 種類・利用目的
- 特定電子メール法: オプトイン
- プロバイダ責任制限法
- 不正アクセス禁止法
- あずかったパスワードを別目的で使ってはいけない
- 不正指令電磁的記録に関する罪
- 「意図に反する動作」+「故意」=ユーザーをだましてやるという意志が必要
- 例: HDDフォーマットツール
- だまして実行させることを意図して配布すると有罪
- バグ → 意図がないので罰されない
- じゃあ、利用規約のバグは?
- ソフトウエアの挙動と利用規約の説明がくい違う場合がある
- ユーザーが「そんな動作をするとは思わなかった」「だまされた」と主張するかも
- バグは処罰されないはずだが、「本当にバグなのか」
- 絶対にユーザーの意図に反することがない ← 幻想
- どうすればいいのか
- 解釈のぶれの範囲がプログラムの挙動と一致するように
- 心理学などが必要。人間は仕様書どおりに動いてくれない
- アプリの実行環境
- permissionモデルの欠陥
- アドレス帳使います、ネット使います → 送信するかどうかわからない
- Adobe Air → ネットとローカルは排他だった
- → いまは現実的ではない。ネットのないアプリなんか考えられない
- スマホアプリ → webアプリのfront endにすぎない
- サーバーのコードとローカルのアプリの組ではじめて仕事になる
- コードを見せたくない人 → 解析されずに動作が制限される仕組みが必要
- 逆にコードを見せてもかまわない人は見せればいい
- 法律面の変化
- 不正指令電磁的記録
- 今まさにソフトウエアの信頼を技術的に担保しようとしている時期に出た
- ユーザー側に害を与えるのは多くはサーバー側
- 不正指令電磁的記録
- 残念な運用
- どうしてこうなった
- ガチのマルウエア作者はつかまらない
- 完全匿名
- backorifice → 正当な目的もあるので堂々と配布されてる
- プログラムの信頼 != サービス全体の信用
- 実際のサービスの信頼が必要
- 社員が信頼できるのか
- 法だけが規制ではない
- 法律による規制はどうせ無法者には役に立たない
- アーキテクチャによる規制・技術的に悪用できない仕組みが必要
- 市場原理 → 悪用することによる利益よりも、バレたときの不利益を大きくする
- 取得できる情報は様々、確認ダイアログがあったりなかったり
- ブラウザ履歴、アプリ一覧、プラグイン一覧など
- フォント一覧は描画してみればわかる → どんな年賀状ソフトが入ってるかわかる
- iOS
- canOpenURLでカスタムスキーム登録状況がわかっちゃう
- 自分の電話番号は公式には取れない → アドレス帳から推測
- Android
- アプリ一覧は誰でも取れる(package一覧)
- 保護されるべき情報とそうでない情報
- 境界は曖昧
- 実行環境によって多種多様
- CSSのvisited linkの取得問題
- 訪問済みリンクの色でわかっちゃう
- プライバシー侵害の問題が正当な利用より大きく評価された
- 取れちゃマズイ情報 → ユーザー許可
- 現状、許可なく取れる情報は使っていいの? → 判断が難しい状況
- 画面の解像度とか
- アドバイス
- 情報の質、ユーザーリスク、悪用・漏洩した場合の被害規模を考える
事例
- スクエニの会員制サービス
- 本サービスへの不満を流布する行為を禁止
- 他サービスでも「その他当社が不適切と判断する行為」があるから、スクエニの方が正直
- 元々、解釈次第でなんとでもできる → エンジニア視点ではバグのようなもの → 運用でうまく
- googleの通話履歴利用問題
- Instagramの例
- 写真を売るはずはないのだが
- ビジネスモデルに無理解だと、無料サービスだから個人情報売ってると誤解される
- 典型的な間違い
- 売ってしまったら継続的に利益が出ないので、そんなサービス作るはずはない
- 使う権利を売っている
- ビジネスモデルの知識欠如、無理解から、「悪いことしてるんじゃないか」という憶測が生まれる → 根拠のないまま流布される
ケーススタディ 〜 よい事例
- Mozilla
- 潜在的個人情報: 単体では個人を特定できないが他の情報と組み合わせると特定できるもの
- 収集している情報は後天的に個人を特定できる情報となり得る
- 「個人情報ではありません」という間違った表示をして回避しようとしてしまう
- Siri: リンクしないポリシー
- URLにはsensitiveな情報が含まれることが多い
- 個人情報かどうかってはっきり決まるものではない
- 個人情報です → 取扱いに制約
- 個人情報ではありません → うそになってしまう
- アドバイス
- 楽天の生メールアドレスをショップに渡すかどうか問題
- 委託 → 楽天に監督義務
- 提供 → 義務はない
- 「業務に必要な範囲」かどうかすぐにはわからない
- そもそもメアドって個人情報?
- 総務省: 組織名、個人名が入ってない記号は違う → えええぇ?
- アドバイス
- ユーザーがコントロールを失うタイミングで警告するのがよい
- 誤解を招きそうなときは別途補足すべき
- 暗号化・ハッシュ化
- 通信経路だけなのか、保存状態なのか。社員でも復号でなくなっているのか
- Dropboxの例
- 技術的に不可能なのか、就業規約としてダメなのかがわからない
- 著作権管理
- リンク
- 電話番号自体はひみつじゃない。「誰が持っているか」が秘密の情報
- メアドも
- 公開/非公開の中間状態があるだろう
- googleの予備のメールアドレス
- 予備のメールアドレスでプロフィール検索できる
- パスワード再発行専用で非公開のものと区別される
- FBのソーシャルグラフ
- ユーザーが許可しても、アプリ外にexportは禁止
- livedoor.comの画像
- クッキーからセッション見ると、Web行動履歴を取ることはできる
- だけど静的情報なのにわざわざセッションデータベース見たりしないよ
- google+
- +1ボタンのポリシー: 統計には使えると表示
- やらないことを明示しているにもかかわらず炎上
まとめ
- サービス提供側とユーザー側の認識のギャップが無視できない
- 経営者、法務、技術者の利解も違っている
- リスクマネジメント → 悪循環
- 透明性確保
徳丸さんとの対談
ここでPCが電池切れとなったので、自分のツイートから発掘
CROSS 2013レポート(2)
CROSS 2013レポートパート2です。次世代Webセッションのメモ。
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
次世代Webセッション前半〜プロトコル編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28598269
- 司会 Jackさん(@Jxck_) 以下J
- 大津さん(@jovi0608) SPDY関連 以下jovi
- 小松さん(@komasshu) Websockets 以下koma
- 清水さん(@kazubu) HTTP/2.0 以下kazubu
HTTP2
- 2012/11最初のドラフト。絶賛議論中
- どんなところが問題?
- kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか
- jovi: SPDYはSSLの上でやってるから気にしてくていいという話だった。crimeの衝撃。chromeは3ではdisableにした(クライアント側からの圧縮率を下げる)
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- crimeはhuffman木の再構成によって発生する。huffman木を変える方法が考えられている
- googleは前回と同じ物が来たときにだけフラグをつける。クッキーだけわかればいいという発想
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- HTTP2が出てきたときにどうupgradeするか
SPDY
- jovi: LINEの特徴
- koma: スマートフォンにはプライベートアドレスが払い出されてる
- マルチプレクシング
- SPDYでできちゃうのでWebsocktsでやらなくてもいいんじゃね的な
- per frame compression
- レスポンスを上げる → テキスト→バイナリ → 圧縮 → などとなっている
- J: SPDY: bandwidthよりRTTが重要という流れだと思うんですけど
- J:デバッグ大変ですよね!? → jovi:大変です!!
- HTTPのときはheaderのparseができればという話だったけど、SPDYのparserは個人でできる範囲をこえてしまった
- J: prioritizationというのがある。HTMLの世界でやっていたドキュメント読み込み順をSPDYに持ってきたときにどうなるかを考える必要がある
- 「ハイパフォーマンスWebサイト」は書き直さなきゃね!
- SPDY4ってどんなカンジなの?
- koma: layer violationがはげしくなってきて、階層どおりになっていない
SPDYとHTTP2とTLS
Websockets
- J: WebsocketsはHTTP→HTTP2に横からささってきた感じですが、これからはどうですか?
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- WSがこのまま世の中に普及するかというのは難しい。明日世の中のIEが全部10になるとかであれば使われるんでしょうが。IE678がいつなくなるかという話で、じゃあやっぱりsocket.ioでHTTPポーリング、ってなるでしょ。ああ、socket.ioは使われますよきっと
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- J: ブラウザ以外のWSのカベは?
- J: WSが切られちゃう件ってどうなんでしょ
- まあ、わけわかんない接続が残ってるの切るのは正しい対応なんでしょうけども
- 2本つないでみて試し、wsが使えるならupgradeしようみたいなのが出ているんですが、そのへんが難しい
- kazubu: IETFでも話題になっている。LBが作りにくい。SPDYでもpriorityをさばくのはLBなのにコンテンツはWebサーバーにあるというギャップがある
- J: WSもSPDYも接続を保持しないといけないからバランスしにくいのでは?
- koma: いままででもクッキーでセッションを考える必要はあった。data by data, frame by frameでLBしようとするとキツイという面はある
- jovi: chromeのgoogle map見ると、ひとつのTCPセッションに複数のホストが入っている。ワイルドカード証明書使ってDNSが同じアドレスになっているから、同じTCPセッションに入る。これは外から見てたらぜったいにわからない
- koma: シングルTCPに入れるのがいいかっていうと、回線品質が悪いときに急に悪くなったりというのがある。パラレルも使っていく工夫が重要
- kazubu: TCPいっぱい使うと間のNATがきびしくなるんじゃない?
- koma: HTTP時代の発想で20本も30本も張ると大変。でも1本にする必要はないんじゃない
- jovi: SSLのslow startから最高速が出てきたところでなんで切らなきゃいけないのって話。googleはこのへんもすごくやってる。half-close使ったりwindowサイズを3→10にしたり、SSL false startしたり
- こういうのがlinuxにも入っていて、みんな知らずに使っている
- J: イニシャルを速くするのと、つないだ後を速くするって話があって、つながっちゃえばやりようはあるんだろうけど、initialはなかなか難しいということか。3-way handshakeはどうしても必要だし
v6
- J: v6はどうなの?
- kazubu: 流行るといいですねーwww
- FBもgoogleも対応しているけど、v6で生活するというのは難しいよね
- kazubu: 流行るといいですねーwww
Webのこれから、どこに向かっていくのか
- kazubu: 効率化が進むけど、問題も引き起こすのでバランスが重要
- komasshu: ホームネットワークのTV・家電とクラウドの関わりが気になる。クラウドはSPDY,WSなどが進んでいくと思うが、ホームネットはHTTP以外のプロトコルでもガンガン動いている。シームレスにdevice - browser - serviceというトータルで考えないといけないと思う
- jovi: 過去から来ていたのはリアルタイム性、RTT。マルチプレクスがもうできた。本当の本当のリアルタイムはこれから先は劇的に伸びるものはもうない。これから先、どんな新しいパラダイムが出てくるかを見ていかないといけない。光はまだまだ遅いw
- Jxck_: みんなこういう話をするとすぐHTTPをdisったりする。HTTPにdisを持っていれば、いままさしくそれを検討する段階なので、どんどん出していくべき。もっとIETFに持っていくなどしていく必要がある。日本人の貢献がもっとできるはず
次世代Webセッション後半〜アーキテクチャ編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28599028
- 司会 Jackさん(@Jxck_) 以下J
- 和田卓人さん(@t_wada) 以下wada
- 山本陽平(@yohei) 以下yohei
- 佐々木庸平(@yssk22) 以下yssk
- 江島健太郎(@kenn) 以下kenn
Websockets
- J: LingrはWSにはならないのか
- kenn: ぶっちゃけよくわからない。互換性が失われる分があるので、サービスとしては採用にふみ切れない。ancientなCOMETを使っている。メリットは永続的なconnection。チャットはアイドリングの時間が長くてTCP接続のコストは高くない。生きたconnectionを使いまくるようなアプリでWSが生きてくるのだろう
- J: 結局COMETでよかったんじゃね?という話
- yssk: メリットが見えない。インフラ屋としてはconnection使い回すというのと、違うアプリが同じLBに入っている場合にどうやってLBのキャパを確保するのかが難しい。アプリがセッションを持ったまま永続してしまうと、バックエンドでサーバー再起動できなくなって困る。バックエンドが同じサーバーで動いていることを前提とされるとつらい
- J: HTTPはステートレスであることが良さだが、それが失われるとどうなります?
- J: statelessだったHTTPの上で信じるに値するRESTだったと思うが、そうもいかなくなってきた今、何をよりどころにすればいいでしょう
- wada: これまでのWeb、実はこうなっていたという説明がようやくストンと落ちたところだと思う。Webがドキュメントをやり取りする世界から、ストックのwebとフローのwebに分断された。twitterは過去が見られなくなったとか
- J: 自由なwebが失われた、みたいなブログがあったけどどう思いました?
- yohei: そのとおりだと思った。テクノラティーあったねーどこ行ったとか。ストックとフローの問題だと、世の中はフローに行ってるから、ゆり戻しがそのうち来るんじゃないかと思っている。タイムラインで流れていく情報をストックで扱う技術とか出てくるんじゃないか
- J: 文書をどう取ってくるかという点をよりどころに技術が進んできたと思う。バイナリになったり、始まりはあるが終わりのないストリームになったりということじゃないかと思うのだが
- yohei: 「インターネットになったな」と思う。ちょっと前はwebをインターネットと呼ぶな、とえらい人が言ってたりしていた。いまやweb==インターネットで、いかにその上でインターネットやるかというのでストリームになっていったんだろう。TCPの上にHTTP乗せてその上でTCPやるのがWSだったりする
- yssk: ゲームのようなHTTPベースじゃなかったものがHTTPでできるんじゃね、というのが今の流れ。WSはTCPの再実装じゃね、とは思っていて、少し懐疑的に見ている
- J: TCPに回帰していくと?
- yssk: そうではない。プロキシないと仕事にならない。HTTPの上にSOAPって言ってたけど、あれ?ということがあったよね
- yohei: HTTPをtransfer protocolとして考えないでsemantics考えろってのがRESTだと思う。結局みんなRPCやりたいんですよね
- kenn: textかバイナリかというのがハテ、と思うところで、テキストの扱いやすさがいい。圧縮してバイナリというのはどうかあと思う
Realtime
- J: 人がボトルネックになるというとそんなにリアルタイム求められてるのかな、と思う
- J: おととしくらいにWSのはしりが話題になってきて、キラーアプリが出るかと思ったけど、結局出てきたのってゲームとチャットだけだった。メッセージングが必要なキラーアプリ感がない。アプリとなると必要とされてないのか
- kenn: いいカンジに次世代webをdisる回になってきましたねw。エンジニアはすぐに効果が得られないものは採用しないと思う。にわとりとたまごではぜったいにたまご(新技術)が先。そこは悲観的には考えていない。時間の問題で出てくると思う。
- J: WSという仕様自体が求められて実装が進んでいて、それを使って何をするかは置いてけぼりになっている
- kenn: low latencyでリアルタイムというのは長く言われている割にようやく今だ!となってきた。時間がかかりますね。
歴史はくり返す
- J: 長い間見ているとよせては返すみたいな話がよくあると思うけど、それをふまえて、今よせているものはどこへ返っていくのか興味がある
- yohei: 今まで死んだスペックってすごくたくさんある。xsltとかw。仕様作っている人達はスペック先行で行っちゃう、楽しいし。しかしそれでうまくいかない。HTTPとかHTML5はうまくいってる? バランス取りながら進められるのがいい。いまだとIETFに行って合議制になった瞬間に終わるんじゃないかみたいな。IETFで仕様が出るよりgoogleでSPDYが234といくようなのがいいんじゃないか
- wada: 技術の歴史が螺旋状になっているよって話をよくする。テキスト/バイナリとか。前の周期を見ると、シンプルなものが生き残ってるのがわかる。やんなきゃいけないルールが多いものが死ぬ。SOAPとか。大きなものは自重で死んでいく。分散・集中だけでなく、自分の言葉をしゃべれるものが使いたいのかどうか。RPCやりたいというのは自分の語彙で話したいということ。なんで動詞が4つしかないんですかってPATCHもあるけど。自分のサーバーなんだし。他人の語彙を話すとなると急にやりたくなくなる
- LISPはマクロで言語を作るための言語だった。その結果みんなオレオレLISPを作ってしまってLISPの人同士で話ができなくなった。
- J: SOAPからRESTに行ったのもできることも少なかったが、覚えるルールが少ない分、よかったってこと?
- wada: ルールが少なければ納得できる。リンクを張ると使えるというおそるべきシンプルさ
TLSは前提?
- J: webはTLSを前提にしていいのかという話がある。プロトコル視点からは都合がいいのだが、web的視点からはどう考えたらいい?
- yohei: ビジネスではTLS前提が大歓迎でそうなるべきと思うが、個人としては受け入れ難い。web=internetと言っているが、internetのあり方としてどっかの会社から証明書を買ってこないと使えないというのは許せない。ハッカーとして自由でオープンなinternetが残ってほしい。テキスト/バイナリはどっちでもいいかな
- kenn: HTTPは実のところバイナリプロトコル。性能とかレイテンシというとTLSは明らかに落ちる。光の速度は越えられないw。それがどこに効いてくるかというとRTT。ハンドシェイクで一往復増えるというのはdrawback。CPUも食うし。フロントエンドnginxの負荷ってスケールさせにくい。オレオレプロトコルならAESかなんかにしてバックエンドでほどくなどやりようがいろいろある。それをフロントのTLSに限定するのはどうなのか。あとSSLも完璧ではなくて、ゲームを作っているとクライアントが信用できない場合もある。ローカルのプロキシで点数を書き換えるチーターもいるので、SSLだからと言って役に立つわけではない。役に立たないものに払うコストとしては見合わない
- yssk: webというモノが何かを考える。SSLにしてレイテンシがありますとかね。CDNが効いていて、遠くてもstatelessなら誰かが取ったcacheが効く、ということをbreakしてまでRPC指向でやる必要があるかというのは疑問。RPCは使いようがあるとしても、web全体でどうかというと、それだけではない
break the web
- J: 検索できるのはドキュメントがテキストベースでURLが固定だからというのが前提になっている。いまあるcacheの仕組みが使えなくなるとどうなんだ。break the webと言われますが、そのwebってどうなんだと思いますか
- yohei: 合わないものはこわせばいいと思う。cacheに代わる技術を作ればいい
- J: こわすだけのメリットがbreakした後のwebにあるのか
- kenn: 例えばスマホはwebなのかどうか
- yohei: あれは、むしろネットですよね
- yssk: 従来のロボット型検索エンジンは、Y!の登録型がうまく回らないところから出てきた。今後pubsubが広まっていくと、webの検索に登録するためにpubする、そのためにリアルタイム使うってのはあるんじゃないかな
- J: 登録型に戻る! そこへ行きますか
- kenn: pushは一発。一方pullは空振りがある。pubsubモデルになるとムダがなくなるよね
- yssk: cloud foundryが使いにくい、herokuが使いやすいのはgithubにpushするという操作があるから
- J: 出していただかないとgoogleに入らないよ、publishしてね、なんかの流れになるんですかね。facebookみたいにデータを囲い込んでる人達が検索するような、そんな世界ですか?
RESTに代わるパラダイム
- J: リアルタイムなwebを作りたい、でも従来型のrailsのwebを共存させようとしたとき、クライアント側にはajaxなど変わる必要があった。サーバー側APIはあまり変わっていなかったと思うが、今後WSでpushします、URLベースでないAPIが出てくると、RESTだけわかっていれば困らなかった時代は終わったんではないでしょうか。何をよりどころに生きていったらいいでしょう?
- wada: 道自体は自然発生的にできると思ってる。リアルタイムwebでは、アーキテクチャでは上に乗ってるのはnodeが引っぱっている。herokuはthinでeventmachineが動いているから、リアルタイムはできる。たくさん出てきているライブラリの中からどれがのびてくるか、思考のバッファにおさまるものが勝つのではないか。覚えることが少ない方が勝つ。プログラマの頭に入る量は決まっていて、そこにおさまり切るかどうかで生産性が決まってくる。nodeのasyncを使わないと非同期プログラミングできない。callback hellを見ると、あれはframeworkではあるけど環境ではない。あれを減らすためにasyncが出てきた。そんな風に、上に次が出てきて、大多数が暮らす主戦場ができると思う
- J: パラダイムシフトなのか、エコシステムがまだできていないということか。DOMで言うjQueryのようなものの登録が必要?
- wada: jQueryって言語内言語。一段抽象度の高い言語クエリー言語なんですよ。そこへ来てはじめてやりたいことの記述量が十分小さくなった。覚えられたのがjQueryの良さ。多くの人が「ああこれなら行けるわ」と思ったところがキーになるだろう
- J: 去年流行ったmeteor, socket streamみたいなものの流れだと思うがキラーなものはまだない。WSでやろうとしていることはネイティブアプリでやってたことが近くなる、XMPPでやってたのと同じじゃんみたいな話がある。swing、xmppのノウハウをいまこっちに持ってくることはできないのか?
- kenn: これから勉強する人は難しいことに押しつぶされそうな世界なので、オレオレでいいから作ってみることが大事じゃないかと思う。古い世代の人ほど新しいものが昔のモノに見えるので、逆に若い人ほど新しく作ったつもりが昔の物に似ている、と思えるんじゃないか。やりたいこととしてぜったいゆずれない部分を守るためにオレオレやればいいんじゃないかな
- yssk: 標準にのっかってWSやるなどは動機としてあると思う。うまく乗っかれればうまくいく。自分は乗れると思ってないんだけど。WSうまくいかなかったときに「ほーらね」って言えるw
- J: ysskさんのやりたいことがいまのweb技術で足りてるということ?
- yssk: APIとの接続として、zeromq, rabbitmqでやるかWSでやるかという選択だとは思う。やってみる価値はある。firewallをbreakできるチャンス?
Layer7のさらに上
- J: generalな世界でやるには課題も多いし、まだWSというには早いんじゃという時期だと思う、でも進んでるからやってみたい、この先どう進んでいくんですかね
- kenn: computerって放っとくとインフラは進んでいく。変わらないのは人間。一日に集中できる時間も決まっている。その中で開発をするなら楽をしたい。ソフトウエアの進化。下を改善するより上を良くするほうがいいと思う。TCPを作り直そうという人はあまりいない。UDPの上でreliableやったりはしないではないけど、HTTPってgood enoughだと思う。その上に何かを乗せ込んでいく。HTTPの上にfacebook、その上にアプリのようにどんどん上に行くし、それが人間の抽象度に合っていると思う。人間が瞬時に判断できる帯域は7bitという説があるんですよ
- J: 収束できるレイヤは4とか7ではなくその上にあるという話?
- wada: 人間のspecだけが変わらない。そこを直視する。何かのフレームワークが一瞬で頭に入るかどうか、と考えると、直観に頼るというのはいい指標ではないか。railsって結局、やることを減らしたからプレイヤーが増えた。何が流行るか流行らないかは、一瞬で制約に気づけるかにかかっている。足り算は流行らない。何かと何かを足すのではなく、何かができないかわりに何かができますという風になる。その「できないこと」を瞬時に理解できるか、判断できるかということだろう。その判断ができればみんながやりたいことに近づいていける
- wada: やりたいことがある、でもやりたい人の脳は変わらない。じゃあ何かができなくなる。同じかより高い抽象でプレイヤーがそろうところにアンテナを張っておくべき
- J: 抽象化の行き先って単純なRPCを定義できるかというところになるんですかね? 抽象化の先ってどこに向かうと思います?
- J: 今本当に何が起こっているかを出そろわせて、じゃあ次の一歩で自分が何ができるかってことを話すのは難しいと思う。自分で考えられるような人間を呼んできて聞く、というこの場はよかったと思う
- J: 自分で考えたこれからのwebについてブログに書くまでがこのセッションということで
感想
考える材料をたくさんもらったセッションでした。自分のものにするには時間がかかりそうです。
Jackさんの話の振り方は本当に上手でしたね。名司会だったと思います。
追加
セッション終了後、@yoheiさんからこんな提言がありました
CROSS 2013レポート(1)
1月18日に行われたCROSS 2013に行ってきました。
昨年、風のうわさには聞いていたものの参加できなかったので、今年はぜひと思っていました。
800人以上が集まったという会場はすごい熱気でした。プレモルも美味しかったし、すごく楽しかったです。来年もぜひ開催してほしいと思います。
さて、メモが長くなってしまったので、セッションごとに分割してみました。Ustreamから書き起こし、とかしていないので、間違いや「そんな意図で言ってない」などということがあると思います。ご指摘いただければ幸いです。
HTML5×セキュリティ(Shibuya.XSS)
- http://www.cross-party.com/programs/?p=143
- @takesako(以下T), @Hamachiya2(H), @bulkneets(M), @hasegawayousukeさん(欠席)
@takesako
- 「HTML5テクニカルレビュー」2012年3月、リックテレコム
- 15年前、1997年サイボウズ設立
- Webアプリ(インストール不要) → すごく流行った
- サポート対象のブラウザ → Firefox 1.0と
- Android端末: 機種数が多すぎて開発が難しい
- 画面の大きさ、プロポーションもマチマチ
- HTML5: 様々なAPI
- fullscreen APIのセキュリティー
- ブラウザを全画面表示できる
- 悪用するとフィッシングできる
- 全画面表示でブラウザの外観をまねる
- ブラウザを判別してそっくりに作る
- ブラウザの対策「全画面表示モードです。このサイトで許可しますか」と聞く
- デスクトップの色をピンクにすると、そこまでは真似られないw
@Hamachiya2
@bulkneets
- (先月報告したのにまだ直ってないXSSの紹介なので割愛)
サニタイズの話
アドレスバー偽装
イタズラ公開のタイミング
- T: はまちちゃん、最近イタズラ減ってきた?
- H: ノーガード戦法が広まってきている。一昔前のブログはみんな技術者ってカンジだった。いまはそんな流れではないからなー
- M: 自分も見つけたときによくガマンしてるなーと思う。投稿できるサイトにはあまりXSSない。大手のおカタいサイトでお問い合わせフォームからイタズラ送れても面白くない
- T: 「こんにちはこんにちは」はすごく気にいってて、昼の業務時間に出してくれる分には対応できるから助かる
- H: 実は対策まで時間がかかるように狙って金曜深夜とか、はてななら土曜出勤するはずだから日曜に出すとか、やってるんですよ
- M: 前にイベント中に直ったことありましたね
クロスドメイン
- T: robots.txt を見るとひみつのURL教えてもらえたりとかは今でもある
- H: その他には、.svn/entriesというのがたまに見えるよね
- M: cross_domain.xmlはドメイン単位なので、間違ってキャッシュすると取り消せないのが困る
- T: IE10はいいですよ。みなさんWindows8でIE10使いましょうみたいな
@takesako: IE10のJITセキュリティーについて
- Chrome以降、JITの高速化戦争勃発
- セキュリティー対策も進んでいる
- 脆弱性の例
- https://speakerdeck.com/takesako/javascripthaji-jie-yu-tonaru
- JSの整数論理演算 → 機械語に落として実行
- 問題点: 定数のたたみ込みが動かない
- ずれたアドレスに飛んでくるとNOP列になってしまう
- ASLR (Address Space Layout Randomization)
- Linux kernelなど
- JIT-Spray
- JIT結果を置く場所は実行許可されているので、そこにコードをしきつめると攻撃に有利
- 定数のたたみ込みをすればしきつめることはできない
- IE10のJITセキュリティー
- codebase alignment randomization → うめ草としてnopではなく割込命令を使う → バスエラー
- random nop insertion
- constant blinding (定数をmovするのでなく、xorも使ってわからないようにする)
- 結論: IE10/Windows8が世界最強のJITセキュリティ
Q&A
- スマートフォンのWebViewはこわくないのか?
- M: こわいですよ! iPhoneアプリで多い。アドレス帳のSQLファイルのpermissionがゆるゆる。WebView内のfile://スキームで動いていると読めた
- M: iOSはJSからできることが多すぎて困る。JSからOSの機能たたけるようにブリッジしてると、任意のJSが実行できるような穴があったときに被害が甚大になっちゃう
- T: 標準ブラウザの問題? アプリも?
- M: Androidだとアプリ一覧見れたりする。どこまで公知なのかもわからない
- M: 端末がいつまでもアップデートされないので困る
- M: PhoneGap使ったアプリもネイティブとブリッジできるので、JSに穴があるとマズイ
- M: 内部用のAPIは認証が甘かったり、みんなたたかれないと思ってるけど結構見えるもの
- H: CSRFもアブない
- T: ぼくはアプリごとに別々の端末持ってる。LINE専用端末とかw
- M: 携帯まるごとシークレットモード(友達に貸すモード)とかほしい
idcon14レポート
10月5日に行われたidcon #14に行ってきました。ヒカリエのDeNA会議室、きれいですね。DeNAステッカーとベイスターズのお水いただきました。
「JSON based Web Service」
- JSON Pointer
- JSON Patch
- JSON Schema
- ドラフト04
- バリデーション、ドキュメンテーション、ハイパーリンク
- validation & documentation
- 値に制約をつけたり型を定義したり
- title, descriptionでドキュメンテーション
- propertiesの中に属性のスキーマを入れる
- typeで型、またデフォルト値など。JSON Pathを使って別のSchemaを参照
- hyperlink
- Schemaに対するrelation, endpoint, method, media typeなど
- サンプル
- まとめ
「Multiple Personae, One "Persona"」
- ぺるそな?
- Mozilla Persona
- ログインのためのより良い方法 (better way)
- より良いとは?
- たくさんのパスワードを必要としない(ID連携)
- 複数のメアドを使い分けられる
- decentralized
- real privacy: 非営利、トラッキングを行わない
- BrowserIDのかんたんな解説(beta1)
- Identity assertion
- 検証方法
- RPはIdPからIdPのpublic-keyをもらってくるだけでOK
- IdPには誰が何をアクセスしようとしているか教える必要がない
- assertionの中にあるJWSの署名を検証できる
- 使い道: メールによるワンタイム認証フローを置きかえることができる
- RPはIdPからIdPのpublic-keyをもらってくるだけでOK
- 実装しているブラウザはない
- /.well-known/browserid → 全然みつからない
- navigator.id.* → 実装を見ない
- persona.org: fallback IdP
- persona.orgが代わりに署名してくれる
- fallback browser
- persona.orgが提供するJavaScriptで機能を提供
- 両方とも使ってしまうと結局persona.orgに頼るメールフローになってしまう
- OpenID Connect OPからid_tokenを取る方がシンプル
- 残念な感じ
- 少なくともブラウザ側実装はほしい
- ネイティブ実装
- Firefox向け → 今年Q3くらい?
- B2G (Firefox OS)にも実装予定。課金とか?
- スマホでアプリ間認証とかに使えるのでは
- 事前にIdPの証明書がわかっていればオフライン検証もできる
- まとめ
- ブラウザの鍵ペアと多段階の署名がキモ
- persora.orgにfallbackしちゃうので現状は残念
- 今後に期待?
- ところでメール連携はId連携と似ている
- メールプロバイダはIdPなのか?
- ユーザーのメールアドレス所持を保証
- パスワード再発行(refresh tokenに似てる?)
- Identifier Providerかな?
- 結論
- パスワードはサービスごとに変えましょう
- パスワードは減らしましょう
- ID連携がパスワードを減らします
- Q&A
- PersonaというサイトとRPの信頼関係は、RPが一方的にpersona.orgを信頼していて逆はないということ?
- bkihara: そのとおり。ドメインに正しくアクセスできるかどうかで担保する。
- IdPには誰が何をアクセスしようとしているか教える必要がない、などがメリット?
- bkihara: そうですね。IdPとしては公開鍵を提供しているだけ。ただし、ブラウザの鍵ペアに対する署名はあまり長時間やっていると盗まれる危険がある。仕様では24時間以内ということになっている。するとログインの度に署名が走るため、統計アタックなどがないかなーと調べている
- nov: 使っている人いる?
- PersonaというサイトとRPの信頼関係は、RPが一方的にpersona.orgを信頼していて逆はないということ?
- 感想: ブラウザで鍵ペアを生成してIdPから署名をもらうというと、PKIをJWTベースで簡単にした感じなんでしょうか。勉強したいと思います。
「日本史から学ぶID」
- (19:47)
- @masanork
- 興味を持ったきっかけ: 間に合わなかった規制改革
- 戸籍が庁舎の中でしか保管できない法律になっていた → クラウドに保存したい
- 改革はなんとかできたが、データ移行が間に合わないうちに震災が起きてしまった
- 戸籍は日本でタブー視されているようで、いつからあるんだろと思って調べはじめた
- 日本書紀を見ると、紀元前からそういうものがあったようだ
- 肉を納めさせる → 取りたてるために管理
- 渡来人も登録
- 税金逃れのために戸籍を登録しない者が発生: 女性として登録、死んだのに生きていることにしたり。今も昔も不正の手口はあまり変わってないw
- 律令制度
- 7世紀くらいになると、掘ると出てくるものがある
- 戸籍を整備して税金を取る。どれくらいの田畑をたがやしているかを調べ、計帳に記述
- 8〜9世紀に一度途断えてしまう
- 人は逃げてしまう。どうやったらいいか → 土地に税金をかけるようになった
- 人は逃げるが田んぼは逃げない。人の頭数を数える必要がなくなった → 戸籍もなくなった
- 朝鮮出兵と人掃令
- 次に頭数を数える必要があったのは徴兵
- そんなに定着はしなかった
- 1635年寺請制度 → 現在の戸籍の原型
- 宗教的な理由で戸籍的なものがあるのは他の宗教も同じ
- キリスト教でも洗礼や葬式の記録によって登録する
- ここまではバックエンドのデータベースの話だった。いよいよトークンの登場
- 往来手形: 関所を通るための手形。パスポート
- 明治維新と戸籍制度
- 岩倉具視使節団と基督教解放
- 東京駅の立てかえ: 大正3年
- 明治の戸籍は血のつながりとか関係なく建物で書いていた
- → 血のつながりで戸籍を作った
- 交通が整備され、住所が変わる人の管理をちゃんとやる必要が出てきた。寄留法 → 登録してもしなくてもよくて、あまり登録されなかった
- 関東大震災 → 表札の昔及
- 配給のために作った世帯台帳
- → 信頼できる整備されると他の用途に使いたくなる
- → 選挙に使った
- → 配給が終わったら困るよね → 住民票になった
- 戸籍と世帯台帳をつなげる仕組みが作られた
- そもそもなんで戸籍と住民票が分かれているのか、という問に対する答
- 当時はコンピュータがなく紙で管理しているので、書きかえるために信頼度が下がる。人が死んだとかめったに使わないものは戸籍として分けて残った
- 当用漢字と人名用漢字
- 住民票を法務省から自治省へ(1967)
- 漢字コードと外字問題が発生(1990年代)
- パソコンとネットの普及
- クレジットカードとパスワード、昔は心配されたけど結局使ってるよね
- 米同時テロ事件 → 本人確認の強化
- 日本には本人確認の法律がない → はじまった
- 住基ネットと反対運動
- 個人情報保護の流れ
- 住基ネット自体は合法という判決が出たが、どこまで組織間で連携していいかは、このときの判決の解釈が大きな論点
- ソーシャルメディアの台頭
- まったく別の文脈で個人が自ら情報を出していく動きが活発になっている
- キリスト教弾圧のための寺請制度が行政に使われた。配給のための世帯台帳が行政の基盤になっていった。いままた、友達関係を記述していたIDが行政に活用されようとするのかな
- IDと政府
- 管理目的を持って管理しようとしてもうまくいかない
- 何かの目的で集めたものを別の目的に使うほうがうまくいくかも
- Q&A
- nat: 今日、入るのに名刺を出してくださいと言われたが、えっ、これ本人確認なの? と思った。どうでしょう
- masanork: それはsunk costであろう。なりすますために印鑑作ったり名刺作ったりはしないだろう。役所で住基カードを出すときらわれる。運転免許の方がよかったりする。tokenの強度よりもattributeを気にしている。
- nat: 名刺の裏にお金貸しますと書いてサインするのはいいと思う。文書として成立する。一方名刺はかんたんにリプレイアタックできる面もある
- masanork: 複数枚の名刺を用意させるという手がある。自分の名刺を複数枚(2枚とか5枚とか)持っていればOK。他人の名刺を作ると私文書偽造になる?
- nat: 米国では人をだます目的で作ると罪になる
- nat: 今日、入るのに名刺を出してくださいと言われたが、えっ、これ本人確認なの? と思った。どうでしょう
- 感想: 非常に面白かったです。歴史の時間に習った、でも忘れてた、というようなものが多く出てきて、勉強になりました
「OAuth Server、セキュアに実装しようず」
- (20:32)
- 司会: @nov
- パネリスト自己紹介
- confidential clientとpublic clientの割合は?
- n: FBクライアントはimplicitだと乗っとられる場合もある
- n: mixiさんimplicitサポートしてないですよね? なぜ?
- y: 社内でサポートしたいねという話は出ては消えをくり返し、3年半経過。一番大きな理由は、過去にmixiサービスで事故ったりということもあり、シビアに考えているということ。一度やらかしてしまうと本当にオワコンになってしまう。OAuthの本来の目的である認可を考えると、ユーザーが許可したとしてサービスが良い子とは限らない。良い子じゃなかったときにPF側で何もできなくなるので、client_idを外すことはできなかった。「あなたはもうダメです」という最後の砦をくずしていない
- n: 楽天さんはどうでしたっけ?
- j: してません
- n: appiaries ではサポートしてますよね
- g: サポートしてます。redirect uriを制限し、カスタムスキーマは禁止。user credentialも許していないのでいいかな、と
- n: NRIでは気にしてます?
- k: サポートしていないところの理由はかんたんで、implicit grantいらないや、というのが多い。サポートしたところはJSのゲーム、flashからAPIを叩きたいということだった。APIを使えるclientがどんなAPIを使えるかというと情報参照程度。書き込み系はガンガンポイントを増やせるなどヤバイので、codeを使ったり、サーバーからリクエストを投げるような用途に限定するなどが現実的
- y: 気にしてるのはセキュリティーだと思う。アプリは主流がJSでブラウザだったりスマホだったりする。FBもGももうimplicit grantをサポートしてブラウザ上でアプリ書いてくださいというように、バランスが変わってきていると見ている。最後の砦とか言ってると世界に取り残されそうな危機感はある。自分で自分の首をしめないように見ながら、ある日決断するのかなあ、と
- n: public clientと両方サポートしてるときは比率どれくらい
- g: 7割くらい。3割はconfidentialを選んでみただけ的な
- n: 通信解析するとsecret送っているアプリがいたりするけど、バレるとマズイよね。むしろimplicitよりマズイと思う
- n: スマホターゲットなんだけどconfidentialしかサポートしない例はあるのか
- k: 基本的にはみんなcodeでconfidential。ただしiOSのkeystoreにちゃんと保存しましょうというところまで手が回っていない。そこがアプリ開発者の人達のモラルやノウハウにまかされている。アプリでインストールベースで全部同じsecretが入っているの、漏洩したらどうします? って言っても、こうしたらみたいのを言えないのがもどかしい。client_secretをインストールベースごとにサーバーで一意に発行するようなお客様もいない。アプリを作る側からすればimplicitでいいよね、ってなってしまう
- y: アプリをクラックされてsecret抜かれちゃうって話になっているけど、通信路からもれるのとは別の話だと考えた方がいい。ストレージをクラックするのは100%ではないのでがんばりましょうという話。通信路の場合は受ける方がSSLでしか受けないとなれば、アプリでは送るしかない。
- n: ユーザーを守るのか何を守るのかという話
- y: OAuth1に戻って署名を送ってもらえばちょっとは上がる。
- j: モバイルアプリにsecretを入れるのは昔は推奨されていたがいまは逆になっている。業界も変わってきている
- n: 悪意のあるユーザーからは守れない。client credentialをサポートしていなければ、漏れても大したことないかな、と
- n: Googleは面白いことにclient credentialをスマホアプリに埋め込ませてる。client credentialフローでは取らせないようにしてるのかな、と想像するけどわからない
-
- 会場: 認可した後の悪いアプリからの防御はどのように考えているのか
- y: ひとつは通報。誰かが見つけてくれて教えてくれたら調査します。もうひとつはAPIのアクセス数の傾向をいまのところ全部見ている。本当にヤバイものにはリミットをかけている。実際にリミットがかかったものは、誰がどのアプリでいつ、を監視している。スパイクが出たり、他のものと傾向が違う場合には調査を始める、という形
- nat: 楽天さんはstateパラメータをサポートしてないのはなんで?
- j: redirect_uriのパラメータを許可しているので、そっちでやってほしい
- y: redirect_uriは登録時に決まってしまう。パラメータをつけられないとすると困りません?
- j: 完全一致でなくある程度の範囲を許しているので、その中でパラメータをつけてもらっている
- nat: stateはクロスサイトスクリプティングを防ぐためにnonceを入れるもの。どうすんの?
- j: query_stringの部分はそのまま送るようになっている
- k: 完全一致だとconversation idがreturn_toに入っているとはじかれるので、うまく使われていなかったり
- nat: 仕様を作っている人達からすると完全一致にしてstate使えということ。オープンリダイレクタを作れてしまうので。stateを送られたらそのまま返せというのは仕様上のMUSTになっている
- k: 昔、zigorouさんのプレゼンでオープンリダイレクタ作れちゃう話はありましたね
- OpenID Connect対応する? 何が面倒?
- nov: 特に結論はないんですけど、OAuth2はドラフトが長いまま31まで来ちゃったんですが、これから実装する人はこのへんの人をつかまえて聞いてください
- 感想: 各社、顧客の要求に応じてトレードオフを決めているということですね
(21:10)
この後、同じ会場でDeNAさん提供の懇親会がありました。うにもちゃんとありましたよ。
今回のidconも面白い話ばかりでした。masanork先生の戸籍制度の歴史は本当に面白かったです。Ustreamでもう一度見直してみよう。
セッションのメモ、間違って書いている点などあると思いますのでツッコミお願いします。
「粋」と「LTソン」と「ランチくじ」〜YAPC::Asia 2012に行ってきた
今年から東大に会場が変わったYAPC::Asiaに行ってきました。
最初に、運営にかかわったスタッフのみなさん、ありがとうございました。この場を可能にしてくれたスポンサー、個人スポンサーのみなさんにも感謝します。
そして主役はなんと言ってもスピーカーの方々、参加者の方々。みんなすごかった。日々の活動の中であれこれ工夫したことが、惜し気なく交換されていて、ここにコミュニティーありというパワーを感じます。技術者としてのカッコ良さ、なんていうか「粋」というのか、そういうものを感じました。2日目午後のPerl今昔物語の中で、こんな会話がありました。司会の馮さんの質問に宮川さんが答えたものです。
これは本の執筆に関する言及でしたが、「競合とか関係ない」というのが、YAPCや、もっと広く日本の勉強会文化の根底にある強さだと思います。ちょっと前に「APIを提供して、たくさん使ってもらった者が勝ち」みたいな言葉が流行りましたが、たくさん出した者がたくさん得るんだなと、それはここにいる技術者達の姿とそのまま重なります。自分ももっと出していかないといけないなー。
今回のYAPCは見たいセッションが重なっていて、というか、全部のセッションを見たくて、体がひとつでは足りないと叫びたくなりました。その悩みに拍車をかけていたのがLTソンで、ホールにいると外から歓声が聞こえてくるんですよね。最初にこの企画を聞いたときには、「2日間もスピーカーを集めるのか、大変だろうな」と思っていました。だけど人がしゃべっているのを見ると自分もしゃべりたくなるもので、それはみんな同じだったみたいで、2日目午後はスピーカーが多すぎて大変になるくらいだったようです。
ぼくも時間をもらって、「Lightning Talk日本上陸」と題して話させてもらいました。日本で最初にLTをやった時、どんな様子だったのかを紹介しました。
最初のLTのときは、1時間で11個のトークをするなんて本当に可能だろうか、10個でいいんじゃないかという心配がありました。みんなとにかく5分で話を終わらせることに命をかけていたw、その結果、56分40秒で11個全部こなしています。とにかく時間内に全部のトークをやること自体も「ネタ」の一部として楽しんだ、フォーマットが面白い、という現象だったんだろうと(今になっては)思います。
この発表の後、LTソンでは1トーク5分質疑応答ナシのフォーマットになってないじゃない、という声が少し出ました。実はぼくのトーク自体も15分以上しゃべってたと思います(ゴメンナサイ!)。その部分について少し言い訳がましいことを書きます。LTは元々、スピーカーが多すぎてセッション枠が足りないことから設定されたフォーマットだったろうと思います。LTソンはそれに対して、「しゃべるということの敷居を下げ、双方向コミュニケーションのできる場を提供したい」というuzullaさんの想いがあって(「やろう!LTソン!」)、そこはばっちり合っていると思います。ツイートからちょっと引用。
Hachiojiスタイルいいですよね。LTとは別の良さがあるので、それを強調したいときは別の名前を使うといいかもしれません。
時間内でなるべく多くの人に話してもらおうとすると、「本来のLT」形式に(自然と)近づきます。きっと最適に近いんでしょう。そこは痛しかゆしかもしれません。つまりHachiojiスタイルは、LTソンの目的には合っていた、それは正しいとか本来とかじゃなくて、最適なフォーマットを選んでる、ということだと思います。
ほんとにそう思います。LTソンを企画・運営したHachioji.pmのみなさん本当に楽しい時間をありがとうございました。
今年はもうひとつ、「ランチくじ」という企画もあって、くじで当たった人達がチームになってランチに行くというものでした。知らない人同士でランチに行くというのはいいですね。シャイな日本人には「くじで強引に決める」のがなかなか効果的だったんじゃないかと思います。2日目の組合せ発表が終わった後、牧さんは「ほらほら、外れた人達も近くの人に声かけて一緒に行って」って言ってたけど、どうだったかな? (すいません、ぼくは昔からの知り合いと2人で中央食堂に行っちゃいました)。単純にシャッフルして掲示するという案もありましたが、不在率が高かったし難しいかなあ。
毎年のことですが、YAPCに行くとものすごくエネルギーをもらいます。今年はとくに、コミュニティーの人と人とのつながりを強く感じました。その象徴みたいにLTソンとランチくじが印象に残っています。Skyarc枠の発表もどれもすごく元気があってすばらしかったです。
自分もなにか少しでも貢献したいと思って、ツイートをまとめておきました。ハッシュタグ検索って、とぅぎゃろうとしてもある程度以上の数はさかのぼれないらしくて、夜になってからでは朝のツイートが取れないことが多いです。早めにスタートしておきました。
- 28日午前 http://togetter.com/li/380849
- 28日午後 http://togetter.com/li/380913
- 28日LT以降 http://togetter.com/li/381051
- 29日午前 http://togetter.com/li/381407
- 29日午後 http://togetter.com/li/381452
- 29日LT以降 http://togetter.com/li/381525
もう一度、YAPC::Asia 2012に関わったすべてのスタッフ、スポンサー、スピーカー、参加者のみなさん、すばらしい時間を本当にありがとうございます。
HTML5とか勉強会の番外編〜ブラウザとサーバの間を考えよう〜に行ってきました
司会: わかささんより、濃い話はツイート×サイン(特製うちわ)が出るとのこと
今回、会場の節電の都合で空調が止まっている中、
配布されたノベルティーのgooうちわを使ってみんな暑さをしのぎました。
会場担当のみなさんありがとうございました。
以下、[]内は私の感想です。
(19:15)
WebSockets html5j.org 小松さん
- どうやったらWebページが速くなるかを日々追求
- wakochiのデモ http://wakachi.komasshu.info
- サーバーに「分かち書き」で入っているテキストをどんどん取ってくるデモ
- WebSockets pipelineを使っている
- 今日のトピック
- Intro to WebSocket and SPDY
- Dive into WebSocket Protocol
Intro to WebSockets
- Webの使い方が変わってきた
- 最初はHTMLひとつ → イメージ、CSS → ユーザー/ユーザー間コンテンツ
- Single resource → multiple resources → multi + bidrectional
- 使われているプロトコルはHTTPで同じ: リクエスト/レスポンスのプロトコル
- どんな問題が?
- 複数リソースの場合、往復をくり返すので遅い
- リアルタイム性にはポーリングが必要
- 現在どんな方法が使われているか?
- 最新テクノロジー: SPDY, WebSocket
- プロトコルスタック
- 比較表: slideshare参照
- ゴールは
- SPDY: レイテンシを縮少
- WebSockets: 双方向アプリケーションを作る
- ゴールは
Dive Into WebSocket Protocol
- デモ1: multi device interaction
- デモ2: 双方向通信の比較
- echocompare.html: マウス座標をエコーするだけのデモ
- WebSocketsでも遅延はあるがなめらかに流れる
- JSでの書き方の例: slideshare参照
- プロトコル定義 RFC6455
- handshake: in context of HTTP/1.1
- data transfer: frame format
- schema: ws(80), wss(443)
- 多くのブラウザでサポートされてきている
- ハンドシェイク
- request
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket ← websocketを使いますよ Connection: Upgrade ← upgradeしたいです Origin: http://example.com Sec-WebSocket-...
-
- response
HTTP/1.1 101 Switching Protocols ← upgradeしますよ Upgrade: websocket ← websocketですよ Connection: Upgrade Sec-WebSocket-...
- データフレーミング
- reachability
- プレーンなデータを送ると、intermediaryが中身の解釈ができないとき打ち切ってしまうことが
- subprotocol
- WS上で動くプロトコルを決めよう → IANA登録
- extension
- multiplexing
- per-frame compression
- socket.io
- fallbackしてくれるJSライブラリ
- スケーラビリティーは?
- ロードバランサ(node-proxy, nginx)でWSを解釈してアプリサーバーに振り分ける
- [感想: WebSocketsはintermediaryがどれくらい対応してくれるのかに期待でしょうか。いったんつながってしまえばTCPみたいなものですが、逆に言うとそこでどんな情報を交換するのか、プロトコルをまた考えないといけないですね]
(19:53)
SPDY IIJ 大津さん
- @jovi0608, https://github.com/shigeki
- slideshare: http://ow.ly/c1NzK
- SPDYのベンチマークができるサイトを公開したい
- 作ってみたら安定しない。過激なことをやろうとすると止まってしまう
- 会場でSPDYのサイトを立ち上げた人 → 2人くらい
- 安いSSL証明書があれば。オレオレでもOK
- Node.js, Jettyなどの実装もある
- 最近SPDYが話題です
- SPDYの歴史
- SPDYの状況
- 最近のトピック: Chrome Secure Proxy
- HTML読込の高速化
- SPDYの特徴 (Google I/O 2012の資料より)
- SPDYに向かないこと (Google I/O 2012の資料より)
- SPDYフレームの詳細
- ハンドシェイク
- SYN_STREAM
- ヘッダ圧縮の仕組はkey-valueペアをzlib圧縮してるだけなので、HTTPに特化しているわけではない
- サーバープッシュ
- SYN_REPLYを送る前に先読みデータを一方向streamをサーバー側からどんどん送っちゃう
- レスポンスが届いたときにはもうデータがキャッシュにある
- Navigation Timing APIでSPDY動作を調べるサイトを作った
- window.performance
- 測ってみた → pushはそんなに稼げない
- 実際にデモ
- [感想: SPDYはNPN拡張でハンドシェークするのが難しいところです。ロードバランサがSPDYネイティブにしゃべれない場合はport forwardingでがんばるのでしょうか]
(20:30)
SSBP Skeed 柳澤さん
- SkeedSilverBulletProtocol
- 誰得?
- ブラウザから使えるわけじゃない
- TCPでいいじゃん
- ↓次のような用途に
- WAN越しにファイルを送ると異様に遅い。特に外国に送ると遅い
- 話の流れ
- この現象の存在自体の認識
- 正確な理解
- TCPの仕様・実装に課題
- さあ直そう
- TCPに仕様・実装はどうなっているか
- 何が問題なのか
- ウインドウサイズの問題
- 広帯域&遠距離で通信する場合の適正なwindow sizeはすごく大きい
- 100Mbps、RTT 150msだと1.875Mバイト
- OS間通信ではバッファの大きさなどが原因で適正値の範囲がそう変えられない
- 広帯域&遠距離で通信する場合の適正なwindow sizeはすごく大きい
- フロー制御の問題
- パケットロス率はある程度から下げられない
- 輻輳ではないのにパケットロスが発生するとレートを下げてしまう
- → だから代替・改善が必要だ
- ウインドウサイズの問題
- SSBPの想定
- 帯域副は広いもの
- 距離は遠いもの
- パケットロスは当然ある
- OSカーネル内で動作するのは必ずしも必要でない
- SSBPの実装
- TCP: 到達完全性の保証とフロー制御の実現とがACK機構を介して密接に結びついている
- ACKが2つの役割を持っている
- SSBP: この2つを完全に分離、それぞれに最適な手法を取る
- 届かなかったパケットを選択的にまとめて報告
- TCP: 輻輳とパケットロスとを同一視
- SSBP: パケットロスは不可避だからそれ以外の方法で
- 輻輳によるパケットロスの前には機器遅延の増大が発生するはず。つまり「狙うべき遅延」があるはず
- 例えば…: 電話かけてから出るまでに時間がかかるようになると不良品が出はじめる
- 電話をかけたら45秒で出れるくらいの忙しさをキープする!
- 輻輳によるパケットロスの前には機器遅延の増大が発生するはず。つまり「狙うべき遅延」があるはず
- ユーザー空間で動作するアプリとすることでバッファを大きく取れる
- その結果… 16時間を30分に
- TCP: 到達完全性の保証とフロー制御の実現とがACK機構を介して密接に結びついている
- とにかく実用性重視
- プロプライエタリなプロトコルを作ることについて
- まとめ
- [感想: すごく面白くて、どんどんのめり込んで聞いてしまうプレゼンでした! 用途を限って最適化するというのはわかりやすい話でした]
(21:00)
第二部: 座談会
- NTTコミュ様ご提供のケータリングとビール、ソフトドリンクなどを楽しみつつ
- ところどころツイート禁止の濃い話をたくさん聞けました
- 総論としてはこんな感じでしょうか
- WebレイヤからWSやSPDYが出てくるのだがと、結局低レイヤの話になってくる
- intermediaryのことを考えないとサービスとしては成立しない
- 両レイヤの技術者の間でのコミュニケーション、乗り入れが重要になってくる
- @komasshuさんの「俺はweb屋だ、俺はネットワーク屋だ、と閉じていては辛いっちゅうことですよ」という言葉が印象に残りました
非常に楽しく、また勉強になる時間でした。ありがとうございました。
idcon13レポート
idcon13に行ってきました。今回はあまり追いてかれた感なかったです。
仕様の話もあり、啓蒙の話もあり、いいバランスだったんじゃないでしょうか。
- イベントリンク: http://www.eventbrite.com/event/2417781650/
- スライドまとめ https://www.facebook.com/idcon.org
- つぶやきまとめ http://togetter.com/li/326813
以下、[]内は私の感想です。
(19:10)
「OAuth大捜査線」 @asyoulike007
- OAuth2.0
- エンジニアが開発、一般ユーザーが認可画面を見て使う
- エンジニア向けの仕様解説や実装方法の記事はよくある
- ディレクタ、デザイナ、営業向けの解説はあまりない
- OAuthを使っていても、適切に実装できていない例がある
- @ritou 椅子を投げたくなる件 d:id:ritou:20120619:1340101421
- → まだまだ布教が足りないですよ
- mixiのOAuth2.0対応
- draft10 (一部12)
- auth code, resouce owner credential, client credential
- 事件は現場でおこってるんだ!
- 現場その1: SAPさんからの問合せ例
- (1)認可画面を表示しないようにして欲しいのですが…
- 認可の意味をおわかりいただけてないのでは?
- 認可画面から50%のユーザーが離脱している
- [要求されるスコープが広すぎたりすると、やっぱり離脱しちゃいますよね]
- 認可画面の出し方にも課題が
- 認可の意味をおわかりいただけてないのでは?
- (2)AさんのアクセストークンをBさんに使い回していいでしょうか?
- 意味を知らない
- 意外とこういう問合せもある
- 保存しておけばどんどんデータが取れるという発想??
- (3)問合せメールにconsumer secretが記載されている
- メールは開発者でなくディレクターが書く場合も
- どのアプリについての問合せなのか特定できる情報として送ってしまう??
- メールが社内MLに転送されたり、チケットに貼られたりしている
- 返信するときに、秘密にしてくださいね、と啓蒙している
- メールは開発者でなくディレクターが書く場合も
- 開発チームへ伝えるべき
- 何のために認可しているのか
- 取り扱いに注意が必要な項目は何か
- 認可画面の実践的な組み込み方
- → ユーザーの混乱を少なくしたい
- 信用問題に関わる大事なこと
- 現場その2: 一般ユーザー様
- OAuthの主役はユーザー。開発者向けに語られることが多いが、ユーザーが最重要なはず
- なんとなく「許可」しているのではないか
- みんなちゃんと理解しているのか?
- なんとなく許可してしまう → スパムアプリが横行
- ユーザー側でpermission controlできることを知らない
- 後から止める方法を知らない
- 一般ユーザーへ伝えるべき
- 認可画面では何を許可しているのか
- 許可/拒否すべきアプリの見分け方
- 被害にあったときの解除方法
- 不要な認可を定期的に掃除すること
- エンジニア向けだけでなく、ディレクター、一般ユーザー向けの解説記事も必要
- Tech総研にて執筆中 http://bitly/Lmnzgo
- Q&A
- _nat: 英語のスライドほしいです
- [感想: 自分の情報をどこまで出すかっていうシンプルな話なんだけど、説明しようと思うと小難しくなってしまうのはどうしてなんでしょうね? イヤなものはイヤと言えばいい(言える仕組はある)、っていうのでは単純化しすぎですか]
(19:30)
「Identity First, Device Second」 @shingoym
- 山中しんご
- いかりや長介 OAuth! 「おい〜っす」 [はずした…]
- 「Mobile First, PC Second」と言ってる会社がいる
- 懐疑的だと思っている
- デバイスなんかどうでもいい。IDの方が重要
- 〜という話をしようと思ったけどやめました[やめるのかよ]
- IdentityRola、みんな知ってますよね?
- [→ アカウントBANされてるじゃないか]
- おっさんだけでIDについて話してるのはあきた
- うまくペルソナ使い付けてやろうぜ
- 前回のidconも男性ばっかりだった
- タコつぼ化イクナイ
- 女性のほうがプライバシーには敏感だったりする
- 海外にはIdentityWomanもいる
- twilog.log/shingoym/date-120410
- 許可しておっけ〜ペロペロ、みたいなノリがほしい
- IdentityRola を始めた
- しばらく内緒でやるはずが、すぐ見つかっちゃった
- なみだぐましい努力w
- なんでバレた?
- keijitakeda先生に返信したらRTされちゃった
- Innovationとは元々「新結合」
- 交わることのない2つ(identity, Rola)の組み合わせ
- いつのまにかフォロワー100人越え
- IdentityRola の名前でいろいろつぶやく
- アカウントbanくらってしまう[やはり]
- 30時間だけ
- Digital Death
- なんでBANされたか?
- 本物ローラに対する質問に横取りして返事したら即攻BAN
- 教訓
- identifierを変えてもわかる人にはわかる
- つぶやきなどの外縁情報である程度特定可能
- 他人になりすますことは難しい
- → ペルソナのコントロールは無理?
- 名誉毀損や肖像権の侵害
- verifiedアカウントの仕組みと価値
- 「なりすましなどのプライバシー侵害?」
- なりすましってプライバシー侵害?、という違和感のある表現だと思っていた。Rolaの件でなりすましによって自分の望まない自己像が作られることは、やはりプライバシー侵害だとわかった
- 次世界のための啓蒙プラットフォーム
- Identity × Rola
- → 次は?
- → @IdentityPamyu
- Q&A
- lef: ぶっちゃけ本気でかくせると思ってた?
- shingoym: 割と本気で。わかってもいいとは思っていた
- lef: ぶっちゃけ本気でかくせると思ってた?
- [感想: IdentityRola知りませんでした。おバカなことをやっているようでいて、ちゃんと教訓が得られている点がすごいです]
(20:05)
「UMA - User Managed Access」 @ritou
- OAuth
- Resource serverとAuthorization serverは一意に結びついている
- 認可管理はリソースの数だけ、たくさん発生する
- クライアントはResource ownerの代わりにリソースアクセスを行う
- 自分が所有するデータにアクセスさせるためのしくみ
- 第三者に共有する仕組みではない
- Resource serverとAuthorization serverは一意に結びついている
- UMA (うーま)
- Resource server と AuthZ serverを分離
- 好みのAuthZ serverを利用可能
- 第三者へのリソース共有も可能
- person-to-self
- person-to-person
- person-to-organization
- ポリシーはユーザーが決定
- Resource server と AuthZ serverを分離
- UMA Flow
- 用語が変わります。Authorizing User, Host, Requester, AuthZ Manager, Requesting Party
- 1. Protecting a Resource
- リソースを保護するAMを指定
- HostがAMからトークンをもらってリソースを登録
- scopeの集まりをresource setとして登録
- ポリシーを設定
- リソースを保護するAMを指定
- 2. Getting Authorization
- アリスはボブに画像URLを教える
- ボブはリソースを取りに行く
- まずはエラーとしてチケットを送信
- AMが作成した認証要求チケットをRequesterに返す
- RequesterはRequesting Partyに対して同意を求める
- Requesting Partyの情報をAMに開示していいかどうかの同意
- AMはpermissionのついていないトークン(RPT)をRequesterに渡す
- RequesterはさっきのチケットをつけてRPTを返す
- AMがボブさんであることを確認して認可
- 3. Accessing a Resource
- RPTを用いてHostにあるリソースをアクセス
- HostはAMにRPTの有効性をチェックしてもらう
- 思ったこと
- リソースと認可の分離だけ見ても可能性を感じる
- コンテンツが強いところは認可管理をアウトソース
- スタートアップが安全にリソースアクセスを提供できる
- グループ企業内のAPI連携など
- 一緒に実装しませんか? いまならブルーオーシャンなんですぐ日本一になれるw
- [感想: 正直難しい。UMA認証を受けるためには自分の身分を明かさないといけないから、それ自体に対しても認可を求めるようになっているなど、納得はできた]
- [懇親会での話題: AM間でトラストして認証を回してやればいい話なんじゃない?]
(20:30)
休憩 〜 Tシャツ配布
(20:40)
「SITF - Student Identity Trust Framework」 @tzmtk
- まつおかさん
- たなかさん
- (先月OpenID Foundation Seminarの内容)
- トラストフレームワークとは
- 何がうれしいの?
- 安全に流通できる
- IDP/RPが満たすべき基準をチェックできる
- 与信の手間を減らせる
- 何がうれしいの?
- ユーザーもうれしくなるはずだよね?
- → 実証してみましょう
- オンライン学割の課題
- 登録時: 本当に学生なの? → 学生証郵送?
- 利用時: いまも学生なの? → 定期的に確認?
- 正しく運用しようとするとコストがかかってしまう
- かと言って雑に運用すると、正規料金を支払っているユーザーが不公平に感じる
- フレームワーク案: 策定しても利用されなければ意味がない!
- Attribute Provider
- IdP :== {discovery, authentication, attribute} provider
- APをIdPから分離することを考えてみよう
- 学認を使って学割
- デモ
- デモサイト: http://sitf-rp2.openidconnect.info/ticket
- @shingoym このデモの台本を後で共有してくださいね
- 宣伝
- 夏からphase2として具体的にやりたい
- 参加者募集 → @shingoym まで
- Q&A
- nov: デモでログインをtwitterでやったのは意味ないんだよね?
- [感想: ユースケースはたくさんありそう。共通する原理があるんだけど、一般の人が理解できるか。あるいは理解しなくても安心して使えるか、であればいいのでしょうか]
(21:00)
世界「Identity Firstでいきますから。」 JIPDEC 野村至さん
- ポイント
- 1. 先進諸外国を見ると「Identity First」な潮流
- 2. 個人情報保護やプライバシーへの配慮
- 3. 先進諸外国はすでに取り組みを始めています
- 4. OECDのdigital identity management指針が発表されました
- Id 1stの潮流
- 自国の情報経済を活性化させたい!!
- 安心・安全で信頼できる利便性の高い情報環境が必要
- 課題
- 適切な身元確認ができない
- 適切な認証環境になっていない
- 適切なデータ利用ができていない
- 適切な運用が必要
- ドイツのデジタル・アイデンティティ・マネジメント
- アメリカのデジタル・アイデンティティ・マネジメント
- イギリスのデジタル・アイデンティティ・マネジメント
- EUの一般データ保護規則案
- プライバシー・個人情報保護の観点を追加
- データポータビリティーの権利
- あるサービスプロバイダから別へ移行できる
- 「忘れてもらう権利」
- 日本
- デジタル・アイデンティティ・マネジメントはあまり重要視されていない
- 余白が多い
- OECDデジタル・アイデンティティ・マネジメント指針
- 国家戦略で!
- [感想: ドイツの例は参考になります。名寄せに関して、日本は割と気にしてないような感じがありますが、もっと問題意識が共有されるといいなと思います]
(21:30 end)
