Category Archives: 和訳

和訳

chromiumのプロセスモデル

chromeのブラウザであるchromium(safariとWebKitみたいな関係?)についてのProcess Models (Chromium Developer Documentation)を要約しつつ和訳したものです。

originの違いでプロセスを別にする、というところがおもしろかったです。同じoriginなら、何か重大な欠陥があってプロセス上のメモリを読み出されても問題ないということか。

Overview

Webのコンテンツは膨大な動的コードを含むようになって、よりドキュメントというよりはアプリケーションになってきている。この変化によって、
ブラウザは単なるドキュメントのレンダラではなく、OSの役割を果たすようになってきた。chromniumはOSがやっているように、サイトやブラウザを複数のOSのプロセスを使って隔離しています。ウェブアプリケーションを安全で堅牢に実行するためOSのように作られています。
その結果、アドレス空間が別になり、OSによってスケジュールされるようになるので、ひとつに問題が出てもほかに影響しません。ユーザはchromiumのTask Managerで各プロセスのリソース使用量をチェックできます。

Supported models

ブラウザをOSのプロセスにどう分割するかを決めるモデルを4つサポートしている。
各モデルは、コンテンツのoriginに応じてどうプロセスを分割するかが異なる。

Process-per-site-instance

デフォルト。
サイトごとに違うレンダリングプロセスを作る。新しく同じサイトを開いたら別のプロセスを割り当てる。
ひとつのサイトとして認識する範囲はSame Origin Policyの範囲。ただしTLDが同じなら同じものとみなす。これはjsでdocument.domainを変更して互いにアクセスできるようにするため。

Strengths
異なるサイトのコンテンツを分離できる
同じサイトでもタブが違えば分離できる(同じサイトの片方が落ちても片方は生き残る)

Weaknesses
メモリオーバーヘッドが大きい レンダリングプロセスがたくさん生成される
windowを経由したりする一部のjs呼び出しにIPCが必要

Process-per-site

同じサイトは全部ひとつのプロセスで実行する。 –process-per-site

Strengths
異なるサイトのコンテンツを分離できる
Process-per-site-instanceと比べてメモリが節約できる

Weaknesses
ひとつのレンダリングプロセスが肥大化する google.comを扱うプロセスなど。ページのどれかが落ちたりリソースの競合が起きて全滅したときに困る。
windowを経由したりする一部のjs呼び出しにIPCが必要

Process-per-tab

process-per-site-instanceやprocess-per-siteがコンテンツのoriginを考慮するのと比較してシンプルなモデル。 –process-per-tab
ひとつのタブとそれこからスクリプトで開かれたタブをHTML5の”unit of related browsing contexts”として扱い、ひとつのレンダリングプロセスで処理する。
シリアライズなしでjavascriptを呼び出すことができる(訳注: スクリプトで開かれたページ同士はスクリプトを相互に参照することが多いことを想定してのモデルなのだろう)。

Strengths
理解しやすい。タブに割り当てられたプロセスはずっと変わらない。

Weaknesses
複数のページが望まない運命をともにすることになる。違うドメインのページを開いても同じプロセスに属する。

Single process

評価目的。 –single-process
FirefoxとかSafariの採用しているモデル。
multi-process architecturesで生じるオーバーヘッドの測定用。安全でないし脆弱。どれかのレンダラがクラッシュしたら全部落ちる。
テスト/開発用でほかのモデルにはないバグがある。

Sandboxes and plug-ins

各レンダリングエンジンはユーザのコンピュータへのアクセスが制限されたsandboxed process の中で実行される。
各レンダリングエンジンはファイルシステム、ディスプレイ、その他大半のリソースに直接アクセスできない。
セキュリティポリシーの適用を行うブラウザプロセス経由でアクセス権限を得ることができる。
結果としてレンダリングエンジンが悪用されても影響を小さくできる。

例外的に、Flashなどのプラグインはプラグインごとに、sandboxではないひとつのプロセスが作られる。つまり、それがどのタブに表示されるかにかかわらずflashは全部ひとつのプロセスで実行される。

Caveats

