Strangeloop「wine.comにsite optimizerを導入してもらった件」
strangeloopnetworks.comで恐らく2012.4.13頃に公開された記事
Case study: Wine.com - Strangeloop
- 2012.4.13の公式アカウントでのtweetから公開日を推定
- ie6-7しか使えない環境から大量の注文が届き、ie6-7で注文出してくるお客はサイトの遅さにシビアで、商材への法規制が複雑かつ改正が頻発し、ページ表記を超柔軟に変えないといけない
- そんな商材（ワイン）のECサイト、7年目突入のwine.comにサイト高速化ツールSite Optimizerを導入してもらうまでの道のりを色々データ出して説明する、という主旨のエントリ
- wine.comのエンジニア達がコンバージョン上げるために、ABテスト、リソースの軽量化、色々最適化を続けた。けど「リソース足りない」のでツール探したのがきっかけ
- ctoのインタビューからとったコメントをもとに再構成。クライアントからのリップサービスも多い
- pdf版もあり
以下斜め読んだ内容
- はじめにwine.comのCTOのお言葉
- フロントエンド最適化ベンダーを調査してみて出した結論
- ベンダーの中でstrangeloopは突出してる
- グローバル展開してるサイトを高速化させた実績のあるのはstrangeloopだけ
- site optimizerはエンタープライズ規模でも対応できる唯一のプロダクト
- クライアントのサイトがクラウド使ってるとかそうでないとかも関係なく対応してる
- wine.com？
- ワイン専門のecサイトでは過去7年no.1。「internet retailer magazine」調べ
- 登録ユーザは100万以上
- ワインの種類は、1万3000種以上
- 2011年のデータだと、200万ボトル以上を出荷、昨対比35%増
- ギフトやアクセサリなどワイン関連の商材もある
- サイトではレビュー投稿、レーティング、リスト作成ができる
- 約4万人くらいのコミュニティができてる
- レビューやワインリストなどがシェアされてる
- Geoffrey Smalling（=wine.com cto）曰く
- パフォーマンスはローンチ直後から最重要課題
- 購入直後にお客からフィードバックをもらうようにしてる
- ceoはこのフィードバックの全てに目を通してる
- フィードバックのうち「サイトが遅い」系は全部cto宛に転送。結構な数が来る
- パフォーマンスがネックになってるのはモダンなECサイト共通の悩み
- お客はインタラクティブなエクスペリエンスを求める
- ニーズに応えるため、ECサイトはリッチなコンテンツをページに詰め込まないといけない
- コンテンツの詰め込みは代償がつきもの
- cto曰く
- リッチな機能と画像のデータ転送とレンダリングには所要時間が発生
- cto曰く
- wine.comの高速化へのもう１つの壁はIE6-7対策が必須なこと
- cto曰く
- 調査してわかったこと
- 購入金額の高いお客の中で金融系の会社の人がかなりいる
- 金融系のお客は職場から注文してる
- 金融系のお客の職場で使えるブラウザはIE6-7だけ
- ie6-7向けにはwine.comはまるで最適化されてなかった
- 金融系のお客はクソ重いページから注文を出す羽目になってた
- cto曰く
- データセンターのリージョンもまずかった
- データセンターは西海岸にあった
- 金融街のお客はたいてい東海岸にいた
- 地理的に離れてるので、ページ読み込み時間が更に遅れる要因となった
- ベストタイムで４秒という状態だった
- ページ読み込み時間が４秒かかること
- これで満足するECサイトも中にはある
- wine.comにとっては満足できる状態じゃない
- 「３秒以下」がwine.comの目標だった
- cto曰く
- 「読み込みに4秒」でよしとできた時は過去の話
- テクノロジーは進歩し、お客の期待は大きくなった
- 4秒じゃ遅い
- 「読み込みに２秒」はデカい目標だったのは昔のことで、今は達成しないといけない
- 達成できなければ、潜在顧客を失う。特に初回訪問者を失う
- 2009年からwine.comのパフォーマンス最適化はスタートしてる
- wine.comのデザインをリニューアルしたタイミングから
- cto曰く
- 当時リニューアルにはとても中の人たちはワクワクしてた
- 訪問者へ提供する情報をより豊かに
- ナビゲーションを合理的に
- 見栄えもよくなった
- お客により豊かなエクスペリエンスを提供できるという自負があった
- しかし待っていたのは、コンバージョンの大幅下落
- デザインリニューアル後のコンバージョン大幅下落の原因を中の人たちは探った
- 今回の新デザイン版と、簡易版でA/Bテストしてみた
- 簡易版はボタン３つ、２−３個の画像、コピー少々だけの構成
- テスト結果は簡易版の圧勝。コンバージョンも相当上昇してた
- cto曰く
- 当時中の人たちが痛感させられた事実
- お客は、素敵なデザインではなくサイトの速度を気にしてる、と
- 「速度大事」と気づいてからサイトのソースに手を入れた
- 簡易版の速度に近づけるように新デザイン版のソースに手をいれた
- テコ入れしていくと新デザイン版のコンバージョンは回復してきた
- 速度改善をサイト全体レベルで実施できるようにリソースを割くべき
- と、気付いたきっかけになった
- 2009年以降のwine.comのエンジニアチームが実行したこと
- サイトのソースに手を入れてパフォーマンス・チューニングを続けた
- 「サイト全ページで３秒以下に」の実現にはリソースが足りないと気付いた
- cto曰く
- wine.comでは1.3万以上の商品ページがある
- 各商品ページに対して、別バージョンが７つある
- 8バージョン必要なのは、ワイン出荷に対する法規制が州によってバラバラでお届け先次第で表記を変えるため
- お客がwine.comを訪問してリンクをクリックしたとき
- お客の居住州を突き止め、該当州への出荷にたいする法的制限の有無をチェックしたあとで、お客に合わせたページを表示させる
- これを３秒以下でやらないとダメ
- wine.comの高速化の課題おさらい
- ページはリッチコンテンツ
- ページは法規制にあわせて８バージョン用意
- ページはie6-7で閲覧される
- 洗い出した課題を解決するものをみつけるべくwine.comチームはリサーチを開始
- cto曰く
- 高速化のためのツール、サービスを探してみた
- strangeloopは抜きん出てた
- site optimizerは全てのブラウザ／OSに対応するツール
- セキュリティも万全だった
- site optimizerはかなり有望にみえた
- １つのツールを手軽なコストで導入するだけで、抱えてる課題全てが解決できるなら、相当すごいこと
- wine.comでのsite optimizer導入はあっという間に終わった
- 2010年のホリデー商戦に間に合った
- wine.comが重視する指標全てで劇的な改善を達成できた
ブラウザ別でみると最大で45%導入後高速化した
- cto曰く
- site optimizerは名前通りのことをしてくれる
- 全てのブラウザ／OS別の最適化をやってくれる
- 期待を裏切らないソリューションを使うのはとても気分がいい
- ブラウザ別平均ページ読み込み時間(2012.2時点)
- ビジネスにあわせてパフォーマンス最適化をさらにカスタマイズ
- サイト規模の恒常的増加が生み出す影響を減らす
- cto曰く
- 「読み込みを２秒以内に」はまだ達成できてないががんばってる
- wire.comのマーケティングの人はどんどん効果的ツール、コンテンツ、etc.をどんどん新たに編み出して導入しようとする
- この手の新規コンテンツ、ツールの導入は、パフォーマンス担当の人からすれば「負担が増えた」と映るの通常
- site optimizerは次々登場する負担を軽減するように働いてくれてる
- （補足）含意不明。どう軽減してくれるのかの説明が脱落してる
- 他のパフォーマンス系のツールと併用できる
- cto曰く
- 「これだけでOK」と言えるような、ページ高速化の万能薬はない
- パフォーマンスに意見のある人でもパフォーマンスに影響をおよぼす複雑な要因の絡まり合いを深く理解しているわけじゃない
- パフォーマンス改善は多方面からのアプローチが必須
- site optimizerはwine.comが導入してるサイト高速化のあくまで１つの（重要な）パーツ
- 高速化のために他にも手を打ってる。AakamaiのDynamic Site Acceleratorも使ってる
- パフォーマンス専門のエンジニアも招聘してる
- cto曰く
2012年10月以降にrssリーダー経由でtweetを受信する方法（2013年3月迄の期間限定）
- 追記
- id:netcraftさんからもっと手軽な方法教えてもらった
- 「https://api.twitter.com/1/statuses/user_timeline.rss?screen_name=nodejs」
- ２週間前より古いtweetも拾えるので下記に書いた方法より優秀
- GET statuses/user_timeline | Twitter Developers
- 2013年3月までというのは変わらず
- google readerやLDRなどrssリーダー購読したいつぶやきがある人向け
2012.10.10くらいから、rss読み込むとこんなxml(rss）しか返ってこなくなった
<?xml version="1.0" encoding="UTF-8"?> <errors> <error code="34">Sorry, that page does not exist</error> </errors>
アナウンスなかったので一時的かと思ったが、２日以上たった
ということで代替手段探した
2013年3月くらいまで有効な代替手段
LDRやgoogle readerにも登録できる
//例 http://search.twitter.com/search.rss?q=from:nodejs http://search.twitter.com/search.rss?q=from:joyent http://search.twitter.com/search.rss?q=from:spdybook http://search.twitter.com/search.rss?q=from:jsconf
という感じに「from:」の後ろにtwitter id入れると、rss受信できる
「from:nodejs」のコロンは「%3A」にエンコードされるので「from%3Anodejs」でも同じ
デメリット
メリット
api経由のrssならではのメリット
「from：」以外にもキーワード使ったフィード作れる
//ハッシュ#nodejsつけたつぶやきをまとめてrss受信 //feedのタイトル＝「from:nodefest OR from:nodejs - Twitter Search」 http://search.twitter.com/search.rss?q=%23nodejs //@nodefestと@nodejsなど複数のidを１つのrssにまとめて受信 http://search.twitter.com/search.rss?q=from%3Anodefest%20OR%20from%3Anodejs //spdyについての日本語のつぶやきだけrssで受信 //@kenya_SPDYさんを除外 //feedのタイトル＝「spdy lang:ja -from:kenya_SPDY - Twitter Search」 //「RT:〜」の嵐になるので、ノイズ多し http://search.twitter.com/search.rss?q=spdy%20lang%3Aja%20-from%3Akenya_SPDY
Guy Podjarny「Responsive Web Designなサイトは遅い、と言っておこう」
- Guy's Pod 2012.10.9のブログエントリ
- 追記
- 元エントリが更新されてたので、修正
- Guyのプレゼン動画聞き齧った内容も少し反映
Guy's Pod » Blog Archive » Responsive Web Design is bad for performance. There, I said it.
- 世界のトラフィックの数割を捌くAkamaiの中の人によるResponsive Web Designネタ
- Guyはモバイル向け速度計測ツール作ってたblaze.ioのCTOだった人
- blaze.io自体は2月にakamaiに買収された
- RWDに期待してる、人にも勧めてる
- けど認めるべき事実としてRWDは遅い、最適化してもどうにもならない部分残る
- その上でRWDでいくのに必要なこと、考えるべきこと、etc.を綴ったエントリ
- RWDが引き起こす速度低下は軽減できるがゼロにはならないでしょ、という立場から書かれてる
- 「RWDを頑張って高速化させる」系TIPSはあまり載ってない
- tips系は、エントリ途中でリンクしてる、スライドに詳しく載ってる
- Performance Implications of Mobile Design (Perf Audience Edition)
- 2012.4.16-18にOrlandで開催されたBDConfでGuyがプレゼンした時のスライド。プレゼン動画もvimeoにアップされてる
- Guy Podjarny - Performance Implications of Mobile Design - BDConf, April 2012 on Vimeo
- 数値、データ豊富でinformativeだが、リソース集としても有益
- rwdのパフォーマンスという（RWDシンパからはまず出てこない）切り口
- モバイル環境でのボトルネックについて事例つきで書いてる60枚くらいのスライド
以下斜め読んだ内容
- responsive web design
- 好きなアプローチだし筋はいいと思う
- けどRWDはとりあえず遅い
- RWDが遅くさせたwebを速くさせるのは結構難しい
- ハイパフォーマンスresoponsive web siteは不可能？
- そうは言ってない
- RWDダメ絶対？
- それも自分は言う気がない
- RWDは大抵の場合オススメできる
- RWDはページを込み入ったものにさせる
- そういう宿命
- 概して、モバイルで遅くなるよね
- RWDネタで書こうと思ったきっかけはTim Kadlecの良エントリ
- Blame the implementation, not the technique - TimKadlec.com
- Tim曰く、実装が良ければたいていの問題は解決できる
- Tim曰く、例えばRWDだって、正確無比に実装すれば高速化できるよ
- Timには一般的は同意できる
- 自分はRWDのパフォーマンスの悪さについて最近プレゼンしたことがある
- Performance Implications of Mobile Design (Perf Audience Edition)
- （補足）
- モバイル専用サイト、RWDなサイトのそれぞれのボトルネック、対策を解説してる
- モバイル専用サイトのボトルネック
- モバイルサイト本体には問題無し。軽量・高速
- PC版からのリダイレクトがボトルネック
- よくあるwww.hoge〜からm.hoge〜へのリダイレクトとか
- ESPNだと1.3秒のロス、ディスニー系サイトで2秒くらい
- httpのリダイレクト、js使ったリダイレクト、それぞれのコスト
- リダイレクトの最小化が、モバイル専用サイトの高速化のポイント
- RWDサイトのモバイルWebでのパフォーマンスの実情
- まずはmediaqueri.es
- Media Queries
- RWDなサイトのショーケース・お手本リスト
- スライド作成時点で掲載されてた347サイト。全部調べた
- webpagetest、解像度は４パターン、iphone/ipadは実機で
- PC版とほぼ同じリソース（html/css/js/img/json/etc..）をモバイルでもDLさせてる、とか
- 掲載サイトの5割〜９割は、ノーガード
- 86％のサイトで、DL量がPC/モバイルでほぼ同じ
- 11%のサイトで、DL量が減っても10%〜50%減の範囲
- 3%のサイトでだけ、DL量が50%以下に減らす努力やってる
- スマホで表示されてないコンテンツもPC版同様にDLされてます
- メディアクエリがPC向けcssロード自体はストップしてくれない、とか
- 「display:none」したってDLは止まらない
-
- 似た話として、css media queryやmedia typeも、DLの振り分けとかやってくれない
- smashing magzineは何か勘違いしてないか？
-
- PC版と同じ画像をDLさせてリサイズさせてるだけ。横行してる
- どうしてPC版並の巨大なDOMツリーがモバイル版でも構築してるんだ？
- RWDの成功例「Boston Gloveサイト」
- 表示はディスプレイサイズに合わせて可変。モバイルではシンプルに
- しかし、1400要素、4000ノードという巨大なDOMツリーが構築されてます
- 不要なリソースDL、過剰なDOMツリー
- これがRWDがモバイルWebを遅くさせる元凶
- RWD高速化TIPS
- 画像をなんとかできると一番大きい
- モバイルのトラフィック上位数千サイトでデータ取った
- リソースDLの67%は画像
- responsiveな画像DL
- サーバーサイド、クライアントサイド
- w3cで標準化が期待されてる部分
- Picture Element Proposal - Responsive Images Community Group
- 標準化されればimg要素を拡張しマークアップレベルで解決
- いわゆるmobile firstを読み替えて高速なモバイルwebへ近づく
- domツリーのサイズをモバイルに最適化。デザインにフォーカスするのではなく
- ミニマムなDOMツリーから、リッチな環境に合わせてDOMツリーをjsでエンハンスしていくアプローチ
- ミニマムDOMツリーからjsでエンハンスしていくアプローチ
- PC版でjsオフにしている人を無視してる
- jsオフにしてるPC環境は1%。彼らへの配慮と、モバイルでのパフォーマンスは両立しない
- どっち？と言われれば、モバイルのパフォーマンスを取る
- 解像度やレイアウト別にDLされるファイルを分けれるようにする
- レイアウトをコントロールするjsはインラインで書く
- 解像度に合わせてjs/cssダウンロードに使うscript/link要素のappendはdocument.write使う
- httpリクエストを減らす工夫。ファイル結合、htmlに直書き
- DLサイズ減らす工夫。minify。画像のフォーマット最適化
- 表示に必要なコンテンツを最初にDL。他は後回しにするDLの仕組み。オンデマンドなDLとかも
- 「@import」使わない
- m.hoge.comのようなモバイル専用サイトを比較対象に。DLされるリソースサイズの最適化を図る
- 計測ツール色々。計測しないと無意味
- mobitest,pcapperf(by google),icy(by stoyan stefanov),iwebinspector,webpagetest
- （補足）
- たいていのRWDなサイトがクソ重い原因は単に実装がクズ過ぎるせい、ということを言ってきた
- Performance Implications of Mobile Design (Perf Audience Edition)
- 自分はakamaiでこの手の高速化を自動的にやってくれるツール開発に取り組んでもいる
- たいていのRWDなサイトはモバイル環境で４〜５倍くらいは高速化できる
- とはいえ「RWDはwebを遅くする」という事実は揺らがない。今後も同じ
- RWDの問題は複雑さに起因する
- よくある「m.」なモバイルサイト（m.hoge.com、m.foo.com）
- シンプル
- htmlだけとかから作り始めれる
- 送受信されるパケットも軽量
- css,js,画像も少量で、それぞれが軽量（なことが多い）
- 他方RWDなサイト
- 複雑
- スマホでアクセスするとRWDなページはブラウザに巨大なhtmlをDLさせる
- やっとhtmlロード終わっても、js,css,画像の読み込みが更に始まる
- 可能な限りリソースの読み込みを回避する
- 可能だし、やるべき
- だが結構難しい
- 実装に問題のないRWDなサイトを作れた場合
- リソースの読み込みを避けて、コードが複雑化するのを避けることのできたサイト
- そのレベルに到達してもパフォーマンスは犠牲になる
- RWDなサイトをチューニングしまくっても、シンプル軽量なモバイル版（m.hoge..なサイト）の速度には追いつけない
- 同様なチューニングはモバイル版にも出来るから追いつけない
- 現状を見れば、RWDなサイトはモバイル版サイトよりも常に遅い
- ここまで言っておいてなんだが自分はRWDを支持してる
- 他人にもRWDをすすめる
- まあ速度は唯一重要なことじゃないから
- サイトの最適化をするというなら、最適化のリストに「高速化」が入ってないはナンセンス
- だが速度は唯一考慮すべき項目、という信条を持てるほど自分はナイーブじゃない
- 速度第一にしたら？と他人にも勧めることはない
じゃあどうすればいいのか？
- 今やってることをそのまま続ける
- RWDやってるならそれをプッシュする
- と同時にパフォーマンスのことを意識する
- エンジニア、デザイナーへ啓蒙する
- 彼らが「速度」のことを念頭に置くようにしてく
- 今日から今できる最善の手を打つ
- ブラウザベンダーに働きかける
- 高速なresponsiveなサイトをより容易に構築できるように
- responsiveな画像表示のために標準化プロセスへ持っていったような努力をしていく
- ビジネスの中に「速度」を組み込んでいく
- サイトが遅いことを要注意認定のバグなんだと考える風土を作ってく
- 実装する側にとって取っ掛かりになるよいリソースがある
- 事実を受け入れる
- RWDで作ることとは遅いサイトを作る事に他ならないこと
- RWDには代償がある
- retina対応の画像がよりリッチなコンテンツを可能すると同時に速度低下をもたらした。これと同じ話がRWDにも言える
- 事実を受け入れ、代償を減らすためにできることを積み重ねていく
- コメント欄
- Guyが丁寧にリプライしてるがinfomartiveだと感じる部分ゼロ
Tobie Langel「ios向け旧facebookアプリが遅かった件」
2012.9.15 public-coremob@w3.orgへのポスト
Perf Feedback - What's slowing down Mobile Facebook from Tobie Langel on 2012-09-15 (public-coremob@w3.org from September 2012)
- facebookがiosアプリをネイティブで作りなおした件について
- facebook.comにもポストした内容から、さらにパフォーマンスに話を絞って掘り下げた内容書いてて面白い
- この投稿自体にはレスが付いてないがinfoQがこのポストをネタに記事書いてて勉強になった
以下斜め読んだ内容
- ネイティブのiosアプリのリリース。なんで出したのか記事だした
- Under the hood: Rebuilding Facebook for iOS
- facebookが直面したパフォーマンス上の問題
- 詳しい説明が欲しいというリクエストが多い
- ということでポストした
開発ツール、開発用API
- ツールが無さすぎで、問題の切り分け大変すぎ
- facebookが直面してる問題はメモリに関係してるとみていた
- コンテンツのサイズがある大きさにになる
- アプリがデバイスのハードウェアのリソースを使い尽くしてクラッシュする
- こんなことがよく起こっていた
- 何が原因でクラッシュが起こってるのか突き止めるのがとても難しい状況だった
- GPUバッファを使い尽くしたからなのか
- リソース制限に到達したからなのか
- 他に原因があるのか
- 見極めるのが難しい
- デバイスに開発ツールが付属してない
- リモートでアクセスできるツールがない
- html5ベースのアプリ開発してるときに知りたかった（が手の届かなかった情報
- ヒープサイズ
- オブジェクトの数
- GCのサイクル
- GPUバッファのサイズ
- リソースの制限
- こういう情報は開発を終えた後でも有益な情報なはず
- 例えば。linkedin
- リソース制限（＝メモリに載せれる画像の量）をチェックするために、ハックしてしのいでる
- LinkedIn for iPad: 5 techniques for smooth infinite scrolling in HTML5 | LinkedIn Engineering
- (補足）
- ネイティブのAPI（ UITableViewController、 UITableView、 UITableViewCells）で享受できる高いパフォーマンスやメモリ効率の良さ
- これをhtml5ベースのipadアプリでどうやって手にするか
- linkedinのipadアプリの目玉UIのinfinity swipeの実装に施したハックの数々
- スクリーンの外にある要素に対して、スクリーンに近い順に、画像置換（src値のreplace）、隣のページへdisplay:none、さらに横のページにはページをremove
- 「display:none」とsrc置換の２つでクラッシュするケースの８割は解決できた
- 小技としてimgにwidth/height指定してauto-scale発動回避とか、css box-shadow禁止とか
- 没案として、UIWebVeiw複数使ったらダメだったとか
- linkedinはそうやってアプリのクラッシュを回避してると記してる
- (補足）
- デバイスのメモリリソース情報についてアクセスできるAPIがあった方がいい
- 認証必須だとしてもAPIがあった方がいい
- fps
- ハードウェレベルでのfpsが測定できない
- これはアプリのテストに致命的
- ACTION-27: Fluidity of motion and consistency of framerates from Robert Shilston on 2012-08-13 (public-coremob@w3.org from August 2012)
- 例えばUIデザインでinfinite scrollingにするかpagenationにするか決めたい時とか
- fingerprintingの点で注意すべきなのは承知してる
スクロールのパフォーマンス
- このパフォーマンス上の問題についてはw3cのworking groupで議論始めてる
- これも重要な問題の１つ
- タイムラインを流れるnewsfeedで問題になる
- inifinite scrollingを使ったUI
- ユーザのスクロールに合わせてコンテンツを先読みしてコンテンツを継ぎ足してる
- どんどん継ぎ足してると、コンテンツの総量がとても大きくなる（画像、テキスト）
- 現時点の実装ではjsでスクロールを実装してる
- 他の実装では速度でない
- 他の実装では色々問題がある
- 実装でぶつかってる問題を箇条書きで
- 必要なものを箇条書きで
- スクロールは高速かつ滑らか
- ユーザのengagementには必須
- ユーザが読み込み済みコンテンツの下端に近づくと、定義済のイベントを発行され、ンテンツが先読みされ、位置が算出され、継ぎ足される
- 滑らかなスクロールを殺すことなく、スクロール中も新規に読み込まれたコンテンツが継ぎ足される
- i/o処理や計算をバックグラウンドで実行できること
- 滑らかなスクロールを殺さないため
- たくさんコンテンツがあっても滑らかなスクロールを維持できること
- 画像が沢山あっても維持できること
- こんなAPIが欲しい
- 現状ブラックボックス状態で、わずかなハックが使えるだけ
- エンジニアはハックに頼ってハードウェアアクセラレーションを使ってる状況
- David Walsh考案
- Force Hardware Acceleration in WebKit with translate3d
- GPUバッファのサイズはデバイスを消費してるコンテンツサイズに相対的？
- だとすればの話だが
- GPUの管理がブラウザに委ねられた状態が相当な間理にかなった形で続くことになる
- とはいえGPUにアクセスできるAPIを提供する点についてはpro/con色々ある話
その他足りないもの箇条書きで
- タッチイベントのトラッキングの精度向上。特にandroidで
- よりスムーズなアニメーション。常に重要
- キャッシュ性能の向上
- app cacheは実用レベルにない。使わないことにした
- MoPad: appcache-london
- （補足）
-
- FT labがホストになって2012.8.14開催されたmeetupのログ
- FT、Economist、facebook、google、Lanyrdなどモバイル用html5アプリ経験のあるエンジニアが参加
- 事例紹介し、オフラインのストレージ機能のハマった点、ハック、どこに使ってるかとかと共有
- ノウハウ共有から進んで、app cacheが本来持つべき機能(jsからキャッシュの更新・削除できるapi用意するetc.)、ダメなとこ（master entriesは元凶だ、etc.）、詰め切れてないとこ（キャッシュの適切なサイズについて「これくらいだろ？」という感覚が共有できてないetc.)
- w3cに整理整頓されたver.あり
- Meeting notes 14 August 2012 - Fixing Application Cache Community Group
-
- （補足２）mountain viewでも同じ趣旨のmeetupが2012.9.24に。twitter,MSも参加
Adam Langley「CRIME attackの件」
ImperialViolet 2012.9.21のエントリ
ImperialViolet - CRIME
CRIME attackについて
- 現時点での対応
- fxと若干違う対応してる点
- 今後のchromeでの対応プラン
をchromeチームのエンジニアがざっくり書いてる
spdy/4で完全対応なんだろうが、それまでのプランの具体的なところを知れてよかった
以下斜め読んだ内容
- 前から気になってた問題
- chromeチームが今回作ったパッチの話
- その前にspdyがヘッダを圧縮する仕組みをおさらい
- zlibのやってることは一言でいうと
- このリテラルバイトを出力
- xバイトに戻ってこいつ（=xバイト）からyバイトを複製
- 圧縮の仕組みの参考になる図を用意した
- 下線ついた文字列＝コピーされるテキスト
- 濃い青の下線部分
- ダイアグラムの中にオリジナルが存在するテキスト
- 灰色線の先にオリジナルのテキストの場所が指示されてる
- 薄い青の下線部分
- 辞書に用意されてる文字列にオリジナルを持つテキスト
- spdyでは共有テキストが定義されてる
- 共有テキストにはヘッダにあると予想される文字列が入ってる
- この共有テキストをzlibが利用する
- 辞書が圧縮のときに有効利用されてる
- CRIMEが光を当てた問題
- zlib使って保護された情報を解読していく手法の詳細はDuongとRizzoのプレゼンが詳しい
- ネットワークトラフィックを監視でき、自在にhttpリクエストを出せる
- この条件をクリアすれば攻撃者はCRIME attackを実行できる
- jsをページに仕込むとかして、ターゲットのセッションを読んで、解読とかできる
- CRIME attackの話を聞いた時のchromeチームの状況
- spdy/4に搭載する圧縮の仕組みを設計してる真っ最中
- この新搭載の圧縮の仕組自体はCRIME attackを回避できる仕組みでもあった
- プロダクトに同梱済みのspdy/2やspdy/3については色々やり残しがある状態
- CRIME attackへの対応
- chrome22以降でspdyのヘッダ圧縮を復活させたい
- ヘッダ圧縮というspdyの機能は捨てがたい
- 転送データ削減につながるから
- spdy/4はまだリリースできる段階にないのでシンプルな解決はできない
- chrome22,23では複雑なやり方で解決させるつもり
以上はあくまでざっくりした説明
- ここで説明したことに対応するコード、脆弱性のないzlibストリームを生成するコード
- クリーンなパッチではない
- spdy/4が準備できたら捨てる代物
- だが、ヘッダ圧縮を復活させれるのはメリット
- 縮小してるがダイアグラムの別のサンプルを載せた
Mike Belshe「SPDYの圧縮方式と攻撃ツールCRIMEの件」
2012.9.14 ietf-http-wgへのポスト
SPDY compression and CRIME attack from Mike Belshe on 2012-09-14 (ietf-http-wg@w3.org from July to September 2012)
- 2011年にSSL/TSLの脆弱性を突いた攻撃ツールをリリースしたJuliano RizzoとThai Duongのコンビ
- セッションハイジャックツールBEAST
- TLS1.0/SSL3.0で採用されてるAESを使ったcipher suiteの脆弱性を突く
- BEASTリリースの反響。TLS1.2へのアップグレード。cipher suiteはRC4へ移行、などなど
- RizzoとDuongのコンビが新作ツールCRIMEをリリース
- Buenos Aires開催予定のEkoparty security conferenceでお披露目予定
- SSL/TSL全てのver.に対して有効な攻撃手法。SPDYも当然有効に
- オプションの圧縮をオンにしてるSSL通信とSPDY通信が対象になる
- RizzoとDuongはyoutubeにデモ動画UPしてる
- CRIME vs startups - YouTube
- 「githubやdropboxもこんな風にセッションハイジャックできますよ」とやってる
- github/dropbox側の対応（＝サーバー側でSSL圧縮をオフにした）後に動画は公開されてる
以下斜め読んだ内容
- CRIMEの件
- という状況を踏まえて、spdyの中の人としてmikeは手短なサマリーをMLにポストしてる
- Fx/Chromeはパッチ適用済
- 最新版を使うユーザは脆弱性を気にしないで使える
- Fx/Chromeへのパッチの難点
- SPDYヘッダの圧縮率が低下してしまった
- 厳密なパフォーマンスの比較はやってないが
- http/2.0では現行のspdyとは異なる圧縮ライブラリを使ってもらいたい
- とはいえ開発コミュニティには影響それほどない
- 前々から圧縮ライブラリの変更は色々な理由で要望されてた話なので
- 今回の問題をざっくりと
- 次期圧縮方式についてはCRIME以前からエンジニアたちが取り組んでる
- 今回のCRIMEによる攻撃が効かないものもある
- 一例としてRobert Peonの実装
- 彼の実装はSPDY/4へ搭載を目指した次期圧縮方式
- Robertの仕事はCRIMEとは独立して進められたもの
- Robertによる実装はリリースできるところまで開発が進んでないが、色々と優れてる
-
- spdy/3よりも圧縮レベル面で向上
- CPU消費がより低く（つまり高速になる）
- メモリ消費も軽減
- CRIMEの攻撃が効かない
-
Drew Olanoff「Mark Zuckerberg曰く『html5に賭けるなんて大変な間違いをしてしまいました』」
- teccrunch 2012.9.11のエントリ
- San Franciscoで開催中のDisrupt 2012の一コマ
Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 | TechCrunch
ios向けにネイティブアプリをリリースした件について率直に書いてる
日本語版techcrunchの翻訳対象外になってる
以下斜め読んだ内容
- Mark Zukerbergがfacebookのモバイル戦略について色々言ってる
- ネイティブアプリじゃなく、html5に乗りかかりすぎだった過去
- html5偏重はモバイル戦略で犯した大きなミス
- html5にフォーカスしたこと自体が間違いだった
- Markが公にhtml5偏重＝間違いだと認めたのは初
- facebookの状況はネイティブアプリリリース後好転
- ネイティブアプリ投下後の反応
- mark曰く、フィードを読んだりポストしたりする数が倍になった
- mark曰く
- プロダクト開発の速度が今年前半は遅かった
- 後半はどんどんとってもクールなもの出せると思ってる
- 「とってもクールなもの」？
- おそらく、マネタイズ絡み
- facebookにとってモバイルは広告収入への鍵、ということが見えつつある
- Zuckerberg Says “On Mobile We Are Going To Make A Lot More Money Than On Desktop” | TechCrunch
- 使ってるツールに一蓮托生な状態から一気に方針転換することはとっても大変
- 去年FB CTOと僕ら（＝techcrunch）でモバイルの未来のことで話をした
- CTOとの話をネタに記事も書いた
- Facebook CTO Bret Taylor On HTML5, Mobile As The Future, And Yes, FriendFeed | TechCrunch
- 当時のCTOはBret Taylor
- facebookは相当html5に入れ込んでたのがわかる
- 参考にhtml5ゲームについてfacebookと話をしてるくだりを抜粋で再掲
- flashを捨て進化していく
- 今fabookでリリースされてるhtml5ゲーム
- かつてはflashがその役割を担ってた部分
- bretにこのへん突っ込んで聞いたら無難な答えくれた
- bret曰く
- flashを捨て進化してくことは大変。今曲がり角の時期に来てる
- flash->html5への移行で色々ギャップ出てきてる。できる限りそれを潰していく
- bretは、未来の主戦場はモバイルと認識してる
- モバイル環境に乗り込んでいき、いろんな問題にぶつかってる
- bret曰く、モバイルのユーザ規模は今後は変わる
- 今支配的なデバイスが未来永劫支配的とは限らない
- bretは明言しないがそう考えてる
- 現在支配的な地位にあるデバイスが別のデバイスに取って代わる。これが実際に起きたとする
- facebookが大量のリソースを今一番使われてるデバイスに注ぐべきか
- むしろfacebookはhtml5にリソースを注ぐのが楽な道じゃないのか？
- html5というか、今後登場してくるたくさんのデバイスで良い感じに動いてくれるような何か
- （補足）
- モバイルデバイスの世界は変化が激しい
- Bretもそう感じてた
- ネイティブアプリを作ってデバイスの力をより搾り出せる
- アップルのような大企業はいつも力説してるところ
- 動画（３０分くらいある）
- あとでかく
