パスワードを忘れた？ アカウント作成
Close
過去のタレコミ一覧：
保留 0件、 却下 20件、 掲載 18件、合計：38件、 47.37%の掲載率
37719 submission
宇宙

訂正依頼：土星探査機カッシーニ、衛星エンケラドゥスの「噴水」に突入予定

タレコミ by airhead
airhead 曰く、
ストーリー「土星探査機カッシーニ、衛星エンケラドゥスの「噴水」に突入予定」の本文二つ目のリンク「プレスリリース」の先が別のストーリーになっています。

正しくは「プレスリリース」です（TarZさんの日記エントリ、指摘コメント）。
36386 submission
著作権

訂正依頼：米ウォールマート、音楽配信サービスのDRMサーバーを停止 3

タレコミ by airhead
airhead 曰く、
Wal-Martの音楽ダウンロード販売は2004年3月には正式にサービスを開始しており（Impress Internet Watchの記事、nikkei BPnetの記事、プレスリリース）、 2007年8月には一部楽曲をDRMフリーで販売開始しています（マイコミジャーナルの記事、ITmediaの記事 — DRM全廃が2008年4月）。

ところがストーリー「米ウォールマート、音楽配信サービスのDRMサーバーを停止」では

米ウォールマートは、現在DRMフリーのMP3形式で楽曲のダウンロード販売を行っています。それよりも前は、試験的にDRM付きのWMA形式でのダウンロード販売を行っていましたが、
となっており、つい最近（前ストーリーの日付の2008年4月）まで試験運用だった、その間ずっとDRM版のみだったようにも読めます。試験運用開始を伝えるITProの記事の日付が2003年12月というのを見れば不自然に思いそうなものですが、実際そのように勘違いしたまま（のように思われる）対立意見を口汚く非難しているコメントが散見されますので、訂正した方がいいんじゃないでしょうか。ITProの記事を用いる必然はないように思います。
755114 submission
アップル

[Low End Mac] Lisa Office Systemレビュー

タレコミ by airhead
airhead 曰く、
  • 編集者へ
  • インタビュー本編をタレコミ（HTML formatted形式）してから気づいたんですが、タレコミではp要素がすべてbr要素×2で置き換えられてしまいます。ul要素の後にも挿入されており、見苦しくなっている部分があります。お手数かけますが適宜直して頂けないでしょうか。タレコミformを使わずメールで送りなおせというのであれば連絡ください。
  • インタビューと同様、訳文冒頭のリンク「Lisaエミュレータ作者、Ray Arachelianインタビュー」のリンク先がLEMの原文記事になっています。
  • 不都合があれば連絡くださいとLow End Macに通知したうえで、スクリーンショットを直リンクに変えています（原文のimg要素をa要素に変更）。
  • アンチMacな人を突付くような表現がほんの少しだけあります。判断はお任せしますがセクションローカルのほうが良いかもしれません。却下であれば私の日記にまわします。
  • セクション・トピック案：アップル、GUI、OS、ソフトウェア


Arachelian氏インタビューでも大きく取り上げられているLisa Office System (LOS) のUIに関して、今回はLisaエミュ/LOSレビュー記事についてもあわせて許諾いただいたので、ここにお届けします。これをもとにデスクトップ環境のありかたを考えてみるのも一興ではないでしょうか。

Lisaエミュレータがリリースされる――OS XおよびWindowsユーザーがApple Lisaを体験することも可能に
Ted Hodges - 2007.02.27

8年前、僕がまだ11歳のとき、僕はたまたまLisa Emulator Projectに出くわした。

それまでLisaについて聞いたことはあったが、Lisa Office System (LOS) を使う機会は一度もなかった。その理由は、そのエミュレータプロジェクトに動作するLisaエミュレータは無く、他のどこを探しても無かったからだ――今の今までは。

そう、Lisa Emulator Projectの創始者Ray ArachelianがついにLisaエミュレータを動作するまでに作り上げたんだ（この経緯について詳しくはLisaエミュレータ作者、Ray Arachelianインタビューをご覧いただきたい）。

他の多くの人たちと同じく、僕はこのエミュレータの稼動を何年も待ちつづけてきており、さっそくこのLisaエミュレータをダウンロードして、ROMを入手し、LOSの入ったメディアを見つけ出した。この両方がエミュレータを動作させるために必要となる。

用意したのはLOS 7/7 Version 3.1で、これをProfileディスクイメージにインストールし、仮想Lisaを起動してみた。

それではLOSの機能をいくつか紹介していこう――説明のためにスクリーンショットも十数枚用意した。

Lisaを起動して最初に目にするのが次の画面だ：

ご存知だろうか？ MicrosoftがWindowsを作るにあたって、Macから盗んだものでないものが一つだけある。砂時計カーソルだ（クラシックMac OSでは腕時計が使われていた）。いやいや、実は彼らはWindows砂時計をLisaから盗んでいたんだ。

それはさておき、起動プロセスはこのくらいにして、本編へと入っていこう。

まず最初に目に付くのは、他のコンピュータとはまったく異なるLisaのふるまいだ。

例を挙げると、もっと最近のGUIで普段やっているように、まずLisaWriteやLisaDrawやその他のアプリケーションを立ち上げ、作ろうとしている文書のタイプを選択し、それから文書を作成し、しかる後にタイトルをつけて保存、といった手順を踏むことはない。Lisaでは（LisaDraw PaperやLisaWrite Paperといった）便箋をダブルクリックして、そこから一枚引っぺがすことから始める。

そして今切り取ったばかりの一枚の紙にタイトルをつける。

そしてその紙を開いて、おもむろに書き始める（あるいは何か描くとか、ご自由に）。

なぜ最近のオペレーティングシステムはこのようにしないのかと不思議に思えるぐらいだ――僕にとってはこの方が理にかなっている。

なぜ僕が時計を95年2月25日に合わせているのかと不思議に思われるかもしれない。ええとつまり、Lisaは1995年で時を刻むのを止めてしまうんだ。（まあ少なくとも、LisaはY2K問題とは無縁だったのだ。）

Lisaのもう一つの特徴はプリエンプティブ・マルチタスクで、メニューを開きっぱなしにしても、システムの他の部分が止まったりしない。

その通り――プリエンプティブ・マルチタスクは、1983年に登場したLisaが標準で備えていた機能だった。（Macでは2001年にOS Xが登場するまで取り入れられなかった。）

さらにLisaで目に留まるのは、終了という選択肢が無いことだ。全部片付ける (Set Aside Everything) 、編集中の文書を片付ける (Set Aside "(document title)") 、保存して続ける (Save & Continue) 、保存して仕舞う (Save & Put Away) 、こういったことはできるが、終了 (Quit) はできない。

終了できない理由は、全てのプログラムが常に開いていることにある。LOSは徹底して文書志向になっているんだ。

これに加えて良い点は、Lisaに何かを保存せよといちいち指示する必要がないことにある。保存せよと指示した場合には参照ファイルが作成され、後々そこに差し戻す (revert) ことができる。

例えば、先週から作業を続けている文書があり、最後に保存したのは2日前、という場合を想像して欲しい。

Lisaは最後に保存してからのあらゆる変更を把握しており、文書を片付けるたびに、わざわざ問い合わせることもなくそれを更新してゆく。

でも文書で失敗してしまった場合にはどうすればいいのか？ ただ単にLisaに、直前の版に差し戻す (Revert to Previous Version) ように指示するだけでいいんだ！ 実際の話、Lisaに何かを保存させたくなるような理由は、後から直前の版に差し戻すことができるように、ということの他に見当たらない。

この差し戻し機能を除けば、文書を保存せねばならないような理由は全くない。自動だから。

それとは別の、僕がとても気に入っている機能を挙げてみよう。あるディスク内の文書を開いている最中にディスクを取り出そうとした場合、Lisaは文書を（複数あってもすべて）保存し、それらを閉じ、そうして初めてディスクを排出する。

これは、誰かに（例えば上司に）別のディスクを渡されて調べておけと言われたような場合に重宝するだろう。

さらに最初に作業していたディスクを再びLisaに入れれば、Lisaは直ちに作業していた文書を自動的に、ディスクを取り出す直前の状態で開きなおしてくれる。

これと同じことは、電源ボタンを押した場合にも起こる。

開いている文書の数か20あって電源ボタンを押したとしても、Lisaはそれらを全て保存し、片付け、全てを仕舞いこんで、そうして初めて自身の電源を切る。

再びLisaの電源を入れれば、直ちにLisaは全てを電源を切る直前の状態で開きなおしてくれる。この動作はMacのスリープに似ているが、たった一つだけ、全ての文書が保存されるという違いがある。

Lisaに文書の複製を指示した場合の動作も、気に入った点の一つだ。複製したいと思うファイルそっくりの点滅するアイコンが作られる。ファイルの複製の前に、まずこの点滅するアイコンを複製したい場所に事前にドラッグしておかなければならない。

想像するにこれは、1983年当時はディスクスペースが限られており、ファイルを複製するにしてもそのディスクにそれだけの空きがない場合もあったためだろう。

ちょっと変わった部分もある――が、現実世界でのことを考えれば驚くにはあたらない――あるプログラムを、それがあるディスクから別のディスクへドラッグした場合、Lisaはファイルをコピーし終えると元のディスクからそのプログラムを削除してしまう。これは奇妙に思えるかもしれないが、考えてみれば実生活で現実のファイルをあるフォルダから別のフォルダに移す場合にしても、ファイルは元あったフォルダに残ってたりはしない。

Lisaエミュレータ

このエミュレータはなんてそっくりなんだと、皆驚かれることと思う。いやまったく、これはすごくよく出来ている。

UIをエミュレートするだけにとどまらず、電源ランプやディスクドライブも含めたコンピュータ全体がエミュレートされている。このエミュレータを実行すれば、誰もがLisaを目の当たりにしているような感覚を覚えるだろう！

この記事を書いている現在、ディスクドライブのモーター音とディスクのアニメーションが機能するのはWindows版のみで、今のところエミュレータにドキュメンテーションは付属していない（訳注：その後beta版と同時にドキュメンテーション草案のPDFがリリースされた）。

バグも存在し、プログラムによってはスクロールバーの矢印が欠けることがある。Deskメニューの誤動作を引き起こすバグもあるようだ。（デスクトップ上の全てのアイテムを表示させるためにデスクメニューが用意されている。）

とはいえ、このエミュレータに関して僕のところで発生している唯一の大きな問題は、僕の733MHz G4では動作がかなり遅いということだ（エミュレータのレポートでは3Mhzで、Lisaのゆったりとしたハードウェア速度5MHzの、わずか3/5でしかない）。Ray Arachelianの確約したところでは、来週に予定されている次のリリースではG4マシンでもずっと速く動作するようになるとのこと。

その一方でWindows版はなかなかの速さで動作する。したがってWindowsマシンをお持ちであれば、当面はそちらでエミュレータを稼動することをお勧めする（「かなり」速いMacを持っていない限り）。

さて、今回のLOS検証記事は楽しんでいただけただろうか。質問やコメントがあれば気軽に電子メールを送って欲しい。おっと、チャンネルはそのままで、現在Ray Arachelianにインタビューしている真っ最中で、Lisa Emulator Projectについてさらに詳しくでお伝えできるはずだから。

"Lisa Emulator Released, Allows OS X and Windows Users to Experience Apple's Lisa" by Ted Hodges, Feb. 27, 2007.
Vintage Mac Living articles copyright ©2005-07 by Ted Hodges. Entire Low End Mac site copyright ©1997-2007 by Cobweb Publishing, Inc., unless otherwise noted. All rights reserved. Japanese translation published under permission from copyright holders.
755116 submission
アップル

[Low End Mac] Lisaエミュレータ作者 Ray Arachelian

タレコミ by airhead
airhead 曰く、
  • 編集者へ
  • 訳文冒頭のリンク「前回のコラム」のリンク先がLEMの原文記事になっています。これを、もう一方のタレコミが採用されたらそのURLに変えていただけないでしょうか（そのままでも大して支障はないですが、できれば）。
  • 導入文が長くなるので説明してませんが、本文中のリンク先は原文のままです（機種名はLEM内のまま、Wikipedia英語版へのリンクが多数あるがたいてい日本語版同項目より詳しい、「カンブリア爆発」なんて日本語版でも良いがそこだけ直すのも変）。
  • セクション・トピック案：アップル、インタビュー、デベロッパー、ハードウェア、ソフトウェア、プログラミング


皆さんはApple Lisaというマシンをご存知でしょうか。このLisaに魅せられて情報収集・提供を行うとともにエミュレータの製作にとりくみ、8年もの歳月を経て先頃ついに1.0betaをリリースした人物がいます。今回の主役、Ray Arachelian氏です。
今回はお届けするのはLow End MacによるRay Arachelianインタビューの翻訳です。公開の許諾を快くしてくださったLow End MacのTed Hodges氏およびDan Knight氏、そしてRay Arachelian氏に、ここで改めて感謝申し上げます。

なお、Arachelian氏からはRetroMacCastで行われたインタビュー (Podcast) もお知らせいただいたので、こちらもあわせてお楽しみください（別記：m4aファイル内の関連リンク）。

Lisaエミュレータ作者、Ray Arachelianインタビュー
Ted Hodges - 2007.03.13

先日僕はある重要な人物にインタビューするという、大変な栄誉に預かることができた。彼の名はRay Arachelian、Apple Lisa Emulatorの作者その人である。彼がいなければLisaを持っていない人にLisa Office Systemの動作を見せる方法はなかったかもしれない。

Lisaエミュレータについて詳しくは前回のコラムをご覧いただきたい。

Ted Hodges: よろしくRay。調子はどうでしょう？

