パスワードを忘れた? アカウント作成

スラドのストーリを選ぶための補助をお願いします。

過去のタレコミ一覧:
保留 0件、 却下 65件、 掲載 162件、合計:227件、 71.37%の掲載率
768273 submission
BSD

本家インタビュー: OpenBSD開発者Theo de Raadt

タレコミ by yh
yh 曰く、

「スラッシュドットはLinuxの話題に偏りがちなので、BSDも」というお声をいただいたので、以下の通り、本家掲載のOpenBSD開発者Theo de Raadt氏のインタビューを翻訳してみました。しかしながら、如何せんちょっと古い記事なので、お詳しい方は、事情が変わっているところなど、コメントでご教示ください。
さて、いつもの通り、たくさんの方々のご協力で翻訳が仕上がりましたことを感謝いたします。

1) コード監査についての書籍は?
LizardKingによる

あなた、もしくは他のOpenBSD開発者の方が(あるいは共著とか)セキュアでバグフリーなコード作成と監査についての書籍を書くつもりはありますか? ほとんどのプログラミングの本には教育目的のサンプルコードが載っています。ほとんどの場合、そんなコードはセキュアなコードのあるべき形とは正反対に、ただ動くだけのもので、多くのプログラマの知識に欠陥を残していきます。コードの監査やコーディング時にセキュリティ上の落し穴を回避する方法についての本はあなたがたの生活を楽にするでしょう――OpenBSD用に監査するコードの量を減らし、素敵な新機能に集中する時間を増やすという形でも!

テオ君:

提案してくれた2つの話題にはたぶん隔たりがある。一つは、原作者がセキュアにコードを書く方法としての、セキュアなコーディング。もう一つは、監査、つまり部外者(あるいは関係者のうち誰か)が後になってコードに残っているごみくちゃをきれいにしようとする過程。問題の一部はたぶん、この2つの間に大きな違いがあるということだ。でも結局、そんな話題について扱った本では、徹頭徹尾、2パラグラフ毎に、同じことをくり返し書く必要があるだろう:
いまコーディングしているインターフェイスを理解しろ!
いまコーディングしているインターフェイスを理解しろ! と。
俺達がソース・ツリーから監査であぶり出したほとんどのセキュリティ上の問題(あるいはただのバグも)はそこから来ている。問題となったコードを書いたプログラマは不注意なのろまで、自分が使っているインターフェイスに注意を払わなかったのだ。ソース・ツリーのそこらじゅうから繰り返し同じ種類のバグが出て来るという現実から俺達は、ほとんどのプログラマが(間違った)用例でコーディングを学んだのだということを知った。堅固なシステムを作るには「動くんだからいいじゃん」という土台で取り組んではいけない。にもかかわらず、何度も何度も、ほとんどの人々がそういうやりかたをするのを目にしてきた。連中は良いソフトウェアには関心がなく、「仕様通り動く」ソフトウェアにしか興味がない。

だからプログラマ達はそんな失敗をし続けられるのだ。そんなわけで、俺は単に悪魔が潜んでいる場所を詳細に教えるだけの本を書くことにはそんなに興味を持てない。今になってもその場所を知らないのなら、他の仕事(きっと引き起こすであろう損害が小さいやつ)を探すべきだ。

2) それ以外もセキュアに
squiggleslashによる

OpenBSDは「独創的」なセキュリティと、組み込まれたツール群がありうべき形の中で最もセキュアであるということについて、なるべくして好評です。しかし、portsシステムはセキュアなアプローチが現在制限されている例でしょう――OpenBSDをインストールして、INN(InterNetNews: http://www.isc.org/products/INN/)のようなポピュラーなサードパーティのソフトを使う場合、INN(あるいは、そういうサードパーティのソフト)を監査するのはBSDの領域から外れるので、そのていどのセキュリティにしかなりえません。

聞きたいのは、OpenBSDチームとして「セキュアなports」ツリー、もしくは何か同様のシステム、を作るにはどうしたらいいか調べるように依頼をされたことがあるかどうかです。そうすることで、OpenBSDのようにセキュアなプラットフォームを運用したいと考えている人々がプラットフォームと同様に多くのアプリケーションに信頼を寄せることが確かなものとなるでしょう。

テオ君:

俺達は、およそ300MBほどになったメインソースツリーで新しいアイディアについて調べたりするのでもう手一杯だね。他にも、ちょっと前に、あるコンポーネントについてXFree86とちょっと関わったりした。これ以上に他のコンポーネントを監査するなんてちょっと非現実的だね。問題を困難にしているのは、コードの分量そのものだけでなく、他にもあるね。いろんな理由で、こういう外部パッケージのメンテナとのコミュニケーションが困難だったりするし。人によっては、俺達がLinuxって言わないからって聞く耳を持たなかったりするんだよ。移植されてくるソフトウェアパッケージの中には、でかすぎて、標準的なシステムとしての品質から本質的に程遠いものもある。

でも一番大事なことなんだが、俺達だって人間で、楽しく人生過ごそうとしているし、いつもいつも心がはやってて吐き気がするようなサイテーなプログラマのゴミに、動かさなければそれで済むのに、突然800時間もムダにするようなことはない。

俺達の監査者がコードを見て、「おや、こいつぁひどい」って言って使うのを避けてしまうということはしょっちゅうあると思う。このやり方が気分のいいものじゃないだろうというのは分かっているが、んじゃ、なんて言ったらいいんだい……

3) OpenBSD,セキュリティ,その他
jdによる

SGIのB1コードのリリースや、多くのUNIXがケーパビリティ、ACL(Access Control List[アクセス制御リスト])等々によってその内容物をセキュアにしようとする試みがありますが、OpenBSDでは、資源制御の課題にどう取り組んでいるのでしょうか?

余談ですが、OpenBSDが分散型カーネル(distributed kernel)の方向に進むということはあるのでしょうか? もしそうならば、セキュリティや資源管理はどのように維持されるのでしょうか? (これは集中型カーネルのシステム[central kernel system]でも十分に難しいことです。)

テオ君:

