2003年9月の技術日記

SCOという「UNIX」の権利を保有している会社が、Linuxを使用している全企業に対して1台当たり7万円のライセンス料を課そうとしている。証明はおろか、証拠も示さず、裁判で判決も出ていないにもかかわらず、「法的手段〜」といった脅迫めいた脅しをかけている。

SCOの言い分

SCOがIBM提訴を決めた本当の理由 by CNET Japan

その他の情報源などから自分的にまとめると、SCOが主張する主な問題点は以下の点：

• （１）SCOが著作権を持つコードのこぴぺがLinuxのソースに見つかった
• （２）SCOが保有する特許のソフトウエア開発を過去にIBMに委託したが、そのコードがLinuxから見つかった

それに対する反論

Linux論争でIBMがSCOに反撃、GPLの解釈が焦点に by ZDNet

ついに行動を起こしたRed Hat、SCOは「反訴検討」 by ZDNet

トーバルズ、モグレン両氏が「SCOの矛盾」を語る by ZDNet

これらの反論の根拠を自分的にまとめると、

• SCOは自分でLinuxをGPLで配布しているので（１）は問題にならない
• 集合的著作権によると、集合の著作権と部分の著作権は区別されるので（２）は問題にならない
• そもそも、著作権に違反しているのはLinuxの開発者側であり、Linux利用者を訴えるのはおかしい

さらにSCOの反論

• SCOは自社の技術をGPLで配布したつもりはない（GPLを良く知らなかった）
• IBMとの契約で、秘密保持契約や派生物の権利も規定してあるので、集合著作権は主張できない
• Linuxの利用に関する権利条項もあるので、利用者を訴えることも出来る

これらの主張とその証拠が裁判でどう判断されるかにかかっている。
しかし、その肝心の証拠がどうも怪しい。

SCOにより「好例だ」と示された証拠について

SCOの「証拠」に対する Bruce Perens 氏の反論 by /.J

SCO の「パターン解析」チームはこのコードを発見し、Linux に存在するコードと似ているという正しい推論をした。しかし彼らはそのコードがすでに他の人々にも合法的にコピーできるように公開されていたかどうかを確かめるというステップを踏まなかったのである。

ということで、SCOが自信を持って唯一公開したコードは全く的が外れていた模様。技術に詳しくない人々は「SCOの証拠はでっちあげではない」と言う人が多いというが、それはつまり技術に詳しくないので「こぴぺ」と示された以上の事に言及できないだけで、技術や歴史に詳しい人々はその「こぴぺ」の事情を知っているということであろう。

先月からSobigが大量にやってくる。1個検出するたびに対ウイルスソフトが警告を発するのだけども非常にめんどくさい。多いときは10分に1回のペースでやってきた。

その中で、どこかのサーバーが「ウイルスを検出したので弾きました」という通知メールを送ってくるものがある。明らかに From や Return-path が偽装されているのだけども、その From 宛に「おい貴様！お宅からこんなウイルス付メールが送られてきました。ちゃんと自分のパソコンぐらい面倒見てください。」みたいなお叱りメールをもれなく送ってくれるという設定になっているらしい。

このようなメールサーバーや経路の途中でウイルスチェックをするシステムのことを、アンチウィルスゲートウェイというらしい。

偽装されたFromに通知メールを送ってしまう設定の結果は以下のよう。

• 第三者（偽装されたメールアドレスの持ち主）は迷惑。また、通知メールにウイルス混入の場合は、さらに被害が拡大する恐れがある。
• 第三者にメールアドレスや、メールや添付ファイルの内容が知られてしまう （ウイルス検出自動通知によるメール・アドレス漏えいに注意，近畿日本ツーリストで発生by IT Pro）
• 通知メールで上のようなトラブルは起きても、決してウイルス感染が収まることは無い。

また、宛先にも通知メールを送ることになっている場合も多々ある。

• Fromが偽装されているので、通知メールをもらった人にとってあまりメリットが無い。
• 偽装だと分からない普通の人は、そのままFrom宛に怒りのメールを送ることがある。
• やっぱりトラブルばかり起きて、何もメリットが無い。