ベータリリースでは multi-process architectures の全部は実装されていない。
現在の実装の注意点と their implications.

  • リンクのクリック、フォームの送信がcross-siteでも、レンダラはじまりのナビゲーションではいまのところプロセスはスイッチしない。
    今はブラウザのlocation barやブックマークからcross-siteなのを呼び出したときだけスイッチする。
    process-per-site-instance, process-per-siteでもこういう動作(訳注: つまり現状Process-per-tabモデルに近い)。

    将来的に変わる予定。

    例外的にスクリプトでabout:blankを開いてからページをリダイレクトさせたときには新しくレンダリングプロセスが作られる。gmailが使っている手法。同じようにすればほかのサイトでも同じ動作をする。

  • frameもおなじレンダリングプロセスで実行される。でもcross-siteフレームはparentにアクセスできないので安全に実行できる。
    将来的に変わる予定。

  • 全体のプロセス数に制限がある。オニのようにプロセスを作らないようにするため。
    いまのところ大体のマシンではレンダリングプロセスを20までしかつくれない。搭載メモリ量によってはこれより少ない。
    結果としてひとつのレンダリングプロセスが複数のサイトに割り当てられることがある。割り当てられ方はランダム。
    将来的にはもっと賢いヒューリスティックな選び方になる予定。

ロケーションバーで検索したときは browser-initiated navigation だけどプロセスをスイッチしない。ひとつめのcaveatが原因。
頻繁に検索するprocess-per-site modelのユーザだと、大半のページがひとつのレンダリングプロセスで実行されることになる。

したがって、ロケーションバーの検索結果は、サーチエンジン専用のプロセスではなくて開いていたタブのプロセスで実行される。
結果としてひとつのサイトに複数のプロセスが割り当てられることがある。

次のバージョンではヒューリスティックを使うけど、ひとつめのcaveatが解決したら取り除く予定。

Implementation notes

さまざまなプロセスモデルをBrowsingInstanceとSiteInstanceというクラスで表現している。
BrowsingInstance はHTML5のbrowsing contextsと結び付けられたもの。
process-per-tab modelのときはBrowsingInstanceごとにレンダリングプロセスが作られる。

SiteInstance は同じサイトのページの集合を表す。BrowsingInstanceの中のページをさらに分割したもの。
重要な点として、ひとつのBrowsingInstance内ではひとつのサイトごとにひとつだけしかSiteInstanceが存在しない。
process-per-site-instance modelでは各SiteInstanceごとにレンダリングプロセスが作られる。

Would You Take a Tumblr With This Man? | The New York Observer のほんの一部和訳

Twitter / KEMONO: vimeoって美大っぽい、YouTubeは情報工学生のイメージ

を読んでTumblrでもそんなことがどこかに書いてあったなと思って探して見つけてきた Would You Take a Tumblr With This Man? | The New York Observer にあるDavidのインタビューの和訳です。

この記事、文体がいかにもインタビューなかんじですが、いくつかあるインタビューの中ではおもしろいので読んでもたぶん損しないです。いきなりガールフレンドを朝4時に叩き起こして飛行機に乗せてプエルトリコで5日間飲んだくれてたとかいうエピソードとか。

感謝! 2008.5.27

Tumblrにquoteされていたの経由で読んでくださった方に、英語がわからなかったところを教えていただいたので差し替えました(語尾など細かいところをほかの部分と同じになるよう変えています)。ありがとうございます。

追記 2008.5.29

Would You Take a Tumblr With This Man? | The New York Observer の全文和訳 – いいことあるかいにきれいな日本語の全文和訳がやってきました!

“はじめはほんとに自分のためだった” とMr. Karpは言った。

“まだ誰も持ってないtumblelogが欲しかった” TumblrはMr. Karpsの人柄を多くの点で反映している。
インターフェイスはとてもシンプルで、ちょっと技術的な素養のある人たちだけでなく、Tumblrというプラットホームを白い石盤に見立てて、コードを書いたり自分だけのものを作ったりするひとたちにも魅力的だ。Mr. Karpはどちらのタイプのユーザも歓迎している。

