再来週土曜日の以下のシンポジウムで講演とパネル討論に出ます。楽しみです。
開催日時: 平成19年2月17日(土) 10:00-17:00
開催会場: 大阪弁護士会館2階ホール [大阪市北区西天満1-12-5]
主催: 大阪弁護士会 刑事弁護委員会、情報ネットワーク法学会、情報処理学会概要:
昨今の情報処理技術、特にインターネット等の発展により、情報処理技術や著作権法などの特別刑法が複雑に絡みあった刑事事件が数多く起こっております。このような事件の弁護活動には、当然ではありますが情報処理技術に関する素養、関連諸法規の知識、さらには技術や産業の発展といった多角的な見識が必要とされます。
そのような中で、ファイル共有ソフトである「Winny」に関する事件(以下「Winny事件」といいます。)の地裁判決が出ました。この事件に関しても、ファイル共有ソフトという技術に対する認識、海外の判決をはじめとするサイバー法に関する海外の実情などについて、情報処理技術者やサイバー法研究者等が様々な見解を発表しております。
そこで、情報処理学会及び情報ネットワーク法学会との共催により、本会も主催者として、各分野の研究者を招き、共同シンポジウムを開催することにより、新たな分野の刑事事件に関する相互交流をはかり、今後の研究の契機になることを目的として、標記シンポジウムの開催を企画した次第です。
技術的・法的見地から有用な話が提供されると思われます。是非、弁護士に限らず、皆さまのご参加をお待ちしています。
プログラム:
1. 「ファイル共有ソフト概説」
講師: 金子 勇 氏 (プログラマー・Winny開発者)2. 「ファイル共有ソフトを巡る法的問題点」
講師: 指宿 信 氏 (立命館大学法科大学院教授・情報ネットワーク法学会)3. 「ファイル共有ソフトと著作権に関する裁判例」
講師: 岡村 久道 氏 (大阪弁護士会会員・国立情報学研究所客員教授・情報ネットワーク法学会理事)4. 「ファイル共有を巡る技術的問題点」
講師: 高木 浩光 氏 (産業技術総合研究所 情報セキュリティ研究センター主任研究員・情報処理学会会員・情報ネットワーク法学会会員)5. 「IT事件に関する弁護技術上の問題点」
講師: 秋田 真志 氏 (大阪弁護士会・刑事弁護委員会副委員長)6. パネルディスカッション「Winny事件が残したもの」
ソフトウェア製品の脆弱性にせよ、Webサイトの脆弱性にせよ、それについての脆弱性情報(exploit)がどこかで公開されているのを見かけたとしよう。問題の内容からして脆弱性情報受付機関に届け出るべき事態であるにもかかわらず、それが届け出られる様子がなく*1、当該Webサイト運営者への直接の通知も行われている様子がないと思ったとき、それを見た人はどう行動すればよいか。
見た人が届け出ればよい。
「ソフトウエア等脆弱性関連情報取扱基準」の「発見者基準」によれば、
(1)発見者(自ら運営するウェブサイトのウェブアプリケーションについての脆弱性関連情報を発見又は取得したウェブサイト運営者を除く。)は、発見又は取得した脆弱性関連情報を経済産業大臣が別に指定する受付機関に届け出ること。ただし、当該ウェブサイト運営者に対し同じ内容を届け出ることを妨げない。
ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号
と、「発見又は取得した脆弱性関連情報を」と書かれているように、「発見者」というのはなにも、技術的な意味での発見者(つまりいわば「第一発見者」)のことだけを指すわけではなく、誰かが公表してしまっているexploitを単に見かけた(取得した)という意味での発見者(「火災の発見者」のようなもの)も含むのだ。
だから、火災が発生しているけどまだ誰も消防署に連絡してないんじゃないかと思えたときと同様の判断で、脆弱性情報も受付機関に届け出ればよい。
その際、「俺が発明したわけじゃないのに、俺が発見者だなんて名乗り出るのは差し出がましい」などと気後れする必要はない。そうした情報の届出も想定している制度なのだから。
届出様式(ソフトウエア製品)(記入の手引き)にも、「この脆弱性関連情報の入手先」という記入項目があり、
[2. 脆弱性関連情報] の記入について
1) この脆弱性関連情報の入手先
この脆弱性関連情報をどのように入手したかを選択してください。
□ 自分で発見した
届出者の方自身が発見した場合は、こちらを選択してください。
□ 人から入手した
届出者の方自身ではなく、ほかの方が発見した情報を入手したことによる届出である場合は、こちらを選択してください。
□ ウェブサイトから入手した
(URL: )
ウェブサイトなどの一般に公開されている情報である場合は、こちらを選択してください。
とあるように、そうした届出が想定されている。私も実際、2004年7月の「未対策・未発表な多数の国内産脆弱性情報が暴露」の事例のとき、以下のように、公開情報の「発見者」として届出をしたことがある*2。
2004年 7月 28日
1. 届出者情報
1) 届出者情報
(略)
2) 届出者情報の取り扱いについて
(略)
3)対策情報公表時の届出者情報の掲載について
□ 希望する ■ 希望しない
2. 脆弱性関連情報
1) この脆弱性関連情報の入手先
□ 自分で発見した □ 人から入手した
■ ウェブサイトから入手した
(URL: http://www2.sala.or.jp/~uuu/security/ )
2) 脆弱性を確認したソフトウエア等に関する情報
様々なソフトウェア、および各所のWebサイトの未対策の脆弱性の情報が
以下のところで公開されてしまっている。
http://www2.sala.or.jp/~uuu/security/
3) 脆弱性の種類
ブラウザの脆弱性、クロスサイトスクリプティング等
4) 再現手順
公開されているサイトを参照
http://www2.sala.or.jp/~uuu/security/
5) 再現の状況
(略)
6) 脆弱性により発生しうる脅威
cookie盗難によるセッションハイジャック、ローカルファイル流出等
7) 回避策
公開されているサイトを参照
http://www2.sala.or.jp/~uuu/security/
8) 検証コード*
公開されているサイトを参照
http://www2.sala.or.jp/~uuu/security/
9) その他
3. IPA 以外の組織への届出について
□ あり ■ なし
4. 今後の連絡について
1) 対策情報の公表の連絡を希望するか
□ 希望する ■ 希望しない
(略)
5. その他
既に誰かが通報したかもしれませんが、念のため届け出ます。
一方、Webサイトの方の届出様式(記入の手引き)の場合には、「この脆弱性関連情報の入手先」の項目がないが、「脆弱性の発見に至った経緯」のところに書いておけばよいだろう。
ただし、Webサイトの脆弱性の届出においては、その脆弱性の存在を確認する際の行為が法令に違反しないように注意しなければならない。
1.発見者基準
(1)発見者(自ら運営するウェブサイトのウェブアプリケーションについての脆弱性関連情報を発見又は取得したウェブサイト運営者を除く。)は、発見又は取得した脆弱性関連情報を経済産業大臣が別に指定する受付機関に届け出ること。ただし、当該ウェブサイト運営者に対し同じ内容を届け出ることを妨げない。
(2)発見者は、以下の点を明示した上で脆弱性関連情報を届け出ること。
①発見者の氏名、連絡先等の情報及びその取扱い
②脆弱性を有するウェブアプリケーションを稼働しているウェブサイトの名称等
③当該脆弱性関連情報
(3)違法な方法により脆弱性関連情報を発見又は取得しないこと。
(4)発見者は、当該脆弱性が修正されるまでの間、当該脆弱性関連情報を第三者に漏えいしないよう適切に管理すること。ただし、当該脆弱性関連情報を正当な理由により第三者に開示する場合、あらかじめ受付機関に問い合わせをすること。
ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号
付録1 発見者が心得ておくべき法的な論点
1.脆弱性関連情報の発見に際しての法的な問題
(1)関係する行為と法令の関係
a) ネットワークを用いた不正
・例えば、脆弱性関連情報を利用して、アクセス制御機能を回避し、インターネットなどを介してシステムにアクセスした場合には、不正アクセス禁止法に抵触します。
・例えば、管理者の了解無く、他人のパスワードを取得し、それを用いて権限なしでシステムにアクセスした場合には、不正アクセス禁止法に抵触します
・故意にサーバの機能や性能の異常を来たそうとして何らかの行為をなし、コンピュータの性能を低下させたりした場合、刑法上の偽計(もしくは威力)業務妨害罪に抵触する可能性があります。さらに、その妨害の程度によっては、刑法の電子計算機損壊等業務妨害罪にも抵触すると解される可能性があります。
b) 暗号化されている無線通信の復号
・暗号化されている無線通信を傍受し復号する行為(無線LAN のWEPキーの解読など)は、第159 通常国会にて改正された電波法に触れる可能性があります。
(2)不正アクセス禁止法に抵触しないと推察される行為の例
脆弱性の発見に最も関係が深い不正アクセス禁止法に対しては慎重な扱いが求められます。といっても脆弱性を発見する際に、必ずしも不正アクセス禁止法に抵触するとは限りません。以下に、不正アクセス禁止法に抵触しないと推察される行為の例を挙げます。
1) ウェブアプリケーションの利用権者が、正規の手順でログインするなどして通常のアクセスをした際に、ブラウザとサーバとの通信の内容を観察したところ、それだけで脆弱性の存在を推定できた場合。
2) ウェブページのデータ入力欄にHTML のタグを含む文字列を入力したところ、入力した文字列がそのまま表示された。この段階ではアクセス制御機能の制限を回避するに至らなかったが、悪意ある者に別の文字列を入力されれば、このサイトにセキュリティ上の問題が引き起こされかねないと予想できた場合。
3) アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察されるURL 中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。(ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。)
(3)IPA の対応と発見者の法的責任
IPA は、脆弱性関連情報の入手方法に関して関知しません。ただし、違法な手段で入手されたことが明白な脆弱性関連情報に関しては、受け付けないことがあります。
また、IPA が脆弱性関連情報を受け付けた場合でも、IPA は脆弱性関連情報の入手手段に関して合法であると判断したわけではありません。さらに、IPAが脆弱性関連情報を受け付けた場合、発見者の脆弱性関連情報の発見に係る法的責任が免責されるわけではありません。
2.脆弱性関連情報の管理に際しての法的な問題
(略)
以前(この届出制度が始まる前)に新聞に次の通りコメントしたことがあった。技術に詳しくない人にはわからないかもしれないが、脆弱性の種類によって、適法な利用をしただけでそこに脆弱性があると推定*3できるものもあるし、不正アクセス禁止法違反行為をしなければ発見できそうにないものもある。
◆ネットの安全性の問題について詳しい独立行政法人・産業技術総合研究所の高木浩光主任研究員の話
CGIの欠陥の有無を外部から確かめようとすると、欠陥の種類によっては不正アクセス禁止法に触れかねないので、具体的な指摘はほとんどされてこなかった。安全なプログラムを作る基礎知識を持たない開発者がCGIを作る場合も多く、欠陥を抱えたサイトが多数放置されている可能性は高い。
「ネットの脆弱さに警鐘」国立大研究員が個人情報を公表, 朝日新聞, 2004年1月4日
何が適法で何が違法なのかはそう簡単な話ではない。偶然に知ってしまった場合を除くと、Webサイトの脆弱性を適法に発見するというのは、関連法令と当該技術についての相当な知識と理解を必要とするものである。
適法かどうかは自分で判断するしかなく、それが出来ない人は何もしないべきであり、出来る人だけが届け出ればよい。間口が狭いがそれはしかたのないことだ。
公開情報を発見して届け出るのはよいが、その際に脆弱性の存在を確認する行為まですることについては、素人にはお薦め出来ない。
技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。
Webアプリを作ったらセキュリティ屋に脆弱性を指摘された——そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか?
「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの?プログラムの内容からして必要のないことなのに?
そう。必要ありません。「それがセキュリティなのだ」「セキュリティのためには当然」なんてセキュリティ屋に言われたら、その人はもう信用しなくてよいです。
具体的にはこうです。CGIパラメータが「p」という配列変数に入ってくるとしましょう。こんなコードを思い浮かべてください。
p[i] = urlDecode(p[i]) p[i] = charcodeConv(p[i]) p[i] = sanitize(p[i])
URLは「%xx」でエンコードされていますから、まずこれをデコードします。そして文字コードを統一するため文字コード変換します。ここまではミドルウェアが自動的に行う場合もあるでしょう。定型的な処理です。この直後に、「サニタイズ処理」が入っています。これが「入力のサニタイズ」です。
サニタイズ処理の内容はこうです。「クロスサイトスクリプティング」脆弱性を例にすると、この脆弱性では「<」や「>」などの文字が原因となります。そこで、「入力のサニタイズ」によって、「<」の文字を削除してしまうとか、全角文字「<」に変換するとか、「<」に変換するという処理が「サニタイズ」だということになります。
しかし、このような処理は必要ではありません。なぜなら、クロスサイトスクリプティング脆弱性を排除するには、HTML文字列を書き出す部分で、「<」などを「<」などに変換(エスケープ処理)すればよいからです。
ちぽっけなCGIプログラムならどっちでもよいでしょう。数行のプログラムなら、入力の直後で処置するのも、HTML出力の直前で処置するのも同じことです。
x = p[i] //入力 x.escape() //処置 print x //出力
しかし、大規模なプログラムではどうでしょうか。入力から出力までのデータフローは長くて複雑なパス(道のり)を構成します。真ん中あたりで処置するのは最悪です。処置されているかいないかの確認が難しくなるからです。そうすると、入力の直後か出力の直前ということになります。そして、入力の直後がよくないのは以下の理由からです。
入力の時点では何をすればよいのかは明白ではありません。「<」を「<」に変換する必要があるのは、その値がHTML出力で使われるという理由からです。その入力値が、もしSQL文の一部として使われるならば、SQLインジェクション対策をしなくてはなりませんから、「'」の文字を処置しないといけません。SQL文にも使われるしHTML出力にも使われるなら、両方処置しないといけないということになってしまいます。両方処置した値がHTML出力に使われたとき、無駄に「'」がエスケープされて「''」とか「\'」と表示されてしまうという、マヌケなことが起きます。入力直後でサニタイズするというのは、プログラムのロジックとして誤りです。
ではなぜそんなことを言うセキュリティ屋がいるのでしょうか。ひとつには、プログラマでないセキュリティ屋がいるからです。Webアプリの脆弱性検査の一部は、プログラミング能力がなくてもできます。攻撃に使われるパターンを入力に与えて結果を見る。脆弱性についての知識さえあれば、欠陥があるという事実の指摘はできるわけです。
コードレビューによる検査ならば、さすがにいくらかプログラミング経験があるはずです。しかし、洗練されたプログラマとは限りません。コードを追いかけることさえできれば、脆弱性は指摘できます。「洗練されたプログラマ」ならば、「コードをどの位置に書くか」にこだわりを持っているはずです。プログラムの見通しをよくし、メンテナンス性を高めるためにです。そのセンスがあれば、必要なところの直前にエスケープ処理を施すのが正しいことはわかるでしょう。
「入力は一か所だから対策が楽だが、出力するところは無数にあるから対策漏れが起きる。だから入力で処置するべきなのだ」と主張する人がいます。しかし、入力はCGIパラメータだけとは限りません。データベースを検索して得た値も該当します。それが多数あるなら対策漏れが起き得るのは同じことです。
「CGIパラメータの入力直後で全部サニタイズしていれば、データベースにもサニタイズ済みの値が入るはずだから大丈夫だ」という主張は誤りです。「セカンドオーダーSQLインジェクション」という攻撃手法が知られています。そんなことはどうでもよいのです。出力(SQL文を構成するところ)でエスケープするという正しいコーディングをしていれば、セカンドだろうがサードだろうが気にする必要がありません。
洗練されたプログラマでないセキュリティ屋は、「入力の全部にサニタイズが必要」などと言います。処置する場所が出力の直前であっても、「入力からの変数にサニタイズ」などと言います。外部からの入力に依存した値(データフローがつながっている値)について処置せよというのです。そんなことは考える必要がありません。出力で使う値の全部に処置すればよいのです。
たとえば、「<h1>...</h1>」というHTMLを出力するコードで、「...」の部分に変数「title」の値を差し込もうというときに、変数「title」が外部からの入力に依存しているかどうかなんてことは考えず、常に「<」と「>」と「&」のエスケープ処理をするということです。
「外部からの入力に依存していない値については(セキュリティ上問題ないので)エスケープを省略する」という発想は、利益がない(いまどきそんな省略で性能に変化が出ることはない)ばかりか、メンテナンス性を悪くし、脆弱性の原因となります。最初に書いた時点では入力に依存していなかった式が、プログラムの別の場所の変更によって、入力依存になるかもしれないからです。
HTML出力するときに「"」を全部「"」に変換せよと、セキュリティ屋が言うことがありますが、これもちょっと正確ではありません。たとえば、「<a href="...">」という出力をするコードで、「...」部分に式の値を埋め込むときには「"」のエスケープが必要になりますが、それは「"」で囲まれた中に埋め込もうとしているからであって、それ以外の場所で「"」をエスケープすることは必要ではありません。
HTMLは文法を持った言語ですから、「"..."」と引用符で囲まれた中に式の値を差し込むときは、その式に「"」が含まれていればエスケープするのはプログラム上もともと当然であって、セキュリティが理由ではありません。これを怠るとたまたまセキュリティ脆弱性にもなるというだけです。
では、セキュリティ屋たちが「入力をサニタイズ」と言うようになってしまった背景は何でしょうか。
ひとつには、既に組みあがったWebアプリに脆弱性が発覚したときに、応急処置として脆弱性を排除するには、CGIパラメータの入力時点で「サニタイズ」する方法が簡単である(出力の全部を漏れなく直すのには時間がかかる)ため、そのような対策が一時期普及したのが背景にあると考えられます。(しかし、先に述べたように、入力はCGIパラメータだけではありません。)
入力値の検査をするべきだという主張もよく耳にします。電話番号が入るはずのパラメータに対しては、数字とハイフンだけからなることを検査して、合格のときだけ処理を実行するというものです。たしかに、これが結果的に脆弱性対策になる場合もあります。しかし必ずなるとは限りません。これは、アプリケーションが要求している「validation」処理であって、サニタイズとは別の機能だと考えるべきです。
もうひとつはPerlです。20世紀には、CGIといえばPerlという時代がありました。open文にファイル名を渡すときに、コマンドとして起動されてしまうような書き方が広まり、これがOSコマンドインジェクション脆弱性となりました。これを出力時のエスケープ処理で処置するのは簡単ではありません。OSのシェルの記号解釈の文法が複雑だからです。そのため、記号を全部削るという対策が普及しました。英語圏ではこれを「sanitize」と呼ぶようになり、日本にも持ち込まれました。(これも、シェルが起動するようなopenの書き方をすべきではないというのがより的確な対策です。)
私は昨年から、「サニタイズ」という言葉を使うのはもうやめようと主張しています。入力での処置を連想させるからです。すると、出力部分で適切にコーディングすることを指して「それをサニタイズと言うのだと思っていました」と言う人が出てきました。そこまで「サニタイズ」の語義を広げるなら、もはや「サニタイズ」という言葉は、「セキュリティをちゃんとする」という程度の意味しかありません。それなら「サニタイズ」という言葉を使う必要がありません。「セキュリティをちゃんとする」と言えばよいのです。
その一方で、サニタイズという発想がセキュリティ屋たちの思考を蝕んでいる実態があります。なんでも「サニタイズしていないのが原因」と書けば説明できた気になるという症状です。たとえば、JPCERT/CCが公表した「JPCERT/CC REPORT 2006-01-12」という文書には、「Perlのフォーマット文字列処理の脆弱性」として、次の記述があります。
この問題は、Perlで書かれたプログラムを修正し、外部から入力されたフォーマット文字列をそのまま処理しないようにすることで解決します。
これは間違った解決策です。フォーマット文字列はできるだけ定数にしておくべきというのが正しいのですが、JPCERT/CCは、「%」をエスケープせよとでも言い出しそうです。この記事は英語版の記事を翻訳したもので、原文では「外部から入力されたデータをフォーマット文字列に含めない」と書かれていて、正しい解決策を示しているのに、JPCERT/CCでは誤訳になっています。
これを書いたセキュリティ屋は、「入力をそのまま処理しない」と言っておけば対策を示したことになると、もはや癖になっているのでしょう。「サニタイズ」という言葉を「そのまま処理しない」に言い換えただけです。
重要なことは、どんなコーディングが正しいのかをコードの場面ごとに個別に理解し、説明することです。それができない(つまりプログラマでない)セキュリティ屋にとっては、「サニタイズ」は万能で便利な言葉なのでしょうが、プログラマが使う言葉ではありません。
コードの汎用性を常に意識して、仕様に忠実な実装で、メンテナンス性の高いエレガントな記述を実施していれば、本来いくつかの脆弱性*1は生じないはずのものです。セキュリティ屋の言う「セキュリティのためのセキュリティ」に惑わされず、何が本来的に正しい書き方なのかを考えていきたいものです。
詳細は「サニタイズ言うな」で検索して熟知すべし。
*1 転載時註: CSRFなどはこれに含まれない。(参照:「クロスサイトリクエストフォージェリ(CSRF)対策がいまいち進まなかったのはなぜか」)
先週の「日常化するNHKの捏造棒グラフ」で挙げた2つ目のグラフの事例に対して、「増加傾向は本当だからいいじゃないか」というようなことを言う人が何人もいて驚いた。
図5の事例はグラフで省略されていることを明示しているし、割合はともかく増加傾向にあることに嘘はない。
傾向そのものはまぎれもない真実で、それを分かり易く図示しているに過ぎない。前者はともかく後者は波線だって入っている。
サンプル点がたった6個しかないあのデータのたったあれだけのバラつきを見て、「増加傾向はまぎれもない真実」と思ってしまう人がいるというこの現実。
正しいグラフは以下のものだが、これを見て、「これより左(平成9年より前)はどうなっているのだろう?」という疑問を持たないのかね、この人たちは。
海難審判庁ののサイトを見に行ったところ、最新版の海難審判庁パンフレットに「データでみる海難と審判」というページがあり、平成13年〜17年のデータが(正しいグラフで)載っていた。古いパンフレットはないだろうかと、海難審判庁に問い合わせたところ、快く以下のデータを教えてくださった。
795, 783, 798, 817, 837, 826, 809, 833, 762, 792, 795, 794, 849, 834, 715, 760, 732 (平成元年〜17年の裁決件数)
このうち平成14年までをグラフにしてみると図2の通りとなる。
これでも「増加傾向はまぎれもない真実」などと言うのかね。
ちなみに、その後の未来の値がどうなっていたかも示すと図3の通りとなる。
少ないサンプル数のデータから、そのバラつきが有意な変化を示すものなのかどうか、直感的に把握するために棒グラフは適している。その場合、波線省略をしてはいけない。面積や高さの比によって把握するからだ。
「増加傾向はまぎれもない真実」と思った人達は、まさに、波線省略されたNHKの棒グラフ(下の図)を見たからこそ、「増加傾向」を直感的に感じたのじゃないのか。
「波線だって入っている」「読み手のリテラシーで理解するべきものだ」と言うような人たちが、自分自身の直感が狂わされていることに気づかない。
他に、NHKの制作現場の関係者をうかがわせる人(高校講座の情報Aの制作関係者?)からのコメントもあった。
身内がつるし上げられてるので、今日は(も?)こっちも大人げないモードで。
おお、高校講座がはてぶに載る日が来るなんて。
bm自身は地理には直接関わってないけど、ちょっとびっくり。
情報Aもどうぞよろしく。来年度、ほとんど再放送(3年目!)だけど。一つめの地理のグラフは、確かにy軸と下の方の波線を書き忘れている点でまずかったと思う。
といってそのためにちゃんと数字書いてるのに、一番最初にそれを隠して見せて印象づけるのは卑怯だよね。
それで数字つけられたらあれれ?ってなる。挑発に乗ってみる, bmblog, 2007年1月29日
何言ってんの?
高木氏がどんな大きなテレビを見ていいるのかは知らないけれど、大きなテレビで見ている人ばっかりじゃない。10インチのテレビとかPCの1ウインドウで見ている人も沢山いるし、最近は携帯の2インチのディスプレイとかで見ている人もいる。そういう人にそれを高木氏が加工したグラフ見せて意図が伝わるのか?という。それも、静止画ではなく1秒程度、もしくはそれ以下しか映せないから凝視させることもできない。テレビは言いたいことは必要(だとおもう)以上にはっきり見せないといけないのだ。芝居でもドラマでも役者がこっちが恥ずかしくなるくらい大げさな演技をするでしょう?
挑発に乗ってみる, bmblog, 2007年1月29日
その2インチのテレビで1秒しか流れないグラフで、「ちゃんと書いてある数字」を読み取れってか?
テレビではいちいち増えたとか減ったとか言わないと気が済まないのではないか?
場合によるでしょう。増えたとか減ったことが番組の問題意識だったらそういわないと気が済まない、というかそもそも話が成り立たないし、逆に変わってないことを言いたかったら彼のグラフでもいいだろう。
挑発に乗ってみる, bmblog, 2007年1月29日
むちゃくちゃだな。それが「情報A」か。
というか、それ以前の問題がある。先週も「これは悪意を持って印象操作しようとして捏造したわけではないだろう。なぜなら、これはたかが高校講座の地理の資料だからだ」と書いたように、この海難審判を紹介するニュースでも、政治的意図でもって増加を印象付けたかったとは考えにくい。
ここで、グラフを作っている人とグラフを見て評価する人が別々になっているのではないか? という疑惑がわいてくる。つまり、
↓
グラフ制作係: (データの内容を見たり考えたりはせず、)棒の見た目のバランスが最適となるよう、軸の下限を調整して作成する。(あるいは、自動で最適化されるソフトで一発生成する。)
↓
記者(ないしディレクターあるいはアナウンサー): (元データを見たりはせず、)出来上がったグラフを見て、「年間800件前後、やや増加傾向にあります」とコメントする。
↓
そのまま放送される。
という構図だ。
グラフ作成リテラシーの欠如した美術系スタッフが絵を描くようにグラフを作り、それを、これまたグラフ読み取りリテラシーの欠如した記者が評価して発言する。そして誰もチェックしない。その結果、「増加傾向にある」というありもしない「事実」が捏造され放送されていく。
高校地理も海難審判も正直どうでもいい。こうした無意識の捏造が、国政に関わるようなニュースでも行われることが恐ろしい。
それが日常茶飯事になっているというのが私の認識なのだが、先週は証拠を提示できなかった。しかし、Webを検索して探してみたところ、まさにそうした捏造棒グラフを収集する目的に特化したblogが見つかった。
誤ったグラフを審査し、情報発信者に正しいグラフの書き方を、消費者へ正しいグラフの見方をPRする。右側のメニューの「バックナンバー」から過去の記事を閲覧することができます。このブログは、単にグラフの書式や体裁を指摘しているのではありません。(書式は重要な要素ですが)縦軸の省略等により、棒の長さを変化(数値が改ざんされたのと同じ)させ、嘘の情報を消費者に公開しているものを指摘しています。
NHKニュースのグラフも収録されている。代表的なものを列挙するとこうだ。
左端の棒が何万人くらいを示しているか、読み取れるだろうか?
見た目のバランスが最適なサイズ。書道の極意に通じるものがある。
もはやグラフを使う意味がわからない。
先週書いていた「@ヒューマン」の「親の年収に占める学費の割合」のグラフは、結局入手できなかったが、私の記憶によれば次の図のような絵だったと思う。
いったい何を読み取れというのか?
こういうのはサブリミナル手法より重大な問題ではないの? NHKのグラフ制作の現場はどうなっているのか。総務省は調査したほうがよいのでは?
ちなみに、こんなコメントもあった。
変化を調べる目的であれば、波線で省略することは問題ないのでは。(その書き方も学校で習ったような)
折れ線グラフであれば小4で波線省略表記を習う。厳密には、棒グラフでは誤りだろうけど、まぁ非アカデミックでは許容範囲なんじゃねと思う。全国学力調査でも使われたらしいし。http://www.asahi.com/edu/news/TKY200701150220.html
折れ線グラフの話はしていない。棒グラフの話だ。
たしかに、算数で習う棒グラフでも波線省略を教わった。上の朝日新聞の記事「記述式指導、戸惑う教師 研究者らは「良問」と評価」によると、今年40年ぶりに復活するという「全国学力調査」の予備調査問題には、棒グラフの図で、波線省略されたグラフが使われたようだ。
ここで注意したいのは、これはグラフを読み取るリテラシーを測る問題だということだ。
算数の授業においても、波線省略のグラフを扱うのは必要なことで、その理由は、現実にそういうグラフが社会に存在しているから、その読み取り方を教えることが重要なのだろう。(2インチの画面で読み取る練習とか、1秒しか見せてもらえない状況で読み取る練習をするのかどうかは知らないが。)
だが、グラフの書き方を教える際に、波線省略の必要性や無用さについてちゃんと教えられているのだろうか? 「長い部分は波線省略して書くもの」などと、書道のごとく教えられてはいまいか?
前回の日記の内容についてアンケートが実施されていた。
「棒グラフの波線省略は問題があるということを、高木さんが取り上げる以前に知っていましたか?(択一)」という質問で、「知っていた」、「知らなかった」、「そもそも波線省略に問題はない」を選ばせたもの(Q01)。結果の画面でクロス集計もできるようだが、数値でしか見れないようなので、グラフにしてみた(数値は票数)。
性別による差が理系文系による差よりも顕著に出たことは意外だった。ちなみに、男女別の文系理系の比は男性で4:6、女性で7:3となっている。*1
年代別で見ると次のようになる。
また、「社会人になってから棒グラフで波線省略手法を使ったことがありますか?(択一)」という質問で、「使ったことがある」、「使ったことはない」、「社会人ではない」を選ばせたもの(Q02)もあったので、これとQ01との関係もグラフ化してみた。
これらから何が読み取られるだろうか。
これをテレビ業界風の絵にしてみた。
*1 文系理系の他に、美術系とかがあっらよかったかも。
昨日もNHKで典型的な捏造棒グラフが放映されていた。
半減するように見えるが、実際には3分の2になる程度だ。このときアナウンサーは「現在6600万人あまりいる労働力人口なんですがこれが年間20万人あまりのペースで減って行きます。2050年には4400万人にまで減って行きます。」と説明していて、「現在の3分の2になる」という説明はなかった。
「(厚生労働省)」とあるので原典をあたってみたところ、社会保障審議会 第2回人口構造の変化に関する特別部会の資料1-2「人口構造の変化をめぐる論点(補足資料)」の3ページ目が出典らしい。
このように原典では、初等教育で教えられる通り正しく折れ線グラフで示されている。
2年前の日記で、NHKエンタープライズ21の「RoBoCoN公式サイト」で「問い合わせ」という部分をクリックするとジャンプする https:// のページがオレオレ証明書で運用されていることについて書いた。証明書の発行者は「KSI First Server」と書かれていた。しかしこれがファーストサーバ社により発行されたものかは不明だった。 オレオレ証明書で運用されているこの状況は現在も変わっていない。そこで先月、ファーストサーバ社に以下の問い合わせをした。
Webサイトのデジタル証明書についてお尋ねします。 NHKのロボコン公式サイト http://www.official-robocon.com/top.html にある「問い合わせ」のページ https://www.official-robocon.com/FS-APL/FS-Form/form.cgi?Code=roboconmail05 でサーバ証明書の内容を確認しますと、 「発行者: KSI First Server」 と書かれています。 これは御社が発行されました証明書でしょうか? 以上の点、お尋ねします。
これに対し1月9日にファーストサーバ社より回答があった。それによると、これは、同社のレンタルサーバサービス利用者向けに、各種設定画面へのアクセス用として提供されている「プライベートサーバ証明書」だという。
その回答では、「時代背景の変化によりこの証明書に関して問題がございます事は弊社でも認識しておりまして」とあり、発行者の表記や運用規定を改定する準備をしているところとのことだった。
続けて以下の質問をしたが返事はなかった。
なるほど、それはすなわち、今回の事例は、レンタルサーバ利用者(サイト運 営者、この場合はNHK)が設定画面を操作する際に使用するために用意された SSLを、サイト運営者がサイトの一般利用者向けの SSLとして誤って使用して いるという意味でしょうか?
同時にNHKエンタープライズにも問い合わせをしていた。
このサイトのセキュリティの確認方法についてお尋ねします。 この問い合わせページ https://www.official-robocon.com/FS-APL/FS-Form/form.cgi?Code=roboconmail05 のSSLサーバ証明書(デジタル証明書)の内容を確認しますと、 「発行者: KSI First Server」 と書かれています。詳細を見ると E = anthrax@anthrax.ksi.ne.jp CN = KSI First Server OU = KSI Internet Service O = Kubota Systems Inc. L = Osaka S = Osaka C = JP とあります。これは大阪のファーストサーバ株式会社(旧クボタシステムズ)から 発行されたものをご使用になっているということと理解してよいでしょうか? 以上の点、お尋ねします。
すると1月10日に「高専ロボコン事務局」から回答があり、
お問合せフォームにつきましては、エラーメッセージの表示などで 大変ご迷惑をおかけしております。 ロボットコンテスト事務局はロボコン公式ホームページの運営にあたって、 ファーストサーバ株式会社のサービスを利用しています。 現在、正式なデジタル証明書の取得について申請中でございます。 なお、お問合せフォームへの記入内容につきましては、暗号化されて 送信されておりますのでご安心ください。
とのことだった。「暗号化されて送信されておりますのでご安心ください」は、事実に反する誤った説明である。
それから1か月が経過したが、状況に変化はみられない。
さらに検索して探してみると、他にも「KSI First Server」発行のオレオレ証明書で一般向けサービスを提供しているサイトがあるようだ。たとえば以下などがある。
セキュリティ上はまったく問題ありませんので、安心して当店でのショッピングをどうぞごゆっくりとお楽しみ下さいませ。
このサイトもファーストサーバのレンタルサーバを使用しているようだ。
それどころか、ファーストサーバ自身のサービスにおいてもオレオレ証明書(第二種オレオレ証明書、証明書ポリシー及び認証局運用規定無し)が使われているようだ。
自分のところで正式な証明書発行サービスをやっているような会社が、なぜこういうことをするのか理解しかねる。
WEB+DB PRESS誌のVol.37に「携帯サイト開発 実践テクニック 2007」という記事が掲載されているのだが、そこにこんな記述があった。
端末認証
登録が必要なサイトの場合,利用する際にはログインが必要です.ID/パスワードを毎回入力するのでは,携帯の場合では特に面倒です.
そこで携帯ならではの認証方法として,現在の端末では取得が容易にできる端末自体の情報(端末ID)を利用します.
(略)
セッション
PCサイトでセッションを使う場合は,通常セッションIDをCookieに保存しますが,携帯ブラウザではCookieにデータを保存することができません.そこで携帯サイトでCookieを使う場合はURLにセッションIDを埋め込むことになります.
セッションIDをGETで渡す
セッションIDをGETで渡す場合は,PHPの設定ファイルを更新するだけでできます.具体的には(略)
携帯サイトでセッションを使うときの注意点
携帯ブラウザの場合,Cookieを使うことができませんので,セッションを使う際はどうしてもURLにセッションIDが含まれてしまいます.URLにセッションIDが含まれる場合はセキュリティに注意する必要があります.
本人以外がセッション付きのURLにアクセスできないようにしましょう.特に検索サービスにクロールされてしまうと問題は深刻です.個人情報が簡単に検索できてしまいます.
そのため,セッションには必ず端末IDを保存しておいて,特定の端末のみアクセスできるようにしておきましょう.(略)セッションに格納されている端末IDと照合することで,違う端末からのアクセスをチェックすることができます.
携帯サイト開発 実践テクニック 2007, 技術評論社 WEB+DB PRESS Vol.37, pp.126-127
おいおい、それは駄目だろう*1。
なぜ「URLにセッションIDが含まれる場合はセキュリティに注意する必要があり」なのかと言えば、Refererによってリンク先にセッションID入りのURLが流出し、流出先サイトの人にセッションハイジャックされてしまうからだ。
一方、「端末ID」とは、たとえばこのサイト「携帯端末の個体識別情報(uid)取得方法」などに書かれているように、単にHTTPのリクエストヘッダに利用者に固有の固定のID文字列が載せられているだけのものだ。
リンク先のWebサイトには、Refererと共に端末IDもリクエストヘッダとして送信されているわけで、セッションID入りURLと端末IDがセットで流出するのだから、当然、同じHTTPリクエストを送るだけの方法でなりすましアクセスされてしまう。
そもそも、「ID/パスワードを毎回入力するのでは携帯の場合では特に面倒です」などといって、端末IDをパスワード代わりにしてはいけない。端末IDは他のサイトにも同じものが送信されるのだから、パスワード代わりになどならない。
こんな基本的なことが携帯業界では未だ常識になっていないようで困ったことだ。
携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。
携帯電話の世界は通信事業者の私的なネットワークだと見なせば、秘密主義によるセキュリティ確保という選択も、事業者の自由だと言われればまあそうなのだろう。だが、その場合は、セキュリティ事故について通信事業者が責任を負うことになるのではないか。
逆に責任を負うつもりがないのであれば、セキュリティを確保するのに必要な情報を通信事業者が公式情報として明確に公表しておくか、さもなくば、それらの情報が秘密保持契約における秘密に当たらないことを契約者に対して明らかにするべきだろう。
*1 キャリアのIPアドレスからのアクセスであることの確認の話は書かれていない。(IPアドレスを確認すればそれで本当になりすまし不可能にできるのかは知らない。それは携帯電話事業者が公式に示すべきことだ。)
一昨年4月23日の日記からリンクしていた、BUGTRAQ-JPの記事「au携帯電話のバーコードリーダでジャンプ先URLが偽装される」が文字化けして読めない状態になっている*1ので、以下にHTML化して再掲しておく。
Date: Fri, 15 Apr 2005 05:17:16 +0900
From: Hiromitsu Takagi <略>@takagi-hiromitsu.jp
To: bugtraq-jp@securityfocus.com
Subject: au携帯電話のバーコードリーダでジャンプ先URLが偽装される
以下は、JVN#9ADCBB12の事例について、ユーザおよび開発者が知っておくべきと考えることがらについて、発見者の立場からその発見内容および考察を公表するものである。
au携帯電話の「バーコードリーダ」機能でQRコードを読み取り、そこに含まれるURLにEZwebでアクセスする際、特定のQRコードを読み取ると、画面上で選択したのとは異なるURLにジャンプしてしまう。この挙動は、リアル世界で配布される悪意あるQRコードによって、バーチャル世界で偽サイトに誘われてしまうという、いわば「ユビキタスフィッシング」の危険性をもたらしている。
この挙動が生じないよう修正された「バーコードリーダ」BREWアプリの新バージョンがKDDIより提供されているので、ユーザは最新版をダウンロードすることでこの問題を解決できる。また、ダウンロードしない場合でも、以下に述べるとおり、この問題の原因を知って使い方に注意することで被害を回避できる。
2005年2月3日 IPA脆弱性情報届出窓口に届け出た。
2005年4月14日 JVNにて公表された。
4月14日付の「auからのお知らせ」に、該当機種が記されている。
「バーコードリーダ」BREWアプリの該当バージョンは不明であるが、少なくとも、発見者は「BARCODE READER MEDIASEEK/KDDI Version 2.0.5h」と表示されるバージョンにおいてこの現象を確認し、また、現時点で最新版の「BARCODE READER MEDIASEEK/KDDI Version 3.0.1a」と表示されるものについて、この現象が起きないことを確認した。
以下の1行の内容をQRコードとして作成すると図1の画像が得られる。
MEBKM:TITLE:http://www.au.kddi.com/;URL:http://i.nttdocomo.co.jp/;;
このQRコードを当該BREWアプリ「バーコードリーダー」で読取ると、携帯電話は図2の画面となる。
ジャンプ先として表示されている1つ目のものが「http://www.au.kddi.com/」となっていることを確認しつつ、「選択」ボタンを押す。すると、メニューが現れる(図3)。
ここで「URLを参照する」を選択すると、「URLへ接続します。よろしいですか?」という確認画面が現れる(図4)。
「はい」ボタンを押すと、www.au.kddi.com ではなく i.nttdocomo.co.jp へジャンプしてしまう。
一般に、携帯電話のWebブラウザにはアドレスバーがない。一部の携帯電話会社のブラウザでは、メニューからURLを確認できるようになっているものもあるが、アドレスバーがないため、携帯電話のユーザは、今見ているページがどこのドメインのサイトであるかを普段意識せずに使うのが通例となっている。特に、auのブラウザでは、メニューにも現在のURLを確認する機能が用意されていない。
現在の画面のアドレスを確認できない(確認しにくい)ことは、フィッシング詐欺など、偽サイトに騙されやすくなる危険性をもたらしかねないところであるが、携帯電話では一般的に、メールはテキストメールである(HTMLメール機能がない)ため、メールで誘われたジャンプ先はテキストとしてURLがはっきりと見えるようになっているうえ、さらに、メールからWebサイトへのアクセスが発生する直前の段階で、ジャンプ先URLを表示させて、本当にここへアクセスしてよいかを確認する機能が搭載されているのが通例である。
このように、携帯電話のWebブラウザでは、ジャンプ前にジャンプ先のサイトのドメイン名を確認するという使い方をユーザに習慣付けることによって、偽サイトへの誘導を防止しているのが現状であると言える。
しかしながら、「バーコードリーダ」の当該バージョンでは、図4 のように、ジャンプ前の確認ステップは存在するものの、本当のジャンプ先URLが表示されない。
また、図2 に示したように、QRコードを読取った直後の画面では、リンク先があたかも http://www.au.kddi.com/ であるかのように表示されているが、この部分の本当のジャンプ先は http://i.nttdocomo.co.jp/ となっている。このような現象が起きる原因は次の通りである。
今回使用したQRコードのデータは、
MEBKM:TITLE:http://www.au.kddi.com/;URL:http://i.nttdocomo.co.jp/;;であるが、これは、NTTドコモの携帯電話用の書式にしたがって書いたものであり、冒頭の「MEBKM:」は「ブックマーク登録機能」を指す。
「TITLE:」以降に記述する部分は表題であり、「URL:」以降がジャンプ先のURLである。これをNTTドコモの携帯電話で読取ったときの表示を図5に示すが、このように、「TITLE:」で指定した部分はリンクとしてではなく、そのままテキストとして表示されるのが本来の挙動である。
auの携帯電話のバーコード機能の仕様には、この「MEBKM:」の書式は存在しないが、当該ソフトウェア「BARCODE READER MEDIASEEK/KDDI Version 2.0.5h」は、NTTドコモ仕様の「MEBKM:」も解釈するように作られている。
通常の使用においては、読み取り結果の画面は図6のようになる。これは、「TITLE:」欄にURLでないテキスト「au by KDDI」を記入したQRコードを読取ったときの画面である。タイトル部分がリンクとなり、ジャンプ先は「URL:」欄に指定したURLとなっている。
しかしながら、タイトル部分がURL形式である場合においても同様に動作してしまうため、図2 のように、あたかも www.au.kddi.com へのリンクであるかのように誤認させる形で、i.nttdocomo.co.jp へのリンクを表示させることができてしまう。これは、PC用のHTMLメールで昨今横行しているフィッシング詐欺の手口と同じ仕組みである。
またこのとき、図2のように、画面には偽のジャンプ先と、本物のジャンプ先の2つが並んで表示されることになるが、この表示は、「MEBKM:」機能を使用せずに、単に2つのURLが記載されているQRコードの場合と違わない表示形式であるため、「MEBKM:」により偽装されているのか、通常の2つのURLなのか、区別がつかない。
したがって、ユーザがジャンプ先を誤認したままアクセスを許可してしまうおそれがある。
こうした挙動の事実を知っていれば、図2の段階で、2つのURLが表示されているときには、2つ目のURLが怪しいアドレスでないかを目視確認することで、そのQRコードがジャンプ先偽装を企んだものではないかと疑うことができる。
また、図3の段階で、「URLを参照する」ではなく「アドレス帳に登録する」を選択し、一旦アドレス帳に登録したうえで、アドレス帳からURLにジャンプするようにすれば、アドレス帳では本物のURLを目視確認できる。
4月14日にリリースされた最新バージョンでは、図2の部分が図7のように表示されるようになった。
つまり、NTTドコモの書式に非対応となった。これにより、TITLE:欄に記述されたURLは、単独のURLとして解釈されることとなり、http://www.au.kddi.com/ として表示されるリンクのジャンプ先は http://www.au.kddi.com/ となるように改善された。
また、http://www.au.kddi.com/news/information/au_info_20050414.html に記されているように、ジャンプ直前の接続確認画面に、ジャンプ先のURLが表示されるように改善された。
今後、本格的なユビキタス社会が到来すれば、チラシ広告や街角のポスターなどに記載されたQRコードから、携帯電話で目的のWebサイトへアクセスするといったことが日常化してくると考えられる。
このとき、銀行や著名なネットショップへのジャンプ用のQRコードを読み取ったつもりが、フィッシング詐欺用の偽サイトへと誘導されてしまうといった事態が起きかねない。本物のポスターに偽サイトのURLを記したQRコードのシールを貼られて誘導されるという恐れもあるので、QRコード画像が掲載された媒体の物理的な真偽を見極めるという対処は現実的でない。
携帯電話ユーザの自衛策は、PCの場合と同様に、ジャンプ先のURLが信頼できるドメインのサイトになっているかを確認することに尽きる。
しかしながら携帯電話にはアドレスバーが存在せず、ジャンプ後ではなく、ジャンプ前にURLを確認せざるを得ない。当該「バーコードリーダ」のこの挙動は、ジャンプ前のURL確認を誤認させるものであるため、ユーザがそのまま偽サイトにパスワード等の重要情報を入力してしまうおそれがあった。
根本的な問題解決のためには、携帯電話のWebブラウザにアドレスバーを設けるべきである。それが当面実現しないのであれば、それまでの間は、外部からの入力によって指定されるURLにジャンプする機能を持つソフトウェアを作成する際には、必ず、ジャンプ前にジャンプ先のURLを表示して、ユーザに確認を求めるよう設計する必要がある。
auからの発表文「バーコード (2次元コード) リーダーご利用にあたっての注意点」では、なぜこの事象に注意しなくてはならないのかが説明されておらず、悪意ある第三者からの攻撃に対して弱いという性質を持つ問題点であることがユーザにわかりにくくなっている。QRコードを介したフィッシング詐欺のおそれがあることは、ユーザに伝える必要があると考える。
こうした種類の脆弱性は現時点では珍しいものであるため、こうした設計や実装がこのような懸念を生じさせるものであることを、開発者に広く知らせることで、類似の脆弱性が今後再び生じないよう促す意義は大きいと考える。
この脆弱性が悪用されるには複数のプロセスを踏む必要があり、また、利用者による能動的な操作が必要となるものであるので、現時点で直ちに攻撃の現実性が高いものではないと考える。また、ユーザの現実的な回避策も存在する。脆弱性を公表することによって生ずるリスクよりも、事実を公表することによって将来の安全を確保する長期的なメリットの方が上回ると判断する。
以上
--
高木 浩光@自宅
*1 メーリングリストBUGTRAQ-JPは2006年3月に終了している。
またもや悲惨なプライバシー漏洩事故が起きてしまった。
山梨県警甲府署勤務の男性巡査の私物パソコンから、ファイル交換ソフト「Winny(ウィニー)」を通じて500人以上の犯罪被害者らの個人情報を含む捜査資料がインターネット上に流出していた問題で、流出した資料に婦女暴行事件の女性被害者の名前や住所などが含まれていたことが24日、わかった。(略)
県警によると、この巡査は20歳代で、報告書などを作成する際の参考にしようと、前任の長坂署勤務時代の先輩警察官から入手し、私物のパソコンに保存していた。県警の事情聴取に対し、「学生時代からウィニーを使っていた」と話している。
警察からの機密漏洩はこれで発生時期として4度目、件数として6回目になる。
昨年の岡山県警のケースでは、巡査長がWinnyでダウンロードしていたファイルが「漫画や音楽やそのほかいろいろ」であることまで判明したにもかかわらず、「他人への譲渡などはなかった」という理由で、巡査長の著作権法違反容疑での立件をしなかった(読売新聞報道より)という経緯がある。
◆県警「譲渡ない」
(略)巡査長を減給処分とした9日の会見で、柴山克彦警務部長は改めて県民に向けて謝罪し、セキュリティー対策の徹底を約束した。一方、巡査長の個人パソコンには不正にダウンロードした数種類のファイルが残っていたこともわかったが、県警は他人への譲渡などはなかったとして、著作権法違反での立件を見送ることを決めた。
(略)会見では、巡査長が2004年夏ごろから個人パソコンでウィニーの使用を開始し、流出したのは今年2月26日だったことも明らかにされたが、どのようなファイルをダウンロードしていたかについては「漫画や音楽やそのほかいろいろ。プライバシー情報にあたるので公表は差し控えたい」と答えるにとどめた。
県警は、再発防止策として、全職員約4300人にファイル交換ソフトを使用しないことなどを記した誓約書を提出させたほか、業務使用を認めた約230台の個人パソコンを全廃し、公用パソコンを配備。外部記録媒体に捜査情報などを保存する際、文書の内容を自動的に暗号化するソフトを導入した。(略)
Winnyで音楽ファイルをダウンロードしても著作権法違反にならないのかについては、まず次を見てみる。
【論点】 PtoP ファイル交換ソフトを用いて、音楽などのファイルを無断でインターネット上へアップロードする行為やインターネット上からダウンロードする行為は著作権法違反となるか。また、PtoP ファイル交換サービスを提供する行為はどうか。(略)
(1) 問題の所在
近年、ナップスターやグヌーテラと呼ばれるインターネット上でのユーザー同士による音楽等のファイルの交換を支援するソフトウェア(以下「PtoP ファイル交換ソフト」という。)が出現し、著作権者及び著作隣接権者の利益が損なわれるおそれが生じてきている。(略)
(2) ユーザーの行為
①アップロード行為
(略)したがって、故意又は過失によって権利者の許諾を得ずにPtoPファイル交換ソフトを用いて音楽等のファイルをインターネット上で送信可能にした者は、複製権(同法第21条、第91条第1項、第96条、第98条、第100条の2)又は公衆送信権若しくは送信可能化権(同法第23条、第92条の2 、第96条の2、第99条の2、第100条の4)を侵害しており、損害賠償責任を負うと解される(民法第709 条)。また、故意過失の有無に関わらず権利侵害があった場合又は侵害のおそれがある場合には権利者から差止請求を受けることもあり(著作権法第112 条)、さらに、刑事責任として3年以下の懲役又は300 万円以下の罰金を課されることがある(同法第119 条)。
②ダウンロード行為
他方、PtoPファイル交換ソフトを用いて権利者によって許諾されていない音楽等のファイルを他のユーザーからインターネット経由で受信し複製する行為(ダウンロード行為)は、技術的保護手段の回避等によって行ったものではなく、かつ個人的に又は家庭内その他これに準ずる限られた範囲内において使用する限り、私的複製に相当し、著作権又は著作隣接権の侵害には当たらないものと解される(同法第30条第1項、第102条第1項)。
ただし、受信した複製物を私的使用の目的以外に使用する場合は複製権(同法第21条、第91条第1項、第96条、第98条、第100条の2)の侵害となり(同法第49条第1項第1号、第102 条第4項第1号)、損害賠償責任(民法第709条)、権利者からの差止請求(著作権法第112 条)、刑事責任(同法第119条)の問題が生じる可能性がある。
なお、例えば、ユーザーがダウンロードしたファイルをそのまま自己のパソコンの公衆送信用記録領域に記録し、インターネット上で送信可能な状態にした(ダウンロード行為が同時にアップロード行為に相当する)場合は、当該ダウンロード行為は私的複製には相当しないため複製権侵害に該当すると解される。
Winnyは、ダウンロードしたファイルは、それと同時に、他の者からの求めに応じて送信する「自動公衆送信」が可能な状態にされる(送信可能化される)仕組みになっている(そのこと自体はBitTorrentでも同様である)のだが、他のP2Pファイル交換ソフトに比べて、その仕組みをユーザが自覚しにくいように作られている。
ユーザが知っていようが知らずにいようが、送信可能化されていることは事実であるので、差止請求を受けることがあるだろうし、損害賠償責任を負うこともあるのだろう。しかし、ユーザがその仕組みを知らなかった場合は、故意による送信可能化と認められずに刑事罰を免れるものなのかもしれない。
岡山県警倉敷署の巡査長がWinnyで音楽ファイルをダウンロードしながら著作権法違反で検挙されなかったのは、それが同時に公衆送信可能化となるものだという認識を巡査長が持っていなかったことが捜査で明らかになったからなのかもしれない。
昨年6月の読売新聞報道にあった「他人への譲渡などはなかったとして」という表現はなかなか微妙なものだ。送信可能化はあったのに譲渡はなかったという。「譲渡」という言葉が故意によるものを指すというつもりなのだろうか?
この報道のせいで「Winnyによるダウンロードは合法」と誤って理解が広がってしまっているのだとすれば、それは岡山県警の会見発言が不用意なものだったせいだと言える。「ダウンロードが同時にアップロードになるという認識が巡査長にはなかったため」と岡山県警は発表するべきだった。
さて、今回の山梨県警の巡査はどうだろうか。これだけWinnyに関する報道や情報が多い中、この期に及んで、「学生時代からウィニーを使っていた」というのに、「ダウンロードすると公衆送信可能化される仕組みだとは知りませんでした」などと白を切ることができるのだろうか?
もちろん、本当に嘘偽りなく今回の巡査にもその認識がなかったのであれば、罰するわけにもいかないし、その著作権侵害が親告罪に該当する部分であるなら、著作権者からの告訴がなければ立件できない*1のだろう。
だがいずれにせよ、少なくとも、今回の事態への対応として山梨県警は次の措置をとることはできるはずだ。*2
昨年3月には警察庁が、私物のPCについてもWinnyの使用を禁止する通達をしている。
警察庁は7日、全国の警察本部に対して、公務だけでなく私物のPCについてもP2Pソフト「Winny」の使用を禁止する緊急対策を通達した。岡山県警や愛媛県警でWinnyによる捜査資料の流出が相次いだことを受け、情報セキュリティ対策の徹底を図る。
おそらくこのときは、禁止する理由として挙げられたのは、情報漏洩リスクを軽減するためというものだったのだろう。その程度の理由ではやめない警察官が全国に何十人か何百人かいて、今回その一人が漏らしてしまったということだろう。今回の報道でも、次のようにある。
ウィニーをめぐっては、岡山や愛媛など全国の警察で資料流出が相次ぎ、県警では昨年3月、こうしたファイル交換ソフトを使用しないという内容の誓約書を全職員から提出させていた。一度ネットに流出した情報は、次々にコピーされて広まるため、削除することは実質的に不可能といわれている。
県警幹部は「あれほど全国で騒がれ、本人も誓約書を出しているはずなのに、まだウィニーを使っていた職員がいたとは信じられない」と憤った。
この機会に、「Winnyでのダウンロード行為が著作権法違反や猥褻物陳列となる」という見解を警察庁なり、山梨県警なりが示すべきだ。知っていれば故意になるのだから、知らせるべきである。
もっとも、一般市民向けの一般論として「Winnyでのダウンロードは著作権侵害ですか? 猥褻物陳列ですか?」と尋ねられれば、「場合により判断される」としか答えようがないというのはわかる。だが、警察職員向けの注意警告として禁止する理由でそう説明することは問題なくできるはずではないか。「著作権侵害又は猥褻物陳列に当たる可能性があるので使用してはならない」と。
さらに、そのように職員に指導したという事実を公表することにも問題がないはずだ。昨年あれだけ問題になって周知されたにもかかわらずそれでもなお同じ事故が再び起きたのでは、今後も延々と同じことが繰り返されると思われてしまうのだから、ここで、新しい手を打ったことを国民に知らせなければ、山梨県警、警察組織全体の信用が回復しないのではないか。
昨年の岡山県警の対応が適切だったならば、今回の山梨県警の事件は防止できたかもしれない。山梨県警が岡山県警と同じ過ちを繰り返すのかが注目だ。
ところで話は変わるが、Winny作者の著作権法違反幇助事件の一審判決の判決文(判決要旨)に次の記述がある。
4 〓〓の正犯性
(1) 弁護人らは(略)〓〓方にあったパソコンのアップフォルダには本件ゲームデータファイルが存在しなかったこと,京都府警による(略)ダウンロード実験でダウンロードしたファイルは,同じキャッシュを有する別のパソコンを〓〓のパソコンが中継したに過ぎない可能性があることなどから〓〓は著作権法違反の正犯が成立しない旨主張する。
(2) そこでこの点について検討するに(略)Winnyには前記のとおり,ファイル転送に関して中継機能が存在するが,Winnyのファイル転送は原則として直接なされるというのであり,中継が発生するのは4パーセント程度と例外的であることや,〓〓は捜索差押さえを受ける(略)近い時期にパソコンの不安定さからOSを再インストールしたことがあると述べており(略)以降に〓〓のパソコンの設定に大きな変更が生じ,その際に当該ゲームデータファイルが削除された可能性が十分に認められることなどを合わせて考慮すれば,京都府警によるダウンロード実験によって本件ゲームデータファイルがダウンロードされた以上,〓〓がその時点において本件ゲームデータファイルを故意に公衆送信可能な状態に置いていたものと認められ〓〓には著作権法違反の正犯が成立する。
5 〓〓の正犯性
(中略)
さらに〓〓の正犯性で述べたとおり,Winnyにおいて中継が発生するのは例外的な場合であることなどを総合的に考慮すれば,京都府警によるダウンロード実験によって本件映画データファイルがダウンロードされた以上,〓〓がその時点において本件映画データファイルを故意に公衆送信可能な状態に置いていたものと認められ,〓〓にも著作権法違反の正犯が成立する。
京都地裁平成16年(わ)第726号著作権法違反幇助事件 判決
中継だった可能性があっても4パーセント程度だと(他の状況と総合して)「故意に公衆送信可能な状態に置いていたもの」と見なされてしまうという、なんだかすごい判決になっている。
*1 その意味で、昨年の岡山県警の事件で、県警が「漫画や音楽やそのほかいろいろ。プライバシー情報にあたるので公表は差し控えたい」としたのは酷い話だ。何が送信可能化されていたのかが公表されなければ、著作権者が告訴できない。
*2 このようにするべきである旨、24日に山梨県警に電話して、担当の方に意見として伝えた。その際、担当の方と少し話した。電話の冒頭で「巡査はWinnyを何に使っていたのでしょうか?著作権侵害などの違法行為があったのでは?」と尋ねたときには、「現在調査しているところで、Winny利用の違法性については判断できない」との模範回答だったので、「あなた個人として、もし仮に、内規で禁止されているでしょうけども、もし仮にWinnyを使うとしたときに、音楽ファイルをダウンロードする行為は違法行為になると思いますか?」ということを聞いたところ、わからない様子だった。使うつもりがないなら知らないということはあるのかもしれないが、そういう人達にこそ、Winnyでのダウンロードが同時にアップロードになる、そして違法行為になるという知識を周知することが重要ではないか。少なくとも警察官なら必須の知識であってしかるべきだ。