アカウント名:
パスワード:
> そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
無料ユーザーは文句言えないんじゃ (スコア:3, 興味深い)
Re: (スコア:0)
Re: (スコア:1)
Aさんが大きなファイルをアップロードしようとすると、DropBoxクライアントはそのファイルのハッシュを計算してDropBoxサーバに送る。サーバでは、同一ハッシュのファイルを他の人がDropBox上に持ってないかをチェックする。Aさんがアップロードしようとしたファイルがたまたまよく知られた動画ファイルなんかであれば、B
Re: (スコア:0)
> そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが
Re: (スコア:2)
・AさんがファイルXをAさんのパスワードで暗号化したビット列x
・BさんがファイルYをBさんのパスワードで暗号化したビット列y
があって、xのハッシュとyのハッシュが偶然一致したので、サーバが勘違いしてビット列yはアップロードされずじまい。Bさんのファイル取得リクエストに対しては、間違ってビット列xが返される。xをBさんのパスワードで復号しても元のファイルYにはならないので、結果、Bさんからするとファイルの内容がランダム文字列に変化してしまったように見える
Re: (スコア:1, 参考になる)
また複数のユーザが同じものをおく可能性は低いという予想のほうがむしろ理解できないです． 自分の原稿，ホームビデオをおくというシチュエーションでは確かにあり得ないです． しかし，「面白いのみつけたよ」ってメール等で送られてきた画像・動画・文書をとっておいたりとか， もっと業務用のイメージで言えば，大きい「お知らせ文書」を添付で送られたりとか，重複が発生する場合もあるでしょう． で，多くのファイルは重複していないとしても，極一部の大きいファイルが数千人・数万人で重複していたら それを削ることの効果は無視できないものになるわけです．
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
ZFSの場合は、Solarisで複数コンテナを使うとほぼ同じ構成のOS一式のディレクトリ構造が複数作られることになる、とかいう仕組みだった気がするので、コストを掛けて実装する理由が想像できるんですが。
DropBoxの場合は、いろいろ考えても1%も削減できないんじゃないか?とか、でも貸しストレージ企業がストレージを1%削減できたとしたらそれは結構なコストダウンになるのか?とか、ついでに、元々更新チェックのためにハッシュを計算してサーバに投げてという仕組みは必須だから、そこに多少の機能を上乗せするだけで実装出来る重複排除機能はそんなに高コストではないのか?とか、でも中身はお客様ご自身以外には絶対見えませんと言う外部仕様にある意味反する機能だし・・・とか。