[CN | DE | EN | FR | JA | ES | KO | PT | ZH]

Brave GNU Worldのまた別な号へようこそ。 ドイツはKarlsruheのLinuxTag前に時間がとれずに、 LT会場からの生中継ならぬ「遅中継」をお届けします。

ときとして e-Democracy (民主主義) ともいう、 e-Government (政府) は、 今日、 物議をかもす話題のひとつです。 多くのロビイストらが、 この話題を研究しています。 欧州委員会は、 特別作業部会を立ち上げました。 ドイツの Ver.di [5] といった一部の貿易組合は、 e-Democracyの議会まで組織し、 IT産業は、 将来の増収を楽しみにしています。

e-Democracyは一般に、 政府の作業工程をより柔軟、 透明、 廉価、 効果的にするために設計されています。 e-Democracy傘下の話題のひとつには、 e-Voting (投票) があり、 これがまさにSede Project [7] の扱っていることです。

Sede

Sede [7] は、 "Secure Democracy" (「安全確実な民主主義」) の略です。 プロジェクトを始めたJos Boersemaの目標は、 簡単で、 しかし、 投票者の匿名性をまもりつつ、 それと同時に結果を検証できるような、 つまり不正のできない、 安全で確実な電子投票機構を作成することです。

仕組みは本当に簡単です。 各投票者は、 一意の投票用紙符号を受け取ります。 投票用紙符号は、 任意の長さをとれて、 小細工が防げるよう、 無作為に生成されます。 選挙に先立って、 Sedeは、 投票用紙符号のある人工投票用紙を郵送します。 投票者は、 電子メール・クライアントを使って、 自分の票を、 投票サーバーに戻します。

投票サーバーは、 票を集計し、 ダブりや無効票を除きます。 各投票者は、 自分の票がちゃんと集計に入っていることを、 オンラインで確認できます。

投票者は、 コメントや宣言を追加でき、 また投票書式は、 投票者の選好に合うよう、 調節することができます。 おまけに、 Sedeは、 比例代表もサポートしています。

このプロジェクトの作者は、 投票書式の符号に基づく体系が、 どうはたらくのかを研究しているうち、 基本的な考えを2002年の11月に思いつきました。 多少の生みの苦しみの後、 プログラムは、 その価値を証明し、 それまでにない集中的な開発活動の対象物となりました。

このプロジェクトはCと、 Zシェルのスクリプトで書いてあり、 GNU General Public License (GPL) の下で、 フリー・ソフトウェアのプログラムとして公開されています。 Sedeはモジュール化されており、 電子メール以外のプロトコルの利用も可能です。 しかし、 Webアクセス用のグラフィカルなフロントエンドがまだありません。

すでにBrave GNU Worldの第25号で指摘したように、 このプロジェクトは、 やや物議をかもしています。 多くの人びとが、 この種の仕組みと実装の安全性に疑問をもっています。 また、 一部の人びとには、 この種の仕組みは一切実装しない方が、 好まれています。

Josの見たところ、 計算機技術を使い紙ベースの票集計の模倣を達成しようとした企画が多いことに、 問題があります。 もちろん、 この一連のプログラムが実際、 電子データ処理の潜在力を作用させなかった、 ということがその特徴です。

棄権者は、 またひとつの重要な面です。 もし侵入者が、 システムの電子メール・メッセージをなんとかかぎ出して、 棄権者の投票者符号を発見できたならば、 侵入者はそのコードを悪用できるでしょう。

匿名性は、 投票者符号から特定の電子メール・アドレスをたぐる方法がないことを、 あてにしています。 しかし、 電子メール・メッセージが、 Internetを経由して伝送される以上、 その保証は、 ありえません。 配送中の投票用紙をかぎつけることで、 電子メール・アドレスと投票者符号のデータベースを作ることが、 攻撃者には可能でしょう。

したがって、 プロジェクトの成功は、 各構成要素の実装程度にかかっています。 もちろん、 還流機構と暗号化で、 劇的に安全性を向上させることはできます。