最初の質問について、オレンジブックの世界に対して大きな誤解があるようだ。多くの人は、オレンジブックをセキュリティについての規定だと思っているが、それは違う。その大部分は、脅威にさらされた場合の説明責任(accountability)についてのものだ。つまり、実はシステムをセキュアにすることについての話じゃない。システムのセキュリティがいつ破られたかを知ることについての話だ。全然違う話なのだ。口角泡を飛ばして「すごい」なんて騒ぐ前に、商業的に展開され、実業務に使われているCや、Bや、さらにはAのシステムがどれくらいあるか数えてみることだ。一方で、オレンジブックに描かれていた世界の一部が、現実のシステムに、実際に使われるのを徐々に見ることになるだろうと思う。ところで、ACLが挙げられているのには驚いたよ。なんせ、それは実際のところB1システムには何の関係もないものだから。

二つ目の質問について、私は分散型カーネルが何なのかまるで分からないし、そういった類のものがシステムのセキュリティや品質を向上させるなんて思わないよ。

(※訳註: オレンジブックとは米国防総省のTCSEC(Trusted Computer System Evaluation Criteria [信頼できるコンピューターシステムの評価基準])のこと。表紙がオレンジだったのでその名がある。レベルの高い方から順にA, B, C, ... とレベル分けをして、それぞれのレベルをさらに1, 2, 3, ... と細分化した。B1というのは大分類Bレベルの小分類1レベルという意味。)

4) フォークと協調
PapaZitによる

OpenBSDはNetBSDからフォークし、いまだに、この2つのグループ間にはかなりの敵意が存在することは多くの人に知られています。個人的な考えですが、その競合は、双方のグループに役立っているのではと思っています。(例えば、現在ではNetBSDでもオープンなサービスはかなり少なくなっています。)

エゴというものはデリケートなものですが、将来には大規模な協調が行われる機会があるとお考えでしょうか? それとも、さらなるフォークや分裂は避けられないものでしょうか?

テオ君:

考えてみろよ。NetBSDは、OpenBSDプロジェクトのネットワークに4年程もブラック・ホール・ルートを続けてやがるくせに、どうやったら高いレベルでの協調なんていうもんができるのか、おれは理解できないね。

まあ、被っているプロジェクトに首を突っ込んでいるデベロッパもいるな。いろんなグループとのトラブルのことで文句を言っていた奴もいたけれども、

このところは、ちょっとは落ち着いてきたようだよ。最近じゃ、デベロッパの結びつきってものは、政治的なことで決まるものじゃないのだね。

Linuxの世界じゃ、金銭的な問題でプロジェクトにフォークが起こるようだよ。BSDの世界では、ほんと純粋に政治的な問題でフォークが起ったみたいなんだけどもね。今後何が起こるかなんか、俺にはわからないよ。かれこれ、BSDキャンプでは5年もフォークが起きてないしね。しかし、何であんたらはそうフォークにこだわるんだ? あんたらは、皆に同じ政党に投票させたいとでも言うのかね?

5) カーネル設計
laertesによる

私は当面の間だけOpenBSDを使っているだけなので、間違った仮定で質問しているなら許してください。

OpenBSDのカーネル設計はモノリシックの類に入ると思います。OpenVMSとNTは2つともマイクロカーネル・アーキテクチャを用いた素晴らしいオペレーティング・システムですね。私にはマイクロカーネル設計というのは、特権的なコード部分が少ないため、本質的により安全なものに思えます。さらに複数のサーバ部の1つが危険な状態になっても、損害は最小化されるのです。

私の質問はこうです。OpenBSDの設計は本質的に安全なのでしょうか? それとも基本的には欠点のある設計だけど、うまくつくろった実現例にすぎないのでしょうか?

テオ君:

それで何が違ってくるってぇのか、さっぱりわからねぇな。あんたのコンピュータの先生って、80年代に書かれた本で教えてたんじゃねえのか? あの頃はマイクロカーネルって言葉だけで、未来のユートピアだったんだぜ。NTがマイクロカーネルだなんて嘘だろう。OpenVMSもそうだって、あんたほんとに信じているのかい。マイクロカーネルってのは、ローダブル・モジュールで仕事をするカーネルじゃねぇんだがなぁ。まぁな、システムがするべき仕事をちゃんとやってるんなら、そこになんか違いがあるってのがわかんねぇなぁ。

6) コード監査の訓練はどこで学びましたか?
EXTomarによる

コードを監査する原動力は、必要性によるものでしょうか、それともBSDの設計から来たのでしょうか? あるいはもとより思いつきなんでしょうか? 何より、どこでそれを学んだのでしょうか? 共に見ている「先達」がいらっしゃるのは、めりはりのある設計のためなのでしょうか? あなた方チームの圧倒されるようなコードのレビューには、感服せざるを得ません…自分にもあれほどの精細なコーディングの素質があれば良いのですが。

テオ君:

監査過程は、自分たちのOSの質を向上させようという欲求から生まれた。最初にそれを始めたときは、魅惑的で、楽しくて、そしてかなり狂信的に近いものがあった。約10人がその共同作業に携わって、原則としてお互いに教えあいながら事を進めてきた。「ホール」や「バグ」といったものより、ソース・コードにおけるプログラマの基本的な誤りや杜撰な点を探した。ずぼらな点を見つけるたびにソース・ツリーを繰り返したどるということを、ずっとやっていたのだ。プログラマが犯した誤りを見つけるたびに(たとえばmktemp(3)を使ってファイルシステム競合が起こるような場合)、ソース・ツリーを最初から最後までたどって、それら「すべて」を修正する。そうやって一つ直すと、他にも基本的な誤りを見つけるだろう。そうしたらまた「すべて」を修正する。そう、大変手間のかかる作業だ。でもとてもただならぬ見返りがある。ボーイングの技術者が、発生した配線の不具合を「すべて」は直さなかったらどうなるかなんて想像できる? 少なくとも、ソフトウェアも同じようにやるように試みましょう。

7) Firewall/NAT box
yamlaによる

Linuxには、FreeSCO(フリースコ)という、3.5インチ・フロッピーに入る、ルータやNAT(ネットワーク・アドレス変換==rfc1631)として使えるものがあります。私はいつもOpenBSDにもこういうものがあったらいいなと思っていました。というのも、こういった(NATやルータとしての)用途には、LinuxよりOpenBSDの方が信頼できるからです。