また、Tumblrのデザインは、ユーザが自分自身でやりたいことをやりはじめるようになっている。(訳注: わかりませんでした。Also implicit in Tumblr’s design is how it allows its users to use their own initiative to create the kind of experience they want. )またTumblrのデザインを見れば、どうやってユーザの独自性を発揮して各自が望むようなユーザエクスペリエンスを作成すればいいかは理解できる。

“DavidはAmazonの”これはなに?”ボタンが嫌いなんだ” とMr. Seibert(訳注: Davidが14歳のときに働いていたアニメ会社のプロディーサ)は言った。“彼は、なんでも理解できる人たちの小さなグループを選ぶほうだ”(訳注:よくわかんない。 He has self-selected to a small group of people who can figure everything out.)“彼はなんでも自発的に解決できる少数派のグループに属することを選んだ”

“今は、アーティストに狙いを定めてる”とMr. Karpは言った。”以前は学生や若者を考えてた。でも自分をオンラインで表現したい大人をターゲットにするほうが簡単だ。アーティストやプロディーサにはYouTubeがあってミュージシャンはMySpaceに追いやられている。あれはサイテーなプラットホームだ” Tumblrは無理なくフィットする。

繰り返すと、Tumblrを使うとおそらく世界で最も簡単に考えたことを共有することができる。
そしてまた、タンブラーの良さをすべての人々にわかってもらうのもすごく簡単だろう。

(訳注:最後のところわかんない。facebookでクソみたいなことを言ってると自分に降り掛かってきて後悔することになる?)
Then again, perhaps Tumblr makes sharing thoughts with the world almost too easy. “If every shitty thing you said ended up at the top of your Facebook profile,” Mr. Karp said, “you would probably reconsider it.”

Mr. Karpはこう言っている。”Facebookでうっかり間抜けな発言をするたびにそれが自分のプロフィールのトップに表示されるのを見たら、きっとFacebookを使うのはもう止めようかと考え直すよ”

Tumblr Inc. 21-year-old founder David Karp following in Steve Jobs’ footsteps の一部和訳

今年はじめのインタビュー記事Tumblr Inc. 21-year-old founder David Karp following in Steve Jobs’ footsteps (Tech Confidential – Behind The Money Blog)の一部を和訳しました。

英語はわからないし、日本語もモスバーガーなみだと言われるほどちゃんと書けないので、ニュアンスが汲み取れてないと思います。

Tech Confidential
批判的なひとたちは”Tumblrはテッキーがテッキーのために作ってる”って言っていますが、どうやってメインストリームに持っていくつもりですか?
David Karp
たしかにぼくたちはfirst-adopter集団にむけてTumblrを公開しましたが、ぼくたちははじめからメインストリームのプロダクトを作ることと、この tumblelogging というカタチをみんなにひろめることとにフォーカスしています。
TC
大きなマーケティングキャンペーンなしに、どうやって大勢のひとたちに届くようにするんですか?
Karp
ユーザがほんとうにハッピーでいられるようにします。
トラフィックの40%はリンクからきています。すごくTumblrを愛しているひとたち − Tumblrで最高におもしろいことをやってくれるアーティストやミュージシャン、そのほかのクリエイティブなひとたち - にフォーカスして、その人たちがやっていることを次のレベルに持っていく助けになれれば、そのひとたちがほかのひとたちを感動させることで磁場ができてTumblrにひとが集まります。

TC
なんでそれでうまくいくと思うんですか?
Karp
Appleは製品の”coolness”で人をひきつけることで、メインストリームでも広く受け入れられるようになりました。Apple製品を使って最高にかっこいいことをやっている、最高にかっこいい人たちをすごく大切にすることでそれをやったんです。

ほかのみんなはクリエイティブな人がAppleの製品を使ってやったことを見て羨ましくなります。自分のためにひとつ買わないわけにはいかなかった。僕たちはTumblrでそれをやりたい。

Firebug 1.2 ‘console’ implementation 和訳

Firebug – Web Development Evolved » Blog Archive » Firebug 1.2 ‘console’ implementationの和訳です。

実装はソースコードに書いてあるのそのまま(あたりまえ)。webページに書かれてある悪意あるコードを特権つきで実行しないようにするための細工だっていうことがわかったところが収穫でした。

