TidBITS#894/27-Aug-07 TidBITS#894/27-Aug-07iPhone やその他の機器が私たちをより多くの場所でインターネットに接続してくれている一方、私たちは悪意あるデータ攻撃に自分自身をさらけ出しつつあるのだろうか？ Glenn Fleishman がサイドジャッキング (sidejacking) について語る。これは、ウェブのトラフィックが処理される方法にかかわる潜在的危険を含んだ弱点だが、それを避けるための最も簡単な解決法が実際には使われる見込みが少ないことの理由についても説明する。また今週号では、Adam が２台のマシンの間で手軽に共有ができるユーティリティの Teleport について検討するとともに、Typinator で使う TidBITS AutoCorrect Dictionary の改訂版が出たことをお知らせする。それから、重量が６トンもある無停電電源装置をデータセンターの最上階に設置するにはどうすればよいのか？ Glenn が私たちのインターネットホスト digital.forest が採用したトップダウンの解決策を紹介する。最後に、リリースのニュースとして、Microsoft Office 2004 11.3.7、iPhone 1.0.2、iMovie 7.0.1、それに iWeb 2.0.1 についてお伝えする。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Jeff Carlson <[email protected]>
訳： 羽鳥公士郎 <hatori@ousaan.com>
米国では、次の月曜日は Labor Day （労働者の日）の祝日だ。３連休でお祝いすることになる。その日、私たちは本誌の発行をお休みする。ただし、だからと言って私たちが労働をサボるわけではない。私たちはこの機会を利用して、TidBITS の基礎工事をするつもりだ。そしてもちろん、ニュースや興味をひく記事はこれまでどおり TidBITS のウェブサイトに掲載する。次号はその次の月曜日、9 月 10 日にお届けする予定だ。ではそのときまで、ごきげんよう。
文： Jeff Carlson <[email protected]>
訳： 羽鳥公士郎 <hatori@ousaan.com>
Apple は最近、iPhone と２つの iLife '08 アプリケーションをアップデートし、詳細がほとんど明らかにされていないバグを修正した。iPhone 1.0.2は、「バグを修正する」という以外には何が変わったのか詳細がまったく明らかになっておらず、すべての iPhone アップデートと同様に iTunes 経由でのみ入手可能だ。iMovie 7.0.1 は、Software Update 経由でもスタンドアロンのダウンロードでも入手でき、明らかにされていない修正がなされただけでなく、ムービーを .Mac ウェブギャラリーに公開するさいの問題が解決された。アップデータは 9 MB のダウンロードだ。ウェブサイトの公開といえば、iWeb 2.0.1（12 MB のダウンロード）は、iWeb 1.x で作成されたサイトをアップグレードしたり公開したりするさいの問題を解決する。
文： Jeff Carlson <[email protected]>
訳： 亀岡孝仁 <takkameoka@bellsouth.net>
iPhone の所有者は先週電話会社の AT&T からテキストメッセージを通じてちょっとばかり良い知らせを受け取った："AT&T 無料メッセージ: 我々は紙の請求書から項目別の詳細リストを省いて簡素化を図ります。このお知らせの詳細については att.com/mywireless を訪れて欲しい。もし紙の詳細請求書が欲しければ 611 に電話して欲しい。"
先週、Jorg Brown が AT&T のデータ料金の常識を外れた明細書、その結果膨大な紙の請求書となってしまった結末について書いた ("iPhone 請求書と海外での問題" 2007-08-20 参照)。この事態は一人の女性が YouTube に彼女が受け取った 300ページに及ぶ請求書 (これを送るのに AT&T は $10 払っている) のビデオを出したことから報道陣の注目を集める事となった。
先週時点での AT&T の解は、iPhone 所有者は電子請求書も選択できることを知らせることであった。明らかに、現実に直面したらしく、今や紙の詳細請求書はオプション事項となった。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
私たちの間違いに今週最大の指摘をしてくれた私たちの友人 Ned Holbrook に感謝したい。先週号の記事“C4 カンファレンスに MacHack を想う”(2007-08-20) で、私は Erlang のことを「新しい」プログラミング言語だと書いてしまったが、実際にはそうではなくて、オープンソースとして 1998 年にリリースされたのだが、最近になってより注目を浴びるようになってきたものだった。Erlang は最初は 1987 年ごろに Ericsson で使われ始めたので、そこから数えれば今年で 20 歳くらいという計算になる。「ついでに、」と Ned は付け加えてくれた。「これを喜んでもらえるなら、ビデオ“Erlang: The Movie”もきっと楽しんでもらえると思う。」それから、YouTube が関連ビデオと称して挙げている“Erlang Quan: Basic Applications”というマーシャルアーツのビデオも見逃せない。あとは、前者のビデオのオーディオだけ取り出して後者のビデオに同期させられたら、どんなに面白いかと思うけれど...
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Microsoft Office 2004 へのセキュリティアップデートをリリースしてから（2007-07-16 の記事“Microsoft Office 2004 11.3.6 がセキュリティ問題に対処”参照）ほんの一月しか経っていないというのに、Microsoft はまたセキュリティアップデートを出してきた。Microsoft Office 2004 for Mac 11.3.7 Update のリリースだ。この 8.5 MB のアップデートは、Microsoft AutoUpdate ユーティリティの中から直接インストールすることもできるが、アタッカーが「あなたのコンピュータのメモリを悪意あるコードで書き換える」ために利用できる可能性のある脆弱性を修正しているという。この 11.3.7 アップデートのためにはあらかじめ 11.3.6 へのアップデートを済ませていることが必要で、その 11.3.6 へのアップデートには 11.3.5 が必要となっている。Microsoft AutoUpdate ユーティリティを使えば、すべての力仕事をあなたに代わって済ませてくれる。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Apple が Mac OS 9 から Mac OS X への大きな跳躍を果たした時、人気を集めていたアプリケーションのうち多くのものが取り残された。全般的にその理由は、非常に古いコードを書き直すために必要となる労力がとにかく大き過ぎるということだった。私の場合、Classic 環境を私がそのために持ち続けていた最後のアプリケーションこそ、Nisus Software の Nisus Writer だった。私はこれでたくさんのマクロを書いて、それらのマクロは TidBITS の出版プロセスの中で鍵となる位置を占めていた。現在の TidBITS 出版プロセスは完全に別のシステムを使っているが、今回 Nisus が引き続き努力を持続してくれ、パワフルな Nisus Writer Pro を復活させてくれたのは素晴らしく喜ばしいことだ。 Nisus Writer Pro には属性対応の検索、マクロ、グロッサリ、目次機能、索引、ブックマーク、孤立行のコントロール、行番号、多言語テキスト対応、文字単位および段落単位のスタイル、不連続な選択、その他多数の機能がある。これまで Mac OS X には小型のワードプロセッサならば多数見られたが、プロフェッショナル向けの機能を揃えることを狙ったものと言えば Word 以外になかった。だから、Mac の世界で本格的なワードプロセッサの選択肢が広がりつつあるのはとても嬉しいことだと思う。
今週の DealBITS 抽選では、Nisus Writer Pro 1.0 を３本、賞品にする。それぞれ定価 $79 相当の製品だ。幸運が足りずに当選から漏れた応募者にはもれなく Nisus Writer Pro の割引価格の資格が得られるので、ぜひ奮って DealBITS ページで応募して頂きたい。寄せられた情報のすべてはTidBITS の包括的プライバシー規約 の下で扱われる。どうかご自分のスパムフィルターや challenge-response システムに注意されたい。当選したかどうかをお知らせする私のアドレスからのメールを、あなたに受け取って頂くのだから。また、もしもあなたがこの抽選を紹介して下さった方が当選すれば、紹介に対するお礼としてあなたの手にも同じ賞品が届くことになるのもお忘れなく。
［訳注： 応募期間は 11:59 PM PDT, 02-Sep-2007 まで、つまり日本時間で 9 月 3 日（月曜日）の午後 4 時頃までとなっています。］
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
ここのところてんやわんやの忙しさだ。客人も多かったし、シカゴでの C4 カンファレンスに行ったり、Tonya と Tristan が休暇旅行に出かけたり、しなければならないことも山ほどあったからだ。この忙しさでは、旅行の前に私の MacBook の準備を整える（基本的には Eudora フォルダをコピーして、デスクトップ Mac ではなくラップトップ機で電子メールが読めるようにすることが主だったが）暇もなくなるかもしれないと思い至ったので、出発の数日前にそれをちゃんと済ませておいた。旅行から帰ってからも私は引き続き忙しかったし、また家の外で MacBook を使わなければならないことも何度かあったので、まだ電子メールを私の G5 に戻すことにまで手が回らないでいる。（もちろん私は IMAP を使ってメールをピックアップすればわざわざ Eudora フォルダをあちこち動き回らせる必要もないことは知っているが、私が保管している電子メールの量は膨大だし、私の生活に占める電子メールの意味は重要なので、まだ POP 以外のものに乗り換えることを試みる気には一度もなれないでいる。）
普段私は２台のコンピュータで仕事をするのは面倒なことだと思っている。電子メールこそが、今でも私が外の世界とコミュニケーションをするための第一の方法だからだ。でも私は文章を書いたり、ウェブを使ったり、ソフトウェアをテストしたりするには２台の 17 インチスクリーンを備えた G5 を使う方が一般的に好みだ。他のコンピュータとの間でファイルやクリップボードのデータなどを移動させたりするのはファイル共有や遠隔コントロールのソフトウェアをもってしてもやはり面倒以外の何物でもなく、違ったキーボードやポインティング機器を使えば私の思考の流れが途切れてしまう。けれどもここ数週間に限っては、私はある素晴らしく賢くて便利なフリーウェアを使ったお陰で、そうした問題のすべてをシンプルかつエレガントに解決することができた。
Abyssoft の Julien Robert の書いた Teleport は、複数の Mac がネットワーク上で一台のキーボードとマウスを共有できるようにするソフトウェアだ。私は仕事机の上で MacBook を私の G5 のキーボードの正面に置き、G5 のスクリーンはその上の棚の上に置いている。カーソルを G5 から MacBook へと動かしたい時には、Control キーを押し下げたままでカーソルを G5 のメインスクリーンの下の縁に放り込む。すると（Wi-Fi 経由でさえも）余分の時間をかけることなく Teleport は MacBook のコントロールを私の G5 のキーボードとポインティング機器（Contour Designs RollerMouse Pro）へと移行させ、カーソルは MacBook のスクリーンの上の縁から現われる。その後は、G5 のキーボードや RollerMouse で何かをすると、それは G5 でなく MacBook に向けた動作だと解される。MacBook をコントロールしている間は、G5 のメインスクリーンの表示が半透明の状態になって、コントロールが MacBook にあることを示している。キーボードとマウスを再び G5 に向け直すには、Control を押し下げたままでカーソルを MacBook のスクリーンの上の縁に放り込めば、カーソルが G5 のメインモニタの下の縁から飛び出す。
Teleport のインターフェイスは最小限のもので、手早く共有を開始したり止めたりするためのメニューバーアイコンがあるのと、あとはシステム環境設定のパネルで、それぞれの Mac のモニタの仮想上のレイアウトを設定したり、信用できるホストを（誰でも勝手にあなたの Mac を遠隔操作でコントロールできてしまっては困るので）指定したり、また、Mac 同士の切り替えや、ファイルやクリップボードデータの転送など、さまざまのオプションを設定したりできるようになっているだけだ。
その通り、Teleport はファイルの転送もできる。（カーソルを別のマシンへ移動させる際にファイルを一緒にドラッグすればよいだけだ。）また、カーソルの移動に伴って自動的にクリップボードのデータを転送するように指定するオプション設定もある。だから、例えば私に電子メールで添付ファイルが届いたとして、そのファイルを G5 機の方に置きたいと思えば、単にそれをスクリーンの上の縁へと Control-ドラッグしてから G5 のデスクトップにドロップすればよい。同様に、何かのテキストを MacBook 上の Eudora から G5 上の BBEdit に持って行きたい場合は、まずそれをコピーして、カーソルを移動させ、それからペーストするだけだ。シームレスとはこのことを言うのだろう。
その他の興味深い機能としては、すべてのデータストリームを暗号化する機能や、スリープしている Mac をコントロールしようとすると自動的にスリープから回復させる機能、クリップボード内容をいつ転送するかについてキーボードの修飾キーでコントロールする方法などもある。
ここ数週間かなり使い込んでみて、私は Teleport にいくつか問題点も見つけた。まず、最も使い易い仮想スクリーンの設定を見極めるには相当時間がかかる。私は当初スクリーンの切り替えにいちいち修飾キーを使わなければならないのは避けたいと思っていたが、そうするとどの側の縁で試してみても実用上の困難が伴ってしまった。今でさえも、MacBook をコントロールする際には、メニューを使おうとした際にもしもメニューバー最上部のピクセルでクリックすれば、何かの理由でただ現在のウィンドウがフォーカスを失ってしまうだけ、メニューは下りて来ない。（Julien によればこれは既知の問題点で、ファイルをドラッグ＆ドロップできるようにすることに関係しているということだ。）一度か二度、私が MacBook をコントロールしている最中に Teleport が反応しなくなったこともあった。その時は、まず MacBook をスリープさせて G5 のコントロールを復活させ、それから MacBook をスリープから起こすという手間が必要だった。また、クリップボードの内容そのものは一つの Mac から別の Mac へと移ってくれるのだが、クリップボードのデータがどんな種類のものかを示すある種のクリップボードのメタデータは移ってくれていないように思える。これは、一つのマシンでコピーしたスタイル付きテキストを別のマシンにペーストすると時によって奇妙なことが起こることから分かる。ひょっとして、これは PowerPC ベースの Mac から Intel ベースの Mac へデータを移そうとしていることに関係しているのかもしれない。この点については、近々新しいバージョンでテストして確認してみたいと思う。以上述べたような問題点は、いずれもちょっとした時折の不便という程度に過ぎず、重大なトラブルを引き起こすようなことはなかった。
Julien は Teleport を Abyssoft という名前の下に出版しているが、彼はここ三年半ほど Apple 社で働いている。そのことが彼が Teleport に注ぐ開発作業を遅らせることはあるかもしれないが、これまで彼の開発作業が止まってしまったことはなかったし、Julien は現在 Leopard 対応版の開発の最中でもある。現状をまとめれば、Teleport は現在 Panther と Tiger で動作し、価格は無料で、複数台の Mac で手早く作業したい人ならば誰でも非常に便利に使える。ダウンロードサイズは 523K だ。
文： Glenn Fleishman <[email protected]>
訳： 亀岡孝仁 <takkameoka@bellsouth.net>
インターネットは光のビームと電気だけの世界だとお思いだといけないので、この写真付の話からインターネットは一方で重機 (そして電気) が満ち溢れている所でもあることを思い直してほしい。
我々の長年に及ぶコロケーション施設であるdigital.forest - 我々のサーバーを収納し、電力と冷却とそして接続を供給してくれる人達 - が、そのバックアップ電源の増強を必要とする事態となった。私がよく見たことがある無停電電源装置というものは靴箱かそれよりちょっと大きいぐらいのものであった。それにはバッテリか時としてフライホイールが含まれていて、必要に応じて電力を供給し続けるというものである。
UPS は、供給電力のスパイクや低下をそぎ落として、いつもきれいであるようにするコンディショニングプロセスの一部をも担っている。私が持っていたことのある一番大きいやつは、約 1,400 ワットを供給でき、万が一電力が低下したり切れたりした時に、数台のサーバーを数十分間は走らせられるものであった；その重さは 40 から 50 ポンド程度であった。(digital.forest で、UPS ユニットをバックアップするのはタンク数台程のディーゼル発電機で、バッテリー電力が尽きる前に動き始める。)
digital.forest の新しい複数のユニットからなる UPS システムは、全部で 11,500 ポンド、ほぼ 6 トンに近い重さがあり、180,000 ワットの電力を供給できる。この大きさと重さを考えた時、同社のスタッフはまず実物大の木枠モデル を作ってデータセンタ内で移動時のクリアランスが取れるかどうかの検証をしてみることとなった。次に、世界で最も大きいデータセンタ建設者でもある建物の所有者に諮っているうちに、寸法的にはビル内を滑らせて運ぶことは可能であるが、その通り道のうちこれだけの点荷重に床が耐えられるよう設計されているかどうか確認できない部分があることが分った。
それなら、いっそのこと屋根をぶち抜いてしまえば良いではないか？(実は、これが最近 Seattle の近くの Apple Store に押し入った泥棒も考えた方法なのである。) They Might Be Giants を引用させて貰えば、"クレーンが要るよ、クレーンが要るよ。" 屋根を一部分引き剥がし、新しいカバー、フォークリフト 2台、それにクレーン、そうすれば UPS はきちんとその場所に収まるさ。
とかくすると、インターネットはデータの神秘的なビットだけではなく、沢山の原子にも依存していることを忘れがちである。
文： Adam C. Engst <[email protected]>
訳： 亀岡孝仁 <takkameoka@bellsouth.net>
Ergonis Software がミスタイプを即座に修正し _かつ_ 誤り語とその修正語のテキストファイルをインポートできる ("Typinator が 2.0 に" 2007-06-11 参照) Typinator 2.0 をリリースした時、私は即座に TidBITS AutoCorrect Dictionary の事を思った。これは巨大な公共ドメインのリストで間違って綴られた言葉とそれの正しい候補語を収納したもので、我々が Eudora の隠れた自動修正機能 ("ATypoKill Eudora ハック" 2000-09-04 参照) を活用したいという Eudora ユーザーのために用意したものである。この辞書の、大部分は Micah Alpern によって作られた、お陰で私のメールメッセージは大幅に速くなりそして書きやすくなった、というのも私はメッセージの中の誤りは直さずにはいられない類の人間だからである。それ程しつこくないという人にとっても、これを使う事で疑いなくメッセージがより正しく書かれる様になる。
そこで私は即座に TidBITS AutoCorrect Dictionary のコピーを掴み、フォーマットは Typinator がインポート出来るものである事を確認したうえで、取り込んだ。インポートは正しく行われた様に見え、Typinator は直ちに私の全てのアプリケーションでより多くのスペルミスを修正し始めたのだが、どうも何かがうまくいっていない様であった。分かったことは、Typinator はある種の単語当りの設定を持っておりそれがその展開がどうなされるべきかの制御をつかさどっているという事であった。具体的にいうと、Typinator は間違い語のケース（大文字か小文字か）に応じて置換語のケースを変更出来るのだが、私のインポートした単語に対して設定されていたデフォルトが多くの場合正しくなかった。Ergonis ならこれらを短時間で直せる魔法のツールを持っているのではないかと想像して、私はその単語のリストを Christoph Reichenberger に送って、全ての単語を簡単にリセット出来ないか頼んでみた。更に、我々と Micah は TidBITS AutoCorrect Dictionary を意図的に公共ドメインに置いているので、E rgonis も - 他の皆と同じ様に - その修正リストを公表するのを歓迎する旨のノートも添えておいた。
言うまでもないと思うが、Christoph はこの 2,300 を超えるミスタイプ語とその訂正語を Typinator に加えるチャンスに飛びついてくれて、数日後には、私の手元には Typinator フォーマット化した私の単語リストが返ってきた。それ以降ずっと使い続けているが、かなりの確信を持って言えるのは、私の使うアプリケーション全てで自動補正機能を持つことになった今では、Typinator の手助けがなくなればひどく悲しむであろうということである。Typinator がミススペルを直す度に点滅しそして音が出るので、私の指がどれほど頻繁に外れてしまうのかが明々白々となってしまった。
もしあなたが現在 Typinator 2.0 を使っているのであれば、無料の download the free TidBITS AutoCorrect Dictionary for Typinator をダウンロードすることを強くお勧めする。もしまだ使っていないのであれば、Christoph は、我々が Ergonis にこの辞書を配布することを許可したお礼として TidBITS ユーザーに対する特別割引を設定してくれた。31-Aug-07 迄の期間限定でこの特別リンクを通して通常であれば 19.99 ユーロに対して 25% の割引が得られる。
文： Glenn Fleishman <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
サイドジャッキング (sidejacking) という言葉が、ネットワーク攻撃の用語集に新たな一項目として加わった。この新しい用語は、現在進行中のウェブセッションであって例えば Gmail のようなリモートサービスを伴ったものを乗っ取ってしまう一つの方法のことで、そこでは、あなたの本人確認をそのサーバに提供する信用証明書を傍受して、それを再利用するという手段をとるのだ。サイドジャックする者には、あなたの Gmail アカウントから電子メールを読み書きしたり、あなたの MySpace ページをアップデートしたりもできてしまうし、また潜在的可能性としてはあなたの人物確認情報を盗み出してあなたの友人たちや同僚たちにあなたが邪悪な、狂気の、あるいは犯罪的な人物だと信じ込ませることさえあり得る。そして、それは単に入り口に過ぎないのだ。
そういう信用証明書は暗号クラッキングツールのようなものを使わずに読み取れてしまうし、多くの場合たとえあなたがセキュアな方法でサイトにログインしていても傍受できてしまう。サイドジャッキングのためにはクラッカーがあなたのコンピュータに遠隔アクセスを得る必要もないし、セッション情報がサイドジャックされたとしても必ずしもそれがあなたのコンピュータの脆弱性が増したことを意味するのでもない。サイドジャッキングに対する防御のためには、ウェブサイトのオペレータ、ユーザー、それにブラウザのメーカーの三者すべてが物事を考え直す必要があるのかもしれない。
Robert Graham は Errata Security 社 の最高責任者の一人だが、今月初めの Black Hat セキュリティカンファレンスで彼の研究を発表し、その後間もなく実証目的のプログラム Hamster をリリースした。発表の場で彼は、単なる出来合いのデモを見せるのではなく、その部屋の内部にあるライブのセッションを使ってサイドジャックを実演してみせ、大喝采を浴びた。彼は観客席の中の一人の Gmail セッションを乗っ取って、その人のアカウントから“I like sheep”という電子メールメッセージを送信してみせた。（ちなみに Errata 社のもう一人の最高責任者は David Maynor だ。）
(日本語)無線ドライバハックは Mac と Windows を標的にするか | Apple、注意深く Wi-Fi 脆弱性を否定 | AirPort アップデートが Wi-Fi 攻撃を防止 | もう一つのマイナーな AirPort 脆弱性が暴かれる | セキュリティホールが２つ閉じられ、１つ開く | モアブはわたしのたらい
サイドジャッキングは、ブラウザとサーバの間にある小さな割れ目に差し込まれたかなてこのようなもので、クラッカーはこれをこじ開けることで錠前を外してしまう。クラッカーは必ずしもあなたのインターネット自動車を盗んで走り去る訳ではないが、ただ一切の痕跡を残さずにあなたの登録情報をわし掴みにして逃げて行くのだ。
Graham のプレゼンテーションは、この種の介入者攻撃に関して従来語られて来なかった新しい事実を暴露した訳ではないものの、彼はその攻撃の及びうる範囲を実演によって示すとともに、その手順を自動化できるツールも提供した。彼は、これまでその重大性が正しく認識されていなかった既知の問題を、緊急に対処する必要のある深刻な責任問題であるという位置付けに変えたのだ。
あなたの名前とパスワードを述べなさい -- サイドジャッキングが働くのは、ほとんどのウェブベースのサービスにおいて、あなたが認証情報（通常はログイン名またはアカウント名にパスワードを対にしたもの）を提供する段階に適用されるセキュリティのレベルと、その後あなたがログインした状態で引き続くセッションに適用されるセキュリティのレベルとの間に不一致があるからだ。
これは、家庭内のネットワークならば問題とはならない。傍受されるリスクは低いか皆無のこともあるし、あなたのコンピュータとリモートサーバとの間でデータが横取りされてしまう可能性は、政府が相手である場合を除けば無視できる程度に小さいだろう。でも、公共の Wi-Fi ネットワークを使う場合、特に iPhone のようなハンドヘルド機を使っている場合には、開いた Wi-Fi ネットワーク上で誰かがあなたのデータ送受信をモニターしている可能性は非常に高くなるだろう。
ウェブメールやその他のサービスの多くでは、あなたがログインする際に SSL/TLS (Secure Sockets Layer/Transport Layer Security) で保護されたセッションを通じてすることを要求ないし許容するようになっている。SSL/TLS は、なかなか巧みなダンスを演じてみせて、あなたのブラウザと、反対側の端にあるサーバとの間で暗号化された接続ができていることを保証する。（SSL/TLS の動作のしかたについてもっと詳しくは、Chris Pepper の徹底的な解説記事“SSL/TLS でセキュアなコミュニケーション： ハイレベル概観” (2007-06-25) を参照。）
すべてのサービスで暗号化されたログインが要求されている訳ではないが、私は皆さんに必ずそのようなログインを使うよう努めることを強くお勧めしたい。そのログインが SSL/TLS を使っているかどうかは、２つのことを見れば分かる。１つはその場所を示す URL が“http”でなく“https”で始まること、もう１つは南京錠アイコンが表示されることだ。いくつかのサイトでは、サイトのデザインの一部として、よくログインウィンドウの近くやナビゲーションバーの中などに南京錠を表示していることがある。そういうものは、何にも意味していない。もしも適切に SSL/TLS 接続が確立していれば、あなたのブラウザがページ領域の外部に南京錠アイコンを表示するはずだ。Safari では、南京錠はウィンドウの右上端にある。（ちょっと見え方は微妙だ。）Firefox では、Location フィールド（右の方、でもフィールド内）と、ウィンドウの右下端の両方に現われる。
（セキュアなログインを提供しているサイトのうちいくつかは、愚かにも通常のウェブページを提示してそこにあなたのデータを入力させ、あなたがログインボタンを押した時になって初めてデータをセキュアなページに送るようにしている。このようにするのは、そのログインが Wi-Fi ホットスポットで乗っ取られるのを助長しているようなものだ。クラッカーに偽物のログインページを表示できる機会を与えているからだ。いくつものテクニックがあって、ろくでなし連中が偽物のホットスポットを設定したり、あるいは本物のホットスポットの中で情報をいじり回したりすることで、バンキングあるいは e-コマースのよくあるサイトのふりができてしまう。ブラウザに認証書の問題点について警告を出させることなくセキュアなサイトのふりをすることは不可能だが、セキュアでない偽物のページを提示するならば、ユーザーを本物のログインページに導きつつその際にその人の信用証明書を横取りすることができる。）
さて、ここからが微妙なところで、これこそがサイドジャッキングが可能となる理由だ。いったんあなたがそのサービスに対して本人確認の証明を済ませ、あなたのアカウントの詳細が引き揚げられてしまうと、その後は何が起こるのだろうか? バンキングやその他のサイトのようにセッション全体を SSL/TLS でセキュアにしているところでなければ、そこから先はセキュアでないウェブセッションに投げ戻されてしまうかもしれない。ここからはすべて、トークンの問題だ。
トークンであなた自身を証明 -- ウェブはその本質上、一定の状態を持たない。つまり、あなたがどこかのウェブサイトでリンクをクリックして行った時、一つのアクションと次のアクションの間に何も内在的な結びつきはない。クッキーが、ある意味で状態と言えるものを提供する。ウェブサイトがあなたのブラウザにいくつかの情報断片を保存することを要求し、その情報断片がその後に引き続く個々のページ表示においてあなたが誰かを同定する。それは素早く次々に開くページかもしれないし、何日も後になってから開かれるページかもしれない。また、サイトの開発者が特別の種類のウェブパスワードを要求してそのパスワードを状態保持のために使うということもあり得る。ただ、この方法はあまり使われていない。その理由については後で触れる。
あなたがウェブサイトにログインする時、多くの場合次のようなことが順々に起こる：
あらかじめ決められた一定の時間が過ぎれば、トークンは期限切れとなる。多くの場合、別のページを見るなどの活動なしに 30 分程度が過ぎただけでそうなる。ウェブサーバがクッキーを期限切れとなるように設定していることもある。その場合は次にあなたがそのウェブサイトを訪れた時にあなたのブラウザがクッキーを送信せずに消去することになる。あるいは、サーバが自身のデータベースからそのトークンを消去して、あなたのブラウザから提供されたトークンを拒否するようになることもある。また、それら両方ともが起こることもある。
トークンは、IP アドレスと結び付けることで、ランダムにトークンを生成してアクセスを試みることを防止していることもある。ただし、一般にトークンは十分長いものなので、可能性は何百兆何千兆とあるだろう。
このトークンはそのままの形でやり取りされ、セッション中は一定期間ずっと一貫して使われる。そして、それこそがサイドジャッキングの運用方法たるものに結び付くのだ。正当なメンバーが現に使っているのと同じ認証情報を再生（再利用）する、という方法だ。
トークンが途中でクラックに結び付く -- Graham が実演したのは何だったかと言うと、これらのトークンが特定のブラウザについての個別の情報に結び付けられてはいないということだ。実際、それらを結び付けることはできない。だから、もしもあなたがオープンな Wi-Fi リンクを通じてこれらのトークンを傍受したら、たとえそれが有料の Wi-Fi ネットワークであろうと、知らないユーザーたちが共有するセキュリティ付きネットワークであろうと、あなたはそれらのトークンをそのサービスにおいて期待されているやり方で再生することができ、完璧に有効なセッションをウェブサイトで作り出すことができてしまう。
トークンを特定のブラウザやユーザーに対応させることができない理由は、クッキー、その中に含まれた情報、ブラウザ、その環境、といったものたち同士の間に実際的な結び付きが存在していないからだ。そのクッキーが特定の IP アドレスから来たことをチェックしても意味がない。なぜなら、多くのサービスプロバイダではすべての外向きリクエストをプロキシサーバあるいは一つの IP アドレスにまとめてから送り出しているからだ。ブラウザの属性、例えば“user-agent”などは、簡単に偽装できてしまう。
もちろん、将来になればブラウザやサーバがセキュアでないセッションに対して何らかの形で暗号化されたクッキーを提供するようになる可能性もある。この対応付けも SSL/TLS によるかもしれないが、セッション全体を暗号化するのではなく、クッキーのみを保護するに過ぎない。そうすることで、計算量の負担を減らしつつセキュリティが向上させられるだろう。そうしたことを実現するためにはブラウザとサーバの両方ともにアップデートが必要となるだろうが、私はまだそのようなことが提議されるのを聞いたことがない。
セッションをサイドジャックするのがどの程度難しいのかを知るために、私は Graham が使った２つのソフトウェアパッケージ、Ferret と Hamster を起動させてみた。Ferret はしばらく前から出回っていた。Parallels Desktop の下で仮想の Windows XP マシンを使い、私は Ferret でデータのキャプチャを始めた。Gmail や他のいくつかのサイトを訪れてみた。それから私は Hamster に移った。Hamster はウェブプロキシとして挙動し、キャプチャされた情報を表示する。トークンを傍受したサイトのウェブアドレスを単純に入力することもでき、その場合 Hamster はそれらをクッキーとして扱う。すると、私はこの方法で至極簡単に私自身の Gmail アカウントにログインすることができた。
Ferret と Hamster を走らせるにはほんの少し Windows のコマンドラインの知識と、クッキーやプロキシが動作する方法へのちょっとした理解が必要だが、Graham にはこれらのツールを磨き上げられたアプリケーションとして作る意図は全くなかった。ただ、このプロセスを自動化するのがどれほど簡単かという実際に動作する例を示してみせたかっただけだ。
ここでの弱点は、ただそのままのテキストが、SSL/TLS で保護されていなければありのままの姿で送られてしまうということだ。では、どうしてこれらのサイトは SSL/TLS あるいは他の方法であなたを安全に保護してくれようとしないのだろうか？ その答をこれからお話ししよう。
サーバのロードとユーザ体験がセキュリティ低下に結び付く -- この記事の原稿の段階で、私は次のような質問を提示した。「トークンに依存しているウェブサイトは、すべてのページで SSL/TLS を使って保護すればよいだけなのに、どうしてそうしないのか？」と。例えば Google の Gmail は、これをオプションとして提供している。普通は gmail.com とタイプして http://mail.google.com/mail/ に振り向けられるのだが、その代わりに https://mail.google.com/mail/とタイプすれば一貫してセキュアな使用ができる。けれども Gmail のようなところは例外的であり、その Gmail でさえこれをデフォルトの選択肢として提供しているのではない。
ここ TidBITS での通例通り、私はこの原稿を経験深い Macintosh ライターやプロフェッショナル、情報テクノロジーのエキスパートたちのグループの中で回覧してもらい、意見を求めた。今回は具体的に、なぜもっと SSL/TLS が適用されないのか、と尋ねた。その答えはごく単純なものだった。コストだ。
私自身セキュアサーバを運営したことがあるので、私もそこにはいくつもの意味で余分の負荷がかかることを知っていた。まずバンド幅 (暗号化にはハンドシェイキングその他細部から来るビットが積み重なる)、次に待ち時間 (暗号化と復号化によってリンクの双方の端で時間を消費する)、それから計算量の負担 (暗号化がプロセッササイクルを食う) もある。
私が気付かなかったのは、そのために生ずるコストの増加が、例えば 20% とか 50% とかいう程度ではなくて、ウェブサイトを運営している人にとってはどんな規模でもコストの増加率が 1,000%（つまり 10 倍）あるいはそれ以上になるということだった。例えば TidBITS のような比較的小規模のところでは、これに加えてちょっぴり余分のコストもかかるだろう。つまり、平均的なユーザーの目からはセキュアにした私たちのページはセキュアでないものよりも少しロード時間が遅くなるかもしれないということだ。
けれども、もしもあなたが一時間あたり何万人、あるいは何百万人という訪問者をかかえるレベルに達したならば、状況は爆発的なものとなる傾向にあると、わが同僚たちは指摘した。一つのサーバが処理できる毎秒の SSL/TLS 処理の回数は、セキュアでない処理の場合に比べてずっと少ない。ひょっとしたら、５分の１程度かもしれないという！ 忙しさが中くらいの程度の会社の場合、その顧客向けのサーバの台数を劇的に増やす必要に迫られるだろう。そうしなければ、これまでと同じ人数のユーザーを相手に同じレスポンスタイムで処理を行なうことができないだろう。
典型的な状況では、SSL/TLS サーバが顧客の側に立ち、そこから情報に対するリクエストをローカルネットワーク内のプレインなウェブ接続によってリレーする。当然ながら、そのこと自体、複雑度を増すことに寄与している。多くの異なったセキュアサーバからこれら内部の各サーバに情報を求めるリクエストが届くのだから。
別の方法として、その会社は自社のサーバに暗号化専用のハードウェアを付属させることもできる。そうすれば SSL/TLS の処理が高速化され、サーバの台数を増やす必要も減るだろう。けれどもそれはやはりコストが増えることを意味し、マシンあたりの複雑度が上がるとともに故障の原因を増やすことにもなる。その上、もしも現行のマシンに十分な数のカードスロットがなくて暗号化カードを入れる余地がないならば、もっと高価なサーバ機に買い替えねばならないことを意味するかもしれないのだ。
どちらの方法にしても、電力消費量は増え、結局運営にかかる費用が増加することになる。また複雑度が増すということは壊れ易くなるということで、故障が起こってもその原因がそのコンポーネントにあるということを見つけ出せないという事態さえあり得る。
また、SSL/TLS はある意味切れ味の鈍過ぎる方法だとも言える。もしもあなたが既に自分の挙動やデータをオープンなネットワークで保護する方策を採っていないのならば、どのみちあなたは今あなたが読んだりブラウズしたりしているコンテンツを誰かが覗き見しているかどうかなど、あまり気にもしていないだろう。それでも、あなたは自分の本人情報やアカウントが悪用されることは望んでいない。何か、SSL/TLS ほどの複雑度やコストを必要とすることなく、それでいてトークンの保護ができる方法はないのだろうか？ それがあるのだ。そして、その方法がどうして実際には使われていないのかの理由を知ったら、きっとあなたは笑い出すだろう。
最もうまい方法は人気なし -- さきほど少し触れたように、ある特別な種類のウェブパスワードがあって、セキュアな方法で送信されるとともにクッキーを通じて送られるトークンと同じように状態を保持できる方法がある。HTTP (Hypertext Transfer Protocol) 規格は、ウェブブラウザやサーバがどのようにしてデータを要求し交換するかを定めている。HTTP 認証では、サーバがユーザ名とパスワードの入力を要求する。この HTTP 認証には（セキュアでない）Basic 認証と（セキュアな）“Digest 認証”の２つの方法がある。（ここで Digest という言葉は暗号化の形態を意味しており、パスワード自体をあからさまにすることなく送信者が受信者に対して双方が同じパスワードを持っていることを裏付けることができるというものだ。）
この Digest認証 - Wikipediaでは、本人確認のための暗号化されたメッセージが盗聴された際に価値を持つようにはならない形でユーザーの人物情報が受け渡しされるよう、ウェブサーバとブラウザの双方が働く。うまくデザインされた実装の下では（実はすべての実装がうまくできている訳ではないが）ブラウザとサーバが互いにリクエストを送り合う度に共有の数字を１つずつ増やして行くことで、盗聴者が前回の Digest を保存して後でそのトークンの Digest 版を再利用することができないようになっている。
それならこれは双方の世界のいいとこ取りをしている、だよね？ ならば、どうしてこれは広く使われていないんだろう？ その理由は、ログインダイアログの見た目が、あまりにも、ダサいからだ。きっとあなたも、アクセス権のないサイトを間違って訪れてしまったり、使うのにパスワードが必要だとは知らなかったサイトを訪れたりして、不意に HTTP 認証のダイアログが開いて驚いた経験があるだろう。そのダイアログにはほんの少しの情報しか書いてない。せいぜいそのあなたが訪れようとしているサイトを簡潔に説明したテキストがあるくらいだ。ダイアログはあなたにユーザ名とパスワードの入力を求めている。ブラウザによっては、今後そこを訪れた時のために認証情報を保存する選択肢を提供することもある。
けれども、このダイアログボックスの見た目を修正する方法はない。なのに、必要な情報をすべて正確に入力しなければ、あなたが OK をクリックする度に同じダイアログが再び現われてくるだけだ。Cancel をクリックすれば、エラーページが開くだけだ。このエラーページはカスタマイズできるのだが。
そもそもの最初から、多くのウェブ会社は HTTP 認証というものが平均的ユーザーが使うには難し過ぎるものだと概念的に決めつけてしまった。そしてその代わりに、彼らは状態保持のためのクッキーを利用するウェブベースのログインを使うようになった。こうして、Apple、Microsoft、Opera、Mozilla、その他どのブラウザ開発者やブラウザプロジェクトに対しても、誰も何も HTTP ログインの見た目を改善せよというプレッシャーをかけることがなく、そのまま時間だけが過ぎてしまった。例えば JavaScript フックを使ってカスタムウェブページを通じたコントロールを HTTP 認証に加えるというような努力は為されなかった。
そして今では、多かれ少なかれすべてが手遅れとなった。何かの奇跡が起こってすべてのブラウザが一斉にウェブページベースの HTTP Digest 認証をサポートし始めでもしない限り、この方法に頼ってログインを提供しようというサイトなど現われないだろう。こうして、私たちは皆現状のシステムに立ち往生している。では、現状でのリスクはどのようなものか、それから、何か他の解決法はないのか、検討してみよう。
サイドジャッキングのリスク -- セッションがサイドジャックされるリスクはかなり高いこともある。もしもウェブメールのアカウントであなたの第一義のメールにアクセスできてしまったら、サイドジャッカーがあなたの使っているいろいろなサイトへ「パスワードを忘れた」と言って回ることができるかもしれない。すると愚かなサイトならばすぐにあなたの新しいパスワードを電子メールで送ってくるので、そのサイトに入る方法が悪党の手に落ちてしまうことになる。賢いサイトならば、その代わりに電子メールでウェブリンクを送ってきて、あなたがそれを使って追加の確認情報を提供できるようにし、それをもってあなたがパスワードを入手したり新しいパスワードを設定したりできるようになる。（あなたもお気付きかもしれないが、ほどんどのバンキングサイトや多くの e-コマースサイトは昨年のうちにこの目的で追加情報をあなたに要求するようになった。これは偶然の一致ではない。）
賢い e-コマースサイトならば、サイトの認証を経ずにはあなたの郵送先住所を変更したり保存されたクレジットカード番号を聞き出したりできないようになっているので、その点は安心できる。例えば Amazon.com では、あなたがチェックアウトする度に新しいセキュアなログインセッションを経なければならないようになっており、いったん再認証を経れば、そのセッションは完全に SSL/TLS で保護されて、詳細情報が近くの盗聴者に見られないようになる。
サイドジャッキングで Amazon.com のパスワードを引き出すことはできないので、悪者があなたの出費で商品を自分の住所に配達させるということはあり得ない。しかしながら、悪者が 1-Click 注文機能を使って品物をあなたの住所に送らせるということはできる。一つのブラウザであなたが 1-Click にいったんログインすれば、あなたはログインしたままの状態で保たれ、追加の認証は要求されない。リモートヘルプのページで、Amazon はこう警告している。公共のターミナルで（何とも古風な言い方だ）注文した後は 1-Click を有効にしたまま放置しないこと、と。でも、今回のサイドジャッキング騒ぎを見て、Amazon も 1-Click の実装を考え直すかもしれない。
ちなみに、セキュアなセッションであろうとセキュアでないものであろうと、Amazon があなたのクレジットカード番号を送り返すことは決してあり得ない。他のサイトでは、この点の保護方針が大きく違っているところもあるが、いずれにしてもクレジットカードを扱うサイトならば決して番号をユーザーに渡し戻すべきではない。私は 1996 年の末ごろに短期間 Amazon.com で仕事をしたことがあったが、その時に起こったある事件のことを思い出す。ある有名なテクノロジー関係経営者であり常連の Amazon 顧客でもある人から、クレジット番号を間違えて入力すると、引き続き現われるページでもう一度番号全体を再入力しなければならない、という苦情が届いたのだ。Jeff Bezos は、これはバグではない、意図的な機能だ、と断固として譲らなかった。彼も、当時の他の経営陣も、運搬中のカード番号盗難について心配することにかけては遥かに時代の先を行っていたのだ。
それほど賢明な開発者や経営者に恵まれていないサイトは、クラッカーたちにとってサイドジャッキングの刃先でこじ開けることがより簡単にできるだろう。Graham や他の人たちは、例えば MySpace のようなソーシャルネットワーキングサイトが広く使われている今、サイドジャッカーがウイルス的なロードを広く大衆に配付して、MySpace トークンの横取りを自動化するツールをばらまき、既存のページを取り込んだり、そこにアタックを埋め込んでアップロードし直したりすることも可能だろうと述べている。
電子メールアドレスを含んだいろいろなサイトにある各種のコンタクト情報も、やはり同じょうに暴露の対象になる。私が Ferret と Hamster を使って私自身の Gmail セッションを読み取った時、私は Hamster が傍受した有用な情報一覧を眺めつつ、その中に Gmail での私のコンタクト相手すべての電子メールのリストがあることに気付いた。それは、電子メールアドレスや名前をタイプし始めた時に働く JavaScript ベースのインスタント補完機能を動かすために Google が供給する情報だった。
あなたがサイドジャックされる可能性の高さは、完全にその場所に依存する。もしもあなたが公共の場所で Wi-Fi を使う際に誰もサイドジャッキングのソフトウェアを走らせていないのならば、あるいはもしもあなたが公共の Wi-Fi ホットスポットをめったに使わないのならば、あなたのデータ（とあなたの本人情報）はほとんど危険に晒されていないだろう。けれども、自動化されたツールと何らかの条件、例えばどこかでの本人情報盗難、あるいは電子メールによるウイルス配付などがあれば、あなたの危険の可能性は途端に跳ね上がるかもしれない。人気のホットスポットはどんなところでもサイドジャッキングの温床になり得る。このことを巡って Adam Engst が数年前に書いた記事“ワイヤレスにおけるセキュリティの必要性を検討： ３つのＬ”(2004-04-05) は、今日も当てはまる良い研究と言えるだろう。
あなた自身をサイドジャッカーから守ろう -- あなた自身がサイドジャックされるのを防ぐには、３つの方法がある：
ウェブサイトをサイドジャッカーから守ろう -- ウェブサイトがその挙動を修正してユーザーたちをサイドジャッキングから守るにはどうすればよいのだろうか？ もちろん、そのウェブサイトがすべての接続に SSL/TLS を要求するという方法もある。さきほど述べたようにこれは費用がかかるかもしれないが、非常にセキュアな方法でもある。お金の支払いあるいはアカウント管理を含むシステムの多くが、例えば私たちのパートナーで、Take Control 電子ブックの注文と支払いを管理している eSellerate もそうだが、すべてを暗号化するという方法を選択している。
より現実的には、サイトがトークンをチェイン管理して、トークンを傍受して再利用しようとする試みを監視するということもできる。私の考えたアイデアは以下のようなものだ。今後、トークンによって状態保持をするためのデザインをする際に私は常にこれを実装してみようと思う。
まず最初に、サーバはトークンをチェイン管理、つまりユーザーがページをリクエストする度に新しいトークンを提供しアップデートする。トークンは、より新しいトークンが使われる時までの間に限ってのみ有効となる。こうして、時間制限の付いたトークンは数ページの間続くかもしれないが、新しいトークンが生成されるやいなや、古いトークンは期限切れとなり、あなたのセッションがサイドジャックされる可能性が大きく減る。セッションの終わりには必ずログアウトを実行してトークンを消去するように奨励するのも有効な対策だろう。サイドジャッカーがあなたのセッションを徹底的に追尾して彼のトークンを常時更新し続けるのでない限り、彼に侵入されることはない。こうすることでデータベースサーバに追加の計算量の負担がかかることは確かだが、並外れて大きな負担という程でもない。基本的に、これは HTTP Digest 認証の「安上がり版」と見ることもできるが、ちゃんとこれで動作する。
第二に、違ったブラウザと思われるものでトークンが使われた時、あるいは期限切れのトークンが繰り返し使われた時は、アクティブなセッションにいるユーザーに対して警告を出す。そのユーザーが次にページをロードすると「おい君、誰か他の者が君のセッションをハイジャックしようとしているぞ。君は今公共のネットワークを使っているんじゃないか？ 一度ログアウトしてから、後でセッションに復帰し直した方がいいぞ。ちなみに、セキュリティについていい読み物があるから、これを読んでみたまえ。」というメッセージを出してやるのだ。もちろんこれは偽陽性（誤った陽性結果）になるかもしれないが、見込みのある方法であることは確かだ。
結局のところ、ウェブは未だにデータ交換の方法としては隙だらけの手段だ。あなたが自分の人物確認を強固なものにするための手段として暗号化を使わない限り、あなたの人物確認は簡単に盗み出され得るものとなってしまう。
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
iMovie '08 の第一印象、ライプラリサイズの問題 -- iMovie '08 では、iPhoto があなたのデジタル写真のライブラリを保存するのと同じ方法でビデオライブラリ全体を表示するようになった。でもこれでは、膨大なビデオコレクションが出来てしまう。保存された題材は圧縮できるのか？ あるいは、ライブラリを外付けドライブに保存しておく方が良いのか？(9 メッセージ)
AirPort Express の良い参考書 -- ある読者が、Apple の AirPort Express で表面的な機能以上のものについて知りたいと、参考文献を探している。例えば Glenn Fleishman の“Take Control of Your AirPort Network”もある。(6 メッセージ)
TidBITS AutoCorrect Dictionary が Typinator を引き立たせる -- TidBITS AutoCorrect Dictionary について書いた Adam の記事を読んで、TypeIt4Me、TextExpander、SpellCatcher X など同種のオートタイプユーティリティについて議論が起こる。 (9_メッセージ)
TidBITS 御用達ツール： Teleport -- このユーティリティの最近の開発状況について、また同種の他のプログラムについて、読者たちが指摘する。(3 メッセージ)
IPhone の問題点？ -- iPhone の電源差し込みピンは iPod のものとは違うのか？ サードパーティの車内充電器を使うと壊れてしまうか？ (9-メッセージ)
Mail がデフォルトでないブラウザを使う？ -- Apple の Mail プログラムは、読者のデフォルトのウェブブラウザが Firefox に設定されている場合でも Safari の方を好むようだ。他のプログラム、例えば iCal のようなものにも同様の傾向があるらしい。 (6_メッセージ)
iPhone アップデートで変になる？ -- ある読者が、最新の iPhone がサードパーティの iPhone ハックと相性が良くないことを発見した。iPhone は、リストアされてしまうのだ。 (4 メッセージ)
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2007 TidBITS: 再使用は Creative Commons ライセンスによります。
, 
日本語版最終更新：2007年 9月 1日 土曜日, S. HOSOKAWA
Take Control 電子ブック日本語版好評発売中