こういうものを作る計画はありますか? もっと簡素なユーザ・インタフェイスで素早く容易に設定できるようなものはどうでしょう。OpenBSDは大好きだし、手で設定したいけど、忙しくて。

テオ君:

まず言っとくけど、フロッピー・ルータとか好きじゃないんだよね。基本的に、あんたは一番信頼ならねぇ記憶装置を使おうとしてんだぜ、さらにその上にセキュリティの基盤を築こうとしてる。容量の小さいハードディスクでも買えよ。CDと、(フロッピーじゃなくて)ちゃんとした記憶装置を使ってやるんだったらまだまともだろうよ。でも、頼むから、フロッピーはやめてくれよ。madなの?

8) コード監査
ATによる

コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったtipsや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか? 古いコードの場合は?

テオ君:

一番のtipsは、今よりももっと良いプログラマになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べることと、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だ。これを読む人の中の果たして何人が、libcのすべての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソース・ツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと。)

APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。

9) デュアルプロセッサ対応
dragonfly_blueによる

OpenBSDを2CPUや4CPUのマシンで動かすことに興味があるという意見が散見されますが、こういったことをするために必要な情報も、手を挙げる人も少なすぎるようにみえます。私はOpenBSDをwebサーバに使用していますが、この点については全くといってエキスパートではありません。でも、それでもなお興味津々なんです。

聞くところによると、マルチプロセッサ対応は、特に競合状態をはじめとして多くのexploitを引き起こす可能性があるので、実装にかなりトリッキーなことをしなきゃいけないそうですね。OSの全体の整合性に妥協することなしにSMPのためにコード・ベースの多くを書き直すのはものすごい量の時間と労力が必要になることも理解しています。

以上を念頭に置いて、2CPUや4CPU対応に本腰を入れるためにどういったリソースが必要になりますか? それから、そういったリソースが無尽蔵に使えるとして、-stableリリースが出せるようになるまでにどれぐらいの期間がかかるでしょうか。将来、マルチプロセッサに対応するのが本当に楽しみにしています。もちろん、現在開発チームが十分忙しいということも分かっています。

テオ君:

今のところ、俺達はSMP対応の作業はしてない。こいつは、ものすごく手がかかるし、俺達はそれほど興味がないんだよ。わるいね。

(※訳註: 「OpenBSD SMPプロジェクトで、作業は継続中ですが、まだ、現時点では使用可能なマシンは何もありませんし、OpenBSDのSMPサポートのスケジュールも出せる状況ではありません。ほとんどのプラットフォームで、OpenBSDはSMPマシン上でも動きはするでしょうが、ひとつのプロセッサしか利用できません。」faqの8.12日本語版)参照。ソース・ツリーに初めてSMPタグが打たれたのは2000年2月12日のこと。SMP Projectのページ。)

10) タイム・ワープ
rhoによる

テオの業績に感謝を。私は、OpenBSDをワークステーションとして、またファイアウォールとして毎日使っています。警官がスクリプト小僧を追っかけている柄のTシャツも最高ですね。

もし、時間をOpenBSD開発の始めに戻せて、そこに至った主義主張の話を無視したとすると、何か違ったことをしたいですか? 商業版に焦点をおいたでしょうか? SMPの開発を、もっと早く進めましたか? それとも、両手を振り回しながら、ぐるぐると駆け回りますか?

もう一つ質問は、OpenBSDの商業利用に関してどのように感じているか。つまり、支持しているか、我慢しているかとかの話です。もうちょっと良い例だと、私がOpenBSDの走るセットトップ・ボックスを作ったとして、OSに機能Xを果たしてもらいたいとします。で、あなたに電話して「テオ、OpenBSDでXをサポートして欲しいんだが」と言ったとします。どんな答えが返ってくるんでしょうか? 「あっち行け」? 「自分で書けよ」? それとも「金払えばOpenBSDチームでやるよ」なんでしょうか?

テオ君:

俺達のコードのライセンスはごく単純だ。俺達は、ベンダーにコードを使って貰いたいと思っている。商用OSにOpenSSHを載せて出荷して欲しいと思っている。SSHの類を載せずに出荷するのは悲劇をもたらすし、それはSSHの終りの時だ。

同じことがOpenBSDでも言える。ある会社が商用ネットワーク機器を組み上げるのなら、一から書き上げた独自OSを使うよりは、OpenBSDを使ってもらう方が好ましい。たいていの場合、それらの会社は問題をアプリケーション空間で悠々と解決している。たとえ、それらの会社で汚い独自OSの歴史があったとしても、同時にもっと酷いアプリケーションの歴史もあるもんだ。

ルータ、ファイアウォール、電話交換機、ファイルサーバおよびその他もろもろの機器において、信頼でき、それらに感心をもつ人達によって設計された構成要素を使えば、もっと状況はよかっただろうに。

だから、どんどんやってくれ。OpenBSDのどの部分でも、商用システムに組み込んで構わんさ。

11) 完全な情報開示とバージョン番号付け
Effugasによる

まず最初に、OpenBSDの構築に費したあなたの労力に感謝します。OpenBSDは、本当に良いパッケージだと思います。

OpenBSDにおけるほとんどのセキュリティ強化は、ソース・コードから安全じゃないライブララリ呼び出しを洗いだす作業にすっぽりと覆われているわけです。しかし、この作業はもちろんありがたいのですが、最近になって、こういった変更は必ずしも文書化されてないし、アプリケーションやユーティリティのバージョン番号に確実に反映されていないという事実が、だんだん気になり始めています。

バージョン番号は、コード・ベースの存在期間の中で特定のスナップショットを反映するものです。それらは、安全ではない版を参照したり、特に安定版を参照するのに用います。番号のメジャー番号は分岐を示し、マイナー番号はコードの特定の状態を表します。それが、ユーザや管理者がバージョン番号を見た時に期待するものです。バージョン管理に粒度を与えなければ、その番号を信用する/しないの理由がなくなります。個人的にソースを検査して、最終的には自分流のバージョン番号を与えることになるでしょう。