Firebug 1.2 ‘console’ implementation

FF3betaでFirebugの1.1のコマンドが動かなくなりました。これを直すのがすごい難しくてコマンドラインとコンソールを作り直す必要がありました。はじめにコンソールについて書いて、次回コマンドラインの実装について書きます(訳注:けっきょく2008.5.16現在まだ書かれてないです)。

Firebugの’console’を使ってWeb開発者はテキストやオブジェクトをFirebugのコンソールパネルに出力することができます。新しいバージョンは emelement messaging を使っています。webページの要素を使ってFirebugに制御フローと値を渡す、っていう意味です。こんなかんじで動きます。

Webページがロードされてからはじめのjavascript関数が呼ばれたりする前に document.createElement() を使ってページにscriptタグを仕込みます。スクリプトは_firebugConsoleという見えないdiv要素とconsole関数を追加します。Webページの開発者が console.log("foo"); を呼ぶとlog()関数は

  1. "foo"という文字列をconsoleのユーザオブジェクトの配列に書き込みます。
  2. _firebugConsole要素のひとつの属性に"foo"オブジェクトのインデックスを書き込みます。
  3. _firebugConsole要素のfirebugAppendConsoleイベントをディスパッチします。

これらは全部標準のDOM操作です。

Firebug側ではfirebugAppendConsoleイベントリスナを_firebugConsole要素に追加しておきます。イベントがやってきたら、要素の属性を使ってユーザーオブジェクトにアクセスしてそれをFirebugのコンソールパネルに書き込みます。

FirebugはユーザーオブジェクトにアクセスすることでFirefoxのセキュリティラッパーテクノロジーを使って、おかしなウェブのコードがextension空間に入ってくるのを防いでいます。

いま(1.2a13)の実装にはもうひとつ間にレイヤがあります。consoleを定義するscriptタグはロードされるページ全部に入れられるわけではありません。かわりに小さな5行でできたwindow.consoleのgetterを定義します。getterはconsoleのコードをロードして、consoleオブジェクトがはじめて使われたときに_firebugConsole要素を作ります。

Mike Shaver, Mark Kahn, Justin Dolskeがこれを作るヒントをくれました。ありがとう。もしコンソールについてソースを見ようと思ったらこのへんになります。

Security check basics 和訳

Firefox3(Gecko1.9)の、いわゆる特権コンテキスト/非特権コンテキストを越えての不適切な関数呼び出しを防いだり、通常のクロスドメイン制約を実現するための仕組みであるSecurity check basics – MDCの和訳です。

MDCにはまだ日本語訳がないのですが(あったら訳さないんだからあたりまえだ)、アカウントをとって勝手に入れちゃってもいいんでしょうか。

Security check basics

このドキュメントではGeckoのセキュリティモデルの基本的概念を概略を示します。

Basic Definitions

GeckoセキュリティモデルはAOCできるか?という形式の問い合わせに答えるかたちで設計されています。
この問い合わせに答えるには、動作を行う実体(Aはactorを意味しています)、実行される動作(Vはverbを意味しています)、実行される動作の対象(Oはobjectを意味しています)についての情報が必要です。

Geckoには、プロパティXを取得するプロパティXを設定する関数Fを呼ぶ、といった限定されたverbがあります。

actorとobjectのふたつはprincipalで表されます。

Principals

principalはセキュリティのコンテキストを表します。ウェブ上での典型的なprincipalはスキーマ+ホスト+ポートの組み合わせです。

AがOにVできるか?を問い合わせるとき、A(actionを実行する実体)をsubject principalと呼びます。O(動作を行われる対象)はobject principalと呼ばれます。

Scripted and native JavaScript functions

JavaScriptには2種類の関数があります。

ひとつめは、単純にCの関数のポインタを保持していて、呼び出されるとthisオブジェクトや引数などをCの関数に渡して呼び出します。ネイティブ関数の例としてArray.sortがあります。関数が呼ばれると、Cのソート関数を呼び出してsort()が呼ばれたArrayオブジェクトを渡します。
ふたつめは、”scripted” functionと呼ばれるものです。JavaScriptのfunctionキーワードや、適切なJSAPI呼び出しで生成されます。これらの関数が呼ばれたときはJavaScriptインタプリタでJavaScriptのコードが実行されます。