Ray Arachelian: 順調だよ。次のリリースの準備をしているところで――この水曜日あたりになると思うけど、これが最初のベータになる――ピースが納まっていくごとに胸の高まりも増すばかりだよ。

Ted: あなたがLisaと関わりをもつようになって、どのくらいになるんでしょうか？

Ray: 初めてLisaを手に入れたのは1989年だね。最初の頃はMacWorksを使ってMacとして使っていたんだ。それがきっかけでHackintosh IIcx（PCケースに収めたIIcxのマザーボード、など）を組んだりもしたし、それ以来すっかりMacのとりこになってしまった。Macを長年にわたって何台も買ってきたのも、それがきっかけさ。

最初はLisaの歴史的重要性も、他のオペレーティングシステムを動かせるということもわかってなかったんだけど、FidoNetなどのBBSネットワークでLisaオーナーと話しているうちに、自分の持っているものが大した宝石だとはっきりしてきてね。Lisaの本当のオペレーティングシステムを探すのに、Steve Hatleにはずいぶんお世話になったよ。

Ted: 初めてLisaに触れたのはいつのことでしょうか？

Ray: 僕は一番初めにやったアルバイトで技術係をやってたんだ。学校が終わってからの典型的2時間だね。僕はブルックリン工業校に通ってて、中等部だったか高等部だったか、って頃。ニューヨーク市教育委員会の、教員向けトレーニングセンターでの仕事で、2つか3つあった教室にはいろんな種類のPCとかApple IIとかMacとかCommodoreとか、そういったものが一杯置いてあった。

ある日、廊下のガラクタ置き場になっているところに見慣れないマシンが放ってあるのを見かけてね。Appleロゴが入ってるし、Macの一種だろうと思ったんだ、マウスも一緒にあったしね。以前研究室でMac Plusで遊んだことがあったから、そのマシンに興味を引かれたんだ。

そいつのことをボスに訊いたんだけど、Lisaっていう言葉を耳にしたのはそれが初めてだった。彼は持っていってもいいと言ってくれて、ハードディスクドライブもくれた。2週間もすると電源が死んじゃったけど、彼は僕のためにわざわざ新しいのを注文してくれて、おまけにMacWorksのフロッピーまでくれたんだ。

で、これはDOSとかWindows 3.1とかの頃の話なんだけど、それらと比較してMac XLが動いてるLisaってのは素晴らしいマシンだった。それをタダで手に入れたんだから、自分の幸運が信じられないぐらいだったよ。

その何週間か何ヶ月か後、これまたゴミ箱行きが決定している壊れたLisaを2台持ってる先生がいたんだけど、僕に要るかと訊いてきた。そのうち1台をなんとか動くようにして、もう1台はバラバラに剥いて捨てた。こうして僕はほぼ完全なLisaを2台とそこそこのスペアパーツを手に入れたってわけさ。

一年後、仕事場ではXenix 286が使われていた。これも幸運だったな、XenixにはLisaで動くバージョンもあったし、それでUnixを独習することができたから。この頃には僕はHackintoshを組んでいて、メインマシンとして使っていた。

Ted: Lisaは何台持っていました？

Ray: 3台、そのうち1台は修理できるような状態じゃなかったけど。そのうち再利用できる部品を取っておいてたんだけど、残念ながらケースとCRTは、すごく狭いアパートに住んでて空き場所が全然なかった頃に捨てちゃったよ。

Ted: Lisaエミュレータを書こうと思ったきっかけは？

Ray: 1997年の暮れ、家の大掃除をしてるときに、一度持ってるマシン全部の電源を入れてようと思ったんだ――ソフトウェアの更新とかOSのパッチ充てとかでよくやってることだけどね。で、2台のうちの1台はどうしても電源が入らない。ウェブを調べまわっていくつかの部品を見つけることはできたけど、部品を見つけるのは以前より難しくなっているみたいだった。

さすがに僕も、うちにあるLisaがいつまでも動きつづけるわけじゃないし、交換部品の供給もどんどん厳しくなっていくと気づいてね。この頃には当然ながら僕も、Lisaの歴史的重要性について十分に認識していた。Lisaの生年月日はMacよりも前だしvMac emulatorがリリースされた（間もない頃だった）から、多分Lisaのエミュレータを書くのはそれほど面倒じゃないだろう、と思っちゃったんだ。我が勘違いここに極まれり、だね。

幸運にも僕は、長年にわたってLisaの情報を大量に集めていたDavid T. Craigを見つけることができた。実際のLisa開発者に連絡を取ってみるとか、彼はそういった助言も数多くしてくれた。振り返ってみると、このプロジェクトでは先導者役に困らなかったね。このエミュレータは彼の助けなくして存在し得なかっただろう。

その他にも、名前を明かすことはなかったけど、長年にわたって期待以上の貢献をしてくれた人たちもいたよ。

Ted: このエミュレータを書くうえでの困難はどれほどだったのでしょうか？

Ray: 想像してたよりもはるかに困難だったね――というのも幸いしたのかな、なにしろ、実際にどれだけの困難が待ち受けているかを分かっていたら、始める前にあきらめていたかもしれないし。

当時、Cはおおよそ理解してた。大学の課程でも習ったし、うちにあるMacをあちこち覗きまわってたから、68000についてもわかっていた。あちこちで小さなDOSプログラムをいくつか書いてたし、今はもうないけど、MacのためのBBSを書いたりもした。Unixを熟知していたけど、それはシスアドの観点からだったな。X Window system向けプログラムの書き方については知らなかったし、エミュレータはそういう技術をまとめて学ぶのにうってつけの口実に思えたんだ。

半年から1年かければそこそこ動くものができて――おそらく完成させるにしてもせいぜい2年、なんて思ってたんだよね。

Ted: エミュレータ製作はどういう風に進んでいったのでしょうか？

Ray: 最初の段階にやったことは、Lisaの資料を全てスキャンしてオンラインに置くことだった。そうしておけば家にいなくても見ることができるし、おまけに取り扱いも楽になる、というのが主な理由だよ。当時僕はロングアイランド鉄道で朝晩通ってたんだけど、コーディングのほとんどはその中でやっていたし、電子版の資料が理想的だったんだ。

それからというもの、それを何度も読み返すのが続いたな。コンピュータの資料をどんどんさかのぼっていくと、最近のコンピュータ用語に使われる表現では辻褄が合わないところが出てくるし、コードを書く前にまず、物事をすみずみまで明確に理解しておかないといけない。Lisaの資料はそれほど厄介じゃなかったけど、まるで資料の研究をしているような感じだったよ。

どのエミュレータにも共通する部分はある。CPUはまさに、その全ての中核だ。当時は68Kエミュレータを探し回っても数はあまりなかった。UAEコアがだいたいできている程度。

ほとんどJITコンパイラという理由でエミュレータ界のある人が推していたのが、Generatorのコア。当時デスクトップの主流は200MHzのマシンだったし、速度を稼いでくれるならなんでも重要だった。ゲストCPUの1命令をエミュレートするにはホスト側で10-40命令かかるから、5MHzのマシンの場合だと、インタープリタ上のCPUを動かすのに最低でも100MHzのCPUが必要で、I/Oなど他のことのためにもある程度余裕を残しておかないといけない。

メモリに関しては全く簡単、マシンのメモリと同サイズの配列を用意するだけ。

LisaのMMU（メモリ管理ユニット）には追加の複雑なレイアもあり、これによって全てのメモリアクセスに対して大掛かりに聞き耳をたてることができるようになっていた。MMUコードをいかに最適化して書き直すかについては、相当な時間を費やして考えさせられたよ。現在のコードにあるのは、MMUの完全な書き直しの3度目になると思う。後になってみると、最近のマシンはかなり速くなっているから書き直す必要はなかったんじゃないかとは思うけど。

2001年末ごろまで、僕のエミュレータからはまとまった量のものを取り出せずにいた。これはエミュレータの常でね、惜しいところまで来ないと大した成果は得られないものなんだ。ROM内の起動時テスト (POST) ルーチンの出力を何とか取り出すことができたんだけど、それでディスプレイルーチンに誤りがあるのがわかって、すぐさまそこを直した。

これこそが一番最初のエウレカ！の瞬間だったんだ。

次に、フロッピーのエミュレーションを動作するようにしなきゃならなかった。ROMだけを見てたらそこはあまり関係ない部分だしね。

第二のエウレカ！の瞬間は、LisaTestを途中まで立ち上げられるようになった頃のことだった。おそらくI/OシステムのどこかかMMUが壊れていたんだろう。

幸いにもLisaにはいくつものOSと、さっき言ったLisaTestがあり、I/O部分に対して健全性検査を行うことができた。I/O部分の大半がLisaTestの徹底検査を通るようになっても、Lisa Office System (LOS) を起動させることができずにいた。それでLisa Monitorを立ち上げてみることにしたら、それもMacWorksもXenixも、当時のままに動くじゃないか。実際のLisaで動いてたし問題あるはずがない。
Arachelian氏より補足
Lisa MonitorとはLisaのごく初期のオペレーティングシステムの名称で、LisaTestやMacWorksの製作はこの上で行われた。いわゆる機械語モニタのことではなく、Lisa開発環境Lisa Pascal Workshopに含まれていた機械語モニタはLisaBugと呼ばれていた。なお、Xenixについては現在も完全動作するまでには至っておらず、立ち上がりはするがログインやシェルは現れない。


2003年になると、僕はCPUコアにバグがあるんじゃないかと疑うようになっていて、僕が使っていたCPUコアであるGeneratorの作者、James Ponderに連絡をとってみた。彼は、彼が気づいていたshift/rotateオペコードのバグについて教えてくれたが、まだ運が巡ってきたわけじゃなかった。

僕はテスタープログラムを組むことにしたんだけど、それには本物の68Kマシンが必要だった。Unixが動いて、その上で68Kコードに加えてGenerator CPUコアそのものをアセンブル・実行できるものがいいし、となればGCC (GNU Compiler Collection) ツール集が挙がってくる。OpenBSDかLinuxをIIsiにインストールすることを考えたけど、これにはFPUが無いからさらに困難だとわかった。

幸いにも僕はNeXTstationを持っていたし、これなら要件を満たしている。そこでエミュレータからCPUコードを抜き出して小テストスイートプログラムを書き、それらをまとめて実行する接着シェルスクリプトも書いた。テストの実行には丸一週間かかり、大量のバグ除去に役立ったんだ。

後になって気づいたんだけど、68040で動いているCPUエミュレータコードとIntelマシンで動いている同じコードとでも差異があって、そのバグを取り除くには例のテスターをLinux x86で動かして68040の出力と比較しなきゃならなかった。前回のテストでの68040の結果を圧縮保存しておいたのはラッキーだったな。

それでもまだLOSを動かすだけの幸運は巡ってこない。そこで僕は作業に戻ってI/Oシステムにもう少し手を加えて、シリアルポートハンドラであるZ8530のコードに着手したんだ。

ようやく僕はLisaのMMUを適正に機能させる魔法を見つけた。2006年7月のことだ。こいつはハードウェアの非公開機能を利用してたんだ。コードが何をしようとしているか、エミュレータ上のハードウェアで何をできずにいるのか、これを較べて調べてなかったら見つけられなかっただろうな。

LOSをインストーラディスクから起動できるようになると、今度はハードディスクドライブのコードを書かなきゃいけなかった。それ無しのLisaはそれほど便利じゃないしね。

エミュレータのコードが完成したのは2006年9月頃のことだった。僕はX Window UIを取っ払うことにしてて、WindowsやOS Xといった他のオペレーティングシステムに移植するのに役立つFOSSはないかとネットを探し回ってた。wxWidgetsは要件を満たしている。僕はwxWidgets本を買ってきて一週間かけてむさぼるように読み、新UIのコーディングを始めた。

当初僕は最初のリリースを、（1983年の）Lisaの最初のアナウンスに合わせて1月19日にしたかったんだけど、別の特別な日、1月24日の直前まで満足に動くものにすることができなかった。最初のリリースは相当バギーだったし、追加リリースを必要としていた。アルファテスト品質にも達していなかったし、それはプレビュー名義にしたんだ。実際、開発版だしね。

次のリリースは1.0のベータで、その後バグフィックス版をいくつか出すことになると思うよ。

Ted: このエミュレータを書くのにかけた期間はどのぐらいなんでしょうか？

Ray: だいたい8年。止めたいと思ったことも何度もあったけど、なんとか自分を納得させてきたし、納得できなくても続けるように無理やり強いてきたね。コンピュータの歴史の本をたくさん読んだり、何ヶ月かおきに『Pirates of Silicon Valley（バトル オブ シリコンバレー）』を観たり――目標に専念させてくれるものなら何でも取り入れたよ。

通り抜けられないと思うような個所は一つもなかったけど、別のレイアに難題が持ち上がったり、他のところに間違いがあるとほのめかすなんてことはしょっちゅうあった。いくつかの通行止めは結構厳しい問題だったけど、大半は難しくなかったな。

出だしを間違えて袋小路、なんてのも結構あった。一番始めの頃には自作のCPUコアをいじくりまわしててGeneratorに切り替えるまでの2、3ヶ月を無駄にしたし。生のX Windowコードを勉強して書くことにも、さらに3ヶ月無駄にした。（僕が始めた頃、いいツールキットに限って有料だった。GTKやKDEはなかったし――少なくとも僕はその存在を知らなかった。） Xの自家製ウィジェットを書くなんて不要な作業の塊だよね。

もちろん、仕事とか家族とか、実生活の都合でエミュレータの作業をまったくしない時期も何ヶ月かあったしね。

Ted: このエミュレータはどのように動作しているのでしょうか？

Ray: たいていのエミュレータがそうであるように、その心臓部はCPUコアだ。（エミュレータには）いろんなタイプがあって――もっとも一般的な（そしてもっとも遅い）のはインタープリタ。ゲストCPUへの命令をフェッチして、デコードして、それから実行する。