あなたとチームは、コード検査の主幹です。安全な構築物用の変更コードとオリジナルコード(さらに敷衍すれば、あなたの安全なコードと多くの無名の配布者による「とりあえずコンパイルできるようにした」改変物)とを区別できなくして名前空間を汚染するのではなくて、改変したすべてのパッケージに関して名前の拡張をし、完全な情報開示の意図の下に、そこに含まれる妥当な変更履歴を提供するのがスジではないでしょうか?

テオ君:

OpenBSDのすべての構成要素に、二つの番号がある。一つは、どのリリースに含まれるかを示す番号で、例えば2.8とかだ。

もう一つは、構築に使われたすべてのソースファイルが持つ番号がある。その番号は、それらから構築されたバイナリにも含まれている。どのバージョンのソースファイルからそれぞれのバイナリができているかは、what(マニュアルセクション1)コマンドを使えばわかる。

オリジナルに関しておっしゃっているが、オリジナルというのは存在しない。OpenBSDは、独自の構成要素をもっている。あなたがどのパッケージを意図しているか私にはわからない。catはcatだし、ftpdはftpd、tarはtarだ。特定のリリースに関して言えば、一つしかない。系統だったアプローチだと、他のグループのやっているバージョン番号付けは、不正な場合がある。なぜなら、ライブラリなどの部分全部を、一つの構図にまとめてしまっているからだ。

この間乗った飛行機の前輪が、バージョン2.7だったか2.9だったか? 気にしないだろ? それでもだ。それが完全なことを保証するために「系統だったアプローチ」とやらが使われていることを気にしているわけだ。そして、OpenBSDの場合は、それは特定のバージョンを選び、パッチを当てるということを意味する。

これ以上を望むのならば、俺達により多くの作業をバージョン管理を費して、それだけシステムそれ自体にかける時間を減らすことを望んでいることになるんだが。

12) お金はどこへ?
MrSparklerによる

リリース毎のCD売り上げが10000枚近くになるというレポートを見ました。Tシャツやポスターの売り上げ、寄付金をあわせるとある程度まとまった金額がOpenBSDの周りを流れていることでしょう。このことと、小切手の宛名がde Raadt氏であるという事実を考えあわせると、資金がどのように扱われているのか、疑問を感じます。不正が行われているなどというつもりはありません、ただ誰がお金に責任を持っているか、OpenBSDプロジェクトが非営利組織(NPO)として登録されているのかどうか(もしそうなら、小切手はその団体に振り出されるべきではないか、CDイメージはその団体の著作物とされるべきではないか)ということを知りたいのです。また、ユーザが自分たちのお金がどこへ行ったのか分かるような簡単な財務レポート(アルバータのNPOであれば要求されるであろうもの)を見たいのです。加えて、リリース毎に何枚のCDが売れたのか正確に知りたいのです。

OpenBSDプロジェクトの開発者達が注ぎこんだ業績に感謝していますし、この質問への答えに関わらず、これからもOpenBSDを使い、購入し、寄付し続ける(そして技術的スキルが身につけば参加する)つもりでいます:本当のところ、お金はどこへ消えるのですか?

テオ君:

俺達はリリースあたり10000枚のCDを売り上げたことはない。もうすぐそうなるだろうけど。プロジェクトは、最終的にはCD売り上げ収入の50%よりわずかに少ないくらいのお金を得る。Tシャツ事業はうまくいっているけど、布地を売ったところで儲けはほんのささやかなものだ。ポスターでは差し引きゼロからわずかに上ってところだ。そりゃいくらかはWebで売れるけど、ほとんどは数多くのカンファレンスで無料配布される。それが俺の計画したポスターの使われ方だ。

俺達はNPO化については検討したことがあるけど、あまりいいアイディアじゃない。全く何の現実的な利益も――あなた方に対して、ということだけど−もたらさない。特にカナダでは、NPO化にはコストと重大な責任が要求される。多くの自由を手放さなきゃならないし、繁雑な経理のために誰かを雇わなきゃいけない。それに、多くの寄付金がカナダ国外から寄せられているから、あなた方に課税対象となるような利益も生み出してやれない。(そして俺はあなた方に尋ねることになる、本当の寄付でなく、税金控除の対象になる金額しか寄付してくれないとは、あんたたちはなんてケチンボなんだ? ってね。実際、そんなのはフリだけだと分かっている。)

プロジェクトから得られるお金はいろんなことに消えていく。第1に、お金は俺がフルタイムでOpenBSDのために働くことができ、他の仕事をしなくてもいいと保証してくれる。フルタイムOpenBSDのために働くことに興味があると言ってくれている、プロジェクトの他の開発者たちにも同じようにしてやりたい。第2に、多少汚れた、面白くもない、そして重要な開発作業では開発者達のポケットに少しのお金が入る。OpenSSHの作業のいくつかは、OpenBSDの資金のうちVanDykeからの寄付金に見合う金額によって賄われている。第3に、プロジェクトで妥当な量のハードウェアを購入している。PowerPCだけだが、今年は4台のマシンを購入した。第4に、カンファレンスへの出荷コストがときどき売り上げ収入を上回ることがある。最後に、開発者がハッキングのために集まるとき、プロジェクトの資金がいろいろなことに支払われる、例えば航空券、滞在費、時にはビール代にも。ビールはアイディアに化け、アイディアは新しいコードに化ける。

769054 submission
インターネット

インターネットの父ビント・サーフ@本家

タレコミ by yh
yh 曰く、
「インターネットの父」として知られるビント・サーフ(Vinton Gray Cerf)博士が本家のインタビューに応じている。1年前に本家に掲載されたもので、以下にその抄訳を、インタビュー翻訳企画の第15回としてお送りしたい。
原題は、"Vint Cerf Talks About Internet Changes"。TCP/IPの開発者のひとりとして、またICANNの理事のひとりとして、科学技術的また法的側面から、インターネットの利用や運営のあり方を中心に様々な側面と時代変化について思うところを語っている。

1) 匿名性についてはどうお考えですか?
Planesdragonによる

――プライバシーに関する個人の権利についてある種のモラルの議論があるにも関わらず、ひとは匿名となるとあっさりと無責任に振舞うという統計的な議論もあります。