セキュリティ上の二種類の関数の違いは、scripted functionはprincipalがコンパイルされて関数に埋め込まれているところです。scripted functionはその関数を定義したスクリプトが実行されたページのprincipalを保持しています。

Determining the subject principal

セキュリティチェックの実行を要求されると、セキュリティマネージャは現在のsubject principal(actorがセキュリティチェックされる動作を行おうとしている)を決定する必要があります。Gecko1.9のセキュリティマネージャはXPConnectにXPConnectが管理しているスタックから”current JSContext”を得るように要求します。このJSContextは実行中のスクリプトが使っているコールスタックへのポインタを持っています。

  • スタック上にJavaScriptがないときは、subject principalは”system”(全能のprincipal)になります。
  • スタック上にJavaScriptがあるときは、スタックを上から下にscripted functionが出てくるまで辿ります。scripted functionには必ず関連づけられたprincipalが存在します(scripted functionを作るときには、誰が作ろうとしているかを伝えないといけません)。それがsubject principalになります。

Determining the object principal

GeckoがあるJavaScriptオブジェクトのprincipalを決めるには、そのオブジェクトからそのオブジェクト自身のprincipalを知っているオブジェクトまで__parent__チェインを辿っていきます(たいていはWindowDocumentです)。それが問い合わせされたオブジェクトのobject principalとして使われます。

XPConnect wrappers – MDC てきとう和訳

どこかでXPCSafeJSObjectWrapperというのを目にして、なんだそれと思ってしらべたらFirefox3からXPCCrossOriginWrapperというのもできたとXPConnect wrappers – MDCに書いてあったのでてきとうな和訳をしました。そういうのがあるっていうのはわかったけど、どこで使われてるのか、どう使うのか、さっぱりわかりません。XPCCrossOriginWrapperはソース検索しても実装とテスト以外出てこないし。

Base Wrappers

XPCWrappedNative

C++実装のオブジェクトをjsに反映reflectするときに生成されるもの。
DOMオブジェクト(windowとか)やchrome要素がこれ。

jsからの呼び出しをC++にマッピングをやってくれる。window.focus()を呼ぶとXPCWrappedNativeのコードを呼んでいることになる。

このラッパはimplicitにXPConnectが生成するので気にしなくていい。
XPCWrappedNative には何種類かあるけどここではとりあげない。

XPCWrappedJS

XPCWrappedNativeと逆のことをするラッパ。
js実装のオブジェクトをC++から呼び出すときに使われる。

XPConnectによって生成されるので気にしなくていい。

Wrapper Wrappers

ここから難しくなってくる。まえの二つはひとつのC++もしくはjsのオブジェクトをラップしてそれをreflectしてるだけだった(厳密には正しくない。下のdouble-wrappingをみてね)。
以下のラッパはほかのjsオブジェクトをラップして、いろんなことをやってくれる。

XPCNativeWrapper

このラッパは初めて作られたラッパーラッパだ。XPCNativeWrapperはXPCWrappedNativeをラップしてるだけで、そのほかのjsオブジェクトをラップしようとすると例外を投げる(このことについて詳しくはdouble-wrappingのところをみてね)。

XPCNativeWrappersはjsのdynamicismからユーザを保護するためにデザインされています。
例を挙げると、

someAnchor.href="http://www.mozilla.com"

っていうコードは、someAnchorが呼ばれたときに悪意あるコードを実行して、正しく動かないようにできます(超訳注: someAnchorのhrefにgetterを設定しておいて無効なhrefを返したりするとかする)。someAnchorがXPCNativeWrapperでラップされていればこれは起こりません。ラッパーは常にIDL(or convention in the case of DOM0 behavior)で定義されたオリジナルのアクションを実行するからです。

