facebook twitter hatena line google mixi email
★お気に入り追加


  • 1
  •  
  • 2012/06/29(金) 12:52:53.57
ファーストサーバ被害者の会
http://toro.2ch.net/test/read.cgi/hosting/1340506326/

ここまで見た
  • 94
  •  
  • 2012/06/30(土) 00:50:20.90
>>90
第三者調査委員会を設置し、調査開始( 6/28〜)
・ 中間レポートの提出(〜 7 月中旬)
弁護士の知恵かりるんだろうな

ここまで見た
  • 95
  •  
  • 2012/06/30(土) 00:50:23.63
まさか東証終わってから情報漏えい発表?

ここまで見た
  • 96
  •  
  • 2012/06/30(土) 00:51:51.97
情報漏えい騒ぎが広がったら、また余計な業務増える所も出てくるな

ここまで見た
  • 97
  •  
  • 2012/06/30(土) 00:52:04.68
>>94
FSだけじゃなんも出来ないの見え見えw

ここまで見た
  • 98
  •  
  • 2012/06/30(土) 00:59:31.84
情報漏えいについても、日経突っ込んでくれんかなー

ここまで見た
  • 99
  •  
  • 2012/06/30(土) 01:01:43.14
すぐひっこめたんだから
セーフだろ

ここまで見た
  • 100
  •  
  • 2012/06/30(土) 01:07:37.85
http://internet.watch.impress.co.jp/docs/news/20120629_543805.html
「復元ファイルの削除を依頼していくという。」
ダメだね

ここまで見た
  • 101
  •  
  • 2012/06/30(土) 01:08:22.94
>>100
なにが?

ここまで見た
  • 102
  •  
  • 2012/06/30(土) 01:08:56.56
>復元ファイルの削除を依頼するとしている。
削除する義務はあるの?

ここまで見た
  • 103
  •  
  • 2012/06/30(土) 01:09:41.08
>>99


1.5日も公開してて すぐ?????
こんだけ時間あれば・・・ローカルへのバックアップは余裕だよね


データ消失の後、データ復旧作業を実施。
6月21日(木)9時ごろにデータの復旧プログラムにより消失データを復旧し、
リカバードファイルとしてお客様に提供しました。
しかしながら、専用サーバーのお客様より、
専用サーバー内において情報にアクセス権限を有していなかった者からも
参照できる状態になっているとの報告があったため、
リカバードファイルの提供を22日(金)21時ごろ停止し、
状況の確認を行ったところ、専用サーバー内において、
アクセス権限を有していなかった情報についても参照が可能な状態にあったことが判明しました。
上記、問題の発覚を受け、共有サーバーにおいても、
リカバードファイルの提供を即時停止し、現在状況の確認を行っております。

ここまで見た
  • 104
  •  
  • 2012/06/30(土) 01:10:46.41
復元ファイルに他契約者の情報が含まれていた=情報漏洩
impressの記事を読めばわかる

ここまで見た
  • 105
  •  
  • 2012/06/30(土) 01:10:55.60
>>102
なんのために、削除しないの?

ここまで見た
  • 106
  •  
  • 2012/06/30(土) 01:12:05.10
>>102
火事場泥棒みたいな思考だな

ここまで見た
  • 107
  •  
  • 2012/06/30(土) 01:12:35.86
>>105
自分のところのデータかもしれないじゃん
だから削除した奴は、データを消失させた責任もまた負うことになるかもしれん

ここまで見た
  • 108
  •  
  • 2012/06/30(土) 01:13:46.52
>>104
impressの記事を読まなくても
最初の段階で復旧データを停止した時点で想像はつく。

データを削除しても、復活が可能ってことを知っていれば
復活不可能といった時点で、どの顧客のデータか
わかんなくなったんだなって気づくだろう。


ここまで見た
  • 109
  •  
  • 2012/06/30(土) 01:14:32.10
>>107
じゃあ、あなたのデータでないものは削除してくださいって
いえばいいってだけかい?

ここまで見た
  • 110
  •  
  • 2012/06/30(土) 01:15:17.86
>>109
どうやって判別すんの?
100%確実に判別できるの?
できないんだったら削除なんて出来るわけがない

ここまで見た
  • 111
  •  
  • 2012/06/30(土) 01:16:51.16
ローカルにバックアップしたデータは顧客のもの!
削除する必要なんかない!
約款にでも書いてあったか?


ここまで見た
  • 112
  •  
  • 2012/06/30(土) 01:17:01.14
ファーストサーバは
顧客に対して、顧客のデータかもしれないものを削除しろとお願いしてる
おかしな話だ

ここまで見た
  • 113
  •  
  • 2012/06/30(土) 01:18:19.42
>>110
99%は正常で自分のデータかもしれない…でも1%は違うかも…断言できないっ!

なんてデータ抱えててもどうしようもねーだろw

ここまで見た
  • 114
  •  
  • 2012/06/30(土) 01:19:12.51
この先どうなるかわから無いし、裁判って証拠必要だろ?
問題が全部円満解決したら消しても良いけど

ここまで見た
  • 115
  •  
  • 2012/06/30(土) 01:22:41.14
>>110
> 100%確実に判別できるの?

だから、そんなデータを何に使うつもりって
聞いてるんだよw

ここまで見た
  • 116
  •  
  • 2012/06/30(土) 01:23:04.26
>>113
で、それがその会社が抱える顧客のデータで
その顧客から問い合わせ来たらどうすんの?
そんな顧客知らないと突っぱねるの?
なんでそんなリスク負わなきゃいけないの?

ここまで見た
  • 117
  •  
  • 2012/06/30(土) 01:23:41.94