インターネットにおける匿名性についてはどうお考えですか? 良いことですか? 悪いことですか? 語る価値もないことでしかなかったりしますか?

ビント:

匿名性については、非常に語る価値がある。プライバシー権は、ときとして、匿名の権利として表れる。ウィンドウ・ショッピングや現金決済では、個人の特定が要求されるべきではない――また多くの人々は、ネットサーフィンについても同じように感じている。あるケースにおいては、個人情報へ第三者がアクセスすることを保護するばかりでは十分ではなく、ネットワーク・ユーザに個人の特定を要求するまでの主張がなされるかもしれない。ホイッスル・ブローイングが問題になるケースにおいては、つまり、なんらかの犯罪を告発するには、保護のために匿名性が重要であるだろう。しかしながら、あなたが上に述べているように、同じ保護の仕方でも濫用の可能性をもたらすことにもなる。匿名性を悪用する力は、匿名性によって合法的に保護される力よりも、真の難問を生むのだ。だから、これは実に語るに値する。――あなたがより考えていくことに関心を持ちたい。

2) DRM?
GreyWolf3000による

――DRMについては、どういう見方をされていますか? 特に、フリッツ・チップやPalladium、MPAA/RIAAのロビイングが、インターネットを底から変えてしまうとお考えにはなりますでしょうか? 現段階でインターネットを手懐けることはできるでしょうか? できるのだとしたら、そういったDRMなどが公正な使い方を侵害するとはお見受けになりますか? 将来的には、インターネットへのアクセスを得るがために、インターネットそれ自身を蝕み始めるようなたくさんの規制がコンピュータ自体に持たされるようになっていくだろうというよく言われる恐れがありますが、それはもっともなものでしょうか?

ビント:

技術的に執行不可能な、あるいはデジタル技術の分野全体を機能不全にさせる効果をもつであろう法的政策には、私は非常に懸念している。デジタル・ミレニアム著作権法に表れたようなDRMの位置付けには、知的財産を保護すべく使われるのかもしれない暗号メソッドの情報を公開したり研究したりすることを違法とするものがあるが、これは現実的でないし、根本的に不健全だ。あなたのご心配は、十分根拠あるものだと私も思う。私も、知的財産保護のための科学技術は望ましいと強く信じる一方、「ある種の」情報は基本的に自由には共有できないようにしてしまおうという議論に悩まされている。インターネットとは大きなテントであって、高度に保護された情報からまったくオープンな情報まで広がる、たくさんの異なった運用モデルをサポートできるべきなのだ。

3) 商業的電子メールの創生期
ekroutによる

――1982年〜1986年の間、MCIデジタル・インフォメーション・サービスの副社長として、あなたは、インターネットに接続する初の商業的電子メール・サービスであったMCIメールのエンジニアリングをひっぱっておいででしたね。

エンジニアのほとんどが知るように、どんなプロジェクトでもいか程かの犠牲は負わなければならないし、金銭的制約などによって、あるべきと願った機能を諦めなければなりません。

かのプロジェクトにおいて、長としてあなたがしなければならなかった難しい決断について、お話をいただけませんでしょうか? また、そのプロジェクトで、その最終製品でやっていけると誰も考えなかったという時はありましたか?

ビント:

プロジェクトが始まったのは1982年後半のこと。デイブ・クロッカーと私がそのテクノロジの基礎部分の設計において直面した最も難しかった判断のひとつは、MCIメールにおいてはリニア・アドレッシングは採らずに、マルチライン・「アドレス」にできるようにしたことだった。MCIメールの受信者コミュニティ内の電子メール宛にも、郵便の住所宛にも、MCIメールでない宛先(例えばCompuServe)にも、Telex宛にも、そして(後には)FAX宛にも、送ってよいようにした。インターネットの電子メールの古典的なリニア・アドレッシング構造は採らずに、そういったマルチライン・アドレス体系を提供するのが重要だと結論するに至るまでには数ヶ月の討論を要した。

私たちは、業者たち(HP,DEC,アメリカン・マネジメント・システムズなど)にTCP/IPを使ってもらうよう当たってみた。けれど、インターネットやTCP/IPが彼らにはまったく知られていなかったことが想像できるかな。――で、それはただ、1983年1月1日、ARPANETで大規模な「出発」となったのだ! これにより、TCP/IPの商業的なサポートがなかったためにMCIメールに特化して開発された様々なプロプライエタリなプロトコルやX.25を使わなければならないというのはおしまいになったのだった。

私たちがMCIメールを立ち上げた時(1983年9月27日)には、ビジネス・セクターでは電子メールなんてものはあまり知られていなかった。ビジネスマンが電子メールを使うようになるなんて到底思えなかった。「接続性」を拡げることによって、MCIメールがもっと有用なものになるようにと、MCIメールの普及キャンペーンの一部としてCompuServeにMCIメールをつなげた。全般的に、電子メールがビジネス界でも広く認められるサービスとなるには、1983年から1992年までかかった。

4) TCP/IP
sdjunkyによる

――TCP/IPプロトコルについてなさったお仕事で、今から変えるとしたらどこでしょうか? 今となってみれば、それがどう利用ないし誤用されてきたかを過去回帰的に振り返ることができるわけですけれども。TCP/IPが作られたときでは思いもつかなかったものを、今から設計に採り入れるとしたら、それは何でしょうか?

ビント:

思うに、アドレス空間は32ビットより大きなものに決めておけばよかった!(その判断は、それに関する議論から1年後の1977年に行われていた。) 加えて、どの端末ユニット(「1個のIPアドレスを伴うもの」)にもそれ自身で他の端末ユニットを「認証」する方法を備えるという概念を、その設計原則に採り入れておけば賢明だったのに今となっては痛感している。現状では、そういった端末デバイスが自分で自身のIPアドレスを宣言しなければならず、それが、構造上、詐称やスプーフィングの機会を導いているのだ。それに加えて、ネットを経由する情報の機密性を高めるために、IPSECのようなエンド・トゥ・エンドの暗号メソッドを開発するある種の機会を設けておけばよかった。私は、1975年から国家安全保障局とともにインターネットのセキュア版に取り組み始めたのだった。皮肉にも。というのも、その設計の詳細は機密扱いで、その設計は、大学や産業界でインターネットの設計を展開することに勤しんでいる開発者で不確かな者とは、まったく共有されなかったからだ。