XPCNativeWrappersはchromeのjsやchromeのcomponentがcontent(less privileged)(超訳注: ふつうのブラウザのウインドウで表示されるページの中身。chromeからはwindow.contentでアクセスできるのでcontentとして表現されている)オブジェクトにアクセスするときはいつもimplicitに生成されます。They can also be created by using new XPCNativeWrapper(wrappedNative) を使うことで生成することもできます。IDLでは定義されていない”Expando”プロパティは、ラップされたオブジェクトによって作られて、ラッパを介しては見えません。

このトピックについて詳しくはXPCNativeWrapperSafely accessing content DOM from chromeをみてください。

XPCSafeJSObjectWrapper

New in Firefox 3
このラッパはXPCNativeWrapperのいくつかの問題に対処するために作られました。特に、extensionによってはネイティブで実装されていないcontentで定義されたオブジェクトに安全にアクセスしたいことがあります(超訳注: gmailの拡張やLDRの拡張のように、contentが定義する変数を呼び出せば楽に何かができる場合など)。XPCSJOWはchromeコードとのバッファとして機能します。

Note: あらかじめ定義された動作を持たない、どんな種類のオブジェクトもラップできるので、ここで保証されるのは信頼できないコードは信頼できないコンテキストでしか実行されないということだけです。In particular, the underlying object might act entirely differently from what is expected.(超訳注:わからん)

Safe JSObject wrappers はいくつかの状況ではimplicitに生成されます。全てのプロパティをラッパ越しにみることができます。

XPCCrossOriginWrapper

New in Firefox 3
cross origin wrapper(XOW)はサイト間のアクセスを仲介するために実装されました。このラッパはXPConnectによってimplicitに生成されます。XOWのコードの中ではすべてのアクセスがチェックされます。
コードを実行するときに同じオリジンのオブジェクトをラップするときは、ラッパはSafe JSObject wrapperとして働き、JSオブジェクトにできることならなんでもXOW経由ででもできます。
ラップしたオブジェクトがアクセスできないときは(超訳注:おそらくオリジンが違ってアクセスできないとき、という意味)XPCNativeWrapperのように働きます。つまり、サイトがAPIをオーバーライドしていてもIDLで動作が規定されているAPIにのみアクセス可能です。

で、どれつかったらいいの?

オーケー、ざっと見たところでコード書きたいよねー。どのラッパを使ったらいいかな。

Chrome Code (extensionとか)

XPCNativeWrapperをみてね。

もっとオブジェクトにアクセスしたいとかcontentがjsで定義したオブジェクトとかIDLにないものにアクセスしたいときはXPCSafeJSObjectWrappersを使いましょう。Firefox3からはXPCNativeWrapper.wrappedJSObjectからimplicitに得ることもできるし、明示的にnew XPCSafeJSObjectWrapper(object)って書いてももいいです。

Note, however, that I’m (mrbkap) looking into implicitly creating these wrappers in all relevant cases and removing the visible constructor.(超訳注:わからん) Firefox2以前だとcontentの定義したjsオブジェクトに安全にアクセスする方法はないです。

Content Code (a webpage)

いままでそうだったのとおなじように、contenのコードはラッパーとかラップとか気にしなくていいです。特にXOWができたのでブラウザが規定してるセキュリティ制約に従っていればラッパのことは気にしなくていいです。でもこれはセキュリティのことを無視していいとかXOWが安全ベルトだと思っていいってことじゃないよ。守ってくれはするけど事故につながることはやっぱりあるよ。

Details

double wrappingのことについて触れたので、それについてもう一度。dobule wrappingはXPCWrappedNativeが他のオブジェクトをラップしてるときのことで、つまりJSオブジェクトがIDLで宣言されているインターフェイス経由で渡されて、XPCWrappedJSが生成されて、javascriptに他のインターフェイス経由で返されたときのことだけど、APIの互換性を保つためにXPCWrappedNativeがXPCWrappedJSのまわりに作られますよ。

Time Rich or Time Poor? てきとう翻訳

diggにのっていた Jeremy LiewというAOL時代のNetscapeのえらいひとっぽいひとが書いてた Time Rich or Time Poor? というのが、日本でケータイvsPCみたいな話と似てるのかなーと思って訳してみました。

以下適当翻訳。