Generatorで使われているコアは、それよりもちょっと上手くやってる。命令をフェッチしたら、デコードした後、命令で使われているパラメータとそれについての情報、つまり各フラグを計算するか否かなどをキャッシュするんだ。こうしておくことで、そのコードが次回実行されるときに格段に素早く実行できる。

GeneratorのコアにはARMホスト用JIT (Just in Time) コンパイラもある。だけど、僕のところではその機能を使っていない。

もっと最近のCPUコアは完全JITコンパイルをサポートしていて、それを使えば実行速度は大幅に改善する。だけど、Generator CPUコアはLisaEmのMMUに緊密に接続されているから、コアの変更は選択肢にはならないんだ。少なくとも、大規模な再設計なしにはね。

CPUはこれぐらいにして先に進もう。I/Oシステムはハードウェアのドライバを書くことと非常によく似ている。シリアルポートドライバとかパラレルポートドライバとか、そういったものを書くのと同じような感じ。ただしドライバの「逆向き」だけどね、なにしろ作ろうとしてるのはハードウェアの振る舞いであって、ドライバじゃないから。結果として仮想のI/Oハードウェアは方向転換し、ホスト側オペレーティングシステムで相当するアナログ部分を見つけ出す。例えば、フロッピーのあるセクタへの書き込みは、そのデータの、あるファイルの所定の場所への保存を意味することになる。

I/Oサブシステムの多くはオートマトンを書くことで対処できる。ハードウェア間のマルチタスクを実現するためにスレッドの分離などをする必要はないんだ。

難易度はハードウェアによって様々だ。色々あるLisaオペレーティングシステムもそれぞれやり方が異なっている。VIA 6522（パラレルポート）だと、以後ポートを入出力のどちらに使うかを指定するディレクションマスクをセットして、1バイト書き込む、そうするとそのバイトが直ちにポートに送られる。もう一つのやり方は、値をポートに書き込んでからディレクションを切り替えるんだけど、ディレクションを切り替えないといつまで経ってもポートに送られない！ ハードウェアの柔軟性が増すにしたがってそのエミュレータを書くのも難しくなるんだ。そういうメソッドを全部サポートしなきゃならないからね。
VIA
Versatile Interface Adapter（汎用インターフェイスアダプタ）。6522はMOS Technology社6502ファミリのI/Oポートコントローラで、CommodoreやApple III、Macintoshなどに使われていた。


Lisaのハードウェアは、ちょっと変わった作りになっていた。例えば、ある特定のI/Oアドレスの読み出しをすると変化が起きてしまう！ 書き込みがあったんじゃないかと思ってしまうんだけど、そのアドレスに触れただけで変化する、少しばかり直感に反するものなんだよね。もちろん、そういう機能のエミュレート自体はたやすい。お次は、エミュレート難度の順にいうと、VIAかCOPS（クロック/キーボード/マウスを扱うコントローラ）、それからZ8530シリアルコントローラ。Z8530は相当手のかかるケダモノでね。完全エミュレートは試みもしなかったけど、その機能を利用できる程度にはエミュレートしたよ。

MMUそのものは基本的にはいたってシンプルなんだけど、これを利用してあらゆるメモリやI/Oの参照に遅延が入るようになっていた。これの最適化されたエミュレーションをいかに設計するかについては、腰を据えて熟考しなきゃならなかった。僕が思いついたのはMMUテーブルをCPUコアのIPCと結びつけるキャッシングシステムだ。これは大量のメモリ操作を要求するしフットプリントが他のエミュレータよりも大きくなるんだけど、パフォーマンスにおける収穫はそれだけの価値がある。

きっちりやるのが一番難しいのはタイミングだ。このエミュレータは今もまだ上手くできていないんだけど、これはつまり、あまりに速くとかバラバラの順番でとか、事が起こる状況次第で動作したりクラッシュしたりする、ってことなんだ。これは、割り込みなどがいつ発生するかを伝えるタイミング情報の入った優先度付きキューで対処できると思う。

Lisaの資料は膨大だ――それでも完全に網羅しているわけじゃないし、誤認を生じやすい部分もある。実行中のコードがしようとしていることを観察しなきゃいけないのはもちろんのこと、資料に書いてあることを無視しちゃったほうがいい場合もある。なにしろ、ハードウェアガイドを書いた人は読者としてエミュレータ作者まで想定してたわけじゃないんだし。シリアルナンバーのハードウェアが実際にどのように動作するかなど、中には隠さなければならなかった情報もあるだろう。

フィニッシュラインに到達するには、あらゆるもののトレースログを取っておかなければいけないし、その中で何を探せばいいのかを理解しておかないといけない。トレースログには、実行された全ての命令、CPUの全てのレジスタ、発生した可能性のあるI/Oなど――基本的には特定の時点に起こった全ての事が、要したCPUサイクルとともに記載される。実行時間1分のトレースログでさえ、優に数ギガバイトにもなるんだ。トレースログを読み始めて数時間もすれば、探しているものを絞り込む方法のコツをつかんで、それに役立つツールを作るようになるよ。

ログを何ギガも通して読むのは大して面白いもんじゃないけど、やる価値は大いにある。ソフトウェアが何をしようとしているかを、素早く把握できるからね。おまけに、ソフトウェアのどの部分がアセンブリ言語で書かれていてどの部分がコンパイラで生成されたのか、どこの効率が良くてどこが悪いのか、そんなことまでわかってしまう。これは68000のウィザードが書いたコード、これはビギナーが書いたコードって見分けがつくようになるよ。

スタックにパラメータを出し入れしてまでほとんど同じことをやる別の関数を呼んで、それでどれだけのオーバーヘッドが浪費されているかさえ分かってない人も多いんだよね。トレースログにかかれば、それもあからさまに暴かれてしまう。最近のアーキテクチャにしたって、特にオブジェクト指向プログラミングに要因があるんだけど、このオーバーヘッドの弊害を相当受けているよ。CPUとメモリシステムのスループットの高さで目立たなくなってはいるけど。

大抵のソフトウェアプロジェクトでは、開発作業が20%、デバッグが80%ってところだ。エミュレータでは多分もっとひどいんじゃないかな、というのは完成間近までまるで結果が得られないからね。結果が得られるようになっても、エミュレータを動作し始めたところから実際に稼動するまで持っていくのには、相当な時間がかかるものなんだ。

Ted: 「Lisaの技術」の歴史を保護することの重要性については、どのようにお考えですか？

Ray: Lisaだけじゃなくほとんどのコンピュータについて、その歴史を保存することは重要だと思う。Lisaはコンピューティング史に残る非常に重要なマイルストーンになることができたけど、記憶にとどめておくべき技術が込められたコンピュータは数多くある。

発生期にある技術のほとんどに共通することだけど、たいていカンブリア爆発というものがあって、何百という――場合によっては何千もの――種類のシステムが登場して、市場シェアを奪い合うことになる。マイクロコンピュータの世界では、1970年代後期から1980年代中期にかけてこの構図が見られたよね。市場はそれらのマシンに進化を促す力にあたるものを加え、当然ながらそれらの大半は死に絶えてしまうことになる――僕たちが保護しようとしているのは、まさにそれなんだ。その多くは興味深い機能を備えていて、それぞれがコンピュータ史家に教えを授けてくれる。

ここで大きな問題があるんだけど、それらのシステムの技術資料の入手が、すでに保存されているものを除いてどんどん難しくなっている。例えばBitsaversは、そんなシステムの資料を収集して保護に役立てようと試みている。これは必ずしもそれらをエミュレートするという目的だけのためじゃなくて、歴史的理由のためでもあるし、そしてまたアンティークハードウェアの所有者がそれらを保存するのに有益でもあるんだ。

技術資料の入手が容易になった側面もあるけど、それはデータ保護に努めている人たちの取り組みがあってこそであり、Commodore 8bit系列のようなよく知られたシステムに限ってのことなんだ。

ソフトウェアライブラリの保護も必要だ。あいにく古いメディアは動作するドライブの数の減少とともにアクセスしづらくなってきている。機械部品は真っ先にお亡くなりになるし、ゴムは経年劣化し、歯車類は潰れ、グリスだったものは糊になり、コンデンサは液漏れして基板を傷める、といった具合。

長期的にみれば、古いコンピュータはいずれ死に絶える。最近の相当部品とかコンデンサの交換なんかで結構やって行けるもんだけど、ゴムローラーや特注ギアの交換はほぼ不可能だ。

だからそれら全てがコンピュータ史家の関心の的になっている。幸いにも、古いコンピュータとその歴史の保護に関心を持っている人は大勢いる。メーリングリスト、ウェブBBS、ブログ、ポッドキャスト、催し物など、交流の場はたくさんある。

まだまだ何十とあるはずだし、ひょっとすると何百とあるかもしれないね。

エミュレータ製作の観点から言うと、ハードウェアの詳細な資料、ROM、それにソフトウェアダンプが必要になる。回路図は大いに役立つね。企業の多くは自社の技術をプロプライエタリと見ていて、自社ハードウェアに関する資料を一切公開しない。彼らが廃業したり製品の廃止を考えたりすると、資料は公開されず、そのシステムは時の経過とともに失われる危険にさらされてしまう。

例えば、他にも色々あるんだけど、僕はNeXTstationエミュレータの製作をやってみたいと思ってる。なんでわざわざ、OS XってNeXTstepの替わりがあるのに、と言う人もいるかもしれないけど、両者を見較べてみると、Mac 128と最新のIntel duo Mac Proの場合と同じくらい違いがあるよね。

新しいMacBookを持っていても、古いMacのソフトウェアを動かしたくなることだってあるんじゃないかな。NeXTstationの話に戻ると――プロプライエタリのハードウェアだから資料は見けられそうにない。だからオブジェクトコードを逆アセンブルしなきゃならない。資料がないと、何もかもがリバースエンジニアリング――こいつは険しい道だ。

僕はかなりツイてたし、必要な資料を入手することができた。だけど他の多くのマシンは、情報不足のために失われてしまっているんだ。

Ted: 僕には、Lisaが非常に先進的なマシンであるように思えます。ある意味、現在僕たちの周りにあるものと較べても進んでいます。これについてはどうお考えですか？

Ray: Lisaのハードウェアはそれほど面白味があるってわけじゃないんだよね。僕に言わせてもらうと、少なくとも他の同クラスのマシンと比較した場合には。Lisaのハードウェアにも非常に独特で興味を引くところがいくつかあるんだけど、Lisaの魂の鍵になっているのはやはりそのソフトウェアなんだ。なにも同じものを造るのは簡単なんて言ってるわけじゃなくて、むしろ他のミニコンにも匹敵するぐらいなんだけどね。

Lisaのハードウェアの興味深い部分を紹介しよう。技術者たちは、Lisaの設計時期に登場したばかりの真新しいCPU、68000を使った。当初MMUを動かすことは考えられていなかったが、彼らは何とか動作させるところまでこぎつけた。彼らは元々Xerox AltoにカスタムメイドのビットスライスCPUを載せたようなものにしようと考えていたんだ。彼らは、きわめて少ないチップでグラフィックを表示させる非常にシンプルな方法を考案しており、もっとも複雑な部分でもほんの少しのROMで制御されていた。Xerox Starでこれに類似するシステムは、43Hzというリフレッシュの遅さに対応する燐光体を使ったモニタを必要としていた。
Arachelian氏より補足
Xerox Starで表示に使われていた遅いハードウェアではリフレッシュレートを上げることができず、フリッカーを抑えるために長残光の燐光体を用いた特別なCRTを必要としていた。Lisaはこの問題を解消しており、通常のCRTを使用していた。


Lisa自体は、それ以前にHPでおそらくはミニコンピュータに携わっていた技術者によって作られた。Lisaはミニコンだ、あるいはほとんどそうだという人もいるかもしれないね。ハードウェア機能を装備するためにLisaにはいくつものCPU/マイクロコントローラ（68000、6504、COPS）が搭載されていた。

基板やそのコネクタクリップの中には、PDP系列といった他のミニコンのハードウェアを連想させるものがある。Lisaの物理的設計は、ハードウェアの交換をとても簡単にできるようになっていた。この観点からいって、相当に練られた設計だったんだ。ミニコンとは違って、Lisaはシングルユーザーマシンとして作られていたけどね。でもやはり、ユーザーに中を触らせようとしない閉ざされたシステムのMacとは対照的だ。Macは明らかに、設計からしてマイコンなんだよね。

ソフトウェアに目を移すと、ほとんどUnixのような感じなんだけど、大半はPascalで書かれていて68000アセンブリ言語も大量にある。ボンネットを開けてみるとOSにはマルチプロセス、メモリ保護、仮想メモリ、パイプ、データ共有などが完備されている。このどれを取っても同時代のミニコンピュータに引けを取らないよ。

歴史的な真の輝きを見せているのは、そのUI設計だ。LOS UIの背景にある研究とアイデアこそ、歴史的観点から特筆すべきものだね。Lisaはそれ以前のものと様々な面で異なっていた。それ以降に登場したあらゆるものと違っているとも言えるだろう。

確かに、PARC以来のコンセプトに基づいた工夫もたくさんあるんだけど、Lisaのデザイナーはさらに多くのものを作り出している。アイデアの大半はMicrosoft Windows 1.xや2.xにコピーされたし、Macで歳月をかけて発展していったものもあるけど、それらは興味深い工夫じゃないな。僕の考える興味深い機能がコピーされていたら普通に目にするものになっていただろうし、それゆえに期興味深くないかも知れないけどね。

Ted: LOSには、その後のオペレーティングシステムに備わることはなかったものの備えているべき機能があったかと思いますが、これについてはどうでしょうか？ あるとすればどれでしょう？