5) インターネットの欠点
Dirk Pittによる

――インターネットはしょうもなくも発展してきていますけれど、どの側面に最も失望なさっていますか?

ビント:

それは難しい質問だ。スパムや、ポルノとか不快なウェブ・サイトや、ドメイン名と商標の衝突や、検閲に執り行う当局の目論見、それらすべては、私がインターネットに失望した側面の例だ。それを相殺するような例としてインターネット上で非常に価値があるアプリケーションや情報の共有がなされていることは、そういった欠陥を埋め合わせてあまりあるように思える。一般的に言って、インターネットが、私たちの複雑で世界的な社会のすべての部分のインフラになればなるほど、私たちは、インターネットに映し出された社会のすべての側面をもっと目にするようになっていくのだ。――ネット上のユーザの人々の多様性について、ひとは現実的になっていかねばならないね。

6) 最も驚いたことは?
zero110による

――インターネットで用いるよう考案された驚くような使い方のうちで、最も(良い意味で、あるいは、悪い意味で)驚かされたのは何ですか?

ビント:

ティム・バーナーズ・リーがWWWを発明してから、その後急速に、マーク・アンドリーセンがMosaicをWWWに実装し、Netscape NavigatorやInternet Explorerやその他ウェブ実装やアプリケーションが続き、インターネットにコンテンツが雪崩れ込んでいったというのが、一番驚いたことだと思っている。もちろん、ネット上のコンテンツが信じられないほど幅広いものでがあることには、同じくらい驚きだ(あるいは、失望だ――上述のとおり)。インターネット・ラジオ、ビデオやインスタント・メッセージングには驚かなかった。1960年代の終わりから1970年代の始めごろにはそのコンセプトはすでにあったのだから。でも、何百万人ものひとがそういう機能を手にして使うようになると、過去にそういった機能を小規模に展開していたのをベースに全体がどうなるかという予想を立てるというのが難しくなったね。

7) インターネット・ガバナンス
cleetusによる

――インターネットには、最も基本的な技術レベルでも機能するように、ある種のスタンダードが必要となります。つまり、ある種のガバナンスです。ガバナンスないしスタンダードの設定の適切な範囲について、どうお考えですか? その投票資格があるのはどんな人でしょうか? ガバナンスを行うための適切なメカニズムとはどんなものでしょうか?

それらは、今現在あるようなものとはどう異なるのでしょうか? そのすべてについて、楽観的でらっしゃいますか? それとも悲観的でらっしゃいますか?

ビント:

明らかなのは、相互作用する数十億ものシステムが互換性を持つよう支えるスタンダードを、私たちは必要としているということだ。――そして、IETFで策定されている自主的なスタンダードや、様々な主体によって策定されているその他多くのものが、その相互運用性がもたらされていることによって、効果的な手段となっているように思える。私は、技術的スタンダードは、「ガバナンス」という、より一般的な言葉からは区別したい。その言葉は、技術的な相互運用性をはるかに超えた数々の問題を含んでいるのだ。ご質問では、技術的スタンダードの策定と、インターネットが機能する法的なフレームワークを、ごっちゃにしているのではないかと思わせる言い方ですね。もし、スタンダードを作る過程のガバナンスに焦点を当てることだけを意図して言っているのなら、IETFの公開手順がインターネットのユーザやプロバイダのコミュニティに長年資しているということを申し上げよう。

スタンダードの策定とインターネットの全般的なガバナンスの両方に機能しうるメカニズムを、私たちが維持し発展させていくことには、私は楽観的であり続けよう。この体系は非常に価値があるものだから、両方のニーズを満たすのに必要とされる支援が得られないことなどないのだという信念に大きく拠っているのだ。

8) ジョン・ギルモアからの手紙
Evroによる

――あなたはなぜカール・オウルバッハに反対するのかと問うたジョン・ギルモアからの書簡には返信なさっていますか? (私の知る限りでは)オウルバッハはICANNの財務書類の入手に務められた方ですよね。私の理解によると、ICANNの唯一のモチベーションは、ICANNにもっと影響力を持たせようというところにあるわけですね(例えば、その役員たちが私腹を肥やせるようにとか)。ICANNが法的には非営利組織だとすると、これはあまり倫理的なこととは思えません。

ビント:

ジョンの手紙には返信しなかった。

もしあなたが、ICANNの役員やそのスタッフたちが「私腹を肥やす」機会を持っているのだと思うなら、ファクト・シートをもっと慎重に見る必要がある。役員たちは誰一人として自分の仕事についてICANNから報酬をもらっていない――旅費の返還は例外だが、役員の多くは自分の旅費は自分で(あるいはその会社が)支払っている。

私の知る限りでは、カールの提訴から生じた裁判所命令に従って、ICANNはカールが要求した情報のすべてを彼に開示している。紛争の基本的なところは、情報をカールに開示すべきではないということでは「なく」て、むしろ、公に開示すべきはどの情報であるかという絶対的な裁量がカールにあるのか否かということだった。ICANNでは、様々なドメイン名のサービス・プロバイダから提供される専有的な情報を扱っているのだ。たとえば、私の理解では、役員の誰ににしてもいったん機密情報が公開されると、それはどう守られるのかをめぐって論争は進展したのだった。

ジョンが言うICANNの特徴づけは同意しない。ICANNはその活動のすべてについての膨大な量の情報をウェブに載せている。多くの非営利組織に比して、ICANNはよりずっと透明だし、どんな方面から寄付を得る機会もかなり大きく設けている。理性的なひとでもそんなことやこれには同意しないというなら、ジョンと私は単に物事を違く見ているというだけのことだ。

9) IPv6?
Ransakによる

――これから数年でIPv6に移行するという「計画」や宣伝を聞いています。でも、アメリカではIPv4でかなり満足しているようです。IPv6は、近い将来(2〜3年で)実現すると思いますか? ご高察では、この移行に拍車をかけることができるであろうものは(明らかなアドレスの枯渇の他には)何だと思われますか? あるいは、移行するべきではなく、NATにもっと依存するべきなのでしょうか?

