「さまざまな問題について」の編集履歴(バックアップ)一覧に戻る
さまざまな問題について - (2010/08/24 (火) 18:22:23) のソース
*さまざまな問題について この事件の背後には,さまざまな問題がありました。岡崎市,岡崎市立中央図書館,三菱電機インフォメーションシステムズ,愛知県警,検察,裁判所のそれぞれに誤りがあり,それらが積み重なった結果,無碍の利用者であったlibrahack氏が逮捕され,20日間勾留され,罪に問われる一歩手前まで追い込まれたのです。 このページでは,それぞれにあった問題点について,繰り返された議論や検証などをもとに,私(管理者:杉谷)の視点で掘り下げます。 具体的なソースについては,[[各種リンク>リンク]]から各所を参照してください。 **岡崎市の問題 岡崎市は,市民の税金を用いて予算を組み,三菱電機インフォメーションシステムズの MELIL/CS を購入しました。また,継続的に運用管理を依頼しています。 MELIL/CSの導入は「プロポーザル方式」で決められました。これは,複数の業者に提案をしてもらい,最も優れた案を採用するというものです。 しかし,WEB システムとして極めて性能の低いシステムを購入してしまったことについては,適切な比較検討が行われたのか,適切な採用条件だったのか等,問いただされるべき問題があります。 運用管理についても,随意契約で継続して三菱電機インフォメーションシステムズと契約しています。不具合を修正させることができる契約内容なのかどうか,確認する意義はあると考えられます。 **岡崎市立中央図書館の問題 岡崎市立中央図書館は,大規模なリニューアルに際して MELIL/CS を導入しました。その後,運用管理の責任を負う形で,図書館側が指示を出し,三菱電機インフォメーションシステムズがそれに応じるという形で運用が続けられました。 今回の事件に際して,警察の求めるままに被害届を出したこと,アクセスログに関して三菱電機インフォメーションシステムズと連携して「これは攻撃ではない」という判断を下せなかったことについて,問題があります。情報システムの運用について,運用主体として委託先と充分に連携できていたのでしょうか。 また,アクセスログの提出が被害届の提出前にも行われていたこと,同時に四名の個人情報を警察に渡していたことなど,図書館としての個人情報取り扱いに問題があったと考えられます。 これは,[[岡崎市個人情報保護条例>http://www.city.okazaki.aichi.jp/reiki/reiki_honbun/ai50401231.html]]第8条に抵触する可能性がある上,[[図書館の自由に関する宣言>http://www.jla.or.jp/ziyuu.htm]]の第3の2で謳われている「図書館は、読書記録以外の図書館の利用事実に関しても、利用者のプライバシーを侵さない。」という言葉とも矛盾します。 被害届の提出前に,個人情報を沿えて,アクセスログを提出する。この行為は,図書館を信頼していた岡崎市民への裏切り行為とも言えるのではないでしょうか。 **三菱電機インフォメーションシステムズの問題 致命的なほど性能の低いシステムを納品したことに関して責任があります。通常,常識的な最低限の技術力をもってシステムを構築していれば,今回の事件は起こりませんでした。 そもそも,一般的な WEB システムにおいて,毎秒一回を下回る速度でのクロールでサーバが応答できなくなることはありえません。 [[Twitter 上での議論>http://togetter.com/t/librahack]]および[[技術者の検証>http://gutei-blog.blogspot.com/]]により,WEB システムとして通常ありえないレベルの欠陥が確認されています。 この欠陥は,セッションが解放されるまで長時間かかることによって有効なセッション数が一定数で頭打ちとなるため,[[サーバの性能をどれだけ上げたとしてもシステムの性能は改善しない,プログラムの根本的欠陥でした。>http://twitter.com/bulkneets/status/21794158063]] また,三菱電機インフォメーションシステムズはMELIL/CS ASP版の欠陥を認識していた可能性が指摘されています。おそらく過去に検索エンジンのクローラのせいで本事件と同様の症状を発生させ,それを回避するために robots.txt を設置していたのではないか,と考察されています。 もし欠陥を認識していながら修正せず検索エンジンからのクローラを排除することで欠陥の存在を隠していたのであれば,顧客である図書館に対して非常に不誠実な対応を取っていたことになります。 また,ソフトの問題で検索が遅く使いづらかったため図書館職員から苦情があった際には,[[「ハードの性能が低いからだ」と答えていた>http://twitter.com/kanda_daisuke/status/21782251370]]ようです。 **愛知県警の問題 まず大前提として,警察の責務は警察法第二条によって定義されています。大雑把に言えば,警察は治安維持と犯罪防止と被疑者の逮捕を行うけれど,その責務は厳密に縛られていて,容疑者の言い分や被害者の言い分のどちらかに肩入れすることなく,公平で,かつ,むやみやたらとその権力を行使してはいけません,といったところです([[警察法>http://law.e-gov.go.jp/htmldata/S29/S29HO162.html]])。 愛知県警は,岡崎市立中央図書館から提示されたアクセスログを読み誤り,また,偽計業務妨害の罪を構成するために故意が必要でないと考え,結果的に librahack氏を逮捕,勾留するに至りました。 アクセスログを読めば,一般的な WEB システムの知識があればこれは攻撃ではないことが明らかであったはずです。 また,偽計業務妨害には故意もしくは未必の故意が必要です。愛知県警はこれを誤り,家宅捜索に至りました。 愛知県警には[[サイバー犯罪を取り扱う部署(生活経済課)>http://www.pref.aichi.jp/police/safety/high-tech/index.html]]があります。何故,技術的知見に基づく判断ができなかったのでしょうか。 加えて,捜査上,対象の行為が罪を構成しているかどうかは警察官が常に意識しているべき要点であるはずです。罪を構成していないのであれば,捜査する必要すらありません。 さらに,警告や注意を行わず,いきなり逮捕に及んでいることを見落としてはなりません。仮に偽計業務妨害であったとしても,迷惑行為に対して警告や注意を行い,それでも改まらなければ罪に問えばよかったのです。事実,librahack氏は逮捕のその日まで,岡崎市立中央図書館のサーバが停止した状態になっていたことは知りませんでした。 そのうえ,任意の事情聴取に際して,「DoS攻撃」「業務を妨害した」「責任を取る」といった文言を含む,あらかじめ準備した調書にサインをさせました。これは,正常な取り調べ(供述調書の記録)とは言えません。 逮捕後,勾留十日目ごろには,警察はlibrahack氏が攻撃を行ったのではないとの認識を持っていたとの取材結果もあります。 愛知県警は四点の誤ちを犯し,結果的に librahack氏は[[不起訴処分(起訴猶予処分)>http://librahack.jp/okazaki-library-case/conclusion.html]]となりました。起訴猶予処分を受けた人は,前科ではないものの,前歴として記録されます。これは将来,万が一別件等で起訴に至った場合,不利な情状証拠となります。 そして,起訴猶予処分となったのは,警察から検察に「罰金刑(略式起訴)か,起訴しないなら嫌疑不十分ではなく起訴猶予処分とする」よう依頼をかけていた,との取材結果があります。 愛知県警の捜査体制は,批判されてしかるべき問題を抱えているといえます。 **裁判所の問題 裁判所は警察の求めに応じ,その必要性を検討したうえで捜査令状や逮捕状を発行します。このとき,嫌疑が不十分である,または嫌疑なしと判断できていれば,捜査令状や逮捕状は発行されなかったはずです。また,そのような判断があれば,警察は捜査内容を見直せたかも知れません。 安易に捜査令状や逮捕状を発行した裁判所は,批判されてしかるべきではないでしょうか。 **検察の問題 検察官にも,愛知県警と同様の問題がありました。しかし,検察官各個人に技術的知見を求めるのは無理があります。ならば,相応の知見を持った第三者の専門家に意見を求めるべきでした。 岡崎市立中央図書館が提示したアクセスログは,見る人が見ればまったく問題のないものであったことが即座にわかるはずのものだったと考えられています。 結果的に librahack氏は[[不起訴処分(起訴猶予処分)>http://librahack.jp/okazaki-library-case/conclusion.html]]となりました。起訴猶予処分を受けた人は,前科ではないものの,前歴として記録されます。これは将来,万が一別件等で起訴に至った場合,不利な情状証拠となります。 検察官は,本来なら嫌疑不十分,または嫌疑なしと判断すべきでした。しかし,県警の求めに応じて,librahack氏を起訴猶予処分としました。これが正しい検察のあり方であるとは言えないでしょう。 **librahack氏の問題 ありません。 ただし,「User-Agentにメールアドレスを埋め込んでクローリングすれば、図書館側から問い合わせが容易だったのでは?」という指摘は存在します。 実際に,RFC 2616 HTTP/1.1の14.22にはメールアドレスを書くFromヘッダが定義されています。 [[日本語訳>http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec14.22]]によれば,「特に、ロボットエージェントは、受信後に問題が起きた場合にロボットを操作している責任者に連絡を取るために、このヘッダを含めるべきである。 」として,クローラはFormタグを実装するべきとされています。 これに対して,趣味で作る程度のクローラに対して厳密に RFC 等に対応する必要はない,そもそもFromヘッダはログに残らない,User-Agentがバラバラでは管理者側の負担が増えるだけなどの[[意見も出ています。>http://d.hatena.ne.jp/mala/]]