Ray: 間違いなくあったね。「文書中心の」デスクトップというアイデアは今時のデスクトップとは別世界だ。今でも文書を取り扱うわけだけど、アプリケーションを基準にして考えてるよね。例えば、「このメモを」ではなくて「このMicrosoft Word文書を誰々に送る」って感じじゃないかな。

Lisaは違っていた。文書を基準にして考えて取り扱えるようになっていたんだ、アプリケーションではなくてね。システムはその機構を隠すよう設計されていた。これは、手続き型プログラミングとオブジェクト指向プログラミングの差に似ていると思う。Lisaのデスクトップは文書に対して行動を取れるようになっていたんだ。文書とそのアイコンは、最近のものよりもずっと密接に関連付けられていて、抽象性は薄かった。いってみれば名詞のようなもので、動詞ではなかったんだ（アプリケーションが動詞にあたる）。

例えば、メモを書くのにLisaWriteの起動なんてしない。LisaWriteの版権はAppleにありますなどと書かれたスプラッシュ画面が出てきて流れを妨げたりしない。隅っこに飛び出てパタパタとうるさいペーパークリップもない。文書にどのテンプレートをコピーするかなんて訊いてきたりしない。

ただ「LisaWrite」便箋を一枚引っぺがして書き始めるだけでいいんだ。補給品入れから紙を一枚取ってきて書きこむのと大して変わらないよね。これは、表計算プログラムのLisaCalcなどといった他のプログラムにも当てはまる。もちろん、最近のOSと同様、文書間のコピー・ペーストもできた。

文書のコピーを作ると、ファイルはまったく同じファイル名で出てくる！ これは今じゃ考えられないよね。最近のデスクトップは「～のコピー」ってことを示す名前に変えてしまう。もちろんこれは表面上のトリックで、しいて言うならデスクトップに表示されるファイル名とディスクに保存されるファイル名が異なるからだけど。でもユーザーにはこれで通じるし、肝心なところは考慮してある。

5MBのハードディスク全体をバックアップするには、そのアイコンを400Kフロッピーにドラッグするだけでいい（推測ではテープのアイコンにも――Lisaのテープドライブは見たことがないので、僕の想像だけど）。そうするとデスクトップ自身がファイルを複数のフロッピーに分けてコピーしてくれて、他にもありますかと訊いてくる。その上、フロッピーのサイズよりも大きいファイルをドラッグすると、それを複数のフロッピーに分割してくれるんだ。

文書の一部が入ったフロッピーを挿入すれば、他のフロッピーも必要だと言ってきて、ファイルを再構成してくれる。これも全て、簡潔さと一貫性を保つという意図が込められてのことなんだ。繰り返すけど、別個のバックアッププログラムを動かさなくていいし、すべてがまさしく文書中心になっていたんだ、プログラム中心ではなくてね。

一日の終わりにLisaをシャットダウンするときも、Lisaは開いたもの全てを記憶しててディスプレイ上の位置を保存する。電源を入れなおすと、全てを置かれていた場所に正しく戻してくれる。デスクの幻影はきちんとその姿を保っているんだ。実生活でいうと、月曜日に仕事場に戻ったときに電卓や時計が机の引出しに仕舞われてたり書類が散らかってたりしたら、気分良くとはいかないんじゃないかな。

今じゃ、Adobe Acrobatファイルとかウェブページを開いて途中まで読んで閉じた場合、後日開きなおしてもどこまで読んだのかはわからなくなってしまう。これ、じれったいよね。確かにハイバネーションやスリープモードを使えば回避できるけど、コンピュータを再起動した場合はやはり見失ってしまう。コンピュータはそれぐらいやってくれてもいいはずだよ、Lisaがやってたようにね。

残念ながらOS XもWindowsもそこまでやってくれない。僕個人の話をすると、場所を維持しておくのは仕事の流れの上で重要だから、できるだけ再起動を避けるようにしている――だけどそうすると、そう頻繁に触らない文書にもメモリ/スワップ領域を消費させられてしまう。

Lisaはおそらく、ソフトウェア制御の電源ユニットを備えた最初期のマシンの一つに挙げられるだろう。強制電源断スイッチなんてなかった。電源スイッチは、OSの関与の及ぶ間はキーボードにあるスイッチと同じように振舞ったんだ。これはMacではIIシリーズまで、PCでは1995年以降まで無かった。

Lisaは当時としては非常に先進的だった。LOS 3.xを載せればマルチタスクマシンになり、完全なオフィススイートの入った最近のマシンが持つ機能のほとんど全てをこなしたんだ――25年も前に。

Ted: 他にこれを言っておきたいということはありますか？

Ray: 理想を言えば、Lisaでも他のエミュレータでもかまわないんだけど、マシンを実際に使ったときとまったく同じものをエミュレータで体験してみたいな。これはまず無理だろうね、僕たちが気づいていない物理的フィードバック系はたくさんあるから――キーボードやマウスの感触だとか、最新の液晶ディスプレイにはないCRTモニタのフリッカーなどなど。

スキンとかサウンドエフェクトとかの領域で近づけることはできるけど、どこまでいっても完璧にはならない。体験の史的正確さこそが、このゲームでの得点につながるんだ。

「Lisaはいつでも私の憧れの、手の届かない存在でした、でもこれで当時そのままのものを手にすることができます」という溢れんばかりの喜びが詰まった電子メールを受け取るのは、何物にも替えがたいことだ。僕が費やした時間が全て報われたって実感させてくれるよ。

Ted: Ray、我々Low End Mac全員を代表してお礼申し上げます。僕は、あなたが本当に素晴らしいことを成し遂げたと確信していますし、こうしてお話できたのも光栄に思っています。ありがとう！

Ray: 喜んで。ありがとうTed。

"Interview with Ray Arachelian, Creator of the Lisa Emulator" by Ted Hodges, Mar. 13, 2007.
Vintage Mac Living articles copyright ©2005-07 by Ted Hodges. Entire Low End Mac site copyright ©1997-2007 by Cobweb Publishing, Inc., unless otherwise noted. All rights reserved. Japanese translation published under permission from copyright holders.
755174 submission
アップル

※タレコミ予告：Low End Macインタビュー

タレコミ by airhead
airhead 曰く、
タレコミ予告です。頃合をみて却下してください。

ここまでのあらすじ
  • Low End Mac (LEM) のインタビュー記事、Interview with Ray Arachelian, Creator of the Lisa Emulatorが面白そうだったので訳しました（ほとんど完了、文字数はMartin Taylor vs Roblimoの3/4程度）。
  • まず著者/インタビュアーのTed Hodgesに/.Jへの掲載許可を申請したところ、許可のついでにLisa Office System (LOS) / Lisa Emulatorの紹介記事Lisa Emulator Released, Allows OS X and Windows Users to Experience Apple's Lisaも訳さないかと言ってきました。で、訳しました（8割方完了、文字数は上記インタビューの1/3程度だが、元記事はスクリーンショット多数）。
  • 次にLEM/Cobweb Publishingの代表Dan Knightに/.Jへの掲載許可を申請したところ、こちらもすんなり許可が下りました。いずれも著作権表示はちゃんとすると約束しての申請でしたが、くれぐれもよろしくとのこと。
  • 先方からも、当のエミュレータ作者Ray Arachelianにも了解を得たほうが良いと言われたし、少々内容が把握できない部分もあったので連絡を取ってみたところ、快諾。疑問点への相当丁寧な解説とともに、この間RetroMacCastでも喋ってきたしそれも取り上げてくれないかと言われ、そのときのpodcastに入ってるURLリストのお土産を持たされました。それが昨晩。


で、
  • /.本家のものでもないので日記やwikiなどでの査読のための公開はしません（本家だったら良いってわけでもないだろうけど）。査読に対訳版が必要であれば「送れ」とairhead@users.sourceforge.jpに言っていただければそちらから送ります。
  • 紹介記事を採用する場合、
    • インタビュー記事と相互に張られているリンクがあるので、/.J掲載後にURL調整をお願いします。
    • スクリーンショットはどうしましょう。こんな感じ？ （LEMが外部から画像への参照をRefererで弾いているかは未確認。弾いてなくても画像については事前連絡したほうが良いか？）
      前 <img alt="altText" src="imgURL">
      後 <a title="altText" href="imgURL"> altText </a>
  • タレコミは早くても今週末になるかと思います。
  • 何かあれば日記かairhead@users.sourceforge.jpへご連絡ください。
758170 submission
インターネットエクスプローラ

※リンク先訂正依頼：IE7は「かなりよい」らしい

タレコミ by airhead
airhead 曰く、

編集者へ：先日の記事FirefoxのアーキテクトによるとIE7は「かなりよい」らしいにおいて、d'Arcさんによるタレコミ部分の最初から数えて2文目に、Blake Rossへのインタビュー日本語訳へのリンクが2つあります。

現在この日本語訳のリンク先として、ブログ『Mozilla Firefox Thunderbird の拡張あれこれ MEMO』の最新エントリページ内のアンカーを指しているため、このリンクをたどっても当該日本語訳に直接アクセスできません。

そこで同箇所の、以下の内容への訂正をお願いします。最新エントリページ（mon-extension-memo.html）から、2006年7月のアーカイブページ（mon-extension-memo.html）に変更しています。同箇所にある『拡張あれこれ MEMO』そのものへのリンクは、現状のままでよいと思います。この訂正がなされた場合にも、その旨の追記は不要と思います。

訂正後の内容：

日本語訳は、Mozilla Firefox Thunderbird の拡張あれこれ-MEMOにて公開されている (Blake Ross へのインタビュー、Blake Ross のインタビュー（その２）)。

訂正後のHTML：

日本語訳は、<a href="http://beau.g-com.ne.jp/mon-extension-memo.html">Mozilla Firefox Thunderbird の拡張あれこれ-MEMO</a>にて公開されている (<a href="http://beau.g-com.ne.jp/mon-extension-memo06_07.html#memo0676">Blake Ross へのインタビュー</a>、<a href="http://beau.g-com.ne.jp/mon-extension-memo06_07.html#memo0677">Blake Ross のインタビュー（その２）</a>)。
758466 submission
Windows

※ 切れていた(11)以降の追加分：Mike Nash@本家

タレコミ by airhead
airhead 曰く、
[編集者へ]
お手数をかけます。タレコミ時に(11)の途中で切れていたとのことなので、(11)の頭から最後の回答までを再送します。
[編集者へ終わり]

(11)
VISTAになってもユーザーは管理者でなければならない？
by arminw

現在のWindowsシステムでは、ユーザーが管理者権を与えられてないと正しく動作しないプログラムが数多くあります。MSはプログラムをそんな風に書く開発者に、普通のユーザーステータスで充分とするよう圧力をかけないのでしょうか？ 最近のマルウェアの多くはひっそりと、ユーザーへの警告程度のこともせずに自らをインストールします。VISTAに何らかの警告を取り入れて、いかなる実行ファイルであっても最初の実行あるいはシステム奥深くへのインストールが可能となる前にパスワードが求められるようにはなりませんか？ それらが信頼されているソースからのファイルと確認されない限りパスワードをタイプしないようにと、ユーザーに伝えるようにはなりませんか？

Nash: Windows Vistaにおける重要な機能強化の一つにユーザーアカウントコントロールと呼ばれているものがあり、それが働きかける一般的ユーザーには大げさな名前に聞こえるかもしれません。詳しく見てみるとユーザーアカウントコントロールは2つの部分からなっています。1つめはWindows Vistaに対して行われる大幅な変更であり、これによって、システムが管理権を要求すべきケースについてはシステムを保護しつつも、システムが管理権を要求すべきでない箇所で要求しないようにすることができます。ここで言わんとしていることをわかりやすく説明する簡単な例を挙げてみましょう。現在Windows XPでは、コントロールパネルの日付と時刻アプレットを開くのに管理者ユーザーである必要がありますが、今にしてみると、このアプレットを開くのにユーザーが管理者であるのを必須とすべきではない場合もあります。例えば、通常ユーザーでも時計を見ることができて当然です。さらに、（システムログの正当性を保つなどの理由から）システムの時刻の変更には管理者権限を要求すべきですが、私がシアトルからボストンに出張した場合に現地時間を間違えず会議に遅刻しないといったことのためには、私にもタイムゾーンの変更ができるようになっているべきなのです。

従ってVistaにおいて我々はそれらの機能を分離し、通常ユーザーがする必要のあることはできるようにしつつ、保護の必要なことについては管理者を要求するようにしました。

もう1つ加えられたものに、我々が被保護管理者 (protected admin) と呼んでいるものがあります。これは管理者ユーザーで動かすときのデフォルトとなっているモードです。あるユーザーが管理者に設定されていても、彼らの基本的な実行は通常ユーザーとしてのものになります。管理者権限が要求されることを彼らがしようとした場合、システムはそのタスクを実行するために管理者への昇格をしてもよいかユーザーに問い合わせて、ユーザーが同意すればそのタスクのみを昇格します（これはセッション全体を昇格するUnixにおいてのスーパーユーザをオンにすることよりもセキュアです）。タスクが完了するとこの高権限プロセスは引き剥がされます。昇格にパスワードを要求するようシステムを設定することもできます。

あなたが書かれたように、これはアプリケーションの互換性とも大きな関わりをもっており、独立系ソフトウェアベンダ (ISV) がVista向けソリューションを作成する助けとなるよう、多大な作業が行われています。彼らのアプリケーションが通常ユーザーで動くのが適切なら、その動作を確実にしなければなりません。

既存のもの（レガシーアプリケーション）についていうと、ほとんどのアプリケーションは次の4つのカテゴリーに分かれると考えられます。1) そのままでも通常ユーザーできちんと動作するアプリケーション、2) 管理者権限を実際に必要とするアプリケーション（例えばシステムユーティリティ）、3) 管理者権限をチェックするが、実際には必要としないアプリケーション、4) 機能の一部において管理者権限を必要とするアプリケーション。