ビント:

一般的に、IPv6が使えるデバイス(インターネットができる携帯電話、PDA、双方向テレビ、その他家電など)がインターネット空間にたくさん出てきたときに、その圧力ができるのだと思う。ひとはしばしば、IPv6への「キラー・アプリケーション」なんてものを考えるが、一般的に、大量のアドレス空間と簡単な設定(プラグ・アンド・プレイ)がただ利用可能となれば、十分に意義のある利点となると私は考えている。IPv4とIPv6が混在している環境というのは、管理が簡単なものにはならないだろうね。――IPv4空間の利用を「拡げる」べく今日用いられているNATは、IPv4の全世界からIPv6の全(ないしほとんどの)世界へと橋渡しをするものとして活躍する必要を明らかにするだろう。IPv6が飛躍的に浸透するのには2〜3年かかるだろうが、2005年までにはそうなると私は予想している。これは、日本でIPv6の実装が大きく進捗しているし、ヨーロッパではご存知のように「プッシュ」されているのだ。「6 by 6」のスローガンは、2006年までにIPv6を大いに発展させようという課題の一種として起こったものだ。数年内に、それが現実的なものか否かが分かるようになるだろう。

10) 人民のインターネット? あるいは人民のための?…
tekratによる

――(今あるような)インターネットが開発中の頃に目を戻しますと、それは政府の軍事プロジェクトでありました。

ビント:

ええと、アメリカ国防総省の高等研究計画局から資金を受けてはいたが、それはアメリカやイングランドやノルウェーやドイツやイタリアの大学とか研究所の院生によって設計されたものだ。

――でありながら、(90年代初めの)インターネット革命によりそれがARPA-Netから解き放たれてからは、誰でも接続でき、技術的なノウハウが十分ある者なら誰でもサーバを走らせてそのシステムの恒久的な一部分となれるという「黄金時代」を手に入れました。

ビント:

ええと、インターネットが初めて広まった1983年ごろ、APRANETはARPANET (bis)とMILNETに分離した。商業的利用は1989年ごろから。APRAPNETは1990年に、またNSFNETは1995年に役目を終えた。それは、商業アクセスやサービスの出現で、事実上誰にでも開かれたものであった。

――とはいえ、今や、おぼろげにも先が見えるようになってきました。巨大なメディア複合体が、「リンク訴訟」や、露骨なビジネス・メソッドの特許のみならず、個人は自分の家庭でサーバを走らせてはいけないとする過酷なサービス約款を通してインターネットをすべてコントロールし、人民の圧倒的多数が、インタラクティブに情報を発信するのに加わるのではなく、消極的に情報を眺めることしかできないという結果に終るだけという未来です。

ビント:

インターネットでの商業的拡大に関してのそういった問題はたくさんある。――とはいえ、ひとびとの大部分が情報を寄与できないというあなたの結論には同意しかねる。私の印象では、多くのISPでは、ウェブ・サイトに情報を掲載する機会を提供している。自宅でサーバを動かすのも未だ一般大衆向きではないけれど、サーバがもっと簡単に操作できて設定できる(プラグ・アンド・プレイ)ようになるにつれ、それは変わっていくものだと考えている。加えて、ISPは、対称で高容量のギガビット・イーサネット・サービスを提供すべく模索するようになるだろう。というのは、それが顧客のニーズに広範にサービスをするとても効率的な方策だからだ。

――みんながみんなしてサーバを動かすこと(人民のインターネット)は「良いこと」だとお考えになりますでしょうか? あるいは、政府や企業が市民への情報の流れをコントロールすること(人民のためのインターネット)の方が良いことだと信じておいでですか?

ビント:

その両方ともに価値を見つけるものでしょう。――加えて、十分な、対称容量がもたらされるまでは、ユーザは委託して自分のサーバ・サイトを運営してもらう方を好むだろうし、ホーム・サーバが自然視されるようになっても、ユーザはそういった運営を専門家に委ねる方を好むだろうし。

――それは自明な選択に見える一方、今現在の私たちの状況を想起していただくと、そこは、インターネットは「ワイルド・ウェスト」であり、メール・ボックスはspamのゴミで散らされ、また、インターネット上の風説は予想外の記事として登場する状況ですが、それが、「人民の」インターネットの直接的な帰結なのです。

したがって、どちらにしても賛成・反対があるのです。根本的には、この質問は、「あなたはワイルド・ウェストの方がいいのですか?」対「あなたはコントロールされてモデレートされたインターネットの方がいいのですか?」というものに凝縮されます。

ビント:

もし、どちらかを選ばなければならないなら、私はより開かれた環境の方がいい。でも、予測の範囲にある法的枠組みや執行の必要性も認めてはいる。ISPに不意打ちされたりするのが好きな人なんていないのだから。

――ビント

770144 submission
ニュース

2ch発:折り鶴14万羽プロジェクト

タレコミ by yh
yh 曰く、
2ちゃんねらが中心となって、「平和記念公園の焼けた折り鶴14万羽折らないか」と呼びかけている。今月1日、関西学院大の学生が広島の平和記念公園の折り鶴に放火し、学長が現地に赴いて謝罪するという事件になったが、このプロジェクトは、その焼失した14万羽分の折り鶴を広島に贈ろうというもの。参加方法は、OFF会を探して合流するか、50羽1セットにして有志に郵送する
2ちゃんねるでは昨日から、扉絵が壷から折り鶴に変わっている。2ちゃんねららは以前にも、テレビ報道への嫌がらせと称しつつ湘南ゴミ拾いオフを決行している。今回のプロジェクトも、参加するもよいし、偽善か否かを関わらず理解を示して応援してみてはどうか。
770245 submission
お金

Suica・パスネット・共通バスカードが一枚に

タレコミ by yh
yh 曰く、
関東圏の、23のパスネット発行事業者、27のバス共通カード発行事業者、3つのSuica発行事業者の(重複分も含めて)延べ53社局が、ICカード乗車券を共通利用できるように合意したと、JR東日本が今日付けのリリース(PDF)を出している。はやければ2006年から順次展開となる。
これは、民鉄やバス各社がこれから導入するシステムの規格を、Suicaに合わせる形になると思われる。3種のカードを使い分ける煩わしさが解消されるし、モバイル・スイカが登場すれば携帯電話だけで方々へ行けそうだ。
共通カードになる利点として、乗り継ぎの際の割引なんかも企画していただけるとありがたいが、複雑な交通機関を網羅することになると、やっぱ無理かしら。
770346 submission
書籍