>>115
どうするも何も、抱えてる顧客のデータだったらどうするんだよ

ここまで見た
  • 118
  •  
  • 2012/06/30(土) 01:24:17.31
>>116
どうやって顧客だって判別すんの?
100%確実に判別できるの?


ここまで見た
  • 119
  •  
  • 2012/06/30(土) 01:25:30.94
バックアップ取れと言ったり、削除しろと言ったり面白い会社ではある

ここまで見た
  • 120
  •  
  • 2012/06/30(土) 01:25:49.87
>>118
顧客から問い合わせあれば、判明する場合もあるだろ
なんでそんな大事かもしれないデータを削除しなきゃいけないんだよ

ここまで見た
  • 121
  •  
  • 2012/06/30(土) 01:26:09.16
一度流出した情報は元には戻らないよjk

ここまで見た
  • 122
  •  
  • 2012/06/30(土) 01:26:24.61
つまり、バックアップとってから削除しろってことだよね?

ここまで見た
  • 123
  •  
  • 2012/06/30(土) 01:27:12.17
>>119
ま 常に上から目線だな


ここまで見た
  • 124
  •  
  • 2012/06/30(土) 01:27:37.03
見覚えの無いデータを持ち寄って交換するところがあれば良いんじゃねえ?

ここまで見た
  • 125
  •  
  • 2012/06/30(土) 01:27:42.66
>>120
それが本当にその顧客だって
どうやって調べる気?

たまたま似てるデータってことがあるよね。
言っとくけど、その問い合わせをしてきた顧客に
確認の質問したらダメだからね。

それこそ情報漏えいだ。

ここまで見た
  • 126
  •  
  • 2012/06/30(土) 01:28:27.67
>>122
天才!

ここまで見た
  • 127
  •  
  • 2012/06/30(土) 01:30:02.29
もうダメかもしれんね。

ここまで見た
  • 128
  •  
  • 2012/06/30(土) 01:30:49.68
データが使えるものか使えないものかは
その会社が決めるんであって、ここで議論してても仕方なかろ?
しょーもないつっこみはやめようぜ

使えるデータがあったら使う
使えないデータだったら使わない
ただそれだけ


ここまで見た
  • 129
  •  
  • 2012/06/30(土) 01:32:11.71
だから復元ファイルの削除もお願いしているだけ。

そのことについても、
しょーもないつっこみはやめようぜ


ここまで見た
  • 130
  •  
  • 2012/06/30(土) 01:34:15.81
>>125
つまり君は
相手が変装したり、変声期で声を偽っていたり、書類を偽装している可能性があるから
あらゆる顧客は本人と証明できないわけだね。



ここまで見た
  • 131
  •  
  • 2012/06/30(土) 01:34:27.25
お願いだけなら、聞かなくてもいいな
機会損失の損害賠償と引き替えに削除したらええがな


ここまで見た
  • 132
  •  
  • 2012/06/30(土) 01:35:31.30
情報漏えいというのは、関係ない会社に
関係ない会社の情報が漏れること。

つまり、「中を見て自分の会社のデータか確認してください」
なんてことは、言えないんだよ。

だって、自分の会社じゃないデータを見る=情報漏えいだから。

だから、削除してくださいというしかない。

ここまで見た
  • 133
  •  
  • 2012/06/30(土) 01:36:03.39
FSが約款を人質にとるなら
顧客は漏洩データを人質にとるべし


ここまで見た
  • 134
  •  
  • 2012/06/30(土) 01:36:39.35
>>130
意味不明。

情報漏えいを防ぐには、
見ないで消すしかないだろ。

ここまで見た
  • 135
  •  
  • 2012/06/30(土) 01:37:46.32
専用サーバに関しては混在無で、アクセス権の不都合のみだよね?
どうせ長い時間かけても完全には復旧しないんだろうし
RECOVERED_FILES最提供すれば良いのにな

ここまで見た
  • 136
  •  
  • 2012/06/30(土) 01:39:37.42
>>135
専用鯖でもメールシャッフルとかあったらしいから駄目っぽい

ここまで見た
  • 137
  •  
  • 2012/06/30(土) 01:40:31.50
>>132
それならその大切なデータを削除する代わりに
その分の賠償請求するしかないな
それが約束されないことには不公平

ここまで見た
  • 138
  •  
  • 2012/06/30(土) 01:41:15.11
>>137
約束は最初にしている。

ここまで見た
  • 139
  •  
  • 2012/06/30(土) 01:42:03.67
不公平というのなら
最初から契約するべきではないな。

ここまで見た
  • 140
  •  
  • 2012/06/30(土) 01:42:25.06
スマフォのニューステロップから飛んできますた

とうとう情報漏えいがニュースになったな

ここまで見た
  • 141
  •  
  • 2012/06/30(土) 01:42:38.99
>>139
そうだな、だから騙して契約させたファーストサーバの罪は重い

ここまで見た
  • 142
  •  
  • 2012/06/30(土) 01:43:06.02
>>135
専用サーバーのお客様より、
専用サーバー内において情報にアクセス権限を有していなかった者からも
参照できる状態になっているとの報告があったため

同じ会社でも、見せていい人と見せてはいけない人の情報があるのしらないの???
他人の給与明細とか丸見えだったら、自分はどう思う?


ここまで見た
  • 143
  •  
  • 2012/06/30(土) 01:44:04.17
>>141
騙される方が悪い

ここまで見た
  • 144
  •  
  • 2012/06/30(土) 01:46:14.60
>>143
それなら、この国は詐欺大国になるね
詐欺しても、騙されるやつが悪いってことで


砂時計アラームタイマー
フリック回転寿司
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード