ソフトウェアの安全性欠陥による損害に対し、開発者を訴えられるようにすべきという議論 143
ストーリー by hylom
訴えたい人は居そうですが 部門より
訴えたい人は居そうですが 部門より
eggy 曰く、
ファーストフード店で食べたハンバーガーにより食中毒を起こした場合、客は店に対して損害賠償訴訟を起こすことができる。だが、ソフトウェアのセキュリティーホールをつかれてマルウェア攻撃による損害を被っても、ユーザーは開発者に対して訴訟を起こすことができない。通常ソフトウェア利用許諾契約書（EULA）には、ソフトウェアの欠陥によって損害が生じてもメーカーが補償しないことを明記した免責条項が含まれる。これに対してケンブリッジ大学のRichard Clayton氏は、避けられるはずの脆弱性によってユーザーに与えてしまった損害に関して、ソフトウェアメーカーは責任を負うべきであると呼びかけている（本家/.、Tech Republic記事）。
しかし、これが実現するのは困難だ。実際に、イギリスでは上院委員会が2007年までにこうした法律を導入するよう提案しており、欧州委員会も2009年に同様の提案を行っているが、未だ実現していない。
マイクロソフトは以前、家が泥棒に入られた被害者は、こじ開けられてしまったドアや窓を製造した会社を訴えるなんてことはないのと同様に、ソフトウェアメーカーは外部侵入による被害で訴えられることはないと論じていた。
じゃあその前に免許制に (スコア:3)
ソフトウェアやコンピュータを使う人は、その前に講習を受けて想定外の利用方法をしない様に教育してから免許を発行したほうがいいね。
ソフトウェアって人間が楽になる為に、その部分の行動をロジック化しなきゃならないんだけど
全ての人が同じように考えて、同じように使わないから問題が起こってしまうんだよね。なら同じ思考の人以外は使わせなければいい。
本来数字を入れるべき場所に攻撃コードを埋め込むとか、車で逆走するような事をすれば減点だよね。
まぁそんなのが無理だからこそ、トライアンドエラーになっちまってるんだと思う。
使う側のモラルの問題を全て製造者側に押し付けてたら包丁も売れなくなるよ。
Re:じゃあその前に免許制に (スコア:2)
> 使う側のモラルの問題を全て製造者側に押し付けてたら包丁も売れなくなるよ。
ソフトウェアの安全性欠陥と使う側のモラルの
問題に関係はない。
Re:じゃあその前に免許制に (スコア:2)
もしライセンス条件に免許が必要となるとJITECとかアビバ、LPIやシルバンあたりが大繁盛ですな。
#そうなる前にMCPやACPくらい取らないとだめか
Re:じゃあその前に免許制に (スコア:1)
せめてファイル／I/Oなどの資源をファイル名／ハンドルの形で直に提示して、
「この資源は使いますがそれ以外は使いません」の形にして、
それを判定するのを躊躇する人間は無能力者として使わせない様にすれば
良いのでは。
やっぱりファイル名を超えて抽象化するのは、やり過ぎですし、それで解らない
という人間は、人類の敵と見なすべきです。
Androidとかも、
・電話帳使います
・インターネット使います
位、細かく言えば良いのに、下手に権限を抽象化wして、わかりやすくw提示する
のでかえって判りづらくしてしまっている。
SELinuxみたいなのは無理でもTomoyoLinux的な、対象はファイル名・ファイルパス
のみなら現実的かと。
暗号化とかも (スコア:2)
昔は64bitでも十分だったけど今は128bitでも内容によっては破られるからね～。
昔は本当に大丈夫でも、技術の進歩とともに大丈夫かどうかは変わってくるからね～。
# かと言ってその契約が嫌なら使わなきゃいいじゃん
# って言うと何も使えなくなっちゃうんだろうしな～
Re:暗号化とかも (スコア:1)
昔は64bitでも十分だったけど今は128bitでも内容によっては破られるからね～。
具体的に教えていただけませんか？ 128bit 鍵の暗号が内容によっては破られるケース。
Re:暗号化とかも (スコア:1)
GPGPUでググれ
破られたという暗号が、どんな暗号化方式かぐらいのヒントが無いと...
自分が GPGPU がらみで知っているのは、去年、SHA-1 のハッシュ値を GPU を使ってブルートフォース解析をしたら、33 日間で 252.5個のハッシュ値を持つレインボーテーブルに相当する解析ができた、という話。 [f-secure.jp]
ハッシュ値のブルートフォースより、暗号鍵のブルートフォースの方が処理が重そうな気がするけど、仮に、１つの鍵を検証する処理と、ハッシュ値の計算処理が同じだとして、252.5の鍵が 33 日間で検証できるとすると、128 bit すべての鍵が検証を終えるのは、
33 日間 × 2128 / 252.5 = 33 × 275.5 日間
先の SHA-1 を解析した GPU より 25.5 = 約 45 倍、高速な物が使えるとすると、
33 日間 × 270 = 38,959,523,483,674,573,012,992 日 = 約 1垓年
かかるんだけどなぁ....。
もし、本当に GPGPU をかき集めて解けるとしたら、「内容によって」じゃなくて、その暗号化方式に、決定的な脆弱性がある、という話になるんだけど、もし、有名どころの暗号化方式でこんな脆弱性があったら、ビッグニュースだなぁ、と。
確かに、WEP-104 のように、鍵生成や鍵管理の問題があって、本来の暗号の強度を発揮できないケースはあると思うけど。
オープンソースなら免責 (スコア:2)
オープンソースや、あるいは個別に利用者にソースコードが開示されていれば
問題点がないかどうか自分で調べることが、勉強さえすれば可能だ、とかいう理屈で免責になる…
という事であれば、どうでしょうね。
社会全体の技術も高まる方向になっていいんじゃないですかね。
Re:オープンソースなら免責 (スコア:1)
既にGPLがあるけど社会全体の技術も高まる方向になんてなってないでしょ。
意識のある人にはよい勉強材料になってるだろうけど、社会全体でみれば無料という扱いでしかない。
線引き (スコア:1)
「避けられるはずの脆弱性」ってのが、きちんと定義できれば、おっしゃることもごもっともなんだけどね。
食中毒は、「避けらるか否かではなく、出してはいけない」だから、
ソフトウェアも「脆弱性の恐れがあったら、出すのが変」が共通理解になれば成り立つだろうけど、
そうなる前に「少々危なくても安く買う」派が台頭するから、今があるんだけどね。
Re:線引き (スコア:1)
食中毒に例えるなら、
未知の対処法が不明な食中毒菌で症状が出た場合どうするかですね。
従来の食中毒に対する対策が十分なら責任は問われないけど、そうでなかったら未知かどうかは関係ない。
要するに「脆弱性」についても対処すべき項目として仕様になければならない。
仕様にない問題は、品質の問題でないなら製造物責任になり得ない。
こんなんでどうでしょ。
Re: (スコア:0)
> 食中毒は、「避けらるか否かではなく、出してはいけない」だから、
はい。悪意の攻撃を防げないという話と、自分自身が害を為すという話は別だと思います。
ただ、ソフトウェアの不具合は、脆弱性（攻撃を防げない）だけではなく、自分自身が害を為す
場合だってありえます。
それを、ソフトウェアの不具合を脆弱性だけに限ってしまうと、MSの言い分をそのまま真に受けて
しまうことになると思います。
Re: (スコア:0)
自分自身が害をなすって、すなわちマルウェアだから、
この議論の結論を待つまでもなく訴えることのできる問題だと思うよ。
Re: (スコア:0)
食中毒と脆弱性を並べちゃうから謎パーになるんですよ。
食堂で出された食事に他の客が毒を仕込むかどうかと脆弱性に対する攻撃ってのならわからんでもない。
根源的な悪意の発生箇所（食中毒は作り手の衛生管理の問題だけどさ）が違うのにトピックでは一緒くたじゃ困るよね。
Re:線引き (スコア:1)
たとえ話は置いておくとしても、
ソフトウェアについては、原因、責任の特定の困難さと、
被害がおおよそ金ばかりで、車のリコールや食中毒のように人体に影響があまりない
ってのが話題だけで終わる原因かな。
Re:線引き (スコア:1)
それじゃあ開発者の健康被害に対して、会社が補償するようにしたらいいんじゃね？
Re: (スコア:0)
全ての事態を想定できるほどソフトウェアは成熟してないって事じゃないかなぁ
食物に例えるなら、未知の食材と謎の調理法だらけで、まだまだ原始的な料理って感じ
この法律が成立した時が見ものだな (スコア:1)
くらっか～ (スコア:1)
合理的に、
「原因がソフトウェアの安全性欠陥に起因すると判定でき」
かつ、
「被害額が算出できる」
なら、当たり前にそうなるよね（走召糸色木亥火暴）
"castigat ridendo mores" "Saxum volutum non obducitur musco"
Re: (スコア:0)
マジレスすると、その二つだけじゃダメで、責任を問う際には普通は故意または過失が要求されるので、
PL法みたいな無過失責任を問おうとする場合は自明ではありませんね。
例がおかしい (スコア:1)
自分が買ったハンバーガーにだれかが毒を仕込んだら、ハンバーガー製造者を訴えられるのか
と言うことだと思う。
Re:例がおかしい (スコア:1)
「ファーストフード店で食べたハンバーガーにより食中毒を起こした場合」で表現できるとしたら、
プログラムにコンピューターウィルスを混ぜて提供した相当かな？
これだったらなんとなく訴訟もありえるかなと思った。
#「避けられるはずの脆弱性によってユーザーに与えてしまった損害」ってのはどう解釈すればいいのやら・・・（英文苦手）
Re: (スコア:0)
製造者にとって予見不可能だったら責任はないんじゃないの？
明らかな脆弱性のある鍵を、それを知りつつ売ったらどうなんだろう？
どくいり きけん たべたら しぬで (スコア:0)
グリコ・森永事件で、「もし誰かが毒入りお菓子を食べたら、グリコ・森永、他各社が訴えられる」という話のような。
お菓子メーカーは被害者であって、加害者ではない。
＃それで開封したら分かるようにと、お菓子は透明のフィルムで包むようになったんだよな。
むしろ品質保証という役目ののひとを (スコア:1)
捕まえて、しょっ引けばいいんだよ。
ソフトウェアは開発者だけが作るものじゃない (スコア:1)
まぁ、タイトルそのままで、要件定義から納品までの間で邪魔するようなユーザーにも、訴え起こして良いんですよね？＞賛同者の皆様
#常日頃、その手のユーザー相手に戦っている開発者なんて、そこらじゅうにいると思うのだが？
フレームワークで対応すべき (スコア:1)
個々の開発者の責任とするのは非現実的です。やるんだったらそういったバグの生じないソフトウェアプラットフォームを用意してその上で開発することでしょう。.NETやJAVAの仮想マシンはそういう考え方に近いですね。
個々の開発者の責任とするとなるとどうなるか?フリーソフトの開発に対するモチベーションを大きく削ぐことになるでしょう。商用ソフトでも、セキュリティ問題ならばセキュアコーディングのコンサルタントを雇う費用が必要になるでしょうし、バグ一般ならばバグが生じにくい開発体制、つまりウォーターフォールモデルを実現するために、多数のドキュメントを作成する工数や、単体テストなどをきっちりと行う工数が必要になりますし、後からの仕様変更は基本禁止、または、それなりの追加費用が必要でしょう。つまり、金もかかりますし、時間もかかります。仕様変更もダメです。つまり、客に対してもそれなりのコストを負担してもらうことになるのですが、これでWin-Winになれるかどうかは怪しいです。
ちょっと魅力かも (スコア:1)
「保険会社のほうから止められているので、仕様の追加は出来ません」
「仕様変更のリスクに対応するためには、この保険にも入っていただかないと
・・・え？ご予算が無い。それは残念です（ニヤニヤ）」
言ってみたい。
ID投稿推奨、マイナスモデ反対、リメンバー・スルー力。
PDSとかだとどうなんだろう？ (スコア:0)
「社会が悪い！」とボヤくんだろうか？
Re: (スコア:0)
ソースを読んで安全を確認しなかった人が悪いんです。安全を確認する方法があるのに、それをしなかったがために被害が出たのであれば、安全を確認しなかった方が悪い。安全は、ただではないんです。
と、いうことで、賠償請求できるプロプライエタリが流行るなんてことはあるのかな？
それとも、ディストリビューターが訴えられたりすることがあるかもしれない。
Re: (スコア:0)
配布元に賠償責任が、なんて話になったらフリーで公開してる人達はみんな引っ込めますな。つーか実際そんな事態になるなら公開してるの引っ込める。
ソフトウェアは他の産業とは仕組みが違う（一品物である、問題が無いことを検証するのは困難）んだから、食品と同じ発想で規制なんてしたらそれこそ産業自体成り立たないでしょ。
なので、こんな広い範囲の規制はちょっとどうかと思う。
＃ こういうの [a-listers.jp]だとどうしてくれんだ(ﾟДﾟ)ｺﾞﾙｧ！と言いたくなるのはそりゃ当然ですがｗ
じゃあ、こっちはライセンスで防衛だな (スコア:0)
イギリス人もしくはイギリスの法律が適用される環境では使うな。
と。
# フリーのソフトがことごとく使えなくなって困る状況は見てみたいな。
Re: (スコア:0)
PDS≠FLOSS。
"NO WARRANTY" っつっても許されない世界?
ビジネスチャンス (スコア:0)
常に訴訟リスクのあるプログラマを対象としたxx社のプログラマ保険！
月々yy円の掛け金で最大zz万円までの保証！
#リアルにそういう時代来たら嫌だな
#でも産婦人科とか､そういうリスキーな医者に対してそういう制度を設けて訴訟から保護しようって議論ありませんでしたっけ？
Re:ビジネスチャンス (スコア:5, 興味深い)
医者は既にあります。ほとんどの医者はだいたい毎年５万円前後は保険金を支払ってるはずです。
27万人×5万円/人/年＝135億円/年が保険会社の定常収益に。
プログラマへの訴訟リスク付加とは、保険会社・弁護士への利益誘導に他なりません。
Re: (スコア:0)
単純に保険付と保険無ソフトを並べて売ればいいんんじゃないか
値段は変わるだろうけど買う側で好きなほう選べばいい
「やらない」 or 「できない」 (スコア:0)
＞ソフトウェアのセキュリティーホールをつかれてマルウェア攻撃による損害を被っても、
＞ユーザーは開発者に対して訴訟を起こすことができない。
よく知らないんだけど、訴訟を起こしてはいけないとかいう法律でもあるん？
Re:「やらない」 or 「できない」 (スコア:2)
普通「訴訟を起こす事ができる」って言う場合は、「責任を問える」という意味で、
要するに「裁判所が損害賠償請求を認めてくれる可能性が高い」という事かと。
Re: (スコア:0)
EULAでできない契約になってるという話だけど、
消費者利益に反する契約は無効になるから、
結局は製造者に責任を問えるかどうか（現在のところソフトだけに起因するよほどの損害がない限り問えない）の問題だと思う。
ドイツはそういうのは無効だったんでは (スコア:0)
ドイツの法律ではソフトウエアのEULAでソフト障害の免責を入れても法律で一部無効になってしまったように記憶してますが。
簡単な解決方法 (スコア:0)
自分の書いたコード ? 自分で何とかする : 文句言うな
Re:ちょっとまって、例がおかしい (スコア:1)
鍵が「世の中に悪い奴が居てそいつらから身を守るツール」として売られているというのは、その商売は「悪い奴ら」の存在を前提としてて、暴論な極論だけど、「そいつらが居る」というのに便乗して商売してることになるわけで。それを、「より悪い奴の方が悪い」というのはちょっと無理がある。
まともな鍵かどうか確認してから買うべきだとか、それを判断するための安全基準があるべきだとか、いろいろ線引きは考えられるけど、まあ、世の情勢に鑑みて落ち着くところに落ち着くような話だと思う。
Re:ちょっとまって、例がおかしい (スコア:1)
＞ 「絶対安全」というキャッチコピー付きで売られてるいかにも頑丈そうな鍵が、ちょっと揺すったら開いちゃった、とかだと訴えたくなる気持ちにもなる。
ソフトウエアで『絶対安全』として売ることは普通はない。
しかもどんな鍵でも理論上壊せない鍵はないわけだし。ソフトウエアもしかり。
そして、いずれにせよそういう場合でも、訴えるならせいぜい詐欺罪であって、PL法やなにかじゃないんじゃねと。
＃この比喩だと問題になるのはセキュリティ関係のソフトだけだな。それ以外は無関係。
Re:ちょっとまって、例がおかしい (スコア:1)
本来、安全を売りに出来て、危険なソフトウェアが売れなくなって市場から自然に消え去る、と言うのが理想ではあるけど、そうなるほどの多様性にはなかなか至らなさそうだし。特にOSとか。
なるべく安全なソフトが流通して欲しいけど、業界の自主的な努力とユーザの選択に任せてたんじゃ十分に進んでない現状があるから、法律とかで無理矢理後ろから叩いた方が良いんじゃね? みたいな主張。
個人的には、まだ慌てるような時間じゃない、っていうかユーザの使い方にも問題が多い、もっと頑張れ、と思ってるけど。
でもって、法律にしちゃえ派が何度も出ては消え去ってる原因としては、「その考えがナンセンスだから」より「MSとかすっごい強い奴ら相手に太刀打ちできないから」の方が大きいんじゃないかと妄想中。
Re:ちょっとまって、例がおかしい (スコア:2)
でも「絶対に欠陥が無く安全なソフトウェア」なんて存在不可能なので、そんなものを作らなきゃ訴えられる世の中になったらIT業界が壊滅しますね。
ケータイ電話もスマートフォンもパソコンも「インターネット」も存在不可能ｗ
ψアレゲな事を真面目にやることこそアレゲだと思う。
Re:ちょっとまって、例がおかしい (スコア:1)
その結果、安全確保に十分なコストを投資する会社が報われるよりよい社会になるのか、今までみたいな楽な商売が出来なくなってIT技術が悲惨な焼け野原になるのかまでは想像が付きませんけど。
Re:ちょっとまって、例がおかしい (スコア:1)
ソフトウェアだけ特別扱いしないと言うなら、悪意を持ってクラックされたことによる被害の責任をソフトウェア製造者へ求めるという今回の話はおかしい
ψアレゲな事を真面目にやることこそアレゲだと思う。
安全性に価値を見いだす人が増えてくれればね (スコア:3, すばらしい洞察)
>ソフトウェア業界が衰退するか、ソフトウェアの値段が跳ね上がる結果になるだけだと思う。
しかし安全性に対する需要があるなら、その分の追加費用を払える人が多いはずなんですけどね。
もし対価を払いたくないというなら、本気で安全性に価値を見いだしてはいないということです。
稟議で偉い人が判子を押してくれるのかどうかという話で。
テスト工程の重要性を認識して貰える良い機会のようにも思えますが、どうでしょうかね。
ソフトウェア関連の稟議を通そうとすると、必ずテスト工程を削れという圧力がかかって困ります。
まぁ、カスタムの開発機なんかもそうなんですけど。
>認証マーク等で、高品質のソフトウェア開発をした人間が報われるようするぐらいの
>ゆるい対策でいいのではないかと思う。
認証マークは金にならないですよね…
Re:やがて (スコア:1)
自動車みたいなパッケージ製品なら、その理屈は通用しますが、ソフトウェアの場合、ユーザーと開発者の双方で作るものなので、その理屈は通じませんな。
パッケージ製品のような作る側だけの努力でどうにかなるものならともかく、そうでないソフトウェアの場合、ユーザー側の努力が期待出来ない以上、衰退するしかないのでは？
Re:やがて (スコア:1)
で、今回の訴えられるようにという話は、パッケージ製品限定の話題なんでしょうか？
スルガ銀行とIBMの間で起きた訴訟騒ぎの例もありますし、そんな脳天気な話題でもないと思うのですが。
「なにかあったときの責任の切り分けもきちんと議論して合意をとって文書で残しておく必要があります」
ええ、同感ですね。ユーザーがきちんと守ってくれればの話ですけどね。
ユーザーはしばしば、事前取り決めも議事録ですらも、「そんな話は聞いていない」とひっくり返す生き物ですよ。
そういう経験を幾度もしてきているので、作る側だけの責任にするのは無茶だと書いているのです（苦笑）