Amazon.comが書籍の電子テキストを提供開始の噂

タレコミ by yh
yh 曰く、
本家発。Amazon.comが数千冊にものぼる紙版書籍の電子テキストをオンラインで提供すべく大手出版社数社と交渉中だと、NYTimes(要無料登録)が伝えている。
この機能は"Look Inside the Book II"と呼ばれ、今秋にもスタートするらしい。Amazon.comでは既に書籍の数ページをオンラインで読めるようにしているが、これを拡張して本文全体を検索可能なものとし、利用者が与えた検索語付近の数ページを閲覧可能とするもの。書籍をまるまる一冊読むことはできず、利用者が読みたい本を探し出しやすくするというマーケティング手法のようだ。
出版社に死蔵されている電子テキストのおもしろい有効活用法かもしれない。日本でもやってくれないかな。
770353 submission
GNU is Not Unix

RMSの伝記和訳プロジェクト:査読者募集

タレコミ by yh
yh 曰く、
結城浩さんのYukiWikiサイトで知ったのだが、初の(?)スラッシュドット発祥のプロジェクトである『Free as in Freedom』和訳プロジェクトが昨日から査読者の募集を開始した模様。まだ全訳が完了したわけではないようだが、ここでタレコミするには訳がある。翻訳モノは、成果物が登場してから、表現についてああだこうだと声があがるけれど、今回は、その出来上がりに自分の意見を反映させる良いチャンスとなるだろう。商業出版を視野に入れていて、その暁には協力者の名前も記してくれるようだ。参加方法は同プロジェクト「出張所」参照のこと。
もちろん、査読に参加しなくても、いままでは断片的にしか知ることのできなかったRMSの逸話をその生い立ちから現在まで日本語で通して読めるいい機会になると思う。
このプロジェクトは、リーダーシップ不在により半年以上進捗がなく事実上死んでいたのだが、この4月から新メンバーの加入で蘇生を果たした。タレコミ者は以前からウォッチしていたが、開始から1年でとうとうここまでたどり着いたかと思うと感慨深い。
770500 submission
アナウンス

オープン・ソース・アワード創設

タレコミ by yh
yh 曰く、
本家発。オープン・ソース・イニシアティブ(OSI)が、オープン・ソース・アワードを創設したとO'ReillyのOpen Source Conventionで明らかにした。ZDNetに記事が出ている。選考委員には、エリック・レイモンドや、ラリー・オーガスティンなど7人が名を連ねる。賞の種類は次の3つで、2004年の同Conventionで発表される。
"The Grand Master Award"は、オープン・ソースとインターネット文化に顕著な貢献した人物に与えられる。技術のみでなくコミュニティでのリーダーシップがあることが望ましい。賞金は10,000ドルで、選考委員に加わることになる。"Merit Awards"は、オープン・ソースやネットワーク・サービスのプロジェクトに対し、年4回与えられ、年に1度の表彰式となる。賞金は500ドル。"Special Awards"は、従来のカテゴリに収まらないプロジェクトや行いが選考委員会によって高く評価された場合に与えられる。賞金は1,500ドル。
770509 submission
TRON

坂村健著『大人のための「情報」教科書』

タレコミ by yh
yh 曰く、
坂村健[ほか]著『大人のための「情報」教科書』(数研出版)という本がこのほど、出版された。この本は、同氏らが執筆した「情報」科目の高校教科書をベースにリバイズしたもの。今年から始まった情報科目は、すでに高校を卒業している大人たちは学ぶ機会がない。そういうひとたちをターゲットに、いわゆるhow to本のように特定のアプリケーションの操作法を教えるのではなく、不変な原理を伝えようというのがその主目的。一読すると、後進たちがどんなことをどんなふうに学んでいるのかという認識を得ることもできる。
教科書ゆえに筆致はニュートラル、内容は基礎的・概説的で/.-Jの読者が必要とする本ではないと思うのだが、太字で書き加えられた解説部分からは問題や政策を訴える坂村節が垣間見られる。
夏の課題図書として坂村健氏の考えを知りたいというひとには、むしろこの本よりも、『ユビキタス・コンピュータ革命―次世代社会の世界標準』(角川書店)、『21世紀日本の情報戦略』(岩波書店)、『情報文明の日本モデル―TRONが拓く次世代IT戦略』(PHP研究所)をお薦めします。
770513 submission
ソフトウェア

IRCStepがオープン・ソース化

タレコミ by yh
yh 曰く、
Mac OS X / OPENSTEP用のIRCクライアントであるIRCStepがオープン・ソース化され、7月9日、そのソースコードが公開された。 修正BSDライセンスのもとで自由に改変、再配布することができる。Cocoa環境でObject-Cが使えるMac OS Xユーザから後を継いで大きく育ててくれるひとが出てきたらと期待したい。なお、#IRCStep (IRCNet)というチャンネルも開設されている。
作者であるAoVA氏のメッセージ「IRCStepのソースを公開するにあたって」によると、その理由を、開発モチベーションの維持が困難になったためとしているが、オープン・ソース化の決断に至ったことには敬意を表したい。なお「余談」として、「MacOS Xの開発環境でnibファイルを編集するとOPENSTEPではコンパイルできなくなることをお知らせしておきます」とのこと。
770545 submission
Python

Guido van RossumがZope.comを去る

タレコミ by yh
yh 曰く、
本家より: Pythonの作者であるGuido van Rossum氏が、現在行われているOreillyのOpen Source Conventionの席上で、Zope.comを去ることを発表した。新たな勤務先は、セキュリティ・ツールSatanの作者として知られるDan Farmer氏の率いるElemental Security社。これによりPyhthonの開発が実質的に変わることはない、との本人談だが、Zope 3の開発からは離れるだろうと推測されている。
ところで、"Guido van Rossum"の発音(au形式)って、「ホイド・ファン・ロシュム」でいいんですか?
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...