アカウント名:
パスワード:
特別なアクセス方法を用いていなければ特段逮捕要件を満たすとは思えないので、このケースではありえないんじゃないでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
善意の通報者 (スコア:1, 興味深い)
通報→不正アクセスで逮捕なんてことにならんのでしょうかね。
Re: (スコア:0)
特別なアクセス方法を用いていなければ特段逮捕要件を満たすとは思えないので、このケースではありえないんじゃないでしょうか。
「定義」の相違 (スコア:1, フレームのもと)
例えばACCS不正アクセス事件では，善意（かなぁ？）の通報者側の有罪が確定してますし．
人は見た目が120%
ACCS事件と比較するのは的外れ (スコア:1)
「善意の通報者」の立場や状況が異なるのに、ACCS事件が出るのは不適切ではないでしょうか？
（１）善意は同じだとしても、「立場」が顧客か非顧客か関わる必然性が異なる
（２）「状況」は、通報者が意図して起こしたものか、偶発的に起こったものか
（３）意図して再現可能なら、「提供者が対応する前に手法を第三者に公開」したか
office氏の事例は、不特定多数が利用可能なフォームだったから、正当な利用が無くても、
立場的には潜在的にサービス受益者だったと言えたかも知れません。
しかし、その手順 [cnet.com]は通常の利用において偶発的に起きる可能性が全く無く、
セミナー当日にもACCSは認識しておらず、office氏はセミナー終了後に報告 [geocities.jp]しました。
「4回の試行で1,184名の個人情報を取得」という数も、「実証の範囲」と見なすには多い量です。
セミナーでインパクトを強めたい、自己顕示欲が働いていたと見なされてもおかしくありません。
さらに、手法がセミナーより広範囲に拡散した事、実際に模倣した人間がいた事も、
公開した場所と手順が正しくなかった事を裏付けるには十分です。
これだけ違いがある以上、今回の事例なら、office氏同様の逮捕要件を満たすはずがありません。
それと、ACCS事件以降では「脆弱性報告の環境」が全く異なっている事も失念してるのでは？
ACCSの事例のような脆弱性発見でも、安全に通報出来るようにIPAの届出窓口 [ipa.go.jp]が出来ていますので、
「手法をサービス提供者の対応前に公開」という誤った手段を取る必要性が全くありません。
当然「修正前に出来るだけ自分で悪用」していては、IPAに届け出ても無意味でしょうけど。
office氏の行為は当時は微妙でしたが、今なら善意の通報者とは見なされない行為になりました。
届出窓口に通報したのに改善されない、その間にも被害が発生しているという状況があって、
義憤にかられてしょうがないなら、反撃されるリスクを負って告発するしか無いでしょう。
けど、そこまで至るケース自体聞きませんし、そういうのは事件として顕在化しているのではないですかね。
まあそれでも、@nifty パレットの事例 [bakera.jp]とかIPAの25回にわたる報告を無視 [bakera.jp]とかあるようです。
そういう場合、発見者がすべき事は、せめて自分が利用中なら退会して、情報の完全な削除を求める事で、
告発しなければならない重大な問題とするかどうかは、反撃されても戦える時間的な暇があるかどうか、
戦っている間にも生活の糧が不自由なく得られるかどうかによってくるのでは無いでしょうか。
補足、顕在化した事例 (スコア:1)
厳密には、報告を受けた所「だけ」は対応していたという事例ではあるのですが、
プログラムのデータアクセス方法に問題があったら、他に同じようなロジックで書いていて、
同じように対策が必要な場所を探す手間を省くという対処療法的な対応をされた場合、
報告者が油断して気がついていたにも関わらず自分の情報が漏洩する事も起きそうですね。
参考：IPAからの指摘を教訓にできなかったアイリスプラザ [bakera.jp]