高度に発展した西側諸国の選挙を見てもわかるとおり、 結局、 紙ベースの方法にも、 多少の弱点はあります。 ここしばらく、 志願した市民支援者による検査でも何もできなかったことを知っています。

潜在的な弱点にもかかわらず、 Sede Projectは、 この領域で起きている技術論議に、 確かに興味深い貢献をしています。

将来の開発計画では、 安定しこぢんまりとした解決法を提供するプログラムの改良や、 重大なバグの迅速なデバッグにとりかかれるようにすることを、 展望しています。 開発者らの次期開発リストには、 暗号サポートと、 いろいろなLinux配布物件用のパッケージの作成があります。

いつもどおり、 このプロジェクトも作業を全部片付けるには、 手助けがいります。 Josは、 フィードバックや手助けを歓迎しています。

オンライン投票: 有意義、無意義?

オンライン投票の実装に入る前に、 オンライン投票が望ましいのか、 そうでないのかどうか、 もっと考えるべきであることは、 確かです。

この新しい技術の代弁者たちは、 選挙がこれで早く効率的になると、 確信しています。 反対者たちは、 計算機投票などまともにとるに値しないと主張しますが、 これは、 その独特の特徴として、 民主主義的な意思決定過程を質的に変えることのない、 ということがいえます。

オンライン投票でより多くの選挙が実施できることや、 それにつれた人民による政府への支配強化を、 より直接的な民主主義形式の推進者らが宣言するとき、 話はさらに興味深さを増します。

これは、 はてしない選挙運動の危機を増加させ、 そしてまた経験の語るように、 ちゃんとした政治家や選挙運動は特に両立しないのです。 特に、 必要であるがしかし一般的でない決断は、 おそらくなされないでしょう。

政府執務室では、 引継ぎや提携に、 いつも時間がかかります。 人民の一部が、 国政選挙と同時に、 地方選挙を執行したがるのは、 そういうわけです。

残念ながら、 選挙が多くても自動的に民主主義の質が向上はしない、 という理由が他にもあります。

票それ自体、 選挙の最重要面、 というわけではありません。 票はすべて、 有望な効果を評価し、 長期的問題を考慮したうえでの、 決意や意思の決定過程から来るものです。

票は、 意思決定に先立ち、 各投票者が前述の過程に参加したときにかぎり、 質的に良い結果を得るにすぎません。 しかし、 それには時間がかかります。

しかし、 今日にいたっても、 往々にして、 職業政治家が、 たとえ特定の手段に責任があるだけであり、 また、 一般に労働時間が長いとしても、 その一部であるべき意思決定過程の全部に参加することは不可能となっています。

したがって、 直接的な民主主義では、 全住民が政治について考える以外に、 何もしないとしても、 各投票者それぞれが徹底的な反映過程をくまなく調べることが、 不可能となっています。 そのため、 かなり表面的な公約の評価に基づいた決定がなされますが、 これは修辞学的ペテンにとても弱いことがあるのです。 これはすべて、 下される判断の質に影響します。

以上のようなことから、 選挙が多ければ多いほど、 より表面的で短期的な決定の傾向を増加させることがわかります。 政治家が自分に責任のある意思決定過程に実際に参加できるよう、 体系を変化させるべきかもしれません。

しかし、 それを達成する方法は、 オンライン投票が良いことか無意味かという問題とは、 ほとんど無関係ですので、 コンピュータ業界に、 より具体的には、 しばしば悪口のたたかれるバックアップの話題に戻ることとしましょう。

Storebackup

Heinz-Josef ClaesによるStorebackup [8] は、 データを、 ローカルのハード・ディスクへであれ、 NFSを使った遠隔計算機のそれへであれ、 保存します。 これで、 追加のハードウェアへの投資なしで、 手早く簡単にバックアップを作ることができます。

テープのバックアップは (特にテープを別のビルにある金庫に保管するなら)、 究極的に安全な解決法ではありますが、 ハード・ディスクのバックアップは高速で、 データの復旧手順が簡素化されます。