通常ユーザーで動くアプリケーションについては、我々は何もしません。同様に、管理者権限を実際に必要とするアプリケーションはしかるべき条件で動作します。そういったアプリケーションに通常ユーザーが遭遇した場合、家庭（すなわち、ドメインに属さないシナリオ）で通常ユーザーは、そのアプリケーションが適切に動作するようシステム昇格を行うために、管理者権限をもっている者にパスワードを入力してもらうよう促されます。我々はこれを「肩越し」昇格ケースと呼んでいます。

管理者であるかをチェックするが実際には必要としないアプリケーションについては、そのアプリケーションの開発者が通常ユーザーおよび管理者ユーザーの両モードでのテストに時間をかけたくないため、初期化時にチェック手続きが設けられている、という状況が一般的です。我々はそれらアプリケーションの詳細なリストをまとめており、我々が把握しているものについてはソフトウェアに小さな互換性修正 (shim) をそえることで、ユーザーが管理者レベルで動かしているかのチェック時に通常ユーザーであってもシステムが応答するようにしています。ユーザーは実際には通常ユーザーのままであり、こうすることでアプリケーションの互換性を保ちつつ、不正な昇格のリスクを避けることができます。

実行の一部において管理者権限を必要とするアプリケーションについては、大半のユーザーにおいて昇格に遭遇することがなくなるようにISVに向けた手引きを提供しており、その中で、最終的に権限を必要としないと見られるコンポーネントと必要とするコンポーネントとを区別してコンポーネント化するために、どのようにアプリケーションを再構成すればよいかを示しています。

(12)
OpenBSD
by hahiss

OpenBSDが非常に少ないリソースで設計から非常にセキュアにできているのに、Microsoftのリソースを総動員してもセキュリティ問題の大波を堰き止められず、すべての者に、Microsoftのプログラムを使ってない私たちにまで影響してるってのは、どうなんだろうね？

Nash: まず最初に、OpenBSDにはWindowsに含まれている機能の比較的小さなサブセットしか含まれていないことを指摘しておかねばならないでしょう。MicrosoftはWindowsにおいて、OpenBSD Orgが彼らのOSにおいて従っているのと同じモデルに従うべきだ、と主張されるかもしれません。問題となるのは、ユーザーがOSに切実に求めているものにはリッチメディアコンテントやハードウェアデバイスなどのサポートが含まれる、ということです。OpenBSDはカーネルを強固にすることに上々の実績をあげていますが、PHPやPerlなどといった、顧客によって広く使われている重要なソフトウェアについてもセキュリティ脆弱性の監査を行っているとは思えません。我々Microsoftはソフトウェアスタック全体、つまりはWindowsのハードウェア抽象化レイヤから始まって、メモリマネージャ、ネットワークスタック、ファイルシステム、UIおよびシェル、Internet Explorer、Internet Information Services、コンパイラ（C/C++、.NET）、Microsoft Exchange、Microsoft Office、Microsoft SQL Server、その他多くの全行程に焦点をあてています。ソフトウェア企業が顧客をセキュアにすることを目標とするなら、スタック全体をセキュアにしなければなりません。一つのコンポーネントを強固にするだけでは、それがいかに重要なものであろうが、実際に顧客が抱えている問題を解決しないのです。

第2に、OpenBSDのほうがセキュアだという表現は、完全に正しいといえません。脆弱性の数は過去3ヶ月だけを比較してみても、OpenBSDが11月、12月、1月で79あったのに対して、Microsoftは11でした（加えて、そこにはOfficeとExchangeそれぞれのものが含まれています――ですからWindowsの全バージョンについては実際には9です）。OpenBSDのサイトで報告されている数をご覧になって、これが本当か確かめてみることをお勧めします。

(Mike Nashが追加した「おまけ」の質問)
Windowsと他の雇い主の違い
by eldavojohn

Nashさん、Microsoft Corp.とData General Corp.というあなたの直近の勤務先2つで、一番大きな違いと一番似ているところはなんでしょうか？ これが一番訊きたいところですが、違いはあなたから見てどれだけ抜本的なものだったのでしょうか？（仕事の役割が変わったという様なことじゃなくて、一般的な違いについてです） 何が一番気に入って、何が一番いやでしたか？

Nash: いい質問です。まず、DGに働いていたのは結構前のことなんですよ（ビジネススクールに行くためDGを辞めたのは1989年でした）。とはいっても、DGは本質的にハードウェアの会社で、Microsoftはなによりもまずソフトウェア第一の会社だというのが、もっとも大きな違いに挙げられるんじゃないかと思います。DGはまず第一にハードウェア販売を事業の柱とすることに注力していて、ソフトウェアも商売上欠かせない要素だったのですが、それ自体に価値を見出しているわけではありませんでした。これと対照的にMicrosoftの基本的な前提は、どんなに難しい問題でもソフトウェアで解決するのがベストであり、さらにいうならハードウェアの力は優れたソフトウェアがあってこそ引き出される、というものなのです。

次に大きな違いは、DGがいつも他の会社との対比において自身を測っていた一方で（私がData Generalにいた頃、Digitalは一大関心事でした）、Microsoftは常に自己改革をしようとする会社だということが挙げられます。結果としてMicrosoftはより自己批判的ではありますが、それと同時に新たな機会と欠落、この両方に対処するための長期的投資も惜しみません。信頼できるコンピューティングイニシアチブがとてもよい例といえます。Blasterは登場して間もなく（Microsoft内外で）多くの人が私に、Blasterは、信頼できるコンピューティングイニシアチブが失敗したことの証しじゃないかと訊いてきました。私の反応は正反対でした。セキュリティを向上させるため時間をかけて注力してきたことに、私は心底喜んでいたのです。もしそうしていなかったら、事態はかなり悪化していたことでしょう。と同時にBlasterは、信頼できるコンピューティング (TwC) に関して我々がなさねばならない変更についての、いくつかの明確な指針を与えてくれました。何よりも、我々が学び続けるとともにTwCにも大幅な変更を加え続けなければならないことを皆に思い知らすことになり、それを計画に盛り込みさえすればよかった。このアプローチは主として企業文化から来るものであり、率直に言わせていただくと、DGの指導者が同じような視点を持っていたら今もDGとして存続していたかもしれません。Microsoftに30年以上も大きな変化と革新があった理由は、これに尽きると思います。ええもちろん、きつい仕事ですよ。

758506 submission
Windows

※差し替え：Microsoftのセキュリティ技術部門VP、Mike Nash@本家

タレコミ by airhead
airhead 曰く、
[編集者へ]
毎度毎度すみません、次の2点を修正した差し替えです。前のタレコミは却下してください。
・Webcast「Security360」の英語版は登録が必要で、そのことを導入部の人物紹介に追記
・「DREAD」に関する訳注を若干修正

MSの組織再編でインタビュー時から配置転換があったようですが、Security Business & Technology UnitからSecurity Technology Unitに変わっただけのようだし、新しい役職を表記するだけに留めています。
追加トピック案：「Microsoft」「セキュリティ」「ビジネス」
[編集者へ終わり]

今回はMicrosoftのSecurity Technology Unit担当バイスプレジデント、Mike Nashへのインタビューです。彼は同社のセキュリティ施策を推進してきた中心人物の一人で、同社のWebcast「Security360（要登録 / 日本語字幕版では登録不要）」でホスト役を務めたりもしています。
時期的にもまず「Vistaでセキュリティ面が具体的にどう変わるのか」が気になるところですが、その他にも、ソフトウェア開発段階での取り組みとその内幕、サードパーティへの働きかけ、平均的ユーザーとマルウェア対策、FOSSに対する見解などが話題に上っています（原文）。

(1)
何が変わった？
by suso

PR部門が原稿を用意する毎度おなじみの回答、要するに、実際のところを隠したり控えめに言ったりするために企業が提供したがるようなものは要りません。Microsoftがセキュリティへの注力を増しており、Vistaが以前のWindowsとは異なったものになるということについて、あなたが断言できるものはありますか？ どんな裏づけをお話しいただけますか？ 「新チームを編成しXをしている」「変更箇所のレビュープロセスはXまで行われている」というような情報は、この質問に答えるうえで有用なものと思います。それとは別に、MSがVistaを開発する過程であなたが目にした、以前の製品におけるあなたの開発のやりかたとの違いはなんでしょうか？

Nash: 我々はMicrosoftで長きに渡ってセキュリティについての考察を重ねてきました。その始まりは、Windows NTをやろうと決めた90年代初頭にさかのぼるかと思います。我々のセキュリティへの取り組みを、よりいっそう深いところから始まる品質の視点に立つものにするという大きな転換があったのは、2002年、Billが「信頼できるコンピューティング」メモを書いたときのことでした。

これを契機として我々は、顧客にとってセキュリティが重大な問題となっていたことを受けて、セキュリティへの注力を大幅に増強することを決めました。思い起こしていただきたいのですが、我々はCode RedやNimdaで後手に回っており、何か手を打つ必要がありました。.NET Framework 1.0、Visual Studio 2002、ASP .NET、Windows Server 2003に対してはセキュリティプッシュとして始まり、製品開発サイクルの比較的後期にあった各チームと個別に面談し、セキュアなコードを書くことの重要性を彼らに説き、彼らに脅威モデルとコードレビューさせる、などを行いました。

これが、セキュアなコードを書くことの重要性について我々の技術者を教育すること、そして企業文化を変えることとどれだけ関わりがあったかを振り返ると、興味深いものがあります。両方の例を挙げてみましょう。

2年か3年前のことになりますがWindows Media Playerに、著作権フィールドを偽造したメディアコンテント片の送信を攻撃者に許すという脆弱性がありました。著作権をパースするコードの欠陥が原因で、攻撃者がバッファをオーバーランさせてマシン上で任意のコードを実行する可能性があったのです。ここで問題となるのは、Windows Media Playerの開発者はその類の攻撃を想定しておき、防止手段を講じておくべきだったか、というものです。考えてもみてください、我々は彼らに、Windows Media Playerを世界一のメディアプレイヤーとするように書いてもらいたいのです。答えは紛れもなくイエスです！ 組織の面倒を見るタイガーチーム[*]を配して我々が出荷する一つ一つの製品のすべてのコードをレビューさせてもいいでしょうが、それでは追いつきません。どれだけセキュリティの専門性を高めても、これで充分ということにはならないでしょう――彼らにしても、よりセキュアにしようとしているコードの詳細を完全に把握することはできず、変更を加えることは何かを壊すことになるかもしれないのです。これは最終レビューには有効ですが、最終レビューというものは道路脇のガードレールのようなものでなければなりません――最後の頼みの綱としては結構ですが、我々に必要なのはより良いドライバーです！ ですから我々は全員を鍛え上げたのです。ここで重要なのは、時を重ねるごとに新しいものを学びもするから（より良いツール、新たな脅威の方向性、新たなシナリオ）、トレーニングも継続的に最新のものにしなければならない、ということです。
* 企業などからの依頼を受け、クラッカーが使う攻撃手法を用いてネットワークシステムの欠陥を調査する専門家チームのこと。こうした合意のもとに行われる侵入テストは「倫理的 (ethical) 侵入テスト」などと呼ばれる。

企業文化というのもまた非常に大きな問題です。Microsoftは、技術に、ビジネスに、競争にと、それぞれに並々ならぬ力を注ぐ企業です。数あるグループに対してセキュリティを優先事項のリスト上位に置かせるというのは、Microsoftでは変えるのがこの上なく難しいことだったのです。4年前の私といえば、競争圧力があるとか特定時期に出荷することをパートナーに約束しているとか、そういった理由をつけてセキュリティレビュープロセスを経ることはできないと拒みつづけるチームと頻繁に会談を重ねねばならないのが常でした。現在は、概ね、皆からの理解をもらっています。いまや我々にとって、セキュリティが競争力およびビジネスにおいての優先事項なのは明らかなのです。いまなお例外を求める者からの上申を目にすることはありますが、その数は極めて少なくなっています。4年前からの大きな変化の一つは、私がノーと言った場合に組織上層部から大きなサポートを得られるようになったことです。

2003年のBlasterの経験は重要なものを生み出すこととなりました。セキュリティ開発ライフサイクル (Security Development Lifecycle - SDL) と呼ばれているものです。実際のところSDLは、我々が以前からしていた作業を制度化したものです。思い出していただきたいのですが、BlasterはWindows Server 2003の脆弱性を突いていました――これはセキュリティプッシュを通過した製品でした（Windows XPにも影響していました）。脆弱性がどのように発生したのかについて事後分析を行ったときに判明したのは、コードの品質においてWindows 2000とWindows Server 2003の間に大きな飛躍があるにもかかわらず我々にはまだやるべきことがある、ということでした。特に、1) 文書化され反復可能なプロセス 2) 製品リリースプロセスに関与する全員が何をすべきかを理解しているようにするための社内教育 3) このプロセスを継続的なものとするためのリリースプロセス中のチェックポイント、これらを整備する必要がありました。

SDLにおいて鍵となるのは、基本的に6ヶ月毎に更新していく必要がある、ということです。これは、脅威の情勢は変わり、我々がサポートするシナリオは拡大し、我々もさらに学ぶという理由によるものです。

Windows Vistaを素晴らしいものとするために鍵となるのは、最新のSDL――さらなるトレーニング、より新しいツール、脅威モデリング、ファイルパーサに関するより包括的なレビュー、禁じられている（危険な）APIの使用を特定して除去するためのコードのレビュー、そして数多くの侵入テスト――これらすべてを最大限の厳格さをもって実施することです。

