俺のデータはすでに暗号化してスイスに預けている 68
ストーリー by nagazou
本当かなあ 部門より
本当かなあ 部門より
あるAnonymous Coward 曰く、
クラウド型ストレージサービスなのに、買い切り型に近い、99年もしくはアカウント所有者の生涯のいずれか短いほうの期間使えるサービスがあるという。pCloudというスイスのサービスで、日本語化もされている。10TBを1190USD(15万9216円)で99年か一生使える（ASCII.jp）。
日本では100年メールが6年で終了した実績があるが、100年サービスが続くという意味ではなく、一日のメールの容量から100年つづいても大丈夫という意味だったそうだ。99年以上生きたらどうする？という心配はスラド民の年齢層からして、杞憂といえるだろう。問題はこのサービスが長くはない寿命の間、続くかどうかだ。ちなみに他のクラウドストレージと違い、10TB以上増やせないということはないので、その点は安心だ。
au 「お、おう」 (スコア:2)
てか、100年後も今のプロトコルが使われているのかな。
3D ホログラフィック（一通 1TByteとか)も base64 でエンコードされて添付されていくるのかしら。
児童ポルノ (スコア:2)
と誤認識されて誤爆し、アカウント停止・クラウドデータ失われる事件が結構あるよね。
そういうリスクも含めて、外部サーバーは基本信用ならないです。
Re: (スコア:0)
pCloud は（追加料金必要ですが）クライアントサイド暗号化のオプションもあるのでそれを使えば先方にはファイルサイズしか分からないです。
ファイルの内容やファイル名は暗号化されて送信されますので、ファイルサイズだけで児童ポルノを判定するのはさすがに無理でしょう。
Re:児童ポルノ (スコア:1)
児童ポルノでないことを外部から確認できない場合は児童ポルノとみなすような法が定められたらどうする。
疑った側でなく疑われた側が潔白の証明ができるようにしておかないと安心できない世の中になりつつある。
Re:児童ポルノ (スコア:1)
そんなの、そういう法律ができた時に考えればいい事だろう
ていうか見かけ上何の変哲もないデータに他のデータを隠すことは技術的に十分可能
よってそんな法ができたとすると、「これは普通の文書だからポルノではないと確認出来ましたよね？」と誤魔化されて無意味な法になり下がるか
「これは秘密のデータが隠蔽されている可能性が否定できないので、ポルノでない事が確認できません」となってあらゆるデータが摘発可能になるか
どう転んでもろくでもない結果にしかならない気がする
「重要なデータはスイスに預けてある」に…… (スコア:2)
「スイスがナチもどきの連中に支配された世界で、ペーターを殺されたハイジが復讐者になる」という馬鹿映画「マッド・ハイジ」を混ぜると、どんな事態になるんだろうか？
5年以内に消えるに (スコア:0)
10テラバイト
なんかノリが (スコア:0)
タイトルと記事のノリと内容の薄さが昔のスラドみたい。
ログを残す系のネットニュースはどこも初期の方を見るとなんかノリが軽いよね。
しかしこういう「先に金を預かって長期間保証します」系がどこもクッソ怪しくて実際民間で上手くいった例が思い浮かばないレベルなのに、年金ってのは各国税金投入や強制や不満や色んな問題がありながらも曲りなりにも一応成り立ってるのが考えてみると不思議。
実効的な契約すら存在しないってのに。
あえて言えば銀行の類もそうか。
Re:なんかノリが (スコア:1)
とりあえずここは2013年のサービス開始とのことで10年続いているらしいので、100年メールよりはマシ。
でも、この春のキャンペーンで8割引きとかやってるので、加入者集めに苦労しているのかなと思う。定期的に会費を取るサービスとは違って、既存ユーザーはコストにしかならないから、常に新規会員を募らないといけないところはねずみ講と似てる。
Re:なんかノリが (スコア:1)
そういえば、高度成長期に1000年とかの定期預金があったとかを見たことがあるけど、
今でも有効なんかな？普通に利率10%超で計算してたような。
＃よく考えたら受け取れない世代の人が相続税で死ぬだけな気がする
年金はね (スコア:0)
現役世代に向けて「老後働けなくなっても"その時の"国がそこそこの生活は保証しますよ」が基本。
＃あくまで基本、資本主義だとブレがあるため完全な保証は困難
先に金預かってるんじゃないの。制度的には現役世代が金銭でリタイアした先達の生活費を工面してるの。だから高齢化、人口縮小で制度崩壊するって言われてる。
Re: (スコア:0)
そりゃそうなんだけど機能的/外観的には疑似的な長期契約が成立してるのが大したもんだ。
Re: (スコア:0)
厳密にはそうではない。ここでいう年金とは、老齢年金のことだが、年金保険という言葉があるように、
損害保険、生命保険などと同じ、一種の保険である。
その中身は「予想外に長生きしてしまった場合に、生活費を出します」の意味である。
80歳まで生きるつもりで、80歳で財産を使い切るプランでいたが、80歳になってもお迎えがくる様子がないのに財産がなくなってしまった、そのような時に、生活費を出します、そういう「保険」だよ。
つまりみんなが100歳まで生きるようになってしまったら当然破綻するので、年金支給年齢が後ろ倒しになるのは避けられない。
Re: (スコア:0)
普通の契約でそんなことやったら捕まるんだけどね
Re: (スコア:0)
年金は支払額を自由に変更できて経費を他の予算に押し付けることができるネズミ講だからね
Re: (スコア:0)
> 先に金を預かって長期間保証します
違うって
現役世代が退職者(年寄り)を養う仕組みだよ
払った金額が貰える金額に連携してるからそう勘違いしがちだけど
Re: (スコア:0)
Re: (スコア:0)
データを見ずに伝聞をうのみにしてるのね
Re: (スコア:0)
GPIFが2001年度の市場運用開始以降2022年度第3四半期までに溶かした年金は、マイナス98兆1,036億円です。
https://www.gpif.go.jp/operati... [gpif.go.jp]
Re: (スコア:0)
それも違う。お金を払うとお金がもらえる制度が年金。
Re: (スコア:0)
70歳までに半分くらい死んでるからね。
暗号化のオーバーヘッド (スコア:0)
ちょっくら調べてみたのですがよくわかりませんでした。メールにファイル添付すると1.4倍くらいになるという記事はありました。
自分の場合は2.4TBほどなので30%ほど暗号化で増えても3TBちょっとですからまぁ大丈夫かな。
平均余命はあと30年から40年くらいですから過去の二倍相当でも10TBには届かないことを考えればゴミデータ（主に黒歴史系）を削除することで余裕ありますね。もっとも転送時間のほうがシャレにならんような気がします。
ファイルの暗号化ってどれくらいファイルサイズ増えるものなのでしょうか。強力なものほど大きくなるんでしょうか。
Re: (スコア:0)
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。
せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。
ファイルサイズが増減するのは符号化。
あとは暗号化するとデータの偏りが減るので圧縮効率は悪くなります。
Re:暗号化のオーバーヘッド (スコア:2)
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。
せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。
絶対的に安全が確保できる、（完全な）秘密分散法 [wikipedia.org]による暗号化は、必ずファイルサイズ（の合計）が増えますけどね。
クラウドサービスを信用しない（できない）場合に有用です。
二つのクラウドサービスに暗号化データを預けて、両方が揃わないと復号ができないようにするとか、三つのクラウドサービス上の暗号化データのうち二つが揃えば（一つ失われても）復号できるような冗長化確保とかができます。
Re:暗号化のオーバーヘッド (スコア:2)
暗号技術であって暗号化ではないからね。
分散する時点で符号化していて、オーバーヘッドはその部分。
多分あなたが秘密分散法を理解できていないだけだと思う。私も数学は苦手だけど…
例えば「(t-1)次曲線に乗っている t 個の点がわかれば、曲線を表す多項式が一意に定まるという性質を利用」するシャミアのしきい値法 [wikipedia.org]の一番簡単な例として、一次方程式（直線）を使って 2つの数 (a, b) を暗号化することを考えると：
暗号化：直線 y = ax + b 上の異なる 2つの点 (x1, y1) と (x2, y2) を自由に決める。この点の情報（2組の数字）を、点ごとに分散して保管する（別々のクラウドサービスとか）。
復号： (x1, y1) もしくは (x2, y2) のどちらか 1点の情報から (a, b) を求めることははできない（1点を通る直線は無数に存在する）。2つが揃えば求めることができる（2点を通る直線は1つしかない）。
直線上の点は無限に存在するので、(x1, y1), (x2, y2), (x3, y3), ... と、3つ以上の点を決めれば、3つ以上に分散した情報のうち、任意の 2点の情報があれば (a, b) を求めることができる。
つまり2つの数 (a, b) を 2つに分散させて暗号化すると 2倍の 4つの数に、n個 (n>1) に分散させると n倍になる。（ファイルならサイズが増える。なお、それぞれの数を何 bit で表現できるかは別の問題。）
3組の情報があれば復号できるようにするためには 2次方程式を使えば良い。y = ax2 + bx + c 上の 3つの点 (x1, y1), (x2, y2), (x3, y3) の情報が集まれば、(a, b, c) を求めることができるし、2つの点の情報しか無ければ求めることはできない。このとき 3つの数を、2つの数 3組以上に分散させるから、3つに分散させる場合には 2倍に、4つに分散させる場合には 8/3 倍に、n個に分散させると 2n/3 倍に増加する。
# 以下、t個の点の情報があれば復号できるようにするためには、(t-1)次方程式を使えば良い、はず。
この n個に分散するときに n倍になったり、2n/3倍になったりという増加は、符号化とは関係がないし、この方式には復号鍵というものも存在しない。
暗号にもいろいろあるということです。
（どっか間違っているかな…）
Re: (スコア:0)
単なる符号化・複合化のオーバーヘッドの話と暗号化のオーバーヘッドの話は別ね。
基本的には暗号化したからといってサイズが増えるわけではない。
(サイズを増やすような暗号化が存在しないという話ではない)
メールの添付ファイルは最近だとほとんど BASE64 符号化だと思うけど、これは元々
6bitの情報を 64 種類の文字 (英大小文字、数字、記号2つ) に置き換える方法。
これにより (最近は減ったけど) 7bit しか通せない mail server を経由しても
問題ないという考え方。ただし 6bit の情報を ASCII 文字 1 文字 (= 8bit) に
符号化するので 4/3 倍 (1.333... 倍) になるという話。
#
Re: (スコア:0)
＃なお別途パッドを保存する容量は考えないものとする
さぞかし重要なデータが (スコア:0)
テスラに買収されなきゃいいね
Re: (スコア:0)
PeeCloudとか言いながら,便座をもってイーロン様が登場する。
「今回は軽めのやつ（便座）にしたよ。新品だから寝泊まりするときの枕にでもしようかな」
そして、便座芸として芸人が取り入れ、忘年会でやるやつが現れる
暗号化して残しておきたいデータ (スコア:0)
昔はいろいろあったんだけど、歳をとるにつれて、暗号化してまで残しておきたいプライベートのデータが少なくなってきている。
残したいデータは暗号化しなくていい、人に見られたくないデータは残す必要がない。
死期が近づいたら、情報機器やデータのパスワードはすべて解除して家族に託す予定。
Re: (スコア:0)
昔はいろいろあったんだけど、歳をとるにつれて、暗号化してまで残しておきたいプライベートのデータが少なくなってきている。
羞恥心が薄れている可能性は要確認ですね
本人はよくても周りに多大な迷惑となることもありますので
Re: (スコア:0)
元コメは「暗号化しないで(敢えて誰でも見える形で)残しておきたいプライベートのデータが増えてる」じゃねーだろ
俺じゃあるまいに
Re: (スコア:0)
残したいし暗号化もしなくても良いけど、第三者からみたら羞恥の極み、という可能性はある。
ステマ (スコア:0)
一番後ろのページのフッタに
って書いてあるけど、これ日本の販売代理店経由の広告記事かアフィリエイトだろ？
しっかりASCIIの記事からpCloudへのリンクにトラッキングパラメータ(Channelid)付いてるし
こんなのに引っ掛かる情弱スラド民はおらんよな？？？
Re: (スコア:0)
広告記事だからどうした？
嘘がなく、有用な内容なら問題ないだろう。
Re: (スコア:0)
最初に広告記事である旨を明記していれば気にしない。嘘がなく、有用な内容しか書いてない記事として読める。
しかし、何度もクリックさせて最終ページで普段より視点に偏りのある広告記事でしたと明かすから苛立たせる
Re: (スコア:0)
それで問題ないならステマ規制とか要らんのですわ
・消費者庁、ステマ規制の運用基準を公表 [srad.jp]
Re: (スコア:0)
提供とハッキリ書いてあるのにステマなどというスラド民はおるみたいだな
Re: (スコア:0)
ちなみにアナタ（このコメントを読んでいるアナタ）にお聞きしたいんですが、親コメント(#4447317)を読む前に広告記事だと認識していましたか？
Re: (スコア:0)
マジレスすると、目についたら取るくらいかな
どうあれ引数は少ないほどいい
Re: (スコア:0)
すぐステマ言う人個人的にはめんどくさいと思ってる。
しかしステマが気になる人にとっては重要なポイントらしいから否定するのもいまいちで。
試してみましたけど (スコア:0)
フォルダのタイムスタンプの保持が出来なかった（この手のサービスは大抵そうなのですが、
アップロードした日時になってしまう）ので、私の用途には合いませんでした。
あと、アカウントの削除がありませんでした。
放置していれば、いずれ失効し、パージされるとのことです。
Re: (スコア:0)
削除が→削除方法が
Re: (スコア:0)
アップロードした日時になってしまう）ので、私の用途には合いませんでした。
ファイル名で対処するとか
今朝のファイル - コピー (3650).txt
Re:試してみましたけど (スコア:2)
最新.txt
最新更新版.txt
最終更新.txt
決定版.txt
追加修正版.txt
.
.
Re: (スコア:0)
なんか異世界おじさん的なシチュエーションだと99年以内でもアカウントか消えているわけか。
Re: (スコア:0)
そうなんですよね。ユーザーなんですが、日付が保持できなくて rxync が使えないのが痛い。
サービスの永続性どう担保する (スコア:0)
必要リソース100年分先払い？
それとも100年後も存続してそうなところに後見してもらう？
事業が他社に渡ってもサービス内容保持する契約にする？
Re: (スコア:0)
倒産または買収された時点でチャラでしょ
Re: (スコア:0)
買収なら契約は引き継がれるだろう
# いらん部門として精算する会社に残されるかもしれんが、それは買収されなかったということで