ちなみに、Fromを偽装しないメールの場合は通知メールは多少役に立つかもしれない。
しかし、ToやCCにたくさん列挙してある場合は通知をたくさんばら撒いてしまう可能性もある。また、存在しないユーザー宛にウイルスを送りつけて、UserUnknownなウイルス付メールを From 宛に送らせるといったウイルスもいるらしく、その場合は通知メールがサーバー間を往復しないように注意深く設定しなければならない。やはり、通知メールはサーバー管理者宛にするというのが適当であろう。

それより、対ウイルスソフト会社側の対応が甘すぎる。検出したウイルスがどんなウイルスか分かっているのだから、Fromを偽装するウイルスの場合は通知しないとか、ヘッダの内容を調べてから偽装を見分けるなどの処理を行うなど、数百万、数千万円以上の価格に見合うだけの仕事をして欲しいと思う。

最近どこにでも「Privacy Policy」や「個人情報保護方針」などの文面を見かけるようになった。詳しくは以下のサイトがわかりやすい。

• ユーザー・プライバシーの尊重(by IBM dW)
• プライバシーポリシーは策定することより実行・遵守が大切(by Manaboo's Room)
• 「値札」としてのプライバシーポリシー(by japan.internet.com)

自分的にまとめると Privacy Policy は以下の項目を明示し、守っていくこと。

• そのWebサイトの目的は何か
• そのWebサイトから顧客に関するどのような情報を収集するのか
• 上に明示した目的に従って、収集された情報をどのように保管・利用するのか

一定の基準を設けて消費者の判断を分かりやすくしようということで、プライバシーに関する認定制度があるらしい。

• TRUSTe
• プライバシーマーク制度

しかし、意味のないPrivacy Policy が氾濫(by memo)したり、情報が漏れ(by @IT)続けたり、チェック体制もよく機能していない(by memo)らしい。特に多いのが「等」「〜ことがあります」の表現(by 今日の必ずトクする一言)で、このような曖昧な表現では説明したことになっていない(by 高木浩光＠茨城県つくば市の日記)。

こんなことになってしまう原因としては以下のよう。

• Privacy Policy を書いている人に問題がある（法律には詳しいが技術に詳しくない、技術には詳しいがポリシーやプライバシーについての意識が無い）
• Privacy Policy を書くことが目的になっている
• プライバシーポリシーが個人情報を直接扱う人々に理解されていない

この中で目に付くのは、Webにおけるセキュリティーの意識の低さや技術レベルの低さである。例えば、上で挙げたリンク先の中には多くの有名情報系企業が名を連ねる。まさかそのようなセキュリティーを謳い文句にしていたりする企業が、誰一人としてまともなセキュリティー技術者を擁していないとは思えない。要するに、あなたの個人情報、Webサイトから漏れまくり!?（3/4） (by PC View) で指摘されているように
（１）企業のWeb製作現場が主戦力から外されたスキルの低い技術者が左遷される場所であったり、
（２）趣味の延長程度の技術しかないデザイナーがWebサイトを運営していることが、セキュリティー事件頻発だったり、Privacy Policy がいいかげんである原因の一端なのであろう。

Webサイトは企業の顔であり、外部の人にとって直接知りうる企業の全てである。Privacy Policy がお粗末であれば企業のモラルを疑われ、ユーザビリティーがお粗末であれば顧客対応がいいかげんだと思われ、セキュリティー問題が起きれば企業への信用が失墜する。情報メディアが増えると、メリットと同時に大変なことも増えるのだなと思う。

昨年 Microsoft は「Windowsはセキュリティーに問題がある」というレッテルを払拭する為に、「Trustworthy Computing」というセキュリティー戦略を打ち出した。現在エンジニアにセキュアなプログラミングの教育を行っているらしい。また、近年の主流であるWebアプリケーションについても、手軽であるが故にセキュリティー上の問題が多くしかも根が深い。

• MS最高セキュリティ責任者の言い分は「ソフトウェアを安全にするだけでは十分でない」 by cnet
• Webアプリケーションに潜むセキュリティホール by @IT
• ソフト/Webの脆弱性対策のため、何が必要なのか by pcweb

セキュアな開発と保守について、

新聞等などで話題になったセキュリティー問題は、破る側の圧倒的な技量や計算量で行われたのかというとそうでもない。ほとんどが「被害者」と言われる方の開発・設定ミスや保守体制の不備から来るものであり、鍵をかけてない家に侵入されたようなものである。中には高度な技術で侵入されたような事例もある。また、仕様の時点で既に穴があるものもある。このことから、セキュリティー上の穴は以下のように分類できるように思う。

:仕様の穴

設計時の理論的な動作ですでに穴や欠陥がある。

ここで既に穴があれば、以降どう頑張っても穴が残ることになる。

仕様ではどういう環境で動かすのかという仮定（後述）が重要になる。

:実装の穴

開発時にセキュリティーの穴を作ってしまう。

アプリケーションの設定や配備時のミスで、意図しない穴があく。

日々新しい穴が見つかるものなので、OSやシステムのアップデートが必要。

:現実・運用時の穴

知られてない穴から侵入される。うっかりミスもここに入るかもしれない。

仮定・想定外の事が起きて、セキュリティーを破られる。

どうあるべきか

• セキュリティエンジニアリング by IPA

それを読んだ上で自分なりに気をつけるところを挙げるとすると以下のよう。

まず、できるだけ沢山のリスクを評価する。現在知られている侵入・攻撃方法や、今から開発しようとしている仕様の弱点を考える。

それらを元に、仕様の前提となる仮定を決める。具体的には、できる・できない、考慮する・しない、見合う・見合わない、あきらめるなど。できれば顧客と一緒に考えたり説明したりする方が良いと思う。例えばインターネットから物理的に隔離された社内システムでは防壁や社員のモラルをある程度信用できるので、「悪人がシステムを直接攻撃することは無い」といった仮定を立てることができる。一方、公衆インターネットに接続されたシステムは、「パケットが盗聴される、Refererを収集される、DoSを受ける、物理的に侵入・攻撃を受ける、高性能計算機で暗号が解析される、ありえない値が入力される、バッファオーバーフローが狙われる、IPやMACアドレスが詐称される、ソーシャルエンジニアリングが行われる・・・」などのあらゆる可能性を立てなければならない。

その仮定を元に、完璧な（少なくともそう思える）仕様を考える。ここで既に穴や欠陥がある場合は仕様として失格だと思う。

実装・テストはひたすら頑張るしかない。具体的には専門書にかかれてあるが、穴を作ってしまう局面は非常に多いようだ。

いつでも保守は忘れられがちになる。システムのアップデートはもちろんのこと、もうひとつ重要なのは仕様策定時に考えた仮定が崩れていないかのチェックだと思う。身近な仮定崩壊の例は銀行の届け出印鑑方式。印鑑は複製が難しいため、陰影だけを調べて認証を行うことができるという仮定は、デジタル技術で陰影の複製が容易になった今では成り立っていない。

仮定が破れてしまったらもう一度仕様策定から始めなければならない。センスのいい仕様であれば、最小限の手間で仕様変更を行うことができるはずだと思う。

結局、開発側のセキュリティー対策を行う為には、各方面の広く深い知識と経験と、先を予見するセンスや想像力といったものが要求されるようだ。電話のように安心してコンピューターが使える世の中は、来るのかどうかも怪しいように思えてくる。

CGIでメールを送る機能、所謂フォームメールの多くは、type="hidden" で送り先を指定しているらしい。試しにgoogleで「フォーム メール CGI サンプル hidden」と入れてみると、大手のフォームメールのサンプル設定が並ぶ。どれもこれも、送り先がhiddenで指定してある。中にはFromまで指定できるものや、添付ファイルまで付けれるものもある。スクリプトが公開されているものもあるので、軽く眺めてみると、特に制限をしているようでもないらしい。

〜?mailto=hogehoge@test1.com&〜 とかやると、任意のアドレスに無条件に送れてしまったりするのだろうか。

人のコンピューターの面倒（相談、購入、トラブル）を見る機会が多いが、所謂オフィスに関する質問はびっくりすることが多い。

• オフィスアプリケーション は MSOffice しか無いと思っている
• MSOffice はパソコンについてくる無料のおまけと思っている
• 無ければコピーすれば良いと思っている
• パソコンを持っている人は全員 MSOffice を持っていると思っている

なので、「MSOffice Standard は4万5千円しますよ」と言うと、！の顔になる。今時、まともにWindowsXPとMSOfficeを買うと7〜8万してしまう。各企業がLinux＋OpenOffice系に乗り換えているのも理に適っている。

確かに、MSOffice は事実上のスタンダードであり、企業の現場や官公庁では当然のようにMSOfficeの文書がやり取りされている。実際、積極的にMSOfficeに用の無い私も、持ってないと多くの場面で困ることが多いので、VMWareのWindowsXPの中にとりあえずOfficeXPを入れている。

しかしながら、以下の点から自分で積極的に使ったり、自信を持って人に勧めたりすることはない。

値段が高すぎる

　確かに機能は多いが、これだけ売れていながら値段が安くならないのは健全ではない。実際、多くの人がお金を払うことより、リスクを犯した違法コピーを選んでいる。いくらなら払うかと聞いた事があるが、Word、Excel、PowerPointのセットで大抵1万円程度が限度らしい。

危ない

　メールや文書を開いただけで目の前のコンピュータを壊すことができる仕組みなど、欠陥以外の何者でもない。しかも、壊れてもMS社は知らんと使用許諾契約書に書いてある。これは初心者は使うなということであろう。

　また、ファイルがMS社による独自仕様なので将来に不安がある。MSOfficeのバージョン間での互換性さえ怪しいので、今作ったファイルを数年後にそのまま使えるかどうか分からない。実際、Office97で作った画像の入った文書をOffice2000で読むと、原形をとどめなくなったことがある。たぶん字だけのテキスト文書程度なら問題はないのであろう。

使い難い

　Officeは出来てから10年近く経つ。基本的な機能はOffice97ぐらいに完成したと言われていて、基本的な使い方はほとんど変わってない。つまり、今も昔もユーザーは同じような問題に遭遇している。相変わらず機能は多いけども、その機能を呼び出す方法は機能が増えるにしたがってさらに分かりにくくなっている。

　機能がありすぎる反面、個々の機能の完成度がいまいちである。Wordなどのデフォルトの書式レイアウトは全然綺麗でない。また、図も、文章に連結してあると予想もしない場所に飛んでいったり、紙からはみ出たまま動かなくなったり、結局手でレイアウトを余儀なくされる。面白いのは、近所で何にでもPowerPointを使う人が増えたことであり、結局必要とされるのは基本機能のみであり、シンプルが好まれるということらしい。

なので、人には無料のOpenOfficeか、使いやすくて安い Lotus Super Office を勧めるのだけども、なかなか受け入れられない。こぞって言うのは「使いにくい」。多くの場合、単に慣れの問題であるのだけども、UIが世界にひとつだと思っているような人には確かに操作方法の違いによって生産性が落ちてしまうかもしれない。

個人的に使ったことのあるOffice製品（主にワープロ系）を並べてみる。
結局適材適所ということかもしれない。

MS Office

メリット

スタンダード、みんな使っている

図形、表が強力

アウトラインモードが便利

デメリット

高い

バージョン間でさえ互換があやしい

枠、図の挙動が手におえない

マクロが危険

基本以外の機能が多く、メニューやダイアログのまとめ方が変

ヘルプが使えない

目次生成が弱い

特に、数十ページ以上の図入り文書を書くと、図の調整に多くの時間を取られてしまい、二度とWordで内容のある文書を書きたくなくなる、

Open Office

メリット

無料

OS問わない

MSOfficeと高い互換

マクロが安全

デメリット

インストールに多少違和感

テンプレート少ない

禁則処理ができない（version 1.0.3）

現在、まだ自分の中では「評価中」。Open Officeで多くの文書を作ってはいるけども、段組を駆使して1ページに図を何枚も貼り付けて、文字の流れを細かく制御するような凝ったレイアウトにはまだ早そう。

Lotus Super Office

メリット

操作性が最高（プロパティー窓が使い易い）

枠、段組の扱いが強い

安い（乗り換え価格で4000円程度）

DBソフトの Approach が使いやすい

デメリット

図を大量に使うと重くなる

UIが見た目古そう

数式が弱い（ほとんどWordproでしか使えない）

矢印、簡単な図形が入れ難い

将来のサポートが不安

自分の中のメイン。凝ったレイアウトや何十ページもある図入りの文書に関しては、Wordproが非常に強力で使いやすいと思っている。

せっかくIBMに移ったのだから、IBMの主力Office製品として是非継続して欲しいと思う。

一太郎

メリット

フリーカーソール

強力な罫線

国産

デメリット

フリーカーソール

罫線

人に使い方を教える程度には勉強してみて使ったことはあけども、一太郎で本気の仕事をしたことが無いので実際には良く分からない。フリーカーソールと罫線はワープロ機から移ってきた人には非常に使いやすいらしいけども、それらを駆使した文書は構造に多少問題があるように思う。

LaTeX, SmartDoc

メリット

強力な文書構造

強力な自動組版

目次、索引、参照の自動生成

数式が強い

デフォルトですでに綺麗

フォーマットがテキストで、OS非依存

デメリット

インストールが大変

慣れないと書き難い

完成図を想像しなくてはならない

ワープロではないけども、自分が書くほとんどの文書形式がこれなので。

いろいろ人と文書を交換していて2つのパターンに分類できそうなことが分かった。

紙上指向

頭の中に1枚の紙が浮かんでいる。

書きたい内容とレイアウトは一心同体だと思っている。

紙1枚にこだわるのが好き。

Excelでは、最初から紙のレイアウトを意識する。むしろ、表はWordで作る。

Wordの中で、図は勝手に動かずに、いつもそこにいて欲しいと思っている。

見出しや箇条書きは自分でレイアウトや書式の設定をする。

インデントやセンタリングは手軽な空白で調整する。

PowerPointが大好き。

多分芸術家。

論理指向

書きたい内容だけが浮かんでくる。

レイアウトは後からついてくるものだと思っている。

文書を書くときには特に枚数は気にしない。

表であらわせるものは、何でもExcelを使う。紙のレイアウトは最後に適当に考える。

Wordの中で、図は文章と共に動くものだと思っている。

見出しや箇条書きはスタイルを使って後で書式を設定するものだと思っている。

空白で位置調整はあまりやらない。タブ・インデントやセンタリングを利用する。

プレゼン目的でしかPowerPointを使わない。

多分理系。

どっちが間違いというわけではないけども、○×でアンケートを取ると圧倒的に紙上指向の人口が多いように思う。

綺麗なレイアウトは、書き手にとっては伝えたいことを効果的に表現する手段であり、読み手にとっては内容の理解を助けるものであると思う。レイアウトの達人は、そのあたりを上手く表現することができる。しかし、多くの人はレイアウトに関する教育や訓練を受けてなかったり、天才的なひらめきも無いのが普通であろう。

以上のことから、多くの場合はレイアウトの素人で紙の上指向なので、人の書いた「〜.doc」な文章は高い確率で読みにくい（理解しづらい）という予想が得られる。

何かと入力チェックは頭が痛い。とりあえず、簡単にJavaで入力された日付がちゃんとしているかどうかのチェック方法。

import java.util.*;
import java.text.*;
------
//String inputDate; "20030930"のような「西暦月日」の形式
SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("yyyyMMdd");
try {
  Date sampleDate = DATE_FORMAT.parse(inputDate);
  if (!DATE_FORMAT.format(sampleDate).equals(inputDate)) {
    //日付として解釈は可能であるが、見た目おかしい
    //例：20030332 --> 20030401と解釈される
  }
} catch (ParseException e) {
  //日付として解釈できないような入力値が不正の場合
}
// ここまで来たらinputDateは正しい。

同様に、時間や他の処理系でも同様なことができるはずだと思う。

RubyでPostgresqlからデータを取ってきて、LaTeXでレイアウトしてPDFにする。
見事に半角カナが含まれていて、困っていたところ、Ruby(1.6.8)の標準添付ライブラリのnkfで「半角カナ」から「全角カナ」に変換出来た。何故か濁点が残っていたので、適当に削除してみた。

require 'nkf'
# inputはSJIS
output = NKF.nkf("-Se", input)
output.gsub!("゛","")
# outputはEUC-JP