この一環として、デフォルト設定をより安全でセキュアなものとする変更についても多くの作業が行われています。通常ユーザーにとってシステムが問題なく動作するように（そのことによって誰もが管理者ユーザーとならなくてもいいように）多くの作業を行っていますが、管理者としてシステムにログオンする必要が依然としてあるユーザー、またはそうしたいユーザーを考慮して、彼らが管理者権限を必要とすることをしようとした場合にもそのことが明確にわかるようにしています。ユーザーはシステムを設定しておくことで、システムがユーザーを昇格させる場面での、昇格を望んでいるかの確認、もしくはパスワードの要求、このどちらも行わせることができます。またVistaのシステムサービスすべてについて、どれが管理者権限を持っているかを調べ、どれが本当に必要としているかを検証しており、必要でないものについては剥奪しています。

Windows Vistaのために我々はエンジニアリングプロセスを強化し、エンジニアリングサイクルにいくつかの新しいチェックポイントを設けました。そういったチェックポイントの一つはVistaのシステムサービスを開発するチームに、新たなVista最小権限オペレーショナルモデルを使用するというプロセスを要求します。各サービスのための計画については社内専門家チームの承認を受けねばなりませんし、代替のアプローチが可能な場面で開発チームがサービスそのものの作成を回避したというのは、かなりの件数に上ります。

セキュリティと安全を向上させるうえでの重要なアプローチとして品質が挙げられるとはいえ、それはその一部分にすぎません。Windows Vistaをさらにセキュアで安全なものとするために、我々はいくつかの重要な機能を加えてもいます。例えば我々は、GIANT Company Softwareから獲得した対スパイウェア技術を採用して改良し、Windows Defenderとしてオペレーティングシステムに統合しました。この対マルウェア技術はWindows 2000およびWindows XPの正規ユーザーにも提供されますが、Vistaに対しての統合は非常に円滑なものになり、顧客にとって保護を受けるのはかなり容易になります。Vistaについて、我々はオペレーティングシステムに組み込まれるファイアウォールの改良も行っています。これは双方向性のもので、IPSecとも上手く機能するよう設計されています。

変化を続けるインターネットでの情勢、そして継続してWindowsプラットフォームに向けられる照準を考えると、残念ながら今後もWindows Vistaを標的とする脆弱性や攻撃が存在するものと思います。これからも怠ることなく、Windows Vistaの脆弱性をよりいっそう見つけにくく、攻撃しにくくしていくことが、1) Windows Vistaにおいて脆弱性および攻撃の両方の数と深刻度は下降し、セキュリティのみを判断基準とするならばVistaへの移行は避けられないものとなる 2) Windows Vista後に登場する製品をさらに良いものにするべく、Windows Vistaの出荷後もセキュリティへの注力を継続する、この2つに繋がるものと確信しています。

(2)
セキュリティ/ユーザーフレンドリーのトレードオフ
by qwijibo

Microsoftにおいて、製品チームがセキュリティに関して一貫した決定を下すのを促進するような全体的なポリシーはありますか？ しばしば問題になっていますが、決定の内容をもっとセキュアにすべきということもあれば、もっとユーザーフレンドリーにすべきということもあります。

例えば、ファイルとプリンタの共有のデフォルト値をオフにしておくことで、知らず知らずのうちにリソースを共有してしまうことを防げますが、小規模ネットワークを構成したいと考えている技術に明るくないユーザーに対しては、その方法に関する知識を以前のバージョンよりも要求することになります。

Nash: これは古くからある問題で、我々としてもかなり前進してきています。Microsoftにはデフォルトでオンに設定するという長き伝統があったわけですが、その背景としてはユーザーの活用を容易にする、それに我々の目玉機能を誇示する、というものがありました。過去を振り返ると、実際に私も問題の一端を担いでいたことについて認めざるを得ません。1995年、私は製品管理ディレクターとして、Windows NT Server 4.0において我々のウェブサーバInternet Information Server (IIS) をデフォルトでオンにするという決定を下したチームの一員でした。

ここ5～10年の出来事が我々に（少なくとも私に）残した教訓は、オンにすればするほどシステムは表面の攻撃範囲を広げてしまい、それゆえにより脆弱になってしまう、というものです。完全に近い品質を、もしくは攻撃を試みる者がいないことを想定するなら、それでも問題なしの決定といえるかもしれません。しかしそれは無理というものですし、デフォルトで何をオンにするかについて、我々はより厳しく選択することを求められています。

Code Redのケースを考えてみましょう。このワームは、IISのインデックスサーバのISAPIフィルタにおける脆弱性を攻撃するものでした。ここでちょっと、IISのインデックスサーバのISAPIフィルタが何であるかをあなたは知らない、もしくは気にしない、という場合を想像してみてください。そんなケースであろうが、Windows Server 2000 SP3のIndex Serverを止めてもISAPIフィルタはインストールされたまま、ということが判明しています。あなたはインデックスサービスを停止すれば脆弱性は軽減すると思われるかもしれませんが、そうではないと判明しているのです。

ですから我々はCode Redでのあらゆる経験をふまえて、信頼できるコンピューティングイニシアチブ (Trustworthy Computing Initiative - TwC) を発足させました。セキュリティ開発ライフサイクルの原動力たるTwCの重要な原則の一つは、設計からセキュア、デフォルトでセキュア、導入してセキュア（Secure by Design, Secure by Default and Secure in Deployment - SD3とも）の原則です。

デフォルトでセキュアの原則では、ほとんどのユーザーが使っている機能でないかぎりデフォルトでオフにすべき、と謳われています。これに加えて我々がここに至るまでに学んだことは（先ほどのCode Redの例でもわかるとおり）、ユーザーに見える機能を検証するだけではだめで、その根底にあるサービスを検証する必要がある、ということです。カスタマー機能がデフォルトでオフなら（もしくはユーザーがオフにしたら）、それらを支える根底となるコンポーネントについても上位機能がサービスを使っていないときにはオフにすべきです。

しかしご指摘のとおり、これは一筋縄にいくことではありません。デフォルトでオフとするものを増やすなら、ユーザーが使いたいと思ったときに彼らがオンにするのを容易にしておく必要があります。例えば、Windows Server 2003 SP1において我々は、システムで不要なものを止めるときにユーザーが簡単に設定できるよう設計された、セキュリティの構成ウィザード (Security Configuration Wizard) を追加しました。デフォルトでオフとすることの利点は、1) 機能に脆弱性がある場合、デフォルトでオフになっていることで個々のシステムが攻撃から守られる 2) ワームやウイルスは機能がオンになっているとの前提をとれないゆえに問題の脆弱性を通じてそのシステムを広範囲に渡って攻撃できない、つまりはシステムの母集団も守られる、この2つがあります。

ここで言及しておかなければならないのは、我々が常々どの機能をオフにするかについて考えているとはいっても、デフォルトでセキュアの原則はどの機能をオンにするかに関わるものでもある、ということです。この好例がWindows XPのファイアウォールです。2001年にWindows XPを出荷した当初、ファイアウォールは入っていましたが、デフォルトではオフになっていました。なぜか？ そのことを伝えた影響力あるユーザーの多くが、既にファイアウォールを備えているし我々のものをオンにしてほしくない、と言っていたからです。我々のファイアウォールがデフォルトでオンになっていることで悪影響が懸念されるアプリが数多くある、とも言っていました。これは自前でファイアウォールを備えている、ユーザーの割合にして少数にとってはよい答えですが、顧客のほとんどにとっては誤りです。結果論になりますが考えてみてください、2001年10月から2004年8月（ファイアウォールをデフォルトでオンにしたWindows XP SP2の出荷時期）までの間にファイアウォールをデフォルトでオンにしていたら、SlammerやBlasterの問題はWindows XPの顧客に対してはあれほどの広がりにならなかったかもしれません。これはZotobに関しても当てはまります。余談ですが、サードパーティのファイアウォールを備えている顧客、あるいはサードパーティのファイアウォールをインストールするOEM、これらについては我々のものをオフにしても一向にかまいません。

Windows XP SP2で初登場したセキュリティセンター (Windows Security Center) は、適したセキュリティ機能がオンになっていること、適切に設定されていることをエンドユーザーが容易に検証できるよう設計されています。我々はこれをWindows Vistaにおいてさらに良いものする予定です。

これは（安全とセキュリティを第一の仕事とするという目標を皆に意識づける）企業文化に深くまつわるものであるのと同時に、それと同じくらい、（機能のデフォルト状態については必ず、大部分の人が必要とするのは何かという背景のもとに検討されるようにする）プロセスにまつわるものでもあるのです。

(3)
2006年のセキュリティ最優先事項
by Anonymous Coward

ITマネージャの関心において最近ではセキュリティが主要な話題となっており、出版物によっては事実上、一面記事がセキュリティの欠陥やパッチで占められているような状況ですが、あなた自身および業界全体にとって、2006年は何がセキュリティの主な焦点になるとお思いでしょうか？

Nash: 私、そしてMicrosoftにとっての答えはシンプルです。2006年のセキュリティの主な焦点は、Windows VistaとWindows Longhorn Serverにおけるセキュリティ品質と機能を、確実にモノにすることです。誤解しないでいただきたいのですが、何もこれは以前の製品やWindows以外の製品のセキュリティに注意を払わないという意味ではなく、Windows VistaおよびWindows Longhorn ServerはWindowsのリリースとしては過去5年程の中でも最も重大なものになることから判断して、しばらく間は数多くのユーザーに幅広く使われるものとなると認識しているのです――ですから、きちんと決着をつけることは重要なのです。

上に書いたようにいま我々は、セキュアな設計、脅威モデル、コード品質、デフォルト設定、侵入テストといったものにおいてのベストプラクティス、さらには過去に類を見ない厳格さを適用すべき時にいます。システムをより安全でよりセキュアにするために、双方向ファイアウォールやWindows Defenderといった新機能の追加も行っています。我々はプロジェクトが機能の完成に近づく間にも、システムがセキュアであることを検証し、テストで見つかった問題の解決に取り組まねばなりません。

ここには業界に関しての難作業もあります。このうちいくつかは、アプリケーションやセキュリティ製品がWindows Vistaで動くのを確認しつつ行わねばなりません。新しいアプリケーションは、通常の（管理者でない）ユーザーアカウントを持つユーザーの元できちんと動作する必要があります。同時に、セキュリティ製品がWindows Vistaできちんと動作するのを確認しておく必要があるのです。例えば、Windows Vistaできちんと動作する優れた対ウイルスソフトウェアがないとなれば、誰もWindows Vistaに移行しようとはしないでしょう。

業界に関しての私のもうひとつの目標は、サードパーティのアプリケーションや組織内で開発されるアプリケーションが我々のセキュリティ開発ライフサイクルを採用することです。理由はこうです――我々がWindowsの品質を高めるにしたがって、その脆弱性を見つけにくく、それによって攻撃を書きにくくすることになります。結果として、セキュリティ研究者や攻撃の作者はスタックの上層に移るという当然の傾向を見せるでしょう。これはすでに確認されています。我々が学んだように、ここで機能する唯一のアプローチは、広範な教育によってもたらされ説明責任を果たすため出荷に先立って検証される、入念に定義されたプロセスに始まるのです。ここで朗報ともいえるのは、我々が自身のプロセスを非常に明確に文書化して学びやすいものにしている、ということです。これについて詳しくはMSDN Security Developer Center（日本語ページ）をご覧ください。

顧客にとっての最優先事項は間違いなく、自らのセキュリティプランを策定し施行することでしょう。私は顧客とともに非常に多くの時間を過ごしていますが、彼らの多くは自らの環境における脅威の分析を行い、セキュリティプランを作り上げていました。とはいえ意外な数の顧客が、プランはあるが施行する機会を逃しているというのです。なによりなことに、大半はセキュリティプランを施行しています――ですから彼らにとっての第一の目標は、自らの環境を見直して新しい脅威に確実に対応できるようにすることです。我々は、顧客（開発者、IT管理者、エンドユーザー）が我々のプラットフォームにおいてさらにセキュアとなるために役立つ、優れた一連のツールの作成も行っています。

我々は顧客がWindows Vistaを評価対象とすることを望んでいますが、いまだWindows XP SP2を導入していない顧客、特に企業顧客がその導入を真剣に検討することは、とりわけ重要です。企業顧客の多数がWindows XP SP2を導入している一方で、まだしていないという顧客も多い。今後Windows VistaまでにすべてのデスクトップがWindows XP SP2にアップグレードするわけではないと理解してはいますが、ラップトップおよびインターネットに直接接続するデスクトップをSP2にすることは、きわめて重要だと考えています。

(4)
セキュリティにおける外からの影響
by kalpol

Linuxのようなオープンソースソフトウェアは、Windowにおけるセキュリティについてのあなたの考え方に影響を及ぼしたか？ であれば、どのように？

Nash: オープンソースのアプローチは私のセキュリティに対する考え方に影響を及ぼしましたが、それはあなたが予想するようなものではないかもしれません。2002年後半にいくつかあった反Microsoft PRを導く前提として、目が多いほどソフトウェアはセキュアになるという論がありましたが、それは私のチームや私自身の反応を引き出すものとなりました。私はその第一歩として、私が見逃しているものを見極めようとオープンソースのプロセスを調査し理解することから始めました。

私はいくつかのことを学びました。学んだことの1つめは、多数の人にコードを調べさせると時に問題点を見つけるが、問題を完了するのに良いプロセスを取らなくても咎める者はいない、ということです。私はLinuxコードのレビューについて書かれているLinuxのウェブサイトをいくつか時間をかけて読みました。驚かされたのは、1) ソフトウェアのレビュー方法における一貫性の欠如、2) それらが実際に解決されたことを検証する説明責任の欠如、この2つです。10ヵ月経って2003年、Blasterに見舞われて私は、Linux同様に我々も完了のあいまいさから不利益を被る可能性がある、と実感しました。これを受けて我々はセキュア開発ライフサイクルを作り上げ、その重要項目として、一貫性と説明責任を推進することを挙げたのです。その背景にあったのは、こういう話です…