おおざっぱにいって、インターネットユーザは二つに分類できます。
Time Rich と Time Poor です。
このブログの読者の多くは Time Poor に入る方だと思いますが、インターネットユーザの大部分は Time Rich のカテゴリに入る方です。
もし新しくインターネットの会社をはじめるなら、誰があなたの観客なのかを知って、自分の経験や Time Poor なひとたちの経験(experience)によって間違った方向に誘導されないようにすることが大切です。

Time Poor

Time Poor なひとたちは、インターネットを何かするために使います。このひとたちはタスクに集中していて、貴重な時間を有効に使う助けになるサイトが好きです。このひとたちむけにつくられているサイトの例としては、検索エンジン、第一世代価格比較サイト(可能な限り素早く一番安いやつが見つけられる)、eコマース、感情に訴えるというよりは機能的な lead gen sites1、あとは自分にあったニュースをフィルターしてくれるたくさんの”サーシャルニュース”などです。

もし Time Poor なひとたちむけにサイトを作るなら、時間とクリック数を最小限にすることに集中しましょう。結果としてビジネスモデルはeコマース、CPC、lead generation が、取引がすぐできるという点でユーザとサイト両方に整合性が取れて、この種のサイトにぴったりです。何をするかによりますが、サブスクリプションで課金することもできるでしょう。

Time Rich

Time Rich なひとたちは、インターネットをひまつぶしに使うので、気がそらされたり、楽しませてくれるのを喜びます。ソーシャルネットワーク、特化型ソーシャルネットワーク、写真共有サイト、芸能関係、スポーツ関係、ソーシャルショッピングサイト(娯楽的ショッピング)2、新しいサイトを提案してくれるソーシャル発見サイト3、動画サイトやゲームサイトがよい例です。

Time Rich のひとたちむけにサイトを作るなら、探検のための選択肢を与えるのに集中しましょう。リンクの密度が最も重要です。つまり、リンクが増えればクリック数も増えます。自然と流れが止まるところすべてにリンクを提示して、あなたのサイトをクリックしつづけるようにしましょう。コミュニケーションとコミュニティを刺激しましょう。そうすればずっとサイトに参加し、戻ってきてくれます。ブックマークしないといけない理由を作って、新しいコンテンツと色あせないおきにいりを用意してひんぱんに戻ってきてもらえるようにしましょう。

CPCと同様にスポンサー広告、CPMを通して利益につなげるのが妥当です。なにか特徴があればサブスクリプションで課金することも可能でしょう。売る製品を自然なところに持って来れれば、eコマースもうまくいくでしょう。
でも、ユーザのためでなく自分の利益のために余計なページピューを必要とする失敗にはまらないようにしましょう。(たとえば、記事を複数のページにわけるとか、プロフィールの編集に余計なステップをつくるとか)ユーザはそのうちあなたのお遊びに気づくくらいには賢いでしょう。
Time Rich は洗練されてない、という意味ではありません。このひとたちはあなたの競合サイトを含めてインターネットで過ごすのに十分な時間があって、どれがベストなのかを知っています。

サイトを作るときには、観客が誰なのかを知り、ターゲットを明確にすれば、そのひとたちのニーズにあった機会を提供できるでしょう。

UPDATE: 新しくきてくれたひとへ。もしこのポストがすぎたったら、二番目に人気のあるポスト Three Ways to Build an Online Media Business to $50m in revenue もみてみてね。

1
なんかdiggみたいな、自己生成型を促すタイプのサイトを lead generation sites と呼んでいるようです
2
日本だとamazonアソシエイトとべったりくっついてるのはよくみかけるけど、そこから一歩広げてウェブにあるやつならなんでもクリップできるもの。stylehiveとか。楽しそうだけどいまいち便利感も自己顕示感も低い。日本だと楽天で事足りるのかも。
3
具体的になんなのか分かりませんでした。

よーするにインターネットを使う目的が something to done / just kill time かでいろいろかわるよねって話でした。

ケータイだとそもそも something to done で使うのが楽じゃないとか、10年前からPC使ってるようなユーザは、昔の something to done の部分が強いユーザしかインターネットを使ってなかった時代の感覚でいると思うとか、それくらいしか感想もなくてつまんなかったです。だれだdiggしたやつは。