Storebackupが初めて日の目を見たのは、 ほぼ3年前。 当時、 Heinz-Josefは、 ラップトップを携帯しながら日常的に出張に出ていました。 データ転送速度の低い並列Zipドライブが使えて、 回線資源をほとんどいらないバックアップ・システムを探しながら。 ハード・ディスク空間をなるべく使わず、 データの復旧手順を簡素化するように、 このプログラムが設計されたのは、 そういうわけなのです。

Storebackupでは、 同一のファイルが (たとえ別録りのバックアップであっても) バックアップ用ディスクに一度だけ書き込まれるようにするのに、 ハードリンクを使っています。 また、 この手法では、 差分や完全のバックアップという効果もあります。

初期バックアップ完了後の全後続作業には、 差分バックアップにいる資源が必要なだけです。 この事実にもかかわらず、 1本のバックアップには、 ファイルシステムの全ツリーと、 そのファイルが、 含まれています。 したがって、 データの復旧が必要な利用者には、 特定のファイルを見つけるためにさがしまわる、 という骨の折れる仕事がないのです。

バックアップや復旧手順では、 ファイル許可も保存されるので、 一部のファイルの復旧には、 ファイル管理者の必要なことがあります。 ハードリンクを使うことによる1つの欠点は、 場合により、 管理者の補助が必要になる、 ということです。 もし複数の利用者が同一のファイルをもっていると、 ファイルの許可がおりない場合には、 ファイルの復旧ができないことがあります。

個々のバックアップ作業は、 並列で実施されます。 たとえば、 同一のファイル群を特定するためにMD5チェックサムを計算するプログラムがあります。 Storebackupが圧縮するファイル群を選択するときに使うパターンは、 各利用者が指定できます。 大きなファイルの複製と、 ハードリンクの作成プロセス群も、 同時にうごきます。 多重プロセッサ・システムをより効果的に活用するため、 複製と圧縮は、 並列で実施可能です。

このStorebackup Projectには、 個々のバックアップ一式を管理し、 古いバックアップを削除するツール同様、 分析と復旧のツールも入っています。 さらに、 Storebackupは、 便利なログファイルを生成します。

このプログラムは、 Perlで書いてあり、 GPLの下でリリースされています。 ソース・コードを除き、 Debianのパッケージがありますが、 これを書いている時点での状態は、 Testing (検査中) とUnstable (不安定) です。

このプロジェクトは、 すでに一部の製品で利用されています。 とても大きなスプレッドシートの編集が必要で、 なおかつ、 そのスプレッドシートをしばしば破棄する悪いくせのある従業員の場合のように、 多くの場合、 利用者の仕事がかなり簡素化されています。 Storebackupに移行して以来、 スプレッドシート復旧時間は、 2時間から2分に激減しました。

どうやってここまで達成できたのか、 と聞かれたとき、 そこの管理者は、 従業員の近くで監視して動作記録をとっていたんだ、 と冗談交じりに答えました。 その管理者が本当の理由をその従業員に説明するまで、 彼女は、 本当にかっかときていて、 その件で笑えるようになるには、 まだしばらくかかったものです。

Heinz-Josefは、 将来の版で、 古いバックアップの削除処理を向上させるつもりでいます。 また、 バックアップ分析 (いつファイルが修正されたか? どこかに同じファイルがあるか?) と復旧手順の間の直結合も追加するつもりです。

しかかりになっている他の改善点は「ぜいたく品」です。 すなわち、 ディレクトリーでも、 ファイルでも、 名前付きパイプでも、 シンボリックやハードリンクでもないファイルのバックアップです。

Heinz-Josefは、 文書化への援助があれば幸いと思っています。 全プログラムには、 けっこうまっとうなお助け機能がありますが、 たとえば、 今のところは、 マニュアル・ページがないのです。

それでは

さて、 今回はこのへんで。 いつもどおり、 フィードバック、 ご質問、 コメント、 新規開発や興味深いプロジェクトのお知らせは、 いつものアドレス [1] までいただければ幸いです。