Blaster発生後に私は、悪用されたバッファオーバーフローについての責任を問うべき者を割り出し、その者の説明責任を確保したいと考えました。しかし詳しく調べてみると、失敗の回避につながるように開発者が従うことになっている文書化されたプロセスもなければ、個々のセキュア開発プロセスが活用されているかを検証するような開発者を対象とした一連の手続きもない、と判明したのです。セキュリティ開発ライフサイクルは基本的に、まさにそれらの、文書化され反復可能なプロセス、明確な教育、そして説明責任を制度化したものです。ここで学んだのは、我々にはマネジメントのすべてのレベルにおいてプロセスを制定し拡充する能力があるのだから、オープンソースのアプローチに模倣できないことを我々のソフトウェアに対して行う機会があったのだ、ということです。

セキュリティに関してオープンソースのアプローチから学んだことの2つめは、有用性 (serviceability) についてです。オープンソースアプローチの支持者が常に挙げることの一つに、オープンソースでは公式パッチを待つ必要がない、コードをダウンロードしてリコンパイルして自ら修正できるから、というものがあります。それはほとんどのユーザーには到底できないことでしょうし、幅広く有効であるとは思えません。うまく自前のパッチを作ることのできる顧客にしても、次のような問題があります。ディストリビューションが新しい修正でコンポーネントを更新するようなことがあっても、比較的精通しているユーザーがすでに自前で済ませているかもしれない修正がそこに含まれているとは限らない。これでは実質的に、自家製パッチを取り消すことになってしまいます。

私が学んだ事柄で鍵となるのは4つ挙げられます。第1、我々の更新がサポートされる全バージョンおよびサポートされる全言語に同時に用意されることは、きわめて重要である。第2、脆弱性が公に開示されるときに我々の更新が用意されているのを確実とするために、できる限りの事をする必要がある。更新を発行するときの謝辞と引き換えに問題を我々に内密に報告することもできるわけで、信頼できる開示は我々にとって大きな助けになります。第3、更新を発行するときには品質の高いものにしなければならない。我々の更新が問題を起こせば更新への信頼が揺らいでしまいます。我々の製品を私が定義づけるとしたら、我々が出荷する製品プラス最新のサービスパックプラス最新のサービスパック後に我々が出荷するあらゆるセキュリティ更新、となります。もし我々がセキュリティ更新を幅広いシナリオでテストしなければ、何らかの問題を起こす可能性は大いにあるのです。

最後に（第4）、更新の導入プロセスを簡略化するツールを用意することは重要である。これによって更新を導入する際の障害を減らし、顧客が最新の状態にあることの公算を引き上げることになるからです。我々がWindows Update、Microsoft Update、Windows Server Update Services、Systems Management Serverのような、パッチ導入を大幅に分かりやすいものにするツールに注力してきた理由は、ここにあるのです。

(5)
Microsoftセキュリティの基本的アプローチとは？
by kickabear

悪用されうるバグを避ける方法としてMicrosoftは、厳格に施行されるコーディング規則をより重んじる傾向にあるのだろうか、それとも、テスト期間におけるしらみつぶしのバグ検出をより重視しているのだろうか？

簡単に答えるなら「もちろん両方」となるだろうが、50/50に割れるというのは考えにくい。で、テストが後部座席にまわるのか、それともコードが？

Nash: 手短に答えるなら実際のところ、3つめの選択肢、つまりはより良い設計になります。これは、ある機能がシステムに持ち込むかもしれないセキュリティ脅威をきちんと理解すること、そして機能やコンポーネントの設計がリスクを低減するのを確実にしておくこと、これらから始まります。しかる後に我々は実装に移りますがその一部分として、あなたの言われる通り、より良い規則も関わってきます。これは教育を通じて伝えられねばならないものですが、コード品質を検証するツールでの補強は可能な限り行われねばなりません。

我々は倫理的に行われる侵入テストおよびインターフェイステストについても、それぞれ多くの時間をかけて行っています。バグの検出は重要ですが、それはあくまで最後の頼みの綱です――ある意味、ソフトウェアエンジニアリングという道路を安全にドライブするための道路のガードレールなのです。悪条件の道路で運転することと同じく、安全はドライバーへの（この場合開発者への）より良い講習から始まるのです。

とはいうものの、この仕事をしていて過去5年間に学んだものを一つだけ挙げるとすれば、セキュリティに銀の弾丸はない、これに尽きます。我々はそれに替わって、数々の投資を通じて前進をしているのです。

(6)
なぜDRMを加える？ また、なぜIEを分離しない？
by Bob_Villa

なぜ君らはVistaに、標準的ユーザーが欲しがりそうにないDRMコントロールを加えようとしているんだ？ 自社ドキュメントをコントロールしたい企業にとっては便利かもしれないが、自身のドキュメントやファイルを制限する製品と知りながらも欲しがる標準的ユーザーがどれだけいるか、私には疑問だ。

それと、WindowsからInternet Explorerを分離することでセキュリティを劇的に改善できるんじゃないかと思う。Opera、FireFox、Safariなどと同様、別個のプログラムだったら… Windows ExplorerがInternet Explorerで動いていることに、正当な理由なんてあるのだろうか？

Nash: まず最初に、一点だけ確認しておきましょう。この場合、あなたがいっているのは現在Windows Vistaに統合されているRights Management Services (RMS) クライアントを指しているのであって、以前からWindowsに組み込まれていてメディアコンテントを保護するのに使われているDRM技術ではない、と思います。RMSの場合で話を進めますが、おっしゃる通り、企業は自らの情報を保護すること、情報の使用をコントロールすることに価値を見出しています。RMSの現行バージョンを使っている顧客からのフィードバックの重要なものとしてセットアップが難しいというのがあったので、我々はRMSクライアントをWindows Vistaに統合したのです。とはいっても、顧客によってはそれを使わないかもしれません。OfficeのようなRMSを利用するアプリケーションがインストールされていて、Officeのその機能を使うとユーザーが選択した場合に限って、使われることになるでしょう。

また我々は、いずれ標準的ユーザーも自身の情報を保護したいと思うようになる、とも考えています。例えば将来ホームユーザーも、友人のリスト、写真、銀行口座情報、その他の個人データといった情報の使用を保護しコントロールしたいと思うかもしれません。

Internet Explorerにまつわる質問については、現実的には2つの側面があります。1) WindowsにIEを備えることの背景にあるプラットフォームの密接な関係、および、2) WindowsにIEを備えることで可能となるユーザー体験、です

プラットフォームの視点からいえば、IEの分離は多くのものを後退させるでしょう。HTMLのレンダリングやインターネットへのアクセスをIEに依存しているアプリケーションは数多くあります。考えてみてください、電子メールアプリケーション、AOL Explorerのようなインターネットを扱えるクライアント、あるいはMicrosoft Moneyでも結構です。これもアプリケーション内でHTMLを描画するのにIEを使っているのです。IE分離は多くのアプリケーションを後退させるだけでなく、そのことによって自前のHTMLレンダリング機能を書かねばならなくなる開発者の、大きな負担にもつながるのです。

体験の視点からいえば、かねてからのWindowsの重要な目標の一つに、ローカルの体験とリモートの（インターネットの）の体験をユーザーインターフェイスの観点から統合することがあります。オペレーティングシステムへのウェブブラウザの統合は、この体験を顧客に届けるうえで重要な部分を占めていたのです。我々にもっとうまくやれる分野といえば、リモートサイトによってやれるような類のものはローカルでやれることよりも少なくする、これを徹底することです――これは見知らぬサイト、信用していないサイトに関しては、何を差し置いても当てはまることです。Windows Vistaに向けたIEの重要な強化の一つに、保護モードなどと呼ばれているものがあります。IEは当初、システムとユーザーリソースへのアクセスを最小限しか持っていない状態です。例えば、いずれかのリモートサイトにアクセスしても、サイトはソフトウェアをインストールしたり、ユーザーのスタートアップフォルダにファイルをコピーしたり、IEのホームページや検索プロバイダの設定を乗っ取ったりするだけの権限を持ち合わせません。もちろん、ユーザーが他のブラウザを使うことと選んでもまったく問題はありませんし、他のブラウザをマシンのデフォルトに設定することも可能です。

我々がWindows VistaのIEにおいて行っている前進によって、現在皆さんがIEのセキュリティに抱いている懸念の多くが対処されるものと、私は確信しています。

(7)
「平均的ユーザー」に付き合ったりしてる？
by Caspian

私は繰り返し何度となく、エンドユーザーと会っています――御婆様方、「サッカーママ」タイプ、サラリーマン――そういう人のコンピュータは決まりきって、スパイウェア、ウイルス、その他のマルウェアがどうにもならないほど詰まっていて、その圧倒的大部分はMicrosoftのソフトウェアにあるセキュリティの欠陥を突くことを通じて感染しています。そういったコンピュータの除菌を、私はしょっちゅう任せられるんですよ。

あなたは（そしてあなたのチームのメンバーは）どのくらいの頻度で平均的エンドユーザーに付き合ってるんでしょうかね？ 大企業のセッティングにおいてだけじゃなく、中小企業において、そして（勝るとも劣らず重要な）世間の一般家庭のセッティングにおいて、ですよ。ジョー・アベレージ氏に付き合ってですね、Microsoftのソフトウェアにある特定のバグや設計上の決定（例：ほとんどのエンドユーザーが管理者権限で動かしている事実）を突かれることで、（彼個人のプライバシーや彼のデータの品位はさておき）彼のコンピュータのパフォーマンスがどれだけ酷いことになっているかを見さえすれば、Microsoftのセキュリティ戦略に重大な転換を迫ることにもなると思うんだけどなあ。

$LATEST_WINDOWS_VERSIONは前任者よりセキュアですよと何度となく謳われているにもかかわらず、私ときたら相変わらず平均的一般家庭に呼び出されて、Internet Explorerの穴（および/または設計上のマズい決定――例：ActiveXコントロールの扱いとそれが持ちうるシステム上のファイルを変更する能力）を通じてWindowsシステムに感染した数え切れないスパイウェアの類を除去しつづけてるし、（対ウイルスソフトウェアが広く利用されていることに反して）いまだに私が調査したエンドユーザーのシステムのほとんどから（Microsoft Outlookを通じてシステムに入り込んだ）ウイルスが少なくともいくつか見つかるような有様です。

ジョー・アベレージ氏のPCをセキュアにするために、あなたは何をしてくれてます？ 平均的ユーザーと少しでも交流を持つことはありますか？ もしないなら、なんでないの？

Nash: 個人的に私は、かなりの時間を割いてエンドユーザーと接しています――たいていは友達や家族ですが、Microsoftでの仕事を通じて会う人たちもいます。私には妻がいて、兄弟3人、姉妹1人、義理の姉妹5人、義理の兄弟3人、両親、義理の母、義理の父、叔父1人、叔母2人、達者な祖母が1人、子供3人（皆PCを使うような歳になってないけども）、甥5人、姪7人がいますし、技術サポートを求める親族からの電話を数多く受けています。彼らのフィードバックが我々のセキュリティ戦略上の決定をどれほど左右してきたかを思うと、実際驚くべきものがあります。例を2つ挙げてみましょう。

Blasterの発生直後に叔父のKenが、その騒動で私がどうしているかを心配して電話をかけてきました。叔父にはちょっと変わったところがあって（とはいっても彼は私の唯一の叔父だし比較対照がいるとはいえませんが）ときどき私のことを「甥っ子」と呼ぶんです。で彼が言うには「甥っ子よ、最近のBlasterとかいうやつでオレは何をすべきなんだ？」 私は自動アップデートをオンに、ファイアウォールをオンにすべきと指示しました。そのやり方を彼が訊いてきたとき、私はいくつかダイアログボックスを挙げて説明し、彼にセットアップさせました。この過程で私は重要なこと2つを学びました。1つめは、それらの変更を行うのはなんとも面倒な作業だということ、2つめは、それまでにWindows Updateのデフォルト設定を変えておくべきだったということです。

2001年にWindows XP初版を出荷したとき、我々はWindows Updateの開始を発表しました。当時、ユーザーがWindowsをインストールしたときに選ぶことになっている選択肢が2つありました。1) 更新があれば通知する、2) 更新があればダウンロードしてインストールできる状態にあることを通知する（デフォルト）、この2つです。1年ほど経ってWindows XP SP1を出荷したとき、更新をダウンロードしてインストールするという3つめの選択肢を加えました。問題は、我々がこの3つめの選択肢（ほとんどの人にとって最善の選択）を加えたときにデフォルトを2つめの選択肢（ダウンロードして通知）にしたままだったことです。そうしていた理由はよくわかりませんが、おそらくは深く考える者がいなかったのだと思います。で、Ken叔父さんとの経験がどんな影響をもたらしたか？ いくつかあります。まず我々はProtect Your PCキャンペーンのページ（日本語ページ）を設けて、ファイアウォールをオンにする小プログラムの提供や、自動アップデートのために3つめの選択肢をオンにする手ほどきを行いました。また、Windows XP SP2において自動アップデートのデフォルト設定の変更も行いました。

2つめの話は私の祖母、Estelleにまつわるものです（私は42歳になるが、彼女をバアちゃんと呼んでいることを明かすのはプライドが許さん、ってこともない）。バアちゃんが最初にPCを買ったのは私がMicrosoftに入って間もない、1992年のことでした。1995年に彼女は2台めのPCを買い――私はWindows 95に夢中で、彼女もそうなったのです。2001年の暮れ、私が親族全員にメールを出して、Windows XPを動かしてないかぎりPCの面倒を見ないと言ったものですから、祖母は慌ててXPマシンを買ってきていました。

2004年2月、私はフロリダにいるバアちゃんを訪ねました。出張から帰る途中だったので、そこに1日ぐらいしか居られませんでした。彼女の家に着くと彼女は、朝食を用意してくれて曾孫の最近の写真を見て、それからPCの調子を見てもらわないとと切り出しました。電源を入れてみると、おかしなことになっているのは明らかでした。マシンは非常に遅くなっていて、デスクトップアイコンの1ピクセルづつ描かれるところが見えるんじゃないかというほどでした。

彼女のマシンはスパイウェアに極度に感染していたとわかりました。彼女はオンライン調査を受けることで$10提供するというメールを受け取っていて、7回もやってたのです。彼女は調査の回答を埋めて$10請求しようとするたびに自覚のないままに、あるソフトウェアライセンス条項に合意してスパイウェアを自らのマシンにダウンロードしていました。これでは彼女は、$900したPCを70ドルで売ってしまったのと変わりません。彼女のマシンを再び動かすのには3時間もかかりました。1ヵ月後再び彼女を訪ねてマシンにWindows XP SP2（当時はベータ）をインストールしましたが、スパイウェアに関しては我々のほうがずっと大きな問題を抱えているということに気づきました。

Microsoftの対スパイウェア戦略へのビジョンと対スパイウェアソリューションを提供することへの注力は、この訪問を機に始まったんです。

今では出張するとき、バアちゃんの家で出くわしたような状況への備えをもう少しするようになっています。Windows XPのService Pack 2、Windows AntiSpyware[*]の最新ベータ、悪意のあるソフトウェアの削除ツールの今月号、これらの入った512MBのフラッシュメモリをブリーフケースに入れて持ち歩いてるんです。
* Windows Defenderのこと。2005年11月Microsoftは、Windows AntiSpywareからWindows Defenderへの改称を発表している。

(8)
未登録マシンに対するWindowsの更新？
by Spy der Mann

拝啓 MicrosoftセキュリティVP様

私の知っているある人物は、Windowsの登録をしていません。彼のPCはスパイウェアがはびこっていて、私が推測するところではおそらく、彼のコンピュータはスパム送信、ウイルス拡散、その他諸々に利用されていたと思います。彼に技術サポートを頼まれたとき、私は彼にWindows UpdateからMicrosoft Anti-Spywareをダウンロードするように言ったのですが、彼の答えは登録が要求されるというものでした。

私の質問はこうです――もしWindowsの更新がインターネットを、ハッカー、スパイウェア、ウイルスから安全なものにするなら、なぜそれを登録済みWindowsに限るんでしょうか？ （私見ですが、これは鳥インフルエンザワクチンを不法滞在外国人に与えないようなものだと思います。）

これについて、どのようなプランをお持ちでしょうか？

Nash: これはいい質問で、我々が方針を定めるうえで苦心したものの一つです。まず、ひとつだけ明確にしておかなければなりません。Windows AntiSpywareはWindowsのライセンスユーザーのみに提供されますが、主に、非ライセンスWindowsシステムが感染した場合にそれがインターネットへの脅威を及ぼすのを避けるという目的から、優先度の高いセキュリティ更新はWindowsの非ライセンスユーザーにも提供しています。とはいえ、我々が非ライセンスユーザーに正規登録を呼びかけているのは言うまでもありません。

結局のところ、Microsoftの第一の責務は有償の顧客を守ることにあります。昨年1月、我々はWindows AntiSpyware技術をライセンス済みのWindowsの顧客に無償で提供するという決定を行いました。我々がGIANT Company Softwareを買収したときの計画では、スパイウェアのスキャンをMicrosoft.comの無料サービスとし、スパイウェアをブロックする技術を有料とする予定でした。頻繁なスキャンであればブロック能力に出費したくない人にとっての良い代替物になる、との考えがあったのです。対スパイウェア技術のベータを数週間運用するうちに、この仮説は成り立たないことが判明しました。というのは、スパイウェアの最初の感染を検知し除去するのは簡単だけれども、スパイウェアが他のスパイウェアを引き連れてくることはよくあり、第二第三の感染を検知・除去することはずっと難しいのです。というわけで我々はすべてのライセンス済みWindowsにブロック能力を持たせるという決定を下したのです。

ここで問題となるのは、なぜ非ライセンスユーザーをスパイウェアから守らないのか、でしょう。手短に答えるなら、スパイウェアが影響するのは主に感染したマシンだからです。ライセンス済みWindowsを所有することの価値に、スパイウェアから守られる、というのも含まれるのです。Windowsの所有にお支払いいただけなければ、保護はされません。

Windowsのライセンスを持たずに感染したあなたの知る人物に対して気の毒に思うというのは、私には無理な注文です。彼らは盗んだソフトウェアを使っているんです。Microsoftは大金持ちだから我々のソフトウェアを皆が違法に使っていようが構わないじゃないか、という理屈も耳にしています。まったく買い手のつかない話ですよ（シャレを言いたかったわけじゃなく）。他の様々なケースで議論することもできましょうが、レストランで食事して支払いをしないとかコンビニエンスストアでお菓子を万引きするとか電器屋からテレビを持ち去るとか、そういったことを我々は容認しません。今回の場合、あなたの知人はタダ飯を要求しつつ、なぜ我々がデザートをよこさないのか理解できないでいるんです。

もしあなたの知人たちが自家製の海賊版Windowsをインストールしているなら、私は彼らに正規製品を入手しインストールするよう勧告します。彼らのPCに海賊版Windowsがプリインストールされているなら、PCを売った会社について彼らに報告いただけなければなりません。我々はその情報を用いてベンダーに是正させるとともに、情報と引き換えにあなたの知人に正当なライセンスを発行いたします。

(9)
MSFT従業員参上
by Anonymous Coward

やあ、Mike、

君への質問は一つだけだ。なぜ僕らは、既知のセキュリティ問題を抱えたまま製品を出荷し続けてるんだ？

現場がどんなことになっているかを話したっていい。皆が製品を作ってる。「セキュリティプッシュ」と名のつくあらゆるものは、その終盤になって宣言される。彼らは2週間から3週間にわたり、潜在的セキュリティ問題を思いついてはそれにDREAD+VRスコア[*]を割り当てて、セキュリティに注意を払っているような振りをする。しかる後に管理者が自由裁量で「バー」を設定するが、これを下回るなら僕らは潜在的・顕在的セキュリティ問題を修正しない。このバーはたいていとても高く、8あたりに設定されることもあるが、それは見つかったすべての問題を修正する時間をスケジュール内に都合できる者がほとんどいないからだ。ちなみにDREADスコアが8というのは、欠陥が大多数の顧客に影響を及ぼし、Microsoftに重大な訴訟コストを課すことを意味している。非常に深刻なバグがバーの下をすり抜けることもあるが、それは顧客の10％以上に影響を及ぼさないってだけの理由でだ。いまや、この施行状況さえ冗談になってる。なにせほとんどの開発者が、DFDが何なのか、どれとどれをどう繋ぐのかをわかっていないんだから。
* 「Damage potential（潜在的損害）」「Reproducibility（再現可能性）」「Exploitability（悪用される可能性）」「Affected users（影響を受けるユーザー）」「Discoverability（検出可能性）」などの指標を用いるリスク算出方法。「恐怖、不安」の意である「DREAD」に5つの指標の頭文字を当てはめている。

これでも、施行状況のもっともばかげた部分じゃない。もっともばかげた部分はセキュリティ「コードレビュー」だ。機能責任者がプリントアウトの山のような束を抱えて部屋に入ってきて、これに割り当てたほんの何時間かでレビューできるような面をしてる、それが実態だよ。それだけの時間でそれだけのコードにざっと目を通すぐらいなら辛うじてできなくもないが、セキュリティ問題の90％はこの「コードレビュー」の間、見過ごされたままだ。

なんだかんだあって結局、製品はほんのわずかだけしかセキュアにならず（最高にばかげたものの一部だけが修正される）、管理者は「製品はいまやフォートノックス[*]級にセキュアだ」なんて妄想を言い出す始末。
* ケンタッキー州ルイビル近郊にある軍用地で、米連邦金塊貯蔵所がある。

僕に言わせりゃ、これは適正なセキュリティプロセスなんかじゃない、虫唾が走るようなシロモノだ。これを変えようってつもりはないのかね？

Nash: いやあこれはいい、しかしまた、難しい質問です。まず言っておかねばなりませんが、セキュリティ品質のための優れたプロセスであるセキュリティ開発ライフサイクル (SDL) は、会社として一貫性を持って行動することを確認するものとして定められています。これはつまり、高度に文書化され反復可能なプロセス、プロセスにどのように従えばよいかを伝える優れた教育、一貫してプロセスが踏襲されてることを確認するための説明責任、これらを持つということです。この説明責任の一部として存在し、実際にプロセスが踏襲されているかを会社に代わって私のチームが確認するものは、最終セキュリティレビュー (FSR) と呼ばれています。結局のところ製品を出荷する製品グループには、プロセスが踏襲されていることを確認する説明責任があるのです。

私はしばしばこんな質問を受けます。「セキュアでないコードを出荷したことで誰がMicrosoftをクビになった？」 私はたいてい、我々Microsoftはセキュリティについて今なお多くのことを学んでいる最中にある、我々が対処しているセキュリティ問題の大半はプロセスに対する不注意や軽視の結果というよりも、その時点で我々が理解していなかった攻撃の新しいベクトルとして発生するものだ、と答えています。

この取り組みを実現するうえで鍵となるものの一つは、会社全体にわたっての一貫した施行です。我々が全製品にわたって同レベルの厳格さを持っている、あるいは持たねばならないと言うつもりはありませんが（Windowsは、例えばゲームなどよりも厳密な検査を受けるべき）、我々はプロセスの適用を適切に行わねばならないのです。総体的にいえば、Microsoftの製品グループは一貫してプロセスを踏襲しています。とはいうものの、Microsoftが抱える従業員は60,000人以上にもなり、中には理解していない者がいても大きな驚きはありません。大きな驚きはありませんが、これは受け入れがたいことでもあります。我々のもとにプロセスを意識していないグループがあるなら、我々は教育問題を抱えているということになります。我々のもとにSDLを意識的に無視している、もしくは意識的に優先度を下げているグループがあるなら、よくても説明責任問題を、最悪の場合には人材問題を抱えていることになります。私が協力できる唯一の方法は、私がそれを把握し適正に対処できるようにすることです。あなたはこの質問を匿名で投稿しているわけですが、ぜひとも直接私に電子メールで連絡いただきたいし、直接会って話し合ってもよいと思います。私があなたの身元を漏らさないことは確約します。もしこれで不都合がおありでしたら、Microsoftの私の直通番号に電話してください（外線を使って――そうすれば発信者IDはブロックされますし、会議室からでも結構です）。その場合にあなたの名前を訊かないと約束します。

何度も申し上げてきたように、信頼できるコンピューティングイニシアチブは、2002年に始まりこれまで無視できない量の改善を行ってきた、一つの道程です。この事例において我々が問題を抱えているのは明らかで、我々がこれからも改善を行っていくには、この問題の修正が欠かせません。

(10)
SSLにいまだにAESがないのはなぜ？
by jonathan_lampe

なぜMicrosftのSSLスタックにはいまだにAESが入ってないんでしょうか？ Microsoft開発者の一人として、SSL実装においてAES（128bit、192bit、256bit）暗号化アルゴリズムを使うことのできる競合ソリューションを見る度にやられたと思うのには、もううんざりです。

（OpenSSLや――Mozillaブラウザを入れてもいい――Java SSLは、どれも以前からAESをサポートしています。SSH実装の大半も以前から備えています。）

Nash: これはいい質問です。AESがFIPSアルゴリズムとして認定されたのは、2001年にWindows XPがリリースされた後になってからです。これをWindows XP RTMに加えるのは基本的に不可能です。我々の暗号法へのアプローチは、我々の広義プラットフォームにおいてプラガブルモデルをサポートして交換を可能にするというものでしたし、それは現在も変わっていません。IEやIISはプラットフォーム（OS）の暗号法能力に依存しており、この能力の追加は、Mozillaでなされたようなブラウザの変更に対して、オペレーティングシステムの変更ということになります。

プラットフォームへのAESサポートを断念しててもよかったのでは、というのはもっともな話ですが、プラガブルな暗号は顧客に大幅な柔軟性をもたらします。Windows Vistaについては、我々が次世代CryptoAPIもしくはCNGと呼んでいるプラガブルな暗号法のサポートを追加しています。CNGにより、AESのサポートだけでなく楕円曲線暗号 (ECC) アルゴリズムおよびSHA-2ファミリーのハッシュアルゴリズムも追加されます。

現在我々は、この能力をダウンレベルに提供することの実現可能性と利点を検討しています。加えて、既存のAES実装がこれまで評価を受けていなかったこととは対照的に、我々の実装がFIPSのガイドラインおよび要件を満たすかの評価を受けることを予定しているとも申し上げておかねばならないでしょう。

(11)
VISTAになってもユーザーは管理者でなければならない？
by arminw

現在のWindowsシステムでは、ユーザーが管理者権を与えられてないと正しく動作しないプログラムが数多くあります。MSはプログラムをそんな風に書く開発者に、普通のユーザーステータスで充分とするよう圧力をかけないのでしょうか？ 最近のマルウェアの多くはひっそりと、ユーザーへの警告程度のこともせずに自らをインストールします。VISTAに何らかの警告を取り入れて、いかなる実行ファイルであっても最初の実行あるいはシステム奥深くへのインストールが可能となる前にパスワードが求められるようにはなりませんか？ それらが信頼されているソースからのファイルと

more
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人